In some mail I received from Robert Smith, sie wrote
[...]
> This is an excellent model to pursue.  One of the arguements that will
> probably come up is:
> what is the performance impact of this security STUFF?

Well, I suspect that would depend on how complex the solution you
intend to implement is :-)

As a first pass, I'm looking at doing a system call wrapper in (e.g.)
/sys/i386/i386/trap.c:syscall().

That's rather trivial but doesn't always provide you with all the
information you need.

The suser() function is used in a lot of places to determine "am I root ?"
where I suspect what people would like it to do is "can I really do this ?".
I'm working on categorizing these, similar to what they did with 386BSD, but
for it to really be effective for "domain" style protection, you need to
change other programs too.  And of course, the default action for the
suser() replacement would be to work the same as it does now to limit
lossage.

Replacing suser() goes a long way to providing extended security checks
(even for root) although there are a couple of other things I'd like to
be able to control.

Of course once the hooks are there, you need something on the other side.

An example of what came to mind was some sort of trap back to a user program
which checked the request against a configuration file.  An example would be
you do "cd /home/web", it looks in its config file which has something like
"chdir user=!web /,!/home/web" and returns saying "no, don't allow that chdir"
- even if it is mode 777!

Darren