On Fri, Jul 25, 2014 at 10:38 AM, Kees Cook [off-list ref] wrote:

On Fri, Jul 25, 2014 at 10:18 AM, Andy Lutomirski [off-list ref] wrote:

quoted

[cc: Eric Biederman]

On Fri, Jul 25, 2014 at 10:10 AM, Kees Cook [off-list ref] wrote:

quoted

quoted

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.

quoted

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,
seehttps://crbug.com/374479).
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.

Then we have the primitives  we need to build sandboxes in a simple
way and we can add seccomp-bpf on top to do things such as open()
hooking (via SECCOMP_RET_TRAP) and to restrict the kernel attack
surface.

Julien

[1] https://code.google.com/p/chromium/wiki/LinuxSandboxing