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

    http://www.phoronix.com/vr.php?view=MTcwOTk

  • #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
                    And the cancer spreads...

                    Comment

                    Working...
                    X