With Fedora 36 working its way towards release later this month, more developer attention and planning is turning to Fedora 37 that will be released this autumn. One of the changes being talked about this week is for signing RPM contents for a means of trusting the files that are executed.
The Fedora 37 change proposal is for adding IMA-based signatures to the individual files that are part of shipped RPM packages. This will allow for enforcing run-time policies by system administrators to ensure the execution of only trusted files or similar policies.
This is a good idea, and it’s important to underline that this is entirely optional – nothing will change for regular end users who are not interested in such policies. This won’t limit your ability to install whatever rpm you want, nor does it lock down anything any further than it is today – it just gives administrators more options.
Which is what Windows has been doing for decades (but Linuxeros were screaming about it for allegedly being some evil scheme to control developers and users).
Anyway, the real issue with app installation on Windows and Desktop Linux is that you have to give the package sudo/UAC admin access, including access to run arbitrary script. I can put anything in postinstall scriptlets, and it will be run as sudo. I know because, over at work, were are putting “systemctl –no-reload enable xxx.service” commands in the postinstall scriptlets so the package enables itself after install).
Meanwhile, more advanced operating systems such as MacOS (.dmg) and Android (.apk) don’t have that: The package manager mounts or copies the files somewhere and that’s it. No arbitrary scripts. Everything else has to be requested via the APIs, which allows for yes/no prompts after install. It’s one of those hidden features of MacOS that justifies the price you pay for a Mac compared to similarly-spec’ed PC (back in the times we could compare specs).
So, no, this doesn’t solve the issue of “trust” in Desktop Linux: Unless you are restricting yourself to open-source software (and maybe a small “known good” set of proprietary apps), you are at the mercy of whoever is providing the signatures for something as important as to what scripts run on your computer as root (sudo). I prefer the MacOS and Android solution, where there is a signing system in place (userland access can be abused after all), but running scripts as sudo/UAC admin during installation is explicitly prohibited by the package manager.
“Greater trust” my (censored)….
kurkosdr,
You’re technically not wrong, but whenever you leave the official repos to use 3rd party applications, the onus has always been on the owner to trust or not trust the 3rd party sources. To me your complaint does not seem to be specific to linux.
And regarding providing root access for every application, I concur it is a bad practice, but most user applications on linux don’t require root. Do you have something specific in mind? This used to be a big problem with windows, but it’s gotten better.
Another point that should be mentioned is that flatpak and snaps will sandbox the applications, which helps protect the user’s own files.
The problem is that both Linux package managers (deb and rpm) require root when installing stuff (which then give to the rpm or deb file to run its scripts as). Same thing for Windows MSI (it essentially requires UAC admin to install things). This means that even fairly simple applications (like a text editor or an MP3 converter) require root to install, even if the application developer doesn’t even want it (instead of the package manager giving me the option to install the application at ~/.local).
This trains users to always provide root when installing stuff. which gives malicious applications cover to abuse postinstall scriptlets to do bad things as root. If I had the ability to install simple applications without root at ~/.local, then applications that require root during instal for no apparent reason (aka applications that are not system utilities) would stick out like a sore thumb.
Meanwhile, MacOS doesn’t require root to install stuff. This is how you allow people to experiment with apps (aka allows the OS to forster an “app economy” in marketing-speak). It’s the reason MacOS has a fairly rich app ecosystem despite it’s market share. Users are less reluctant to experiment with new apps.
I am talking about root given during the installation. It boggles my mind. We care so much about what an application will do when run and have all these permission systems in place, but when installed, let’s give it root to run its postinstall scriptlets as, even if the application doesn’t want it.
kurkosdr,
When you’re dealing with system wide packages, which is what RPMs and DEBs are designed for, one needs root to modify the system. I can understand why you don’t like the OS maintainer having root access since it provides access to the local system, however I’d like to note some facts about this:
1) Giving the OS maintainer root scripts doesn’t increase the access they already have anyways by updating executables, shared objects, kernels, to do whatever they want.
2) Every platform that provides vendor updates including windows, linux, macos, IOS, android, etc are all vulnerable to maintainer attacks, if they so wanted to.
So, if you have a reason to not trust the maintainer, you probably should disable updates from them. If you want to run applications from an untrusted source, then you should install into a dedicated user account or consider using flatpaks, which are isolated and can be installed as a non-privileged user if desired. These packages are close in security to what IOS and android offer.
It’s not the application that gets root but rather the maintainer’s install scripts, there is a distinction. This is needed because those scripts need to be able to modify the system by design. They need to change system directories, update config files, kernel settings, load drivers, restart services, update permissions, etc. Things that normal user accounts don’t have access to and legitimately needs to be done for the install to complete. The repos are just doing their job.
For me the real culprit is the standard linux/unix hierarchy being such an ugly mess in the first place. Applications needing to be installed by throwing resources everywhere…I’m not a fan. I really liked the way your average windows 3.1 applications worked: virtually all software could be installed by unzipping it, this was fantastic! There was no need for an installer. Removal was just a matter of deleting one directory. I used to backup and restore applications with nothing more than basic directory copies! Even microsoft’s own titles including office worked fine this way. Unfortunately the windows application environment really started regressing with windows 95 and it spawned the need for complicated installers with full admin privileges.
It’s really hard to change established norms, but there are some who try. Gobolinux took this simple philosophy to heart and built a distro around a sensible directory structure.
https://gobolinux.org/
Stuff like mp3 converters are not system-wide packages and don’t need to modify the system, so I don’t see why deb and rpm should force me to install such packages with root access.
There is a difference between, as an OS maintainer, having root access and being forced to use it to install menial apps like mp3 converters. I don’t wanna.
Updates for apps installed without root can be updated without root. OS updates will need root sure, but the OS vendor is someone you have to trust anyway. System utilities will also need root (though it was 10 years since I installed “system utilities” not from the OS vendor, most users don’t either).
I think the maintainer’s install scripts shouldn’t receive root by default, and maintainers should be discouraged from asking such access.
For non-system apps like mp3 converters, they don’t need to change system directories, kernel settings, load drivers, mess with root services or update permissions. Config files should be user-specific and only changed via API calls.
No, not for simple apps like mp3 converters. And any settings like file associations, start-at-boot etc can be asked via API calls later (on a user level).
You can also have the standard linux/unix hierarchy in ~/.local instead or /usr, it’s a bonehead decision to not have it (and instead use /usr for ever app, which is not user-specific). The problem is that most Unix greybeards and Linux weenies don’t even see it as a problem, since they love the idea of doing things as root. At least Microsoft kind of know that having UAC pop up every now and then (say, when trying to install an mp3 converter) is a bad thing, and give developers the option to put applications in C:/User/(User)/AppData (but even they can’t make up their minds).
MacOS and Android are doing it right.
kurkosdr,
You are mistaken. They really are system-wide and multimedia software in particular can have a surprising number of system dependencies. If you prefer stand-alone software that installs in the local user account with no system dependencies, that’s what snap and flatpak are designed to do.
DEBs and RPMs are designed to do system-wide installations that require root access. I understand you may not like this, but in this case they’re the wrong tools for you. You probably want to use snap or flatpak instead.
That’s true for applications installed in the user account, but DEBs and RPMs are designed to update system binaries/libraries/services/etc. If you don’t want that then you should consider different solutions.
Exactly, this is why giving your distro maintainers root access doesn’t increase the scope of trust.
The alternative is something like UAC permission dialogs, which windows users almost universally despised. Sure it would be possible to increase the amount of elevation prompting on linux, but keep in mind the user is already prompted to start the installation because root is needed to make system changes outside the user account. Throwing in additional root prompts increases the annoyance factor while not doing much for security.
As mentioned previously linux distros already support an isolated application security model using snap & flatpak, which can install locally without root access. There’s an ongoing debate as to whether or not all applications should be migrated to these new isolated package managers. Technically we could but there are nuanced tradeoffs.
My gripe with Flatpak and Snap is that they run apps in a container, which I don’t see why (did they fix the issue in Snap where it won’t detect your home directory?) I just want the equivalent of dmg and apk. Is there a coincidence these are used in OSes people love the most?
But still, Flatpak and Snap are much better than deb and rpm. Too bad the Unix graybeards and Linux weenies won’t let it happen because they are control freaks who want to “repackage” everything for their specific distro. Not to mention that Flatpack and Snap allow people to (gasp!) effortlessly install proprietary software on Desktop Linux.
I will believe it when I see it. For now, deb and rpm is still how most apps are installed, even apps that don’t need root during install.
kurkosdr,
I don’t understand why you praise android, which runs applications in their own sandboxes, while criticizing linux for doing the same. In any case though these sandboxes are relatively new for desktop linux. If that’s not what you want, then you’ve got plenty of options. See AppImage for one. Snap also offers a confinement mode that seems to explicitly address your gripe.
https://snapcraft.io/docs/snap-confinement
I would suggest that the problem is not that linux doesn’t have anything like “dmg”, but that it’s difficult to get everyone to embrace a common standard.
You can criticize DEB & RPM for not supporting local installs, but we’ve already discussed how these are the wrong tool for the job. But for applications that are being used system-wide, root is a necessary to perform actions that the user lacks permission for.
As long as it’s not some silly VM-like thing, I am OK with sandboxes.
I wish FlatPack, Snap and AppImage suceed, but let’s see if they actually do. There is too much resistance in the communitah when it comes to people being free’d from repos.
I will believe it when I see it,
kurkosdr,
Yea, the solutions are there, but getting everyone on board is a challenge. Still, there are tens of thousands of snap and flatpak packages already so by some measures it’s already “succeeding” – obviously it depends on your specific criteria. If you consider “success” to include the killing off of RPM and DEB, then we’re not there and IMHO this is not that important. Ubuntu has been converting many popular applications to snap, so it’s definitely seeing uptake by large numbers of users whether they realize it or not.
Linux/Unix has no concept of permissions more granular then user, group, and other, so the concept of user space permissions is having to be retrofitted to the OS. Linux has cgroups, so hammer, nail. Nail, hammer. 🙂
There’s nothing magical about a “dmg”. It’s equivalent to “tar.gz” file, and I think it might just be a zip file.
Also, snap is awful.
Yes. There weren’t dueling package managers for MacOS or Android. Apple and Google decreed it was “dmg” and “apk” or nothing. People didn’t pick them. Those weren’t the two options people liked the most.
Flatpak is coming along nicely. 🙂 The software selection is pretty good, and Fedora offers Flatpak software up via Gnome Software.
Most regular people are pretty happy with Flatpak. It needs work, especially with theming and permission granting/revoking (ex: cheese doesn’t automatically have permissions to the webcam and doesn’t ask), but it’s coming along. 🙂
Honestly, I see “security buffs” pushing back the most because “tHeY’Re NoT sEcuRe”. Ignoring that wasn’t the original point of the project, but it’s a useful feature which is being worked on.
Snap is awful and centralized though, so I’m ready for that go away.
Apples and Oranges.
You are confusing the requirements to manage desktops and/or smartphones with servers (lots of it simultaneously more specifically). If one has to manage a fleet of hundreds, of even thousands of servers, you can’t just go one by one with “yes” and “no” questions, and these pre/post installation scripts do the very important job of handling things like migrating settings, databases, and automating tasks (that in no way you can cover every single use case with a API).
It’s the paid job of the system administrator, if he is at least half competent, to know about the presence of these scripts, what they do, and even customize them, before issuing mass deploy.
The real problem on (desktop) Linux is this insistence of using package solutions made for server use cases on desktop computers.
Yes, RPM and DEB (and similar solutions) are nice for power users on a desktop that know how to use command line, or has a nice mind map of each and every application on his desktop to use something like Synaptic to install software. But all these solutions just crumble upon their own weight when there a attempt to make them more user friendly with a nice “store front” and presenting granular options to tune their system access.
Thanks for articulating it better btw. Again, I want FlatPack, Snap and AppImage to succeed, but I will believe it when I see it.
I’m not aware of Windows of MacOS having anything like this.
This is part of the effort to implement dm-verity and fs-verity in order to create a trusted computing base. It’s more like a builtin intrusion detection system, and IMA signatures are to make sure files which have been compromised aren’t run.
It’s sort of useful for desktops, but it’s more about servers and the increase of malware attacks on Linux servers. I was just looking at implementing this for my servers. 🙂
https://lwn.net/Articles/888543/
https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
Android is adding IMA signatures in APK for file verification to keep malware down.
https://source.android.com/security/features/apk-verity
https://source.android.com/security/verifiedboot/dm-verity
MacOS also supports “.pkg” files which is a giant script to launch other scripts.
“.dmg” is equivalent to a tarball, and I believe MacOS will ask for priv escalation if the account isn’t an admin. There are provisions for an account specific applications folder, but I haven’t seen it used.
Linux has Flatpak for GUI applications. Everything gets installed in “$HOME/.var/app”, and the person doesn’t have to elevate permissions to install the application.
Linux package managers not being able to install applications into an account’s home dir is a missing feature. You are correct that I should be able to “dnf install neovim”, and neovim gets installed under “$HOME/.local”.
Of course, it would also be better if all accounts got their own container with an overlay of the systems dirs which they could modify. That way they could make changes to their little environment without changes being visible to the rest of the system.