From: Jann Horn <jann@thejh.net>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Stephen Smalley <sds@tycho.nsa.gov>,
Andrew Morton <akpm@linux-foundation.org>,
"security@kernel.org" <security@kernel.org>,
James Morris <james.l.morris@oracle.com>,
Janis Danisevskis <jdanis@google.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Kees Cook <keescook@chromium.org>,
Roland McGrath <roland@hack.frob.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
LSM List <linux-security-module@vger.kernel.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Eric . Biederman" <ebiederm@xmission.com>,
Paul Moore <aul@paul-moore.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Benjamin LaHaise <bcrl@kvack.org>,
Eric Paris <eparis@parisplace.org>,
Seth Forshee <seth.forshee@canonical.com>,
John Johansen <john.johansen@canonical.com>
Subject: Re: [PATCH 7/9] ptrace: forbid ptrace checks against current_cred() from VFS context
Date: Sun, 18 Sep 2016 22:38:17 +0200 [thread overview]
Message-ID: <20160918203817.GA2903@pc.thejh.net> (raw)
In-Reply-To: <CALCETrXHCz0h-KTJOQoBcCLm50QvbJi7W5c8yjh9BxeUj8FrUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
On Sun, Sep 18, 2016 at 12:57:57PM -0700, Andy Lutomirski wrote:
> On Sep 18, 2016 5:05 AM, "Jann Horn" <jann@thejh.net> wrote:
> >
> > This ensures that VFS implementations don't call ptrace_may_access() from
> > VFS read or write handlers. In order for file descriptor passing to have
> > its intended security properties, VFS read/write handlers must not do any
> > kind of privilege checking.
> >
>
> Ooh, nifty! Can you warn about capable() too?
>
> Warning about all access to current->cred could be fun. I expect we
> have zillions of these bugs. Think keys, netlink, proc, etc.
True, that would probably spam dmesg quite a bit. %pK under printk() is
pretty nonsensical (heh, maybe we even have code doing capable() checks
in IRQ context via printk()), then there are all those broken capable()
checks for root-only sysctls and so on.
For capable(), I've been thinking about adopting Linus' old suggestion of
simply overriding the creds on VFS read/write entry. If we make
current->cred non-refcounted and task-private (no RCU-safe pointer
assignment), it's going to basically be two extra pointer reads and writes
per read/write call - even for such a hot code path, that should be fine
IMO. (And if we don't want to do this for all read/write calls, we could
at least do it for sysctls, that would already help quite a bit.)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-09-18 20:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-18 15:05 [PATCH 0/9] Various fixes related to ptrace_may_access() Jann Horn
2016-09-18 15:05 ` [PATCH 1/9] exec: introduce cred_guard_light Jann Horn
2016-09-18 15:05 ` [PATCH 2/9] exec: turn self_exec_id into self_privunit_id Jann Horn
2016-09-18 18:13 ` Ben Hutchings
2016-09-18 18:31 ` Jann Horn
2016-09-18 18:45 ` Ben Hutchings
2016-09-18 19:08 ` Jann Horn
2016-09-18 19:57 ` Andy Lutomirski
2016-09-19 15:31 ` Jann Horn
2016-09-18 15:05 ` [PATCH 3/9] proc: use open()-time creds for ptrace checks Jann Horn
2016-09-19 13:01 ` Stephen Smalley
2016-09-19 14:32 ` Jann Horn
2016-09-19 14:45 ` Stephen Smalley
2016-09-18 15:05 ` [PATCH 4/9] futex: don't leak robust_list pointer Jann Horn
2016-09-18 18:28 ` Ben Hutchings
2016-09-18 18:33 ` Jann Horn
2016-09-18 15:05 ` [PATCH 5/9] proc: lock properly in ptrace_may_access callers Jann Horn
2016-09-18 19:15 ` Jann Horn
2016-09-18 15:05 ` [PATCH 6/9] ptrace: warn on ptrace_may_access without proper locking Jann Horn
2016-09-18 15:05 ` [PATCH 7/9] ptrace: forbid ptrace checks against current_cred() from VFS context Jann Horn
2016-09-18 18:38 ` Ben Hutchings
2016-09-18 18:40 ` Jann Horn
2016-09-18 19:57 ` Andy Lutomirski
2016-09-18 20:38 ` Jann Horn [this message]
2016-09-18 20:18 ` Linus Torvalds
2016-09-18 20:52 ` Jann Horn
2016-09-18 15:05 ` [PATCH 8/9] fs/proc: fix attr access check Jann Horn
2016-09-18 15:05 ` [PATCH 9/9] Documentation: add security/ptrace_checks.txt Jann Horn
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=20160918203817.GA2903@pc.thejh.net \
--to=jann@thejh.net \
--cc=akpm@linux-foundation.org \
--cc=aul@paul-moore.com \
--cc=bcrl@kvack.org \
--cc=casey@schaufler-ca.com \
--cc=ebiederm@xmission.com \
--cc=eparis@parisplace.org \
--cc=james.l.morris@oracle.com \
--cc=jdanis@google.com \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=oleg@redhat.com \
--cc=roland@hack.frob.com \
--cc=sds@tycho.nsa.gov \
--cc=security@kernel.org \
--cc=serge@hallyn.com \
--cc=seth.forshee@canonical.com \
--cc=tglx@linutronix.de \
--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.