Date: Sun, 19 Apr 1998 18:25:55 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Niall Smart <rotel@indigo.ie>, Robert Watson <robert+freebsd@cyrus.watson.org> Cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Message-ID: <Pine.BSF.3.95.980419181315.16057E-100000@alive.znep.com> In-Reply-To: <Pine.BSF.3.96.980419191830.4778A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Apr 1998, Niall Smart wrote: > On Apr 19, 3:16pm, Marc Slemko wrote: > } Subject: Re: suid/sgid programs > > On Sun, 19 Apr 1998, Niall Smart wrote: > > > > > > But if someone can break the uid that lpr runs as then they can probably > > > > break root anyway. > > > > > > How? > > > > Because they then have full access to the queue directory that lpd reads > > from and lpd does run as root so it can access the files people want to > > print. > > lpr can be setuid "lp" so that it can write to the print spool > directory, it has access to the file the user wants to print because > that is it's real uid. lpd can be root.wheel 770 and immediately > setuid to "lp" after opening the socket. (Or you could just disable > this silly priveledged socket scheme) Not unless you are willing to lose "lpr -s" and the ability to print to remote printers. "this silly privileged socket scheme" may be silly but throwing it out without replacing it isn't the answer. On Sun, 19 Apr 1998, Robert Watson wrote: > On Mon, 20 Apr 1998, Niall Smart wrote: > > > lpr can be setuid "lp" so that it can write to the print spool > > directory, it has access to the file the user wants to print because > > that is it's real uid. lpd can be root.wheel 770 and immediately > > setuid to "lp" after opening the socket. (Or you could just disable > > this silly priveledged socket scheme) > > In previous discussions, people have suggested adding a "sockets" group > for which low port bindings are allowed. This might be implemented by > using a sysctl that identifies the gid to the kernel (or something). Any > program running with this in its groups would be allowed to bind low port > number. This provides an immediate fix for having a bunch of daemons (and > applications) running as root. It fixes little and, in general, opens more security holes than it fixes. While there are some valid uses for it, they are generally few and far between. First, you still have host based authentication. You may not like it, but it is still shipped with FreeBSD and used. This means that anyone getting access to low ports can do damage. On top of that, there is the problem that anyone getting access to low ports can impersonate other services. Consider, for example, a web server like Apache. If you have it started by the same user it runs as, then you can't let any users run CGIs without a wrapper. On top of that, you must trust the entire code of the server to have no security holes. Compare that to the setup right now: you only have to trust the small part that runs as root, because the rest of the code just gives access to a throwaway user if there are any holes. That is still a problem, but not the huge problem it would be if you opened up low ports. In general, being able to have a server like Apache init under one uid then run under another is useful. For example, it protects your logfiles from being altered if someone breaks into the uid that it runs as. If you want to take this one step further, it is trivial to have a wrapper program that is setuid and opens the required sockets before setuid()ing and execing the actual server. You do lose some functionality here, such as the ability to close and reopen the socket or open sockets at runtime instead of init time, but that is often acceptable. I say again: these things often aren't as simple as they appear at first glance or they would have been changed before now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980419181315.16057E-100000>