Preemptive strategies

Robert Connolly robert at linuxfromscratch.org
Wed Oct 29 20:07:10 PDT 2008


On Wednesday October 29 2008 08:09:24 pm Chris Buxton wrote:
> I'm no programmer, so I can't help with the request. However, I can
> clarify something about the behavior of named:
>
> named doesn't chroot to an empty directory (at least not, in any
> useful way). It chroot's to a directory containing the things it needs
> to use during its operation:
>
> - configuration and data files
> - /dev/{*random,null,log} and possibly others
> - /etc/localtime (might not be necessary, but I've always included it)
> - maybe even /proc, remounted read-only
>
> Some of these can be opened before chrooting, if necessary, such as /
> dev/random and /dev/log, but doing so reduces the security of the
> chroot by providing an open file handler leading outside of the jail.
>
> However, back to Robert's original point, the service binary itself (/
> usr/sbin/named or equivalent) is not in the jail. If it were put
> there, launched, and then deleted, would the system keep it around as
> an open (unnamed) file, for memory mapping? In other words, when a
> binary loads, does it all load, or is part of it left unread and only
> loaded as needed? If so, then chrooting a running pid might
> conceivably provide a file handler leading outside of the jail - a
> file handler owned by the kernel, I think, and not the process itself,
> but still something to think about.
>
> Chris Buxton
> Professional Services
> Men & Mice
>
> On Oct 29, 2008, at 4:48 PM, Robert Connolly wrote:
> > The runas program I mentioned is part of Titan Security Toolkit:
> > http://www.trouble.org/titan/
> >
> > It unfortunately has a special copyright, organizations with more
> > than 300
> > employees need written permission to use it, and they don't want
> > people
> > adding patches which change or add behavior, only bug fixes.
> >
> > Anyway, it's exactly the same as 'env -i su - user -c', except that
> > it also
> > has a chroot option, and does not require the user to have a valid
> > shell.
> >
> > The package also includes a program named noshell, which is
> > like /sbin/nologin, except that it logs login attempts to syslog.
> >
> > Chrootuid is similar:
> > ftp://ftp.porcupine.org/pub/security/index.html
> >
> > But has a freer copyright.
> >
> > The problem I have with these, and all other chroot tools, is that
> > they run
> > the target program inside the chroot, not outside, so it doesn't
> > work with an
> > empty chroot. named, ntpd, etc, start as root, chroot to an empty
> > directory,
> > then drop root.
> >
> > I can't think of a way to chroot to an empty directory, unless the
> > chroot(2)
> > call is done within the program. The chroot(2) system call doesn't
> > allow for
> > a pid to be chrooted after it is loaded.
> >
> > I think what I'm looking for is a new chroot system call, like
> > chroot_pid:
> > int chroot_pid(const char *path, int pid);
> >
> > In the kernel, it looks like chroot(2) is sys_chroot(), in fs/
> > open.c. I looked
> > at it, and I have no idea how to add pid support to it.
> >
> > Can any of you make something usable enough to submit to kernel.org?
> > or think
> > this not a wise idea?
> >
> > robert
> > --
> > http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
> > FAQ: http://www.linuxfromscratch.org/faq/
> > Unsubscribe: See the above information page

The point of this is not packages which support chroot(2), but for everything 
else.

irssi could be patched to check for /usr/sbin/setpcaps, check 
for --with-linuxcaps, and chroot to ~/.irssi without suid, but irssi is only 
one package.

We get the same effect with /usr/bin/irssi as script that 
does '/usr/bin/irssi.bin ; pid=$$ ; chroot_pid $pid', with sgid group 
irssi. /usr/bin/irssi.bin is only executable by group irssi. group irssi, 
in /etc/group, has no users. /usr/bin/chroot_pid has the sys_chroot 
filesystem linux capabilities attribute. This script would work with any 
package without patches... some tweaking may be needed though, but less than 
patching the package. Grsecurity allows us to disallow users to run their own 
programs, so with this users could only run the system irssi which chroot's 
itself.

The same can be done with lynx, and almost anything else. The application 
would have read access to / only during startup. The focus is on applications 
that access the network, but it could work with others.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20081029/b8c1ab4d/attachment.sig>


More information about the hlfs-dev mailing list