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