Privileges (was libresolv+ bug)

[mcnabb () argus cu-online com (Paul McNabb)]

I've worked with several different MLS systems that used the concept
of least privilege.  Without straying to far outside the bounds of
this forum, I'll give a brief overview of how *most* work.

1) The process table is changed so that processes have a set of
privileges (implemented as a bit map).  Various vendors have different
bit sets, and most systems have more than one type of privilege set
but I won't go into that here.

2) The kernel is changed so that instead of checking for UID=0 it
checks to see if a process has the right privilege or set of privileges.

3) Files get a new attribute set, including one or more sets of
privileges.  These are picked up when executing a file the same way
that setuid/setgid works.  (This implies a new file system type, but
not always.)

4) Privileges are not necessarily handled across an exec(), so shell
escapes and other nefarious holes don't give you a process with privilege.

5) Some implementations are very "plain Jane" (I guess that's not PC)
but get the job done.  Others are very feature rich and allow all
kinds of restrictions, emulation modes, environment sensitive privileges,
etc.

6) There is usually a single command, similar to chmod, that allows
a person to set privileges on files (of course there are restrictions
about who can run the program and under what circumstances).

7) COTS programs don't need modifying to get privileges, since they
are sitting on a file system type that supports them external to the
file itself.  Some integration is required to get a program to work
exactly as you want if it is complex and written with superuser
functionality built in to its internal logic.

8) Running on a system with least privilege can knock out about 90%+
of the known security holes in Unix (without any other change)!  So
it's definitely a good idea to consider such a system for critical
machines, such as servers and firewalls.

9) And yes, our company makes versions of Solaris 2.x that have this
privilege mechanism in them.  Most other Unix versions have a "trusted
version", such as HP, SCO, Digital Unix (old OSF), AIX, Solaris 1.x
(old SunOS), etc.

>  Date:        Fri, 23 Aug 1996 20:01:13 +0800
>  From: "Mikolaj J. Habryn" <dichro () tartarus uwa edu au>
>
>  >>>>> "TP" == Thomas Ptacek <tqbf () rdist org> writes:
>
>      TP> Instead of talking all day about how we should prevent
>      TP> security problems by patching individual security holes, both
>      TP> entirely and, on a program-by-program basis, piecemeal, as
>      TP> those holes are revealed to us, we should be discussing how to
>      TP> provide programs with enough privileges to do their job, and
>      TP> nothing more. Unfortunately, none of the solutions we've got
>      TP> out-of-the-box and on the net address "least privilege"
>      TP> adequately.
>
>    absolutely. for some reason, there is a distinct lack of
>  appreciation of the two issues. privileged code that is badly written
>  can and will be exploited. but containing that (inevitable) damage
>  seems to get very little attention - perhaps because it's so difficult
>  to do well on traditional unix systems.
>
>      TP> Why would you continue forcing programs to run as root, just
>      TP> so they can do something as trivial as binding to a privileged
>      TP> port (the concept of privileged ports strikes me as one of the
>      TP> worst concepts ever introduced into Unix networking code),
>      TP> instead of hacking your kernel so that some other UID or GID
>      TP> can do it instead (say, anything running as UID "netpriv" or
>      TP> GID "network"), thus eliminating any real concerns of
>      TP> far-reaching security programs in a whole ugly host of
>      TP> user-level networking programs?
>
>    and indeed, many people do wind up doing this. though it could be
>  improved still further, given a more flexible system (and the time to
>  write it :). why does a network daemon (inetd, say) need privs to
>  write to disk (beyond logging)? restrict your mail daemon uid to allow
>  bind()s only to port 25 or > 1024. if someone compromises it, sure,
>  they'll be able to intercept incoming mail. but, they won't be able to
>  intercept incoming interactive sessions and capture passwords. and so
>  on. of course, setting up this level of restrictions is time
>  consuming, and fairly complex - but it would seem well worth it.
>
>    i've been toying with the notion of doing a completely abstract
>  implementation of this for a while now. something where you can build
>  a directed graph of access levels, then attach privileged operations
>  to them arbitrarily. for extra points, make it dependent on the
>  context and arguments of the operation. for still more credit, do it
>  without needing to add a pcode interpreter of some kind into the
>  kernel. a simple implementation wouldn't be particularly difficult - a
>  basic graph handling package with rapid functions to determine whether
>  a given node is 'above' another or not... then go through the kernel,
>  and gradually convert all the suser() (or whatever your local
>  equivalent is - i'm most familiar with linux) calls to queries to the
>  new engine. since nobody's done it yet, it's probably a lot more
>  difficult than it appears to me. or has it been done?
>
>    how do systems like trusted solaris, etc. and the MLS ones present
>  themselves? ie, how much flexibility do they give to someone trying to
>  provide only a minimal set of privileges?

------------------------------------------------------------
Paul McNabb                     mcnabb () argus cu-online com
Argus Systems Group, Inc.       TEL 217-384-6300
1405A East Florida Avenue       FAX 217-384-6404
Urbana, IL 61801 USA
------------------------------------------------------------