Announcement

Collapse
No announcement yet.

New Sandboxing Features Come To Systemd

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

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


    • #17
      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; 06-04-2014, 01:13 PM.

      Comment


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


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


          • #20
            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; 06-04-2014, 01:39 PM.

            Comment


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


              • #22
                I wonder how much the anti-systemd shills in this thread are getting paid by Microsoft to try and sabotage the evolution of an effective open platform.

                Because let's face it, no intelligent person would think the cluster of bloated, poorly suited scripts most of these shills advocate are actually a good solution, it's just Microsoft scared of a modern open platform. They want you to be stuck in the dark ages.

                Enemies of systemd are enemies of free and open source software. Truth.

                Comment


                • #23
                  Originally posted by jrch2k8 View Post
                  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
                  If you pull the embedded card, you're going to have to explain what is wrong with the standard busybox. You know, the thing used in 99% of embedded linux.

                  Comment


                  • #24
                    Originally posted by Truth View Post
                    I wonder how much the anti-systemd shills in this thread are getting paid by Microsoft to try and sabotage the evolution of an effective open platform.

                    Because let's face it, no intelligent person would think the cluster of bloated, poorly suited scripts most of these shills advocate are actually a good solution, it's just Microsoft scared of a modern open platform. They want you to be stuck in the dark ages.

                    Enemies of systemd are enemies of free and open source software. Truth.
                    There were a couple trolls which is to be expected in a phoronix thread about anything. It's quite silly to attribute it to a conspiracy involving Microsoft.

                    Comment


                    • #25
                      Originally posted by curaga View Post
                      If you pull the embedded card, you're going to have to explain what is wrong with the standard busybox. You know, the thing used in 99% of embedded linux.
                      systemd-networkd was written with containers and servers as the main initial use cases, not embedded systems or desktops. In a container, the performance improvement over the existing Linux dhcp clients is incredible and greatly speeds up spinning up a container. On a system talking to a dhcp server over the network, that's much less important since there's a whole lot of extra latency and most consumer routers are incredibly slow to start with. It could work well on an embedded system, but there are existing lightweight alternatives to dhclient / dhcpcd

                      It also has a nice plain text configuration format and good support for dealing with edge cases like bridges and bonding.
                      Last edited by strcat; 06-04-2014, 02:56 PM.

                      Comment


                      • #26
                        Originally posted by curaga View Post
                        If you pull the embedded card, you're going to have to explain what is wrong with the standard busybox. You know, the thing used in 99% of embedded linux.
                        busybox is fine, it provide many tools that you could need but is not exactly standard and for certain task/usages requires a lot of hand tuning but could be better than systemd depending your use case.

                        until now busybox is basically the only way to have a semi decent small linux system from ultralow - high end embeded but the side effect is every embed device is totally unique and is really hard to support 3rd party aggregates or even extend functionality. I mean once you decide to leave your confort zone of GPIO led displays and a small autostarted C app that collect data and send result to an tty to a world of smart interactive touch enable devices busybox become really hard to deal with and is very error prone and this is what systemd and wayland are focused on solve on embedded(with a bit of Qt5) thanks to the smartphones revolution, now even a crappy ARM cortex SoCs has gotten loooot better and many have enough GPU to handle accelerated interactivity(the drivers are horrible tho, FUCK YOU QUALCOMM).

                        so and this is my point, you need the right tool for the job, aka if you only need to capture data and send to an tty(industrial sensors for example) for later analyze don't be a moron, go grab busybox and minimal kernel image set to autostart you C app and flash it to a rom because anything else is overkill but if you wanna provide smart visualization and analisis devices with touch screens, network support, security(for personel access/access hierarchy/etc) then you need systemd because you need to handle multiple services, initialization order, network autostart, ondemand services tosave power, basic OS integrity, etc. and systemd can do so standarly which make your job lot easier in the future specially if you wanna add functionality later.

                        sure busybox(+other tools ofc) can do both but for the second scenario is a lot harder and require you to reinvent the wheel everytime(and normally your wheel end up been unique so only you can understand it)

                        Comment


                        • #27
                          Originally posted by strcat View Post
                          There were a couple trolls which is to be expected in a phoronix thread about anything. It's quite silly to attribute it to a conspiracy involving Microsoft.
                          Please do not respond to this guy, "Truth" is a well known troll, like endman and beetreetime.

                          Comment


                          • #28
                            Not so cool

                            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.

                            Comment


                            • #29
                              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.
                              Exploitable security bugs are profitable... Those "reports" will come in the form of 0days, discovered by chance by security researchers; they will make fun of them, and corporations opposing Linux will profit from the bad publicity.
                              BTW, I'm still wondering if there is any security researcher auditing systemd...

                              Comment


                              • #30
                                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...".
                                Err, android's only Mac, tmk, is selinux.

                                Comment

                                Working...
                                X