On Fri, Sep 01, 2017 at 02:25:42PM -0300, Felipe Sateler wrote: > On Tue, Aug 22, 2017 at 7:31 AM, Michael Biebl <bi...@debian.org> wrote:
Sorry for late response, I was on holiday. >>> I was running an uncommon configuration of 64-bit systemd and 32-bit >>> udev (strange omission I'm going to fix right now). It was running fine >>> until udev-234, when udev started being killed with SIGSYS. Setting >>> SystemCallArchitectures= (instead of native) in systemd-udevd.service >>> made udev working again. >>> >>> While I understand the root cause was my error, udev is such critical it >>> would be great it was more robust :-) Please consider setting >>> SystemCallArchitectures to the architecture of the udev package, >>> tightening the dependencies, or at least some sanity check during >>> installation. >> >> This can unfortunately not be expressed via package dependencies afaik >> and dropping SystemCallArchitectures= doesn't seem like a good idea. I >> suspect this was added upstream for a good reason >> I'm also not convinced if it's worth complicating the maintainers >> scripts for such an exotic case. > > Well, udev can run arbitrary programs via RUN commands, is it right to > assume that those will always be native? Agreed. Indeed, even broadening SystemCallArchitectures won't help here, as I learned when my system didn't boot because of some of the helpers being other architecture. As I see it, SystemCallArchitectures is a nice hardening measure, but nothing more than that. It doesn't help with any immediate security threats and might provide some benefit only in case of hypothetical attacks. Therefore, my preferred solution would be to drop it completely from the udev unit file. Another option is to state clearly the RUN interface works only for native applications, but then if the system is multi-arch, there is no way of knowing if some non-native executable can't be called directly or indirectly. Such requirement can have an impact on other foreign packages innocently being called from udev rules. It can be also pretty hard to debug and have an impact on booting the system. Third option is to set SystemCallArchitectures to all architectures enabled in dpkg, but it sounds quite complex and removes all potential benefits from setting it in the first place (because on multi-arch systems that will typically equal to all architectures supported by the kernel anyway). For the record, the (short) upstream discussion is here: https://github.com/systemd/systemd/pull/5283#pullrequestreview-22863442, I'm adding the reviewer to CC:. -- pozdr(); // Jarek
signature.asc
Description: PGP signature
