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
1  
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
2  
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 at 13:42

1 Answer 1

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

Your Answer

 
discard

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.