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 < gre...@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 >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
