public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: symlinks with permissions
Date: Sun, 1 Nov 2009 20:39:30 +0000 (UTC)	[thread overview]
Message-ID: <hckrm2$6bl$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 4AEDC8DD.4080806@schaufler-ca.com

Casey Schaufler  wrote:
>David Wagner wrote:
>> Pavel has provided a concrete attack script.  If you believe
>> that the protections afforded by that script can be circumvented,
>> how about showing us the specific attack, described to a similar
>> level of concreteness and specifity, that demonstrates how to
>> upgrade the read-only fd to a read-write fd without using /proc?
>>
>> Put another way: if you are right that the arguments about
>> pathname based access controls apply here and lead to the
>> conclusions you are espousing, then you should be able to
>> exhibit a specific, concrete, fully specified attack on Pavel's
>> script, without using /proc.  Right?
>
> No. The going in premise, that the behavior is a security flaw,
> is incorrect.  The mode bits on the file allow the requested access.

I see.  May I conclude that you are unable to answer my challenge?

I challenged you to show exactly how else a non-root user could gain write
access to the file, in Pavel's script, other than using /proc/../fd/...
Based on the fact that you have repeatedly declined to answer this
challenge, it sounds like I can safely conclude that you do not know of
any other way that a non-root user can accomplish this, in the situation
Pavel outlines.

So, it sounds like we have agreement that:

  * In the situation Pavel outlines, a malicious non-root user
    given read-only access to the file can use /proc/../fd/.. to
    upgrade that fd to read-write access.

  * If /proc/../fd/.. didn't exist, the non-root user would not have
    been able to do that.

So the /proc/../fd/.. mechanism is enabling a malicious user to get
access that they would not have been able to get in the absence of
this mechanism.

Do you agree with that summary?


The above are the facts, as I see them.  (In contrast, the following is
my opinion: It is my opinion that these facts demonstrate that this is
a security violation.)  But I'm not asking for your feedback about my
opinion; I'm asking you about the facts.  Do you agree with my statement
of the facts?

  reply	other threads:[~2009-11-01 20:39 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
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 [this message]
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='hckrm2$6bl$1@taverner.cs.berkeley.edu' \
    --to=daw@cs.berkeley.edu \
    --cc=daw-news@cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox