symlinks with permissions

symlinks with permissions

[Pavel Machek]

...yes, they do exist, in /proc/self/fd/* . Unfortunately, their
permissions are not actually checked during open, resulting in
(obscure) security hole: if you have fd open for reading, you can
reopen it for write, even through unix permissions would not allow
that.

Now... I'd like to close the hole. One way would be to actually check
symlink permissions on open -- because those symlinks already have
correct permissions.

But ... then I got lost in vfs. Can someone help? Is there better way?

    	       	   	   	    	    	     	   	  Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Pavel Machek]

On Mon 2009-10-26 13:57:49, Trond Myklebust wrote:
> On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
> >   That's what I'd think as well but it does not as I've just learned and
> > tested :) proc_pid_follow_link actually directly gives a dentry of the
> > target file without checking permissions on the way.

It is weider. That symlink even has permissions. Those are not
checked, either.
 
> I seem to remember that is deliberate, the point being that a symlink
> in /proc/*/fd/ may contain a path that refers to a private namespace.

Well, it is unexpected and mild security hole.

Part of the problem is that even  if you have read-only
filedescriptor, you can upgrade it to read-write, even if path is
inaccessible to you.

So if someone passes you read-only filedescriptor, you can still write
to it.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Jan Kara]

  Hi,

On Sun 25-10-09 07:29:53, Pavel Machek wrote:
> ...yes, they do exist, in /proc/self/fd/* . Unfortunately, their
> permissions are not actually checked during open, resulting in
> (obscure) security hole: if you have fd open for reading, you can
> reopen it for write, even through unix permissions would not allow
> that.
> 
> Now... I'd like to close the hole. One way would be to actually check
> symlink permissions on open -- because those symlinks already have
> correct permissions.
  Hmm, I'm not sure I understand the problem. Symlink is just a file
containing a path. So if you try to open a symlink, you will actually open
a file to which the path points. So what security problem is here? Either
you can open the file symlink points to for writing or you cannot...
  Anyway, if you want to play with this,
fs/proc/base.c:proc_pid_follow_link
  is probably the function you are interested in.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: symlinks with permissions

[Serge E. Hallyn]

Quoting Jan Kara (jack@suse.cz):
>   Hi,
> 
> On Sun 25-10-09 07:29:53, Pavel Machek wrote:
> > ...yes, they do exist, in /proc/self/fd/* . Unfortunately, their
> > permissions are not actually checked during open, resulting in
> > (obscure) security hole: if you have fd open for reading, you can
> > reopen it for write, even through unix permissions would not allow
> > that.
> > 
> > Now... I'd like to close the hole. One way would be to actually check
> > symlink permissions on open -- because those symlinks already have
> > correct permissions.
>   Hmm, I'm not sure I understand the problem. Symlink is just a file
> containing a path. So if you try to open a symlink, you will actually open
> a file to which the path points. So what security problem is here? Either
> you can open the file symlink points to for writing or you cannot...
>   Anyway, if you want to play with this,
> fs/proc/base.c:proc_pid_follow_link
>   is probably the function you are interested in.

The problem he's trying to address is that users may try to protect
a file by doing chmod 700 on the parent dir, but leave the file itself
accessible.  They don't realize that merely having a task with an open
fd to that file gives other users another path to the file.

Whether or not that's actually a problem is open to debate, but I think
he's right that many users aren't aware of it.

-serge

Re: symlinks with permissions

[J. Bruce Fields]

On Mon, Oct 26, 2009 at 11:57:29AM -0500, Serge E. Hallyn wrote:
> Quoting Jan Kara (jack@suse.cz):
> >   Hi,
> > 
> > On Sun 25-10-09 07:29:53, Pavel Machek wrote:
> > > ...yes, they do exist, in /proc/self/fd/* . Unfortunately, their
> > > permissions are not actually checked during open, resulting in
> > > (obscure) security hole: if you have fd open for reading, you can
> > > reopen it for write, even through unix permissions would not allow
> > > that.
> > > 
> > > Now... I'd like to close the hole. One way would be to actually check
> > > symlink permissions on open -- because those symlinks already have
> > > correct permissions.
> >   Hmm, I'm not sure I understand the problem. Symlink is just a file
> > containing a path. So if you try to open a symlink, you will actually open
> > a file to which the path points. So what security problem is here? Either
> > you can open the file symlink points to for writing or you cannot...
> >   Anyway, if you want to play with this,
> > fs/proc/base.c:proc_pid_follow_link
> >   is probably the function you are interested in.
> 
> The problem he's trying to address is that users may try to protect
> a file by doing chmod 700 on the parent dir, but leave the file itself
> accessible.  They don't realize that merely having a task with an open
> fd to that file gives other users another path to the file.
> 
> Whether or not that's actually a problem is open to debate, but I think
> he's right that many users aren't aware of it.

If /proc/self/fd/23 is a symlink to /home/me/privatedir/secret, then an
open("proc/self/fd/23",...) still traverses the whole /home/.../secret
path, and needs appropriate permissions at each step, doesn't it?

Probably I'm just terminally confused....

--b.

Re: symlinks with permissions

[Jan Kara]

On Mon 26-10-09 13:36:29, J. Bruce Fields wrote:
> On Mon, Oct 26, 2009 at 11:57:29AM -0500, Serge E. Hallyn wrote:
> > Quoting Jan Kara (jack@suse.cz):
> > >   Hi,
> > > 
> > > On Sun 25-10-09 07:29:53, Pavel Machek wrote:
> > > > ...yes, they do exist, in /proc/self/fd/* . Unfortunately, their
> > > > permissions are not actually checked during open, resulting in
> > > > (obscure) security hole: if you have fd open for reading, you can
> > > > reopen it for write, even through unix permissions would not allow
> > > > that.
> > > > 
> > > > Now... I'd like to close the hole. One way would be to actually check
> > > > symlink permissions on open -- because those symlinks already have
> > > > correct permissions.
> > >   Hmm, I'm not sure I understand the problem. Symlink is just a file
> > > containing a path. So if you try to open a symlink, you will actually open
> > > a file to which the path points. So what security problem is here? Either
> > > you can open the file symlink points to for writing or you cannot...
> > >   Anyway, if you want to play with this,
> > > fs/proc/base.c:proc_pid_follow_link
> > >   is probably the function you are interested in.
> > 
> > The problem he's trying to address is that users may try to protect
> > a file by doing chmod 700 on the parent dir, but leave the file itself
> > accessible.  They don't realize that merely having a task with an open
> > fd to that file gives other users another path to the file.
> > 
> > Whether or not that's actually a problem is open to debate, but I think
> > he's right that many users aren't aware of it.
> 
> If /proc/self/fd/23 is a symlink to /home/me/privatedir/secret, then an
> open("proc/self/fd/23",...) still traverses the whole /home/.../secret
> path, and needs appropriate permissions at each step, doesn't it?
> 
> Probably I'm just terminally confused....
  That's what I'd think as well but it does not as I've just learned and
tested :) proc_pid_follow_link actually directly gives a dentry of the
target file without checking permissions on the way.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: symlinks with permissions

[Serge E. Hallyn]

Quoting J. Bruce Fields (bfields@fieldses.org):
> On Mon, Oct 26, 2009 at 11:57:29AM -0500, Serge E. Hallyn wrote:
> > Quoting Jan Kara (jack@suse.cz):
> > >   Hi,
> > > 
> > > On Sun 25-10-09 07:29:53, Pavel Machek wrote:
> > > > ...yes, they do exist, in /proc/self/fd/* . Unfortunately, their
> > > > permissions are not actually checked during open, resulting in
> > > > (obscure) security hole: if you have fd open for reading, you can
> > > > reopen it for write, even through unix permissions would not allow
> > > > that.
> > > > 
> > > > Now... I'd like to close the hole. One way would be to actually check
> > > > symlink permissions on open -- because those symlinks already have
> > > > correct permissions.
> > >   Hmm, I'm not sure I understand the problem. Symlink is just a file
> > > containing a path. So if you try to open a symlink, you will actually open
> > > a file to which the path points. So what security problem is here? Either
> > > you can open the file symlink points to for writing or you cannot...
> > >   Anyway, if you want to play with this,
> > > fs/proc/base.c:proc_pid_follow_link
> > >   is probably the function you are interested in.
> > 
> > The problem he's trying to address is that users may try to protect
> > a file by doing chmod 700 on the parent dir, but leave the file itself
> > accessible.  They don't realize that merely having a task with an open
> > fd to that file gives other users another path to the file.
> > 
> > Whether or not that's actually a problem is open to debate, but I think
> > he's right that many users aren't aware of it.
> 
> If /proc/self/fd/23 is a symlink to /home/me/privatedir/secret, then an
> open("proc/self/fd/23",...) still traverses the whole /home/.../secret
> path, and needs appropriate permissions at each step, doesn't it?
> 
> Probably I'm just terminally confused....

No, never mind, I misread his earlier email.  Sorry.

-serge

Re: symlinks with permissions

[Trond Myklebust]

On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
>   That's what I'd think as well but it does not as I've just learned and
> tested :) proc_pid_follow_link actually directly gives a dentry of the
> target file without checking permissions on the way.
> 
> 								Honza

I seem to remember that is deliberate, the point being that a symlink
in /proc/*/fd/ may contain a path that refers to a private namespace.

