All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [RFC 2/2] fs,proc: Respect FMODE_WRITE when opening /proc/pid/fd/N
Date: Tue, 22 Apr 2014 20:58:02 +0200	[thread overview]
Message-ID: <20140422185802.GA31201@amd.pavel.ucw.cz> (raw)
In-Reply-To: <CANq1E4TPPcdD-8FF_Kc=r44Vrd51Vmt-OVu+EtCC-oEzXkvJvg@mail.gmail.com>

On Tue 2014-04-22 17:19:42, David Herrmann wrote:
> Hi
> 
> On Tue, Apr 22, 2014 at 4:31 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > Such as here?
> >
> > http://www.securityfocus.com/archive/1/507386
> 
> Thanks, that's the first real example someone mentioned.
> 
> Quoted from your link:
> 
> > 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.
> 
> In other words, the bug you describe is that /proc/pid/fd/ allows
> access to objects without a reachable path to the only _real_
> filesystem link. But isn't the same true for openat()?

I don't think openat helps you. This is what we are talking about, it
is easy to reproduce. Can you reproduce it without /proc mounted?

I think that chmod 700 . should stop you. Openat seems no worse than
just placing cwd there...

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
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  parent reply	other threads:[~2014-04-22 18:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 16:22 [RFC 0/2] Fix permission checks on open("/proc/self/fd/N", O_RDWR) Andy Lutomirski
2014-04-21 16:22 ` [RFC 1/2] fs,proc: Pass nameidata to proc_get_link implementations Andy Lutomirski
2014-04-21 16:29   ` Al Viro
2014-04-21 16:22 ` [RFC 2/2] fs,proc: Respect FMODE_WRITE when opening /proc/pid/fd/N Andy Lutomirski
2014-04-21 16:30   ` Al Viro
2014-04-21 17:00     ` Andy Lutomirski
2014-04-21 17:04       ` Andy Lutomirski
2014-04-21 17:48         ` Andy Lutomirski
2014-04-22 12:44   ` David Herrmann
2014-04-22 13:49     ` Andy Lutomirski
2014-04-22 14:17       ` David Herrmann
2014-04-22 14:33         ` Andy Lutomirski
2014-04-22 15:03           ` David Herrmann
2014-04-22 15:20             ` Andy Lutomirski
2014-04-22 14:40         ` Pavel Machek
2014-04-22 14:31     ` Pavel Machek
2014-04-22 15:19       ` David Herrmann
2014-04-22 15:24         ` Andy Lutomirski
2014-04-22 16:44           ` David Herrmann
2014-04-22 17:05             ` Andy Lutomirski
2014-04-22 18:58         ` Pavel Machek [this message]
2014-04-22 21:31           ` David Herrmann
2014-04-22 21:34             ` Andy Lutomirski
2014-04-22 22:12             ` Pavel Machek

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=20140422185802.GA31201@amd.pavel.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=dh.herrmann@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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.