Message-Id: <200910291632.n9TGWs3q021724@fs4113.wdf.sap.corp>
Date: Thu, 29 Oct 2009 17:32:54 +0100 (MET)
From: Martin Rex <Martin.Rex@....com>
To: pavel@....cz (Pavel Machek)
Cc: marco@....nl, bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on

Pavel Machek wrote:
> 
> > IMHO; no bug or security issue, just a misunderstanding of the
> > mechanism...

Correct.  It is a completely flawed assumption.

In Unix, an open() of a file checks access permissions as
specified in the files inode.  If someone wants access control
applied to a file, then he MUST do so using the permission in
the file inode.

Making assumptions about directory search and acces permissions
is plain stupid.


>
> The /proc/self/fd/X appears to be a symlink, but it is not; it
> operates on underlying objects directly. And IMNSHO it should honor
> restrictions opened filedescriptors have, like append-only or
> read-only.

/proc/self/fd/X is something virtual, not something real.  It is
state as held by the kernel, it is not persisted anywhere.

The reason why it is visualized like a symlink is to provide clue
about the actual filename behind that filedescriptor (at least
at the time when the open was performed).

If it was a real symlink, then it would no longer work if the
file was renamed, moved to a different directory or deleted (while still open)
between the creation of the file descriptor and the time that someone
wanted to access the very same file through /proc.


There are two conceivable approaches to implementing the open() for
a filedescriptor shown in /proc.  Either go throuh the inode and
check the access permissions on the file at the current time
(which is a sensible implementation and what the kernel seems
to be currently doing), or implement it as a dup() and transfer
of the filedescriptor.  (Tranfering open filedescriptors between
processes can also be done by IPC).  Implemetenting it via dup()
would probably keep the original filedescriptor attributes
(such as read-only) but would require an entirely seperate
approach to access control (who is allowed to dup() that filedescriptor),
and it would create problems:  like you would not be able to look
into files that were opened only for write through /proc, which
would seriously impair the usefulness of the fd-listing in /proc.


This feature of /proc is just fine as it is.  It does seem to confuse
people who think in contorted fashion and make a lot of flawed 
assumptions, though (those guys are going to create many other
security problems as well, so we should rather educate them
about avoiding flawed assumptions.

Directory access permissions are purely about access to directory
contents (which are plain names), Directory access permissions
(at least on Unix) do NOT affect access to files, and they're
NOT checked for permission on open(2) -- and have never been.

There may be a side-effect of directory access permissions when
open(2) resolves a filename, but that is purely a side-effect,
not a by-design feature guaranteed by open(2).  Thinking otherwise
is a flawed assumption.


If you move (mv,rename) a file around in the filesystem,
like from a 0700 directory into a 0755 directory, that operation
will _not_ affect the file access permissions in the inode.
It doesn't matter wether you did not intend the file to become
available when you did the mv/rename.  The OS will only check
the file access permissions on the inode on open, and mv/rename
doesn't touch them.  Different path accessibility in the new
location/directory is a pure side-effect, not a by-design
feature of open(2) that any operations like "mv/rename"
will guarantee.


If you put world-writable (0666) access permissions on a file, the observed
result is exactly what you asked for when doing so.  Why does a file in
a 0700 directory need anything more than 0600 access permissions
as far as applications are concerned?


The files inode does NOT know and NOT care where the directory entries
are located that reference this inode and what permissions are on the
directory and path up to the root.


The real fun with unexpected results is with Microsoft Windows ACLs
and inheritable permissions on directories.  If you move files around
there, the effects on the resulting access permissions of a file
are quite often surprising, especially if the files are moved
across device boundaries.


There absolutely is not substitute for careful application design,
If the observed behaviour with the linux fd-semantics in the /proc
filesystem is a problem for an application, then this is a severe
design flaw of the application, based on fatally flawed assumptions,
not a security problem or vulnerability of the underlying OS.



-Martin

Powered by blists - more mailing lists