Sign up ×

I read or heard somewhere (maybe in LinuxCBT's SELinux course; but I'm not sure) that there are online Linux servers, for which the password of the root user is also given. The Linux server is hardened using SELinux rules, such that everyone can login with the root user, but cannot make any harm to the OS.

It seems like a myth to me, but I wanted to make sure: Is it possible to harden a Linux box (possibly with SELinux), such that even the root user cannot do specific malicious activities on it? (Examples: deleting system files, clearing log files, stopping critical services, etc.)

Such a Linux box will be a great starting point for building a honeypot.

Edit: Based on an answer (now deleted), and a little Googling, I got at least two links which pointed out to such hardened Linux servers. Unfortunately, both servers are down. For the record, I'll copy-paste the descriptions here:

1) From

Free root access on a SE Linux machine!

To access my Debian play machine ssh to as root, the password is ...

Note that such machines require a lot of skill if you are to run them successfully. If you have to ask whether you should run one then the answer is "no".

The aim of this is to demonstrate that all necessary security can be provided by SE Linux without any Unix permissions (however it is still recommended that you use Unix permissions as well for real servers). Also it gives you a chance to login to a SE machine and see what it's like.

When you login to a SE Linux play machine make sure that you use the -x option to disable X11 forwarding or set ForwardX11 no in your /etc/ssh/ssh_config file before you login. Also make sure that you use the -a option to disable ssh agent forwarding or set ForwardAgent no in your /etc/ssh/ssh_config file before you login. If you don't correctly disable these settings then logging in to the play machine will put you at risk of being attacked through your SSH client.

There is an IRC channel for discussing this, it is #selinux on

Here is a quick FAQ

2) From

Hardened Gentoo's purpose is to make Gentoo viable for high security, high stability production server environments. This project is not a standalone project disjoined from Gentoo proper; it is intended to be a team of Gentoo developers which are focused on delivering solutions to Gentoo that provide strong security and stability. This machine is Hardened Gentoo's SELinux demo machine. The primary use of it is to test and audit SELinux integration, and policy.

share|improve this question
It's been claimed here too. While it is surely theoretically possible, it seems hard to me (unless you confine that root user so much that it can't do anything useful). Writing SELinux rules that really do what you set out to do is difficult in the best of cases. –  Gilles Dec 25 '13 at 22:53
With recent kernels, non-root users can create namespaces where they have UID 0. Since they aren't UID 0 in the toplevel namespace, they can't harm the system. They intrinsically get no opportunity for harm, unlike the SELinux approach where all such opportunities have to be taken away. See kernel: Namespaces support, and Fully seperate two accounts without installing seperate operating systems? –  Gilles Dec 25 '13 at 22:56
Not SELinux, but I have used McAfee HIPS to accomlish this.… –  Christopher Jul 17 '14 at 13:42

3 Answers 3

Reality: yes, SELinux can confine the root user.

This is possible because SELinux do not actually care about the current Unix user: all it sees is a supplementary metadata called the context (which includes, among other fields, a domain field) and which lets SELinux decides whether the requested action can be authorized or not.

What one usually conceives as the root user would be mapped in SELinux as a root Unix user running either the unconfined_t or sysadm_t SELinux domains. It is the classical full-powered omnipotent root user.

However, one could perfectly setup his system to spawn a root shell (I mean root Unix user shell) running the restricted user user_t SELinux domain. As per SELinux policies, such shell would be no different than any other restricted users shells and would have no special privilege on the system, thus effectively confining the root user.

Appart from an experimental point-of-view, doing such thing literally is useless, however similar practice find their way in real world. A classic example would be a database administrator needing to be able to stop/start the database daemons, edit configuration files, etc. Without SELinux, all these actions would require the user to escalate toward root privileges (even if it is normally for a single command line via the sudo tool for instance, however even that may be prone to leaks).

Thanks to SELinux, we could give this user a genuine root shell, but instead of running unconfined_t or sysadm_t domains it will run the dbadm_t domain. This mean that he will have more privilege than a restricted user, but these new privileges will be limited to what is needed to administrate the database server: this user will not be able to tamper with other services, files or run other administrative commands than those strictly required to do his job.

The same way, the web server and other services administrators could also have other root shells running in parallel on the same system, every one will see their current Unix user being root, but thanks to SELinux each one will have effectively different privileges limited to what is needed for their own purposes.

share|improve this answer

Yes, it's possible. But not very useful.

You could theoretically disallow the root user from running binaries that could be used for malicious purposes, enforcing policies via something like SELinux. However, this presents a problem, which is that even if the root user was initially disallowed from doing something, he or she could just use other methods to change or remove the SELinux policies. Because of this problem, you would effectively have to disallow the root user from performing any action at all, making it not very useful.

share|improve this answer
First, I was as pessimistic as you are. But, gaining more knowledge, it seems that there's no need to "disallow the root user from performing any action at all." Check my edited answer, which includes links and info to proof-of-concepts . Unfortunately, they're no longer available; but it seems that the implementations were not severely restrictive. –  M.S. Dousti Dec 30 '13 at 21:06


This may sound cheap, but it's easy: change the uid of the user root to non-zero. Simply go into /etc/passwd and /etc/shadow, modify the existing uid=0 entries from "root" to something else, and then add an account named "root" whose uid is not zero and unused.

It achieves the purpose without. It's also a way to claim that anyone may have "root access" without actually providing escalated privileges.

share|improve this answer
Well yes, but then the root user is simply not actually the root user. The question is asking whether the actual super user can be limited in such a way. –  terdon Apr 15 at 10:28
Sounds dangerous - except you create another account with uid 0 of course. But that would be the same as renaming root, and reusing the name "root". –  Volker Siegel Apr 15 at 10:39
The question only refers to "root" which is not necessarily equivalent to the super-user, ie, uid=0. On rare occasions, this is a useful distinction. –  Otheus Apr 15 at 10:56
Nevertheless, the context makes it clear that the OP is asking whether the super user, and not some random user whose username is root can be limited in such a way. –  terdon Apr 15 at 11:28
That's your interpretation. "Is it possible... that even the root user cannot do specific malicious activities on it? Yes. Rename the user. –  Otheus Apr 15 at 11:47

Your Answer


