From: Andy Lutomirski <luto@amacapital.net> To: Djalal Harouni <tixxdz@opendz.org> 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 FS Devel <linux-fsdevel@vger.kernel.org>, kernel-hardening@lists.openwall.com, Djalal Harouni <tixxdz@gmail.com> Subject: Re: [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Date: Wed, 2 Oct 2013 17:51:15 +0100 [thread overview] Message-ID: <CALCETrUcg4o5QeGMP1rRAzJSfjwS=qD3DsDWV3=fPJQOA3xkKw@mail.gmail.com> (raw) In-Reply-To: <20131002143759.GA2966@dztty> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni <tixxdz@opendz.org> wrote: > On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote: >> On 10/01/2013 01:26 PM, Djalal Harouni wrote: >> > /proc/<pid>/* entries varies at runtime, appropriate permission checks >> > need to happen during each system call. >> > >> > Currently some of these sensitive entries are protected by performing >> > the ptrace_may_access() check. However even with that the /proc file >> > descriptors can be passed to a more privileged process >> > (e.g. a suid-exec) which will pass the classic ptrace_may_access() >> > check. In general the ->open() call will be issued by an unprivileged >> > process while the ->read(),->write() calls by a more privileged one. >> > >> > Example of these files are: >> > /proc/*/syscall, /proc/*/stack etc. >> > >> > And any open(/proc/self/*) then suid-exec to read()/write() /proc/self/* >> > >> > >> > These files are protected during read() by the ptrace_may_access(), >> > however the file descriptor can be passed to a suid-exec which can be >> > used to read data and bypass ASLR. Of course this was discussed several >> > times on LKML. >> >> Can you elaborate on what it is that you're fixing? That is, can you >> give a concrete example of what process opens what file and passes the >> fd to what process? > Yes, the references were already given in this email: > https://lkml.org/lkml/2013/8/31/209 > > This has been discussed several times on lkml: > https://lkml.org/lkml/2013/8/28/544 > > https://lkml.org/lkml/2013/8/28/564 (check Kees's references) > > >> I'm having trouble following your description. > Process open a /proc file and pass the fd to a more privilaged process > that will pass the ptrace_may_access() check, while the original process > that opened that file should fail at the ptrace_may_access() So we're talking about two kinds of attacks, right? Type 1: Unprivileged process does something like open("/proc/1/maps", O_RDONLY) and then passes the resulting fd to something privileged. Type 2: Unprivileged process does something like open("/proc/self/maps", O_RDONLY) and then forks. The parent calls execve on something privileged. Can we really not get away with fixing type 1 by preventing these files from being opened in the first place and type 2 by revoking all of these fds when a privilege-changing exec happens? I'm not objecting to your patches so much as thinking that read(2) has no business looking at current->cred *at all*. But maybe that ship has already sailed. --Andy > > >> --Andy >> > > -- > Djalal Harouni > http://opendz.org -- Andy Lutomirski AMA Capital Management, LLC
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net> To: Djalal Harouni <tixxdz@opendz.org> 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 FS Devel <linux-fsdevel@vger.kernel.org>, kernel-hardening@lists.openwall.com, Djalal Harouni <tixxdz@gmail.com> Subject: [kernel-hardening] Re: [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Date: Wed, 2 Oct 2013 17:51:15 +0100 [thread overview] Message-ID: <CALCETrUcg4o5QeGMP1rRAzJSfjwS=qD3DsDWV3=fPJQOA3xkKw@mail.gmail.com> (raw) In-Reply-To: <20131002143759.GA2966@dztty> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni <tixxdz@opendz.org> wrote: > On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote: >> On 10/01/2013 01:26 PM, Djalal Harouni wrote: >> > /proc/<pid>/* entries varies at runtime, appropriate permission checks >> > need to happen during each system call. >> > >> > Currently some of these sensitive entries are protected by performing >> > the ptrace_may_access() check. However even with that the /proc file >> > descriptors can be passed to a more privileged process >> > (e.g. a suid-exec) which will pass the classic ptrace_may_access() >> > check. In general the ->open() call will be issued by an unprivileged >> > process while the ->read(),->write() calls by a more privileged one. >> > >> > Example of these files are: >> > /proc/*/syscall, /proc/*/stack etc. >> > >> > And any open(/proc/self/*) then suid-exec to read()/write() /proc/self/* >> > >> > >> > These files are protected during read() by the ptrace_may_access(), >> > however the file descriptor can be passed to a suid-exec which can be >> > used to read data and bypass ASLR. Of course this was discussed several >> > times on LKML. >> >> Can you elaborate on what it is that you're fixing? That is, can you >> give a concrete example of what process opens what file and passes the >> fd to what process? > Yes, the references were already given in this email: > https://lkml.org/lkml/2013/8/31/209 > > This has been discussed several times on lkml: > https://lkml.org/lkml/2013/8/28/544 > > https://lkml.org/lkml/2013/8/28/564 (check Kees's references) > > >> I'm having trouble following your description. > Process open a /proc file and pass the fd to a more privilaged process > that will pass the ptrace_may_access() check, while the original process > that opened that file should fail at the ptrace_may_access() So we're talking about two kinds of attacks, right? Type 1: Unprivileged process does something like open("/proc/1/maps", O_RDONLY) and then passes the resulting fd to something privileged. Type 2: Unprivileged process does something like open("/proc/self/maps", O_RDONLY) and then forks. The parent calls execve on something privileged. Can we really not get away with fixing type 1 by preventing these files from being opened in the first place and type 2 by revoking all of these fds when a privilege-changing exec happens? I'm not objecting to your patches so much as thinking that read(2) has no business looking at current->cred *at all*. But maybe that ship has already sailed. --Andy > > >> --Andy >> > > -- > Djalal Harouni > http://opendz.org -- Andy Lutomirski AMA Capital Management, LLC
next prev parent reply other threads:[~2013-10-02 16:51 UTC|newest] Thread overview: 179+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-10-01 20:26 [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 1/9] procfs: add proc_same_open_cred() to check if the cred have changed Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [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 ` [kernel-hardening] " Djalal Harouni 2013-10-02 1:36 ` Andy Lutomirski 2013-10-02 1:36 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 14:55 ` Djalal Harouni 2013-10-02 14:55 ` [kernel-hardening] " Djalal Harouni 2013-10-02 16:44 ` Andy Lutomirski 2013-10-02 16:44 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 14:36 ` Djalal Harouni 2013-10-03 14:36 ` [kernel-hardening] " Djalal Harouni 2013-10-03 15:12 ` Andy Lutomirski 2013-10-03 15:12 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 15:12 ` Andy Lutomirski 2013-10-03 19:29 ` Djalal Harouni 2013-10-03 19:29 ` [kernel-hardening] " Djalal Harouni 2013-10-03 19:29 ` Djalal Harouni 2013-10-03 19:37 ` Andy Lutomirski 2013-10-03 19:37 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 19:37 ` Andy Lutomirski 2013-10-03 20:13 ` Djalal Harouni 2013-10-03 20:13 ` [kernel-hardening] " Djalal Harouni 2013-10-03 20:13 ` Djalal Harouni 2013-10-03 21:09 ` Andy Lutomirski 2013-10-03 21:09 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 21:09 ` Andy Lutomirski 2013-10-04 8:59 ` Djalal Harouni 2013-10-04 8:59 ` [kernel-hardening] " Djalal Harouni 2013-10-04 8:59 ` Djalal Harouni 2013-10-04 15:40 ` Andy Lutomirski 2013-10-04 15:40 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 15:40 ` Andy Lutomirski 2013-10-04 18:23 ` Djalal Harouni 2013-10-04 18:23 ` [kernel-hardening] " Djalal Harouni 2013-10-04 18:23 ` Djalal Harouni 2013-10-04 18:34 ` Andy Lutomirski 2013-10-04 18:34 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 18:34 ` Andy Lutomirski 2013-10-04 19:11 ` Djalal Harouni 2013-10-04 19:11 ` [kernel-hardening] " Djalal Harouni 2013-10-04 19:11 ` Djalal Harouni 2013-10-04 19:16 ` Andy Lutomirski 2013-10-04 19:16 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 19:16 ` Andy Lutomirski 2013-10-04 19:27 ` Djalal Harouni 2013-10-04 19:27 ` [kernel-hardening] " Djalal Harouni 2013-10-04 19:27 ` Djalal Harouni 2013-10-04 19:32 ` Andy Lutomirski 2013-10-04 19:32 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 19:32 ` Andy Lutomirski 2013-10-04 19:41 ` Djalal Harouni 2013-10-04 19:41 ` [kernel-hardening] " Djalal Harouni 2013-10-04 19:41 ` Djalal Harouni 2013-10-04 22:17 ` Andy Lutomirski 2013-10-04 22:17 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 22:17 ` Andy Lutomirski 2013-10-04 22:55 ` Eric W. Biederman 2013-10-04 22:55 ` [kernel-hardening] " Eric W. Biederman 2013-10-04 22:55 ` Eric W. Biederman 2013-10-04 22:59 ` Andy Lutomirski 2013-10-04 22:59 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 22:59 ` Andy Lutomirski 2013-10-04 23:08 ` Andy Lutomirski 2013-10-04 23:08 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 23:08 ` Andy Lutomirski 2013-10-05 0:35 ` Eric W. Biederman 2013-10-05 0:35 ` [kernel-hardening] " Eric W. Biederman 2013-10-05 0:35 ` Eric W. Biederman 2013-10-09 10:35 ` Djalal Harouni 2013-10-09 10:35 ` [kernel-hardening] " Djalal Harouni 2013-10-09 10:35 ` Djalal Harouni 2013-10-05 13:23 ` Djalal Harouni 2013-10-05 13:23 ` [kernel-hardening] " Djalal Harouni 2013-10-05 13:23 ` Djalal Harouni 2013-10-07 21:41 ` Andy Lutomirski 2013-10-07 21:41 ` [kernel-hardening] " Andy Lutomirski 2013-10-07 21:41 ` Andy Lutomirski 2013-10-09 10:54 ` Djalal Harouni 2013-10-09 10:54 ` [kernel-hardening] " Djalal Harouni 2013-10-09 10:54 ` Djalal Harouni 2013-10-09 11:15 ` Djalal Harouni 2013-10-09 11:15 ` [kernel-hardening] " Djalal Harouni 2013-10-09 11:15 ` Djalal Harouni 2013-10-09 17:27 ` Andy Lutomirski 2013-10-09 17:27 ` [kernel-hardening] " Andy Lutomirski 2013-10-09 17:27 ` Andy Lutomirski 2013-10-13 10:18 ` Djalal Harouni 2013-10-13 10:18 ` [kernel-hardening] " Djalal Harouni 2013-10-13 10:18 ` Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 3/9] procfs: Document the proposed solution to protect procfs entries Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 4/9] procfs: make /proc/*/{stack,syscall} 0400 Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [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 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 6/9] procfs: add permission checks on the file's opener of /proc/*/stat Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-02 1:39 ` Andy Lutomirski 2013-10-02 1:39 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 15:14 ` Djalal Harouni 2013-10-02 15:14 ` [kernel-hardening] " Djalal Harouni 2013-10-02 16:46 ` Andy Lutomirski 2013-10-02 16:46 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 19:00 ` Djalal Harouni 2013-10-02 19:00 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 7/9] procfs: add permission checks on the file's opener of /proc/*/personality Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 8/9] procfs: improve permission checks on /proc/*/stack Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 9/9] procfs: improve permission checks on /proc/*/syscall Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-02 1:40 ` [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Andy Lutomirski 2013-10-02 1:40 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 14:37 ` Djalal Harouni 2013-10-02 14:37 ` [kernel-hardening] " Djalal Harouni 2013-10-02 16:51 ` Andy Lutomirski [this message] 2013-10-02 16:51 ` Andy Lutomirski 2013-10-02 17:48 ` Kees Cook 2013-10-02 17:48 ` [kernel-hardening] " Kees Cook 2013-10-02 17:48 ` Kees Cook 2013-10-02 18:00 ` Andy Lutomirski 2013-10-02 18:00 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 18:00 ` Andy Lutomirski 2013-10-02 18:07 ` Kees Cook 2013-10-02 18:07 ` [kernel-hardening] " Kees Cook 2013-10-02 18:07 ` Kees Cook 2013-10-03 23:14 ` Julien Tinnes 2013-10-03 23:14 ` [kernel-hardening] " Julien Tinnes 2013-10-03 23:14 ` Julien Tinnes 2013-10-02 18:26 ` Djalal Harouni 2013-10-02 18:26 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:26 ` Djalal Harouni 2013-10-02 18:41 ` Djalal Harouni 2013-10-02 18:41 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:41 ` Djalal Harouni 2013-10-02 18:22 ` Djalal Harouni 2013-10-02 18:22 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:22 ` Djalal Harouni 2013-10-02 18:35 ` Kees Cook 2013-10-02 18:35 ` [kernel-hardening] " Kees Cook 2013-10-02 18:35 ` Kees Cook 2013-10-02 18:48 ` Djalal Harouni 2013-10-02 18:48 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:48 ` Djalal Harouni 2013-10-02 19:43 ` Kees Cook 2013-10-02 19:43 ` [kernel-hardening] " Kees Cook 2013-10-02 19:43 ` Kees Cook 2013-10-03 6:12 ` Ingo Molnar 2013-10-03 6:12 ` [kernel-hardening] " Ingo Molnar 2013-10-03 6:12 ` Ingo Molnar 2013-10-03 12:29 ` Djalal Harouni 2013-10-03 12:29 ` [kernel-hardening] " Djalal Harouni 2013-10-03 12:29 ` Djalal Harouni 2013-10-03 15:15 ` Andy Lutomirski 2013-10-03 15:15 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 15:15 ` Andy Lutomirski 2013-10-03 15:40 ` Djalal Harouni 2013-10-03 15:40 ` [kernel-hardening] " Djalal Harouni 2013-10-03 15:40 ` Djalal Harouni 2013-10-03 15:50 ` Andy Lutomirski 2013-10-03 15:50 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 15:50 ` Andy Lutomirski 2013-10-03 18:37 ` Djalal Harouni 2013-10-03 18:37 ` [kernel-hardening] " Djalal Harouni 2013-10-03 18:37 ` Djalal Harouni 2013-10-04 9:05 ` Djalal Harouni 2013-10-04 9:05 ` [kernel-hardening] " Djalal Harouni 2013-10-04 9:05 ` Djalal Harouni 2013-10-02 18:12 ` Djalal Harouni 2013-10-02 18:12 ` [kernel-hardening] " Djalal Harouni 2013-10-03 6:22 ` Ingo Molnar 2013-10-03 6:22 ` [kernel-hardening] " Ingo Molnar 2013-10-03 12:56 ` Djalal Harouni 2013-10-03 12:56 ` [kernel-hardening] " Djalal Harouni 2013-10-03 13:39 ` Ingo Molnar 2013-10-03 13:39 ` [kernel-hardening] " 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='CALCETrUcg4o5QeGMP1rRAzJSfjwS=qD3DsDWV3=fPJQOA3xkKw@mail.gmail.com' \ --to=luto@amacapital.net \ --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=mingo@kernel.org \ --cc=rientjes@google.com \ --cc=serge.hallyn@ubuntu.com \ --cc=tixxdz@gmail.com \ --cc=tixxdz@opendz.org \ --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: linkBe 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.