Keeping secrets from root on Linux

Question

I am looking for ways to harden a linux system so that even when gaining full root access (through legit or non-legit means), some secrets remain inaccessible. But first a little background.

Many of the different linux security models (SELinux, TOMOYO, etc.) concentrate on limiting what processes can do by policy and making sure they do not need full root access. They aim to keep any exploits contained so other parts of the system can not be compromised. However, it seems that these do not directly tackle the case where full root has already been gained - or, even further, keeping secrets from the valid root user. It seems that usually these can be just turned off by the real root at runtime.

Another approach is to limit the ways of gaining full unrestricted root - for example not allowing all access to a remotely connected root user, but requiring a login from the physical console. However, this is not my goal either - the assumption is that any such protections have been overcome already and the root is as legit as it can be.

It is obvious that anyone with physical access to the machine can get everything stored on the harddrive and possibly also everything stored in memory. It is also obvious that if the root user has the power to modify binaries or kernel images, no security promises can be given after reboot. I am only interested in attacks that can be done without rebooting the system.

Also, during the start up process, secrets will most likely be transmitted in through many places and many security critical functions are needed. It is ofcourse great if secrets can be protected during the start up process as well, but what is enough for me is a step during start up where elevated privileges can be dropped and after which there are no ways of regaining them.

So, with these limitations, what are the ways on Linux to prevent the full root user from accessing some secrets?

• Can there be files on the filesystem that are not accessible even to the full root by any means, but accessible to some processes? Some currently running processes, or even new processes started by the processes currently having access?

• Can secrets be kept in memory by running processes so that even the full root can not gain access to them by any means? Can these secrets be transmitted to new processes by some means that the root cannot affect?

This is a hard question to write so that I get answers relevant to me, so I will try to edit the question to be more specific if necessary.

---

Obvious things coming to mind that need to be limited would be:

• Disable access to /proc/mem

• Disable access to /proc/<pid>/mem

• Disable access to /proc/<pid>/fd/*

• Disable module loading (only after some modules have been loaded, preferably)

• Disable ptrace access to any process

Answer 1

Actually, it is possible to restrict root if one is prepared to define such a restriction as fundamentally trusting the operating system. This can be done using SELinux (that I know of) and presumably other such systems. The best such example I have seen of SELinux used in such a way is Russell Coker's Play SELinux Machine.

As a brief overview of how it works, the name "root" is not special in Unix. The UID 0 is. UID 0 is taken to mean "trust everything I say". This applies specifically to the standard access model used on Unices, Unixen or however you pluralise "Unix".

LSM, or Linux Security Modules, allows you to hook into just about everything and audit/deny actions as you see fit. In the case of SELinux, SELinux permissions are checked after Unix permissions, so your flow looks like this:

Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen

The next stage to understand is that there are, or have been historically, different versions of the SELinux Policy. Before I get into that, understand that in SELinux:

• inodes have types, suffixed _t, which might also be called domains; and
• users have roles, suffixed _r.

Combined, they control what action a user in a given role may do, and what a process in a given domain may do.

Now, there are three main SELinux policies:

1. targeted. This is the default policy for desktops like Fedora. The idea of targeted is that critical system services and daemons are run in domains, but a lot of what you the end user does is run in unconfined_u:unconfined_r:unconfined_t. No prizes for guessing what that means - if Unix permissions work, SELinux is effectively pass-through.
2. strict. This policy involves removing unconfined_u entirely. This is not an easy process, especially on the Linux desktop (i.e. init 5). Specifically, the X11 security model is not great and often requires unconfined_t for some applications. You can do this, but I would expect working with X11 to be harder (although not impossible) especially when executing GUI applications that require root. There is a project underway to provide support for SELinux-like functionality in X, called XACE (X Access Control Extensions).
3. MLS. MLS stands for multi-level security and means the end of the permission string: user_u:system_r:httpd_content_t.s0-s2:c5-c7, i.e. those s and c numbers actually mean something. Specifically they form a no read up, no write down setup such that unless the process is running as a certain level, the information they can see will be limited. The idea of this level of information is to protect classified assets—SELinux was originally developed by the NSA, presumably for this purpose.

So that's your background. Now, according to the web pages (see FAQ) root is UID 0 on the play machine; however, root is set to run as user_r and not sysadm_r in the strict policy. This means the user will not be allowed to execute administrative functions from the shell.

What would be interesting to know, then, is the status of the other processes that do require root. Presumably such processes have been appropriately labelled and have policies that allow them the access they require. The question then becomes how do you administer the system and can any of these processes launch a shell in that user's context. If that can happen, you can still manage an exploit.

Since the play machine is currently down (at time of writing), I'm working on assumptions here; but essentially, you would need a process running in sysadm_r and with UID 0 as your target for an exploit. Assuming such a process exists and is exploitable, you could still get to root. As for still being able to admin via root, there are two options that I can think of:

• Either there is a trusted transition of some sort that means root then can transition to sysadm_r (less secure) or
• On different runlevels, a different policy applies, so to admin the machine one sets the runlevel to 1 and the policy does not restrict root. I'm guessing here.

Summary

If your question is "can I easily and safely do this now?" the answer is no. If your question is "I am prepared to learn about SELinux, get down and dirty with my distribution and put up with quite a lot of things not working" the answer is it is possible to constrain root much more than your average install. That said, this does not in any way make you invulnerable to exploits—it does not make it impossible for a user to circumvent this extra access control either in software or physically.

So yes, you can make things invisible to root; however, the extra technical burden aside, the same caveats apply as to any access control setup on any normal user—there is no silver bullet.

Oh and blatant self-promotion: you might like my blog post on storing secrets in software. It's on the security stackexchange blog, so I don't feel so bad about promoting that. Essentially, as you can see, there are mechanisms to make life a lot more difficult for an attacker (and you), but in the end, it's a case of "turtles all the way down" i.e. fundamentally impossible to do.

Answer 2

I've had to tackle this problem before, when approached by a client wanting to keep 'private messages' secure between users on a website. It's possible to protect some data in some circumstances, but this is reasonably limited.

My approach was to simply store an encrypted version of the note on the server, and have it sent to them (once authenticated of course), then decrypt it entirely client-side. This means that even in the event of a full compromise of the server security (i.e. root access), the notes remained secure. The limitations of this however:

• Protected data is only secure up until the point of compromise, and no later. Depending on the method used to encrypt the information, a rooted server may trick the user into revealing the decryption keys (JavaScript injection, or for native GUI clients, issuing a compromised client update) or otherwise intercepting the decryption keys (if the keys are based off the same method as authenticating the user, such as a password, they can be intercepted during the server-side authentication process).
• Transmission requires perfect forward secrecy otherwise the encrypted data could be intercepted, stored, and then decrypted post-compromise as discussed above.
• This doesn't protect anything if the client is also compromised. Unless you're processing encrypted data entirely in your own head (and if you can, you deserve a trophy or something), you're going to be giving sensitive data to something, and nothing is perfectly uncompromisable.
• There is no way of using this data server-side (i.e. for indexing purposes) unless decryptable/plaintext metadata is stored alongside, which may reveal additional information.

Essentially this limits the potential uses for this scenario, and there are still weaknesses, but it is possible for it to work in some situations. Password hashing is a (reasonably) successful example of 'root compromise protection', in that even physical access won't reveal the passwords of a user (except of course if that password is transmitted post-compromise).

There's other examples in this thread that are worth looking into also, but give some thought to the client-side processing scenario, using the server simply as a secure storage service.

TC

Answer 3

Can there be files on the filesystem that are not accessible even to the full root by any means, but accessible to some processes? Some currently running processes, or even new processes started by the processes currently having access?

No. When a process can access them, so can root. If you want to do such things, you'll have to heavily modify the whole system, possibly a system which boots an immutable kernel from some readonly device and which denies root certain file/memory accesses while permitting them for other users which root can't impersonate.

Can secrets be kept in memory by running processes so that even the full root can not gain access to them by any means? Can these secrets be transmitted to new processes by some means that the root cannot affect?

No. See answer above.

You can't, by definition, restrict access for root. If you limit root's access then it isn't a root user anymore.

If I wanted to deny root access to secrets, then I'd try to hide them. Cryptographic containers, maybe hidden in swap memory or somewhere else and only accessible with a password or some other sort of steganography. It's damn hard to find a needle in a haystack, although not impossible.

Answer 4

There are a number of indirect ways through which root can end up executing arbitrary code. You can disable them, and indeed some security frameworks might disable them, but they cripple the ability of root to perform administration tasks.

For example, root can read and write to disks directly, bypassing all manner of filesystem permissions. You can take away this ability, but then root won't be able to move a full filesystem to a new disk in an emergency.

Root can load kernel modules, and thereby can do everything the kernel can do. You can take away this ability, but then you preclude loading drivers for hot-pluggable media. (This may be desirable in .001% of unix installations, but it's not the general case.)

Root can update executables that allow users to log in, such as login or sshd. These daemons handle user authentication, so if you control their code, you can inject a backdoor. You can take away this ability, but then root won't be able to perform security upgrades.

Root can create and remove users and change authentication credentials: if you can edit /etc/passwd to add an account, you can also edit it to temporarily make an account passwordless. You can remove this ability by making some files read-only even for root, but then you'll end up with a system where you can't create or remove user accounts without rebooting.

Security frameworks effectively create limited-root users which are root only in a subset of the system — root only in a virtual machine, not in the “real” system. This limited-root loses the possibility of performing administration tasks on the real system. I think virtualization is what you're after.

Answer 5

Like Falcon said, the root user by definition has access to all of those things, or it is no longer the root user.

The kernel controls all of the hardware, so once you are root you have the same access. You really need virtualization so your root user is only root for the virtualized OS it is running on and some Hypervisor sits outside of that root. (not to say that hypervisors aren't exploitable, but what you are trying to do is equivalent to this).

Answer 6

This is relatively easily accomplished by using a "two key" selinux system: root has no permissions to do anything, and some other user without root permissions does, so to change stuff, you first need to be the non-root other user, then you "su" to root to make the change.

Neither user in isolation can do or see anything.

I'm using this. It works really well.

Answer 7

The actual need is not well defined in the question, but two potential solutions what is alluded to have not been mentioned:

• Containers
• HSMs

Containers - which are of course just a more architecturally-sensible approach to what was being done piecemeal with tools like jails and SELinux - may be of relevance in the context of a reframing of the question - is there a way that a unix-like logical system can be exposed to attackers such that it may be root-compromised yet secrets on the physical system are still protected. With containers we are getting close to this goal. A recent paper by security group NCC is worth a read: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf

HSMs are hardware encryption devices that prevent the retrieval of decryption keys via physical or logical methods, so may be an answer to the question reframed as- I have secrets that I have to decrypt securely, what do I do with the keys.

Answer 8

Have you tried Grsecurity? It can effectively restrict root users in every possible way. https://grsecurity.net/

Grsecurity, coupled with PaX makes your box an impregnable fortress... if you do it right