Date: Wed, 24 Jan 1996 20:08:31 +0000 (GMT) From: Paul Richards <p.richards@elsevier.co.uk> To: security@FreeBSD.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601242008.UAA19526@cadair.elsevier.co.uk> In-Reply-To: <199601241812.KAA12343@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 24, 96 10:12:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Nathan Lawson who said > > > Nathan Lawson stands accused of saying: > > > This "someone" is not well-protected enough to own critical things > > > like binaries. Until you can prove to me that a bin compromise is > > > as hard as a root compromise, I won't relent. Consider NFS, > > > hosts.equiv, and login. None of those will stop a bin intrusion. > > > If you can log in as bin, login will let you. If you can access a > > > filesystem via NFS, bin access is allowed while root is mapped to > > > nobody. Hosts.equiv allows _every_ user except root to access the > > > equivalent account. > > > > Bin has no shell. (See below). Few or no binaries are ever setuid bin. Umm, bin does have a shell bin:*:3:7:Binaries Commands and Source,,,:/:/bin/sh The real point against you're argument is segregation of priviliges. Why give any more privilage to a binary than is necessary. If a binary doesn't need to be root then don't make it owned by root at all and then if something goes wrong, like you mistakenly suid a bin binary and not realise it, the possible damage is less than if it was a root binary. This segregation is more to do with protecting sysadmins from themselves than it is about preventing break-ins and the added segragation is *NOT* a potential security hole since those uid's do not have passwords and therefore *cannot* be cracked in and of themselves. You *have* to crack root first. The point about bin is that the system is not owned by an actual user. Another, related point, is that if someone does get access to bin, the damage they can do is limited to the system binaries, you can't go trashing other people's files. To be honest, in a break-in situation the system files are my least concern, if you're security minded you'll be aware pretty soon if someone is messing with your system files and deal with it. Detecting damage to users files is more difficult and in many ways is more important, if someone cracks bin and takes your system down you have outage while you restore, if someone trashed an users mission critical data you're in big trouble. Sysadmins make mistakes, if you make a potentially serious mistake with a bin owned system binary the possible damage is limited to bin owned files. If you make a mistake with a root owned file it's a different matter. This is what segregation of privilages is all about. Making a lot more of the system owned by root just increases the number of potential pitfalls facing sysadmins. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601242008.UAA19526>