Re: Request for discussion.

[mcn () c3serve c3 lanl gov (Michael Neuman)]

> Changes
> -------
> - run network daemons with lower priveledges.
> discussion:  Why are so many net daemons run as root?

  Most of the things you mention are fixed by a system such as Trusted 
Solaris. It separates trust into about 50 or so privileges. There is no 
such thing as and all-powerful 'root' any more. I ran TS 1.1 for a while 
and eventually gave up because I found the privilege system too 
cumbersome to do any real work. (Granted, I was developing security tools 
which needed FULL access)

  If you get the opportunity, try Trusted Solaris. You'll see that while
all the features you mention make your system a lot more secure, the
time required to administer the system properly probably isn't worth it
for most people. For example, every privileged program requires
installation by the sysadmin user, then privilege granting by the
secadmin user. Sure this can be one person, but the manual says this is
a big no-no. And in any case, it can't easily be done from the command
line (the sysadmin must be at SYSTEM_LOW, and the secadmin must be at
SYSTEM_HIGH).  Anyway, it seems to work, but, like I said, I found it too
difficult to do any real work (even with the extensive manual set, and
following the directions carefully).

> - collect suid programs into common directory, or perhaps
>   a seperate directory for uid/gid. (both in src and bin form).
> rationale:  Increase awareness of security critical programs.
>   Make it easier to check all suid programs at once.

  I think AIX tries to do this with it's TCB stuff. Again, it makes the
system more secure, but makes it SERIOUSLY difficult to add (and test)
new daemons, or programs...
 
> - database of priveledged programs and dependencies.  Ie config
>   files, temp files, directories, databases, etc.
> rationale:  Keep track of assumptions in security critical programs.
>   Avoid holes that arise out of changing an assumption (example
>   making utmp world readable).  Make it easier for automated
>   checks (ie. world writeable directories like preserve and
>   msgs).

  Trusted Solaris does this. I *think* AIX's TCB does this as well.
 
> - system list of users allowed to use suid and sgid.  Suid
>   binaries not run if file owner not allowed to use suid/sgid.
> rationale:  reduce the ability to store priveledge on a filesystem.

  Access Control Lists are also part of Trusted Solaris--it allows finer
grain control (ie. user X is allowed to run suid prog X) at the cost of
more administration.
 
> - secure network services.  authentication and encryption.
>   point to point encryption in socket layer?  Change
>   services that rely solely on addresses for authentication to
>   rely on additional or other information.  Replace
>   the priveledged ports model.

  I implemented something like this a while back. Public key
distribution is the main problem. The second is it takes a while to
do the public key encryption to exchange a key. (On the order of a
second or two, longer if you include a real public key distribution
system). That second may not be a big deal except for services
like HTTP which make dozens of connections. (I actually implemented the
whole system: ANSI X9 public key distribution server, the encrypted
socket library, and a secure HTTP client & server--if you're interested:
http://www.c3.lanl.gov/~mcn/sunrise/sunrise_security.html)

> - finer grained priveledges.  ie. net -> raw sockets, priveledged
>   ports, etc.  rlogin,rsh,etc become suid net.
>     net - raw sockets, priveledged ports, packet filters, routing tables
>     console - console and keyboard device.  X servers.
>     fs - quotas.
>     uucp - modem
>     kmem - read kmem
> rationale:  Priveledged programs run with least priveledge required.

  Trusted Solaris does this. In fact, it's even finer than that--for
modems and floppys (and the sound port), you need to 'check them out'
from the operating system. The OS logs the whole thing, makes sure
locking is correct, then gives you the ability to access the device.
Then, the program you run that accesses that device must have the
correct privilege to access it.
 
> - capability based security model.   Passing of priveledges.
>   Ability to create new capabilities with a subset of
>   a capability as in VSTa.  Disabling of priveledges.
>   Multiple priveledges per process.  Security server for
>   giving away priveledges to certain programs (is this
>   possible to do in a secure way) to replace suid/sgid.
>   Security server for requesting priveledges.
> rationale:  Finer grained security model.  Run programs
>   with least priveledge required.  Reduce coupling
>   of filesytem security with system security.  Support
>   the transition from host security to distributed
>   network security.

  Again, Trusted Solaris... I think BSD4.4 is heading in the right
direction for a less complex system with good security. Immutable and
append only files, along with a LOT of kerberos support is the right
direction. Let's just hope the SysV camp doesn't blow off BSD's
accomplishments as "research trivialities" again.

-Mike