Repository navigation
Consistent refusal when apparmor is off - #1702
Open
philocalyst wants to merge 5 commits into
Open
philocalyst wants to merge 5 commits into
philocalyst wants to merge 5 commits into
Conversation
Keep policy-selected profiles available in every build and check runtime AppArmor availability before command execution. Return an unsupported error when AppArmor is enabled but this build cannot apply the profile. Keep AppArmor FFI behind its feature flag, update policy fixtures, and cover profile precedence and behavior without build support.
Extract policy-selected profile preparation and error mapping into a helper that sudoedit can reuse. Keep the command execution order intact.
Prepare the selected profile after authentication and before opening files, so an unsupported profile is rejected before files are created. The pending transition takes effect when the editor executes. Document editor confinement in both the manual source and generated page.
The release build already enables the apparmor feature. Update the README to match the flags used by util/build-release.sh.
Explain that profiles are ignored when AppArmor is disabled and that builds without AppArmor support reject configured profiles when it is enabled. Update the default-profile reference and the README guidance. Keep the manual source and generated page in sync.
Collaborator
|
og-sudo also seems to silently ignore |
Author
|
gasp let me check what they've said about it i'm sure it's come up before |
Author
|
yeah i read through their mailing list and see no discussion on this. to me this feels more intuitive, yet i'm biased, but... it really is (more intuitive) [they added apparmor support in 2022] |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A sudoers rule, say (
APPARMOR_PROFILE=), orDefaults apparmor_profile, may select an AppArmor profile for a given command. Builds without theapparmorfeature would let go of that selection silently, leaving a system which DID enforce AppArmor failing to confine the given command. An example of this situation is sudo-rs for... Debian! Sudoedit ignored the profile in every build :(Changes
Restrictionsalways carries the selected profile, andset_profile_for_next_execruns in every build. Already, it asks the kernel whether AppArmor is enabled: when it is not, the profile is ignored, as before. When it is, a build without the feature now just refuses the command (saying:unable to change AppArmor profile to BLANK: this build of sudo-rs does not support AppArmor) instead of it's current unconstrained behavior. This matches an existing policy inNOEXEC:. Everycfg(feature = "apparmor")now lives inapparmor.rs.util/build-release.shhas enabled it since 0.2.7.)Verification
Debian 13 arm64 VM with AppArmor enabled, a profile that denies writing one path, and upstream main (
base) against this branch (fix), each built with (aa) and without (noaa) the feature.