Subject: Re: "real" OpenBSD compat - how hard would it be?
To: Alaric B. Snell <alaric@alaric-snell.com>
From: Jaromir Dolecek <jdolecek@netbsd.org>
List: port-i386
Date: 03/19/2003 18:59:15
Alaric B. Snell wrote:
> On Wednesday 19 March 2003 16:04, Jaromir Dolecek wrote:
>
> > Remapping of the syscalls is really easy.
>
> Really? How easy would this be:
Trivial. Just start using systrace, integrated into -current :)
Jaromir
> I had an idea a few years back when helping my then-employer set up a very
> secure chrooted environment under FreeBSD. I had to write a version of ps
> that used nothing but /proc to avoid having to be setgid kmem, and so on.
> IIRC we had no setuid or setgid processes in the chroot, but still a fully
> functional Unix shell account server. We even joked about the only noticeably
> difference being the lack of many devices in /dev and a /kernel file, so got
> a Visual Basic source file and put it under /kernel :-)
>
> But the idea was to have a bitmap in the proc structure that limits what
> syscalls a process can make. There would be a syscall to clear bits and mask
> off chosen syscalls, but no way of setting them again; like chroot it would
> be a restriction that can only increase. The bitmap would be inherited by
> forked children.
>
> The plan was to be able to ditch all sorts of worrying syscalls when starting
> processes in the chroot; so that even if they did managed to escalate to root
> privs somehow (perhaps with a bug in the sshd) they would still not be able
> to mknod a special device or reboot the system or write to sysctls or
> whatever.
>
> It's a super-paranoid extra layer of security, but it struck me as a fun
> idea. One thing that it *would* add that is currently impossible (as opposed
> to just adding another obstacle to already-forbidden things) is that a
> process could fork children that were incapable of opening files or network
> connections, having just read and write on existing fds passed down from the
> parent, by masking off open, socket, listen, bind, etc. Masking off mmap
> would be a problem since it would prevent you from mmapping /dev/zero to get
> more copy-on-write zero pages, but one could have the mmap syscall always be
> permitted if you're mapping /dev/zero, and only to check the flag if you're
> doing other files - but I don't even know if NetBSD uses the whole 'mmap
> /dev/zero' thing to map zero pages in?
>
> The tricky parts would be the various places where certain syscalls can do a
> wide variety of tasks. As always.
>
> ABS
>
> --
> A city is like a large, complex, rabbit
> - ARP
>
--
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow. Do not let this distract you.'' -=-