Date: Sat, 23 Aug 2008 13:27:01 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux Message-ID: <alpine.BSF.1.10.0808231319210.91974@fledge.watson.org> In-Reply-To: <g8ohbu$a23$1@ger.gmane.org> References: <g8kv7v$sp2$1@ger.gmane.org> <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> <p0624080ec4d51f26d476@[128.113.24.47]> <g8ohbu$a23$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Aug 2008, Ivan Voras wrote:
>> I am extremely uneasy about adding anything related to uid's or gid's, or
>> similar dynamic values.
>
> This argument pops up often without explanation. The only thing I can think
> of is applications using ".." on a dynamic symlink and ending up somewhere
> where it doesn't want to, but this can also be said for normal symlinks.
>
> Can anyone explain more possible security problems with having @uid in
> varsymlinks?
The issues I'm aware of revolve more about usability than security, although
frequently security relies on determinism. Consider setuid tools, such as lpr
or sudo, which currently behave deterministically when a path is passed, and
the effect of having "@uid" present in a symlink evaluated in the lookup to
/tmp:
lpr /tmp/my.txt
sudo mv /tmp/group.tmp /etc/group
While I see arguments going many different ways on this, I think POLA
reasonably demands that we not significant disrupt the semantics of /tmp or
other situations where, on face value, a uid-based symlink might be used.
And, from a general security perspective, maintaining the assumptions of
current users, applications, etc, is quite important for avoiding
vulnerabilities that stem from changing underlying execution model
assumptions.
I think Brooks's reimplementation of the DFBSD approach addresses most of my
concerns with respect to classic name space manipulation attacks, but even
then I would advise extreme caution.
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0808231319210.91974>