Adding PaX markings to select Wolfi packages

[kaniini]

Hi!

For the past few months, I have been working on a piece of software called Edera Protect built on some open source components such as Edera's krata and openpax packages. Edera Protect uses these components to provide a Kubernetes-compatible execution environment designed around privilege domain isolation.

In order to harden the jail further, Edera has also written a from-scratch implementation of some key PaX features, which mitigate the risks of common memory safety vulnerabilities. These features run in a default-deny configuration, meaning that the capability to execute arbitrary memory not described by an ELF .text segment must be explicitly granted to a binary through a so-called PaX marking. When working correctly, this provides resistance to most memory safety violations, which is useful because it provides protection against unknown vulnerabilities.

However, because these protections are default-deny, they will prevent any code which depends on JIT execution from running by default. PaX markings allow for binaries to declare that they depend on JIT execution, or that they want ASLR disabled, etc, providing compatibility with these edge cases.

Edera plans on allowing the default-deny policy to be configurable via a PaX cgroup, however, this will require administrator intervention, and provides suboptimal hardening over just exempting a few binaries. Edera also plans to provide a set of rule definitions to mark binaries at image unpack time, but this too, is not fool-proof.

I recently landed our paxmark utility in #24173 to help with setting PaX markings. But before I go and add the ~15-20 PaX markings needed, I wanted to ask a few questions:

• Should Melange be augmented to detect and error on TEXTREL ELF entries? Any case where a TEXTREL happens, ASLR is entirely defeated, so this is bad for security in general.
• Should Melange automatically add PaX markings based on binary analysis (the work in chainguard-dev/bincapz looks incredibly useful here)? The heuristic would be to look for any mmap(2) or mprotect(2) calls which use PROT_EXEC to mark pages as executable.
• Would a Melange pipeline wrapping paxmark be useful?
• Should we just manually manage PaX markings in Wolfi for now?

The sorts of things that we would be looking to add markings for are things like Java, .NET, LLVM, etc. Anything that JITs code into anonymous memory mappings, basically.

[xnox]

I guess there is large overlap between binaries that need to be marked for this thing and also those that do not support CET (ibt, shadow stack). Beyond PAX I wonder if markings like these can help with auto generating selinux execmem policies too.

I hope gcc itself / libgccjit is considered as not interesting and not needing these markings.

Automated detection and marking sounds dangerous.

I am trying to land hardening upgrades right now, so wouldn't want to error on TEXTREL just now.

Manual pipeline should be fine, inline in wolfi-dev/os pipelines subdir. But hopefully with something niche at first.

The fallout concern is if something barfs at seeing these markings. And also it will be probably of little value overall as majority deployments do not have relevant kernel patches to leverage all that.

(But I am also yet to see CET enabled as enforcing anywhere - as Nvidia basically prevents it so far).

[kaniini]

Yeah PaX markings can help for generating SELinux policies as well.

libgccjit itself wouldn't need the markings, as they use dlopen(3) to pull in the JIT-generated code.

Ok, we will just manage these manually. The markings are in the form of an xattr, so kernels that lack a PaX implementation will just ignore it. At the moment, the only kernel variants with a PaX implementation are grsecurity or OpenPaX, so the impact should be zero.

[xnox]

Indeed, most things ignore xattr - so that's easy. I am not well versed in OCI format - but I hope that all of xattrs survive that to actually reach your product.