Firewall Wizards mailing list archives
RE: chroot useful?
From: Joseph Judge <joej () joesmac ultranet com>
Date: Mon, 17 Nov 1997 08:13:59 -0500
From what I understand of MemCo's SeOS --- this is what they do via
a loadable kernel module. This means the Unix acts "normal" until after boot, then then there is this RACF-like set of ACLs that have to be happy before the call is passed on to the system. -- joe ----------
From: Marcus J. Ranum[SMTP:mjr () nfr net]
Sent: Sunday, November 16, 1997 9:59 AM To: firewall-wizards () nfr net Subject: Re: chroot useful? On the topic of reducing privilege, one thing I've always wanted to do (but never had time for!) is what I'd call "syscall wrappers" for lack of a better term. Most UNIXes have a jump table that defines all the system calls, and almost all include the source for the jump table as part of the basic binary distribution, so that you can add new ones if you want. So, the idea: 1) write a call-through interface that replaces all the original calls in syscalls.c. On a BSD4 system its /sys/kern/syscalls.c and it looks like: char *syscallnames[] = { "#0", /* 0 = indir or out-of-range */ "exit", /* 1 = exit */ "fork", /* 2 = fork */ "read", /* 3 = read */ "write", /* 4 = write */ This is just the names. There's a mapping table that is built which maps syscall #4 to the actual kernel function that does write( ) -- so you'd replace that with syscall_wrapper_write( ) which would do various things and maybe call the original write( ) just the same way that tcp_wrappers "replaces" the original program that inetd would call with an intermediary. 2) maintain a separate data structure that is a call permissions table, then keep a set of reference counted structures around, which are inherited across exec( ) and fork( ) just like file descriptors. if you want to be somewhat hands off, I think you could almost do it so that you didn't even need to put a hook in struct proc but obviously fixing struct proc would be much easier 3) add a new ioctl that allows a process to give away its right to use a syscall. this would be irrevocable. it should have nothing to do with being uid == 0. 4) perhaps add a new syscall that allows you to adopt a complete set of syscalls. to use this you must be uid == 0 and not have given the right to use it away. this way uid == 0 could give away a process branch's ability to ever regain syscalls, by simply giving away the magic syscall 5) whenever a call is made you check and see if the process is allowed to do it, or you return EPERM and a new errno value. You could further extend the system by having stub syscalls (let's not call them proxies, shall we?) that actually unrolled some arguments and further checked them. For example, the read( ) stub syscall might check the file read/write/append mode. Then you could have a process' parent gave away its child's ability to do anything but write( ) to a file after it had open( )ed it in append mode. I suppose you could do things like disable relative path processing ("..") on a per-process basis. There are times when I really would have liked that... Or the ability to only exec( ) files in "." This would extend the Java sandbox type concept into the operating system -- a very useful idea if anyone could take advantage of it. There are problems with this scheme (aren't there always!?) -- lots and lots of UNIX libraries do mysterious things under the sheets that would break. DNS, for example, expects to read /etc/resolv.conf. On other systems it reads other files before even doing that. And so on. Another problem is that while it's a useful idea it's a kludge. Normally it'd be better to design a generalized mechanism for granting O/S interface permissions as part of a complete system for permissions (files, ACLs, O/S calls, network calls) The other problem with syscall wrappers is that they assume that the person using them has an awareness of all the "gotchas" and ways a particular call could be abused by a given application. That's too large a knowledge set to expect anyone to have, for any practical purpose. It'd be a good hack for building firewall systems, if I were still doing that kinda stuff. :) mjr. -- Marcus J. Ranum, CEO, Network Flight Recorder, Inc. work - http://www.nfr.net home - http://www.clark.net/pub/mjr
Current thread:
- Re: chroot useful?, (continued)
- Re: chroot useful? Darren Reed (Nov 16)
- Re: chroot useful? Aleph One (Nov 17)
- syscall wrappers (was Re: chroot useful?) Bennett Todd (Nov 17)
- Re: syscall wrappers (was Re: chroot useful?) George Ross (Nov 20)
- Re: chroot useful? Darren Reed (Nov 16)
- RE: chroot useful? Y. W. Ko (Nov 16)
- Re: chroot useful? Anton J Aylward (Nov 17)
- Re: chroot useful? Darren Reed (Nov 20)
- Firewalling DCOM and brethren David C Niemi (Nov 21)
- Re: Firewalling DCOM and brethren Magossa'nyi A'rpa'd (Nov 21)
- Re: chroot useful? Darren Reed (Nov 20)
- Re: chroot useful? Anton J Aylward (Nov 17)
- RE: chroot useful? Joseph Judge (Nov 17)
- Re: chroot useful? Paul McNabb (Nov 17)
- Re: chroot useful? Paul McNabb (Nov 17)
- Re: chroot useful? C. Harald Koch (Nov 20)
- Re: chroot useful? Anton J Aylward (Nov 20)
- Re: chroot useful? chuck yerkes (Nov 21)
- Re: chroot useful? Adam Shostack (Nov 21)
- Re: chroot useful? chuck yerkes (Nov 21)
- Re: chroot useful? Paul McNabb (Nov 20)
- Re: chroot useful? Colin Campbell (Nov 21)
- Small code (was Re: chroot useful?) chuck yerkes (Nov 23)
- Re: chroot useful? Colin Campbell (Nov 21)
- Re: chroot useful? Anton J Aylward (Nov 21)