linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Andy Lutomirski <luto@kernel.org>, security@kernel.org
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Kees Cook <keescook@chromium.org>, Willy Tarreau <w@1wt.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	yalin wang <yalin.wang2010@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid()
Date: Wed, 25 Jan 2017 21:43:54 +0000	[thread overview]
Message-ID: <1485380634.2998.161.camel@decadent.org.uk> (raw)
In-Reply-To: <9318903980969a0e378dab2de4d803397adcd3cc.1485377903.git.luto@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On Wed, 2017-01-25 at 13:06 -0800, Andy Lutomirski wrote:
> If an unprivileged program opens a setgid file for write and passes
> the fd to a privileged program and the privileged program writes to
> it, we currently fail to clear the setgid bit.  Fix it by checking
> f_cred instead of current's creds whenever a struct file is
> involved.
[...]

What if, instead, a privileged program passes the fd to an un
unprivileged program?  It sounds like a bad idea to start with, but at
least currently the unprivileged program is going to clear the setgid
bit when it writes.  This change would make that behaviour more
dangerous.

Perhaps there should be a capability check on both the current
credentials and file credentials?  (I realise that we've considered
file credential checks to be sufficient elsewhere, but those cases
involved virtual files with special semantics, where it's clearer that
a privileged process should not pass them to an unprivileged process.)

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program than to understand a correct
one.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-01-25 21:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25 21:06 [PATCH 0/2] setgid hardening Andy Lutomirski
2017-01-25 21:06 ` [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid() Andy Lutomirski
2017-01-25 21:43   ` Ben Hutchings [this message]
2017-01-25 21:48     ` Andy Lutomirski
2017-01-25 23:15       ` Frank Filz
2017-01-26  0:12     ` Kees Cook
2017-01-25 21:06 ` [PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory Andy Lutomirski
2017-01-25 21:31   ` Ben Hutchings
2017-01-25 21:44     ` Andy Lutomirski
2017-01-25 23:17   ` Frank Filz
2017-01-25 23:50   ` Willy Tarreau
2017-01-25 23:59 ` [PATCH 0/2] setgid hardening 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=1485380634.2998.161.camel@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=keescook@chromium.org \
    --cc=koct9i@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=security@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=w@1wt.eu \
    --cc=yalin.wang2010@gmail.com \
    /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