BugTraq
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 23 2009 09:12PM
Dan Yefimov (dan lightwave net ru) (4 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 25 2009 09:46AM
Klaus Lichtenwalder (k lichtenwalder computer org)
Re: /proc filesystem allows bypassing directory permissions onLinux Oct 24 2009 06:47AM
Anton Ivanov (arivanov sigsegv cx) (1 replies)
Re: /proc filesystem allows bypassing directory permissions onLinux Oct 24 2009 04:19PM
Dan Yefimov (dan lightwave net ru) (1 replies)
Re: /proc filesystem allows bypassing directory permissionsonLinux Oct 24 2009 04:59PM
Anton Ivanov (arivanov sigsegv cx) (1 replies)
Re: /proc filesystem allows bypassing directory permissionsonLinux Oct 24 2009 05:39PM
Dan Yefimov (dan lightwave net ru) (1 replies)
Re: /proc filesystem allows bypassing directorypermissionsonLinux Oct 24 2009 06:05PM
Anton Ivanov (anton ivanov kot-begemot co uk) (1 replies)
Re: /proc filesystem allows bypassing directorypermissionsonLinux Oct 24 2009 06:36PM
Dan Yefimov (dan lightwave net ru) (2 replies)
Re: /proc filesystem allows bypassing directorypermissionsonLinux Oct 27 2009 08:59PM
Ivan Jager aij+ (at) mrph (dot) org [email concealed] (aij+ mrph org)
Re: /proc filesystem allows bypassingdirectorypermissionsonLinux Oct 24 2009 07:27PM
Anton Ivanov (anton ivanov kot-begemot co uk) (1 replies)
Re: /proc filesystem allows bypassing directory permissions onLinux Oct 29 2009 11:00AM
Pavel Machek (pavel ucw cz)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 23 2009 10:05PM
Pavel Machek (pavel ucw cz) (2 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 26 2009 03:30PM
Casper Dik sun com (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 26 2009 04:16PM
Dan Yefimov (dan lightwave net ru) (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 26 2009 09:58PM
psz maths usyd edu au (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 27 2009 06:50AM
Marco Verschuur (marco osp nl) (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 27 2009 12:56PM
psz maths usyd edu au (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 27 2009 08:19PM
Marco Verschuur (marco osp nl) (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 28 2009 09:38PM
Pavel Machek (pavel ucw cz) (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Oct 29 2009 04:32PM
Martin Rex (Martin Rex sap com) (1 replies)
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

[ reply ]
Re: /proc filesystem allows bypassing directory permissions on Oct 29 2009 08:36PM
Pavel Machek (pavel ucw cz)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 23 2009 10:21PM
Dan Yefimov (dan lightwave net ru) (1 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 23 2009 10:39PM
Pavel Machek (pavel ucw cz) (3 replies)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 26 2009 09:49PM
Glynn Clements (glynn gclements plus com)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 26 2009 04:05PM
Tamber Penketh (james penketh googlemail com) (1 replies)
Re: /proc filesystem allows bypassing directory permissions onLinux Oct 27 2009 12:55AM
Pavel Machek (pavel ucw cz)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 23 2009 10:55PM
Dan Yefimov (dan lightwave net ru)
Re: /proc filesystem allows bypassing directory permissions on Linux Oct 23 2009 09:22PM
Arturo 'Buanzo' Busleiman (buanzo buanzo com ar)


 

Privacy Statement
Copyright 2010, SecurityFocus