Announcement

Collapse
No announcement yet.

Systemd Now Allows Custom BPF Programs To Be Loaded On Cgroups

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Systemd Now Allows Custom BPF Programs To Be Loaded On Cgroups

    Phoronix: Systemd Now Allows Custom BPF Programs To Be Loaded On Cgroups

    Systemd now allows loading of custom BPF programs for network traffic filtering that are applied to all sockets created by processes of a given systemd unit...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      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?
      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.
      On a rooted Android phone you can simply install AFWall+https://f-droid.org/en/packages/dev.ukanth.ufirewall/
      Then you can simply specify which applications are allowed to use the network / internet. It's very simple and easy to understand.
      Why it can't be the same on Linux?
      Hopefully systemd will solve also this problem.

      Comment


      • #4
        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.

        The cgroups approach, which is now quite popular in Linux could achieve the same, without all the downsides, but we're still far away for being able to use it universally.
        Right now systemd (and some other init-systems/service-mangers) only launch system-applications and only those easily get their own cgroup.
        With the BPF feature it is indeed quite easy to build per-service (or in some sense per-application) firewall rules, that are performant and work well.

        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.

        Comment


        • #5
          Originally posted by Danny3 View Post
          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.

          Comment


          • #6
            Originally posted by tg-- View Post
            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).
            Last edited by wagaf; 29 June 2019, 11:03 AM.

            Comment


            • #7
              Originally posted by wagaf View Post
              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.

              Comment


              • #8
                Originally posted by polarathene View Post

                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.
                Last edited by wagaf; 29 June 2019, 01:00 PM.

                Comment


                • #9
                  Originally posted by Candy View Post
                  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?

                  Comment


                  • #10
                    Originally posted by Candy View Post
                    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.

                    Comment

                    Working...
                    X