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
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, th
Hi!
> 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 i
Jim Paris wrote:
>
> > Therefor it's totally of no influence what you do with the original
> > directory permission. File access has nothing to do with directory
> > permissions...!
>
> Right. However the whole point of this discussion is that that is a
> non-obvious point, there was no other wa
On Mon 2009-11-02 18:53:19, Martin Rex wrote:
> Jim Paris wrote:
> >
> > > Therefor it's totally of no influence what you do with the original
> > > directory permission. File access has nothing to do with directory
> > > permissions...!
> >
> > Right. However the whole point of this discussion
On Mon, Nov 02, 2009 at 08:53:26PM +0100, Pavel Machek wrote:
> > The link count of a files tells you the number of hard links that
> > are persisted within the same filesystem. It is _NOT_ a promise
> > that there are no other means to access the inode of the file.
>
> It used to be promise bef
Gabor Gombas wrote:
>
> On Mon, Nov 02, 2009 at 08:53:26PM +0100, Pavel Machek wrote:
>
> > > The link count of a files tells you the number of hard links that
> > > are persisted within the same filesystem. It is _NOT_ a promise
> > > that there are no other means to access the inode of the fil
On Tue, Nov 03, 2009 at 12:33:28AM +0100, Martin Rex wrote:
> > "mount --bind" behaves like a hard link and it does not increment the link
> > count.
>
> that seems to work similar to a hardlink on a directory (and also requires
> root privileges). It doesn't work for the same directory level, b
On 03.11.2009 2:33, Martin Rex wrote:
Doing it for a socket might be a bad idea -- and usually impossible,
one cannot undo the shutdown(SHUT_WR) of a socket...
Nobody will ever need that, since sockets are bidirectional and their file
descriptors are in fact both readable and writable. But chan
On Wed 2009-11-04 09:06:25, Gabor Gombas wrote:
> On Wed, Nov 04, 2009 at 10:17:13AM +1100, p...@maths.usyd.edu.au wrote:
>
> > But, mount requires root (and root can do anything, including shooting
> > himself in the foot).
>
> Irrelevant. The statement was that if /proc is not mounted, then the
On Wed 2009-11-04 09:06:25, Gabor Gombas wrote:
> On Wed, Nov 04, 2009 at 10:17:13AM +1100, p...@maths.usyd.edu.au wrote:
>
> > But, mount requires root (and root can do anything, including shooting
> > himself in the foot).
>
> Irrelevant. The statement was that if /proc is not mounted, then the
> Irrelevant. The statement was ...
Sorry, you misunderstood, that was not the statement.
The statement was that with /proc you can "do" things you shouldn't.
We have seen what those things are. Sadly(?) so far none seem very
dangerous, or common, or conducive to mayhem: no urgency to fix.
Chee
On Wed, Nov 04, 2009 at 10:17:13AM +1100, p...@maths.usyd.edu.au wrote:
> But, mount requires root (and root can do anything, including shooting
> himself in the foot).
Irrelevant. The statement was that if /proc is not mounted, then the
link count tells if there are other ways to access the inod
>>> "mount --bind" behaves like a hard link and it does not increment the link
>>> count.
>
> # touch /tmp/a
> # mount --bind /etc/passwd /tmp/a
> # ls -l /etc/passwd
> -rw-r--r-- 1 root root 1990 2009-08-24 16:22 /etc/passwd
> ...
> Two references to the same inode, yet the link count is 1 and /pr
On Wed, Nov 04, 2009 at 09:15:31PM +1100, p...@maths.usyd.edu.au wrote:
> > Irrelevant. The statement was ...
>
> Sorry, you misunderstood, that was not the statement.
Here is the statement I replied to:
>> The link count of a files tells you the number of hard links that
>> are persisted within
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 wor
> >pa...@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?
> >pa...@toy:/tmp/my_priv$ chmod 666 unwritable_file
> >p
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
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
-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 h
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 Linu
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 06
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
On 24.10.2009 1:56, Pavel Machek wrote:
Now... go back to my original email:
%pa...@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 permissio
> >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 c
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 co
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 th
Pavel Machek wrote:
So what did happen? User guest was able to work around directory
permissions in the background, using /proc filesystem.
gu...@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 thi
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 exp
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
permissio
On Mon 2009-10-26 13:42:17, Dan Yefimov wrote:
> On 25.10.2009 2:40, p...@maths.usyd.edu.au wrote:
> >Dear Pavel,
> >
> >>... that's exactly the problem.
> >
> >I see, the /proc/*/fd/* objects seem "confused": are they symlinks,
> >hardlinks, or open file descriptors? I guess should always act as
>
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc//fd/ are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
"act" as hardlin
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, t
On Sun, 25 Oct 2009, Pavel Kankovsky wrote:
> pavel might have detected this attack if he checked the number of
> hardlinks on "unwritable_file" between the chmod's. But he did not
> check that.
I stand corrected. He did it--in a comment:
> # check link count on unwritable_file. We would not wa
[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
Dear Dan,
> ... in authentic kernels /proc//fd/ are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
"act" as hardlinks. Could that be fixed somehow? (I did look at the
kernel fs/proc/base.c but did not make much sense to me...)
BTW: did you notice how bugtraq
On 24.10.2009 20:59, Anton Ivanov wrote:
Not to tell about
that /proc//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 c
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//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
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
> On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
> >Dear Dan,
> >
> >>... in authentic kernels /proc//fd/ are symlinks ...
> >
> >They appear to /bin/ls as symlinks, but observation suggests that they
> >"act" as hardlinks. Could that be fixed som
On 24.10.2009 22:05, Anton Ivanov wrote:
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 permiss
On Sat 2009-10-24 10:47:38, p...@maths.usyd.edu.au wrote:
> 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:
>
>
> >
> > Not that I would have expected anything different considering who posted
> > it in the first place.
> >
> Thus Debian kernel team should be blamed for that misbehaviour. Don't worry,
> hardlinks behave just the same way, as you describe. Use authentic Linux
> kernels, if you dislike that
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc//fd/ are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
"act" as hardlinks. Could that be fixed somehow? (I did look at the
kernel fs/proc/base.c but did not make
Dear Pavel,
> ... that's exactly the problem.
I see, the /proc/*/fd/* objects seem "confused": are they symlinks,
hardlinks, or open file descriptors? I guess should always act as
the latter, where access mode flags (O_RDONLY or O_RDWR) are set at
open() and not changeable afterwards in fcntl().
Consider this scenario, pavel's actions are the same as in yours:
pavel & guest: cd /tmp
pavel: mkdir my_priv; cd my_priv
pavel: echo this file should never be writable > unwritable_file
guest: mkdir pirate_chest
guest: ln my_priv/unwritable_file pirate_chest
pavel: chmod 700 .
pavel: chmod 666 un
On 25.10.2009 2:40, p...@maths.usyd.edu.au wrote:
Dear Pavel,
... that's exactly the problem.
I see, the /proc/*/fd/* objects seem "confused": are they symlinks,
hardlinks, or open file descriptors? I guess should always act as
the latter, where access mode flags (O_RDONLY or O_RDWR) are set
On Mon 2009-10-26 18:11:56, Dan Yefimov wrote:
> On 26.10.2009 18:06, Pavel Machek wrote:
> >On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
> >>On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
> >>>Dear Dan,
> >>>
> ... in authentic kernels /proc//fd/ are symlinks ...
> >>>
> >>>They appear
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 t
On Sat, Oct 24, 2009 at 02:31:47AM +0400, Dan Yefimov wrote:
> On 24.10.2009 1:56, Pavel Machek wrote:
> >a) this kind of hardlink does not exist when /proc is mounted (and on
> >non-Linux)
> >(and c) writing to file descriptor opened read-only is bad).
> Did you think of creating a hardlink to
On 26.10.2009 18:30, casper@sun.com wrote:
In Solaris, you don't have permission to access a file in /proc//fd unless
you can control the process.
$ ls -l /proc/1/fd
/proc/1/fd: Permission denied
If you can control, then clearly you have access the file anyway
simply by controlling it using
On 26.10.2009 18:26, Pavel Machek wrote:
On Mon 2009-10-26 18:11:56, Dan Yefimov wrote:
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc//fd/are symlinks ..
> >>>guest certianly does not have permission to ptrace() pavel's
> >>>processes, so...
> >>
> >>But guest has permissions to ptrace() his own processes. If we
> >>remember your original report, he abuses input redirection of bash
> >>run by himself. So again, there's no real security hole here.
>
Pavel Machek wrote:
>
>pa...@toy:/tmp$ uname -a
>Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel
>GNU/Linux
>pa...@toy:/tmp mkdir my_priv; cd my_priv
Attacker opens my_priv and waits.
>pa...@toy:/tmp/my_priv$ echo this file should never be writable >
>unwritable_file
>#
On 26.10.2009 18:58, Pavel Machek wrote:
guest certianly does not have permission to ptrace() pavel's
processes, so...
But guest has permissions to ptrace() his own processes. If we
remember your original report, he abuses input redirection of bash
run by himself. So again, there's no real secu
On Friday 23 October 2009 23:39:24 Pavel Machek wrote:
> Check it again. There's no race; I check link count before chmod 666.
And between checking the link count and the chmod?
signature.asc
Description: This is a digitally signed message part.
Am Samstag, den 24.10.2009, 01:12 +0400 schrieb 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
On Oct 23, 2009, at 3:56 PM, Pavel Machek wrote:
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.
If the directory is mounted via NFS or is ex
On 2009-10-24 Derek Martin wrote:
> 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.
Wrong, because the file's attributes aren't stored in the directory, but
in the respective inode.
Regards
Ansgar Wieche
Dan Yefimov said:
>> 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 lik
> -Original Message-
> From: nom...@nomail.com [mailto:nom...@nomail.com]
> Sent: Monday, October 26, 2009 9:15 AM
> To: bugtraq@securityfocus.com
> Subject: Re: Re: /proc filesystem allows bypassing directory
> permissions on Linux
>
> >> I do not think mount
On 26.10.2009 18:14, nom...@nomail.com wrote:
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?
Do your homework and test it. You can't create
Pavel Machek wrote:
> Check it again. There's no race; I check link count before chmod 666.
Which creates a race condition, as the link could be created after the
check but before the chmod.
You can't safely rely upon directory permissions if the directory was
created 0777 then chmod'ed down l
Dear Casper and Dan,
> If you can control, then clearly you have access the file anyway
> simply by controlling it using a debugger.
Sorry, but no. The "attacker" has the file opened O_RDONLY, and cannot
"upgrade" that to O_RDWR.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.mat
On Mon, Oct 26, 2009 at 9:01 AM, Tony Finch wrote:
> Attacker uses openat() to open and modify the "private" file.
At least with Linux 2.6.18, you still need +x permission on the
directory to access its contents using openat(2).
Tony Finch wrote:
> Attacker opens [directory] and waits. ...
> Attacker uses openat() to open and modify the "private" file.
Surely if the permissions do not allow lookup then openat() will fail.
[The attacker opened directory when it was searcheable; then permissions
were closed; then attacker
On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
> and testing them. Remember the scenario from the original mail and try
> finding a window, during which creating a hardlink would still work thus
> evading directory permissions check.
The main thing this does is allow a hardlink-lik
On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to 0666
|| User1 verifies no hard links to file
||
On Mon, 26 Oct 2009, Matthew Dempsky wrote:
> On Mon, Oct 26, 2009 at 9:01 AM, Tony Finch wrote:
> >
> > Attacker uses openat() to open and modify the "private" file.
>
> At least with Linux 2.6.18, you still need +x permission on the
> directory to access its contents using openat(2).
According
Marco Verschuur wrote:
> And due to the actual file permissions the read-only fd can easily
> changed to read-write.
How would you do that? Cannot use fcntl() as that would not let you.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathemati
Hi!
> >pa...@toy:/tmp$ uname -a
> >Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel
> >GNU/Linux
> >pa...@toy:/tmp mkdir my_priv; cd my_priv
>
> Attacker opens my_priv and waits.
...
> >pa...@toy:/tmp/my_priv$ cat unwritable_file
> >this file should never be writable
>
>
Why not?!?
File permissions allow everybody write access to the file.
The path via /proc to the file has been created when the initial path
via /tmp was wide open.
Closing the initial path via /tmp has no effect on the /proc path
And due to the actual file permissions the read-only fd can eas
On Mon 2009-10-26 16:05:18, Tamber Penketh wrote:
> On Friday 23 October 2009 23:39:24 Pavel Machek wrote:
>
> > Check it again. There's no race; I check link count before chmod 666.
> And between checking the link count and the chmod?
At that point directory permissions will already disallow an
On 26.10.2009 23:05, Isara Beaumont wrote:
Dan Yefimov said:
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
anoth
On Tue, Oct 27, 2009 at 4:29 AM, Tony Finch wrote:
> According to POSIX, if you open the directory with O_SEARCH then openat()
> does not re-check search (+x) permissions.
I stand corrected. (Though my test system doesn't appear to have O_SEARCH.)
On 27.10.2009 14:04, Vincent Zweije wrote:
On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to 0666
My buy.. :-( I persumed a re-use of the read-only FD, but that's not
the case.
I replayed it on a test-box and did some strace meanwhile and also
took a look
at the sourcecode of kernel/fs/proc.
It seems that the /proc filedescriptor is directly referring the file
inode
When creating this
On Mon, Oct 26, 2009 at 07:37:38PM +0100, Ansgar Wiechers wrote:
> On 2009-10-24 Derek Martin wrote:
> > 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.
>
> Wrong, because the file's attributes aren't s
Tony Finch wrote:
> According to POSIX, if you open the directory with O_SEARCH then openat()
> does not re-check search (+x) permissions.
My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH.
But anyway... even if openat() does not re-check permissions, it should
surely fail
On Sat, Oct 24, 2009 at 10:36:11PM +0400, Dan Yefimov scribbled thusly:
> Thus Debian kernel team should be blamed for that misbehaviour. Don't
> worry, hardlinks behave just the same way, as you describe. Use authentic
> Linux kernels, if you dislike that.
Shall we blame Red Hat too? Just teste
On Wed, Oct 28, 2009 at 10:30:37PM +0100, Pavel Machek wrote:
> On Tue 2009-10-27 11:49:32, CaT wrote:
> > On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
> > > and testing them. Remember the scenario from the original mail and try
> > > finding a window, during which creating a hardl
Dear Dan,
You wrote:
>> User1 creates file with permissions 0644
>> User2 opens file for read access on file descriptor 4
>> User1 chmod's directory to 0700
>> User1 verifies no hard links to file
>
> Here's a window, during which User2 is able to create a hard
Hi!
> > > Not that I would have expected anything different considering who posted
> > > it in the first place.
> > >
> > Thus Debian kernel team should be blamed for that misbehaviour. Don't
> > worry,
> > hardlinks behave just the same way, as you describe. Use authentic Linux
> > kernels, if
On Tue 2009-10-27 11:49:32, CaT wrote:
> On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
> > and testing them. Remember the scenario from the original mail and try
> > finding a window, during which creating a hardlink would still work thus
> > evading directory permissions check.
>
On Tue, Oct 27, 2009 at 08:09:57PM +0300, Dan Yefimov wrote:
|| On 27.10.2009 14:04, Vincent Zweije wrote:
|| > After chmodding the directory to 0700, *first*
|| >check the link count, *then* chmod the file to 0666:
|| >
|| > User1 creates file with permissions 0644
|| >
Hi!
> >That race is easily fixed.
>
> No, you're not right.
>
> > After chmodding the directory to 0700, *first*
> >check the link count, *then* chmod the file to 0666:
> >
> > User1 creates file with permissions 0644
> > User2 opens file for read access on file descripto
On Tue, Oct 27, 2009 at 03:34:04PM -0500, Derek Martin wrote:
> $ mkdir foo
> $ cd foo
> $ echo hi > bar
> $ ls -la
> total 12
> drwxr-xr-x 2 user1 group1 4096 2009-10-27 16:22 ./
> drwx-- 57 user1 group1 4096 2009-10-27 16:22 ../
> -rw-r--r-- 1 user1 group13 2009-10-27 16:22 bar
> $ chmo
On Tue 2009-10-27 21:19:19, Marco Verschuur wrote:
> My buy.. :-( I persumed a re-use of the read-only FD, but that's not
> the case.
>
> I replayed it on a test-box and did some strace meanwhile and also
> took a look
> at the sourcecode of kernel/fs/proc.
>
> It seems that the /proc filedescrip
On 29.10.2009 0:27, Pavel Machek wrote:
That race is easily fixed.
No, you're not right.
After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file with permissions 0644
User2 opens file for read access on
p...@maths.usyd.edu.au wrote:
> > According to POSIX, if you open the directory with O_SEARCH then openat()
> > does not re-check search (+x) permissions.
>
> My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH.
> But anyway... even if openat() does not re-check permissions,
On Thu 2009-10-29 18:24:01, Dan Yefimov wrote:
> On 29.10.2009 0:27, Pavel Machek wrote:
That race is easily fixed.
>>>
>>> No, you're not right.
>>>
After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file
> > 0700 mode from the origin, you would be right, and procfs wouldn't allow
> > opening files in that directory too, but if you let others to traverse
> > that directory and open your believed to be secure files from the origin,
> > it's your fault.
>
> I can do the example with fd passing and
Jim,
Your assumption that the same file descriptor is being re-opened is
wrong!
The file descriptor retrieved via /proc is a new one. It is not the
same as the
initial read-only.
Do a strace on your test and you will see that the 'file descriptor'
in /proc
will be accessed as an ordinairy
Hi!
> Your assumption that the same file descriptor is being re-opened is
> wrong!
> The file descriptor retrieved via /proc is a new one. It is not the
> same as the
> initial read-only.
True, we were just being sloppy with the words. But it does not matter
one iota.
> As Martin Rex already exp
Marco Verschuur wrote:
> Your assumption that the same file descriptor is being re-opened is
> wrong! The file descriptor retrieved via /proc is a new one. It is
> not the same as the initial read-only.
Yes, I totally agree.
> Therefor it's totally of no influence what you do with the original
Jim,
Sorry, but your 'prove' below is wrong!
You are opening the locked down file as root and passing that
fd as input to the nobody process.
So nobody is not opening /dir/file.txt (he can't because he hasn't
access to it via /dir) but root is...
Therefor the write to the fd is failing, because
Pavel,
Proc does not need to be fixed, because /proc is referring to a file
inode.
And due to the fact that it's being presented in /proc as an fd, you
treat it
as an fd, therefor your expectations do not match.
Your assumptions is; because you accessed the world writable file via
a read-on
Hi!
(no html, please).
>Proc does not need to be fixed, because /proc is referring to a file
>inode.
Well, that does not mean /proc does not need fixing.
>You are expecting transactional behavior in /proc, where /proc only
>registers object information.
...
>And I think you
> ... another solution -- allow fcntl() to remove read-only and
> append-only limitations, so that behaviour is at least explicit.
Do not lower security, just to emulate /proc sloppiness. (That would be
like fixing a root security bug by doing away with the root password.)
Is there anything (curre
>> 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?
Do your homework and test it. You can't create the hardlink - the link(oldpath,
newpath) cal
99 matches
Mail list logo