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

Test whether sysfs mountpoints are accessible before mounting them #5697

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

Conversation

DanWin
Copy link

@DanWin DanWin commented Feb 18, 2024

In a restrictive environment where access to /sys/ is blocked to regular users, flatpak should not depend on sysfs as discussed in issue #5138

Copy link
Collaborator

@smcv smcv left a comment

Choose a reason for hiding this comment

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

This could probably be using --ro-bind-try, as is done for /proc/self/ns/user adjacent to the lines you deleted?

@DanWin
Copy link
Author

DanWin commented Mar 20, 2024

I thought so too @smcv , but when I tested this with --ro-bind-try under Whonix, it would still fail though, because this option will silently ignore non-existing sources. It still fails, when it doesn't have permissions to access the source, which the hardening scripts in Whonix did, by changing permissions of /sys

@smcv
Copy link
Collaborator

smcv commented Mar 20, 2024

Please could you say more in the commit message about precisely what "access to /sys/ is blocked" means in the system you're targeting? (chmod 0700 on /sys/block, etc.? chmod 0700 on /sys? /sys mounted as an empty filesystem? AppArmor? SELinux? ...)

I'd prefer not to be making this work accidentally, in a way that depends on implementation details and is fragile against future changes.

g_file_test() can be either access() or stat() depending on options, and as currently implemented, G_FILE_TEST_EXISTS is access with F_OK - so some of the interactions between that and various ways you might disable access to a mount point are probably relatively subtle.

If your actual goal is to deal with locked-down systems where access to these directories doesn't work, then access with R_OK|X_OK might be a better match: that would cover any reason why we can't detect or can't open the directory.

It's also worth noting that applications do rely on access to these directories (for example SDL uses /sys to distinguish between game controllers and non-game-controller input devices), so locking them down is a significant feature reduction - but presumably if you're doing this, you're already comfortable with sacrificing functionality for a sense of security.

@DanWin DanWin force-pushed the sysfs-mount branch 2 times, most recently from 00c7cec to 572d2a8 Compare April 20, 2024 15:25
In a restrictive environment where access to /sys/ is blocked by file
permissions (chmod 0700 /sys), flatpak should not depend on sysfs as
discussed in issue flatpak#5138
@DanWin
Copy link
Author

DanWin commented Apr 20, 2024

Thanks for your feedback @smcv , I have made changes as suggested.
This specific use case is when setting chmod 0700 /sys which is what was done previously in whonix.
Some applications may need access to /sys but I think this should be handled by the application in question to error in case of necessary access. Most applications will run fine without access to /sys, so launching flatpak should not depend on the accessibility of /sys. This is why I've made the mounts optional

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants