Complex security mechanism is unsecure

[John F Haugh II]

In article <6922 at titcce.cc.titech.ac.jp> mohta at necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>Then, for example, think about a case where NFS mounted file system
>is exported with root access converted to nobody (but, uucp to uucp,
>daemon to daemon). Then, list what system administrators should take care.

How about starting with exporting the file system read-only and only
to systems which are properly administered.

Secure systems cannot exist in an open environment with insecure
ones unless you prevent the insecure ones from accessing your
system.  If you are exporting your filesystems to the entire world
read-write, and your neighbors don't care about security you will
NEVER have a secure system.

>>Really, I think that the addition of more
>>than one ring of security by using other uids than only root is very
>>valuable and costs next to nothing in extra complexity.
>
>And you can have seven levels of security like Multics without
>extra complexity.

Perhaps if Multics had insecure network filesystems such as NFS
it would still have required added complexity, no?

>My point is that root become more vulnerable if it trust uucp, daemon
>and others.

This is neither new information nor interesting.  There is no
special relationship between "uucp" and "root" above and beyond
the relationship between an ordinary user and "root".  If the
security of your system is dependent on the security of any
non-root user account (such as "uucp", "bin", "sys", etc.), any
compromise in the security of that account, either by NFS mounts
or carelessly giving out "bin" or "uucp" passwords is going to
directly impact the security of the system.  "root" should not
carelessly trust a poorly administered "uucp" system any more
than it should trust Joe Luser.  We know this already.

>Moreover, if I remember correctly, in 4.2BSD, /etc/syslog was owned
>by daemon, which will be executed by root at boot time from /etc/rc.local.
>At least, on SunOS 3.5, /usr/etc/in.syslogd is owned by daemon and
>executed by root.

By the standards of security which you wish to claim are required,
EVERY executable on the system must be owned by root, and all the
files used by all those executables must also be owned by root.
And so on.  All that is actually required is some statement that
the executable in the directories which root can execute from are
"trustable", and so on for the configuration files.  Start with
not granting access to the accounts owning the files, directly or
otherwise.

Yes, and NFS is a botch.  What else is new?
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh at rpp386.cactus.org
"While you are here, your wives and girlfriends are dating handsome American
 movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."