Announcement

Collapse
No announcement yet.

Lennart Poettering On The Open-Source Community: A Sick Place To Be In

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

  • Originally posted by interested View Post
    systemd employs powerful kernel security features like "kernel capabilities" and namespaces (and cgroup) that can protect all daemons on the system.
    MAC (selinux or apparmor or whatever) is NOT a systemd feature
    cgroups are NOT a systemd feature
    namespaces ARE a mess (at least currently)

    what are "kernel capabilities" ?


    security fact:
    if an attacker gets root privileges on your computer, you lost
    period

    Comment


    • Originally posted by gens View Post
      MAC (selinux or apparmor or whatever) is NOT a systemd feature
      cgroups are NOT a systemd feature
      namespaces ARE a mess (at least currently)
      Right. However, practically speaking, those `kernel features' aren't features at all as long as they're not exposed in a meaningful way. A feature that's not usable without e.g. hacking together a shell script first is not a real feature. It's a geek substitute for jerking off. (Not saying that's necessarily a bad thing.) Systemd exposes e.g. cgroups in a way that's not a total PITA for the average admin and/or integrator to use. I'd like to say that systemd's doing a good job at it, but since we've never had the kind of plumbing that's provided by it, there's simply no frame of reference.

      Originally posted by gens View Post
      what are "kernel capabilities" ?
      He was likely refering to capabilities(7).

      Comment


      • Originally posted by gens View Post
        MAC (selinux or apparmor or whatever) is NOT a systemd feature
        cgroups are NOT a systemd feature
        That precisely why he said "kernel security features". You're trying too hard.

        Comment


        • Originally posted by ceage View Post
          Right. However, practically speaking, those `kernel features' aren't features at all as long as they're not exposed in a meaningful way. A feature that's not usable without e.g. hacking together a shell script first is not a real feature. It's a geek substitute for jerking off. (Not saying that's necessarily a bad thing.) Systemd exposes e.g. cgroups in a way that's not a total PITA for the average admin and/or integrator to use. I'd like to say that systemd's doing a good job at it, but since we've never had the kind of plumbing that's provided by it, there's simply no frame of reference.
          i still fail to see how selinux relates to systemd

          as for cgroups and shell scripts jerking off
          http://libcg.sourceforge.net/ looks simple and straightforward to me

          also from the kernel Documentation
          Code:
          To start a new job that is to be contained within a cgroup, using
          the "cpuset" cgroup subsystem, the steps are something like:
          
           1) mount -t tmpfs cgroup_root /sys/fs/cgroup
           2) mkdir /sys/fs/cgroup/cpuset
           3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
           4) Create the new cgroup by doing mkdir's and write's (or echo's) in
              the /sys/fs/cgroup virtual file system.
           5) Start a task that will be the "founding father" of the new job.
           6) Attach that task to the new cgroup by writing its PID to the
              /sys/fs/cgroup/cpuset/tasks file for that cgroup.
           7) fork, exec or clone the job tasks from this founding father task.
          
          For example, the following sequence of commands will setup a cgroup
          named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
          and then start a subshell 'sh' in that cgroup:
          
            mount -t tmpfs cgroup_root /sys/fs/cgroup
            mkdir /sys/fs/cgroup/cpuset
            mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
            cd /sys/fs/cgroup/cpuset
            mkdir Charlie
            cd Charlie
            /bin/echo 2-3 > cpuset.cpus
            /bin/echo 1 > cpuset.mems
            /bin/echo $$ > tasks
            sh
            # The subshell 'sh' is now running in cgroup Charlie
            # The next line should display '/Charlie'
            cat /proc/self/cgroup
          also simple
          and since it exposes a virtual file system, it makes it easy to get an overview from any kind of language ( C, shell, C++, lolcode, whatever can do files )

          but ye sure, if people like it another way that's fine
          i like the "everything is a file" way of simple modern system programming

          Comment


          • Originally posted by erendorn View Post
            That precisely why he said "kernel security features". You're trying too hard.
            y, my bad

            i just don't know why many people think you NEED systemd to use those features
            and because youknowwho talks as if you do, many do think like that (especially for cgroups)

            Comment


            • They attack it, because they're noobs.

              Comment


              • Originally posted by gens View Post
                MAC (selinux or apparmor or whatever) is NOT a systemd feature
                I am not talking about MAC's. systemd's security features works on top of MAC's, and aren't a substitute for those.


                Originally posted by gens View Post
                cgroups are NOT a systemd feature
                namespaces ARE a mess (at least currently)
                cgroups is a kernel feature, the point being that every systemd distro have easy support for cgroup right out of the box and by default. On non-systemd distros the SA have to muck around with rather complicated instructions, while on systemd distros the SA can just add a single keyword to a text config file in order to use a cgroup feature (or use the systemctl CLI tool).

                And good luck with having future cgroup support on non-systemd distros when the OS container developers switches to systemd. Considering how few developers the systemd-opponents can attract, the software will bit rot shortly after such a switch.

                Kernel namespaces can be criticized, but they do work and are improved all the time, and is what all the non-systemd OS container projects like LXC relies on.
                Using Kernel namespaces on top of MAC's etc., provides better security than not using kernel namespaces.


                Originally posted by gens View Post
                what are "kernel capabilities" ?
                http://man7.org/linux/man-pages/man7...ilities.7.html
                0pointer.de/blog/projects/security.html

                In short, kernel capabilities can limit what a program can do, and any process that is forked from that inherits the limitations.


                Originally posted by gens View Post
                security fact:
                if an attacker gets root privileges on your computer, you lost
                period
                Kernel capabilities can inhibit even root binaries. That is a major point about them, so they supplement ACL's beautifully.


                The whole point is that systemd allows easy use "out-of-the-box" for such powerful kernel security features. The distro maintainers may turn on such features without the end-user being aware of anything or need to configure complex scripts or read difficult tutorials and man pages.

                What makes systemd such a cool project is that they make it easy for both end-users, distro maintainers and developers to use advanced kernel features.

                Comment


                • Originally posted by interested View Post
                  cgroups is a kernel feature, the point being that every systemd distro have easy support for cgroup right out of the box and by default. On non-systemd distros the SA have to muck around with rather complicated instructions, while on systemd distros the SA can just add a single keyword to a text config file in order to use a cgroup feature (or use the systemctl CLI tool).

                  And good luck with having future cgroup support on non-systemd distros when the OS container developers switches to systemd. Considering how few developers the systemd-opponents can attract, the software will bit rot shortly after such a switch

                  ....


                  In short, kernel capabilities can limit what a program can do, and any process that is forked from that inherits the limitations.

                  Kernel capabilities can inhibit even root binaries. That is a major point about them, so they supplement ACL's beautifully.

                  The whole point is that systemd allows easy use "out-of-the-box" for such powerful kernel security features. The distro maintainers may turn on such features without the end-user being aware of anything or need to configure complex scripts or read difficult tutorials and man pages.

                  What makes systemd such a cool project is that they make it easy for both end-users, distro maintainers and developers to use advanced kernel features.

                  well, a couple things
                  i'l keep it to the point

                  putting processes in cgroups is easy and can be added to any init easily
                  either with existing mechanisms or by adding one more kind of declaration in whatever form of .config/.service/.whatever or even by just doing it automatically
                  looking at it i could add it to my computers rc stile shell script based init in some half an hour - hour (a pessimistic approximation)

                  what are OS container developers ?
                  docker ?

                  anyway
                  cgroups are a simple mechanism with a simple and flexible API
                  just reading the short kernel documentation on them is enough to be able to use all of it
                  will systemd provide you with every cgroups feature ?
                  i see it only uses them so that it itself does not have to track a process, but maybe i'm wrong

                  as for end users
                  end users do not need to even know what cgroups are
                  in fact almost all end users won't notice any difference

                  if you are more of a "power user"
                  systemd will get in your way
                  look around what launchd users have to say, they have been using something like it for a longer time

                  as for security
                  the NX bit can be rendered useless
                  the "vm.mmap_min_addr = 4096" protection against null pointer dereferencing attacks can be worked around
                  etc
                  my point is you have to fix security bugs in every program that can be accessed in any way
                  adding layers, while definitely helpful, may instill a false sense of security
                  and there is no bigger security threat then false sense of security

                  if you want a secure system you have to make lots of sacrifices, as shown by distros that heavily focus on security
                  moreover there are some kernel feature that can, if an attacker gets the privileges to use them, enable an attacker to do whatever without leaving a trace
                  (ptrace, /proc and idk)


                  but i'm no security expert
                  i just watch ccc videos 'cuz i like low level stuff


                  as for systemd making things easy
                  that can be discussed as much as gnome3 making things easier compared to gnome2


                  PS sorry but ever since you said that i need to get enlightened, i can not take you too seriously
                  just being honest
                  (i still try)

                  Comment


                  • Originally posted by gens View Post

                    putting processes in cgroups is easy and can be added to any init easily
                    either with existing mechanisms or by adding one more kind of declaration in whatever form of .config/.service/.whatever or even by just doing it automatically
                    looking at it i could add it to my computers rc stile shell script based init in some half an hour - hour (a pessimistic approximation)
                    I don't think you can use the new cgroups "unified hierarchy" in a secure way without a manager of some sort.
                    Not a problem, there already exist such managers such as "cgmanager" (Ubuntu/LXC).

                    I think it would be great if the non-systemd distros actually copied systemd features and made a cgroup framework that made it easy for SA's to use "out-of-the-box".
                    I don't have high expectation of it happening though.


                    Originally posted by gens View Post
                    what are OS container developers ?
                    docker ?
                    Yes, and LXC (and systemd of course). There are others. They are developing and maintaining almost all the cgroups software, but since they are beginning to switch to systemd, they will drop all such development over time. Again, the lack of developers and focus on development on the non-systemd distros, make it hard to believe that somebody is picking up that development.

                    Originally posted by gens View Post
                    anyway
                    cgroups are a simple mechanism with a simple and flexible API
                    just reading the short kernel documentation on them is enough to be able to use all of it
                    will systemd provide you with every cgroups feature ?
                    i see it only uses them so that it itself does not have to track a process, but maybe i'm wrong
                    systemd also uses cgroups to limited resources, either by adding simple keywords to the unit/slice, or by using "systemctl" tool on running services like this: "systemctl set-property httpd.service CPUShares=500 MemoryLimit=500M"


                    Originally posted by gens View Post
                    as for end users
                    end users do not need to even know what cgroups are
                    in fact almost all end users won't notice any difference
                    cgroups (as resource manager) are useful, even for people who doesn't care, can't program etc. Think; a Wayland window is maximized in order to play a game; the system automatically limits all other windows and background processes to a minimum, and gives the game absolute latency priority. Or somebody who uses a pro audio program; they want nothing to disturb their latency, but want it done automatically since they want to make music, not fiddle with OS' internals.


                    Originally posted by gens View Post
                    if you are more of a "power user"
                    systemd will get in your way
                    look around what launchd users have to say, they have been using something like it for a longer time
                    While systemd was inspired by launchd, they simply can't compare with features and scope: systemd is now much, much more advanced. It really isn't a limiting factor, even for extreme powerusers.

                    Originally posted by gens View Post
                    as for security
                    the NX bit can be rendered useless
                    the "vm.mmap_min_addr = 4096" protection against null pointer dereferencing attacks can be worked around
                    etc
                    my point is you have to fix security bugs in every program that can be accessed in any way
                    adding layers, while definitely helpful, may instill a false sense of security
                    and there is no bigger security threat then false sense of security
                    There isn't a "silver bullet" in security. This is why security in depth is the only way forward for Linux. The old Linux security model is quite sound, but it is brittle; once an attacker have exploited a process, there are few restrictions on gaining new privileges and thereby getting all the keys to the kingdom.

                    By combining ACL's with MAC's like SELinux, with namespace process isolation and ensuring that any running process only have the absolute minimal amount of capabilities, you can begin to sandbox services, and making them hard to be used as a jump-board for gaining new privileges.

                    Every defence layer should either prevent or at least minimize further attack vectors, making it ever more difficult and "costly" for the attacker to gain access to the system.

                    But it isn't enough to make it difficult and "costly" for the attacker, the defence should be as easy and "cheap" as possible; "cheap" foremost in man and brain power needed by the end user to make the defences, but also of course in hardware/processing cost and usability; a defence that bogs down the pc or otherwise makes it too hard to use, is of no use.

                    It is quite possible to harden Linux without using systemd, but historically this have meant that the end user should configure a lot of things manually, perhaps even glue some subsystems together with code, and basically read up on the security framework. The end result was that few bothered.

                    With systemd, a lot of this becomes much easier, since systemd provides a high level, uniform framework for adding several security features. Much of this security will be "cheap" as in, requiring no work for the end user; the daemons will simple come pre-hardened by the distro.

                    Again, I think it would be great if the non-systemd distros would implement similar features as default, but it would require a developer community that doesn't seem to exist at the moment.

                    Comment


                    • Originally posted by interested View Post
                      I think it would be great if the non-systemd distros actually copied systemd features and made a cgroup framework that made it easy for SA's to use "out-of-the-box".
                      I don't have high expectation of it happening though

                      ....

                      systemd also uses cgroups to limited resources, either by adding simple keywords to the unit/slice, or by using "systemctl" tool on running services like this: "systemctl set-property httpd.service CPUShares=500 MemoryLimit=500M"

                      cgroups (as resource manager) are useful, even for people who doesn't care, can't program etc. Think; a Wayland window is maximized in order to play a game; the system automatically limits all other windows and background processes to a minimum, and gives the game absolute latency priority. Or somebody who uses a pro audio program; they want nothing to disturb their latency, but want it done automatically since they want to make music, not fiddle with OS' internals..

                      so..
                      cgroups, as in just the process grouping part of them, are light
                      as soon as you add cpu/io/net limiting, they are no longer that light

                      linux already deals with latency since it is by design a preemptive kernel
                      sound has precedence, as do some other hardware thingies (powertop gives an overview)
                      even CFS, as a process timeslice scheduler, is designed to have a maximum latency
                      and even more, it is designed to be completely fair (hence the name)

                      for example, and i will simplify the example;
                      you have a process, that we will call "game"
                      and another process that we will call... idk.. "compile"
                      they bout use as much cpu as they can, 100% if they can
                      if you don't do anything they will bout get 50%
                      even if you compile with multiple threads, that in the linux scheduler are treated as processes, you will still get 50%-50% thanks to process grouping (automatic)

                      but if you give the compile process a nice of 20, then things get interesting
                      according to this the formula for calculating a "weight" of a process as seen by CFS is
                      1024 / (1.25 ^ nice_value)
                      so a process of nice 0 (our game) has a weight of 1024, while a process of nice 20 weights approximately 11.8
                      as we can see the ratio of those two processes is 1024 to 11.8, that is almost 100 to 1
                      more precisely, the "compile" process would get ~1.14% of total cpu time
                      same as putting it in a cgroup and limiting it to 1.14% cpu (and it will take more time to finish its work, in practice)
                      the formula used is ( 100 / ( 1024 / (1.25 ^ 20) + 1024 / (1.25 ^ 0) ) ) * 1024 / (1.25 ^ 20) , if anyone's interested
                      i sincerely doubt that would make any difference when playing a game

                      the other important thing is IO, more precisely disk IO
                      should be a similar, if not the same, thing,
                      it's just called ionice instead of nice
                      and since, and i quote, "For kernels after 2.6.26 with the CFQ I/O scheduler, a process that has not asked for an I/O priority inherits its CPU scheduling class."
                      just setting a background processes nice to 20 would work just fine
                      potentially even better then cgroup arbitrating (worst case, the same)

                      afaik distros give the package upgrading process a niece of 20 by default,
                      so that's not a problem at all (on the latency side)


                      so that just leaves the network and memory
                      memory is a tricky thing and most processes deal with out of memory conditions by flat out failing, so limiting is only a safeguard in case of leaking
                      and leaking memory is a bug
                      another, better, way of dealing with constrained memory is to not use bloated software

                      as for network
                      if QoS would work properly you could download torrents and still get good ping
                      if router manufacturers would build the god damn things right there wouldn't even be a need for QoS
                      ( check out byte queue limits for a software solution to that, phoronix also had an article on that )
                      ye sure, limiting every other processes network speed can get the same effect
                      or, you know, you could just not download porn while playing

                      (on a single core cpu, you wouldn't want cgroup cpu/memory/io limiting overhead anyway)


                      as for audio latency, that's easy
                      just don't use PulseAudio
                      we, as linux gamers, had the single clear advantage over windows by having almost no audio latency
                      using PA we loose that claim
                      it (PA) is ironic in that it claims low latency and the only optimization, except the bad scheduler, is int to float using SSE

                      and it could do so much more, like using movntdq (SSE2) as to not pollute the cache when writing to the device buffer
                      even that (writing to the device buffer directly) has been used by youknowwho to claim that the whole of PA has a "zero-copy" architecture
                      zero-copy is NOT an architecture, it is a feature of the motherboards northbridge architecture used to copy from RAM to and from a device (or RAM) without involving the cpu
                      and even that is not as good as it sounds, as it brings other implications that i could write a whole page about
                      so PA's architecture could be best described as a "memcpy()" architecture
                      (and there is loads more BS in how PA is described, and how ALSA is described when compared to PA)


                      i could talk about the rest, but this is tiring me slowly

                      Comment

                      Working...
                      X