8

I'm looking for holes in my current implementation of a chroot jail that I have implemented for a group of users. Is there anything I can do better here?

I utilized the following packages: RHEL6 openSSH jailkit

The user runs a standard shell, not the jailkit specific shell, but I configured openSSH to start the users chrooted via the MatchGroup directive.

Only ssh access to this server is enabled.

I utilized jailkit to build the jail itself and resolve the needed library dependencies.

I build the jail using copies of all the required files instead of hard links.

Each user has their own jail and the mount point for the jails is mounted nosuid.

The users do not require anything needing SUID so I take care to strip all such SUID bits within the user's jail, not that it matters much with the nosuid flag on the mount.

All files outside of the user's home directory are root owned.

The following is the complete list of commands, paths, and devices I've made available to the users in the jail. Pretty standard stuff:

/dev/random /dev/urandom /dev/null /bin/vi /bin/env /usr/bin/which /bin/hostname /usr/bin/id /usr/bin/file /usr/share/misc/magic /lib/libnsl.so.1 /lib64/libnsl.so.1 /lib/libnss*.so.2 /lib64/libnss*.so.2 /etc/nsswitch.conf /etc/ld.so.conf /bin/sh /bin/bash /bin/ksh /bin/ls /bin/cat /bin/chmod /bin/mkdir /bin/cp /bin/cpio /bin/date /bin/dd /bin/echo /bin/egrep /bin/false /bin/fgrep /bin/grep /bin/gunzip /bin/gzip /bin/ln /bin/ls /bin/mkdir /bin/mktemp /bin/more /bin/mv /bin/pwd /bin/rm /bin/rmdir /bin/sed /bin/sh /bin/sleep /bin/sync /bin/tar /bin/touch /bin/true /bin/uncompress /bin/zcat /etc/motd /etc/issue /etc/bash.bashrc /etc/bashrc /etc/profile /usr/lib/locale/en_US.utf8 /usr/bin/awk /usr/bin/bzip2 /usr/bin/bunzip2 /usr/bin/ldd /usr/bin/less /usr/bin/clear /usr/bin/cut /usr/bin/du /usr/bin/find /usr/bin/head /usr/bin/less /usr/bin/md5sum /usr/bin/nice /usr/bin/sort /usr/bin/tac /usr/bin/tail /usr/bin/tr /usr/bin/sort /usr/bin/wc /usr/bin/watch /usr/bin/whoami /usr/bin/mc /usr/bin/mcedit /usr/bin/mcview /usr/share/mc /etc/terminfo /usr/share/terminfo /usr/bin/joe /usr/bin/nano /usr/bin/vi /usr/bin/vim /etc/vimrc /etc/joe /usr/share/vim

To complicate things, I have an automount exposed within the jailed user home directory which mounts a remote FUSE/sshfs filesystem as root with the following options: ro,noexec,nodev,nosuid,nonempty,noatime,follow_symlinks,allow_other,auto_cache,max_read=65536
Each user gets thier own automount entry hard coded to the jailed user home.

I have compiled all the exploits I could find intended to break out of the chroot and intentionally put them in the jail. Without removing the 'nosuid' directive from the jail mount, owning the file to root, and setting the SUID bit on one of them, I have been unable to break out.

Anything else I'm missing?

Improve this question

1 Answer 1

Reset to default
5

bash can establish tcp connections, you shouldn't forget to check your firewall. Maybe you would like to drop all traffic from the users with iptables -A OUTPUT -m owner --uid-owner youruser -j DROP but this shouldn't replace your firewall.

If the user is able to open a connection he could scan the network and exploit vulnerable services to break the jail or compromise over servers.

Improve this answer
3
  • 1
    They have no /dev/tcp or /dev/udp. Still an issue?
    – Daren Schwenke
    Commented May 16, 2012 at 21:25
  • 2
    /dev/tcp and /dev/udp arn't real devices. The don't exist in my system but I can use them anyway in bash. It's a feature the bash developers built in.
    – sfx
    Commented May 16, 2012 at 23:34
  • 2
    Yep. Just tried it in the jail and it worked. Scary. Thank you. cat </dev/tcp/10.0.0.1/21 220 (vsFTPd 2.0.5)
    – Daren Schwenke
    Commented May 17, 2012 at 0:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .