Announcement

Collapse
No announcement yet.

New Sandboxing Features Come To Systemd

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

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


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


      • #13
        Originally posted by atari314
        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


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


          • #15
            Originally posted by nerdopolis View Post
            How DARE the systemd developers add useful features to their software product!!1!!!eleven!11!!!! The NERVE of these guys!!!1one!!!! /s
            Yeah it's not like they are reinventing every single feature of an operating system, right?

            Comment


            • #16
              Originally posted by strcat View Post
              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.
              The problem is that for any distro, the second you say "put your MAC in learning mode" you have already failed. You want either the architects / packagers themselves, or the security project, to produce profiles for all the various binaries shipped, because you can't audit the ones you already have.

              That is why I can't really trust tomoyo, even though it is supported out of the box on Arch.

              And it is also not practical to tell someone to install Manjaro, put gr in learning mode, and then shut it off, and to know when to go back in and fix it when some application legitimately wants access somewhere else - the designer of the software would have known this, but just analyzing binary behavior and assuming that is the limited scope of intended uses can miss a lot of rare resource utilization that is intended.

              My impression having tried both is that AppArmor profiles are much more intuitive for an Arch packager to use, since they are path based, you are already installing the program according to ACLs on directories given you by the Arch base. Of course I am biased, though, since I've never tried grsecurity in practice because I feel learning mode defeats the point for a consumer user - for enterprise, learning MAC is great because they have the capacity to audit their programs directly and trust them, and then they just have to ironclad for exploits from the base rules. We don't really have that convenience in the consumer space.

              But honestly I don't care which, and I would contribute if there was any forerunner attempting to do so, but it is a huge undertaking to try to generate profiles for all Arch packages (for any MAC), let alone the AUR. But I don't think it is a solvable problem, because the theoretical best case is that pacman begins mandating MAC profiles (from whatever MAC is most popular, I don't care which) in all packages, with some optional switch to disable it, in the same way it requires signed packages right now.

              But just because it is a hard problem doesn't mean it is not worth solving - I think it is a deep fundamental weakness in any distribution based on binary packages to not have fine grained access control on its binaries, because you never know what exploits or backdoors might trickle in from upstream. It makes Linux seem like childs play next to Android, which has a great user facing resource access control model, that is not as finely tuned as good MAC, but much better than "any binary ever can access all the network resources, the X screen, all your user readable logs, all your other program binaries, every config and share in your home directory, all your etc configuration...".
              Last edited by zanny; 04 June 2014, 01:13 PM.

              Comment


              • #17
                Originally posted by z411 View Post
                Yeah it's not like they are reinventing every single feature of an operating system, right?
                the problem is perspective vs plain hate/lack of understanding

                for example:

                1.) dhcp/network in systemd: omg rewriting the OS, no this is not intended to replace isc dhcp servers at NASA nor is meant to replace NetworkManager in Ubuntu but is targeted as an standard way for ultra minimal system(like ARM-Mips embeeded) to obtain very cheaply the most basic way to get an IP and a network connection since for this target systems an isc dhcp client/server or NetworkManager are like killing an ant with a 100 nukes, remember linux run in a very wide range of systems not just your ubuntu desktop.

                2.) cron systemd: omg rewriting the OS RUN!!!!: no again this is meant to provide standarization baselines and integration from the services more easily, sure a/f/d/ng/x/cron are good but neither are good at integration neither are 100% compatible with each other and neither are standard in distros and not all of them are small enough to be used on embedded, again remember linux run on a very wide scope of systems

                etc, the point is not all the functions in systemd are meant to be used by X system/platform but is more like a set of standard tools that are available and integrable with the init system ondemand depending on your needs, so sure some are stupid to use in a desktop or a server but they are life saver and real world problem solvers in Virtualization and embedded or supercomputers or micro-controllers or specialized system for example

                Comment


                • #18
                  Originally posted by jrch2k8 View Post
                  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
                  It is a blacklist-based shortcut because it's doing exactly that (blacklisting) and is simply a shortcut for something previously possible by using ReadOnlyDirectories directly. If the service is running as root, it's in no way constrained by this. If the service isn't running as root, then /usr is already entirely read-only via DAC.

                  There are high value security features in systemd like PrivateDevices=yes, PrivateTmp=yes, PrivateNetwork=yes, seccomp and the capability support. It seems to be missing the ability to enter a process namespace and set the no_new_privs bit (at least without seccomp) so there's plenty of low-hanging fruit left.

                  I'm missing the point of making a shortcut for a specific directory blacklist with little security value. It doesn't involve much implementation work so it's not a big deal in that sense, but it does dilute the high-value security features with nearly useless ones. There's a limit to the obscure settings people will tolerate in the unit files, and this is a waste of the complexity budget.

                  Comment


                  • #19
                    Originally posted by zanny View Post
                    The problem is that for any distro, the second you say "put your MAC in learning mode" you have already failed. You want either the architects / packagers themselves, or the security project, to produce profiles for all the various binaries shipped, because you can't audit the ones you already have.

                    That is why I can't really trust tomoyo, even though it is supported out of the box on Arch.

                    And it is also not practical to tell someone to install Manjaro, put gr in learning mode, and then shut it off, and to know when to go back in and fix it when some application legitimately wants access somewhere else - the designer of the software would have known this, but just analyzing binary behavior and assuming that is the limited scope of intended uses can miss a lot of rare resource utilization that is intended.

                    My impression having tried both is that AppArmor profiles are much more intuitive for an Arch packager to use, since they are path based, you are already installing the program according to ACLs on directories given you by the Arch base. Of course I am biased, though, since I've never tried grsecurity in practice because I feel learning mode defeats the point for a consumer user - for enterprise, learning MAC is great because they have the capacity to audit their programs directly and trust them, and then they just have to ironclad for exploits from the base rules. We don't really have that convenience in the consumer space.

                    But honestly I don't care which, and I would contribute if there was any forerunner attempting to do so, but it is a huge undertaking to try to generate profiles for all Arch packages (for any MAC), let alone the AUR. But I don't think it is a solvable problem, because the theoretical best case is that pacman begins mandating MAC profiles (from whatever MAC is most popular, I don't care which) in all packages, with some optional switch to disable it, in the same way it requires signed packages right now.

                    But just because it is a hard problem doesn't mean it is not worth solving - I think it is a deep fundamental weakness in any distribution based on binary packages to not have fine grained access control on its binaries, because you never know what exploits or backdoors might trickle in from upstream. It makes Linux seem like childs play next to Android, which has a great user facing resource access control model, that is not as finely tuned as good MAC, but much better than "any binary ever can access all the network resources, the X screen, all your user readable logs, all your other program binaries, every config and share in your home directory, all your etc configuration...".
                    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).
                    Last edited by strcat; 04 June 2014, 01:39 PM.

                    Comment


                    • #20
                      And there lays the trouble with all that hate

                      Originally posted by TheBlackCat View Post
                      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?
                      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.

                      Comment

                      Working...
                      X