Meet the Gang   1   2   3   4   5   6   7   8   9

pseudo-chroot

From Faber Fedor

Answered By Mike "Iron" Orr, Heather Stern

Hi guys (and Heather)!

Is there a way to chroot a user such that they can't travel out of heir home dir but without having to copy a bunch of binaries to their home dirs?

I'd like to restrict my users to not being able to see into /bin, /etc, and most importantly /home/httpd without jumping through hoops.

[Iron] For /home/httpd, set the ownership and permissions so the webserver process has read access, the person who maintains the content has read/write access, and nobody else has any access.

The standard Debian setup is for the webserver to run as user 'www-data', group 'www-data', and the HTML directory (/var/www) is:

drwxrwsr-x   11 root     www-data     1024 Nov 12 17:25 /var/www/

Unix comes with a catchall user 'nobody', group 'nogroup', for processes that shouldn't have any privileges. But in that case, you'd either have to make /home/httpd world-readable (which is what you said you don't want), or owned by 'nobody' or group 'nogroup' (which is bad because 'nobody' should never own any files, although some sysadmins disagree).

Chroot requires you to copy the binaries, as you say.

The 'bind' filesystem in recent 2.4 kernels allows you to make a directory appear to be in two different locations, and the shadow location can be inside a chroot jail. Or so some documentation I saw a few months ago said. That may or may not be more convenient than copying binaries and shared libraries.

Why don't you want your users reading files in /bin and /etc? Normally it's only a few senstitive files that need to be protected (those containing passwords). For each case, you'll need to think of a strategy that allows the user to do their work without being able to read the password. For programs, make the file world-executable but not world-readable (mode -rwxrwx--x).

To prevent users from listing the files in /bin (to discover commands they didn't know existed), but still allow them to run or list programs whose names they know, make the directry itself world-executable but not world-readable (mode -rwxrwx--x).

To prevent users from reading sensitive files in /etc, arrange to have the program run as a different user or group, and give only that user/group access to the configuration file(s). But that means making the program setuid or setgid, so that it will run under its own permissions rather than the user's, but set[ug]id itself is a security risk. Relatively speaking, setgid is safer than setuid.

As an alternative to setuid, you can arrange for the programs to run via 'sudo' or 'super', two proxy programs that do something like suid but in a safer and more configurable way.

It's probably a bad idea to make /etc non-world-readable. Numerous standard programs would break.

[Heather] Hmm, if most of your users don't need to access the web server, and you aren't offering home based web access... www.example.org/~username ... then you could simply run the web daemon in a more complete than usual chroot, and only give members of the webmaster team accounts within its jail. You'd need more than one ssh running... one per jail, and one for the top... but it can be very effective.

Each "child jail" can have much more limited /etc contents and a seriously stripped binaries tree, as well as only having the user accounts that match its purpose. The top can house your syslog, as there's an easy option for reading multiple /dev/log nodes. I think you get up to 19 extras.

The trick works especially well if combined with some of the recent "chroot as a one way trip" patches being offered out there. These nearly always prevent double chrooting, so you'll need to tweak the trapped daemons to be ok with not being able to chroot any further. The patches keep changing too, so I haven't settled on a preferred one yet.

This page edited and maintained by the Editors of Linux Gazette Copyright © 2002
Published in issue 74 of Linux Gazette January 2002

HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

Meet the Gang   1   2   3   4   5   6   7   8   9