Cheers
  Trond

Re: symlinks with permissions

[J. Bruce Fields]

On Mon, Oct 26, 2009 at 06:46:31PM +0100, Jan Kara wrote:
> On Mon 26-10-09 13:36:29, J. Bruce Fields wrote:
> > On Mon, Oct 26, 2009 at 11:57:29AM -0500, Serge E. Hallyn wrote:
> > > Quoting Jan Kara (jack@suse.cz):
> > > >   Hi,
> > > > 
> > > > On Sun 25-10-09 07:29:53, Pavel Machek wrote:
> > > > > ...yes, they do exist, in /proc/self/fd/* . Unfortunately, their
> > > > > permissions are not actually checked during open, resulting in
> > > > > (obscure) security hole: if you have fd open for reading, you can
> > > > > reopen it for write, even through unix permissions would not allow
> > > > > that.
> > > > > 
> > > > > Now... I'd like to close the hole. One way would be to actually check
> > > > > symlink permissions on open -- because those symlinks already have
> > > > > correct permissions.
> > > >   Hmm, I'm not sure I understand the problem. Symlink is just a file
> > > > containing a path. So if you try to open a symlink, you will actually open
> > > > a file to which the path points. So what security problem is here? Either
> > > > you can open the file symlink points to for writing or you cannot...
> > > >   Anyway, if you want to play with this,
> > > > fs/proc/base.c:proc_pid_follow_link
> > > >   is probably the function you are interested in.
> > > 
> > > The problem he's trying to address is that users may try to protect
> > > a file by doing chmod 700 on the parent dir, but leave the file itself
> > > accessible.  They don't realize that merely having a task with an open
> > > fd to that file gives other users another path to the file.
> > > 
> > > Whether or not that's actually a problem is open to debate, but I think
> > > he's right that many users aren't aware of it.
> > 
> > If /proc/self/fd/23 is a symlink to /home/me/privatedir/secret, then an
> > open("proc/self/fd/23",...) still traverses the whole /home/.../secret
> > path, and needs appropriate permissions at each step, doesn't it?
> > 
> > Probably I'm just terminally confused....
>   That's what I'd think as well but it does not as I've just learned and
> tested :) proc_pid_follow_link actually directly gives a dentry of the
> target file without checking permissions on the way.

Got it, thanks.--b.

Re: symlinks with permissions

[Trond Myklebust]

On Sun, 2009-10-25 at 10:36 +0100, Pavel Machek wrote:
> Well, it is unexpected and mild security hole.
> 
> Part of the problem is that even  if you have read-only
> filedescriptor, you can upgrade it to read-write, even if path is
> inaccessible to you.
> 
> So if someone passes you read-only filedescriptor, you can still write
> to it.
> 									Pavel

If someone passes you a file descriptor, can't you in any case play
games with, openat(fd,"",O_RDWR), in order to achieve the same thing? I
must admit I haven't tried it yet, but at a first glance I can't see
anything that prevents me from doing this...

Cheers
  Trond

Re: symlinks with permissions

[J. Bruce Fields]

On Sun, Oct 25, 2009 at 10:36:04AM +0100, Pavel Machek wrote:
> On Mon 2009-10-26 13:57:49, Trond Myklebust wrote:
> > On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
> > >   That's what I'd think as well but it does not as I've just learned and
> > > tested :) proc_pid_follow_link actually directly gives a dentry of the
> > > target file without checking permissions on the way.
> 
> It is weider. That symlink even has permissions. Those are not
> checked, either.
>  
> > I seem to remember that is deliberate, the point being that a symlink
> > in /proc/*/fd/ may contain a path that refers to a private namespace.
> 
> Well, it is unexpected and mild security hole.
> 
> Part of the problem is that even  if you have read-only
> filedescriptor, you can upgrade it to read-write, even if path is
> inaccessible to you.
> 
> So if someone passes you read-only filedescriptor, you can still write
> to it.

