Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fix handling/ordering of seccomp(), selinux/aa during service exec #3993

Closed
poettering opened this issue Aug 19, 2016 · 3 comments
Closed

fix handling/ordering of seccomp(), selinux/aa during service exec #3993

poettering opened this issue Aug 19, 2016 · 3 comments
Labels
bug 🐛 Programming errors, that need preferential fixing pid1
Milestone
v232

Comments

@poettering
Copy link
Member

A follow-up from #3970: let's clean up the handling/ordering of post-seccomp code in the service execute path. In particular:

  • we should probably set up seccomp last, and do selinux/aa first
  • when seccomp is enabled the error path should refrain from logging in order not to trigger any seccomp collisions on its own
@poettering poettering added bug 🐛 Programming errors, that need preferential fixing pid1 labels Aug 19, 2016
@poettering poettering added this to the v232 milestone Aug 19, 2016
@poettering poettering mentioned this issue Aug 19, 2016
Closed
@poettering poettering mentioned this issue Aug 31, 2016
Closed
@poettering
Copy link
Member Author

also, we need to think about no-new-privileges in relation to seccomp (which it often implies) and selinux

@evverx
Copy link
Member

evverx commented Aug 31, 2016

we need to think about no-new-privileges in relation to ... selinux

Related:

Some helpful links:

poettering added a commit to poettering/systemd that referenced this issue Oct 25, 2016
@poettering
execute: apply seccomp filters after changing selinux/aa contexts
f62becf 
Seccomp is generally an unprivileged operation, changing security contexts is
most likely associated with some form of policy. Moreover, while seccomp may
influence our own flow of code quite a bit (much more than the security context
change) make sure to apply the seccomp filters immediately before executing the
binary to invoke.

This also moves enforcement of NNP after the security context change, so that
NNP cannot affect it anymore. (However, the security policy now has to permit
the NNP change).

(The SMACK code should probably be moved to, but we'll leave that out for now.)

This change has a good chance of breaking current SELinux/AA setups, because
the policy might not expect this change of behaviour. However, it's technically
the better choice I think and should hence be applied.

Fixes: systemd#3993
poettering added a commit to poettering/systemd that referenced this issue Oct 25, 2016
@poettering
man: document that too strict system call filters may affect the serv…
aafd190 
…ice manager

If execve() or socket() is filtered the service manager might get into trouble
executing the service binary, or handling any failures when this fails. Mention
this in the documentation.

The other option would be to implicitly whitelist all system calls that are
required for these codepaths. However, that appears less than desirable as this
would mean socket() and many related calls have to be whitelisted
unconditionally. As writing system call filters requires a certain level of
expertise anyway it sounds like the better option to simply document these
issues and suggest that the user disables system call filters in the service
temporarily in order to debug any such failures.

See: systemd#3993.
@poettering
Copy link
Member Author

My proposed fix is waiting in #4483

poettering added a commit to poettering/systemd that referenced this issue Nov 2, 2016
@poettering
man: document that too strict system call filters may affect the serv…
2ca8dc1 
…ice manager

If execve() or socket() is filtered the service manager might get into trouble
executing the service binary, or handling any failures when this fails. Mention
this in the documentation.

The other option would be to implicitly whitelist all system calls that are
required for these codepaths. However, that appears less than desirable as this
would mean socket() and many related calls have to be whitelisted
unconditionally. As writing system call filters requires a certain level of
expertise anyway it sounds like the better option to simply document these
issues and suggest that the user disables system call filters in the service
temporarily in order to debug any such failures.

See: systemd#3993.
@walyong walyong mentioned this issue Oct 24, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug 🐛 Programming errors, that need preferential fixing pid1
Milestone
v232
Development

No branches or pull requests
2 participants
@poettering @evverx