• 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 P3-800 Compaq Desktop machine running Debian/Etch 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 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.
  • Exec-shield is being run too. It is a kernel patch to prevent stack-smashing attacks.
  • This machine is intentionally more permissive than the Gentoo play machine. 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.