[systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

[Jeremy Linton]

Hi,

There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC changes. Glibc enables BTI only on segments which are marked 
as being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That 
call is caught by the seccomp filter, resulting in service failures.

So, at the moment one has to pick either denying PROT_EXEC changes, or 
BTI. This is obviously not desirable.

Various changes have been suggested, replacing the mprotect with mmap 
calls having PROT_BTI set on the original mapping, re-mmapping the 
segments, implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is 
already set, and various modification to seccomp to allow particular 
mprotect cases to bypass the filters. In each case there seems to be an 
undesirable attribute to the solution.

So, whats the best solution?


Thanks everyone,


PS: There is a fedora bug about this here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1888842 which is also 
tracking a systemd issue of the same subject.