Systemd Now Allows Custom BPF Programs To Be Loaded On Cgroups

[skeevy420]

It's not infallible, but it is actually very efficient. Centralized distribution provides a sort group immunity. I'm not aware of any mainstream distro sending malware, viruses and bad add-ons to their users. Are you? Was it intentional or else, did they fix the problem when it was reported?

The main problem with centralized distribution, is that it requires a lot of dedication from each maintainer, meaning we're missing out on lots of resources, meaning trusted distributions must either be small, for-profit or progressing slowly. Users seem unwilling to accept any of those alternatives.

I'm not saying central distribution is bad, but only that we've outgrown it.

Arch and Manjaro beg to differ. Small, not-for-profit, fast progress.

Suse begs to differ. Both large, for profit, fast progress and large, for profit, slow progress releases. Leap & Tumbleweed.

iMHO, it's the release cycle model that needs to change. Both freeze and play catch up & freeze and play catch up for even longer (LTS) just sucks on a desktop where we damn-near require a decent amount of the system to be in a bleeding edge state just to account for Steam, AMDGPU, other misc. gaming reasons, media codecs, web security, security in general, and more.

It adds more burden on maintainers since they have to account for version 3 updating to version 5 from LTS to LTS and not getting some random file from program version 4 that program version 5 expects to be there but doesn't install and is planned to be fixed with program version 6 (which also now depends on application B version 2 but is froze at application B version 1 which means application B also needs backports to be compatible with program version 6). The maintainer gets stuck with buggy version 5 and has to backport fixes from new versions because the distribution freeze time didn't jive with the release cycle of that particular program and has to do the same thing for a dependency package. Multiply that scenario with an entire repository of software and then double it if the distribution is like Ubuntu with LTS and regular interval freezes and that's where all the increased burden comes from.

I'd be happy if LTS meant using an LTS kernel with the LTS Plasma desktop and other LTS versions of software that get both LTS and current/stable releases.

[jo-erlend]

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

It's not infallible, but it is actually very efficient. Centralized distribution provides a sort group immunity. I'm not aware of any mainstream distro sending malware, viruses and bad add-ons to their users. Are you? Was it intentional or else, did they fix the problem when it was reported?

The main problem with centralized distribution, is that it requires a lot of dedication from each maintainer, meaning we're missing out on lots of resources, meaning trusted distributions must either be small, for-profit or progressing slowly. Users seem unwilling to accept any of those alternatives.

I'm not saying central distribution is bad, but only that we've outgrown it.

[Danny3]

In a way, that more innocent world view should be enough. But hey, these days when everyone is OK with their apps stealing all their data it seems obsolete.

When it comes to security nothing is enough and not everyone is OK with tapps stealing their data.
On the phone you can solve most of the problems by replacing the recovery with a custom one and the stock Android ROM with a custom one like Lineage OS, Google Play store with F-droid store and put a firewall like AFWall+ where you can decide which apps are allowed and which not to use the internet or local network.
Hopefully Linux will get one day somewhat closer to Android high level of security, but people need to stop saying that Linux is more secure just because the whole burden of responsability is put on the user with those stupid nagging popups for password.

[S.Pam]

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.

In a way, that more innocent world view should be enough. But hey, these days when everyone is OK with their apps stealing all their data it seems obsolete.

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

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

[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

[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

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

[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