TOMOYO and runc containers dislike one another.

["Dr. Greg" <greg@enjellic.com>]

Hi Tetsuo, I hope this note finds your day going well.

The rather lively discussion we had here, after you submitted your
patches to Linus to allow TOMOYO to be implemented as a loadable LSM,
caused us to put some resources into the upcoming V5 release of TSEM,
in order to generalize its modeling capabilities.

As a result of that work, we are now able to implement TOMOYO as a
TSEM loadable module/model plugin that implements the TOMOYO security
model, in an isolated security modeling namespace that is driven by
LSM events that only occur in that namespace.

Essentially a demonstration of workload specified LSM's.  A few rough
edges, but it is significantly beyond a proof of concept
implementation.

We don't suggest that it fixes the problem with Linux distributions
not compiling TOMOYO or AppArmor into the kernel.  It does however
demonstrate that an LSM can be created that has generic modeling
capabilities that can be implemented with loadable modules in a
namespace specific manner.

We can discuss later, why this type of infrastructure may incent
distributions to include it in their kernels.

The TSEM userspace tools have the ability to create a modeling
namespace that tracks a simple process heirarchy or a runc isolated
container heirarchy.  In the process of testing TOMOYO in a container
environment we ran into issues with TOMOYO causing the runc execution
to fail.

We reproduce this in a stock kernel with TOMOYO as a native LSM, so it
doesn't seem specific to our TSEM based implementation of TOMOYO.

We tracked the problem down to the tomoyo_realpath_nofollow() function
failing due to an error return from kern_nopath().

For smoke testing purposes, we are using the minimal default TOMOYO
policy that is used in the absence of userspace policy loading.  Given
we are the farthest thing from experts in TOMOYO this may be a
limitation of that internal policy.

We are testing with runc version 1.1.15 which is the most current
release of the 1.1.x series.

Kernel version is 6.10 something.

The path causing the issue is as follows:

/dev/fd/7

Here are the warning messages that runc spits out:

FATA[0000] nsexec[1291]: could not ensure we are a cloned binary: No
such file or directory

ERRO[0000] runc run failed: unable to start container process: waiting
for init preliminary setup: read init-p: connection reset by peer

Since we can generate this in a native TOMOYO implementation we
thought it may be worthwhile to bring this issue to your attention.
It seems odd that no one would have tripped on this given the ubiquity
of runc based container environments.

We would look forward to your thoughts.

Have a good remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project