Skip to content

Change seccomp blacklist to a whitelist #18979

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jan 6, 2016
Merged

Conversation

jessfraz
Copy link
Contributor

Running various tests on official images, but opening the discussion. ping @justincormack

@phemmer
Copy link
Contributor

phemmer commented Dec 29, 2015

I was wondering why we weren't using a whitelist instead. The whitelist makes more sense to me for one main reason: default action is secure (http://stackoverflow.com/a/504424/486035).
With a blacklist, even if we blacklisted every possible syscall that could be abused, new kernels can come out which introduce new syscalls, and if docker's blacklist is old, it won't protect them.

👍

@jessfraz jessfraz added this to the 1.10 milestone Dec 29, 2015
@jessfraz
Copy link
Contributor Author

does this mean you will compile seccomp into your binary now 0:)

@cpuguy83
Copy link
Member

SGTM

@thaJeztah
Copy link
Member

Using a white list sounds like a better approach to me, so +1

Tentatively moving this to code review

@justincormack
Copy link
Contributor

The clone rule needs fixing, will send patch. Ah sorry this was done I missed the commit.

I am slightly inclined to add back in the comments from the blacklisted syscalls as documentation of the ones not in the whitelist, not sure what anyone thinks.

@justincormack
Copy link
Contributor

Ok I have tested this extensively: tested that individual syscalls are being correctly filtered, used it as my default docker install and built stuff (eg docker/docker, Linux kernel compile), double checked the syscall list for 32 bits, arm, powerpc. So LGTM.

For reference easiest way to check individual syscalls being filtered is:

docker run -it --cap-add ALL justincormack/ljsyscall -e "print(require('syscall').acct('/tmp/t'))"
nil Operation not permitted
docker run -it --cap-add ALL justincormack/ljsyscall -e "print(require('syscall').clone('newuts,newpid'))"
nil Operation not permitted
docker run -it --cap-add ALL --security-opt seccomp:unconfined justincormack/ljsyscall -e "print(require('syscall').acct('/tmp/t'))"
nil No such file or directory
docker run -it --cap-add ALL --security-opt seccomp:unconfined justincormack/ljsyscall -e "print(require('syscall').clone())"
11
0

@jessfraz
Copy link
Contributor Author

Thanks I can add those as integration tests :) and I'm working on all new docs with the old comments as well

On Dec 30, 2015, 06:59 -0800, Justin Cormacknotifications@github.com, wrote:

Ok I have tested this extensively: tested that individual syscalls are being correctly filtered, used it as my default docker install and built stuff (eg docker/docker, Linux kernel compile), double checked the syscall list for 32 bits, arm, powerpc. So LGTM.

For reference easiest way to check individual syscalls being filtered is:

docker run -it --cap-add ALL justincormack/ljsyscall -e "print(require('syscall').acct('/tmp/t'))" nil Operation not permitted docker run -it --cap-add ALL justincormack/ljsyscall -e "print(require('syscall').clone('newuts,newpid'))" nil Operation not permitted docker run -it --cap-add ALL --security-opt seccomp:unconfined justincormack/ljsyscall -e "print(require('syscall').acct('/tmp/t'))" nil No such file or directory docker run -it --cap-add ALL --security-opt seccomp:unconfined justincormack/ljsyscall -e "print(require('syscall').clone())" 11 0


Reply to this email directly orview it on GitHub(#18979 (comment)).

@jessfraz
Copy link
Contributor Author

opened additional tests here: #19002 and docs will come soon in another PR

@cpuguy83
Copy link
Member

Looks like you have settimeofday in the whitelist, shouldn't that be blocked?

@jessfraz
Copy link
Contributor Author

Good catch thanks

On Dec 30, 2015, 18:30 -0800, Brian Goffnotifications@github.com, wrote:

Looks like you havesettimeofdayin the whitelist, shouldn't that be blocked?


Reply to this email directly orview it on GitHub(#18979 (comment)).

@GordonTheTurtle GordonTheTurtle added the dco/no Automatically set by a bot when one of the commits lacks proper signature label Jan 4, 2016
@GordonTheTurtle GordonTheTurtle removed the dco/no Automatically set by a bot when one of the commits lacks proper signature label Jan 4, 2016
@cpuguy83
Copy link
Member

cpuguy83 commented Jan 4, 2016

LGTM

jessfraz and others added 4 commits January 4, 2016 11:55
Signed-off-by: Jessica Frazelle <acidburn@docker.com>
Signed-off-by: Jessica Frazelle <acidburn@docker.com>
…ndle_at

Being able to obtain a file handle is no use as we cannot perform
any operation in it, and it may leak kernel state.

Signed-off-by: Justin Cormack <justin.cormack@unikernel.com>
sysfs and ustat syscalls are marked obsolete.

Signed-off-by: Justin Cormack <justin.cormack@unikernel.com>
This is the newer verion of lseek on many 32 bit platforms

Signed-off-by: Justin Cormack <justin.cormack@unikernel.com>
This is used on some 32 bit architectures, eg x86

Signed-off-by: Justin Cormack <justin.cormack@unikernel.com>
@justincormack
Copy link
Contributor

Looking good after more testing. There is one issue that running compatible architectures is currently blocked (eg 32 bit x86 on x86_64). There is an easier fix or a nicer one, will look at it tomorrow, but need not stop merging. Sent fix to @jfrazelle

@calavera calavera closed this Jan 5, 2016
@calavera calavera reopened this Jan 5, 2016
@calavera
Copy link
Contributor

calavera commented Jan 5, 2016

sorry, wrong button 😄

@calavera
Copy link
Contributor

calavera commented Jan 5, 2016

That file looks quite long but whatever. LGTM

@jessfraz
Copy link
Contributor Author

jessfraz commented Jan 5, 2016

we could use go generate? I was thinking about that in the beginning

On Tue, Jan 5, 2016 at 9:22 AM, David Calavera notifications@github.com
wrote:

sorry, wrong button [image: 😄]


Reply to this email directly or view it on GitHub
#18979 (comment).

@justincormack
Copy link
Contributor

Unfortunately Linux has too many syscalls, and it matches the libcontainer spec format, well the Go is a bit more readable. It is not ideal, but not sure there is much that can be done.

@jessfraz
Copy link
Contributor Author

jessfraz commented Jan 5, 2016

no i want it to be good :(

On Tue, Jan 5, 2016 at 9:23 AM, David Calavera notifications@github.com
wrote:

That file looks quite long but whatever. LGTM


Reply to this email directly or view it on GitHub
#18979 (comment).

In the default seccomp rule, allow use of 32 bit syscalls on
64 bit architectures, so you can run x86 Linux images on x86_64
without disabling seccomp or using a custom rule.

Signed-off-by: Justin Cormack <justin.cormack@unikernel.com>
This version is sometimes used eg by glibc on x86

Signed-off-by: Justin Cormack <justin.cormack@unikernel.com>
@jessfraz
Copy link
Contributor Author

jessfraz commented Jan 5, 2016

FWIW it will be easier to see the diff once its merged ;)

@thaJeztah
Copy link
Member

will merging make all red Janky's go green? 😇

@jessfraz
Copy link
Contributor Author

jessfraz commented Jan 5, 2016

i think it was becausse llvm repo was screwed up

@jessfraz
Copy link
Contributor Author

jessfraz commented Jan 6, 2016

green \o/

calavera added a commit that referenced this pull request Jan 6, 2016
Change seccomp blacklist to a whitelist
@calavera calavera merged commit 4b1872f into moby:master Jan 6, 2016
@jessfraz jessfraz deleted the make-whitelist branch January 6, 2016 18:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants