-
Notifications
You must be signed in to change notification settings - Fork 876
chroot: handle slightly broken seccomp defaults #2105
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
When a seccomp rule includes multiple equality checks for the same argument for a syscall, they can never ALL be satisfied. Because that's how they're supposed to be treated, libseccomp returns an error when we try to add them as part of the same conditional rule. Try to detect this exact case, and if we detect it, treat each condition as its own rule. Signed-off-by: Nalin Dahyabhai <[email protected]>
| // were OR'd, when in fact they're ordinarily | ||
| // supposed to be AND'd. Break them up into | ||
| // different rules to get that OR effect. | ||
| if len(rule.Args) > 1 && opsAreAllEquality && err.Error() == "two checks on same syscall argument" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where's the string from? It always worries me to check for an error by looking at the string output rather than a particular error type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I share your concern. This is an error object that github.com/seccomp/libseccomp-golang creates every time it returns the error, so we can't just compare the error itself for equality with a known value. If there's a better method, I'm happy to switch to it.
TomSweeneyRedHat
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@rhatdan @vrothberg PTAL
vrothberg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a hard time reviewing this. Is there any chance we can generalize the problem and get it into libseccomp-golang?
|
📌 Commit f4f2c05 has been approved by |
|
☀️ Test successful - status-papr, status-travis |
Why was it merged without a reply to my concerns above? |
|
I saw this as a separate PR, not necessarily related to Buildah. I am also wondering if the chroot code is specific to Buildah, and not sure if this is useful to other projects. |
|
FWIW, we're doing this here instead of the seccomp bindings to mirror part of how runc does things in opencontainers/runc#1616. |
When a seccomp rule includes multiple equality checks for the same argument for a syscall, they can never ALL be satisfied. Because that's how they're supposed to be treated, libseccomp returns an error when we try to add them as part of the same conditional rule. Try to detect this exact case, and if we detect it, treat each condition as its own rule.