By the way, nfs-exporting a filesystem also allows bypassing lookup
permissions: anyone on the network can access an inode directly (using
an nfs filehandle) without necessarily traversing any path to that
inode.  (Assuming they can guess the filehandle--probably doable in most
cases.)

Not arguing for or against, just another data point.

--b.

Re: symlinks with permissions

[Pavel Machek]

On Mon 2009-10-26 14:22:16, Trond Myklebust wrote:
> On Sun, 2009-10-25 at 10:36 +0100, Pavel Machek wrote:
> > Well, it is unexpected and mild security hole.
> > 
> > Part of the problem is that even  if you have read-only
> > filedescriptor, you can upgrade it to read-write, even if path is
> > inaccessible to you.
> > 
> > So if someone passes you read-only filedescriptor, you can still write
> > to it.
> 
> If someone passes you a file descriptor, can't you in any case play
> games with, openat(fd,"",O_RDWR), in order to achieve the same thing? I
> must admit I haven't tried it yet, but at a first glance I can't see
> anything that prevents me from doing this...

According to my documentation, openat needs directory fd.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Jamie Lokier]

Pavel Machek wrote:
> On Mon 2009-10-26 14:22:16, Trond Myklebust wrote:
> > On Sun, 2009-10-25 at 10:36 +0100, Pavel Machek wrote:
> > > Well, it is unexpected and mild security hole.
> > > 
> > > Part of the problem is that even  if you have read-only
> > > filedescriptor, you can upgrade it to read-write, even if path is
> > > inaccessible to you.
> > > 
> > > So if someone passes you read-only filedescriptor, you can still write
> > > to it.
> > 
> > If someone passes you a file descriptor, can't you in any case play
> > games with, openat(fd,"",O_RDWR), in order to achieve the same thing? I
> > must admit I haven't tried it yet, but at a first glance I can't see
> > anything that prevents me from doing this...
> 
> According to my documentation, openat needs directory fd.

Correct.  There has been something about fstatat() and similar
allowing a non-directory when passed a NULL path, but openat() does
not.  (It's probably ok to extend openat() to allow a NULL path, if it
does the equivalent of re-opening /proc/self/fd/NN).

I think this whole issue is neatly solved by enforcing the file access
mode for open(/proc/PID/fd/NN) to be a safe subset of the original
file access mode.

It should use the original file access mode so that O_APPEND can
be enforced too.  Checking symlink permissions wouldn't do that.

Anything you can change with fcntl(F_SETFL) is fair game for changing.

The ptrace permission check is nice, but even with ptrace you can't
convert a read-only descriptor to a writable one (or write-only to
readable, or append-only to writable, etc.)

-- Jamie

Re: symlinks with permissions

[Eric W. Biederman]

Pavel Machek <pavel@ucw.cz> writes:

> On Mon 2009-10-26 13:57:49, Trond Myklebust wrote:
>> On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
>> >   That's what I'd think as well but it does not as I've just learned and
>> > tested :) proc_pid_follow_link actually directly gives a dentry of the
>> > target file without checking permissions on the way.
>
> It is weider. That symlink even has permissions. Those are not
> checked, either.
>  
>> I seem to remember that is deliberate, the point being that a symlink
>> in /proc/*/fd/ may contain a path that refers to a private namespace.
>
> Well, it is unexpected and mild security hole.

/proc/<pid>/fd is only viewable by the owner of the process or by
someone with CAP_DAC_OVERRIDE.  So there appears to be no security
hole exploitable by people who don't have the file open.

> Part of the problem is that even  if you have read-only
> filedescriptor, you can upgrade it to read-write, even if path is
> inaccessible to you.
>
> So if someone passes you read-only filedescriptor, you can still write
> to it.

Openly if you actually have permission to open the file again.  The actual
permissions on the file should not be ignored.

Eric

Re: symlinks with permissions

[Pavel Machek]

On Tue 2009-10-27 21:15:54, Eric W. Biederman wrote:
> Pavel Machek <pavel@ucw.cz> writes:
> 
> > On Mon 2009-10-26 13:57:49, Trond Myklebust wrote:
> >> On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
> >> >   That's what I'd think as well but it does not as I've just learned and
> >> > tested :) proc_pid_follow_link actually directly gives a dentry of the
> >> > target file without checking permissions on the way.
> >
> > It is weider. That symlink even has permissions. Those are not
> > checked, either.
> >  
> >> I seem to remember that is deliberate, the point being that a symlink
> >> in /proc/*/fd/ may contain a path that refers to a private namespace.
> >
> > Well, it is unexpected and mild security hole.
> 
> /proc/<pid>/fd is only viewable by the owner of the process or by
> someone with CAP_DAC_OVERRIDE.  So there appears to be no security
> hole exploitable by people who don't have the file open.

Please see bugtraq discussion at
http://seclists.org/bugtraq/2009/Oct/179 .

(In short, you get read-only fd, and you can upgrade it to read-write
fd. Yes, you are the owner of the process, but you are not owner of
the file the fd refers to.)

> > Part of the problem is that even  if you have read-only
> > filedescriptor, you can upgrade it to read-write, even if path is
> > inaccessible to you.
> >
> > So if someone passes you read-only filedescriptor, you can still write
> > to it.
> 
> Openly if you actually have permission to open the file again.  The actual
> permissions on the file should not be ignored.

The actual permissions of the file are not ignored, but permissions of
the containing directory _are_. If there's 666 file in 700 directory,
you can reopen it read-write, in violation of directory's 700
permissions.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Eric W. Biederman]

Pavel Machek <pavel@ucw.cz> writes:

