Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 http://www.coker.com.au/selinux/play.html:

Free root access on a SE Linux machine!

To access my Debian play machine ssh to play.coker.com.au 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 irc.freenode.net.

Here is a quick FAQ

2) From http://www.osnews.com/comments/3731

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. mcafee.com/us/products/… –  Christopher Jul 17 '14 at 13:42

2 Answers 2

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. –  Sadeq Dousti Dec 30 '13 at 21:06

Is it possible to harden a Linux box (possibly with SELinux), such that even the root user cannot do specific malicious activities on it?

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


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.