Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check iffile's opener may access task

[Djalal Harouni]

On Wed, Oct 09, 2013 at 06:27:22PM +0100, Andy Lutomirski wrote:
> On Wed, Oct 9, 2013 at 11:54 AM, Djalal Harouni <tixxdz@xxxxxxxxxx> wrote:
> > On Mon, Oct 07, 2013 at 02:41:33PM -0700, Andy Lutomirski wrote:
> >> On Sat, Oct 5, 2013 at 6:23 AM, Djalal Harouni <tixxdz@xxxxxxxxxx> wrote:
> >> > On Fri, Oct 04, 2013 at 03:17:08PM -0700, Andy Lutomirski wrote:
> >> >>
> >> >> Exactly.  Hence the NAK.
> >> > But Having two LSM Hooks there is really not practical!
> >>
> >> It'd doable *if* it turns out that it's the right solution.
> >>
> >> But revoke seems much more likely to be simple, comprehensible, and
> >> obviously correct to me.
> > Yes Andy, I agree, revoke is much better!
> >
> > But it will not handle or fix all the situations, as I've said what if
> > revoke is not invloved here? there is no an execve from the target task!
> >
> >
> > Remember:
> > /proc/*/{stat,maps} and perhaps others have 0444 and don't have ptrace
> > checks during ->open() to not break some userspace... especially
> > /proc/*/stat file
> 
> For /proc/*/stat: check permissions when opening.  If the opener
> passes the ptrace check, set a flag in file->private_data indicating
> that this struct file has permission.
That will fix it, but it will need some extra work since
file->private_data is already used to store seq_file structs!

> For /proc/*/maps: either fail the open if the check fails or set a
> flag that causes the resulting struct file to be useless.
Not sure about this, we need to inspect glibc


> >
> >
> > So you will have an fd on these privileged files!
> >
> > Current will execve a privileged process, and pass ptrace_may_access()
> > checks during ->read()...
> >
> > Here revoke is not involved at all! so it will not fix these files and
> > they will continue to be vulnerable.
> >
> > IMO to fix them, we must have the correct ptrace_may_access() check and
> > this involves: current doing an execve + current's cred
> >
> >
> >
> > BTW, Andy we already return 0 (end of file) for /proc/*/mem
> >   ->read()
> >     ->mem_read()
> >       ->mem_rw()
> >         if (!atomic_inc_not_zero(&mm->mm_users))
> >                 return 0
> >
> > So can this be considered some sort of simple revoke?
> >
> 
> Apparently not.  I haven't looked at the code, but I just tried it.
> The fd from /proc/<pid>/maps survives an exec of the process it's
> pointing at.  That means that either the mm changing has no effect on
> the struct file or that an unshared mm survives exec.
yes the old mm (during ->open()) will survive but not vma, ->read() will
return zero

In the mean time, to close some of these vulnerabilities, I'll submit
another patch to prevent open() arbitrary /proc/*/{stack,syscall}

1) Make them 0400
2) Add the ptrace_may_access() during ->open() for ptrace capabilities
   and LSM checks

It would be nice to get your Acked-by Andy!

-- 
Djalal Harouni
http://opendz.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/