Skip site navigation (1)Skip section navigation (2)
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>