RE: securety related question...

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Richard
> Lightman
> Sent: Sunday, October 06, 2002 7:56 AM
> To: [email protected]
> Subject: 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:

<parts of very thorough reply deleted>

Yes, I found this when I made some modifications to these programs.
When I changed djbdns to use the syslog facility, I discovered one
had to make some access to the log before jumping into chroot, or
the time zone settings in the log entries would be incorrect :-)

> 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.
>

Well, I'm using splogger :-)

> 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.
>

Yes, this would be a good arrangement.  Based on the responses, I think
what I will do is try my virtual chroot arrangement for qmail, since it
is easy to do.  But, when I get a chance, I'll look at modifying the
qmail source to allow it to chroot as well.  If I'm successful, I'll
make the patches available :-)

Thanks for all the helpful replies!

BK

Bob Kimmel
Bendheim Center for Finance
Department of Economics
Princeton University
[email protected]

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