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


                    • #11
                      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


                      • #12
                        Originally posted by jrch2k8 View Post
                        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)
                        The feature will be useful when making / inaccessible and whitelisting directory trees as readable or readable+writable works. A blacklist is a really bad way of approaching this. It's intended to work so I agree with some of the reasoning behind the feature, but I don't understand the justification for adding these blacklist shortcuts.

                        Comment


                        • #13
                          Originally posted by strcat View Post
                          The feature will be useful when making / inaccessible and whitelisting directory trees as readable or readable+writable works. A blacklist is a really bad way of approaching this. It's intended to work so I agree with some of the reasoning behind the feature, but I don't understand the justification for adding these blacklist shortcuts.
                          Let's say, hypothetically, they did that and someone runs into a corner-case where a service misbehaves as a result. Any guess what sort of headlines would show up in places like here. I think it would be something along the lines of "systemd change breaks users' systems".

                          If we were in a situation where the programmers of services would get the blame if their service misbehaves, then I would expect systemd devs to be willing to go down that route. But when anything they do, or even things people imagined they did, brings attacks from all sides, why would they voluntarily give their enemies more ammunition?

                          Comment


                          • #14
                            Originally posted by atari314 View Post
                            And the cancer spreads...
                            How DARE the systemd developers add useful features to their software product!!1!!!eleven!11!!!! The NERVE of these guys!!!1one!!!! /s

                            Comment


                            • #15
                              Originally posted by strcat View Post
                              The feature will be useful when making / inaccessible and whitelisting directory trees as readable or readable+writable works. A blacklist is a really bad way of approaching this. It's intended to work so I agree with some of the reasoning behind the feature, but I don't understand the justification for adding these blacklist shortcuts.
                              dont see it as blacklist shortcuts, see it more like the most basic path you can block to be sure that a service can't screw your personal data or touch the kernel images when no other security system is active(most ARM-MIPS distros/lazy security distros).

                              this is not a security measure taken to compete with RHEL Selinux enalbed hardneded servers at NASA but aims to be the most elementary security baseline feature available in distro instead of absolutely nothing

                              Comment

                              Working...
                              X