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 pageThe 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
pgpcKSelUGas2.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
