# ProtectSystem=
TemporaryFileSystem=/:ro
BindReadOnly=/usr/bin/binary /lib /lib64 /usr/lib usr/lib64 <paths you want to read>
EDIT: More info here: https://github.com/systemd/systemd/issues/33688
Yesterday's, just in case: https://us.jlcarveth.dev/post/hardening-systemd.md https://news.ycombinator.com/item?id=44928504
well, the con is you might unknowingly break some setups. take NetworkManager: after tightening it down, did you check both IPv4 and IPv6 connectivity? did you check that both the `dns=systemd-resolved` and `dns=default` modes of operation (i.e. who manages /etc/resolv.conf) work? did you check its ModemManager integrations, that it can still manage cellular connections? did you check that the openvpn and cisco anyconnect plugins still work? what about the NetworkManager-dispatcher hooks?
> Why don't distros flip more of these switches?
besides the bit of "how many distro maintainers actually understand the thing they're maintaining well enough to know which switches can be flipped without breaking more than 0.01% of user setups", there's the bit of "should these flags be owned by the distro, or by the upstream package?" if the distro manages these, they'll get more regressions on the next upstream release. if the upstream sets these, they can't be as aggressive without breaking one or two of their downstreams.
Maintainers _could_ take the time to lock down sshd and limit the damage it can do if exploited, but there are costs associated with that:
1. Upfront development cost
2. Maintenance cost from handling bug reports (lots of edge cases for users)
3. Maintenance cost from keeping this aligned with upstream changes
From packaging stuff for nixpkgs, a distro that often is without upstream support, it is usually very useful to look at how mainstream distro package services.
Those hardening steps also tend to be well tested even if sometimes a bit lax. If you want to find out how, e. G., postgresql can be hardened, consider looking at the Debian, Ubuntu and/or RHEL packages as a starting point.
I started my Linux journey so late I can't imagine living without systemd, the few systems I've encountered without systemd are such a major PITA to use.
I recently discovered "unshare" which I could use to remount entire /nix RW for some hardlinking shenanigans without affecting other processes.
systemd is so good, warty UX when interacting with it but the alternative is honestly Windows in my case.
Just an example of systemd limitation is that systemd does not support musl, so if you want to build a tiny embedded sysroot, you already have some limitations.
OpenEmbedded has carried a patchset to build systemd against musl for use in Yocto for a long time.
postmarketOS already got approval from Poettering to make a musl-linked systemd more officially supported.
More information at https://news.ycombinator.com/item?id=2565780
> Why didn't you just add this to Upstart, why did you invent something new?
> Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise.
> If you love Apple launchd so much, why not adopt that?
> launchd is a great invention, but I am not convinced that it would fit well into Linux, nor that it is suitable for a system like Linux with its immense scalability and flexibility to numerous purposes and uses.
launchd is horrible though, the folks complaining about systemd would be up in arms if they had to write poorly typed XML key/value files
1. Agglutination of shell scripts
2. "Oh wow, this is getting annoying"-phase: Wrapper for scripts (SRC SMC openrc etc pp)
3. Service supervision daemons (SMF, launchd, systemd)
This feeling is particular striking for me, because I once worked on a Linux project with the aim of improving packaging and software distribution. We also got a lot of hate, mainly for not being .deb or.rpm, and it looked to me as if the hate was a large reason for the failure of the project.
This matched my experience: there were a few vocal haters who were very loud but tended not to be professional sysadmins or shipping binaries to other people, and they didn’t have a realistic alternative. If you distributed or managed software, you had a single, robust solution for keeping daemons running with service accounts, restarts, dependencies, etc. for Windows NT circa 1993 and macOS in 2005 so Linux not having something comparable was just this ongoing source of paper cuts which caused some Linux shops to have unexpected, highly visible downtime (e.g. multiple times I saw data center outages where all of the Windows stuff and the properly configured Upstart/SystemD stuff come up after retrying but high-profile apps using SysV init stayed down for hours because the admins had to clean it up by hand).
Anyone who packaged software was also happy to stop supporting different combinations of buggy shell scripts and utilities, too – every RPM I built went from hundreds of lines of .sh to a couple dozen lines of better systemd. systemd certainly isn’t perfect but if you had an actual job to do you were going to look at systemd as the best path to reduce that overhead.
Broad view betweeen BSD ecosystem offers that this wasn’t a good way. I still want to see a good alternative from that point of view…
It can be argued that it didn't solve very many problems and added a huge amount of complexity.
Most of the complainers weren't really relevant. They weren't making the decisions on what goes in a distro, and an init system is overall a fairly minor component most users don't use all that often anyway.
> This feeling is particular striking for me, because I once worked on a Linux project with the aim of improving packaging and software distribution. We also got a lot of hate, mainly for not being .deb or.rpm, and it looked to me as if the hate was a large reason for the failure of the project.
I think that's a good deal trickier because packaging is something a Linux user does get involved with quite often, and packaging systems don't mix well. A RPM based distro with some additional packager grafted on top is a recipe for disaster.
Still, I think it's also a case of the same thing: sell it to the right people. Find people making new distros suffering problems with DEB and RPM and tell them your tool can save them a lot of pain. The users can come in later.
To quote one of my favorite Clone Wars episodes: Fifty tried, fifty died [1].
There have been so, so many attempts at solving the "how to ship binary builds for Linux" question... both deb and rpm have their good and their bad, and on top of that you got `alien`, flatpak, Docker images, the sledgehammer aka shipping everything as a fully static binary (e.g. UT2004 did this) or outright banning prebuilt binaries (the Gentoo and buildroot way). But that's not the actual problem that needs solving.
The actual problem is dependency hell. You might be lucky to be able to transplant a Debian deb into an Ubuntu installation and vice versa, or a SLES rpm to RHEL, but only if the host-side shared libraries that the package depends on are compatible enough on a binary level with what the package expects.
That suddenly drives up the complexity requirements for shipping software even for a single Linux distribution massively. In contrast to Windows, where Microsoft still invests significant financial resources into API-side backwards compatibility, this is not a thing in any Linux distribution. Even if you're focusing just on Debian and Ubuntu, you have to compile your software at least four different times (one each for Debian Stable, Debian Testing, Ubuntu <current rolling release> and Ubuntu <current LTS>), simply because of different versions of dependencies. Oh and in the worst case you might need different codepaths to account for API changes between these different dependency versions.
And even if you had some sort of DSL that generated the respective package manager control files to build packages for the most common combinations of package manager, distributions and actively supported releases of these, there's so, so much work involved in setting up and maintaining the repositories. Add in actually submitting your packages to upstream (which is only possible for reasonably-ish open source packages in the first place), and the process becomes even more of a nightmare.
And that's all before digging into the topics of autotools, vendoring (hello nodejs/php/python ecosystems), digital signature keyrings, desktop manager ecosystems and god knows what else. Oh, and distribution bureaucracy is even more of a nightmare... because you now have to deal with quirks in other people's software too, and in the worst case with a time span of many years of your own releases plus the distribution release cadence!
Shipping software that's not fully OSS on Linux sucks, shipping closed source software for Linux sucks even more. Windows has had that sort of developer experience figured out from day one. Even if you didn't want to pirate or pay up for InstallShield, it was and is trivial to just write an executable, compile it and it will run everywhere.
[1] https://starwars.fandom.com/wiki/Mystery_of_a_Thousand_Moons
I do think packaging can be improved. I hate almost everything about how dpkg works, it's amazing. So I'm squarely in the RPM camp because I find the tooling a lot more tolerable, but still surely further improvements can be made.
Want to see Linux on the desktop actually happen? Then allow a hassle free way for commercial software that is not "pray that WINE works good enough" aka use win32 as an ABI layer.
Of course we can stay on our high horses and demand that everything be open source and that life for closed source developers be made as difficult as possible (the Linux kernel is particularly and egregiously bad in that perspective), but then we don't get to whine about why Linux on the desktop hasn't fucking happened yet.
The whole point of my comment was to keep in mind the incentives of different sub-groups. If “Linux on the desktop” doesn’t benefit the people that make Linux work, I don’t see what the big deal is.
I remember an old Debian machine with /etc/init.d/something [start|stop|reload|restart] but I can't recall being able to automatically restart services or monitor status easily. (I didn't speak $shell well back then either)
/etc/init.d/whatever were all shell scripts, and they all had to implement all the features themselves. So `/etc/init.d/foo restart` wasn't guaranteed to work for every script, because "restart" is something that each script handled individually. And maybe this one just didn't bother implementing it.
There's no good status monitoring in sysV because it's all convenience wrappers, not a coherent system.
Thanks for the sysV explanation, it sounds worse to me.
There are two ways to design a system: so simple that it has obviously no bugs, and so complex that it has no obvious bugs.
When Vault is not available, if I’m working on a side project, for example, that’s what I always go for. Even wrote a small Go package[2] to get said credentials when your application is running inside a service with that feature.
dir, err := os.Getenv("CREDENTIALS_DIRECTORY")
cred, err := os.ReadFile(filepath.Join(dir, "name"))
I thought the go culture was that dependencies are bad, and abstractions (i.e. any function calls) are confusing and bad, so it's better to just inline stuff like this and write it fresh each time you need it.
For my projects I can just include the dependency, as I wrote it and don’t mind using it. Other people can copy it instead, since the proverb goes “a little copying is better than a little dependency”.
Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd.
As an insult, it was rather less successful than the "Micro$oft" / "Slowaris" / "HP-SUX" mockery from the 1990s - but it did manage to sow enough confusion that that it still pops up regularly today, even in contexts that are otherwise neutral or positive about it.
I’ve been using it because having some random letter capitalized seems to be the totally unsurprising for this sort of plumbing software. (And by plumbing, I mean: very useful and helpful boring stuff that deals with messy problems that I’m happy not to care about, just to be clear that I mean it positively, haha).
Normally the rule is that people mis-capitalizing the name are usually critical of the project.
It's systemd, not SystemD
this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). Maybe they will? But this same approach hasn't worked with apparmor so why should it work with systemd? Who will do the job?
If you consider apparmor maintainers provide skeleton-templates in many cases that will make the parser stop complaining. ("look I have a profile so apparmor shuts up, but don't take too close a look OK")
Then there is firejail, which some argue[2] is snake-oil considering the high level of administrative glue compared to its massive attack-surface (also it's a setuid binary).
I didn't mention SElinux since I don't know a single person who had the joy (or pain depending on perspective) of working with it. But again, seems the expectation to implement security with it is shifted to the user.
https://fedoraproject.org/wiki/Changes/SystemdSecurityHarden...
Maybe your point is that this isn't done by the vendor in practice. And I'm sure there's room for lots of improvement. However, one of the great things about how systemd units can be provided by the vendor and seamlessly tweaked by the administrator is that the vendor (i.e. packager and/or distro) can set these up easily.
There definitely are packages that ship with locked-down files. Tor and powerdns (pdns) are two off the top of my head.
→ Overall exposure level for pdns.service: 1.9 OK
→ Overall exposure level for tor.service: 7.1 MEDIUMIt would be great to see it implemented but for now at least on Debian/sid the situation is as follows:
UNIT EXPOSURE PREDICATE
ModemManager.service 6.3 MEDIUM
NetworkManager.service 7.8 EXPOSED
alsa-state.service 9.6 UNSAFE
anacron.service 9.6 UNSAFE
atop.service 9.6 UNSAFE
atopacct.service 9.6 UNSAFE
avahi-daemon.service 9.6 UNSAFE
blueman-mechanism.service 9.6 UNSAFE
bluetooth.service 6.0 MEDIUM
cron.service 9.6 UNSAFE
dbus.service 9.3 UNSAFE
dictd.service 9.6 UNSAFE
dm-event.service 9.5 UNSAFE
dnscrypt-proxy.service 8.1 EXPOSED
emergency.service 9.5 UNSAFE
exim4.service 6.9 MEDIUM
getty@tty1.service 9.6 UNSAFE
irqbalance.service 1.2 OK
lvm2-lvmpolld.service 9.5 UNSAFE
polkit.service 1.2 OK
rc-local.service 9.6 UNSAFE
rescue.service 9.5 UNSAFE
rtkit-daemon.service 7.2 MEDIUM
smartmontools.service 9.6 UNSAFE
systemd-ask-password-console.service 9.4 UNSAFE
systemd-ask-password-wall.service 9.4 UNSAFE
systemd-bsod.service 9.5 UNSAFE
systemd-hostnamed.service 1.7 OK
systemd-journald.service 4.9 OK
systemd-logind.service 2.8 OK
systemd-networkd.service 2.9 OK
systemd-timesyncd.service 2.1 OK
systemd-udevd.service 7.1 MEDIUM
tor@default.service 6.6 MEDIUM
udisks2.service 9.6 UNSAFE
upower.service 2.4 OK
user@1000.service 9.4 UNSAFE
wpa_supplicant.service 9.6 UNSAFEWhy would you say that? I would agree that the developer likely has better insight into what the software needs. But the security boundary exists at the interface of the application and the system, so I think that both application devs and system devs (i.e. distros) have something to contribute here.
And because systemd allows for composition of these settings, it doesn't have to be a one-or-the other situation--a distro can do some basic locking down (e.g. limiting SUID, DynamicUser, etc.), and then the application dev can do syscall filtering.
In any case, I agree that I'd like to see things get even more locked down. But it's worth remembering that, before systemd, there was basically no easy-to-use least-privilege stuff available beyond Unix users and filesystem permissions. The closest you had (afaik) was apparmor and selinux. In both of those cases, the distro basically had to do all the work to create the security policy.
Also, n.b., that pdns.service I noted is provided by PowerDNS themselves.
and really, these should be written by the developers, not distro maintainers
poking around on my Ubuntu machine, a few daemons have some hardening, chronyd looks pretty good
"Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. [...]"
[TIL - it's not even as old as me!] https://australianfoodtimeline.com.au/1978-launch-of-big-m/
By the way, I love that the OP used the Text Fragment (Scroll-to-Text Fragment) feature. I hope it is going to catch on more, quite helpful / useful.
Anyway, why would someone use the spelling with upper D beats me. It's not proper English.
/s