Date: Fri, 13 May 2011 02:28:36 -0700 From: Chris Telting <christopher-ml@telting.org> To: Jonathan McKeown <j.mckeown@ru.ac.za> Cc: freebsd-questions@freebsd.org Subject: Re: Established method to enable suid scripts? Message-ID: <4DCCF9C4.2040106@telting.org> In-Reply-To: <201105130932.32144.j.mckeown@ru.ac.za> References: <4DC9DE2C.6070605@telting.org> <201105121657.57647.j.mckeown@ru.ac.za> <4DCBFC39.8060900@telting.org> <201105130932.32144.j.mckeown@ru.ac.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/13/2011 00:32, Jonathan McKeown wrote: > On Thursday 12 May 2011 17:26:49 Chris Telting wrote: >> On 05/12/2011 07:57, Jonathan McKeown wrote: >>> I'll say that again. It is inherently insecure to run an interpreted >>> program set-uid, because the filename is opened twice and there's no >>> guarantee that someone hasn't changed the contents of the file addressed >>> by that name between the first and second open. >>> >>> It's one thing to tell people they need to be careful with suid because >>> it has security implications. Deliberately introducing a well-known >>> security hole into the system would in my view be dangerous and wrong. >> That race condition bug was fixed in ancient times. Before Freebsd or >> Linux ever existed I believe. It's a meme that just won't die. People >> accepted mediocrity in old commercial versions of Unix. I personally am >> unsatisfied by kludges. > That seems somewhat unlikely given, as someone else pointed out upthread, that > Perl still comes with a compile-time option SETUID_SCRIPTS_ARE_SECURE_NOW, > suggesting that they often aren't. Yes, there are ways to avoid this race > condition - the usual one is to pass a handle on the open file to the > interpreter, rather than closing it and reopening it. > > This fix is not present in every Unix or Unix-like OS. In particular (although > I'm happy to be corrected if I'm wrong) it's not present in FreeBSD, to the > best of my knowledge. Whether there's a reason for that other than lack of > developer time I don't know. > Indeed. I think it's more of a case that since you can't count on it on other systems (especially closed source systems) to disable it for portability reasons although I would loved to be proved wrong. Happy Friday.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DCCF9C4.2040106>