Re: [atomic-devel] I am working on seccomp integration into docker for project Atomic.

[Colin Walters <walters verbum org>]

On Tue, Oct 28, 2014, at 07:59 AM, Daniel J Walsh wrote:
>
> At this time coming up with a whitelist, would just about be
> impossible.  I am concentrating on creating a reasonable list of
> syscalls, that should not be allowed within a non-privileged container. 
> Then we can allow an admin to add/remove syscalls using the docker run
> CLI.

This sounds reasonable - we know name_to_handle_at() and such should
always be banned.

> The idea is to limit the attack surface of the kernel.  Just turning on
> seccomp within a docker container will eliminate all non-native
> syscalls, by default.  On an X86_64 system x32 and i686 syscalls will be
> eliminated.

This sounds less reasonable.  The way I see this is we have an ad-hoc
informally specified ABI between the host and container.  Docker
containers
embed everything except the kernel, so *theoretically* they're isolated.

Except in reality, Docker injects things like /etc/resolv.conf.  This
works because
let's be realistic - everyone uses a libc that understands
/etc/resolv.conf[1].
But it starts to get fuzzy if we talk about injecting more things.

And if we start axing off things like 32 bit system calls, it will
almost certainly break apps.

I'd say that we need some sort of explicit versioned ABI, and containers
should
also have the ability to tell the host they want to opt in to stronger
security classes,
like 32 bit filtering.

[1] Except
https://lists.fedoraproject.org/pipermail/devel/2014-April/198706.html
is looming still...