On Mon, 2023-07-03 at 07:43 -0700, Casey Schaufler wrote:

On 7/3/2023 12:57 AM, Roberto Sassu wrote:

quoted

On Sun, 2023-07-02 at 12:55 -0500, Dr. Greg wrote:

quoted

On Thu, Jun 29, 2023 at 10:11:26AM +0200, Roberto Sassu wrote:

Good morning, I hope the weekend is going well for everyone, greetings
to Roberto and everyone copied.

quoted

On Wed, 2023-06-28 at 21:10 -0500, Serge E. Hallyn wrote:

quoted

On Thu, Jun 22, 2023 at 04:42:37PM +0200, Roberto Sassu wrote:

quoted

Hi everyone

I briefly discussed this topic at LSS NA 2023, but I wanted to have an
opinion from a broader audience.

In short:

I wanted to execute some kernel workloads in a fully isolated user
space process, started from a binary statically linked with klibc,
connected to the kernel only through a pipe.

I also wanted that, for the root user, tampering with that process is
as hard as if the same code runs in kernel space.

I would use the fully isolated process to parse and convert unsupported
data formats to a supported one, after the kernel verified the

Can you give some examples here of supported and unsupported data
formats?  ext2 is supported, but we sadly don't trust the sb parser
to read a an ext2fs coming from unknown source.  So I'm not quite
clear what problem you're trying to solve.

+ eBPF guys (as I'm talking about eBPF)

If the week goes well, we will be submitting the second version of our
TSEM LSM for review.  It incorporates a significant number of changes
and enhancements, based on both initial review comments, and
importantly, feedback from our collaborators in the critical
infrastructure community.

Just as a levelset.  TSEM provides kernel infrastructure to implement
security controls based on either deterministic or machine learning
models.  Quixote is the userspace infrastructure that enables use of
the TSEM kernel infrastructure.

Based on your description Roberto, TSEM may be of assistance in
addressesing your issues at two different levels.

First with respect to protection of an isolated workload.

TSEM is inherently workload based, given that it is based on an
architecture that implements security modeling namespaces that a
process heirarchy can be placed into.  This reduces model complexity
and provides the implementation of very specific and targeted security
controls based on the needs of a proposed workload.

The security controls are prospective rather than retrospective,
ie. TSEM will pro-actively block any security behaviors that are not
in a security model that has been defined for the workload.

For example, with respect to the concerns you had previously mentioned
about ptrace.  If the security model definition does not include a
security state coefficient for a ptrace_traceme security event, it
will be disallowed, regardless of what goes on with respect to kernel
development, modulo of course the ptrace_traceme LSM hook being
discontinued.

Hi Greg

thanks for your insights.

The policy is quite simple:


     r/w  ^                             kernel space
----------|-----------------------------------------
          v (pipe)                        user space
 +-----------------+       +-----------------------+
 | trustworthy UMD |---X---| rest of the processes |
 +-----------------+       +-----------------------+

The question was more, is the LSM infrastructure complete enough that
the X can be really enforced?

I believe that it is. SELinux and Smack, users of the LSM infrastructure,
enforce "X". They also require netlabel for IP communications, and Smack
falls short on newer protocols, but that's not the fault of LSM.

quoted

Could there be other implicit information flows that the LSM
infrastructure is not able/does not yet mediate, that could break the
policy above?

Sure. Every so often something pops into the kernel (e.g. io_uring)
without proper LSM integration. We try to discourage that, and correct
it when we find it.

Well, ok. I guess Paul's point was that it is better to write code in
the kernel to be sure, than running in this kind of risk. Maybe for
certain workloads, it is a much better choice.

For example, if the trustworthy UMD had the task to extract the crypto
material from X.509 certificates an PKCS#7 signatures, and pass it to
the kernel, breaking the isolation almost certainly would mean that the
kernel accepts more kernel modules than it should.

The question would be, if we restrict the scope of data processed by
trustworthy UMDs, would that make the solution more acceptable?

An idea for example would be: if we do appraisal with the traditional
methods (signature in the xattr, HMAC, etc.) the trustworthy UMD would
not have any impact.

Only if the IMA policy says, allow appraisal based on what the
trustworthy UMD provides, maybe it is ok? (Mimi?)

Thanks

Roberto

quoted

I guess TSEM could be for more elaborated security models, but in this
case the policy is quite straithforward. Also, your TSEM would be as
limited as mine by the LSM hooks available.

Thanks

Roberto