Date:	Wed, 28 Oct 2009 21:13:12 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	David Wagner <daw-news@...berkeley.edu>
CC:	linux-kernel@...r.kernel.org,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: symlinks with permissions

David Wagner wrote:
> Casey Schaufler  wrote:
>   
>> There is no security violation here. Consider the case where
>> the file is unlinked after it is opened. What directory permissions
>> would matter in that case?
>>     
>
> Where are you going with this?
>   

Probably straight into a level of obscurity that only a
very small fraction of us care about, but hear me out.

> Suppose I open a file in read-only mode.  Suppose moreover I only
> have permission to read the file but not write it (given the full
> permissions on the path to the file).

Ok. The parenthetical clause is a problem. Once you have the file
descriptor the path that you used to get it is completely irrelevant.
Not just unimportant. It matters not at all. The only thing that
matters at that point are the mode bits on the file itself. Why?
If /a/foo is a hard link to /b/bar (for the uninitiated that means
that foo and bar are on the same file system and share an inode
number) there is absolutely no way to tell, given a file descriptor,
which path was used to open the file. Further, it is no longer
necessary that foo, bar, a, or b even exist any longer. So if
/proc/8675309/fd/3 is accessable for write access to a process it
does not matter one horse's pitutte what the mode bits on a or b
might be. Period.

>   Suppose that someone else deletes
> the file.  Then the OS had darn well better prevent me from upgrading
> my read-only file descriptor to a read-write file descriptor.

Nope. Not if the mode bits on the file allow it. How you got to
the file matters not at all. The mode of the path you happened to
use matters not at all. What matters are the mode bit on the file
itself.

>   If some
> OS feature created a backdoor that allowed me to upgrade my read-only
> file descriptor to read-write access (even in cases where the file and
> directory permissions would prevent me from directly opening the file in
> read-write mode), then we'd darn well consider that a security violation.
> That is roughly analogous to what is happening here.
>   

No, I don't believe that is correct. Unless I read the discussion
incorrectly, the file has to be writeable for the "exploit" to
work. The reason that it looks like an exploit is that the mode bits
on the containing directory "should" prevent the requested access,
but in reality /proc/8675309/fs/3 provides an alternative pathname
to the object, just as having a hard link or an alternative mount
point might. Neither of those cases is an "exploit", although I can
easily understand how they might appear to be to those who are
unfamiliar with the acyclic graph that is the Linux (Unix) file
system name space.

> I do think Pavel's attack is a security violation.  I don't understand
> why there is any debate about this; it seems pretty clear-cut to me.
> It may be an obscure corner-case, but it still seems like a cut-and-dry
> security violation.  (Incidentally, I found the quality of some of the
> discussion on bugtraq pretty disappointing as well.)
>   

Sorry if my arguments lack clarity. It's been a rough year.

The only access that really matters is that of the object itself.
The path you use to get to it only matters during the resolution
of the path, after which it is, and must be, irrelevant. If there
is a path that leads to the object that is constructed some other
way, as the "fd" bit of /proc is, then the semantics of that path's
construction are what matter for the resolution of that path. Since
they have no way or reason to determine what the original
resolution path might have been there is no point in whinging
that the access of the /proc/8675309/fd/3 path is different from
the /a/foo path any more than there is that /b/bar might be
different.

>   
>> The path name is
>> an ethereal convenience and once traversed has no bearing on the
>> security state of the object.
>>     
>
> I think you've missed the point of Pavel's attack.  Pavel's attack allows
> a malicious process to take an existing read-only file descriptor and
> turn it into a read-write file descriptor, in cases where the filesystem
> permission bits should not have allowed the malicious process to do that.
> *That* is the security violation.  *That* should not be allowed.
>   

Again, once the file descriptor exists the only mode bits
(Or Smack label, or SELinux context, or ACL) that matters is
that of the object itself. It is perfectly OK to change a RO
to an RW if the mode bits allow it.

> Perhaps take a look at Pavel's post describing the attack again?

Yeah, I did that. It still looks like the complaint is that
/proc/8675309/fd/3 gives you the ability to gain RW access to
an object for which you have RW access.

Look, with hard links and the various mount options available
today you just can't count on setting the mode on a directory
to completely protect the files that it references. Look carefully
at the semantics of directories. They do not contain files. They
contain names of files. Setting the mode on a directory protects
access to the name of a file, not access to the file. There are
multiple ways to name a file, and access to any of the names of
a file to which you have access is sufficient to get you access
to the file.

As always, I could be missing something completely, but I have
been arguing Unix/Linux file system security issues for longer
than some of the people reading this have been alive.

Now, ask me if I think that /proc/8675309/fd/3 is a good idea,
and we'll have a different discussion, but from an old school
security standpoint (objects, subjects, accesses) there just is
not a problem.

If you want to introduce the notion that the pathname used to
access a file matters on subsequent access control decisions, well,
good luck, but don't say I didn't warn you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists