Preemptive strategies

Chris Buxton cbuxton at menandmice.com
Wed Oct 29 17:09:24 PDT 2008


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




More information about the hlfs-dev mailing list