No announcement yet.

New Sandboxing Features Come To Systemd

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by strcat View Post
    Both grsecurity's RBAC and AppArmor use path-based policies, and in both cases policies can be created by the packagers. On top of that, both grsecurity and AppArmor support learning modes. The difference here is that grsecurity resolves these paths from the policy into inodes, so it's a more secure system without extra complexity for the policies. The learning support is incredibly useful for packagers or people contributing to the packages. The Arch Linux kernel no longer has any LSM support, so there is zero official support for TOMOYO, AppArmor or SELinux.

    On the other hand, there is a kernel with grsecurity support in the repositories along with a lot of work already done on integrating it into the distribution. There is a `paxd` package enabling the PaX exploit mitigations shipping with a well maintained exception list. This provides much stronger ASLR along with protection against exploits using return-oriented programming or other techniques. There is also a lot of hardening of the kernel itself against exploits and miscellaneous features that are far easier to deal with than MAC while still having a high value like trusted path execution (only users added to the tpe group can execute files in non-root controlled directories if kernel.grsecurity.tpe is flipped on).

    If someone wants to work on integrating MAC into Arch Linux, then either they need to be a trusted user / developer and have enough influence to get an LSM re-enabled in the [core] kernel, or they can contribute to grsecurity RBAC policies since there's already someone maintaining it and integrating it (me).
    What kind of policies would you accept? As I said, I really want to see Arch usable for everyone I know and not just myself, but they need good MAC that I can trust with a comprehensive included policy set. I just don't see the likelihood of out of tree patches being added to the Arch stock kernel, so I don't even see the road that leads to getting it into the stock kernel. And if it isn't in the stock one, there are all the aur or extended kernel mods like ck or pf that won't build it, and you end up compiling your own kernels if you want the latter stuff. Albeit, having used the ck and pf patchsets, I always end up going back to stock just because the maintenance and circumstantial breakage gets excessive. And my last point of contention is that grsecurity is not used in any major mainstream distribution,

    I'll try it the grsecurity Arch kernel this weekend, though. Is there an IRC / mailing list for its development? I do want to get involved at some point with policy creation, albeit I'm coming from a guy who has only contributed to Suse apparmor profiles and has never used the gr tools. I'll need to get some reading done...

    Some initial impressions though, after reading the wiki pages, READMEs from the grsec site, and a new superuser posts about it:

    1. They don't try to mainline it because they don't want parts in the mainline kernel, they want the whole package - and they perceive the kernel developers as security hostile. Honestly, my biggest issue with this project is that it looks like it can never become mainline, and thus it can never become popular. This is why I've always supported apparmor - it is flawed, it is insufficient, it breaks a lot, but it is better than nothing and usable. I have no gripes with it if the majority of the Arch ecosystem considers adopting it, though.

    2. Is there a way to only use per subject policies, rather than user policies? For single user systems polkit and systemd already do the appropriate resource allocations to unprivileged users, the user profiles seem redundant in that context - usually the DAC policies of the packages themselves are more than sufficient, and what I really want is binary hardening and restricted policies so exploited network facing software can't start jacking the entire system. I get where they have value on, say, a huge LDAP server, where just having custom groups for each user class is insufficient.

    3. I thought the stock kernel already does ASLR and has noexec page flags.

    The profiles look very apparmor-esque, though, which is good. Trying to do any access control in SELinux makes me want to devour brains since mine melted. Network access controls are nice and fine grained...

    Damn it, the more I'm reading about gr, I'm strongly regretting my writing it off years ago under the pretense "it is not mainline, it can never be serious". Kind of hypocritical to think the LSM model is a broken wreck and ridiculous while not considering out of tree security models that avoid using it.

    Also, this is making me really want to think about switching my server to Arch from Debian just for the gr kernel.
    Last edited by zanny; 06-04-2014, 06:54 PM.


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


      • #33
        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.
        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.


        • #34
          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.


          • #35
            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?


            • #36
              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.


              • #37
                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 )


                • #38
                  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.