Written by Jan Otte, Tuesday 31 July 2018
Welcome to the second article of the series.
Just to briefly repeat what did we cover last time:
This article is meant as a continuation so please read through the first article if you haven't done it yet.
A very important topic to cover in this article series is something we call security model of the router.
Before getting to that, let's look at the user model. There are a few user models being used in the operating systems based on Linux. Please note that this definition is something to make our security model more understandable and help with further understanding of the securing process, it is not a formal definition as used in information science.
Also, we will be talking about a default models only. By using various system tools, the model can be made more complicated (though it usually does not bring any benefit unless a complete policy is implemented).
Most of the Linux desktops are following the root-user (typical desktop) or root-user-guest (public information kiosk) user models. Some distributions are also transferring to the root-privilegeduser-user or, very seldom, to the root-privilegeduser model (the single-user systems).
Most of the Linux-based servers are using the root-user-guest or root-user model.
Most of the consumer-level (not industrial) routers are also using root-user-guest model.
We are using the root-limiteduser model.
Now lets have a closer look to find out what we are talking about:
Now, what is the limiteduser role we are using in our user model?
Before answering the question, we actually need to understand a role of the router.
The router's possible usage (some use cases outlined in the previous article) require the router to act as a routing device and also an application gateway. It needs to be able to fulfill these roles properly.
A routing device itself does not need a regular user role. Why? Because there are no real user data. Users are not logging onto a desktop (no desktop there) nor storing any data there. A router needs to forward, generate, process, consume, filter or store some data. But these are not data like documents or multimedia content to be consumed by users logged onto the router.
As for the application gateway, router must be able to host applications providing added value to the owner of the device or consumers of the device's services. But again, the router is not fulfilling a role of a full-blown user-aware server. While it can provide data processing or even applications, it is not powerful enough to do e.g. webservice hosting or fulfill collaboration server/file server/domain server roles. Therefore, the applications the router is aimed for do not need user-level access. All the applications and services installed by default are system-level applications.
Therefore, there is only the root user allowed to log-in to the router and do any type of changes.
So, what is the limiteduser user role good for?
The limiteduser may be perceived (at this point of understanding) as a guest role. The limited user is allowed to access only the Web service and it is recognized as a limited user. In other words, the limited user is able to see statistics, settings (without passwords) and this role may be used by a custom user module if needed.
This limited user role, however, should never be given an access to the shell service (services mentioned in first article, will be discussed more in future articles) as that would break our security model (below). Remember this as a golden rule to stick with whenever you are going to add user accounts on the router - all added users must be playing the limiteduser role (no shell access).
Now we are ready to talk about security model. In our security model of the router, there are only two access levels possible:
What do we achieve by using this security model?
One of the typical security problem is privilege escalation. The operating system is a no small piece of software code. In software code, there are errors and especially these days, when speed of development is usually more important than quality, the number of both known and unknown bugs grows.
With our security model, there is no user (other than root), that is allowed to remotely access any type of shell. The point is to block all the possible local privilege escalation by simply not allowing remote access - by not allowing the user role on the system.
Simply put - a user only has a remote access to the system when she knows the root credentials. There is no need to use any local privilege escalation hack when you are root - there is simply nothing more to gain. All other users are banned from any access than the limited web service.
Well, we are for sure not able to close the possible unknown remote vulnerabilities in the services we are running (no-one is). But for that we do all we can do - monitor known information sources regarding security, determining if the vulnerabilities are present on our system and patching our operating system to close the vulnerabilities. Actually, we keep an eye on the published vulnerabilities pretty close and we release very quickly if there is a critical bug to be patched. As for some vulnerability monitoring sources, refer to the links below.
Also, we may talk about security of user applications - about services being ran by our users - but as we cannot foresee what the user is running (on top of the operating system), we cannot handle that. On the other side, we can (and we do) provide some securing possibilities, which will be discussed in later articles.
As evident from the security model, the local exploit attack vector is closed by following the root-limiteduser model. Of course, the web service (as the only service allowing some level of access) must be kept a close eye on, but that is something we do take care of. Also, any open IP service allowing hidden shell access would open up an way for attacker how to exploit a local privilege escalation bug via the IP service. Therefore we patch all such known bugs.
Next to that, we usually also patch the local vulnerabilities if possible (especially within the services), but not at the same pace as remote vulnerabilities.
To sum up the security model stuff: