Re: chroot useful?

[Darren Reed <darrenr () cyber com au>]

In some mail I received from Marcus J. Ranum, sie wrote
> 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.

I'm not sure it's a widely read book, but I think "use_priv()" from
386BSD as discussed in "The Basic Kernel Source Code Secrets" by
Jolitz & Jolitz (Appendix B) introduces a different approach with
defining roles depending on where access is first gained to the
Unix system.

>       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:
[...]

Yup.  Although, there are some system calls when the information provided
at the _system call_ interface isn't quite what you really want unless you
know how to translate it yourself.  E.g. does open("../../dev/kmem", ..)
actually open /dev/kmem ?  In the approach described above in 386BSD,
suser() is replaced by use_priv() in every location.  use_priv() is
essentially just one big switch statement and an if to determine if
your priviledges match or exceed those required to perform the task
being asked.

>       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

Sounds like an extension on "struct ucred".  However, this may not work
very well for OS's where you can modify tables but not recompile the
kernel.

Actually, I think there is a product (commercially available) which does
work exactly (or if not, very close) to your description.  The name of
it doesn't come to mind, but for those who know what RACF is, it is
essentially a RACF implementation and interface for Unix with all the
system calls "redirected".

[...]
> 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.

At this point, you're starting to get into OS specific code and you
either (a) duplicate existing code in the wrapper - dangerous because
what happens there could effect the system call or (b) put the hooks
further in as well.

[...]
> 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.

I think that the approach being described here is good for chroot'd
environments and maybe that's all.  Out in the big bad world of Unix,
if I have "uid 0" and I can use cron/crontab, what does it matter if
I can or can't open /dev/kmem myself ?  The cron daemon is not very
likely to have any restrictions placed upon it and neither is there
any standard transferral of priviledges you (no longer) have.

If I could mention that yucky Orange Book for a second, were the
data labelled going into cron/crontab and those programs recognised
those labels, then perhaps the confinment would be worthwhile.

> It'd be a good hack for building firewall systems, if I were still
> doing that kinda stuff. :)

mmm, good hacks :)

Darren