Re: securety related question...

* Bob Kimmel <[email protected]> [2002-10-06 10:32]:
> 
> The problem is that the alternative is sometimes not to chroot at all.
> For example, I am currently running qmail.  I would like to chroot, but
> I can't (at least, if there is a way to do it, I don't know what it is).
> My idea was, using the mount --bind option might allow one to use chroot
> when one couldn't otherwise.  So, my question is, does doing this defeat
> the purpose of chroot as badly as not using chroot does :-)  If I can
> chroot a daemon without mounting other parts of the filesystem within
> the chroot jail, I'll do that.  But if I can't, is a virtual chroot
> better than no chroot at all?
> 

Instead of prepareing the jail, and the runing the program in chroot,
it would be better to run the program, form the inside, collect
file descriptors and maps of the things you want and then chroot
before handling any input. This does not protect against a modified
binary, but then if the cracker could do that, he could modify your
setup for the chroot jail.

The is what DJB's dnscache and tinydns do. Here is proc entry for
dnscache on my machine:

-r--r--r--    1 root     root            0 Oct  6 12:15 /proc/115/cmdline
lrwxrwxrwx    1 root     root            0 Oct  6 12:15 /proc/115/cwd -> /var/dnscache/root
-r--------    1 root     root            0 Oct  6 12:15 /proc/115/environ
lrwxrwxrwx    1 root     root            0 Oct  6 12:15 /proc/115/exe -> /usr/bin/dnscache
-r--r--r--    1 root     root            0 Oct  6 12:15 /proc/115/maps
-rw-------    1 root     root            0 Oct  6 12:15 /proc/115/mem
-r--r--r--    1 root     root            0 Oct  6 12:15 /proc/115/mounts
lrwxrwxrwx    1 root     root            0 Oct  6 12:15 /proc/115/root -> /var/dnscache/root
-r--r--r--    1 root     root            0 Oct  6 12:15 /proc/115/stat
-r--r--r--    1 root     root            0 Oct  6 12:15 /proc/115/statm
-r--r--r--    1 root     root            0 Oct  6 12:15 /proc/115/status

/proc/115/fd:
total 0
l-wx------    1 root     root           64 Oct  6 12:15 1 -> pipe:[675]
l-wx------    1 root     root           64 Oct  6 12:15 2 -> pipe:[675]
lrwx------    1 root     root           64 Oct  6 12:15 3 -> socket:[707]
lrwx------    1 root     root           64 Oct  6 12:15 4 -> socket:[708]


/proc/115/maps contains:
08048000-08054000 r-xp 00000000 3a:06 30385      /usr/bin/dnscache
08054000-08055000 rw-p 0000c000 3a:06 30385      /usr/bin/dnscache
08055000-0809e000 rwxp 00000000 00:00 0
40000000-40013000 r-xp 00000000 3a:06 2543       /lib/ld-2.2.5.so
40013000-40014000 rw-p 00012000 3a:06 2543       /lib/ld-2.2.5.so
40018000-40019000 rw-p 00000000 00:00 0
40019000-4012b000 r-xp 00000000 3a:06 2542       /lib/libc-2.2.5.so
4012b000-40131000 rw-p 00111000 3a:06 2542       /lib/libc-2.2.5.so
40131000-4022a000 rw-p 00000000 00:00 0
bffff000-c0000000 rwxp 00000000 00:00 0

As you can see, dnscache got access to its binary, and various
libraries before chrooting to /var/dnscache/root, which contains only
configuration files. These need to be available because I might add
extra servers for dnscache to use.


Doing this with qmail will be more of a challenge. Qmail uses several
processes to handle different parts of the delivery process.

USER       PID  PPID COMMAND
qmaill     113     1   multilog t /var/log/multi/qmail
qmails     118     1   qmail-send
root       120   118     qmail-lspawn ./Maildir/
qmailr     121   118     qmail-rspawn
qmailq     122   118     qmail-clean

multilog gets its input from a file descriptor, only needs to access
the directory where it rotates the logs. Once the binary and libraries
are in place, this program could probabl run in chroot.

qmail-lspawn handles local delivery. It has to be able to change
persona to any uid that can receive mail so it can run the user's
choices for mail delivery. This can involve access to an file the
user has access to, so qmail-lspawn would not work well in a chroot
jail.

qmail-send picks up e-mails and hands them to qmail-lspawn,
qmail-rspawn and qmail-clean through file descriptors. qmail-rspawn
delivers to remote users, and I am not sure what qmail clean does,
but I think all three could probably chroot to the /var/qmail directory
once they have the liraries.

Richard
-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message