MemoryDenyWriteExecute=yes should not affect executables run due to notifications by systemd-udevd

[mikebcom]

Submission type

• Bug report
• Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

v232

NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!

Used distribution

Debian 9 (stretch)

In case of bug report: Expected behaviour you didn't see

Some executables outside of systemd are no longer run, even though they should be called according to existing rules. This is complicated by the fact that the error shown in the journal is obscure (even with systemd debugging enabled), e.g. systemd-udevd[1510]: Process 'ifmgrctl' failed with exit code 127. This is even though the same example executable 'ifmgrctl' here is run just fine with systemd v215 used for Debian 8.

It turns out that the problem is due to MemoryDenyWriteExecute=yes being set in the default unit file for systemd-udevd.service, with the underlying as yet unresolved issue being due to the way that Golang created this 'ifmgrctl' executable most likely causing a segment mapping issue.

While it would be useful to have a warning message to detect infraction of the W^X check, and while it is easy enough to override MemoryDenyWriteExecute once the problem has been root-caused, for reasons of backwards compatibility, systemd-udevd.service should not inhibit calls to executables outside of systemd.

In case of bug report: Unexpected behaviour you saw

…

In case of bug report: Steps to reproduce the problem

Event notification to Golang-built executable due to systemd rules.

[evverx]

@mikebcom , what is the output of the

readelf --all /path/to/your/binary | grep -i pie

?

Also, try this

sudo systemd-run -t --property MemoryDenyWriteExecute=yes /path/to/your/binary

Do you see something like

error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted

?

[evverx]

Hm, unrelated but interesting https://fedoraproject.org/wiki/Changes/golang-buildmode-pie

Change default build mode of golang in Fedora packaging macros to buildmode=pie, which results in packages using them to produce Position Independent Executables

I think we should remove MemoryDenyWriteExecute

Actually, we don't control RUN+= and so on. I think we shouldn't try to restrict those binaries (see also #4293)

[poettering]

hmpf, go code in an udev rule? that sounds like a poor choice of tooling to me...

Not sure how I feel about this one. Yes, udev is a plug-in framework and we don't control the plugins, but I am tempted to say that tighter controls on udev plugins is a good thing, and we should still do it, though document this in NEWS.

[evverx]

hmpf, go code in an udev rule? that sounds like a poor choice of tooling to me...

Well, that's not about go really

This comes from the dynamic loader

error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted

[mikebcom]

Many thanks for your prompt replies. While I agree that the W^X check should be an option that is to be encouraged, having it on by default (in systemd-udevd.service, everywhere else is fine) is painful when going through a distro upgrade (Deb 8 to Deb 9 RC2) and being hit by unexpected regressions, especially given the obscure error message reported (when the child process cannot be spawned). We understand that the underlying segment mapping issue needs to somehow be fixed in Go, but the request here is for systemd to maintain backwards compatibility to allow other components to continue functioning as before.

@evverx, you are right, the problem is with the dynamic loader.

sudo systemd-run -t --property MemoryDenyWriteExecute=yes /usr/bin/ifmgrctl
/usr/bin/ifmgrctl: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted

Thanks for this useful debugging tip! We had found the error by running 'strace -f -p ', which then led on to realising that this is because of the new W^X check.

Details of the example executable:

readelf --all /usr/bin/ifmgrctl | grep -i pie
0x000000006ffffffb (FLAGS_1) Flags: PIE

file /usr/bin/ifmgrctl
/usr/bin/ifmgrctl: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=729868d63d740fbe6e9c6f2efe05eb36f70d5567, not stripped

Also using 'ldd' to get the shared libs for the binary and running 'execstack -q' (from pax-utils) on these, none are showing as requiring executable stack, which is correct.

• Mike

[evverx]

having it on by default (in systemd-udevd.service, everywhere else is fine) is painful when going through a distro upgrade (Deb 8 to Deb 9 RC2) and being hit by unexpected regressions

@mikebcom , there is a short discussion there #5283 (comment)

Summary:

That said, this should be documented in NEWS and downstream distros should be welcome to undo this change if they think it's necessary. It's pretty easy to do that after all.

As far as I understand the only way is to ask distro-maintainers

[mikebcom]

Thanks for the clarification, Regards - Mike

[poettering]

Well, that's not about go really

This comes from the dynamic loader

well, but go appears to create these binaries in this way. I think the best fix would be to fix the toolchain here, rather than turn off the security on this one

[poettering]

I filed PR #5414, retroactively adding a comment about this to the NEWS section of 232, suggesting people turn this off locally if they run into problems with this due to programs compiled with toolchains that are incompatible with W^X.