> On Tue 2009-10-27 21:15:54, Eric W. Biederman wrote:
>> Pavel Machek <pavel@ucw.cz> writes:
>> 
>> > On Mon 2009-10-26 13:57:49, Trond Myklebust wrote:
>> >> On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
>> >> >   That's what I'd think as well but it does not as I've just learned and
>> >> > tested :) proc_pid_follow_link actually directly gives a dentry of the
>> >> > target file without checking permissions on the way.
>> >
>> > It is weider. That symlink even has permissions. Those are not
>> > checked, either.
>> >  
>> >> I seem to remember that is deliberate, the point being that a symlink
>> >> in /proc/*/fd/ may contain a path that refers to a private namespace.
>> >
>> > Well, it is unexpected and mild security hole.
>> 
>> /proc/<pid>/fd is only viewable by the owner of the process or by
>> someone with CAP_DAC_OVERRIDE.  So there appears to be no security
>> hole exploitable by people who don't have the file open.
>
> Please see bugtraq discussion at
> http://seclists.org/bugtraq/2009/Oct/179 .
>
> (In short, you get read-only fd, and you can upgrade it to read-write
> fd. Yes, you are the owner of the process, but you are not owner of
> the file the fd refers to.)

Assuming you have permission to open it read-write.

>> > Part of the problem is that even  if you have read-only
>> > filedescriptor, you can upgrade it to read-write, even if path is
>> > inaccessible to you.
>> >
>> > So if someone passes you read-only filedescriptor, you can still write
>> > to it.
>> 
>> Openly if you actually have permission to open the file again.  The actual
>> permissions on the file should not be ignored.
>
> The actual permissions of the file are not ignored, but permissions of
> the containing directory _are_. If there's 666 file in 700 directory,
> you can reopen it read-write, in violation of directory's 700
> permissions.

I can see how all of this can come as a surprise.  However I don't see
how any coder who is taking security seriously and being paranoid about
security would actually write code that would have a problem with this.

Do you know of any cases where this difference matters in practice?

It looks to me like it has been this way for better than a decade
without problems so there is no point in changing it now.  

Eric

Re: symlinks with permissions

[Casey Schaufler]

Pavel Machek wrote:
> On Tue 2009-10-27 21:15:54, Eric W. Biederman wrote:
>   
>> Pavel Machek <pavel@ucw.cz> writes:
>>
>>     
>>> On Mon 2009-10-26 13:57:49, Trond Myklebust wrote:
>>>       
>>>> On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
>>>>         
>>>>>   That's what I'd think as well but it does not as I've just learned and
>>>>> tested :) proc_pid_follow_link actually directly gives a dentry of the
>>>>> target file without checking permissions on the way.
>>>>>           
>>> It is weider. That symlink even has permissions. Those are not
>>> checked, either.
>>>  
>>>       
>>>> I seem to remember that is deliberate, the point being that a symlink
>>>> in /proc/*/fd/ may contain a path that refers to a private namespace.
>>>>         
>>> Well, it is unexpected and mild security hole.
>>>       
>> /proc/<pid>/fd is only viewable by the owner of the process or by
>> someone with CAP_DAC_OVERRIDE.  So there appears to be no security
>> hole exploitable by people who don't have the file open.
>>     
>
> Please see bugtraq discussion at
> http://seclists.org/bugtraq/2009/Oct/179 .
>
> (In short, you get read-only fd, and you can upgrade it to read-write
> fd. Yes, you are the owner of the process, but you are not owner of
> the file the fd refers to.)
>
>   
>>> Part of the problem is that even  if you have read-only
>>> filedescriptor, you can upgrade it to read-write, even if path is
>>> inaccessible to you.
>>>
>>> So if someone passes you read-only filedescriptor, you can still write
>>> to it.
>>>       
>> Openly if you actually have permission to open the file again.  The actual
>> permissions on the file should not be ignored.
>>     
>
> The actual permissions of the file are not ignored, but permissions of
> the containing directory _are_. If there's 666 file in 700 directory,
> you can reopen it read-write, in violation of directory's 700
> permissions.
> 									Pavel
>   

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? Or what about the case where the file
has a link count of 2, say /a/foo and /b/ish are hard links. If
/a is 777 and /b is 700 what would your position be regarding
the file descriptor obtained by opening /b/ish? The path name is
an ethereal convenience and once traversed has no bearing on the
security state of the object. You need to change the semantics
of Linux (and Unix) file systems for your concern to make any
sense at all.

Re: symlinks with permissions

[Jamie Lokier]

Casey Schaufler wrote:
> Pavel Machek wrote:
> > The actual permissions of the file are not ignored, but permissions of
> > the containing directory _are_. If there's 666 file in 700 directory,
> > you can reopen it read-write, in violation of directory's 700
> > permissions.
> > 									Pavel
> 
> 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?

That's an even worse security violation.

If you have a file opened read-only which is unlinked (and there's no
other file descriptors to it), it is impossible to modify the file
except through this quirk of /proc/NN/fd.  In traditional unix, it is
impossible to modify full stop.  Even root can't write to it.

