Xref: utzoo comp.unix.internals:2357 comp.unix.admin:1273 Path: utzoo!news-server.csri.toronto.edu!rutgers!bellcore!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.unix.internals,comp.unix.admin Subject: Re: Unix security additions Message-ID: Date: 17 Mar 91 17:44:28 GMT References: <39950@cup.portal.com> <1991Mar14.230944.9184@eci386.uucp> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 100 Nntp-Posting-Host: aberdb In-reply-to: woods@eci386.uucp's message of 14 Mar 91 23:09:44 GMT On 14 Mar 91 23:09:44 GMT, woods@eci386.uucp (Greg A. Woods) said: woods> In article <39950@cup.portal.com> PLS@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@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk