From: Pavel Machek <pavel@ucw.cz>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
Jan Kara <jack@suse.cz>, "J. Bruce Fields" <bfields@fieldses.org>,
"Serge E. Hallyn" <serue@us.ibm.com>,
kernel list <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
jamie@shareable.org
Subject: Re: symlinks with permissions
Date: Wed, 28 Oct 2009 22:03:24 +0100 [thread overview]
Message-ID: <20091028210323.GA4159@elf.ucw.cz> (raw)
In-Reply-To: <m1k4yfkbfg.fsf@fess.ebiederm.org>
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
next prev parent reply other threads:[~2009-10-28 21:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-25 6:29 symlinks with permissions Pavel Machek
2009-10-26 16:31 ` Jan Kara
2009-10-26 16:57 ` Serge E. Hallyn
2009-10-26 17:36 ` J. Bruce Fields
2009-10-26 17:46 ` Jan Kara
2009-10-26 17:57 ` Trond Myklebust
2009-10-25 9:36 ` Pavel Machek
2009-10-26 18:22 ` Trond Myklebust
2009-10-27 8:11 ` Pavel Machek
2009-10-27 10:27 ` Jamie Lokier
2009-10-26 18:35 ` J. Bruce Fields
2009-10-28 4:15 ` Eric W. Biederman
2009-10-28 8:16 ` Pavel Machek
2009-10-28 11:25 ` Eric W. Biederman
2009-10-28 21:03 ` Pavel Machek [this message]
2009-10-29 2:20 ` Eric W. Biederman
2009-10-29 11:03 ` Pavel Machek
2009-10-29 16:23 ` Eric W. Biederman
2009-10-30 18:35 ` Pavel Machek
2009-10-30 20:37 ` Nick Bowler
2009-10-30 23:03 ` Eric W. Biederman
2009-10-31 2:30 ` Jamie Lokier
2009-10-28 16:34 ` Casey Schaufler
2009-10-28 19:44 ` Jamie Lokier
2009-10-28 21:06 ` Pavel Machek
2009-10-28 22:48 ` David Wagner
2009-10-29 4:13 ` Casey Schaufler
2009-10-29 7:53 ` David Wagner
2009-10-30 14:07 ` Pavel Machek
2009-10-31 4:09 ` Casey Schaufler
2009-11-01 9:23 ` David Wagner
2009-11-01 17:43 ` Casey Schaufler
2009-11-01 20:39 ` David Wagner
2009-11-01 22:05 ` Casey Schaufler
2009-10-26 18:02 ` J. Bruce Fields
2009-10-26 17:57 ` Serge E. Hallyn
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=20091028210323.GA4159@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=bfields@fieldses.org \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@us.ibm.com \
--cc=trond.myklebust@fys.uio.no \
--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.