mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (12/11/90)
In article <18792@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >The result of making a system call "root-only" is that any application >which might have a legitimate need to execute that function must be >set-uid to root in order to perform that now privileged operation. In general, making some application set-uid to root is more secure ^^^^ than making it set-uid to, say, uucp. In the latter case, you must be careful that no unauthorized person can have uucp nor root priviledge. If you have an executable owned by uucp in root's command serach path (like /usr/bin/tip), those who have uucp priviledge can easily set a trojan horse trap. >Unfortunately, if you have an application that >wants to change the ownership to the user, such as cu, you must now >make cu set-UID to "root". But it is more secure. So, don't make the security mechanism complex. The simpler, the more secure. Masataka Ohta
jfh@rpp386.cactus.org (John F Haugh II) (12/12/90)
In article <6874@titcce.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > In the latter case, you must be careful that no unauthorized person can > have uucp nor root priviledge. If you have an executable owned by uucp > in root's command serach path (like /usr/bin/tip), those who have uucp > priviledge can easily set a trojan horse trap. sure, and any program owned by "bin" which is in root's command search path is also likely to be a trojan horse. most of the programs in /bin have that property. this is why "bin" shouldn't have a password unless you are willing to have the owners of "bin"'s password become "root" someday. and the same applies, of course, to "uucp" and "sys" and so on. > >Unfortunately, if you have an application that > >wants to change the ownership to the user, such as cu, you must now > >make cu set-UID to "root". > > But it is more secure. not true - read on. > So, don't make the security mechanism complex. The simpler, the more secure. this part is true - the number of things which you must protect against with "root" being the effective user ID is far greater than the number of failure modes with a program set-UID to "uucp". "uucp" has no extra privileges, whereas "root" has all of them. consider for just a moment the entire catagory of failures along the lines of "illegal file access". "root" does not require access permission to change a file, but "uucp" does. there still remains many other system calls which have special behavior with euid == 0. none of those apply to euid == "uucp". finally, as if we were adding insult to injury, the common implementation of setuid() on System V does not include the ability to toggle between euid == 0 and euid == ruid - the first visit from 0 to ruid is permanent, which means that you either run as euid == 0 all day long, or fork off other processes to change their id's and exit. yet, if euid != 0 and ruid != 0, you are free to alternate between euid and ruid repeatedly (actually, between ruid and the saved set user ID). so, the short form answer is that in general set-UID to root is far less secure that set-UID to non-root, and this is borne out in various security related documents and criteria. you should =always= execute with the least amount of privilege required to perform the task at hand. set-UID to root is a direct violation of this concept of least privilege. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
ske@pkmab.se (Kristoffer Eriksson) (12/13/90)
In article <6874@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In general, making some application set-uid to root is more secure >than making it set-uid to, say, uucp. > >In the latter case, you must be careful that no unauthorized person can >have uucp nor root priviledge. But that is fairly easy to prevent for a non-user account. Just make it impossible to login to that account. (If, in stead, you break into that account by using some bug in some set-uid program owned by that account, then it wouldn't exactly be more secure to have that program owned by root, so that is no way to avoid my argument.) -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (12/13/90)
In article <4627@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: >>In general, making some application set-uid to root is more secure >>than making it set-uid to, say, uucp. >(If, in stead, you break into that account by using some bug in some >set-uid program owned by that account, then it wouldn't exactly be more >secure to have that program owned by root, so that is no way to avoid my >argument.) The complexity of the security mechanism is different. >But that is fairly easy to prevent for a non-user account. Just make it >impossible to login to that account. Yes, it is fairly easy if you know what to do. But, with a complex security mechanism, it is difficult for an average system administrator to know what to do. A careless administrator may even think that it is safe to give some half-trusted user "uucp" privilege. In article <18808@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >sure, and any program owned by "bin" which is in root's command search >path is also likely to be a trojan horse. most of the programs in /bin >have that property. The proper solution is to remove "bin", which is done on BSD UNIX. I am really astonished to know "bin" is still there on SystemV. >> So, don't make the security mechanism complex. The simpler, the more secure. >this part is true - the number of things which you must protect against >with "root" being the effective user ID is far greater than the number >of failure modes with a program set-UID to "uucp". I don't think it is "far greater". Many known (now closed) security holes to gain root privilege could not have been closed by running related daemons with "uucp" nor by changing the owner of related setuid programs to "uucp". >"uucp" has no extra privileges, whereas "root" has all of them. "uucp" has large capability over files owned by "uucp" and referenced by "root". That is the reality. >you should =always= execute with the >least amount of privilege required to perform the task at hand. "=always="? No, "unless the security mechanism become complex" is the condition. But, the relationships of management related files are already very complex. So, don't bring extra complexity such as a non-root setuid program. Masataka Ohta
jfh@rpp386.cactus.org (John F Haugh II) (12/13/90)
In article <6886@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>you should =always= execute with the >>least amount of privilege required to perform the task at hand. > >"=always="? No, "unless the security mechanism become complex" is >the condition. No, there are no exceptions - the correct response is "always". In the case of complex security mechanisms the correct response is "and particularly in the case of complex security mechanisms". The glossary of the friendly neighborhood Orange Book says ... "Least Privilege: This principle requires each subject [program -ed] in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use." >But, the relationships of management related files are already very >complex. So, don't bring extra complexity such as a non-root setuid >program. Unless there is a requirement for root permissions, adding root permissions is an unneeded complexity. It requires that =every= system call which behaves differently from non-root to root users be analyzed for unexpected behavior. There should be no difference in the precautions taken when you are writing a set-UID "uucp" program as when writing a set-UID "root" one. If you adhere to this you will have a program which =cannot= be less secure simply because any incorrect or unauthorized action performed while UID "uucp" could also be performed while UID "root" with the "root" executed functions succeeding while the "uucp" ones would fail. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
strick@osc.com (henry strickland) (12/15/90)
In article <4627@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: >In article <6874@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>In general, making some application set-uid to root is more secure >>than making it set-uid to, say, uucp. >> >>In the latter case, you must be careful that no unauthorized person can >>have uucp nor root priviledge. > >But that is fairly easy to prevent for a non-user account. Just make it >impossible to login to that account. Nope. In a great many NFS networks today it's not too hard to find one workstation on which you can make yourself root. In the normal NFS setup, making myself root on a workstation does not give me root priveleges on the filesystem of a remote NFS server which I can mount the partitions of. But I can easily be any other user or any group I want on that remote partition, including daemon, bin, uucp, kmem, wheel, operator, audit, etc. Since this is so easy, we have to set our goals to being root on the server. ;-) Now if any of these non-root users owns (or groups has w bits on) some file in the PATH of root (or one of the directories or superdirectories in the PATH), the trojan horse can ride. So I appreciate the suggestion about it being better to set up your priveleged binaries to run setuid root, if it's at all conceivable that root might some day want to run them (lpr, uucp, tip, xterm, rogue). That doesn't negate the advice to do the *minimum* necessary as root and then setuid(non-root). In the usual case that you *really* wanted to execute with effective uid xyzzy, the first thing the binary should do is setuid(xyzzy). ( right? ) strick <strick@osc.com>
ske@pkmab.se (Kristoffer Eriksson) (12/15/90)
In article <6886@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <4627@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: > >>(If, in stead, you break into that account by using some bug in some >>set-uid program owned by that account, then it wouldn't exactly be more >>secure to have that program owned by root, so that is no way to avoid my >>argument.) > >The complexity of the security mechanism is different. What security mechanism are you talking about? What is more complicated? And I don't think it is relevant, anyway. >>But that is fairly easy to prevent for a non-user account. Just make it >>impossible to login to that account. > >Yes, it is fairly easy if you know what to do. I don't see how it is significantly easier to protect the root account alone. >But, with a complex security mechanism, it is difficult for an average >system administrator to know what to do. I don't find it that complex. 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. >A careless administrator may even think that it is safe to give some >half-trusted user "uucp" privilege. Make the administrator do all work in assembler, and maybe he won't dare do anything at all, and we will get a very "secure" system... No, I think this argument is of no significance. To prevent carelessnes, you want to remove a useful security feature? My judgement is that root would become more vulnerable to simple mistakes, rather than less. >"uucp" has large capability over files owned by "uucp" and referenced by >"root". That is the reality. When does root need to reference uucp files? >"=always="? No, "unless the security mechanism become complex" is >the condition. It doesn't become very much more complex. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (12/16/90)
In article <4645@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: >What security mechanism are you talking about? What is more complicated? >I don't see how it is significantly easier to protect the root account alone. 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. >I don't find it that complex. Do you still think so? >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. >My judgement is that root would >become more vulnerable to simple mistakes, rather than less. My point is that root become more vulnerable if it trust uucp, daemon and others. >>"uucp" has large capability over files owned by "uucp" and referenced by >>"root". That is the reality. >When does root need to reference uucp files? It is not necessary, but on my 4.2BSD base system, % ls -l /usr/bin | grep uucp -rws--x--x 2 uucp 86016 May 19 1989 cu ---s--s--x 2 uucp 53248 Apr 7 1988 ruusend -rws--x--x 2 uucp 86016 May 19 1989 tip ---s--s--x 1 uucp 61440 Apr 7 1988 uucp -rwxr-xr-x 1 uucp 49152 Apr 7 1988 uudecode ---s--s--x 1 uucp 24576 Apr 7 1988 uulog ---s--s--x 1 uucp 20480 Apr 7 1988 uuname ---s--s--x 1 uucp 24576 Apr 7 1988 uupoll ---s--s--x 2 uucp 53248 Apr 7 1988 uusend ---s--s--x 1 uucp 20480 Apr 7 1988 uusnap ---s--s--x 1 uucp 65536 Apr 7 1988 uux 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. Masataka Ohta
jfh@rpp386.cactus.org (John F Haugh II) (12/17/90)
In article <4645@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: >In article <6886@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>A careless administrator may even think that it is safe to give some >>half-trusted user "uucp" privilege. > >Make the administrator do all work in assembler, and maybe he won't dare >do anything at all, and we will get a very "secure" system... Ohta-san makes a valid complaint, except that any administrator worth their salt knows that giving "bin" or "uucp" (or any other administrative user ID) access to an untrustable user =is= equivalent to giving away root access. This isn't news. Basically, the *-closure of the files executed by root, or which control the function of a subject with root privilege must be protected. That means that every program directly executed by root, and the programs that those programs execute, and the files that those programs use, and the tools that generate the files that those programs use, and so on, must be kept under root control or there is a chance that root may be violated. That's a pretty big collection of files, but making the owner "root" does not make the collection smaller. >No, I think this argument is of no significance. To prevent carelessnes, you >want to remove a useful security feature? My judgement is that root would >become more vulnerable to simple mistakes, rather than less. In reality root is subject to more severe errors since any error gives is likely to give direct access to the root account. With layered security, a flaw in one program may stop there. For example, a hole in a set-GID mail program may make it so that you can read someone elses mail, while a hole in a set-UID root program may make it so that you can read any file on the entire system. This is all grossly overgeneralized and oversimplified, but you should begin to see the difference, and why least privilege is simply more secure. The only privilege you have ("uucp" access) is that exact privilege you need. >>"uucp" has large capability over files owned by "uucp" and referenced by >>"root". That is the reality. > >When does root need to reference uucp files? Quite often. Don't dismiss the arguments he makes. It's just that this is not new news. Giving away a "uucp" login is certainly giving away access to everyone elses accounts, and probably the same as giving away access to "root" as well. If you don't know this, you have a serious problem already. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@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."
jfh@rpp386.cactus.org (John F Haugh II) (12/17/90)
In article <6922@titcce.cc.titech.ac.jp> mohta@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@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."
ske@pkmab.se (Kristoffer Eriksson) (12/18/90)
In article <4088@osc.COM> strick@osc.com (henry strickland) writes: >In article <4627@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: >>But that is fairly easy to prevent for a non-user account. Just make it >>impossible to login to that account. > >Nope. In a great many NFS networks today it's not too hard to find one >workstation on which you can make yourself root. I thought we already new that NFS was a horrid mess as regards to security. Fix NFS! (Or throw it out) Don't throw out good security features. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (12/18/90)
In article <18826@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >That's a pretty big collection of files, but making the owner "root" >does not make the collection smaller. Smaller? It is not my opinion. My opnion is, it is less complex. >This isn't news. This is the news. In article <18827@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) 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. Nice start. Please continue, until you recognize it complex. Masataka Ohta
jfh@rpp386.cactus.org (John F Haugh II) (12/19/90)
In article <6948@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <18826@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>That's a pretty big collection of files, but making the owner "root" >>does not make the collection smaller. > >Smaller? It is not my opinion. My opnion is, it is less complex. Sure, and letting everyone log onto the system as "root" is also less complex. You have yet to demonstrate how being less complex is some assurance of security. Quite to the contrary, it is widely recognized that least privilege and privilege bracketing techniques provide for increased security by reducing the effects of software errors. Both of these techniques increase what you call "complexity" while simultaneously increasing "security". Software "firewalls" have the same effect. Limiting the damage that an error in the UUCP subsystem can cause to files controlled by the UUCP subsystem =will= limit the effects of software errors or malicious damage. >>This isn't news. > >This is the news. The oldest references that I am aware of predate the 1978 BSTJ "UNIX" edition. While it might be "information", it isn't "new" information. I would say that it is at least 12 year old information. >>How about starting with exporting the file system read-only and only >>to systems which are properly administered. > >Nice start. Please continue, until you recognize it complex. NFS =is= a security hole. The best thing you can do to improve security on a system with NFS is to remove NFS. Changing all the file ownerships to "root" will not save your ass. Now, if you can come up with a flaw in layered security on a properly administered system, then it might be "interesting". -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@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."
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/19/90)
As quoted from <6948@titcce.cc.titech.ac.jp> by mohta@necom830.cc.titech.ac.jp (Masataka Ohta): +--------------- | >>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. | | Nice start. Please continue, until you recognize it complex. +--------------- It became complex when you exported the filesystem via NFS. Additional users adds almost nothing to the resulting complexity.... You are proposing that there should be one user: root. MS-DOS and other single user operating systems work this way, and are anything but secure. Alternatively, you are suggesting that anything root interacts with be owned by root, and that user files may be owned by and modifiable by the user provided root never do anything with them. You want a complex security nightmare? Try to maintain this system without *ever* having a process with root permissions interacting with a file that isn't owned by root. You aren't proposing anything simpler, you're proposing something that looks simpler on paper but has many hidden compexities. The layout is simple, but the actual administration is complex. THERE IS NO WAY AROUND THIS. The only way to get simple security is to put a lock on the door to the computer room and attach no terminals or computers outside that room, and let nobody in or out of the room for any reason. And I can argue that *that* can not be trusted. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (12/19/90)
In article <18840@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>Smaller? It is not my opinion. My opnion is, it is less complex. > >Sure, and letting everyone log onto the system as "root" is also >less complex. Moreover, with current UNIX, it is as secure as letting everyone log onto the system as "uucp". >You have yet to demonstrate how being less complex >is some assurance of security. Isn't it obvious that, if all important files are owned only by root, letting everyone log onto the system as "uucp" becomes secure. >>This is the news. >The oldest references that I am aware of predate the 1978 BSTJ >"UNIX" edition. While it might be "information", it isn't >"new" information. I would say that it is at least 12 year >old information. But, still, you don't understand the importance of simplicity. >NFS =is= a security hole. Yes, it is, partly because it is complex. >Now, if you can come up with a flaw in layered security on a >properly administered system, then it might be "interesting". I know it is impossible to properly administrate a system with layered security such as ACL. >security on a system with NFS is to remove NFS. Changing all >the file ownerships to "root" will not save your ass. Remove NFS? You had better remove your ass. Masataka Ohta
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/20/90)
I think many of you are missing the point of having files owned by root. When root owns files, and keeps them publicly unwritable, nobody else can mess with them. If you let anybody else own files, you are giving that user permission to change those files too. If root ever uses a file owned by somebody else, there's a security problem. Hence for better security, root should own all files that it uses. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi