-
Notifications
You must be signed in to change notification settings - Fork 18.8k
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
Conversation
e4d6adf
to
9356732
Compare
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). 👍 |
does this mean you will compile seccomp into your binary now 0:) |
SGTM |
Using a white list sounds like a better approach to me, so +1 Tentatively moving this to code review |
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. |
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:
|
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:
|
opened additional tests here: #19002 and docs will come soon in another PR |
Looks like you have |
9356732
to
f473b64
Compare
Good catch thanks On Dec 30, 2015, 18:30 -0800, Brian Goffnotifications@github.com, wrote:
|
f71602e
to
dcb0619
Compare
LGTM |
dcb0619
to
7632772
Compare
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>
7632772
to
9236091
Compare
This is used on some 32 bit architectures, eg x86 Signed-off-by: Justin Cormack <justin.cormack@unikernel.com>
Looking good after more testing. |
sorry, wrong button 😄 |
That file looks quite long but whatever. LGTM |
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
|
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. |
no i want it to be good :( On Tue, Jan 5, 2016 at 9:23 AM, David Calavera notifications@github.com
|
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>
FWIW it will be easier to see the diff once its merged ;) |
will merging make all red Janky's go green? 😇 |
i think it was becausse llvm repo was screwed up |
green \o/ |
Change seccomp blacklist to a whitelist
Running various tests on official images, but opening the discussion. ping @justincormack