On Sat, 02 May 2026 at 14:21:57 -0600, Greg Dahlman wrote:
LD_PRELOAD and capabilities
These seem orthogonal, rather than being part of the same idea.
LD_PRELOAD is discretionary (cooperative) so it would only be useful if
used in a design something like this:
- at the kernel level, AF_ALG just doesn't work (fails with a
permission-related error), at least for unprivileged processes
- but in user-space, an opt-in LD_PRELOAD module intercepts the socket(),
etc. calls for AF_ALG, and emulates the behaviour of current kernels
by calling into a user-space crypto library
It can't be a security boundary, but it can be a mitigation for the
regressions that a new security boundary (or complete feature removal)
would otherwise cause, similar to the way LD_PRELOADs like aoss and
padsp mitigated the regressions for older binaries when distro kernels
disabled OSS audio.
Meanwhile capabilities are a way to let trusted, privileged processes
have access to things that unprivileged processes do not, for example
making AF_ALG available to a few system services that need it but not
available to all of user-space.
You should expect any UID (even nobody) to be able to gain the
privileges in their bounding set
The kernel can distinguish between "CAP_FOO in the init namespace" and
"CAP_FOO in any other userns" if it wants to, and some kernel features
are already gated by having a capability in the init namespace
specifically. For example CAP_SYS_ADMIN in the init namespace allows
mounting block-device-backed filesystems like ext4, but CAP_SYS_ADMIN in
a different userns only allows a few "safe" mount operations
(bind-mounts, overlayfs, FUSE).
smcv
