All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>, Willy Tarreau <w@1wt.eu>,
	"security@kernel.org" <security@kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Brad Spengler <spender@grsecurity.net>
Subject: Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH)
Date: Sun, 25 Aug 2013 04:37:42 +0100	[thread overview]
Message-ID: <20130825033741.GX27005@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20130823010726.GP27005@ZenIV.linux.org.uk>

On Fri, Aug 23, 2013 at 02:07:26AM +0100, Al Viro wrote:
> On Thu, Aug 22, 2013 at 01:54:15PM -0700, Linus Torvalds wrote:
> > On Thu, Aug 22, 2013 at 1:48 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > >
> > > Sure.  But aren't they always last?
> > 
> > What do you mean? I'd say that the /proc lookup is always *innermost*.
> > Which means that it certainly cannot bail out, since there are many
> > levels of nesting outside of it.
> > 
> > > With the current code structure, trying to enforce some kind of
> > > security restriction in the middle of lookup seems really unpleasant.
> > 
> > If it's conditional (ie "linkat behaves differently from openat"), it
> > certainly means that we'd have to pass in that info in annoying ways.
> 
> Nope.  All we need to pass is one more LOOKUP_...  Add
> 	if (unlikely(nd->last_type == LAST_BIND)) {
> 		if ((nd->flags & LOOKUP_BLAH) && !may_flink(...)) {
> 			terminate_walk(nd);
> 			return -EINVAL;
> 		}
> 	}
> in the beginning of lookup_last() and pass LOOKUP_BLAH in flags when
> linkat() calls user_path_at().  That will affect *only* the terminal
> symlinks and cost nothing in all normal cases.  The same check can
> bloody well go into path_init() - take
>                 if (*name) {
>                         if (!can_lookup(dentry->d_inode)) {
>                                 fdput(f);
>                                 return -ENOTDIR;
>                         }
>                 }
> in there and slap
> 		else {
> 			if ((flags & LOOKUP_BLAH) && !may_flink(...)) {
>                                 fdput(f);
> 				return -EINVAL;
> 			}
> 		}
> after it.

OK, let me summarize these threads so far:
	* restrictions for flink() are needed and they'd better be
consistent for AT_SYMLINK_FOLLOW + /proc/<pid>/fd/<n> and simply
passing the descriptor as dfd.
	* CAP_DAC_OVERRIDE is sufficient; so should be O_TMPFILE used
to open that sucker.
	* lookup_last() is the natural place for catching the case
of following a trailing procfs symlink - it can be done very cheaply
there.

FWIW, I'm tempted to try the following trick:
	* introduce FMODE_FLINK in file->f_mode; O_TMPFILE would set it,
unless O_EXCL is present.
	* introduce LOOKUP_LINK, to be passed by sys_linkat() when
resolving the target.
	* have path_init() called with empty pathname and LOOKUP_LINK in
flags do checks for FMODE_FLINK or CAP_DAC_OVERRIDE
	* have ->proc_get_link() report whether the target is linkable
(either as bool * or by returning 1 instead of 0).  After the call of
->proc_get_link() check that and set nd->last_type to LAST_BIND_LINKABLE.
Note that *all* places looking at ->last_type treat LAST_BIND as "none
of the above" - we never compare with it, so splitting it in two wouldn't
break anything.
	* have lookup_last() check if LOOKUP_LINK is present and ->last_type
is LAST_BIND; fail unless we have CAP_DAC_OVERRIDE.

AFAICS, it gets more or less sane behaviour; additionally, it makes possible
to introduce explicit "I want that descriptor to be suitable for flink()"
open(2) flag - that would require teaching do_last() about LOOKUP_LINK,
making it check for CAP_DAC_OVERRIDE if it sees LAST_BIND / LOOKUP_LINK,
same as lookup_last() above (we obviously want to avoid the possibility
to take a non-flinkable descriptor and use it to reopen the sucker in
flinkable way).

Alternatively we can revert "fs: Allow unprivileged linkat(..., AT_EMPTY_PATH)
aka flink" for the time being.  flink() is certainly an awful mess and I
seriously regret touching it ;-/

Comments?  Hell, maybe somebody even has printable ones - stranger things
have happened...

  reply	other threads:[~2013-08-25  3:37 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-21 19:14 [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH) Andy Lutomirski
     [not found] ` <CA+55aFxi-ps2f2M8xPhfbuQ0pToqupPrDsLi2+GPUK2sqdYfUw@mail.gmail.com>
     [not found]   ` <CALCETrW7+LcexA6v6RQDKhni_yJAduOmiSDneCpq3v8sPDvwUQ@mail.gmail.com>
2013-08-21 20:16     ` Willy Tarreau
2013-08-22 18:48 ` Linus Torvalds
2013-08-22 18:53   ` Willy Tarreau
2013-08-22 19:05     ` Andy Lutomirski
2013-08-22 19:23       ` Linus Torvalds
2013-08-22 20:10         ` Andy Lutomirski
2013-08-22 20:15           ` Willy Tarreau
2013-08-22 20:22             ` Andy Lutomirski
2013-08-22 20:44               ` Linus Torvalds
2013-08-22 20:48                 ` Andy Lutomirski
2013-08-22 20:54                   ` Linus Torvalds
2013-08-22 20:58                     ` Andy Lutomirski
2013-08-23  1:07                     ` Al Viro
2013-08-25  3:37                       ` Al Viro [this message]
2013-08-25  7:26                         ` Andy Lutomirski
2013-08-25 14:23                           ` Al Viro
2013-08-25 17:04                             ` Andy Lutomirski
2013-08-25 19:57                         ` Linus Torvalds
2013-08-25 20:06                           ` Al Viro
2013-08-25 20:23                             ` Linus Torvalds
2013-08-26 17:37                               ` Linus Torvalds
2013-08-26 18:07                                 ` Linus Torvalds
2013-08-26 18:11                                   ` Andy Lutomirski
2013-08-27 19:16                                   ` [RFC PATCH] fs: Add user_file_or_path_at and use it for truncate Andy Lutomirski
2013-08-27 19:32                                     ` Linus Torvalds
2013-08-27 20:28                                       ` Andy Lutomirski
2013-08-28  6:16                                         ` Al Viro
2013-08-28 16:24                                           ` Linus Torvalds
2013-08-28 19:04                                           ` Andy Lutomirski
2013-08-28 19:59                                             ` Al Viro
2013-08-28 21:07                                               ` Andy Lutomirski
2013-08-27 23:08                                     ` Al Viro
2013-08-27 23:13                                       ` Andy Lutomirski
2013-08-24 18:29             ` /proc/pid/fd && anon_inode_fops Oleg Nesterov
2013-08-24 21:24               ` Willy Tarreau
2013-08-25  5:23                 ` Al Viro
2013-08-25  6:50                   ` Willy Tarreau
2013-08-25 18:51                     ` Linus Torvalds
2013-08-25 19:48                       ` Oleg Nesterov
2013-08-25 20:05                         ` Linus Torvalds
2013-08-26 15:33                           ` Oleg Nesterov
2013-08-26 16:37                             ` Oleg Nesterov
2013-08-26 17:54                               ` [PATCH] proc: make proc_fd_permission() thread-friendly Oleg Nesterov
2013-08-26 18:09                                 ` Linus Torvalds
2013-08-26 19:35                                   ` Linus Torvalds
2013-08-26 20:20                                     ` Willy Tarreau
2013-08-27 15:05                                       ` Oleg Nesterov
2013-08-27 14:39                                     ` [PATCH 0/1] proc: make /proc/self point to thread Oleg Nesterov
2013-08-27 14:40                                       ` [PATCH 1/1] " Oleg Nesterov
2013-08-27 16:39                                         ` Linus Torvalds
2013-08-27 17:49                                           ` Oleg Nesterov
2013-08-27 18:15                                             ` Linus Torvalds
2013-08-27 18:28                                               ` Oleg Nesterov
     [not found]                                     ` <CALCETrXP-mYBPRon=0NzexW1FK1Qxz2+Bwv7-WeHBQpvW7ywRg@mail.gmail.com>
2013-08-27 15:45                                       ` [PATCH] proc: make proc_fd_permission() thread-friendly Oleg Nesterov
2013-08-26 18:32                                 ` Eric W. Biederman
2013-08-26 18:46                                   ` Oleg Nesterov
2013-08-26 18:56                                     ` Oleg Nesterov
2013-08-26 19:10                                     ` Eric W. Biederman
2013-08-27 14:53                                       ` Oleg Nesterov
2013-08-25 18:32                   ` /proc/pid/fd && anon_inode_fops Linus Torvalds
2013-08-25 19:11                     ` Al Viro
2013-08-25 19:17                     ` Andy Lutomirski
2013-09-03 15:58                     ` Pavel Machek
2013-08-25 15:45                 ` Oleg Nesterov
     [not found]               ` <20130825051044.GY27005@ZenIV.linux.org.uk>
     [not found]                 ` <20130825155348.GB25922@redhat.com>
     [not found]                   ` <CALCETrXrtP2C+g=QeNWK4EMctmonW91kWoO1xmy7rDmEj__1Dw@mail.gmail.com>
     [not found]                     ` <20130825174936.GA30957@redhat.com>
2013-08-25 17:55                       ` [PATCH 0/1] anon_inodefs: forbid open via /proc Oleg Nesterov
2013-08-25 17:55                         ` [PATCH 1/1] " Oleg Nesterov
2013-08-22 19:39       ` [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH) Willy Tarreau

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=20130825033741.GX27005@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=security@kernel.org \
    --cc=spender@grsecurity.net \
    --cc=torvalds@linux-foundation.org \
    --cc=w@1wt.eu \
    /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.