-
Notifications
You must be signed in to change notification settings - Fork 74
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
Audit seccomp and add no_new_privs everywhere #156
Comments
tlsdated seems to do it properly. tlsdate and tlsdate-helper when run independently are not yet hardened. |
This will likely land in 0.0.12 - quick and dirty efforts to sandbox tlsdate and tlsdate-helper resulted in tlsdated ceasing to function properly. As it stands, I want to ensure seccomp is in use with tlsdated by default as it is enabled as a service and running at boot on Debian GNU/Linux. I will probably add a sandboxing function when tlsdated doesn't invoke it. This will take more than a few minutes and so it seems reasonable to wait for this feature. |
@redpig - I'm thinking that I might set a flag for running tlsdate that will ensure that if set by tlsdated, it won't enable the seccomp jail. If it isn't disabled at run time, it will be loaded (say by tlsdate -> tlsdate-helper). This should allow tlsdate/tlsdate-helper to both use seccomp without requing that a user is running the tlsdated daemon. Does that seem reasonable? |
This feature will go into 0.0.13 and not into 0.0.12. |
We should ensure that tlsdated, tlsdate and tlsdate-helper are all audited properly. Lets confirm their seccomp status, lets ensure that when we drop privs, we can't regain them (even without seccomp filtering) and so on.
The text was updated successfully, but these errors were encountered: