rohanssrao / silverblue-privesc

Fedora Silverblue privilege escalation
GNU Affero General Public License v3.0
6 stars 2 forks source link

is it really a security flaw? #4

Open cgwalters opened 1 year ago

cgwalters commented 1 year ago

I was linked to this repository. Here's my thoughts.

This is a demonstration that any program running as a member of the wheel group (e.g., a pip or npm package, or curl | bash) is able to execute arbitrary code as root without user interaction.

Yes sure, but honestly if you've done curl | bash then that arbitrary code can inject malware that waits until the next interactive password prompt or successful invocation of sudo and just do whatever it wants then...

Also, there's an xkcd for this: https://xkcd.com/1200/

Honestly though I'd very much like to move the policy out of the main package at least to something like a desktop-specific package, and they could more easily choose to use or drop it as they see fit.

osalbahr commented 1 year ago

I agree that this might not be considered a security flaw by some depending on their position on the tradeoff between security and convenience, and that curl | bash can inject all sorts of malware. It is ultimately the user's responsibility to validate anything that runs on their system.

However, I am not aware of another Linux distro that allows this behavior by default. For example, pkcon in Fedora Workstation requires authentication when installing a local package, which I think is a sensible decision. Therefore, rpm-ostree’s behavior increases the attack surface compared to Workstation. In fact, @rohanssrao started making this proof-of-concept after visiting https://fedoraproject.org/ and seeing that the immutable desktops were described as having “an additional layer of security,” which seems incorrect given this behavior.

Additionally, according to the README, this behavior does not seem in compliance with Fedora’s Privilege Escalation Policy which states

for installing Fedora-signed packages from administrator-configured repositories, the requirement to ask for a password is waived

This implies that there is a requirement to ask for a password to install a local package.

The Polkit rule that allows this behavior seems to have been put in place to permit gnome-software to install without prompting for a password (https://github.com/coreos/rpm-ostree/issues/745). However, it might've inadvertently permitted more than needed. Let me know if I’m missing something here.

travier commented 12 months ago

Related to https://gitlab.com/fedora/ostree/sig/-/issues/7

boredsquirrel commented 10 months ago

seeing that the immutable desktops were described as having “an additional layer of security,” this is really ironic, as the immutable filesystem is supposed to make malware harder to install. now it just needs to be a RPM and your done.

waits until the next interactive password prompt or successful invocation of sudo and just do whatever it wants then...

Thats why aliases are pretty dangerous. Some things like app names have to be immutable, so that sudo something cant be rewritten to execute anything with sudo. Afaik Windows did that kind of, with their Administrator prompt which runs isolated. But in the end the OS would need to

until this is done, Linux is very insecure.

I tried to fix the polkit permissios, have a look. They may be hardened enough, or would require even less permissions.

What is important and also forgotten until now, is that with this rule automatic background updates for nonwheel users are broken, which is horrible if you want a secure system where you are not the administrator daily.