Written by Jan Otte, Monday 30 July 2018

Welcome to the second article of the series.

Just to briefly repeat what did we cover last time:

• We sketched out the topic for the series.
• We have touched the default configuration and configuration customization topic.
• We have established basic terminology.
• We had a brief look at the core services of the router.
• We have touched the default password change topic.

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:

• root-user means there are basically two user roles in the system. The first, root is a so-called superuser. Alternatively called admin. This is the role for the system administrator who can do anything - also altering the system data. Then, there is also a role of a regular user of the system. It does not matter how many users are on the system. All of them are the regular users - the non-superuser ones. Every user can alter their own data while not allowed to alter other user's or system's data.
• root-user-guest uses the same user model as above, but it adds one more role - the guest user. The guest is (usually) using the system without knowledge of the access credentials and without the possibility to alter any of the system or user data. Also, the nature of guest data is usually temporary - once the guest session ends, the data are wiped out and all processes terminated.
• The root-privilegeduser-user adds another user role into the mix. The privilegeduser is actually a user that can act as root in the system without additional authentication (just retyping a privilegeduser password does not count as additional authentication, it is merely a refresh of the login procedure). It does not add any real additional security to the system, it just masks the root account so that the remote access to the root account can be disabled. It has a few another implications to the system but nothing significant enough to discuss at this place.

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:

1. The root user. This is administrator level access. System, it's data and running application are on this level. This is the only level allowing configuration changes. Root user can be allowed to log in using running services - let's count with SSH and HTTPS protocols at the moment, we will discuss v2/v3 differences later on.
2. The limited user. Only able to log into the web service using a limiteduser role (cannot change anything, useful only for looking at status, statistics and configuration). There is no way how to elevate from this access level to the root user access level.

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:

• Non-root users are allowed to access the limited user interface via web service. No other remote access.
• Only root user is allowed to remotely access full web service and remotely access a shell.
• We release patch releases for remote exploits very quickly.
• We do not promise to patch every local exploit (because of the security model blocks typical attack vector here).
• You should never-ever allow non-root user shell access to the router, as that action would break the security model and open potential hole for an attacker.

Links:

• NIST Vulnerability DB
• CVE Details
• CVEs on Mitre
• CERT Vulnerability Notes DB