[systemd-devel] Udev hardening
Adi Ml
maladi1747 at gmail.com
Mon Dec 14 16:18:24 UTC 2020
I guess that udev can block devices from userspace only, so from there.
Of course, you are right-whitelist is better.
As for usbguard, I thought about using seccomp and filterring system calls
in my udev service based on their code - I have seen that they list a group
of system calls and restrict the usage to them only.
Anyway, I understand, the system calls that udev use are mentioned in its
configuration files and are also the system calls used in scripts ran when
a rule is been trigerred (the rules writer have to specify the scripts in
the rules file of course) .
בתאריך יום ב׳, 14 בדצמ׳ 2020, 17:41, מאת Greg KH <
gregkh at linuxfoundation.org>:
> On Mon, Dec 14, 2020 at 05:31:17PM +0200, Adi Ml wrote:
> > I am using udev in order to create a kiosk mode. I want to block devices
> > which fit a certain vid pid.
>
> Block devices from where? The kernel or userspace?
>
> udev runs _after_ the kernel has seen the device and bound to it.
>
> And usb vid/pids can be made to be whatever they want to be, be careful
> about triggering off of them to prevent specific things from happening,
> that way is tough. It's easier to whitelist valid devices that you know
> are correct, and then only allow specific actions to happen on them.
>
> You might want to look into using https://usbguard.github.io/ for how to
> do this "properly".
>
> > I want to filter system calls anyway because I
> > dont know which devices are entered and I want to avoid devices which
> will
> > do unusual things like rubber ducky.
>
> devices do not make system calls directly, and if you plug a rubber
> ducky in that acts like a keyboard, that is not going to create things
> in udev's process context.
>
> > What do you mean by filtering system calls in scripts- is it needed
> when
> > the user can influence actions commited in the script ?
>
> Look at the programs / scripts that udev calls out to in the udev
> configuration files for examples of these. A user does not directly
> influence them, except if they are allowed to create/remove hardware.
>
> Hope this helps,
>
> greg k-h
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20201214/ef021920/attachment-0001.htm>
More information about the systemd-devel
mailing list