Comment 6 for bug 1943480

Revision history for this message
Jeff (jeff09) wrote :

Can confirm the principle of least surprise being violated here. It took me getting a permission error trying to replace a file to test a bugfix to realize that:
- Commands without explicit permission elevation do system-wide modifications
- A theoretically user level setup is not fully covered by the backup of user files due to modifications escaping outside of the environment modifiable by the user
- Storage usage sneaked out of the expected scope (home of the user). Not meaning just installed programs, but ".removed" and "repo" added up to double digit GiBs, towering above the "app" and "runtime" sizes the user is shown during installation

The mentioned issues all stem from the problem that elevation is done with no notice and the usual barriers missing like either having to use sudo, or (worse case) being asked for a password instead of just denying the operation without being root.
However, circumventing the password requirement for privilege escalation presents an interesting dilemma:
- Either passwordless sudo is not a security issue as the user is expected to keep his account secure, and the additional obstacle of entering the password doesn't provide (much) security
- Or the extra step of requiring a password can be relied on as a security feature, therefore a combo of app-uninstall + modify-repo + app-install with a malicious repository could be used for interactive privilege escalation in some cases

Not completely on-topic, but as there's a divergence in privilege elevation here, I'll add an extra concern and question:
As hardware security key support is starting to look good, how will it be possible to use one universally for privilege elevation? As I understand, PolKit is mostly independent from PAM, so merely requiring pam_u2f.so for sudo as a second factor might not provide any extra security if PolKit would be still okay with just the password.
Can't say I'm a huge fan of PAM, but the centralized configuration surely seems to have an advantage, especially in such cases like this where a project is allowed to "slip" in rules lowering the security requirements for system modification.