linux-kernel - Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Oct 2013 12:16:26 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Djalal Harouni <tixxdz@...ndz.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Kees Cook <keescook@...omium.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	David Rientjes <rientjes@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	Djalal Harouni <tixxdz@...il.com>
Subject: Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's
 opener may access task

On Fri, Oct 4, 2013 at 12:11 PM, Djalal Harouni <tixxdz@...ndz.org> wrote:
> On Fri, Oct 04, 2013 at 07:34:08PM +0100, Andy Lutomirski wrote:
>> On Fri, Oct 4, 2013 at 7:23 PM, Djalal Harouni <tixxdz@...ndz.org> wrote:
>> > On Fri, Oct 04, 2013 at 04:40:01PM +0100, Andy Lutomirski wrote:
>> >> On Fri, Oct 4, 2013 at 9:59 AM, Djalal Harouni <tixxdz@...ndz.org> wrote:
>> >> > On Thu, Oct 03, 2013 at 02:09:55PM -0700, Andy Lutomirski wrote:
> [...]
>> Sorry, I described the obviously broken scenario incorrectly.  Your
>> patch breaks (in the absence of things like selinux) if a exec
>> something setuid root.
>>
>> [...]
>>
>> >
>> > I did the check in the proc_same_open_cred() function:
>> >  return (uid_eq(fcred->uid, cred->uid) &&
>> >          gid_eq(fcred->gid, cred->gid) &&
>> >          cap_issubset(cred->cap_permitted, fcred->cap_permitted));
>>
>> Which has nothing to do with anything.  If that check fails, you're
>> just going on to a different, WRONG check/.
>>
>> >
>> > Check if this is the same uid/gid and the capabilities superset!
>> >
>> > But in the proc_allow_access() the capabilities superset is missing.
>> >
>> >
>> > So to fix it:
>> > 1) if proc_same_open_cred() detects that cred have changed between
>> > ->open() and ->read() then abort, return zero, the ->read(),write()...
>>
>> IMO yuck.
>>
>> >
>> >
>> > 2) Improve the proc_allow_access() check by:
>> >    if this is the same user namespace then check uid/gid of f_cred on
>> >    target cred task, and the capabilities superset:
>> >    cap_issubset(tcred->cap_permitted, fcred->cap_permitted));
>> >
>> >    If it fails let security_capable() or file_ns_capable() do its magic.
>> >
>>
>> NAK.  You need to actually call the LSM.  What if the reason to fail
>> the request isn't that the writer gained capabilities -- what if the
>> writer's selinux label changed?
> Sorry I can't follow you here! Can you be more explicit please?
>
> For me we are already doing this during ptrace_may_access() on each
> syscall, which will call LSM to inspect the privileges on each ->open(),
> ->write()... So LSM hooks are already called. If you want to have more
> LSM hooks, then perhaps that's another problem?

Can you show me where, in your code, LSMs are asked whether the
process calling read() is permitted to ptrace the process that the
proc file points at?

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