Announcement

Collapse
No announcement yet.

New Sandboxing Features Come To Systemd

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

  • #31
    Probably going to go through the front door in fedora 22.

    Comment


    • #32
      I don't like systemd - but that's no reason to be incorrect on purpose and I see a lot of misinformed FUD here


      Check the actual commit. http://cgit.freedesktop.org/systemd/...a7800846482eed
      These are namespace mount flags - you can emulate that with unshare (man 1 unshare).
      This is much simpler and faster than setting up RBAC through any mechanism. Its basically a different view of the filesystem mount. Fast/simple.


      Note that grsec gets a lot of positive advertisement as being the underdog/not in mainline and theres a lot of great stuff with it, but in the real world it isnt all that much better or worse than other alternatives. LSM for example isnt limited at all. Its less safe against kernel compromise. But for most people, if the kernel is compromised in any way, its already game over. And in most cases, for GrSec RBAC it is.

      The real gem in the GrSec kernel is that it includes PaX. At the same time PaX code is tracked by extremely large patch files with no history, making it difficult to understand and audit. And thats why its not in mainline.

      Comment


      • #33
        Originally posted by Luke View Post
        Systemd devs, like all programmers, need bug reports, not personal attacks and hate headlines, when something breaks. If all those attacks on systemd force systemd devs to turtle up and try everything new in private for fear of being attacked over bugs in alpha code, you get more bugs instead of less bugs when code gets released into system configurations the programmers don't have on hand for testing.

        Expect alpha code to have issues, expect finished code used in released versions of operating systems to be reliable. These go together folks! Let's face it, a lot of people are using systemd right now, and they need code that works. Many of us appreciate core security upgrades that can be used to say, sandbox the network and block remote attacks.
        Yes, in an ideal world where everyone was acting objectively and logically that would be the case. In the real world, however, there is a lot of irrational hatred of systemd, and there are "news" outlets that are willing to pounce on the smallest issue and spin it into a massive failure. There is a large social component to free software, and ignoring the implications of that is not a good way to encourage usage, and by extension contributions, to your project.

        Comment


        • #34
          Originally posted by asdfblah View Post
          BTW, I'm still wondering if there is any security researcher auditing systemd...
          I am pretty sure systemd went through a security audit prior to inclusion in Red Hat. There were some minor issues, but all fixable.

          On the other hand, what sort of security audit do distro init scripts get?

          Comment


          • #35
            Originally posted by asdfblah View Post
            BTW, I'm still wondering if there is any security researcher auditing systemd...
            The Red Hat Security Response Team (security audit) is quite active, and they did have a look at systemd (they have filled several CVE for systemd in the past).
            You can be sure that the version that will end up in RHEL 7 will be fully audited.

            Comment


            • #36
              Originally posted by rmiller View Post
              This is only useful if the service runs with a privileged user. A unprivileged user (nobody, http, dhcp, etc) can only access to the files that are owned by him.
              They can also access to file that are world readable. ( not that it change much, but that's for nitpicking )

              Comment


              • #37
                Originally posted by misc View Post
                They can also access to file that are world readable. ( not that it change much, but that's for nitpicking )
                Which is possible. When I was using Owncloud 2.X I kept all of my files in my home directory instead of /srv/www/Owncloud/Data/ just for easier backup. In order of Apache/Nginx to read and write to the folders I had to mess with the permissions-- which eventually just descended into me making them 777 because for some reason even with "proper" group and user listing Owncloud wouldn't work right with them.

                The example's not perfect, but the point I was trying to make is: None of us have any idea of what crazy, hackish setups people either choose to use / get forced to use to make something work.. So we have to work with that unknown.

                Comment

                Working...
                X