Announcement

Collapse
No announcement yet.

Systemd's Plan For Stateless Systems, Factory Resets

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

  • #21
    Originally posted by oneofone View Post
    I truly hope all the systemd trolls are just trolling for fun, because it must be such a pathetic existence to actually believe the random shit they say on systemd topics.
    i do believe they actually believe what they preach probably because most of them aren't devs or are highel level languages devs that never used git before, so they actually believe systemd is an nvidiaesque 30million LoC single blob named systemd that weights 1 Gb that reside in an evil git single repository when the actual facutal truth is that systemd is pretty much KISS compliant, dozens of small service in separate executable running ondemand exclusively when needed and this dozens of binaries only are good at doing very specific things and small sized.

    In fact systemd only need 5 systems to run, PID1 service, Dbus,Udev, journalctl and logind everything else is optional or ondemand and the "evil" additional tools are included to keep the standarization effect but prolly will never be used if it doesn't fit your use case

    Comment


    • #22
      Originally posted by justmy2cents View Post
      if i would have to guess, the applications will probably reside in both usr and home as part of http://www.superlectures.com/guadec2...ions-for-gnome
      Originally posted by interested View Post
      Looking into the crystal ball, the future seems to be that will be two kinds of "apps": the normal ones as we know it, in form of a rpm or deb package, and "sand boxed" apps that are developed via a special SDK, and runs in an environment that are totally independent of the underlying OS.

      Such SB apps can in theory run unmodified on any Linux distribution that support the sand boxing environment. Such apps could in theory be carried over to a new OS (either OS upgrade or another brand) without modification and without loss of data and configuration.
      There still needs a lot of work to make this happens, like kdbus in the kernel etc, so this is mostly theoretical at this point.

      AFAIK, you can just install normal apps either system wide in the "golden master" image (persistent) or in a running OS container if you got the right user permissions (might not be persistent across boots, depending of model.)


      I especially like the "Verifiable System". Security is so damn hard to get right on the Internet and every system exposed is under a constant attack. It would be nice if only a sand boxed container OS was exposed to the net, that could be verified as not-compromised (AV-scanners etc. aren't much help against this these days, and Tripwire and similar also have its problems).
      That makes a lot of sense. So, system wide apps get installed through the package manager to somewhere on / and sandboxed apps go to /home. However, will these sandboxed apps get to make any use of the system-wide installed libraries?

      Originally posted by justmy2cents View Post
      at least how i get it, i think there is no need for special SDK. making package would be the matter of build tools, where you specify target aka. "i want to run this on everything up from CentOS 5". build tools should simply make the package that will contain all the libraries needed to run on desired targets. no matter if you'll run it on distro that would already supply most of required ones.

      as far as SDK for sandboxing goes, again there should be no need for that. that is matter of sandbox it self, not your application. you need port 34534 for example, your socket code is just as usual, no difference. but, unless you specified sandbox to open it for you, sandbox simply won't allow it to pass trough. beside security, it also gives great overview of what application will do before it can do it. unlike half assed sandboxing in android for example

      not all applications would make sense to deploy like that, hell... i love package distribution. but for a lot... it's a way to go. it's also a way to get commercial development on board since targets are not restricted to singular distribution and you can provide long term support without the need to patch it every week just because some OSS project changed. not to mention the flaw of package management, usually you get constricted to specified version of app for whole life time of that distro, where installing newer can be rather painful experience.
      Could it be made so Gnome's libraries and KDE's Frameworks (which always come with an explicit minimum version of Qt that can be used) be made the SDK? Sort of how the Free Desktop Standards expects Qt and GTK to both be parts of the "Free Desktop" (which is what we all should refer to these desktops collectivitly, it's why the standard is there). This way, each sandboxed app does not have to include all of these libraries AND these important libraries will be sandbox ready.

      Originally posted by interested View Post
      There are several kinds of sand boxing when it comes to systemd. The present one relies on "kernel capabilities" and "cgroup" and is good for protecting services; you can lock down services so even if the "http" daemon is compromised, the attacker can't get privilege escalation, even by executing arbitrary code. Or prevent an attacked daemon from fork-bombing or hogging IO or CPU time. It can also prevent a compromised daemon from reading certain directories, even if it manages to execute code with system wide rights (root) etc.

      The other kind of sand boxing isn't implemented yet. It will require kdbus and "Portals" (similar to Android's "Intents" http://www.phoronix.com/scan.php?pag...tem&px=MTI5NDQ

      It will probably have a special SDK, so developers can target that instead of the underlying OS.
      The thinking is, that this allows app developers to potentially target all Linux distros at the same time, and will be a tremendous boost for Linux based phones and tablets.

      A problem now a days is, that Linux has a small desktop userbase, and even that base is fragmented into countless variations. This makes it hard to convince e.g. the local Metro train company, or bank to develop a Linux app, and if they do, they tend to only target large userbase Linux distros like Fedora or Ubuntu.
      A stable SDK and API that potentially works across all Linux distros will make it much more attractive for third party developers.

      This kind of sandboxing will of course also be of great use for normal programs: as it is now, a browser can read/write everywhere the user can, even do it without user permission too. This is bad when a browser gets compromised, since it can steal information or plant a trojan or similar.
      When sandboxed the browser may be limited to certain directories and if it wants to read a file, it doesn't do it directly, but will have to ask the "Portal" to fetch it, ensuring that the user can give it permission or deny the request.
      That last part sounds like an amazing use case. That does sound a lot like Android's content providers (which makes use of Android Intents).

      Though that makes me wonder; can Javascript apps like Dropbox and Gmail actually read my files at any given moment, or just the ones I chose using the file chooser?

      Thanks for the anwsers justmy2cents and interested.

      Comment


      • #23
        Originally posted by CTown View Post
        That makes a lot of sense. So, system wide apps get installed through the package manager to somewhere on / and sandboxed apps go to /home. However, will these sandboxed apps get to make any use of the system-wide installed libraries?
        Could it be made so Gnome's libraries and KDE's Frameworks (which always come with an explicit minimum version of Qt that can be used) be made the SDK? Sort of how the Free Desktop Standards expects Qt and GTK to both be parts of the "Free Desktop" (which is what we all should refer to these desktops collectivitly, it's why the standard is there). This way, each sandboxed app does not have to include all of these libraries AND these important libraries will be sandbox ready.
        at least as far as i get it. yes,... and... no. if you watch that video link, he mentions how you select target. so, if i selected target like fedora 20, then probably yes. but, if i selected centos5, then it would bundle all libraries needed which means app wouldn't use the ones in system.

        i could also imagine that one could make utility that would strip original sandbox like you ask. don't know that for sure, pure guess

        ahh, and i did one mistake when saying you never need any special SDK. if you have completely locked down sandbox, then you need special SDK. watch the part where it explains how app would access file. except, that isn't some library with its API like usual, but rather known IPC provider for that feature. video is really worth watching, explains whole lot
        Last edited by justmy2cents; 17 June 2014, 09:33 PM.

        Comment


        • #24
          Originally posted by justmy2cents View Post
          what is there to defend against? poster is obviously still in 1985 and way to scared to proceed to reality
          It's because the reality where people believe that utter s..t like systemd can be useful is pretty scary...

          Comment


          • #25
            Originally posted by pouar View Post
            That's much worse
            Not according to Phoronix readers. See how excited everyone is?

            Comment


            • #26
              Originally posted by prodigy_ View Post
              It's because the reality where people believe that utter s..t like systemd can be useful is pretty scary...
              and here you are wearing your big boy pants and defying the all the horror of reality... all this just to enlighten us. ok, you did your best, even if attempt was at best... lame, useless, well.. whatever, even as trolling it was subpar

              now you can take off the bbpants and return to land of sysv, rainbows and unicorns where it is safe

              Comment


              • #27
                Cool, we might end up with systemd using SecureBoot to do the same thing Windows is doing.

                Eventually there could be cool sticker involved too .

                Comment


                • #28
                  Originally posted by justmy2cents View Post
                  and here you are wearing your big boy pants and defying the all the horror of reality... all this just to enlighten us. ok, you did your best, even if attempt was at best... lame, useless, well.. whatever, even as trolling it was subpar

                  now you can take off the bbpants and return to land of sysv, rainbows and unicorns where it is safe
                  Is this guy BO$$? Or just another angry wet mop?
                  Hi

                  Comment


                  • #29
                    Originally posted by interested View Post
                    There are several kinds of sand boxing when it comes to systemd. The present one relies on "kernel capabilities" and "cgroup" and is good for protecting services; you can lock down services so even if the "http" daemon is compromised, the attacker can't get privilege escalation, even by executing arbitrary code. Or prevent an attacked daemon from fork-bombing or hogging IO or CPU time. It can also prevent a compromised daemon from reading certain directories, even if it manages to execute code with system wide rights (root) etc.

                    The other kind of sand boxing isn't implemented yet. It will require kdbus and "Portals" (similar to Android's "Intents" http://www.phoronix.com/scan.php?pag...tem&px=MTI5NDQ

                    It will probably have a special SDK, so developers can target that instead of the underlying OS.
                    The thinking is, that this allows app developers to potentially target all Linux distros at the same time, and will be a tremendous boost for Linux based phones and tablets.

                    A problem now a days is, that Linux has a small desktop userbase, and even that base is fragmented into countless variations. This makes it hard to convince e.g. the local Metro train company, or bank to develop a Linux app, and if they do, they tend to only target large userbase Linux distros like Fedora or Ubuntu.
                    A stable SDK and API that potentially works across all Linux distros will make it much more attractive for third party developers.

                    This kind of sandboxing will of course also be of great use for normal programs: as it is now, a browser can read/write everywhere the user can, even do it without user permission too. This is bad when a browser gets compromised, since it can steal information or plant a trojan or similar.
                    When sandboxed the browser may be limited to certain directories and if it wants to read a file, it doesn't do it directly, but will have to ask the "Portal" to fetch it, ensuring that the user can give it permission or deny the request.
                    Very interesting.

                    Will these new sandboxing features make security systems such as SELinux or RBAC obsolete ?

                    Comment


                    • #30
                      Originally posted by stiiixy View Post
                      Is this guy BO$$? Or just another angry wet mop?
                      nah, i'm just pi$$ed off that only troll that showed up was so lame. usually, systemd thread is so funny. basically, i'm angry i wasted my popcorn for nothing

                      Comment

                      Working...
                      X