SE Linux Play Machine

Free root access on a SE Linux machine!

To access my Debian play machine ssh to zp7zwyd5t3aju57m.onion as root, the password is “SELINUX“.
I give no-one permission to distribute this password. If you want to share information on this machine you must give the URL to this web site. In some jurisdictions it would be considered a crime to distribute the password without my permission (IE without giving the URL to this web page).

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.

FAQ

• Editing thanks.txt_append_only with vi won’t work, use cat or echo to append data to the file. The following commands will work:

  echo something >> thanks.txt_append_only_dont_edit_with_vi
  cat >> thanks.txt_append_only_dont_edit_with_vi
  

• There is no harm in letting you see dmesg output for such a machine, security by obscurity isn’t much good anyway. For a serious server you would probably deny dmesg access, but this is a play machine. One of the purposes of the machine is to teach people about SE Linux, and you can learn a lot from the dmesg output.
• This is not a simulated machine or honeypot. It’s a real Lenovo ThinkCenter desktop PC running Debian/Jessie (pre-release) SE Linux in a Xen DomU. You really have UID==0. The Xen configuration is a default Debian install with a standard Debian kernel. SE Linux does it’s own permission checks in addition to the Unix permission checks. If you don’t believe me you are free to write assembler programs to call getuid() etc. But it would be a lot easier for you to just install a recent version of Debian or Fedora, see how it works, and read the source if you wish.
• I will provide instructions on installing such machines soon.
• To administer a SE Linux machine you need to have sysadm_r (the SE Linux administrative role) and UID==0 (the regular Unix admin account). So there needs to be a UID==0 account. As in regular Linux the UID==0 account does not need to be named “root”. In the case of this machine the root account has UID 0, but it has few privs in SE Linux.
• The default policy in Fedora is known as the targeted policy, it has no restrictions on user login sessions (so can never be used for such a machine). The policy I use for this machine is known as the strict policy. The default configuration of the strict policy does not support running in such a manner and requires some changes.
• This machine is intentionally more permissive than some other play machines. I let you see the policy files so you can learn how to configure a machine in this way.
• Regarding core-dumping bash to read the history. That’s nice work, but you could have just used cat, grep, or any of your favourite tools on /root/.bash_history with much less effort.
• Some people have asked for ping, telnet, etc access. I would like to provide such access (and have provided it in the past). I removed ping access because some people were using ping with large packet sizes to attack machines with small network connections. I removed telnet access because people were running scripts to try and discover (and attack) hosts with broken telnetd’s. As for whether the machine is usable without such access, for it’s intended purpose (demonstrating what SE Linux can do) it is quite useful. As a general shell server it’s not very useful because you share your account with lots of people who may rm your files or kill your processes.
• Some types of files and directories may not be stat’d by unprivileged users (this includes shadow_t for /etc/shadow). Such files and directories show up in flashing red in the output of “ls -l” because ls can’t even determine whether it’s a file or a directory.