mirk@warwick.UUCP (Mike Taylor) (06/03/89)
In article <3, I think> jfh@rpp386.cactus.org (John F. Haugh II) writes: > I think [a previous poster] meant getting rid of UID == 0 being a > privileged user. Again, this an Orange Book requirement. It also > makes much sense. Programs should have privilege, not users. The > ability to access a program can then be limited to a collection of > users or groups. Uuuh, are you sure? There seems to be a prevailing feeling that the whole of UNIX is something that was cobbled together ar random by people writing bits without thinking about whether or not they were secure, made sense or whatever. While this is largely true of Berkeley UNIX, or at least, of those bits that have been added since V7, the concept of a root id belongs to fundamental core UNIX, it is one of the concepts that Thompson, Richie and friends though long and hard about when they were designing UNIX. Granted, at that time, it was never intended primarily to be a *secure* system, but it was *very* carefully designed, nothing was in that hadn't been thought through, and root is no exception. Like GOTO, I maintain that the problem with root is not that it is a flawed copncept, but that is is misused, overused, and general ABused by people who should know better. The UNIX way of handling privilege IS fundamentally secure, and it's pretty elegant to boot. You have exactly one privileged user, and one way of inheriting that privilege -- the setuid mechanism. The fact that many UNIX installations are insecure is due to the mess that people have buult on top of that idea, not on the idea itself. Most UNIXes have many things setuid to root which really dont need to be. For example ... > Or use /etc/group to allow some group of users to newgrp to an > administrative account. The group ``dumpers'' might exist for persons > taking file system dumps. All of the dumpable devices would then have > file group ``dumpers''. Root wouldn't have to be used for dumps any > longer. You can already do this -- the mechanisms are in place and have been since way way back. All that needs to be done is make the program group-executable, and maybe setuid to whatever account it needs to be able to access the dump device. There's almost always already a way to do it, I have found. Whatever "it" is. I believe in having as many accounts as necessary to run all the standard daemons, servers &c., under their own account, so as to decentralise privilege. Many services are setuid root in order to do some simple thing, whereas all they really need is to be setuid to a special account that owns whatever files need privileged access. Then people penetrating security in, say, fingerd (not topical any more,. but never mind) would then have obtained access to the account "finger", but not to root. Big deal. And remember -- all this can be done, without bending over backwards, with UNIX machinery that already exists. "Those who do not understand UNIX are condemned to re-invent it, poorly" -- Henry Spencer. ______________________________________________________________________________ Mike Taylor - {Christ,M{athemat,us}ic}ian ... Email to: mirk@uk.ac.warwick.cs Unkle Mirk sez: "You fritter and waste the hours in an offhand waistcoat."
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/06/89)
In article <1961@ubu.warwick.UUCP> mirk@uk.ac.warwick.cs (Mike Taylor) writes: >Uuuh, are you sure? There seems to be a prevailing feeling that the >whole of UNIX is something that was cobbled together ar random by >people writing bits without thinking about whether or not they were >secure, made sense or whatever. I would suspect that stopped being the official feeling of AT&T when UNIX became a commercial product. Commercial operating systems need to have security features so that buyers will pay real money for them ... > While this is largely true of >Berkeley UNIX, or at least, of those bits that have been added since >V7, the concept of a root id belongs to fundamental core UNIX, it is >one of the concepts that Thompson, Richie and friends though long and >hard about when they were designing UNIX. Monolithic privilege is simple, elegant and neither secure nor trustable. Any single flaw in the privilege scheme may be exploited to obtain complete privilege. Given the choice between monolithic root privilege, or VMS-like privileges, I'd much rather have the VMS approach. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/06/89)
In article <16638@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >Monolithic privilege is simple, elegant and neither secure nor >trustable. Any single flaw in the privilege scheme may be exploited >to obtain complete privilege. To the contrary, the kernel implementation of UID 0 being the ONLY privileged UID along with the set-UID implementation is small and simple enough to be completely validated. That provides sufficient kernel support for layered implementation of more elaborate security schemes. You need to distinguish between the typical hodge-podge of user-mode privileged programs found on commercial UNIX systems and the inherent security hooks. The latter make possible implementation of a provably secure, trustworthy multi-level security scheme. More elaborate kernel hooks make it harder to be sure there are no loopholes. It doesn't matter what a "flaw" would mean if you can PROVE there are no flaws.
dinah@shell.UUCP (Dinah Anderson) (06/06/89)
In article <3, I think> jfh@rpp386.cactus.org (John F. Haugh II) writes: > I think [a previous poster] meant getting rid of UID == 0 being a > privileged user. Again, this an Orange Book requirement. It also > makes much sense. Programs should have privilege, not users. The > ability to access a program can then be limited to a collection of > users or groups. But what you are really saying is that a certain group of users would have the privilege to access a program which provides a certain privilege or access. I agree with the basics of what you are saying, but the real issue is the users running the programs, not the programs themselves. We need to know who is running what programs (for accountability in extreme sensitive cases.) Dinah Anderson Shell Oil Company, Information Center (713) 795-3287 ..!{sun,psuvax,bcm,rice}!shell!dinah
rang@cpsin3.cps.msu.edu (Anton Rang) (06/07/89)
In article <10370@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <16638@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>Monolithic privilege is simple, elegant and neither secure nor >>trustable. Any single flaw in the privilege scheme may be exploited >>to obtain complete privilege. > >To the contrary, the kernel implementation of UID 0 being the ONLY >privileged UID along with the set-UID implementation is small and >simple enough to be completely validated. [ stuff about layers ] > More >elaborate kernel hooks make it harder to be sure there are no loopholes. Why? If you have a layered security system, every part of it must be validated. It's no easier than putting it in the kernel. What's more, if you have a single privilege, you have to ensure that EVERY operation you do is provably secure. I doubt this is doable with existing validation mechanisms. >It doesn't matter what a "flaw" would mean if you can PROVE there are >no flaws. This can be done (well, approximated) much more easily if you have a large number of distinct privileges. If a section of code is running with, say, "GROUP" privilege (under VMS, this gives access to other processes in the group, and allows access to group data structures), you don't need to worry that a call to open a file will read a protected file. With monolithic privilege, any privileged code could do this. I've done some (little) work on security validation. It's not easy. Monolithic privilege schemes don't help at all. +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
shore@mtxinu.COM (Melinda Shore) (06/07/89)
[] It's been my experience that sloppy administration is more likely to be at fault when a breakin occurs than is the inherent security/lack- of-security of a particular OS. Management of layered privileges in medium-sized to large organizations gets out of hand amazingly quickly, and it's not at all unusual for people who aren't systems administrators but have some privileges to hand out their passwords. The theory of layered privileges is nice, but the reality is Not Good. -- Melinda Shore shore@mtxinu.com Mt Xinu ..!uunet!mtxinu.com!shore
arosen@hawk.ulowell.edu (MFHorn) (06/08/89)
From article <1177@shell.shell.com>, by dinah@shell.UUCP (Dinah Anderson): > In article <3, I think> jfh@rpp386.cactus.org (John F. Haugh II) writes: >> I think [a previous poster] meant getting rid of UID == 0 being a >> privileged user. That may have been me, or I'm one of those that agree. > the real issue > is the users running the programs, not the programs themselves. We need > to know who is running what programs (for accountability in extreme > sensitive cases.) Exactly. One of the most important parts of my privileges design is the ability to log the use of any/all privileges. The message would include the privilege used, who used it, and the object(s) acted upon (file, process, etc.). [And unlike VMS, you won't be able to turn accounting off without tripping an alarm.] By having multiple privileges, you can more easily monitor who is doing what. It's also [almost] trivial to detect a breakin; you know who did something, what they did, and when and how they did it. Another thing that makes my privilege scheme better than VMS' (IMHO) is it's simple, and documented. I have not met a VMS guru who can say exactly what a user can do with a particular privilege, or (especially) a combination of privileges. Also, no one can say what privileges are needed to perform a particular task. -- Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/08/89)
In article <10370@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <16638@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>Monolithic privilege is simple, elegant and neither secure nor >>trustable. Any single flaw in the privilege scheme may be exploited >>to obtain complete privilege. > >To the contrary, the kernel implementation of UID 0 being the ONLY >privileged UID along with the set-UID implementation is small and >simple enough to be completely validated. Agreed. You may trivially verify that the suser() function performs the desired result. This is not news. Now go verify that the utilities which execute with root privilege perform their intended function. The problem rapidly expands because every program may potentially be run by root. Turning off all of the SUID programs may not do any good, if a bad guy [ as did happen with a vendors secure product ] persuades root to execute an unprivileged command. You can't trust monolithic privilege. Period. > That provides sufficient >kernel support for layered implementation of more elaborate security >schemes. I really have to disagree, and I think the folks at NCSC agree with me. Secure and trustable kernels must be designed to be secure and trustable - a trustable system is not going to be created by tacking on another layer of cruft which must be verified for correctness. > You need to distinguish between the typical hodge-podge of >user-mode privileged programs found on commercial UNIX systems and >the inherent security hooks. The latter make possible implementation >of a provably secure, trustworthy multi-level security scheme. More >elaborate kernel hooks make it harder to be sure there are no loopholes. I'm not certain I understand the argument, but I will argue that simpler is not always better. Consider - the existence of the mkdir() call complicates the kernel, yet it removes the need for a root privileged program. Recall Doug Davis' mkdir hole? Along the same vein, why should an installation program require root privilege so it can create a few device files? Wouldn't it be more trustable if there were a privilege associated with creating device files which granted no other special abilities? >It doesn't matter what a "flaw" would mean if you can PROVE there are >no flaws. Part of the requirement for A1 is demonstrating that IF there are flaws that the damage will be limited. Monolithic privilege prevents this assurance. Oh - I've yet to read a text on programming which ever stated that it was possible to create a program of the size of an operating system which has no bugs. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
hill@faline.bellcore.com (Chris Hill) (06/08/89)
John Haugh II writes: >Oh - I've yet to read a text on programming which ever stated that it >was possible to create a program of the size of an operating system >which has no bugs. >-- This is the crux of the matter: the problem is not just one of security, but of writing code without errors which jeopardize security. It is currently not possible to verify the amount of code required for programs as large as operating systems. Since it is impossible to write error free code, it is impossible to create a completely secure system. Of course, it gets worse than that: not only must the OS be proveably correct, the hardware must be also - it must react in and ONLY in a predictable manner to all possible stimuli. Discuss ways to maximize security, but (for the time being) forget finding/eliminating ALL the loop holes. Chris Hill chris@nyquist.bellcore.com
maujf@warwick.ac.uk (Mike Taylor) (06/08/89)
[I suggested that the UNIX privilege mechanism is elegant and secure] In article <3327@cps3xx.UUCP> rang@cpsin3.cps.msu.edu (Anton Rang) writes: > [Proof of OS security] can be done (well, approximated) much more > easily if you have a large number of distinct privileges. If a > section of code is running with, say, "GROUP" privilege ... I will never understand why people find it so difficult to accept that UNIX allows this. All the mechanisms are in place, the only thing that is required is for sysadmins to take the time to configure their systems in a way that takes adcantage of it. That's what UNIX groups, and group permissions on files, are all about! Using the setuid mechanism, it's quite simple to limit the extent of any user's or any group's privileges. > You don't need to worry that a call to open a file will read a > protected file. With monolithic privilege, any privileged code > could do this. No, only if the system is carelessly set up. Suppose we want to allow a group of four or five people access to root privileges, but only for one particular job. Then we write a program to do this job, and chmod it 4750, (-rwSr-x---), so that anyone in the right group can run it as root, but no-one else can access it. Then you put the users in the relevant group, and there you are. What's so difficult about it? If you barf at the idea of allowing the root privileges at all, even when only a single operation is possible, then you can always make the resource that the file uses, (maybe an accouting file?) group- writeable. Of course, this is preferable when possible, but sometimes can't be done, (maybe the resource already needs to belong to another group, like /dev/kmem being group kmem) But to re-iterate my point again: UNIX supplies a complete, elegant and secure privilege mechnaism, and the fact that it has so many holes in it *now* is only due to the insecure things people have done with it. ______________________________________________________________________________ Mike Taylor - {Christ,M{athemat,us}ic}ian ... Email to: mirk@uk.ac.warwick.cs
jmm@eci386.uucp (John Macdonald) (06/09/89)
In article <16650@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >In article <10370@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>In article <16638@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>>Monolithic privilege is simple, elegant and neither secure nor >>>trustable. Any single flaw in the privilege scheme may be exploited >>>to obtain complete privilege. >> >>To the contrary, the kernel implementation of UID 0 being the ONLY >>privileged UID along with the set-UID implementation is small and >>simple enough to be completely validated. > >Agreed. You may trivially verify that the suser() function performs >the desired result. This is not news. > >Now go verify that the utilities which execute with root privilege >perform their intended function. The problem rapidly expands because >every program may potentially be run by root. Turning off all of >the SUID programs may not do any good, if a bad guy [ as did happen >with a vendors secure product ] persuades root to execute an >unprivileged command. > > [ and more ] Not all SUID programs are SUID to root! The people who are arguing that the *kernel* requires many different permission variants seem to have missed this point. Unix (from v1 on through all less historical variants) provides the SUID mechanism which permits implementation of permission variants without any kernel knowledge of the meaning or interrelation of the variants. Thus you can have uucp-permission, or lpr-permission, or bin-permission. If you want a system that is proveably secure, you: 1. get rid of all root logins from the normal /etc/passwd 2. get rid of all suid-root programs that have not been fully verified 3. create suid-<category> programs to manage privelged activities for each different <category> you need. You may need to write (and prove correct) a suid-root permission management program for complicated cases. For the system maintenance functions that require root privileges, you either prove correct the maintenance programs that are needed, or you reboot the system, staying in single-user mode, using a different /etc/passwd file from what is normally used is multi-user mode. Put an armed guard at the console full-time to prevent unauthorized use of this hole in security. This setup allows the kernel to be proved since there is not a huge amount of requirement - it must not give out root permission gratitously, it must implement suid correctly. It allows any site to configure its own security requirements without having to make any change to the kernel. It allows the typical system be sold as reasonably secure without the high expense of proof which satisfies needs of most systems[1]. It puts the cost of proving or validating any additional security needs on those people who require and implement those needs. This does not preclude providing some programs which do some of these tasks either with the system, or in any other fashion (comp.unix.sources); but people who *require* security will have to validate such programs anyhow. [1] Flames about the "reasonably secure" phrase above are not really required - I am aware of the fact that most Unixes, as delivered, and as later manipulated, are not perfectly secure; but they are good enough for most non-military purposes - most sites would not be willing to pay an extra $10K [for example] to get a secure version of their system that was otherwise identical.
maujf@warwick.ac.uk (Mike Taylor) (06/09/89)
In article <16650@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes: > In article <10370@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >> The kernel implementation of UID 0 being the ONLY privileged UID along >> with the set-UID implementation is small and simple enough to be >> completely validated. > Agreed. You may trivially verify that the suser() function performs > the desired result. This is not news. Now go verify that the > utilities which execute with root privilege perform their intended > function. You keep saying this. The point is, _it's_not_the_kernel's_fault!_ Just because a lot of people have written insecure utilities and persuaded other people to make them setuid root, doesn't make the fundamental system insecure -- it just makes the people stupid, and that really _isn't_ news! :-) If UNIX had been written with "layered privileges" in the kernel, (instead of the system we have whereby you can build them using groups and the suid mechanism), then its security would still be the mess it is today, just because that is what people are like. ______________________________________________________________________________ Mike Taylor - {Christ,M{athemat,us}ic}ian ... Email to: mirk@uk.ac.warwick.cs
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/10/89)
In article <1989Jun8.210946.26746@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes: >1. get rid of all root logins from the normal /etc/passwd Now that's a good start :-) >2. get rid of all suid-root programs that have not been fully verified Yes, you must do this as well. /bin/mkdir will always be a member of my bag of tricks. >3. create suid-<category> programs to manage privelged activities for > each different <category> you need. You may need to write (and prove > correct) a suid-root permission management program for complicated > cases. This is not adequate. There are many operations under UNIX which only root can perform. The idea behind making 0 a non-special UID is that than you must have some other object with a finer granularity in order to perform the operation. Certainly you could have every utility check it's invoker to verify permission - but what do you do when a bug such as /bin/mkdir crops up and demonstrates how little security stock UNIX has designed into it? >This setup allows the kernel to be proved since there is not a huge amount >of requirement - it must not give out root permission gratitously, it must >implement suid correctly. It allows any site to configure its own security >requirements without having to make any change to the kernel. It allows the >typical system be sold as reasonably secure without the high expense of proof >which satisfies needs of most systems[1]. Proving a kernel secure is not sufficient. You must also prove that all of the programs executing with privilege are secure. By creating more programs to manage privilege you are creating a larger task. Assurance goes straight out the window since any one flaw in the program affects all of the privileges the program posseses, and that is every privilege. >It puts the cost of proving or validating any additional security needs on >those people who require and implement those needs. This does not preclude >providing some programs which do some of these tasks either with the system, >or in any other fashion (comp.unix.sources); but people who *require* >security will have to validate such programs anyhow. ... Which is the consumer. Provably secure systems will not be running the latest version of nethack or smail. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/10/89)
In article <127@orchid.warwick.ac.uk> mirk@uk.ac.warwick.cs (Mike Taylor) writes: >But to re-iterate my point again: UNIX supplies a complete, elegant >and secure privilege mechnaism, and the fact that it has so many holes >in it *now* is only due to the insecure things people have done with >it. Your plan requires at a minimum concurrent group sets, and then STILL requires being SUID root if it performs any of the tasks which only root may perform. Consider for a moment a `mount' program which only group `oper' may execute. Group 'oper' is not special - you must still be UID 0 in order to mount a filesystem [ System V least wise ]. So you must make the modes 4010 with user 'root' and group 'oper'. And you must prove that EVERY operation performed by `mount' conforms to the security system you've implemented. The alternative is to grant the mount program `MOUNT' privilege _and_ use permission bits. Make the program mode 010, group oper, and have code similiar to add_privilege (MOUNT); mount (device, directory); drop_privilege (MOUNT); buried in there. Now you must only show that the privilege MOUNT can not be abused by other calls - and it can't because the privilege only exists during the mount() system call. You may make you job much easier by coding main (...) { drop_privilege (ALL); as the very first step. Your proof now consists of the statement `There is no privilege to abuse, except here ...' This is why least privilege and privilege bracketing is such a hot idea. What are you going to trust, a program running with root privilege 100 percent of the time, or a program running demonstrably with no privilege 99 percent of the time and only a single privilege the remaining 1 percent? -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
peter@ficc.uu.net (Peter da Silva) (06/10/89)
In article <16658@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > Proving a kernel secure is not sufficient. You must also prove that all > of the programs executing with privilege are secure. By creating more > programs to manage privilege you are creating a larger task. This is questionable. I would much rather prove that the superuser is safe and then verify <N> seperate programs than prove that <N> sets of routines in the kernel are all secure. For one thing you can do it incrementally. And you're still going to have a bunch of programs that will have to be verified. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
trt@rti.UUCP (Thomas Truscott) (06/11/89)
There are number of ways to strengthen UNIX security such as by auditing for unusual process activities, adding the DOD-oriented MLS policies, and ACLs (I suppose), I do not see how handing out a "piece of the root" enhances security. It might possibly reduce the damage caused by a typical errant process but a *malicious* process (user) will just take the privilege(s) and turn them into full-blown superuser privilege. Nothing is gained except complexity and a false illusion of security. For example: > Consider for a moment a `mount' program which only group `oper' > may execute. ... > And you must prove that EVERY operation performed by `mount' > conforms to the security system you've implemented. It was claimed that giving the `mount' program only the MOUNT privilege improves security, since only the mount(2) system call need be checked for security. (In ordinary UNIX `mount' would have to be set-user-id root, and everything it does would have to be checked for security.) 1) What kind of security are we trying to achieve? Either variant of `mount' permits group `oper' to mount a new /etc, complete with an oper-friendly /etc/passwd. 2) Everything in `mount' needs to be checked anyway lest it be fooled into abusing its MOUNT privilege (e.g. does `mount' call gets() :-)). And, although irrelevant, I cannot resist throwing in: 3) In BSD 4.3 and SYS 5.3 the same effect can be achieved by having `mount' do a set[re]uid(2) to a nobody uid and be superuser only during the mount(2) system call, and perhaps also when updating /etc/mtab (if you have one of those). (Does MOUNT privilege give write permission on /etc/mtab?) Tom Truscott
peter@ficc.uu.net (Peter da Silva) (06/12/89)
In article <16659@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > Consider for a moment a `mount' program... > The alternative is to grant the mount program `MOUNT' privilege > _and_ use permission bits.... A perfect example of why this is a red herring. So, you're saying that if you break that 'mount' program all you've broken is protecting the 'MOUNT' privilege, and root is still secure. But as soon as you get MOUNT privilege you can mount a file system containing a program with any other privilege you want... and you have the keys to the kingdom again. ROOT lives... it's just called 'MOUNT'. So why be complex when you can be simple? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
maujf@warwick.ac.uk (Mike Taylor) (06/12/89)
In article <16659@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes: > Consider for a moment a `mount' program which only group `oper' may > execute. You must make the mode 4010 with user 'root' and group > 'oper'. And you must prove that EVERY operation performed by `mount' > conforms to the security system you've implemented. Not at all -- It is quite possible to have a setuid root binary that immediately throws away its privilege when run, reverting to the effective uid of its invoker, and which restores its root-ness only for the "critical region" in which it is doing those dark and secret things that only root can do. Then the critical section alone need be verified, and security holes in the rest of the program do not cause the security of the root account to be compromised. ______________________________________________________________________________ Mike Taylor - {Christ,M{athemat,us}ic}ian ... Email to: mirk@uk.ac.warwick.cs "Quick! Back into the fish!" - Eric Idle (Burthold in "Baron Munchhausen")
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/14/89)
In article <4499@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <16659@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >> Consider for a moment a `mount' program... > >> The alternative is to grant the mount program `MOUNT' privilege >> _and_ use permission bits.... > >A perfect example of why this is a red herring. No, this is a perfect example of a trustable system. Least privilege is a _requirement_ for trusted computing systems. It isn't something you get to wave off as being a `red herring'. Minds far better than yours or mine have MANDATED that this is going to be the way it is going to be. 'The TCB modules shall be designed such that the principle of least privilege is enforced.' -- TCSEC 3.2.3.1.1 >So, you're saying that if you break that 'mount' program all you've broken >is protecting the 'MOUNT' privilege, and root is still secure. Yes. Now that you can mount something, what are you going to mount? 'The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices.' -- TCSEC 3.2.1.3.4 Now that you have this floppy containing your password-free su, who are you going to convince to mount it on the only trusted floppy drive in the system? Your assumption is that you will be able to obtain, through some machinations an arbitrary privilege. A system with this as a flaw is open to more direct attacks than having bogus file systems mounted. >But as soon as you get MOUNT privilege you can mount a file system containing >a program with any other privilege you want... and you have the keys to the >kingdom again. ROOT lives... it's just called 'MOUNT'. You assume a trusted system is going to trust any data being imported? >So why be complex when you can be simple? Because simple does not work in this case. It is not sufficient to state that a system performs its claimed purpose, you must demonstrate that the system is designed in such a fashion that it degrades gracefully. Obtaining some individual privilege should not grant every privilege. The current UNIX idiom requires one to only know a single critical flaw. A layered privilege approach requires you to know a flaw which will grant you the entire set of privileges required to perform a task. Even then the system may not trust YOU to execute the process which you have constructed. [ Please reference VAX/VMS which includes the concept of an operator console, something which UNIX does not presently support ] Please, before anyone else wants to waste time responding about their ideas regarding security, read a bit about what people who have already defined security have to say. The objections Peter has raised display a severe lack of understanding about the current state of the art in trusted systems designs. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
vandys@hpcupt1.HP.COM (Andrew Valencia(Seattle)) (06/14/89)
/ hpcupt1:comp.unix.wizards / jfh@rpp386.Dallas.TX.US (John F. Haugh II) / 7:26 pm Jun 13, 1989 / >... Least privilege >is a _requirement_ for trusted computing systems. It isn't something >you get to wave off as being a `red herring'. Minds far better than ^^^^^^^^^^^^^^^^^^^^^ >yours or mine have MANDATED that this is going to be the way it is ^^^^^^^^^^^^^ >going to be. It's good to see that optimism still flourishes on the Usenet! Sorry. I'll go back to the woodwork now. Andy ...!hplabs!hpisoa1!vandys
peter@ficc.uu.net (Peter da Silva) (06/15/89)
In article <16662@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes a whole bunch of stuff about trusted computing bases (which he abbreviates throughout as TCB without explaining this abbreviation)... > Your assumption is that you will be able to obtain, through some > machinations an arbitrary privilege. A system with this as a flaw is > open to more direct attacks than having bogus file systems mounted. Actually that's a pretty direct attack. But, yes, I'm assuming that you will be able to obtain, though some machinatins, any arbitrary privilege. I have read somewhat about the subject, and I find it hard to credit that a useful system could be built that will satisfy all the requirements of a TCB. Security and convenience are diametrically opposed goals. In any real system that's open enough to get any actual work done, there will be holes. No matter how many people work though the code in an attempt to verify it... an operating system is far more complicated than any mathematical proof, for example, and look at the work necessary to validate one of those. So all you get for your effort is a warm fuzzy feeling that your system is secure. If you really want security, lock the terminal and computer up in a faraday cage, and don't let anything in or out except well filtered line current. Dropping back a few notches to UNIX, now, let's consider a real system. One that's sitting in a computer room with maybe a locked door keeping people from sliding in a boot tape and hitting restart. Minimal physical security. That's about the closest thing to a secure system 99% of the people need. Now, what advantage would ripping root into a dozen seperate capabilities (yet with complex interactions that have to be checked) give a system like that? > You assume a trusted system is going to trust any data being imported? I assume a real system outside the DoD is going to allow people to do real work. And, frankly, I don't care what a system inside the DoD allows. > The objections Peter has raised display > a severe lack of understanding about the current state of the art in > trusted systems designs. We're not talking about DoD-certified paranoid systems in Falls Church, we're talking about the typical UNIX system: a departmental or single-user computer doing software development, accounting, engineering, etc... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
allbery@ncoast.ORG (Brandon S. Allbery) (06/15/89)
As quoted from <132@orchid.warwick.ac.uk> by maujf@warwick.ac.uk (Mike Taylor): +--------------- | In article <16650@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes: | > In article <10370@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: | >> The kernel implementation of UID 0 being the ONLY privileged UID along | >> with the set-UID implementation is small and simple enough to be | >> completely validated. | > Agreed. You may trivially verify that the suser() function performs | > the desired result. This is not news. Now go verify that the | > utilities which execute with root privilege perform their intended | > function. | | You keep saying this. The point is, _it's_not_the_kernel's_fault!_ | Just because a lot of people have written insecure utilities and | persuaded other people to make them setuid root, doesn't make the | fundamental system insecure -- it just makes the people stupid, and | that really _isn't_ news! :-) +--------------- Agreed -- you can misuse any privilege system to make a system insecure. The best possible collection of privileges is worthless if you give every yser and program all privileges.... Someone was moaning about how /etc/mount ought relinquish all privileges except when it absolutely need them, to "simplify verification". Fine -- except that it needs multiple abusable privileges (i.e. file read/write) most of the time. And you must verify that it does in fact release its privileges when it's not using them, i.e. that it doesn't call a library routine which grabs file write privileges and doesn't release them. The proper solution can be done with (BSD-style) Unix as it is. I specify BSD-style because you need multiple groups to be useful, although it is certainly possible to "newgrp" around to get privileges, and requiring this might make the certifiers happier. /etc/mount: setuid root(0), mounts the named filesystem, executable only by owner (root) and group mount or wheel or etc. It *might* update a file readable/writeable only by the group; in that case, it can let go of its setuid after it has performed the mount. /etc/umount: Same as above, except unmounts. /etc/mounts: Might be setgid mount if you want anyone to be able to execute it. All it does is format and print the file updated by /etc/mount and /etc/umount; for this, it does not need root privileges, just group privileges. For higher security, don't make it setgid and limit its execution to group mount. If you omit the file update, you have limited each program to a single specific and easily verifiable function. You can then implement the file update in a second program which has permissions only to perform that function; this gets you easily-verified programs via Unix's setuid/setgid and Unix's ability to easily perform complex operations with small programs instead of monoliths, born of (relatively) cheap process creation. Secure Unix *is* possible; it just requires a re-think of most of the utilities. Since they all have to be re-thought anyway to meet *any* security classification, may as well go whole-hog and do it right. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
al@escom.com (Al Donaldson) (06/16/89)
In article <16662@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > Least privilege is a _requirement_ for trusted computing systems. > [then some quotes from the TCSEC]. Well, I don't classify myself as a Unix "wizard" (a root password does not a wizard make), but I do know a bit about the Orangebook, and there are some oversights here that need to be corrected. I held off a day since originally reading this article, waiting for others to make this point, but since they haven't, here goes. First, the Orangebook (TCSEC or DoD 5200.28-STD) categorizes systems into a hierarchy of divisions (D, C, B, A) and classes (e.g., C1, C2) that can be used to identify levels of functionality and assurance in a vendor's product. Whether a product meets these requirements is determined through an evaluation by the National Computer Security Center (NCSC). Part of this process is a decision by the computer vendor (generally based on market or contract requirements) as to which level (C2, B1, B3, A1??) the vendor wants to shoot for. Since John's quotations were from Section 3.2 of the Orangebook, I assume he has market or contractual requirements for building a B2 system. Within this framework, John is pretty much on target. However, B2 goes quite a bit beyond what the bulk of the unwashed masses (myself included) use on a day to day basis. As I remember, a recent Air Force acquisition for a large number of trusted Unix systems only anticipated that about ten percent of the systems would be B1, the rest would be C2. Its important to understand here that B-level systems are evaluated to label data with security labels (e.g., Unclassified, etc) and enforce security policy on accesses to that data, something that most of us in the commercial sector don't want to bother with. In my estimation, what is far more important is bringing up the bulk of Unix systems to the C2 level of assurance, by (1) providing an auditing capability that can be turned on or off, (2) providing a usable means (other than having a zillion groups) of allowing the user to control access to his or her files, and (3) having some way to identify WHO is logged on with the super-user privilege. This is specially needed on larger systems where more than one person may have the root password. Breaking up superuser privilege into various sub-privileges might be nice for some sites, maybe, but it certainly is NOT required for C1-B1 level systems and it would be a royal pain on a smaller system such as mine. Al Donaldson al@escom.com (703) 620-4823 Man - "What's he got that I haven't got?" Woman - "Awareness." Man - "What's that?"
mouse@mcgill-vision.UUCP (der Mouse) (06/22/89)
In article <4499@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <16659@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >> The alternative is to grant the mount program `MOUNT' privilege >> _and_ use permission bits.... > So, you're saying that if you break that 'mount' program all you've > broken is protecting the 'MOUNT' privilege, and root is still secure. > But as soon as you get MOUNT privilege you can mount a file system > containing a program with any other privilege you want... and you > have the keys to the kingdom again. ROOT lives... it's just called > 'MOUNT'. Ever hear of "nosuid"? If you're going to shatter the current single privilege bit [yes, I know it's not stored that way] into many, there will be two mount privileges, of which one grants permission to mount a filesystem and the other grants permission to mount a filesystem in such a way that the kernel (or filesystem handler, or whatever) believes the privilege bits on it. The second one *is* the keys to the kingdom, as you point out - but /etc/mount doesn't have it: all /etc/mount grants to a nonprivileged user is the first one. In order to do the second type of mount, you have to have acquired the corresponding privilege bit from somewhere else. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jfc@athena.mit.edu (John F Carr) (06/22/89)
In article <1566@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: [on allowing non-root to run mount] >Ever hear of "nosuid"? Before allowing mount access to someone, make sure that all your system directories are opened by some process (so you can't mount over them). Otherwise you may find somebody else's /etc mounted over your own (for example), at which point nosuid is no longer effective (there are a number of less obvious directories, depending on your system). --John Carr (jfc@athena.mit.edu)
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/23/89)
In article <12148@bloom-beacon.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes: >In article <1566@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >Before allowing mount access to someone, make sure that all your system >directories are opened by some process (so you can't mount over them). >Otherwise you may find somebody else's /etc mounted over your own (for >example), at which point nosuid is no longer effective (there are a number >of less obvious directories, depending on your system). I was laying in bed thinking exactly this just last night ... I had long wondered why login should be in /etc rather than /bin and overmounting system directories makes the perfect case. I might remember to protect /etc from being overmounted; will I remember to protect /bin and others where system programs reside? This problem of trusted programs executing non-trusted programs by accident causes UNIX to be inherently untrustable. No trusted program should ever execute any untrusted program. UNIX completely lacks this concept. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/25/89)
In article <16734@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >No trusted program should ever execute any untrusted program. >UNIX completely lacks this concept. Yeah, and it lacks a lot of other bogus concepts too. That's why some of us love UNIX so.
nagle@well.UUCP (John Nagle) (07/12/89)
In article <4554@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Security and convenience are diametrically opposed goals. > >In any real system that's open enough to get any actual work done, there >will be holes. No matter how many people work though the code in an attempt >to verify it... an operating system is far more complicated than any >mathematical proof, for example, and look at the work necessary to validate >one of those. Sadly, this remains true. As one of the few people ever to build a working verification system, (see my paper in POPL '83), I have to agree with this. Only machine verifications are worth anything; hand proofs of even tiny programs tend to contain errors, usually in the direction that makes bad proofs succeed. Still, in 1983, we were up to programs of a few hundred lines, proven to obey all their assertions and invariants and not to violate any subrange, array bound, or machine overflow constraint. Don Good's work at the University of Texas continues, and they are steadily advancing what can be proven correct. Unfortunately, a secure operating system doesn't look anything like UNIX internally. You want a much smaller system. The vocabulary of things that a user application can ask of the operating system is much too large. Every system call has potential holes, and the semantics of many system calls, especially those which alter the execution environment, are very hard to model formally. "Mount", as pointed out above, is especially messy. A good argument can be made that trust and user programmability should never meet in the same CPU. The notion of a secure file server is in many ways more promising than the notion of a secure operating system. >So all you get for your effort is a warm fuzzy feeling that your system >is secure. If you really want security, lock the terminal and computer up >in a faraday cage, and don't let anything in or out except well filtered >line current. That's how high-level systems are still secured today. Solid steel, line power filters, airlocks with RF-tight gaskets, and several levels of physical security to keep anybody from getting close. John Nagle
nagle@well.UUCP (John Nagle) (07/12/89)
In article <16734@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes: >This problem of trusted programs executing non-trusted programs by >accident causes UNIX to be inherently untrustable. No trusted program >should ever execute any untrusted program. UNIX completely lacks this >concept. It's worse than that. No trusted program should even read non-trusted data. The distinction between program and data is not meaningful here; if data can change the actions of a program, a security attack via that data is possible. Consider the worm attacks via the mail system, for example. Back in the Kernalized Secure Operating System days, we had the notion of "integrity level" built into the system. A process running at a high integrity level cannot read data from a lower level. This implies that when one is running at "ADMINISTRATOR" integrity level, only "ADMINISTRATOR" level files can be read or executed. Lower level files can be written, though. Low-integrity level programs cannot, of course, write high-integrity data, although they can read it. (The reverse applies to security level; you can move data up in security level, but not down. All files and processes had both.) It turns out to work, but it is a giant pain to operate under those restrictions. John Nagle