Paths are in this discussion as an *example* of something that cannot
be done except through /proc/NN/fd.  Paths are not the issue.

As you've noticed, the same security hole occurs for files which have
been unlinked and don't have any path.

The real issue is gaining more access to an open file than you had before.

> Or what about the case where the file
> has a link count of 2, say /a/foo and /b/ish are hard links. If
> /a is 777 and /b is 700 what would your position be regarding
> the file descriptor obtained by opening /b/ish?

It depends on the flag passed to open() when the file descriptor is
obtained.  That's where the pseudo-symlink permission comes from,
which is what Pavel is getting it.

> The path name is an ethereal convenience and once traversed has no
> bearing on the security state of the object.

That's right.  The security state should depend _only_ on the
file open mode, that is O_RDONLY/WRONLY/RDWR/APPEND.

That is more or less what Pavel is saying too, because the
pseudo-symlink permission is calculated from the file open mode
(except for O_APPEND, which is why it shouldn't be done using the
pseudo-symlink permission).  Ignore the path aspect, it's just a distraction.

-- Jamie

Re: symlinks with permissions

[Pavel Machek]

Hi!

> >> > Well, it is unexpected and mild security hole.
> >> 
> >> /proc/<pid>/fd is only viewable by the owner of the process or by
> >> someone with CAP_DAC_OVERRIDE.  So there appears to be no security
> >> hole exploitable by people who don't have the file open.
> >
> > Please see bugtraq discussion at
> > http://seclists.org/bugtraq/2009/Oct/179 .
> >
> > (In short, you get read-only fd, and you can upgrade it to read-write
> > fd. Yes, you are the owner of the process, but you are not owner of
> > the file the fd refers to.)
> 
> Assuming you have permission to open it read-write.

Please see the bugtraq discussion.

It works even if you would not have permission to write to it with
/proc unmounted.

> >> Openly if you actually have permission to open the file again.  The actual
> >> permissions on the file should not be ignored.
> >
> > The actual permissions of the file are not ignored, but permissions of
> > the containing directory _are_. If there's 666 file in 700 directory,
> > you can reopen it read-write, in violation of directory's 700
> > permissions.
> 
> I can see how all of this can come as a surprise.  However I don't see
> how any coder who is taking security seriously and being paranoid about
> security would actually write code that would have a problem with
> this.

So, there's "surprise" that gives _you_ write access to my files. You
agree that it is surprising, and you would not have write access to my
file if /proc was not mounted.

Call it "security surprise" if you prefer. But many people call it
"security hole".

> Do you know of any cases where this difference matters in practice?

No. Do you have a proof that it does not matter anywhere?

> It looks to me like it has been this way for better than a decade
> without problems so there is no point in changing it now.  

Unix compatibility?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Pavel Machek]

> > Please see bugtraq discussion at
> > http://seclists.org/bugtraq/2009/Oct/179 .
> >
> > (In short, you get read-only fd, and you can upgrade it to read-write
> > fd. Yes, you are the owner of the process, but you are not owner of
> > the file the fd refers to.)
> >
> > The actual permissions of the file are not ignored, but permissions of
> > the containing directory _are_. If there's 666 file in 700 directory,
> > you can reopen it read-write, in violation of directory's 700
> > permissions.

> 
> There is no security violation here. Consider the case where

