Page 1 of 4 123 ... LastLast
Results 1 to 10 of 38

Thread: New Sandboxing Features Come To Systemd

  1. #1
    Join Date
    Jan 2007
    Posts
    15,399

    Default 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. #2
    Join Date
    Aug 2012
    Posts
    101

    Default

    All Your Security Are Belong To Us.

  3. #3
    Join Date
    Jun 2008
    Posts
    168

    Default

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

  4. #4
    Join Date
    Feb 2011
    Posts
    1,296

    Default

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

  5. #5
    Join Date
    Sep 2007
    Posts
    344

    Default

    Quote 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?

  6. #6
    Join Date
    Mar 2011
    Location
    Canada
    Posts
    103

    Default

    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.

  7. #7
    Join Date
    Dec 2012
    Posts
    573

    Default

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

  8. #8
    Join Date
    May 2012
    Posts
    658

    Default

    Quote 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

  9. #9
    Join Date
    Mar 2011
    Location
    Canada
    Posts
    103

    Default

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

  10. #10
    Join Date
    Feb 2014
    Posts
    45

    Default

    And the cancer spreads...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •