Magic symlinks redux

[Robert Watson]

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