RBAC is a security feature of the hardened-sources kernels. As its name suggests, its a role-based access control system which allows you to define policies for restricting access to files, sockets and other system resources. Even root is restricted, so attacks that escalate privilege are not going to get far even if they do obtain root. In fact, you should be able to give out remote root access to anyone on a well configured system running RBAC and still remain confident that you are not going to be owned! I wouldn’t recommend it just in case, but it should be possible.
It is important to understand what RBAC will give you and what it will not. RBAC has to be part of a more comprehensive security plan and is not a single security solution. In particular, if one can compromise the kernel, then one can proceed to compromise the RBAC system itself and undermine whatever security it offers. Or put another way, protecting root is pretty much a moot point if an attacker is able to get ring 0 privileges. So, you need to start with an already hardened kernel, that is a kernel which is able to protect itself. In practice, this means configuring most of the GRKERNSEC_* and PAX_* features of a hardened-sources kernel. Of course, if you’re planning on running RBAC, you need to have that option on too.
Once you have a system up and running with a properly configured kernel, the next step is to set up the policy file which lives at /etc/grsec/policy. This is where the fun begins because you need to ask yourself what kind of a system you’re going to be running and decide on the policies you’re going to implement. Most of the existing literature is about setting up a minimum privilege system for a server which runs only a few simple processes, something like a LAMP stack. I did this for years when I ran a moodle server for D’Youville College. For a minimum privilege system, you want to deny-by-default and only allow certain processes to have access to certain resources as explicitly stated in the policy file. RBAC is ideally suited for this. Recently, however, I was asked to set up a system where the opposite was the case, so this article is going to explore the situation where you want to allow-by-default; however, for completeness let me briefly cover deny-by-default first.
The easiest way to proceed is to get all your services running as they should and then turn on learning mode for about a week, or at least until you have one cycle of, say, log rotations and other cron based jobs. Basically your services should have attempted to access each resource at least once so the event gets logged. You then distill those logs into a policy file describing only what should be permitted and tweak as needed. Basically, you proceed something as follows:
1. gradm -P # Create a password to enable/disable the entire RBAC system
2. gradm -P admin # Create a password to authenticate to the admin role
3. gradm –F –L /etc/grsec/learning.log # Turn on system wide learning
4. # Wait a week. Don't do anything you don't want to learn.
5. gradm –F –L /etc/grsec/learning.log –O /etc/grsec/policy # Generate the policy
6. gradm -E # Enable RBAC system wide
7. # Look for denials.
8. gradm -a admin # Authenticate to admin to do extraordinary things, like tweak the policy file
9. gradm -R # reload the policy file
10. gradm -u # Drop those privileges to do ordinary things
11. gradm -D # Disable RBAC system wide if you have to
Easy right? This will get you pretty far but you’ll probably discover that some things you want to work are still being denied because those particular events never occurred during the learning. A typical example here, is you might have ssh’ed in from one IP, but now you’re ssh-ing in from a different IP and you’re getting denied. To tweak your policy, you first have to escape the restrictions placed on root by transitioning to the admin role. Then using dmesg you can see what was denied, for example:
[14898.986295] grsec: From 192.168.5.2: (root:U:/) denied access to hidden file / by /bin/ls[ls:4751] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4327] uid/euid:0/0 gid/egid:0/0
This tells you that root, logged in via ssh from 192.168.5.2, tried to ls / but was denied. As we’ll see below, this is a one line fix, but if there are a cluster of denials to /bin/ls, you may want to turn on learning on just that one subject for root. To do this you edit the policy file and look for subject /bin/ls under role root. You then add an ‘l’ to the subject line to enable learning for just that subject.
role root uG
…
# Role: root
subject /bin/ls ol { # Note the ‘l’
You restart RBAC using gradm -E -L /etc/grsec/partial-learning.log and obtain the new policy for just that subject by running gradm -L /etc/grsec/partial-learning.log -O /etc/grsec/partial-learning.policy. That single subject block can then be spliced into the full policy file to change the restircions on /bin/ls when run by root.
Its pretty obvious that RBAC designed to do deny-by-default. If access is not explicitly granted to a subject (an executable) to access some object (some system resource) when its running in some role (as some user), then access is denied. But what if you want to create a policy which is mostly allow-by-default and then you just add a few denials here and there? While RBAC is more suited for the opposite case, we can do something like this on a per account basis.
Let’s start with a failry permissive policy file for root:
role admin sA
subject / rvka {
/ rwcdmlxi
}
role default
subject / {
/ h
-CAP_ALL
connect disabled
bind disabled
}
role root uG
role_transitions admin
role_allow_ip 0.0.0.0/0
subject / {
/ r
/boot h
#
/bin rx
/sbin rx
/usr/bin rx
/usr/libexec rx
/usr/sbin rx
/usr/local/bin rx
/usr/local/sbin rx
/lib32 rx
/lib64 rx
/lib64/modules h
/usr/lib32 rx
/usr/lib64 rx
/usr/local/lib32 rx
/usr/local/lib64 rx
#
/dev hx
/dev/log r
/dev/urandom r
/dev/null rw
/dev/tty rw
/dev/ptmx rw
/dev/pts rw
/dev/initctl rw
#
/etc/grsec h
#
/home rwcdl
/root rcdl
#
/proc/slabinfo h
/proc/modules h
/proc/kallsyms h
#
/run/lock rwcdl
/sys h
/tmp rwcdl
/var rwcdl
#
+CAP_ALL
-CAP_MKNOD
-CAP_NET_ADMIN
-CAP_NET_BIND_SERVICE
-CAP_SETFCAP
-CAP_SYS_ADMIN
-CAP_SYS_BOOT
-CAP_SYS_MODULE
-CAP_SYS_RAWIO
-CAP_SYS_TTY_CONFIG
-CAP_SYSLOG
#
bind 0.0.0.0/0:0-32767 stream dgram tcp udp igmp
connect 0.0.0.0/0:0-65535 stream dgram tcp udp icmp igmp raw_sock raw_proto
sock_allow_family all
}
The syntax is pretty intuitive. The only thing not illustrated here is that a role can, and usually does, have multiple subject blocks which follow it. Those subject blocks belong only to the role that they are under, and not another.
The notion of a role is critical to understanding RBAC. Roles are like UNIX users and groups but within the RBAC system. The first role above is the admin role. It is ‘special’ meaning that it doesn’t correspond to any UNIX user or group, but is only defined within the RBAC system. A user will operate under some role but may transition to another role if the policy allows it. Transitioning to the admin role is reserved only for root above; but in general, any user can transition to any special role provided it is explicitly specified in the policy. No matter what role the user is in, he only has the UNIX privileges for his account. Those are not elevated by transitioning, but the restrictions applied to his account might change. Thus transitioning to a special role can allow a user to relax some restrictions for some special reason. This transitioning is done via gradm -a somerole and can be password protected using gradm -P somerole.
The second role above is the default role. When a user logs in, RBAC determines the role he will be in by first trying to match the user name to a role name. Failing that, it will try to match the group name to a role name and failing that it will assign the user the default role.
The third role above is the root role and it will be the main focus of our attention below.
The flags following the role name specify the role’s behavior. The ‘s’ and ‘A’ in the admin role line say, respectively, that it is a special role (ie, one not to be matched by a user or group name) and that it is has extra powers that a normal role doesn’t have (eg, it is not subject ptrace restrictions). Its good to have the ‘A’ flag in there, but its not essential for most uses of this role. Its really its subject block which makes it useful for administration. Of course, you can change the name if you want to practice a little bit of security by obfuscation. As long as you leave the rest alone, it’ll still function the same way.
The root role has the ‘u’ and the ‘G’ flags. The ‘u’ flag says that this role is to match a user by the same name, obviously root in this case. Alternatively, you can have the ‘g’ flag instead which says to match a group by the same name. The ‘G’ flag gives this role permission to authenticate to the kernel, ie, to use gradm. Policy information is automatically added that allows gradm to access /dev/grsec so you don’t need to add those permissions yourself. Finally the default role doesn’t and shouldn’t have any flags. If its not a ‘u’ or ‘g’ or ‘s’ role, then its a default role.
Before we jump into the subject blocks, you’ll notice a couple of lines after the root role. The first says ‘role_transitions admin’ and permits the root role to transition to the admin role. Any special roles you want this role to transition to can be listed on this line, space delimited. The second line says ‘role_allow_ip 0.0.0.0/0’. So when root logs in remotely, it will be assigned the root role provided the login is from an IP address matching 0.0.0.0/0. In this example, this means any IP is allowed. But if you had something like 192.168.3.0/24 then only root logins from the 192.168.3.0 network would get user root assigned role root. Otherwise RBAC would fall back on the default role. If you don’t have the line in there, get used to logging on on console because you’ll cut yourself off!
Now we can look at the subject blocks. These define the access controls restricting processes running in the role to which those subjects belong. The name following the ‘subject’ keyword is either a path to a directory containing executables or to an executable itself. When a process is started from an executable in that directory, or from the named executable itself, then the access controls defined in that subject block are enforced. Since all roles must have the ‘/’ subject, all processes started in a given role will at least match this subject. You can think of this as the default if no other subject matches. However, additional subject blocks can be defined which further modify restrictions for particular processes. We’ll see this towards the end of the article.
Let’s start by looking at the ‘/’ subject for the default role since this is the most restrictive set of access controls possible. The block following the subject line lists the objects that the subject can act on and what kind of access is allowed. Here we have ‘/ h’ which says that every file in the file system starting from ‘/’ downwards is hidden from the subject. This includes read/write/execute/create/delete/hard link access to regular files, directories, devices, sockets, pipes, etc. Since pretty much everything is forbidden, no process running in the default role can look at or touch the file system in any way. Don’t forget that, since the only role that has a corresponding UNIX user or group is the root role, this means that every other account is simply locked out. However the file system isn’t the only thing that needs protecting since it is possible to run, say, a malicious proxy which simply bounces evil network traffic without ever touching the filesystem. To control network access, there are the ‘connect’ and ‘bind’ lines that define what remote addresses/ports the subject can connect to as a client, or what local addresses/ports it can listen on as a server. Here ‘disabled’ means no connections or bindings are allowed. Finally, we can control what Linux capabilities the subject can assume, and -CAP_ALL means they are all forbidden.
Next, let’s look at the ‘/’ subject for the admin role. This, in contrast to the default role, is about as permissive as you can get. First thing we notice is the subject line has some additional flags ‘rvka’. Here ‘r’ means that we relax ptrace restrictions for this subject, ‘a’ means we do not hide access to /dev/grsec, ‘k’ means we allow this subject to kill protected processes and ‘v’ means we allow this subject to view hidden processes. So ‘k’ and ‘v’ are interesting and have counterparts ‘p’ and ‘h’ respectively. If a subject is flagged as ‘p’ it means its processes are protected by RBAC and can only be killed by processes belonging to a subject flagged with ‘k’. Similarly processes belonging to a subject marked ‘h’ can only be viewed by processes belonging to a subject marked ‘v’. Nifty, eh? The only object line in this subject block is ‘/ rwcdmlxi’. This says that this subject can ‘r’ead, ‘w’rite, ‘c’reate, ‘d’elete, ‘m’ark as setuid/setgid, hard ‘l’ink to, e’x’ecute, and ‘i’nherit the ACLs of the subject which contains the object. In other words, this subject can do pretty much anything to the file system.
Finally, let’s look at the ‘/’ subject for the root role. It is fairly permissive, but not quite as permissive as the previous subject. It is also more complicated and many of the object lines are there because gradm does a sanity check on policy files to help make sure you don’t open any security holes. Notice that here we have ‘+CAP_ALL’ followed by a series of ‘-CAP_*’. Each of these were included otherwise gradm would complain. For example, if ‘CAP_SYS_ADMIN’ is not removed, an attacker can mount filesystems to bypass your policies.
So I won’t go through this entire subject block in detail, but let me highlight a few points. First consider these lines
/ r
/boot h
/etc/grsec h
/proc/slabinfo h
/proc/modules h
/proc/kallsyms h
/sys h
The first line gives ‘r’ead access to the entire file system but this is too permissive and opens up security holes, so we negate that for particular files and directories by ‘h’iding them. With these access controls, if the root user in the root role does ls /sys you get
# ls /sys
ls: cannot access /sys: No such file or directory
but if the root user transitions to the admin role using gradm -a admin, then you get
# ls /sys/
block bus class dev devices firmware fs kernel module
Next consider these lines:
/bin rx
/sbin rx
...
/lib32 rx
/lib64 rx
/lib64/modules h
Since the ‘x’ flag is inherited by all the files under those directories, this allows processes like your shell to execute, for example, /bin/ls or /lib64/ld-2.21.so. The ‘r’ flag further allows processes to read the contents of those files, so one could do hexdump /bin/ls or hexdump /lib64/ld-2.21.so. Dropping the ‘r’ flag on /bin would stop you from hexdumping the contents, but it would not prevent execution nor would it stop you from listing the contents of /bin. If we wanted to make this subject a bit more secure, we could drop ‘r’ on /bin and not break our system. This, however, is not the case with the library directories. Dropping ‘r’ on them would break the system since library files need to have readable contents for loaded, as well as be executable.
Now consider these lines:
/dev hx
/dev/log r
/dev/urandom r
/dev/null rw
/dev/tty rw
/dev/ptmx rw
/dev/pts rw
/dev/initctl rw
The ‘h’ flag will hide /dev and its contents, but the ‘x’ flag will still allow processes to enter into that directory and access /dev/log for reading, /dev/null for reading and writing, etc. The ‘h’ is required to hide the directory and its contents because, as we saw above, ‘x’ is sufficient to allow processes to list the contents of the directory. As written, the above policy yields the following result in the root role
# ls /dev
ls: cannot access /dev: No such file or directory
# ls /dev/tty0
ls: cannot access /dev/tty0: No such file or directory
# ls /dev/log
/dev/log
In the admin role, all those files are visible.
Let’s end our study of this subject by looking at the ‘bind’, ‘connect’ and ‘sock_allow_family’ lines. Note that the addresses/ports include a list of allowed transport protocols from /etc/protocols. One gotcha here is make sure you include port 0 for icmp! The ‘sock_allow_family’ allows all socket families, including unix, inet, inet6 and netlink.
Now that we understand this policy, we can proceed to add isolated restrictions to our mostly permissive root role. Remember that the system is totally restricted for all UNIX users except root, so if you want to allow some ordinary user access, you can simply copy the entire role, including the subject blocks, and just rename ‘role root’ to ‘role myusername’. You’ll probably want to remove the ‘role_transitions’ line since an ordinary user should not be able to transition to the admin role. Now, suppose for whatever reason, you don’t want this user to be able to list any files or directories. You can simply add a line to his ‘/’ subject block which reads ‘/bin/ls h’ and ls become completely unavailable for him! This particular example might not be that useful in practice, but you can use this technique, for example, if you want to restrict access to to your compiler suite. Just ‘h’ all the directories and files that make up your suite and it becomes unavailable.
A more complicated and useful example might be to restrict a user’s listing of a directory to just his home. To do this, we’ll have to add a new subject block for /bin/ls. If your not sure where to start, you can always begin with an extremely restrictive subject block, tack it at the end of the subjects for the role you want to modify, and then progressively relax it until it works. Alternatively, you can do partial learning on this subject as described above. Let’s proceed manually and add the following:
subject /bin/ls o {
{
/ h
-CAP_ALL
connect disabled
bind disabled
}
Note that this is identical to the extremely restrictive ‘/’ subject for the default role except that the subject is ‘/bin/ls’ not ‘/’. There is also a subject flag ‘o’ which tells RBAC to override the previous policy for /bin/ls. We have to override it because that policy was too permissive. Now, in one terminal execute gradm -R in the admin role, while in another terminal obtain a denial to ls /home/myusername. Checking our dmesgs we see that:
[33878.550658] grsec: From 192.168.5.2: (root:U:/bin/ls) denied access to hidden file /lib64/ld-2.21.so by /bin/ls[bash:7861] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:7164] uid/euid:0/0 gid/egid:0/0
Well that makes sense. We’ve started afresh denying everything, but /bin/ls requires access to the dynamic linker/loader, so we’ll restore read access to it by adding a line ‘/lib64/ld-2.21.so r’. Repeating our test, we get a seg fault! Obviously, we don’t just need read access to the ld.so, but we also execute privileges. We add ‘x’ and try again. This time the denial is
[34229.335873] grsec: From 192.168.5.2: (root:U:/bin/ls) denied access to hidden file /etc/ld.so.cache by /bin/ls[ls:7917] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:7909] uid/euid:0/0 gid/egid:0/0
[34229.335923] grsec: From 192.168.5.2: (root:U:/bin/ls) denied access to hidden file /lib64/libacl.so.1.1.0 by /bin/ls[ls:7917] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:7909] uid/euid:0/0 gid/egid:0/0
Of course! We need ‘rx’ for all the libraries that /bin/ls links against, as well as the linker cache file. So we add lines for libc, libattr and libacl and ls.so.cache. Our final denial is
[34481.933845] grsec: From 192.168.5.2: (root:U:/bin/ls) denied access to hidden file /home/myusername by /bin/ls[ls:7982] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:7909] uid/euid:0/0 gid/egid:0/0
All we need now is ‘/home/myusername r’ and we’re done! Our final subject block looks like this:
subject /bin/ls o {
/ h
/home/myusername r
/etc/ld.so.cache r
/lib64/ld-2.21.so rx
/lib64/libc-2.21.so rx
/lib64/libacl.so.1.1.0 rx
/lib64/libattr.so.1.1.0 rx
-CAP_ALL
connect disabled
bind disabled
}
Proceeding in this fashion, we can add isolated restrictions to our mostly permissive policy.
References:
The official documentation is The_RBAC_System. A good reference for the role, subject and object flags can be found in these Tables.