[future patch] dropping user privileges on demand

[ari]

nick at garage.freebsd.pl said this stuff:

> Let me explain you something. "flowpriv" isn't a well known standard.
> If you susspect that developers will rewrite their programms (and there
> are many things for rewritting to use such mechanism) you're wrong.
> This is my opinion.
> That's why I've decide to create CerbNG - it is totally transparent
> for applications and I think Niels Provos shares my opinion in systrace.

And i'm sure it is and will be useful.

However, performance drawbacks are nothing to sneeze at.  Additionally,
systrace acts on the system calls you specify.  If programmers are to
take advantage of the interface, you can't expect them to drop every
unnecessary system call that may potentially do harm.  This makes their
applications cumbersome and utterly nonportable.  They must be able to
take advantage of class-based privileges, which will automatically do
what they're supposed to do on different systems.  An example that i've
used in the past is creating a file on the filesystem.  The programmer
should be able to drop filesystem creation permissions, without worrying
about the need to drop open, mkfifo, bind, link, symlink, mkdir, and any
other system calls that happen to be available in this particular kernel
version.  Note that any patches one adds to his kernel may also affect
the available system calls.

Of course it isn't a well-known standard.  It hasn't even been written
yet, aside from some proof-of-concept code that i have yet to package up
and put on the site.  Nor was systrace a well-known standard before it
was written (not that it's necessarily a "standard" now, though it is
quite popular).  I wouldn't expect programmers to immediately begin
using this code; if it catches on, however, and it's implemented in a
number of different operating systems, then there stands a greater
chance.  If it doesn't catch on and isn't used, then so be it.

So while i do appreciate the suggestion of using systrace, it's not
something i'm considering.  What i _am_ considering, however, is tying
this into mandatory access controls, for which hooks are already in the
kernel.  But MAC doesn't seem to be fully implemented yet, as of
5.1-RELEASE.

I am threatening neither cerb nor systrace by implementing flowpriv[1].
I believe they serve different purposes, and should work together quite
well.

ari


[1] The name may or may not stay "flowpriv".  Again, it's in its early
stages, and this is a working title.  "F" is for "function"; "low" and
"priv" relate to dropping privileges.