linux-hardening - Re: [QUESTION] Full user space process isolation?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 03 Jul 2023 09:57:53 +0200
From:   Roberto Sassu <roberto.sassu@...weicloud.com>
To:     "Dr. Greg" <greg@...ellic.com>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Paul Moore <paul@...l-moore.com>,
        James Morris <jmorris@...ei.org>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Kees Cook <keescook@...omium.org>,
        Casey Schaufler <casey@...aufler-ca.com>,
        David Howells <dhowells@...hat.com>,
        LuisChamberlain <mcgrof@...nel.org>,
        Eric Biederman <ebiederm@...ssion.com>,
        Petr Tesarik <petrtesarik@...weicloud.com>,
        Christoph Hellwig <hch@...radead.org>,
        Petr Mladek <pmladek@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tejun Heo <tj@...nel.org>, linux-mm@...ck.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
        linux-integrity@...r.kernel.org, linux-hardening@...r.kernel.org,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [QUESTION] Full user space process isolation?

On Sun, 2023-07-02 at 12:55 -0500, Dr. Greg wrote:
> 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.
> 
> > On Wed, 2023-06-28 at 21:10 -0500, Serge E. Hallyn wrote:
> > > On Thu, Jun 22, 2023 at 04:42:37PM +0200, Roberto Sassu wrote:
> > > > 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?

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

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