SELinux Play Machine!

网上有人证明SELinux可以完全取代传统的Unix权限控制做得试验机，可以用来做测试和学习SELinux，很不错的想法！
下面是作者的Play Machine的访问方法，

Fedora

To access my Fedora play machine ssh to cable.coker.com.au
as root, the password is "qwerty".
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).
下面是关于这台Play Machine的FAQ，有机会一定也要搞台这样的Play Machine玩玩:-)

• 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_vicat >> 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 virtual machine. It's a real P3-1000 IBM Desktop machine
  running Fedora SE Linux. You really have UID==0. 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.