0

For hardening a server I log in every time after reboot and manually do

systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket

which works just fine. udevd is, after all, the daemon handling device change events, e.g. new USB devices and the like. Since the server is located in a datacentre several hundred miles away I am not likely to plug in any device.

My question is:

Can I completely disable systemd-udevd (and the corresponding sockets) or will the system stop booting?

So, can I do

systemctl disable systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket

?

I suppose the question is whether systemd-udevd is used during booting for finding disks, or for md software RAID, or other things like network setup.

(I am afraid I cannot try this out by disabling it really as there is no remote console and the computer may just hang, requiring expensive remote hands.)

Improve this question

2 Answers 2

Reset to default
2

It's definitely used during boot, and there is usually no point in stopping the service, as it has a rather small memory footprint (most of the memory it uses is shared with other processes), and you need it to hot-swap a harddisk, which is a typical task in a server environment.

Improve this answer
1
  • Thanks. For security hardening it is useful to stop anything running that is not needed. One attack scenario might be an attacker plugging in a USB device locally. One can always start the service when failed sector messages start coming in. Anyway, do you have some more information please where which script uses it during boot (call chain)?
    – Ned64
    Nov 15, 2020 at 17:56
1

Since your last comment you can disable local usb plugin by setting a udev rule :

sudo vi /etc/udev/rules.d/01-lockusb.rules

Append the above :

ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'for host in /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default; done'"

Reload the rules and the triggers :

sudo udevadm control --reload-rules && udevadm trigger

It's better to not disable the whole service that is used during boot, and also mainly is part of detecting network & storage devices like mutlipath disks & raids.

Improve this answer
1
  • Thanks, that's a very useful note, though not strictly an answer. I may end up writing a systemd service that stops that other service a few seconds after boot (leaving a race I realise).
    – Ned64
    Nov 15, 2020 at 18:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .