From: Djalal Harouni <tixxdz@opendz.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
David Rientjes <rientjes@google.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
kernel-hardening@lists.openwall.com, tixxdz@gmail.com
Subject: [kernel-hardening] Re: [PATCH v2 6/9] procfs: add permission checks on the file's opener of /proc/*/stat
Date: Wed, 2 Oct 2013 16:14:30 +0100 [thread overview]
Message-ID: <20131002151430.GB2669@dztty> (raw)
In-Reply-To: <524B7934.9070606@amacapital.net>
On Tue, Oct 01, 2013 at 06:39:00PM -0700, Andy Lutomirski wrote:
> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
> > Some fields of the /proc/*/stat are sensitive fields that need
> > appropriate protection.
> >
> > However, /proc file descriptors can be passed to a more privileged
> > process (e.g. a suid-exec) which will pass the classic
> > ptrace_may_access() permission check during read().
> >
> > To prevent it, use proc_same_open_cred() to detect if current's cred
> > have changed between ->open() and ->read(), if so, call
> > proc_allow_access() to check if the original file's opener had enough
> > permissions to read these sensitive fields. This will prevent passing
> > file descriptors to a more privileged process to leak data.
> >
> > The patch also adds a previously missing signal->cred_guard_mutex lock.
> >
> > This patch does not break userspace since it only hides the fields that
> > were supposed to be protected.
> >
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Eric W. Biederman <ebiederm@xmission.com>
> > Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
> > ---
> > fs/proc/array.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index cbd0f1b..f034e05 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -394,7 +394,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
> > char state;
> > pid_t ppid = 0, pgid = -1, sid = -1;
> > int num_threads = 0;
> > - int permitted;
> > + int permitted = 0;
> > struct mm_struct *mm;
> > unsigned long long start_time;
> > unsigned long cmin_flt = 0, cmaj_flt = 0;
> > @@ -404,10 +404,22 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
> > unsigned long rsslim = 0;
> > char tcomm[sizeof(task->comm)];
> > unsigned long flags;
> > + struct file *file = m->private;
> > + int same_cred = proc_same_open_cred(file->f_cred);
> > + unsigned int ptrace_mode = PTRACE_MODE_READ | PTRACE_MODE_NOAUDIT;
> >
> > state = *get_task_state(task);
> > vsize = eip = esp = 0;
> > - permitted = ptrace_may_access(task, PTRACE_MODE_READ | PTRACE_MODE_NOAUDIT);
> > +
> > + if (!mutex_lock_killable(&task->signal->cred_guard_mutex)) {
> > + permitted = ptrace_may_access(task, ptrace_mode);
> > + if (permitted && !same_cred)
> > + permitted = proc_allow_access(file->f_cred,
> > + task, ptrace_mode);
> > +
> > + mutex_unlock(&task->signal->cred_guard_mutex);
> > + }
> > +
>
> else permitted = false?
permitted is initialized to 0
First the original ptrace_may_access() check did not hold
cred_guard_mutex, so add it. If we can't grab mutex then let permitted
to be zero. Yes this a change in behaviour and I think it's correct, IOW
we were not able to perform the ptrace_may_access() check, otherwise
permitted will depend on checks result.
However, there is still a race here since we set the permitted value
before gathering the appropriate info about task. At the read() data moment
this target task may have been gone privileged... , acquiring an X lock
on target task, will just break/slow things, as it has been shown before...
Not to mention that the race window is small...
> But surely this would be *much* more comprehensible if you had
> proc_allow_access do the entire check.
I don't understand what you mean by "do the entire check" ?
the /proc/pid/stat file is used by "ps", "top" ... it's a vital file
We don't want to break it, otherwise "ps" will hide processes. So just
do the ptrace_may_access() check correctly with the help of
proc_allow_access() and set the permitted variable only. The patch did
not touch /proc/pid/stat fields.
I've done tests on ps and top, and they work fine.
--
Djalal Harouni
http://opendz.org
WARNING: multiple messages have this Message-ID (diff)
From: Djalal Harouni <tixxdz@opendz.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
David Rientjes <rientjes@google.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
kernel-hardening@lists.openwall.com, tixxdz@gmail.com
Subject: Re: [PATCH v2 6/9] procfs: add permission checks on the file's opener of /proc/*/stat
Date: Wed, 2 Oct 2013 16:14:30 +0100 [thread overview]
Message-ID: <20131002151430.GB2669@dztty> (raw)
In-Reply-To: <524B7934.9070606@amacapital.net>
On Tue, Oct 01, 2013 at 06:39:00PM -0700, Andy Lutomirski wrote:
> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
> > Some fields of the /proc/*/stat are sensitive fields that need
> > appropriate protection.
> >
> > However, /proc file descriptors can be passed to a more privileged
> > process (e.g. a suid-exec) which will pass the classic
> > ptrace_may_access() permission check during read().
> >
> > To prevent it, use proc_same_open_cred() to detect if current's cred
> > have changed between ->open() and ->read(), if so, call
> > proc_allow_access() to check if the original file's opener had enough
> > permissions to read these sensitive fields. This will prevent passing
> > file descriptors to a more privileged process to leak data.
> >
> > The patch also adds a previously missing signal->cred_guard_mutex lock.
> >
> > This patch does not break userspace since it only hides the fields that
> > were supposed to be protected.
> >
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Eric W. Biederman <ebiederm@xmission.com>
> > Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
> > ---
> > fs/proc/array.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index cbd0f1b..f034e05 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -394,7 +394,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
> > char state;
> > pid_t ppid = 0, pgid = -1, sid = -1;
> > int num_threads = 0;
> > - int permitted;
> > + int permitted = 0;
> > struct mm_struct *mm;
> > unsigned long long start_time;
> > unsigned long cmin_flt = 0, cmaj_flt = 0;
> > @@ -404,10 +404,22 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
> > unsigned long rsslim = 0;
> > char tcomm[sizeof(task->comm)];
> > unsigned long flags;
> > + struct file *file = m->private;
> > + int same_cred = proc_same_open_cred(file->f_cred);
> > + unsigned int ptrace_mode = PTRACE_MODE_READ | PTRACE_MODE_NOAUDIT;
> >
> > state = *get_task_state(task);
> > vsize = eip = esp = 0;
> > - permitted = ptrace_may_access(task, PTRACE_MODE_READ | PTRACE_MODE_NOAUDIT);
> > +
> > + if (!mutex_lock_killable(&task->signal->cred_guard_mutex)) {
> > + permitted = ptrace_may_access(task, ptrace_mode);
> > + if (permitted && !same_cred)
> > + permitted = proc_allow_access(file->f_cred,
> > + task, ptrace_mode);
> > +
> > + mutex_unlock(&task->signal->cred_guard_mutex);
> > + }
> > +
>
> else permitted = false?
permitted is initialized to 0
First the original ptrace_may_access() check did not hold
cred_guard_mutex, so add it. If we can't grab mutex then let permitted
to be zero. Yes this a change in behaviour and I think it's correct, IOW
we were not able to perform the ptrace_may_access() check, otherwise
permitted will depend on checks result.
However, there is still a race here since we set the permitted value
before gathering the appropriate info about task. At the read() data moment
this target task may have been gone privileged... , acquiring an X lock
on target task, will just break/slow things, as it has been shown before...
Not to mention that the race window is small...
> But surely this would be *much* more comprehensible if you had
> proc_allow_access do the entire check.
I don't understand what you mean by "do the entire check" ?
the /proc/pid/stat file is used by "ps", "top" ... it's a vital file
We don't want to break it, otherwise "ps" will hide processes. So just
do the ptrace_may_access() check correctly with the help of
proc_allow_access() and set the permitted variable only. The patch did
not touch /proc/pid/stat fields.
I've done tests on ps and top, and they work fine.
--
Djalal Harouni
http://opendz.org
next prev parent reply other threads:[~2013-10-02 15:14 UTC|newest]
Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-01 20:26 [kernel-hardening] [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 1/9] procfs: add proc_same_open_cred() to check if the cred have changed Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-02 1:36 ` [kernel-hardening] " Andy Lutomirski
2013-10-02 1:36 ` Andy Lutomirski
2013-10-02 14:55 ` [kernel-hardening] " Djalal Harouni
2013-10-02 14:55 ` Djalal Harouni
2013-10-02 16:44 ` [kernel-hardening] " Andy Lutomirski
2013-10-02 16:44 ` Andy Lutomirski
2013-10-03 14:36 ` [kernel-hardening] " Djalal Harouni
2013-10-03 14:36 ` Djalal Harouni
2013-10-03 15:12 ` [kernel-hardening] " Andy Lutomirski
2013-10-03 15:12 ` Andy Lutomirski
2013-10-03 19:29 ` [kernel-hardening] " Djalal Harouni
2013-10-03 19:29 ` Djalal Harouni
2013-10-03 19:37 ` [kernel-hardening] " Andy Lutomirski
2013-10-03 19:37 ` Andy Lutomirski
2013-10-03 20:13 ` [kernel-hardening] " Djalal Harouni
2013-10-03 20:13 ` Djalal Harouni
2013-10-03 21:09 ` [kernel-hardening] " Andy Lutomirski
2013-10-03 21:09 ` Andy Lutomirski
2013-10-04 8:59 ` [kernel-hardening] " Djalal Harouni
2013-10-04 8:59 ` Djalal Harouni
2013-10-04 15:40 ` [kernel-hardening] " Andy Lutomirski
2013-10-04 15:40 ` Andy Lutomirski
2013-10-04 18:23 ` [kernel-hardening] " Djalal Harouni
2013-10-04 18:23 ` Djalal Harouni
2013-10-04 18:34 ` [kernel-hardening] " Andy Lutomirski
2013-10-04 18:34 ` Andy Lutomirski
2013-10-04 19:11 ` [kernel-hardening] " Djalal Harouni
2013-10-04 19:11 ` Djalal Harouni
2013-10-04 19:16 ` [kernel-hardening] " Andy Lutomirski
2013-10-04 19:16 ` Andy Lutomirski
2013-10-04 19:27 ` [kernel-hardening] " Djalal Harouni
2013-10-04 19:27 ` Djalal Harouni
2013-10-04 19:32 ` [kernel-hardening] " Andy Lutomirski
2013-10-04 19:32 ` Andy Lutomirski
2013-10-04 19:41 ` [kernel-hardening] " Djalal Harouni
2013-10-04 19:41 ` Djalal Harouni
2013-10-04 22:17 ` [kernel-hardening] " Andy Lutomirski
2013-10-04 22:17 ` Andy Lutomirski
2013-10-04 22:55 ` [kernel-hardening] " Eric W. Biederman
2013-10-04 22:55 ` Eric W. Biederman
2013-10-04 22:59 ` [kernel-hardening] " Andy Lutomirski
2013-10-04 22:59 ` Andy Lutomirski
2013-10-04 23:08 ` [kernel-hardening] " Andy Lutomirski
2013-10-04 23:08 ` Andy Lutomirski
2013-10-05 0:35 ` [kernel-hardening] " Eric W. Biederman
2013-10-05 0:35 ` Eric W. Biederman
2013-10-09 10:35 ` [kernel-hardening] " Djalal Harouni
2013-10-09 10:35 ` Djalal Harouni
2013-10-05 13:23 ` [kernel-hardening] " Djalal Harouni
2013-10-05 13:23 ` Djalal Harouni
2013-10-07 21:41 ` [kernel-hardening] " Andy Lutomirski
2013-10-07 21:41 ` Andy Lutomirski
2013-10-09 10:54 ` [kernel-hardening] " Djalal Harouni
2013-10-09 10:54 ` Djalal Harouni
2013-10-09 11:15 ` [kernel-hardening] " Djalal Harouni
2013-10-09 11:15 ` Djalal Harouni
2013-10-09 17:27 ` [kernel-hardening] " Andy Lutomirski
2013-10-09 17:27 ` Andy Lutomirski
2013-10-13 10:18 ` [kernel-hardening] " Djalal Harouni
2013-10-13 10:18 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 3/9] procfs: Document the proposed solution to protect procfs entries Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 4/9] procfs: make /proc/*/{stack,syscall} 0400 Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 5/9] procfs: make /proc entries that use seq files able to access file->f_cred Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 6/9] procfs: add permission checks on the file's opener of /proc/*/stat Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-02 1:39 ` [kernel-hardening] " Andy Lutomirski
2013-10-02 1:39 ` Andy Lutomirski
2013-10-02 15:14 ` Djalal Harouni [this message]
2013-10-02 15:14 ` Djalal Harouni
2013-10-02 16:46 ` [kernel-hardening] " Andy Lutomirski
2013-10-02 16:46 ` Andy Lutomirski
2013-10-02 19:00 ` [kernel-hardening] " Djalal Harouni
2013-10-02 19:00 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 7/9] procfs: add permission checks on the file's opener of /proc/*/personality Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 8/9] procfs: improve permission checks on /proc/*/stack Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-01 20:26 ` [kernel-hardening] [PATCH v2 9/9] procfs: improve permission checks on /proc/*/syscall Djalal Harouni
2013-10-01 20:26 ` Djalal Harouni
2013-10-02 1:40 ` [kernel-hardening] Re: [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Andy Lutomirski
2013-10-02 1:40 ` Andy Lutomirski
2013-10-02 14:37 ` [kernel-hardening] " Djalal Harouni
2013-10-02 14:37 ` Djalal Harouni
2013-10-02 16:51 ` [kernel-hardening] " Andy Lutomirski
2013-10-02 16:51 ` Andy Lutomirski
2013-10-02 17:48 ` [kernel-hardening] " Kees Cook
2013-10-02 17:48 ` Kees Cook
2013-10-02 18:00 ` [kernel-hardening] " Andy Lutomirski
2013-10-02 18:00 ` Andy Lutomirski
2013-10-02 18:07 ` [kernel-hardening] " Kees Cook
2013-10-02 18:07 ` Kees Cook
2013-10-03 23:14 ` [kernel-hardening] " Julien Tinnes
2013-10-03 23:14 ` Julien Tinnes
2013-10-02 18:26 ` [kernel-hardening] " Djalal Harouni
2013-10-02 18:26 ` Djalal Harouni
2013-10-02 18:41 ` [kernel-hardening] " Djalal Harouni
2013-10-02 18:41 ` Djalal Harouni
2013-10-02 18:22 ` [kernel-hardening] " Djalal Harouni
2013-10-02 18:22 ` Djalal Harouni
2013-10-02 18:35 ` [kernel-hardening] " Kees Cook
2013-10-02 18:35 ` Kees Cook
2013-10-02 18:48 ` [kernel-hardening] " Djalal Harouni
2013-10-02 18:48 ` Djalal Harouni
2013-10-02 19:43 ` [kernel-hardening] " Kees Cook
2013-10-02 19:43 ` Kees Cook
2013-10-03 6:12 ` [kernel-hardening] " Ingo Molnar
2013-10-03 6:12 ` Ingo Molnar
2013-10-03 12:29 ` [kernel-hardening] " Djalal Harouni
2013-10-03 12:29 ` Djalal Harouni
2013-10-03 15:15 ` [kernel-hardening] " Andy Lutomirski
2013-10-03 15:15 ` Andy Lutomirski
2013-10-03 15:40 ` [kernel-hardening] " Djalal Harouni
2013-10-03 15:40 ` Djalal Harouni
2013-10-03 15:50 ` [kernel-hardening] " Andy Lutomirski
2013-10-03 15:50 ` Andy Lutomirski
2013-10-03 18:37 ` [kernel-hardening] " Djalal Harouni
2013-10-03 18:37 ` Djalal Harouni
2013-10-04 9:05 ` [kernel-hardening] " Djalal Harouni
2013-10-04 9:05 ` Djalal Harouni
2013-10-02 18:12 ` [kernel-hardening] " Djalal Harouni
2013-10-02 18:12 ` Djalal Harouni
2013-10-03 6:22 ` [kernel-hardening] " Ingo Molnar
2013-10-03 6:22 ` Ingo Molnar
2013-10-03 12:56 ` [kernel-hardening] " Djalal Harouni
2013-10-03 12:56 ` Djalal Harouni
2013-10-03 13:39 ` [kernel-hardening] " Ingo Molnar
2013-10-03 13:39 ` Ingo Molnar
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=20131002151430.GB2669@dztty \
--to=tixxdz@opendz.org \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=gorcunov@openvz.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=rientjes@google.com \
--cc=serge.hallyn@ubuntu.com \
--cc=tixxdz@gmail.com \
--cc=torvalds@linux-foundation.org \
--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.