Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 38

Thread: New Sandboxing Features Come To Systemd

  1. #21
    Join Date
    May 2013
    Posts
    570

    Default And there lays the trouble with all that hate

    Quote 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.

  2. #22
    Join Date
    Jan 2014
    Posts
    27

    Default

    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.

  3. #23
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,185

    Default

    Quote 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.

  4. #24
    Join Date
    Mar 2011
    Location
    Canada
    Posts
    97

    Default

    Quote 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.

  5. #25
    Join Date
    Mar 2011
    Location
    Canada
    Posts
    97

    Default

    Quote 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 at 02:56 PM.

  6. #26
    Join Date
    Jun 2009
    Posts
    1,180

    Default

    Quote 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)

  7. #27
    Join Date
    Jun 2011
    Posts
    1,030

    Default

    Quote 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.

  8. #28
    Join Date
    May 2014
    Posts
    8

    Default 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.

  9. #29
    Join Date
    Oct 2012
    Posts
    245

    Default

    Quote 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...

  10. #30
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •