Announcement

Collapse
No announcement yet.

New Sandboxing Features Come To Systemd

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

  • New Sandboxing Features Come To Systemd

    Phoronix: New Sandboxing Features Come To Systemd

    Lennart Poettering has added two new service sandboxing features to systemd...

    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
    All Your Security Are Belong To Us.

    Comment


    • #3
      Originally posted by Filiprino View Post
      All Your Security Are Belong To Us.
      Do you think a hijacked service should be able to devastate your system? The more low level is the security mechanism, the more effective it is.

      Comment


      • #4
        Originally posted by Filiprino View Post
        All Your Security Are Belong To Us.
        Right, because providing an optional security mechanism automatically means all other security mechanisms instantly disappear.

        Comment


        • #5
          Originally posted by Filiprino View Post
          All Your Security Are Belong To Us.
          Where else, if not in the system launching services, should such stuff be configured?

          Comment


          • #6
            It's quite sad that more blacklisting is being introduced. It would be much nicer to have InaccessibleDirectories=/ with whitelisting via ReadOnlyDirectories/ReadWriteDirectories in a working state... blacklists are a bad way to approach security.

            Comment


            • #7
              Originally posted by strcat View Post
              It's quite sad that more blacklisting is being introduced. It would be much nicer to have InaccessibleDirectories=/ with whitelisting via ReadOnlyDirectories/ReadWriteDirectories in a working state... blacklists are a bad way to approach security.
              This seems like it is unnecessarilly reinventing apparmor, poorly. Albeit, I guess directory access control is coming at it from another angle.

              Apparmor already provides the necessary controls to restrict program behavior. I don't like how the usual default is no profile = go bananas, but you can fix that.

              It has always been one of my largest gripes with Arch that MAC is not functional pretty much at all. If I knew anything about how to port apparmor profiles from Ubuntu or Suse where they have a huge stock of them (and I had the time) I'd try it. I think that is honestly the only thing holding me back from recommending Manjaro / Chakra to average users (not newbies yet, but the average joe should have good MAC support).

              Comment


              • #8
                Originally posted by oleid View Post
                Where else, if not in the system launching services, should such stuff be configured?
                not like there are GID's and permissions or anything like that

                Comment


                • #9
                  Originally posted by zanny View Post
                  This seems like it is unnecessarilly reinventing apparmor, poorly. Albeit, I guess directory access control is coming at it from another angle.

                  Apparmor already provides the necessary controls to restrict program behavior. I don't like how the usual default is no profile = go bananas, but you can fix that.

                  It has always been one of my largest gripes with Arch that MAC is not functional pretty much at all. If I knew anything about how to port apparmor profiles from Ubuntu or Suse where they have a huge stock of them (and I had the time) I'd try it. I think that is honestly the only thing holding me back from recommending Manjaro / Chakra to average users (not newbies yet, but the average joe should have good MAC support).
                  Arch Linux has an official package for grsecurity, which has a great MAC implementation. The profiles are very easy to write, especially thanks to both full-system auto-learning and granular learning for specific subjects. It resolves the paths in the profile to inodes when the policy is loaded, so it doesn't have the security disadvantage associated with PATH-based MAC. It also has more power than the LSM alternatives since it's not limited to whatever hooks ended up all over the kernel for SELinux.

                  Comment


                  • #10
                    this is not an apparmor/selinux/tomoyo/grsecurity replacement, this is a previous step to those. This is a standard way across distro(using systemd ofc) to tell a service "hey i kinda don't trust you so you won't access my files generally speaking" to get early boot safe sandboxing, once the boot process kicks in your apparmor/selinux/tomoyo/grsecurity services take the fine grained control over what is accesible and how.

                    this is very useful in many scenarios:

                    1.) standarized basic sandbox: after all every distro use a different MAC implementation (fedora selinux, ubuntu apparmor, other tomoyo, arch grsecurity +, gentoo you choose, etc.)

                    2.) early boot service: some service start before your MAC, so for this period of time your files could be vulnerable

                    3.) embedded ARM/MIPS: nice for basic security without the extra weight of a full MAC system(especially in ARM low end hardware, they dont have extra cycles to waste in fine grained security)

                    Comment

                    Working...
                    X