This is awesome. I ran systemctl --user on my system, and there’s so much noise there (from units that handle mounts and so much other stuff you wouldn’t consider a ‘service’) that even if something malicious existed it would be hard to immediately spot. And it would be impossible to spot if it used a name that made it look like one of the noise.
It gets even better, I haven’t ever published it because I actually use it on red teams but there are ways to use the dependency checks on services to essentially create very difficult to kill back door by making multiple systemd user backdoors that depend on each other and also create and enable more of themselves hydra style. You can also have them running and clean themselves up so that there are no on-disk service files for even more nastiness. Lots of fun to be had everywhere!
The security reporting process is a bit nebulous and hard to approach, so I think it’s valuable to explain why it’s not actually a reportable issue. The ability to create these unit files is intended functionality using allowed user rights, I’m not actually breaking any security here. The reason why this seems like an “issue” is the difference between a vulnerability and a persistence technique, I’m not actually breaking any security assumptions with this, so there would be no reason for there to be something like say… a CVE, which most people are familiar with.
I use systemd unit files for a custom break reminder program. It works quite well (better than existing software for me), though sometimes it fails to start the screensaver after waking up; haven’t seen that happen recently though.
However, the battery information can be also obtained through D-Bus where it should be possible to listen to a signal and get notification each time the value changes – instead of periodically checking the current state.
Thanks! and you’re the second person to mention this – for battery specifically, yeah this makes a lot more sense, I was just wanting to mention the timer stuff – I’ll make an edit at the end, maybe plugging a friends solution
I love systemd user services. I recently started using them for emacs. Now that I’ve realized how easy they are I’ll probably make a lot more use of them.
My favourite use case for systemd user services is sneaky backdoors that disappear when users log in: https://hosakacorp.net/p/systemd-user.html
This is awesome. I ran
systemctl --useron my system, and there’s so much noise there (from units that handle mounts and so much other stuff you wouldn’t consider a ‘service’) that even if something malicious existed it would be hard to immediately spot. And it would be impossible to spot if it used a name that made it look like one of the noise.It’s better to run
systemctl --user list-dependenciesas it would give you a better overview of the services you (probably) care about.oh, thanks, that’s much better. Though, does this show the sneaky backdoor services that OP mentioned?
Wow. That’s fantastic!
This is great, thanks for sharing. Def an argument here for a systemd –user whitelist or a reminder to check the noise from time to time
It gets even better, I haven’t ever published it because I actually use it on red teams but there are ways to use the dependency checks on services to essentially create very difficult to kill back door by making multiple systemd user backdoors that depend on each other and also create and enable more of themselves hydra style. You can also have them running and clean themselves up so that there are no on-disk service files for even more nastiness. Lots of fun to be had everywhere!
Seems like this should be reported if it hasn’t been already…
The security reporting process is a bit nebulous and hard to approach, so I think it’s valuable to explain why it’s not actually a reportable issue. The ability to create these unit files is intended functionality using allowed user rights, I’m not actually breaking any security here. The reason why this seems like an “issue” is the difference between a vulnerability and a persistence technique, I’m not actually breaking any security assumptions with this, so there would be no reason for there to be something like say… a CVE, which most people are familiar with.
There are places where this is documented as a potential security impacting place that requires additional monitoring for indicators of compromise, such as in the MITRE ATT&CK framework. In fact this technique and the Metasploit module I wrote for it are referenced in ATT&CK in the 4th reference.
Nice. I’ve been using systemd user services for making restic backups. Works really well so far.
Neat. Restic is great. TIL systemd user space. :)
I use systemd unit files for a custom break reminder program. It works quite well (better than existing software for me), though sometimes it fails to start the screensaver after waking up; haven’t seen that happen recently though.
I didn’t even realize ExecStart could take formatting (your
%h), nice. Thanks for sharingNice example of user-level systemd service.
However, the battery information can be also obtained through D-Bus where it should be possible to listen to a signal and get notification each time the value changes – instead of periodically checking the current state.
Thanks! and you’re the second person to mention this – for battery specifically, yeah this makes a lot more sense, I was just wanting to mention the timer stuff – I’ll make an edit at the end, maybe plugging a friends solution
I love systemd user services. I recently started using them for emacs. Now that I’ve realized how easy they are I’ll probably make a lot more use of them.