All of lore.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 09:23:34 +0000 (UTC)	[thread overview]
Message-ID: <hcjk2m$v46$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 4AEBB86F.3090601@schaufler-ca.com

Casey Schaufler  wrote:
>Pavel Machek wrote:
>> Look again. I can count on paths if I can prevent mounts and
>> hardlinks.
>
> But you can't.

Yes, he can and did.  See Pavel's original post with his
attack script.  It's all there!

Hardlinks: in his *original* post, listing the attack script,
Pavel checks the hardlink count, which does defend against
hardlinks.  So can we drop the hardlink objection?

Mounts: can only be exploited by root.  On many Linux systems,
one cannot defend against a threat model where root is malicious,
and as a consequence, root-only attacks are out of scope for
those systems.  For those systems, this /proc mechanism is
a security hole: it enables attacker to do bad stuff they
couldn't have done without it.

> I refer you back to the long and tedious arguments
> against pathname based access controls.

I don't find that reference helpful.  Those arguments don't
seem relevant to this situation, as far as I can see.  I would
find specificity more useful than analogies.

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?

  reply	other threads:[~2009-11-01  9:23 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 [this message]
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='hcjk2m$v46$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 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.