Unix security additions

Piercarlo Antonio Grandi pcg at test.aber.ac.uk
Mon Mar 18 03:44:28 AEST 1991


On 14 Mar 91 23:09:44 GMT, woods at eci386.uucp (Greg A. Woods) said:

woods> In article <39950 at cup.portal.com> PLS at cup.portal.com (Paul L
woods> Schauble) writes:

PLS> When unix was first developed, the system gave only minimal attention to
PLS> security issues. Lately, this has been a hot topic and a lot of work has
PLS> been done to improve Unix security.

I would disagree with both statements; Unix was not designed for a
secure environment or for security, but some security mechanisms were
built in anyhow, probably as a result of the author's exposure to
Multics.

woods> Excuse me, but IMHO, when UNIX was first developed, *more*
woods> attention was put into careful consideration of security issues
woods> than with almost any other system of its time (except maybe for
woods> MULTICS).

This is a fairly counterfactual statement. There were systems
(capability based systems for example) designed for much greater
security at the time than Unix could possibly have, and Multics and
these other systems are simply in entirely another league from Unix.

woods> A significant patent was even granted to one of the inventors for
woods> a very innovative systems security technique.

If you really believe what you have written (significant, very
innovative, systems security), I have this nice patent on moving cursors
on a screen using XOR that I can let you have for a song :-( :-( :-(.

PLS> I'm curious: What do you think are the five most significant changes or 
PLS> additions that have been made to Unix to improve its security?

The most significant thing would be a completely different filesystem,
and then a drastic simplification of the programmer's interface, and
then removal of uid 0 privileges, and then system object labeling and a
security manager to enforce security policies on labeled objects. Only
the latter two have been done, and they are the least important...

The filesystem semantics and the system call semantics have become more
complex and hazardous with time, resulting in kernel bloat and other
great opportunities for insecurity.

woods> The most significant "things" that have affected UNIX security in
woods> the past few years are the perpetuation of myths about how
woods> insecure some people perceive UNIX to be.

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.

woods> In addition, partially because of a large amount of ignorance,
woods> UNIX security has been mangled by well meaning vendors who were
woods> pushed by clients who believed the myths.

No, I would not cathegorize vendors as "weel meaning", because _some_ of
have have real security experts on their staff, and they know perfectly
well that what is being provided is the *illusion* of security, not
security.

See the infamous trapdoor left in most System V/386 products, even those
with purported C2 level security. Also see the ridiculous C2 security
provisions of SCO Unix, which are so cumersome to be a security hazard
in themselves, as they get in the way of ordinary system administration.
if security mechanisms cost a lot of effort and administrative
attention, they will be circumvented.

woods> The only other significant thing I can think of is "the network".
woods> Many network tools have introduced significant security problems
woods> to UNIX where none existed in isolated systems.  Eg. sendmail,
woods> finger, & nfs.

How true. All these networking thingies have been designewd to "work",
without any attention paid to security, recoverability, performance,
portability or other silly ideas. Slowly a process of fixup engineering
is being applied to each of them, in a painful and ultimately
unproductive effort.

woods> Of course the things most people might have been thinking of are
woods> the various implementations of "Orange Book" security features
woods> for UNIX.

The AT&T one using labels and the like is not that bad, even if it has
some defects. SCOMP from Honeywell was/is great. But, as SCOMP somehow
shows, the best approach is to build a secure system from scratch and
emulate Unix on top of it...
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at aber.ac.uk



More information about the Comp.unix.internals mailing list