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.''     -=-