Systemd Now Allows Custom BPF Programs To Be Loaded On Cgroups

[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.

[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.

[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.

[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_j_newbury]

To get the feature for every user application, you would have to give every user application their own cgroup, which right now does not happen.
Systemd currently largely doesn't touch this (though it could in theory, because there is user-session support), and nobody seems to work on it.
Besides using systemd user-sessions (which would launch applications in cgroups for users) to achieve this, the common desktops (Gnome or KDE and others) could implement a similar feature in their own launcher, but as far as I know this hasn't happened as well.

I certainly hope we will get each and every simple application in their own cgroup at some point, which would be a great usability and security benefit.

This is exactly where Gnome is going. On my current session:

systemctl --user status
● artifact
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Mon 2019-06-24 07:47:15 BST; 5 days ago
   CGroup: /user.slice/user-1000.slice/[email protected]
           ├─gvfs-goa-volume-monitor.service
           │ └─1735 /usr/libexec/gvfs-goa-volume-monitor
           ├─evolution-calendar-factory.service
           │ └─1726 /usr/libexec/evolution-calendar-factory
           ├─gvfs-daemon.service
           │ ├─  1547 /usr/libexec/gvfsd
           │ ├─  1552 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
           │ ├─  2002 /usr/libexec/gvfsd-http --spawner :1.13 /org/gtk/gvfs/exec_spaw/2
           │ ├─  9128 /usr/libexec/gvfsd-network --spawner :1.13 /org/gtk/gvfs/exec_spaw/3
           │ ├─  9146 /usr/libexec/gvfsd-dnssd --spawner :1.13 /org/gtk/gvfs/exec_spaw/5
           │ ├─253263 /usr/libexec/gvfsd-trash --spawner :1.13 /org/gtk/gvfs/exec_spaw/0
           │ └─253413 /usr/libexec/gvfsd-burn --spawner :1.13 /org/gtk/gvfs/exec_spaw/1
           ├─evolution-source-registry.service
           │ └─1639 /usr/libexec/evolution-source-registry
           ├─gvfs-udisks2-volume-monitor.service
           │ └─1665 /usr/libexec/gvfs-udisks2-volume-monitor
           ├─gnome-terminal-server.service
           │ ├─  1186 bash
           │ ├─  1251 su -
           │ ├─  1253 -su
           │ ├─  2456 /usr/libexec/gnome-terminal-server
           │ ├─108358 bash
           │ ├─108401 systemctl --user status
           │ ├─244394 bash
           │ ├─244399 su -
           │ ├─244401 -su
           │ ├─244408 bash
           │ └─247991 joe undervolt.py
           ├─init.scope
           │ ├─1494 /lib/systemd/systemd --user
           │ └─1495 (sd-pam)
           ├─gvfs-gphoto2-volume-monitor.service
           │ └─1739 /usr/libexec/gvfs-gphoto2-volume-monitor
           ├─at-spi-dbus-bus.service
           │ ├─1586 /usr/libexec/at-spi-bus-launcher
           │ ├─1591 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
           │ └─1593 /usr/libexec/at-spi2-registryd --use-gnome-session
           ├─gvfs-metadata.service
           │ └─1683 /usr/libexec/gvfsd-metadata
           ├─dbus.service
           │ ├─  1508 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
           │ ├─  1616 /usr/libexec/ibus-portal
           │ ├─  1629 /usr/libexec/gnome-shell-calendar-server
           │ ├─  1649 /usr/libexec/goa-daemon
           │ ├─  1651 /usr/libexec/gconfd-2
           │ ├─  1657 /usr/libexec/dconf-service
           │ ├─  1661 /usr/libexec/mission-control-5
           │ ├─  1721 /usr/libexec/goa-identity-service
           │ ├─  6603 /usr/bin/nautilus --gapplication-service
           │ ├─ 10187 file-roller /tmp/.private/steve/mozilla_steve0/mpd-0.20.15-flac_container.patch.zip
           │ ├─ 10197 /usr/bin/gedit --gapplication-service
           │ ├─250652 /usr/bin/seahorse --gapplication-service
           │ └─253289 gpg-agent --homedir /home/steve/.gnupg --use-standard-socket --daemon
           ├─evolution-addressbook-factory.service
           │ └─1806 /usr/libexec/evolution-addressbook-factory
           └─gvfs-mtp-volume-monitor.service
             └─1743 /usr/libexec/gvfs-mtp-volume-monitor

[s_j_newbury]

This is exactly where Gnome is going. On my current session:

systemctl --user status
● artifact
State: running
Jobs: 0 queued
Failed: 0 units
Since: Mon 2019-06-24 07:47:15 BST; 5 days ago
CGroup: /user.slice/user-1000.slice/[email protected]
├─gvfs-goa-volume-monitor.service
│ └─1735 /usr/libexec/gvfs-goa-volume-monitor
├─evolution-calendar-factory.service
│ └─1726 /usr/libexec/evolution-calendar-factory
├─gvfs-daemon.service
│ ├─ 1547 /usr/libexec/gvfsd
│ ├─ 1552 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
│ ├─ 2002 /usr/libexec/gvfsd-http --spawner :1.13 /org/gtk/gvfs/exec_spaw/2
│ ├─ 9128 /usr/libexec/gvfsd-network --spawner :1.13 /org/gtk/gvfs/exec_spaw/3
│ ├─ 9146 /usr/libexec/gvfsd-dnssd --spawner :1.13 /org/gtk/gvfs/exec_spaw/5
│ ├─253263 /usr/libexec/gvfsd-trash --spawner :1.13 /org/gtk/gvfs/exec_spaw/0
│ └─253413 /usr/libexec/gvfsd-burn --spawner :1.13 /org/gtk/gvfs/exec_spaw/1
├─evolution-source-registry.service
│ └─1639 /usr/libexec/evolution-source-registry
├─gvfs-udisks2-volume-monitor.service
│ └─1665 /usr/libexec/gvfs-udisks2-volume-monitor
├─gnome-terminal-server.service
│ ├─ 1186 bash
│ ├─ 1251 su -
│ ├─ 1253 -su
│ ├─ 2456 /usr/libexec/gnome-terminal-server
│ ├─108358 bash
│ ├─108401 systemctl --user status
│ ├─244394 bash
│ ├─244399 su -
│ ├─244401 -su
│ ├─244408 bash
│ └─247991 joe undervolt.py
├─init.scope
│ ├─1494 /lib/systemd/systemd --user
│ └─1495 (sd-pam)
├─gvfs-gphoto2-volume-monitor.service
│ └─1739 /usr/libexec/gvfs-gphoto2-volume-monitor
├─at-spi-dbus-bus.service
│ ├─1586 /usr/libexec/at-spi-bus-launcher
│ ├─1591 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
│ └─1593 /usr/libexec/at-spi2-registryd --use-gnome-session
├─gvfs-metadata.service
│ └─1683 /usr/libexec/gvfsd-metadata
├─dbus.service
│ ├─ 1508 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
│ ├─ 1616 /usr/libexec/ibus-portal
│ ├─ 1629 /usr/libexec/gnome-shell-calendar-server
│ ├─ 1649 /usr/libexec/goa-daemon
│ ├─ 1651 /usr/libexec/gconfd-2
│ ├─ 1657 /usr/libexec/dconf-service
│ ├─ 1661 /usr/libexec/mission-control-5
│ ├─ 1721 /usr/libexec/goa-identity-service
│ ├─ 6603 /usr/bin/nautilus --gapplication-service
│ ├─ 10187 file-roller /tmp/.private/steve/mozilla_steve0/mpd-0.20.15-flac_container.patch.zip
│ ├─ 10197 /usr/bin/gedit --gapplication-service
│ ├─250652 /usr/bin/seahorse --gapplication-service
│ └─253289 gpg-agent --homedir /home/steve/.gnupg --use-standard-socket --daemon
├─evolution-addressbook-factory.service
│ └─1806 /usr/libexec/evolution-addressbook-factory
└─gvfs-mtp-volume-monitor.service
└─1743 /usr/libexec/gvfs-mtp-volume-monitor

Anybody who installs software distributed from unknown sources is taking unknown risks. You really shouldn't have absolute trust in any source. Mainstream Linux distributions have an incentive to ship software which meets a level of quality which doesn't tarnish their reputation, that's their entire model. That doesn't mean you can absolutely trust them, but it's reasonable to assume they are not deliberately malicious, since if they behave any other way they'll effectively cease to exist. Generally, I'm entirely unconvinced installing malicious software in a sandbox makes it "okay", and if it can't be audited, it can't be trusted, how can you know?

In my opinion, this is a better "trust model" than the Android approach. Resource access requirements are determined by the package author and distributor and user/system administrator can override the defaults based upon application requirements. Until recently this was pretty much impossible to do at every layer of the stack, but finally this is enforceable with systemd/cgroups/bpf.

The Android model fails because it can't explain to non-technical users why certain permissions are required, so vague requirements are a back door for malicious software to break "user trust" even while trust between 3rd party software vendor and system vendor remains intact.

[pal666]

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?

afaiui now you can have stupid rules for cgroups instead of stupid rules for ports

I'm waiting for years that at least one Linux distro catch up to Android when it comes to firewall security and easy of use.

afaik android has one uid per app, maybe its firewall has stupid rules for uids

[horizonbrave]

Are you drunk or something?

I wish to have a filter/ban list, I hope he/she is not going to rise to the position of new debianxfce attention seeking bag of dicks troll
I like some humour and fun in the forums, but he/she's not, just annoying repetitive crap at best. Forums shouldn't be a vomit bucket for frustratred people, go figure

[phoron]

Yes, I understand jo-erlend and s_j_newbury. Basically, having proprietary apps with the user granting permissions to each app (like android or flatpack) seems safer and more user controllable, but in the end just shifts the responsability from the authors to the users. It's shoving the problem under the carpet, so to say. I think there needs to be 2 things:

- people must understand that none is able to understand technology to the level necessary to audit or have any confidence. And delegating the confidence to others is fragile. So individually people should use as little technology as possible, and know as much about it as possible, approaching the ideal "only use what you completely understand". Else you seem much more "productive", "powerful", and "efficient", but at unknown risks, which for me is not responsible at all.

- as a compromise the solution is to collectivize the audit effort. Yes, free software can be audited and yet often it is not. But if you have the concept of a distribution whose job is not producing software or using software for production, but selecting, adapting, testing and publishing sets of software for a relatively big population to use, then you still can't trust there aren't problems, but at least you get some confidence that the problems you find might be the same other users of the same distro have found. And if you inform about them and work with the rest of the community to raise awareness or fix them, then you mutualise a difficult task and can achieve
a little more than if you try to control everything yourself.

But sharing or caring (spending time, let alone money) for collective welfare is culturally anathema, and so users want magic bullets and marketing wants to sell lead. That's why this sandbox idea emerges when proprietary software (or services as a software substitute) enters the picture. They promise you to be able to use more magic, not less, and they promise you they'll add more magic so that this magic you don't understand is safe. So you're given more configuration overhead but more choice of essentially untrusted code on your machines. But since they're supposed to be isolated, your risk shouldn't be so high. But can they really be isolated ? In order to do something useful programs should work on your data, and if they can manipulate your data then they can also destroy it, corrupt it or maybe exfiltrate it. So you have a sandbox but then you need a portal out of the sandbox, because otherwise, your apps aren't so useful...

And on the subject of collective failures, don't get me started on democracy in the EU...

[rtfazeberdee]

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.

Oh dear, Candy has escaped from the padded room again. Nurse!! Nurse!! emergency meds needed !!