linux-kernel - Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp

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] [day] [month] [year] [list]

Message-ID: <CAHse=S-9L5no=+R6Oh4KcMZ6C2sK+7EVLckuQikQgmA+MFD2oA@mail.gmail.com>
Date:	Sun, 27 Jul 2014 13:10:10 +0100
From:	David Drysdale <drysdale@...gle.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Julien Tinnes <jln@...gle.com>, Kees Cook <keescook@...omium.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Paolo Bonzini <pbonzini@...hat.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Paul Moore <paul@...l-moore.com>,
	James Morris <james.l.morris@...cle.com>,
	Linux API <linux-api@...r.kernel.org>,
	Meredydd Luff <meredydd@...atehouse.org>,
	Christoph Hellwig <hch@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data

On Fri, Jul 25, 2014 at 7:32 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Fri, Jul 25, 2014 at 11:22 AM, Julien Tinnes <jln@...gle.com> wrote:
>> On Fri, Jul 25, 2014 at 10:38 AM, Kees Cook <keescook@...omium.org> wrote:
>>>
>>> On Fri, Jul 25, 2014 at 10:18 AM, Andy Lutomirski <luto@...capital.net>
>>> wrote:
>>> > [cc: Eric Biederman]
>>> >
>>> > On Fri, Jul 25, 2014 at 10:10 AM, Kees Cook <keescook@...omium.org>
>>> > wrote:
>>>
>>> >> Julien had been wanting something like this too (though he'd suggested
>>> >> it via prctl): limit the signal functions to "self" only. I wonder if
>>> >> adding a prctl like done for O_BENEATH could work for signal sending?
>>> >>
>>> >
>>> >
>>> > Can we do one better and add a flag to prevent any non-self pid
>>> > lookups?  This might actually be easy on top of the pid namespace work
>>> > (e.g. we could change the way that find_task_by_vpid works).
>>>
>>> Ooh, that would be extremely interesting, yes. Kind of an extreme form
>>> of pid namespace without actually being a namespace.
>>>
>>> > It's far from just being signals.  There's access_process_vm, ptrace,
>>> > all the signal functions, clock_gettime (see CPUCLOCK_PID -- yes, this
>>> > is ridiculous), and probably some others that I've forgotten about or
>>> > never noticed in the first place.
>>>
>>> Yeah, that would be very interesting.
>>
>>
>> Yes, this would be incredibly useful.
>>
>> 1. For Chromium [1], I dislike relying on seccomp purely for
>> "access-control" (to other processes or files). Because it's really hard to
>> think about everything (things like CPUCLOCK_PID bite, see
>> https://crbug.com/374479).
>
> Not public :(
>
>> Se we have a first layer of sandboxing (using PID + NET namespaces and
>> chroot) for "access-control" and a second layer for kernel attack surface
>> reduction and a few other things using seccomp-bpf.
>>
>> The first layer isn't currently very good; it's heavyweight and complex (you
>> need an init(1) per namespace and that init cannot be multi-purposed as a
>> useful process because pid = 1 can never receive signals). One PID namespace
>> per process isn't something that scales well. (Also before USER_NS it
>> required a setuid root program).
>>
>> 2. Even with a safe pure seccomp-bpf sandbox that prevents sending signals
>> to other process / ptrace() et al and that restrict clock_gettime(2)
>> properly, things become quickly very tedious because as far as the kernel is
>> concerned, the process under this BPF program can still pass
>> ptrace_may_access() to other processes. This means for instance that no
>> matter what you do, a model where open() is allowed can't work if /proc is
>> available. We need a mode that says "ptrace_may_access()" will never pass.
>>
>> So yes, I really would like:
>> - a prctl that says: "I'm dropping privileges and I now can't interact with
>> other thread groups (via signals, ptrace, etc..)".
>> - Something to drop access to the file system. It could be an unprivileged
>> way to chroot() to an empty directory (unprivileged namespaces work for
>> that, - except if you're already in a chroot -). This is a little tricky
>> without allowing chroot escapes, so I suspect we would want to express it in
>> terms of mount namespace, or something else, rather than chroot.
>
> Capsicum will give you this.

Yep, that's the idea.  As long as there aren't any open DFDs for "/proc" on
entry to capability mode, there shouldn't be a way to access it later -- but it
is still possible to openat(2) new files (relative to a pre-opened DFD).

> See the other thread for a more concrete proposal.  prctl is getting
> out of hand.
>
> --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/