You are able to write to my files, when unix permissions forbid
that. How do you call that? Strange behaviour of /proc/*/fd/ symlink
that is not really a symlink allows that.

See bugtraq discussion at http://seclists.org/bugtraq/2009/Oct/179 .
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Eric W. Biederman]

Pavel Machek <pavel@ucw.cz> writes:

> Hi!
>
>> >> > Well, it is unexpected and mild security hole.
>> >> 
>> >> /proc/<pid>/fd is only viewable by the owner of the process or by
>> >> someone with CAP_DAC_OVERRIDE.  So there appears to be no security
>> >> hole exploitable by people who don't have the file open.
>> >
>> > Please see bugtraq discussion at
>> > http://seclists.org/bugtraq/2009/Oct/179 .
>> >
>> > (In short, you get read-only fd, and you can upgrade it to read-write
>> > fd. Yes, you are the owner of the process, but you are not owner of
>> > the file the fd refers to.)
>> 
>> Assuming you have permission to open it read-write.
>
> Please see the bugtraq discussion.
>
> It works even if you would not have permission to write to it with
> /proc unmounted.
>
>> >> Openly if you actually have permission to open the file again.  The actual
>> >> permissions on the file should not be ignored.
>> >
>> > The actual permissions of the file are not ignored, but permissions of
>> > the containing directory _are_. If there's 666 file in 700 directory,
>> > you can reopen it read-write, in violation of directory's 700
>> > permissions.
>> 
>> I can see how all of this can come as a surprise.  However I don't see
>> how any coder who is taking security seriously and being paranoid about
>> security would actually write code that would have a problem with
>> this.
>
> So, there's "surprise" that gives _you_ write access to my files. You
> agree that it is surprising, and you would not have write access to my
> file if /proc was not mounted.

I also find it a surprise you would ever make a file world writable.

I find it a surprise that in any application that cared you would allow the
file to be opened, or passed through a unix domain socket and then have
the permissions changed.

> Call it "security surprise" if you prefer. But many people call it
> "security hole".
>
>> Do you know of any cases where this difference matters in practice?
>
> No. Do you have a proof that it does not matter anywhere?
>
>> It looks to me like it has been this way for better than a decade
>> without problems so there is no point in changing it now.  
>
> Unix compatibility?

Thinking about this proc fundamentally gives you the ability to create
(via open) a new file descriptor for a file you already have open.

That is the design and things are working by design.

I do see a security issue in your example, but the security issue I
see is how you have chosen to use the linux facilities, that have been
there for ages.  Facilities cloned from plan 9 and apparently
available in slightly different forms on many unix variants existence.
/dev/fd/N is not a linuxism.

To close this whole would require some sort of stacking inode that
when opened opened the real fs inode.  With all kinds of convolutions
and complications.  Just to close the issue that some idiot might
give someone a fd to a world writeable file that they don't want
them to open.

Given this is an old well established facility with a long tradition,
that does not appear to be easy or simple to exploit.  I believe the burden
of proof has not been met to say the design has a security issue.

I certainly am not interested in debugging or maintaining the stacking
inode code that would be necessary to close this theoretical corner
case.  There are much more real bugs that need attention.

Eric

Re: symlinks with permissions

[Pavel Machek]

Hi!

> >> It looks to me like it has been this way for better than a decade
> >> without problems so there is no point in changing it now.  
> >
> > Unix compatibility?
> 
> Thinking about this proc fundamentally gives you the ability to create
> (via open) a new file descriptor for a file you already have open.

Yes. Problem is that by using /proc, I can work-around open(READONLY)
restriction and work-around open(APPEND_ONLY) restriction.

> I do see a security issue in your example, but the security issue I
> see is how you have chosen to use the linux facilities, that have been
> there for ages.  Facilities cloned from plan 9 and apparently
> available in slightly different forms on many unix variants existence.
> /dev/fd/N is not a linuxism.
> 
> To close this whole would require some sort of stacking inode that
> when opened opened the real fs inode.  With all kinds of convolutions
> and complications.  Just to close the issue that some idiot might
> give someone a fd to a world writeable file that they don't want
> them to open.

Ok, so you agree issue is there. Good.

Now, fix for READONLY issue should be fairly simple: follow link in
/proc/*/fd/* should check the link permissions,  and return
read-only/write-only descriptors as neccessary.

Basically, that follow link should behave as dup(), not as open().

> I certainly am not interested in debugging or maintaining the stacking
> inode code that would be necessary to close this theoretical corner
> case.  There are much more real bugs that need attention.

But if we can get trivial 10-liner, that should be acceptable, right?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Eric W. Biederman]

Pavel Machek <pavel@ucw.cz> writes:

> Hi!
>
>> >> It looks to me like it has been this way for better than a decade
>> >> without problems so there is no point in changing it now.  
>> >
>> > Unix compatibility?
>> 
>> Thinking about this proc fundamentally gives you the ability to create
>> (via open) a new file descriptor for a file you already have open.
>
> Yes. Problem is that by using /proc, I can work-around open(READONLY)
> restriction and work-around open(APPEND_ONLY) restriction.

If you are allowed to do that simply opening the inode.

I can also use a bind mount on the file before you lock down
permissions instead of proc in your example to achieve the same
affect.  An extra path to an inode.

In general there is not a way to lock down the path to a file to a
more restrictive set of permissions after it has been opened.  Not
until sys_revoke or similar syscall has been implemented.  Even then I
am a bit dubious.

>> I do see a security issue in your example, but the security issue I
>> see is how you have chosen to use the linux facilities, that have been
>> there for ages.  Facilities cloned from plan 9 and apparently
>> available in slightly different forms on many unix variants existence.
>> /dev/fd/N is not a linuxism.
>> 
>> To close this whole would require some sort of stacking inode that
>> when opened opened the real fs inode.  With all kinds of convolutions
>> and complications.  Just to close the issue that some idiot might
>> give someone a fd to a world writeable file that they don't want
>> them to open.
>
> Ok, so you agree issue is there. Good.

I don't agree that the kernel has a problem.  I agree that there
is a security hole in your example.

I don't believe you can rely on the directory permissions in the general
case to control access to a file.

> Now, fix for READONLY issue should be fairly simple: follow link in
> /proc/*/fd/* should check the link permissions,  and return
> read-only/write-only descriptors as neccessary.

The follow_link is just a follow link.  Either we add an extra path
to the fd or we don't.  Follow link doesn't know it is being used for open.

That isn't completely correct.  You might be able to look at the
intent and if it is LOOKUP_OPEN and the open mode is compatible return
the original file descriptor.  Even if you do that and the kernel is
guaranteed to take that path in all examples that still leaves an
extra path for syscalls that don't require a filedesciptor to use.

> Basically, that follow link should behave as dup(), not as open().

There are reasons why an open is an open here.  I don't remember the
details but I found the archive of that conversation once.  Maybe it was
just technical limitations of the time.

>> I certainly am not interested in debugging or maintaining the stacking
>> inode code that would be necessary to close this theoretical corner
>> case.  There are much more real bugs that need attention.
>
> But if we can get trivial 10-liner, that should be acceptable, right?

How many linux shell scripts and other applications that use /dev/fd/N
or /proc/self/fd/N will you be breaking?

Closing a theoretical security hole at the expense of breaking real
applications is a show stopper.

Feel free to play and test but I'm still not buying it.

Eric

Re: symlinks with permissions

[Pavel Machek]

Hi!

> > Basically, that follow link should behave as dup(), not as open().
> 
> There are reasons why an open is an open here.  I don't remember the
> details but I found the archive of that conversation once.  Maybe it was
> just technical limitations of the time.

That would be really really useful to bring 

> >> I certainly am not interested in debugging or maintaining the stacking
> >> inode code that would be necessary to close this theoretical corner
> >> case.  There are much more real bugs that need attention.
> >
> > But if we can get trivial 10-liner, that should be acceptable, right?
> 
> How many linux shell scripts and other applications that use /dev/fd/N
> or /proc/self/fd/N will you be breaking?

Zero. (Well unless someone is exploiting it in wild).

> Closing a theoretical security hole at the expense of breaking real
> applications is a show stopper.

I don't plan to remove /proc/*/fd; but I would like it to behave like
dup().

