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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: NT security backup
    ... I want to backup the security permissions for the shares not ... >>> have to create manually this shares on the new server. ... permissions are not held in the registry, but in the file descriptor itself. ...
    (comp.os.ms-windows.nt.admin.security)
  • RE: What server hardening are you doing these days?
    ... permissions on their data, and Microsoft encourages ISVs to minimize ... I've been able to discuss ACLs and other security issues in Windows with ... Control or DAC (which is what you're referring to by the "stupid ...
    (Focus-Microsoft)
  • Re: symlinks with permissions
    ... permissions on the path to the file). ... Are you trying to argue how Linux *should* work, ... refuse to expose a way to upgrade a read-only file descriptor to ... some way to upgrade a O_RDONLY file descriptor into O_RDWR mode based on ...
    (Linux-Kernel)
  • Re: get rid of security center?
    ... I have come up with a solution that does not disable Security Center, ... By changing the Permissions of that key, ... settings from being changed again. ... the firewall alert settings in Security Center get ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Password Protect IExplore
    ... You can protect the files and folders you store on your computer to make ... To set, view, change, or remove special permissions for files and folders ... clear the Inherit from parent the permission entries that apply ... To configure security so that the subfolders and files will not ...
    (microsoft.public.internet.explorer.ieak)