From owner-freebsd-security Wed Jan 24 18:12:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA12509 for security-outgoing; Wed, 24 Jan 1996 18:12:41 -0800 (PST) Received: from fire.stf.org.sg (fire.stf.org.sg [137.132.19.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA12494 for ; Wed, 24 Jan 1996 18:12:15 -0800 (PST) Received: (from jseng@localhost) by fire.stf.org.sg (8.6.12/8.6.9) id KAA22403; Thu, 25 Jan 1996 10:16:55 +0800 Date: Thu, 25 Jan 1996 10:16:55 +0800 (SGT) From: James Seng To: Nathan Lawson cc: Michael Smith , security@FreeBSD.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601241812.KAA12343@statler.csc.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk On Wed, 24 Jan 1996, Nathan Lawson wrote: > Pardon me. I was thinking of the many other nologin accounts that had a > null shell (meaning /bin/sh by default). Actually, even if bin has /nonexistant as a shell in passwd, it can still be login in various ways (rsh -l bin /bin/sh -i). In either case, one more account, one more trouble..but somehow, i still prefer BSD ways of letting bin own the binaries and not root like Linux..dunno why *8) Perhaps i think root have too much power? It seem like none or all solution. In this aspect VMS is better i guess. > 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. Speaking of NFS, anyone knows how secure is FreeBSD NFS? I remember there used to be a case whereby NFS filehandle can be easily guessed..does it still exist here or FreeBSD is using the DES-key? > 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. In that case, i guess the system admin should wake up a bit *8) Anyone who see bin in that wtmp got to do something fast... It is funny that we have access control on telnetd (or is it logind?), that is who and who is able to login thru telnet, but we have no access control on rlogin, rsh etc...hmm... > It hurts security. I still have yet to hear a good reason why bin ownership > has even one advantage over root. Lets see...because we dont like root to have too much privelliges? *8)))))) (sorry, i couldnt think of a good reason either but i support the idea for bin to own binaries..hehe *8) -James Seng (jseng@stf.org.sg)