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.