Message-ID: <14599d8216f1b7520ff5f6cfb27377fa79709f13.camel@huaweicloud.com>
Date:   Thu, 29 Jun 2023 10:11:26 +0200
From:   Roberto Sassu <roberto.sassu@...weicloud.com>
To:     "Serge E. Hallyn" <serge@...lyn.com>
Cc:     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 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)

File digests are distributed in a multitude of formats: RPM packages
provide them in RPMTAG_FILEDIGESTS, DEB packages in md5sum (now
sha256sum), containers I guess they have a manifest.

File digests would be used as reference values for IMA Appraisal and
IMA Measurement (to have a predictable PCR).

If we manage to write a tiny parser for RPM headers (I'm talking about
something like 200 lines) to extract the file digests, basically we
have all the information we need to do IMA Appraisal on current, past
and future RPM-based Linux distributions.

If we do the same for DEB (ok, well, when they switch from MD5 to
SHA256), we can support all DEB-based Linux distributions too.

On the opposite side, yes, we can change the RPM format, ask the
distributions to sign per-file. If it was that easy, we would not be
(still) waiting for the first distribution (Fedora 38) to support file
signatures since 2016, when the feature was proposed (sorry if it looks
like diminishing what Mimi and IBM proposed, I'm trying to convey the
idea of how difficult is to realize that architecture).

What about other formats? How long it could take for them to be adapted
to store file signatures?

Immediate support for IMA Appraisal is as far as looping into the RPM
header sections to obtain the data offset of RPMTAG_FILEDIGESTS and
converting the digests at that offset from hex to bin (we need also to
verify the PGP signature of the RPM header, but I would leave it for
later).

You probably also see how close we are to accomplish the goal. I'm open
to suggestions: if this idea of an isolated process doing the parsing
is not suitable, I could implement it in a different way.

So far I proposed:

- In-kernel parser (dangerous, not scalable)
https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/
- eBPF (no program signatures, not compliant with the LSM conventions,
  unsolved security issues)
https://github.com/robertosassu/diglim-ebpf/commit/693745cb388bca7354233cadae1fe2d23d47ff9d
- Isolated user space process (not enough isolation guarantees)
https://lore.kernel.org/linux-kernel//20230317145240.363908-1-roberto.sassu@huaweicloud.com/
https://lore.kernel.org/linux-kernel//20230425173557.724688-1-roberto.sassu@huaweicloud.com/

Thanks

Roberto

> > authenticity of the original format (that already exists and cannot
> > change).
> > 
> > Preventing tampering of the process ensures that the conversion goes as
> > expected. Also, the integrity of the binary needs to be verified.
> > 
> > 
> > List of wished data formats:
> > 
> > PGP: verify the authenticity of RPM/DEB/... headers
> > RPM/DEB/... headers: extract reference file checksums for
> >                     (kernel-based) file integrity check (e.g. with IMA)
> > 
> > 
> > Alternative #1:
> > 
> > Write the parsers to run in kernel space. That was rejected due to
> > security and scalability concerns. If that changed, please let me know.
> > 
> > 
> > Alternative #2:
> > 
> > Linux distributions could provide what the kernel supports. However,
> > from personal experience, the effort seems orders of magnitude higher
> > than just writing a tiny component to support the original format. And
> > there is no guarantee that all Linux distributions will do it.
> > 
> > 
> > Full process isolation could be achieved in this way:
> > 
> > process -> outside: set seccomp strict profile at process creation
> >                     so that the process can only read/write/close the
> >                     pipe and exit, no other system calls are allowed
> > 
> > outside -> process: deny ptrace/kill with the process as target
> > 
> > Anything else?
> > 
> > 
> > The only risk I see is that a new feature allowing to interact with
> > another process is added to the kernel, without the ptrace permission
> > being asked.
> > 
> > With the restrictions above, can we say that the code inside the
> > process is as safe (against tampering) to execute as if it runs in
> > kernel space?
> > 
> > Thanks
> > 
> > Roberto

Powered by blists - more mailing lists