Linux

48008 readers

816 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago

MODERATORS

[email protected]

112

Fedora 40 Will Enable Systemd Service Security Hardening (fedoraproject.org)

submitted 10 months ago by [email protected] to c/[email protected]

10 comments fedilink hide all child comments

Summary

Improve security by enabling some of the high level systemd security hardening settings that isolate and sandbox default system services.

Benefit to Fedora

Fedora services will get a significant security boost by default by avoiding or mitigating any unknown security vulnerabilities in default system services.

all 14 comments

sorted by: hot top controversial new old

[–] [email protected] 23 points 10 months ago

This is great and already used on some distros like NixOS for many services. Regular users won't notice this change.

[+] [email protected] -27 points 10 months ago (3 children)

Cool, but why is it part of the init system?

[–] [email protected] 28 points 10 months ago (1 children)

You misspelled "System and Service Manager"

[–] [email protected] 56 points 10 months ago (1 children)

Yeah, it's not really advertised as an init system anymore. It's an entire system management suite, and when seen from that angle, it's pretty good at it too. All of it is consistent, it's fairly powerful, and it's usually 10-20 lines of unit files to describe what you want. I wanted that for a long time.

I feel like the hate always comes from the people that treat the UNIX philosophy like religion. And even then, systemd is very modular, just also well integrated together: networkd manages my network, resolved manages my DNS, journald manages my logs, timesyncd manages my NTP, logind manages my logins and sessions, homed mounts my users profiles on demand.

Added complexity, yes, but I've been using the hell out of it. Start services when a specific peripheral is plugged in? Got it. Automatically assign devices to seats? Logind's got you covered, don't even need to mess with xorg configs. VM network? networkd handles it. DNS caching? Out of the box. Split DNS? One command. Don't want 2000 VMs rotating their logs at exactly midnight and trashing your ceph cluster? Yep just slap a RandomizedDelaySec=24h to the units. Isolate and pin a VM to dedicated cores dynamically? Yep it'll do that. Services that needs to run on a specific NUMA node to stay close to PCIe peripherals? Yep easy. All very easily configurable with things like Ansible or bash provisioning scripts.

Sure it may not be for everybody, but it solves real problems real Linux admins have to deal with at scale. If you don't like it, sysvinit still works just fine and I heard good things about runit too. It's an old and tired argument, it's been over 10 years, we can stop whining about it and move on. There's plenty of non-systemd distros to use.

[–] [email protected] 10 points 10 months ago

Saving this for all my future pro-systemd flames, thank you!

[–] [email protected] 8 points 10 months ago

The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.

So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.

A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.

So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It's all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs -- something still a thing in many other inits.

I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.