On Thu, Oct 18, 2001 at 11:51:06AM +1000, Simon Burge wrote:
> Steve Bellovin wrote:
> 
> > The problem is the 'incoming' directory.  My concern is that *if* someone
> > finds a flaw in ftpd (say, a buffer overflow), they could do a mknod in 
> > the upload directory and use that to escape the chroot.  The question is
> > what can I do to prevent that.  I've toyed with adding a 'no special 
> > files' flag to the kernel; I've also checked to see if there's some 
> > mount option akin to nocoredump, but I don't see any.
> 
> mount -o nodev ... ?
> 
>              nodev       Do not interpret character or block special devices
>                          on the file system.  This option is useful for a
>                          server that has file systems containing special de-
>                          vices for architectures other than its own.

So, I used to build run-from-ATA-flash bastion hosts like this:  all
filesystems with executables mounted read-only, all writable filesystems
mounted noexec, nodev.  Seemed simple and elegant, as well as secure; if
I ran at securelevel 2, I thought I was pretty safe.

Christos persuaded me that I wasn't.  Why?  Well, you can create a shared
library in one of the scratch filesystems and get it loaded using
LD_LIBRARY_PATH or LD_PRELOAD when running an existing executable.

Fixing this would require not allowing executable mappings if the backing
vnode weren't executable.  I think that this is actually unquestionably
correct, but because the original Sun implementation didn't require it,
we will get zillions of complaints from people who say that we "broke
shared libraries".

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
						   William Styron