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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html