From: Kees Cook <keescook@chromium.org>
To: Andrea Righi <andrea.righi@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Christian Brauner <christian.brauner@ubuntu.com>,
regressions@lists.linux.dev
Subject: Re: Regression when writing to /proc/<pid>/attr/
Date: Tue, 8 Jun 2021 10:03:40 -0700 [thread overview]
Message-ID: <202106081003.2BECE93@keescook> (raw)
In-Reply-To: <YL8Rwb1Pnbdwk0xc@xps-13-7390>
On Tue, Jun 08, 2021 at 08:44:17AM +0200, Andrea Righi wrote:
> On Mon, Jun 07, 2021 at 07:15:36PM -0700, Kees Cook wrote:
> > On Mon, Jun 07, 2021 at 05:02:28PM -0700, Linus Torvalds wrote:
> > > On Mon, Jun 7, 2021 at 4:38 PM Kees Cook <keescook@chromium.org> wrote:
> > > >
> > > > I'm assuming the issue is the latter (open, drop privs, write). And
> > > > I assume fsuid/fsgid has changed? (i.e. cred_fscmp() couldn't be used
> > > > either?)
> > >
> > > Hmm. Do we have some place to hide self_exec_id at open time, and then
> > > just verify that it's still the same at IO time?
> > >
> > > IOW, replace that f_cred comparison with a "self_exec_id has not
> > > changed" comparison instead?
> >
> > I think we can't use self_exec_id because the original flaw could just
> > be changed to have the parent open two children (the fd opener and the
> > victim), which would have the same self_exec_id.
> >
> > > Perhaps squirrel it away in file->f_private? Or are we already using
> > > that (didn't check)?
> >
> > But we can do tracking via file->private_data since the attr files don't
> > use a custom opener. I think an mm_struct comparison is likely what's
> > needed here? (This is actually what several of these special proc files
> > are already doing, but they actually _use_ mm_struct.)
> >
> > UNTESTED:
>
> Thanks Kees! Comparing mm_struct makes sense to me. With this applied
> the regression that I was experiencing with containers doesn't happen
> anymore.
>
> I'll run more stress tests with this, but for now it looks good to me,
> so FWIW:
>
> Tested-by: Andrea Righi <andrea.righi@canonical.com>
Oh good! Thanks for testing and sorry for the extra work I created! I'll
get this spun up into a proper patch.
-Kees
>
> >
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index 58bbf334265b..7118ebe38fa6 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -2674,6 +2674,11 @@ static int proc_pident_readdir(struct file *file, struct dir_context *ctx,
> > }
> >
> > #ifdef CONFIG_SECURITY
> > +static int proc_pid_attr_open(struct inode *inode, struct file *file)
> > +{
> > + return __mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
> > +}
> > +
> > static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,
> > size_t count, loff_t *ppos)
> > {
> > @@ -2704,7 +2709,7 @@ static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,
> > int rv;
> >
> > /* A task may only write when it was the opener. */
> > - if (file->f_cred != current_real_cred())
> > + if (file->private_data != current->mm)
> > return -EPERM;
> >
> > rcu_read_lock();
> > @@ -2754,9 +2759,11 @@ static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,
> > }
> >
> > static const struct file_operations proc_pid_attr_operations = {
> > + .open = proc_pid_attr_open,
> > .read = proc_pid_attr_read,
> > .write = proc_pid_attr_write,
> > .llseek = generic_file_llseek,
> > + .release = mem_release,
> > };
> >
> > #define LSM_DIR_OPS(LSM) \
> >
> > --
> > Kees Cook
--
Kees Cook
next prev parent reply other threads:[~2021-06-08 17:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 14:22 Regression when writing to /proc/<pid>/attr/ Christian Brauner
2021-06-07 23:38 ` Kees Cook
2021-06-08 0:02 ` Linus Torvalds
2021-06-08 2:15 ` Kees Cook
2021-06-08 6:44 ` Andrea Righi
2021-06-08 17:03 ` Kees Cook [this message]
2021-06-08 11:59 ` Christian Brauner
2021-06-08 16:39 ` Linus Torvalds
2021-06-08 8:51 ` Christian Brauner
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=202106081003.2BECE93@keescook \
--to=keescook@chromium.org \
--cc=andrea.righi@canonical.com \
--cc=christian.brauner@ubuntu.com \
--cc=regressions@lists.linux.dev \
--cc=torvalds@linux-foundation.org \
/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.