Systemd Now Allows Custom BPF Programs To Be Loaded On Cgroups

[starshipeleven]

This Trust(tm) model doesn't work when you get malware, viruses or bad add-ons, or what not. Besides, distros aren't infallible.

Yes, the "trust" model is dated and inferior to the modern approach, but then again it was born long ago when security wasn't really a huge concern and the concept of "the user decides what software he can trust is all that is needed" was still believed by most.

[S.Pam]

All your programs are implicitly Trusted. The solution to misbehaving apps would be to get your distributor to fix the app so it doesn't misbehave anymore. In this context, the only real reason to firewall individual programs, is when you're really protecting yourself against your users, such as in a corporate or government environment.

This Trust(tm) model doesn't work when you get malware, viruses or bad add-ons, or what not. Besides, distros aren't infallible.

[S.Pam]

Would be nice if SystemD really fully supported cgroups v2, aka unified. Yes, freezer is missing, but why not spend the time to migrate that controller over ? Seems much more important than eBPF at the moment.

[jo-erlend]

Does this mean that we can finally have a firewall where we can simply specify rules for programs instead of pretty stupid rules for ports?
... Why it can't be the same on Linux?
Hopefully systemd will solve also this problem.

Throughout its history, Desktop Linux has been based on a centralized distribution model. That means the source of your programs is the same as the source of your kernel, which in turn means there's been very little incentive to develop protection against apps. All your programs are implicitly Trusted. The solution to misbehaving apps would be to get your distributor to fix the app so it doesn't misbehave anymore. In this context, the only real reason to firewall individual programs, is when you're really protecting yourself against your users, such as in a corporate or government environment. But in these contexts, you have so many users, spending a little time setting up SELinux or AppArmor is not a big deal in the grand scheme of things.

As Desktop Linux has grown, the centralized distribution model has become inefficient and most individual users want faster app updates, which really means opening the system to third-party distributors. That software should be considered implicitly Untrusted, hence it requires the type of security you're asking for, which is why both Flatpak and Snapd are designed for this from the beginning.

[jo-erlend]

SystemD is a body of religious beliefs and practices launched in March 2010 by German author Lennart Poettering (1980). Poettering initially developed a program of ideas called SystemD, which was distributed through the GNU Foundation. The foundation soon entered bankruptcy, and Poettering lost the rights to his seminal publication SystemD: The Modern Science of Mental Health in (unknown). He then recharacterized the subject as a religion and renamed it systemd.

If you're going to make statements like that without very strong references, you should make sure not to mention mental health.

[tildearrow]

SystemD is a body of religious beliefs and practices launched in March 2010 by German author Lennart Poettering (1980). Poettering initially developed a program of ideas called SystemD, which was distributed through the GNU Foundation. The foundation soon entered bankruptcy, and Poettering lost the rights to his seminal publication SystemD: The Modern Science of Mental Health in (unknown). He then recharacterized the subject as a religion and renamed it systemd.

Are you drunk or something?

[wagaf]

Eh, I'm not big on installing apps without much thought on Android either tbh. Plenty of the free ones ask for permissions to things they should not need at all, more than likely to do some sorta data harvesting, I dunno, apparently serving ads just isn't enough and they need to be shady too?

Some of those apps will refuse to work/function if you don't permit their requests, they don't explain what they're for which doesn't help when you can't tell why an offline/single player game would want access to your contacts/call log and mic/whatever. Others you can refuse and they'll work fine but ask again when you try to do something that needs a permission like access to the filesystem(though personally that's too broad as it can be read/write access to the entire filesystem when all you want/need is to provide access to your photos/gallery or a location to save.

Even with filesystem access permission, apps on Android can't access each others private files, only files on the shared storage/sdcard (usually not much valuable data there).

With recent Android versions, even when storing data on shared storage, those files will get deleted when uninstalling the app, as well as any other app data/configuration. Now, the only way to reliably access the file system (other than for private app data) is to use the Storage Access Framework which has fine-grained per-file permissions, and requires explicit user intent (SAF allows to share a specific file with a specific other app, or use the system "open file" or "save file" dialogs).

edit: what you said even highlights how the Android architecture effectively gives back control to users by allowing them to know what apps are doing and allowing them to deny the permission.

[polarathene]

That's in part the reason why people don't want to install apps on their Windows (afraid of spamware/crapware/virus) but have much less problems to do so on Android/iOS.

Eh, I'm not big on installing apps without much thought on Android either tbh. Plenty of the free ones ask for permissions to things they should not need at all, more than likely to do some sorta data harvesting, I dunno, apparently serving ads just isn't enough and they need to be shady too?

Some of those apps will refuse to work/function if you don't permit their requests, they don't explain what they're for which doesn't help when you can't tell why an offline/single player game would want access to your contacts/call log and mic/whatever. Others you can refuse and they'll work fine but ask again when you try to do something that needs a permission like access to the filesystem(though personally that's too broad as it can be read/write access to the entire filesystem when all you want/need is to provide access to your photos/gallery or a location to save.

If I need an app, I'll generally go online and search for any open-source or reputable app rather than trust the app store blindly for picking an app that can do what I'm after.

[wagaf]

There's a conceptual difference between Android and Linux.
In Linux, if you run an application, it runs under your user. In Android, each application gets their private user ID, which makes it trivial to block its traffic in iptables, which afwall utilizes.

This is a very simple solution, but has many downsides, and thus isn't exactly well-liked in the Linux world, as it breaks a LOT of existing expectations and applications.
It works for Android since Google is in full control over the whole stack and there is no interoperability with any other operating system to consider.

This is the way to go to be able to run apps that might not be trusted by users. Users are not engineers or security experts so it's not possible to expect them to trust their apps (and every app can get breached). If users aren't protected, the value of desktop apps is greatly reduced.

That's in part the reason why people don't want to install apps on their Windows (afraid of spamware/crapware/virus) but have much less problems to do so on Android/iOS. On Windows people just use web apps in part because these are strictly isolated.

At some point all desktop apps will have to adapt to these new security scheme or see their use plummet in favor of sandboxed environnements. The sooner the better..

Actually, having one user per app/service is already the norm for servers, for good reasons (no program can be trusted 100% so they must be isolated from each other in case they get compromised).

[starshipeleven]

Does this mean that we can finally have a firewall where we can simply specify rules for programs instead of pretty stupid rules for ports?

No. It's at best a prerequisite for some of the ways you can do that.

Why it can't be the same on Linux?

Because applications on Linux aren't sandboxed in any way by default (beyond the very basic "run by user X" so inheriting its privileges, which is woefully inadequate for modern security and privacy), so the system does not have a lot of control over what the application does.

The current way to "specify rules for programs" is designed for servers (unsurprisingly), and you need to install and manually configure AppArmor or SELinux for each specific application you want to lock down like that. It's powerful and it works as it tracks the application process, but it's not terribly user-friendly.

In Android, the application is sandboxed, it has to request permission to the system to do anything, and its actions can be easily tracked and denied by the system without having to track the application from the outside.

Hopefully systemd will solve also this problem.

systemd is only part of the solution.

The Linux project that is working towards that goal is Flatpak, they are basically doing the same as Android, sandboxing applications and having them ask permissions to the system for each action they want to take on the outside world. With the "portals" system http://docs.flatpak.org/en/latest/de...n.html#portals they basically achieve what Android does.

It's currently being developed so it's not finished, but that's the goal anyway.

Also flatpaks can be made without any real sandboxing too (just to run applications with their own libraries), at least for now. I hope they will introduce some flags that allow people to see/reject/filter applications that aren't using a sandbox and portals for all their operations in the future.