[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] I am working on seccomp integration into docker for project Atomic.
- From: Daniel J Walsh <dwalsh redhat com>
- To: Jon Stanley <jonstanley gmail com>
- Cc: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] I am working on seccomp integration into docker for project Atomic.
- Date: Tue, 28 Oct 2014 08:56:52 -0400
On 10/28/2014 08:47 AM, Jon Stanley wrote:
> On Tue, Oct 28, 2014 at 7:59 AM, Daniel J Walsh <dwalsh redhat com> wrote:
>
>> syscalls, by default. On an X86_64 system x32 and i686 syscalls will be
>> eliminated.
> This seems problematic in the fact that you couldn't then run a 32-bit
> application in a container, unless I'm missing something.
There will be options to allow you to add back in 32 bit support.
>> Sandstorm also blocks ptrace, which I am also thinking of adding.
> Again, for debug, I've used strace inside a container, so some sort of
> way to allow this (without the big hammer of --privileged) would be
> required, I think.
Again you can add/remove any syscalls using CLI I am thinking of
docker run --security-opt seccomp:add:ptrace ...
>> I would like to have other people input, on other syscalls that we
>> should add, or ones that should not be on the list.
> I assume that a privileged container will not be subject to these
> restrictions, right? I've done some initial work on containerizing 3rd
> party things that use kernel modules, and thus far I've been able to
> run them in a privileged container. I wouldn't expect that to change
> as a result of this.
Yes --privileged will continue to turn off all Security measures.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]