Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data

[Andy Lutomirski]

On Fri, Jul 25, 2014 at 11:22 AM, Julien Tinnes <jln@xxxxxxxxxx> wrote:
> On Fri, Jul 25, 2014 at 10:38 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>>
>> On Fri, Jul 25, 2014 at 10:18 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx>
>> wrote:
>> > [cc: Eric Biederman]
>> >
>> > On Fri, Jul 25, 2014 at 10:10 AM, Kees Cook <keescook@xxxxxxxxxxxx>
>> > 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.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/