Unix security additions

John F Haugh II jfh at rpp386.cactus.org
Mon Mar 18 23:15:28 AEST 1991


In article <PCG.91Mar17174428 at aberdb.test.aber.ac.uk> pcg at test.aber.ac.uk (Piercarlo Antonio Grandi) writes:
>Unix is a terribly insecure system, if by security we mean something
>substantial, like the military think about it. If we mean security as in
>not letting hackers have free rein in an office environment, then with
>effort and care, once *can* achieve some effective very basic security,
>thanks to the thoughtful provision of minimal security primitives.
>
>Just to give examples of the very low level of *real* security problems
>of Unix, containment/write down is not addressed, trapdoor problems are
>not addressed, file protection granularity is too coarse, etc. It is
>possible to get around all these problems, with great effort, and
>implementing mechanisms and policies from scratch. Database vendors have
>more "securiryt" because they have done precisely that.

Security is what you define it to be for the system you are defining
it for.  UNIX was designed to be a nice little operating system for
people to get work done in.  It wasn't designed for spook work.  As
such, the lack of MAC is a feature, not a bug.  That means that it is
just fine for a cooperative little office environment.

MAC and trusted path and so on are real nice, if you need them.  If you
don't, you wind up with the problem you mentioned concerning SCO UNIX -
you have all these features you can't figure out what to do with.  I
can't imagine a system administrator that can't figure out how to
remove a file named "-r" from his home directory [ the answer is "you
have to run mkfs to remove the file" ] being able to set up object
auditing for a random assortment of files.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.



More information about the Comp.unix.internals mailing list