Date: Wed, 24 Jan 1996 10:12:39 -0800 (PST) From: Nathan Lawson <nlawson@statler.csc.calpoly.edu> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601241812.KAA12343@statler.csc.calpoly.edu> In-Reply-To: <199601241221.WAA27070@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 24, 96 10:51:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Nathan Lawson stands accused of saying: > > > If nothing else, it's convenient to have "someone" own "system" things. > > > It's _preferable_ that this "someone" isn't a user in the common sense of > > > the word. > > > 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. Pardon me. I was thinking of the many other nologin accounts that had a null shell (meaning /bin/sh by default). > If you're paranoid, your NFS mounts are nosuid. I'd say bin was of > comparable secureness to root. Root is, however, more likely to be stupid > and use their password in cleartext over the 'net or be shoulder-snooped. If root gets compromised, then bin is compromised too (I can su bin or just overwrite bin-owned files as root). However, if bin is compromised, root is _not_ necessarily compromised unless you have lots of common binaries owned by bin. See the difference? Bin is only a common user without a password. It has no more protection than your or my account, except its password cannot be sniffed (since there is none). It doesn't matter if your NFS mounts are nosuid. They have to be read-only too. Think about this: you export /usr/bin to some diskless FreeBSD client. Some guy gets root on that client, does an su bin, and replaces /usr/bin/login with some script to start a shell on a port. Now all he has to do is telnet to your machine, telnetd starts up login, and it pops up his root shell on another port. How about hosts.equiv? Joe User gets root access on a machine. He can rlogin to the server as any user. What user would get him more privileges? Well, he can't login as root since hosts.equiv doesn't allow that. So, he rlogins as bin, replaces some key binaries, and you have the same compromised state. Now let's say nothing was owned by bin. All binaries are owned by root. Joe User rlogin's or nfs's into the server as bin. Whoops! He's gained no more privileges than if he had chosen Susy User or any other account. Now, he has to exploit some local bug to get root on server (which isn't impossible, but will definitely take a bit longer). > Having binaries owned by bin compromised is no more likely than having > binaries owned by root compromised. The added protection of having a > nonlogin user owning them is obviously worth it, presuming that root is > reasonably careful. Not true (see above). Bin compromises are much easier than root, especially if the admin is careful about the root password. > Either way, bin is a convenient and simple safeguard. It hurts nothing, > so why the angst? It hurts security. I still have yet to hear a good reason why bin ownership has even one advantage over root. -- 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?199601241812.KAA12343>