Date: Mon, 20 Apr 1998 17:06:44 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Niall Smart <rotel@indigo.ie> Cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Message-ID: <Pine.BSF.3.95.980420170029.16057V-100000@alive.znep.com> In-Reply-To: <199804202201.XAA00941@indigo.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Apr 1998, Niall Smart wrote: > On Apr 19, 6:25pm, Marc Slemko wrote: > } Subject: Re: suid/sgid programs > > On Mon, 20 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. > > lpr hands print jobs for remote printers off to lpd, so it doesn't > need to be setuid. lpd accepts connections from any port number, > so the sending lpd doesn't have to stay root so it can open > connections to remote printers from a privledged port. FreeBSD lpd may accept such connections, others don't. > > Yes, you lose the ability to lpr -s but security comes at a price, > and this is a small price IMO. Many people don't even know about > lpr -s, especially the twits with 16Mb of 32-bit color images > embedded in their print jobs. > > > "this silly privileged socket scheme" may be silly but throwing it out > > without replacing it isn't the answer. > > The replacements, cryptography and credential passing over UNIX > domain sockets, are ready and willing! First, that isn't being advocated here. What is being advocated is saying that "oh, it can do everything just as well as some other user so just make it do the same thing as some other user." Second, life isn't as easy as that. Trying to put cryptography in the base code of any freely available program is difficult, especially in the US, and can seriously limit exportability, usability and compatibility. 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.980420170029.16057V-100000>