(I still hope some security team does work for me :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions

[Nick Bowler]

On 19:35 Fri 30 Oct     , Pavel Machek wrote:
> > How many linux shell scripts and other applications that use /dev/fd/N
> > or /proc/self/fd/N will you be breaking?
> 
> Zero. (Well unless someone is exploiting it in wild).

I've definitely written at least one script before that does something
along the lines of 'echo foo > /dev/fd/N'.  It's not one that I remember
anything else about, so perhaps its behaviour would be unaffected by
forbidding this if the particular file descriptor did not originally
have read-write permissions.  I have a hard time believing that amongst
millions of users, not one of them has a script that would be affected.

Frankly, I don't understand what is particularly surprising about the
fact that people can write to files with world write permissions.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: symlinks with permissions

[Eric W. Biederman]

Pavel Machek <pavel@ucw.cz> writes:

>> >> I certainly am not interested in debugging or maintaining the stacking
>> >> inode code that would be necessary to close this theoretical corner
>> >> case.  There are much more real bugs that need attention.
>> >
>> > But if we can get trivial 10-liner, that should be acceptable, right?
>> 
>> How many linux shell scripts and other applications that use /dev/fd/N
>> or /proc/self/fd/N will you be breaking?
>
> Zero. (Well unless someone is exploiting it in wild).

There are other differences like different offsets etc that may matter.

>> Closing a theoretical security hole at the expense of breaking real
>> applications is a show stopper.
>
> I don't plan to remove /proc/*/fd; but I would like it to behave like
> dup().
>
> (I still hope some security team does work for me :-).

Seriously turning this into dup is about 20 lines of code in follow
link.  Just look at the open intent in the nameidata.  nfs should
have an exampled of using the open intent somewhere.

I bet you will get a lot more traction and discussion if you write
a basic mostly working version of the patch.

Eric

Re: symlinks with permissions

[Jamie Lokier]

Eric W. Biederman wrote:
> Pavel Machek <pavel@ucw.cz> writes:
> >> How many linux shell scripts and other applications that use /dev/fd/N
> >> or /proc/self/fd/N will you be breaking?
> >
> > Zero. (Well unless someone is exploiting it in wild).
> 
> There are other differences like different offsets etc that may matter.
> 
> >> Closing a theoretical security hole at the expense of breaking real
> >> applications is a show stopper.
> >
> > I don't plan to remove /proc/*/fd; but I would like it to behave like
> > dup().
> >
> > (I still hope some security team does work for me :-).

Yes, it must not be like dup(), sharing the file pointer, because I'm
sure that really will break some programs.

Like all the ones using gnulib (formerly libiberty) which use
/proc/self/fd/N/path/to/file to implement fake openat(N,"path/to/file").

> I bet you will get a lot more traction and discussion if you write
> a basic mostly working version of the patch.

I agree, and I'll be happy to review/break it ;-)

-- Jamie