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.

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

i/b: allow ro when allowing rw for mount-control #14543

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

zyga
Copy link
Contributor

@zyga zyga commented Sep 26, 2024

AppArmor has fixed CVE-2016-1585 which made mount rules more strict. This has caused a regression where snaps relying on the old behavior stopped working.

One failure mode we are aware of is when the snap declares "rw" mounts in the mount-control plug but uses "ro" mount in practice. In this case we can reasonably emit an equivalent "ro" permission when "rw" permissions are already granted.

Jira: https://warthogs.atlassian.net/browse/SNAPDENG-32513

AppArmor has fixed CVE-2016-1585 which made mount rules more strict.
This has caused a regression where snaps relying on the old behavior
stopped working.

One failure mode we are aware of is when the snap declares "rw" mounts
in the mount-control plug but uses "ro" mount in practice. In this case
we can reasonably emit an equivalent "ro" permission when "rw"
permissions are already granted.

Jira: https://warthogs.atlassian.net/browse/SNAPDENG-32513

Signed-off-by: Zygmunt Krynicki <[email protected]>
@zyga zyga added the Needs security review Can only be merged once security gave a :+1: label Sep 26, 2024
@zyga zyga marked this pull request as ready for review September 26, 2024 13:43
Copy link

codecov bot commented Sep 26, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.87%. Comparing base (ac897ee) to head (5544abb).
Report is 30 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #14543      +/-   ##
==========================================
+ Coverage   78.85%   78.87%   +0.01%     
==========================================
  Files        1079     1080       +1     
  Lines      145615   145837     +222     
==========================================
+ Hits       114828   115025     +197     
- Misses      23601    23618      +17     
- Partials     7186     7194       +8     
Flag Coverage Δ
unittests 78.87% <100.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@setharnold
Copy link

Deploying a new snapd is easier than deploying a new target snap?

@zyga
Copy link
Contributor Author

zyga commented Sep 27, 2024

Deploying a new snapd is easier than deploying a new target snap?

We don't quite know the extent of snaps that are affected and we'd have to communicate to all the users. At some scale deploying a fix on the side of snapd might be easier.

Copy link
Contributor

@alexmurray alexmurray left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed privately, I am in two minds about this change - I kind of think if we want this behaviour (rw implicitly grants use of ro) then either we should expect this to be done in AppArmor itself - OR we go ask snap publishers to update their snaps. I feel like trying to do this in snapd and grant extra permissions that are not explicitly requested is a bit odd and has the potential for confusion etc, so whilst I understand introducing a regression is not ideal, I think it is cleaner to not introduce such a workaround/hack here. @jrjohansen I'd be keen to know what you think about this too from the AppArmor side.

@zyga
Copy link
Contributor Author

zyga commented Oct 1, 2024

I understand the sentiment. I'll wait for JJ's opinion as I have no strong preference either way. CC @ernestl for scheduling awareness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs security review Can only be merged once security gave a :+1:
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants