Root for All on the SE Linux Play Machine

SE Linux gives you an extra layer of security that protects the system even from root. Russell decided to show how it works by giving everyone root access.
How to Run Your Own Security Test/Challenge Machine

If you want to run your own security test machine, the first thing to do is find a suitable place to house the server. This is easier said than done, as such a machine attracts a lot of network scans and penetration attempts on the network. The terms of service of most ISPs prohibit such things, and you risk being disconnected.

Once you have arranged the hosting, you have to devise a good method for taking the machine off-line in a hurry in case something goes wrong. Direct physical access to the power switch is convenient for this purpose. A method of controlling the power or hardware reset over the Internet also is a good option. Failing that, you should install the test machine on its own switch port, for a managed switch, or, as a cheaper option, on a crossover cable to a Linux machine running Netfilter. This way, you can disable network access to the entire machine quickly.

The next thing to do is choose suitable hardware. For example, an iPAQ is not ideal for this type of machine, as it is possible to render it unusable through software. Commodity desktop PC hardware is a good option, though. The worst-case scenario would be replacing the motherboard, which is cheap and easy. Another good option is to obtain free hardware, so you won't have lost any money if the system dies. Some nice hardware seems to end up in the rubbish nowadays.

Once you have the machine basically configured, you have to set up suitable packet filters to prevent it from being used for attacks on other machines. How strict these filters are depends on the agreement you have with your ISP. If you have no specific agreement regarding such access—if you are using a home broadband connection—then the filters should be very strict. If your contract specifically permits running servers, you can allow greater access, even the ability to host Web pages. Granting more network access allows more interesting tests to be performed. A frequent complaint from users was the test machine didn't have enough access granted to allow a wide enough range of testing. For the next play machine, I plan to provide full network access, so users can receive mail on the machine, host Web pages and do most other things that they request.

The firewall should be set up both on the test machine and on any other machines on the same physical network. The test machine can be configured reasonably with Netfilter to discard or reject the packets silently, without logging them, although you may want to log them for interest. The router should be configured to log all such packets when it drops them, so you know if someone gets past the filter on the test machine or cracks its security in any other way. If your ISP knows of your plans for a security test server, then a minimal firewall should work. This will prevent SMTP connections, spoofed source IP addresses on packets being sent and connections to Web-mail services such as Hotmail, which includes blocking access to Web proxies and configuring any local Web proxies to not allow the test machine access to Web mail.

Having any machines other than the test machine and the router on the same LAN may be a bad idea, as it may allow the test machines to be used to attack the other machines. Having several security test machines on the same physical network may be fun, though, as it would allow them to be used to attack each other. If you have only one test machine, connecting it to the router by a crossover Ethernet cable or a null-modem cable running PPP probably is a good option.

Once the machine is connected and all firewalls are arranged, the difficult work begins. You have to determine how to limit the access that is granted and audit it as appropriate. For SE Linux, all that needs to be done is to change the root entry in the users' file to user root roles { user_r };. Another option is to remove the root entry from the database entirely, as the default identity of user_u is permitted only the role user_r and gives the extra restriction of preventing password changes. To change the password of a nonprivileged account, the identity must match the user name.

The policy database then has to be recompiled and loaded into the kernel to apply the change. After that, the root user has no significant access to the system, so make sure you grant some other account administrative privileges first.

The next time I set up a test machine, I plan to get someone with legal experience to review the usage conditions to make sure they state what is permitted in a clear and legally binding language. I will place the password on a Web page that has the usage conditions and change it regularly, so people can't get in without reading the conditions. Too many people were obviously not reading the conditions, particularly regarding local DoS attacks through fork bombs and using all available disk space.

If you run an SE Linux play machine, please let me know so I can publicize it on my Web page.

I have been using the IRC channel #selinux on for supporting the play machine and for answering general SE Linux questions. I encourage anyone else who is running such a security test machine, whether SE Linux or some other system, to join that channel to discuss it.