New Sandboxing Features Come To Systemd

[Truth]

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.

[curaga]

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.

[strcat]

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.

[strcat]

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.

[jrch2k8]

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)

[Luke_Wolf]

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.

[rmiller]

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.

[asdfblah]

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

[liam]

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.

[zanny]

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

What kind of policies would you accept? As I said, I really want to see Arch usable for everyone I know and not just myself, but they need good MAC that I can trust with a comprehensive included policy set. I just don't see the likelihood of out of tree patches being added to the Arch stock kernel, so I don't even see the road that leads to getting it into the stock kernel. And if it isn't in the stock one, there are all the aur or extended kernel mods like ck or pf that won't build it, and you end up compiling your own kernels if you want the latter stuff. Albeit, having used the ck and pf patchsets, I always end up going back to stock just because the maintenance and circumstantial breakage gets excessive. And my last point of contention is that grsecurity is not used in any major mainstream distribution,

I'll try it the grsecurity Arch kernel this weekend, though. Is there an IRC / mailing list for its development? I do want to get involved at some point with policy creation, albeit I'm coming from a guy who has only contributed to Suse apparmor profiles and has never used the gr tools. I'll need to get some reading done...

Some initial impressions though, after reading the wiki pages, READMEs from the grsec site, and a new superuser posts about it:

1. They don't try to mainline it because they don't want parts in the mainline kernel, they want the whole package - and they perceive the kernel developers as security hostile. Honestly, my biggest issue with this project is that it looks like it can never become mainline, and thus it can never become popular. This is why I've always supported apparmor - it is flawed, it is insufficient, it breaks a lot, but it is better than nothing and usable. I have no gripes with it if the majority of the Arch ecosystem considers adopting it, though.

2. Is there a way to only use per subject policies, rather than user policies? For single user systems polkit and systemd already do the appropriate resource allocations to unprivileged users, the user profiles seem redundant in that context - usually the DAC policies of the packages themselves are more than sufficient, and what I really want is binary hardening and restricted policies so exploited network facing software can't start jacking the entire system. I get where they have value on, say, a huge LDAP server, where just having custom groups for each user class is insufficient.

3. I thought the stock kernel already does ASLR and has noexec page flags.

The profiles look very apparmor-esque, though, which is good. Trying to do any access control in SELinux makes me want to devour brains since mine melted. Network access controls are nice and fine grained...

Damn it, the more I'm reading about gr, I'm strongly regretting my writing it off years ago under the pretense "it is not mainline, it can never be serious". Kind of hypocritical to think the LSM model is a broken wreck and ridiculous while not considering out of tree security models that avoid using it.

Also, this is making me really want to think about switching my server to Arch from Debian just for the gr kernel.