archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <>
To: Oleg Nesterov <>, Paul Moore <>,
	James Morris <>,
	"Serge E. Hallyn" <>,
	Stephen Smalley <>,
	Eric Paris <>,
	Andrew Morton <>,
	Mimi Zohar <>,
	Kees Cook <>,
	Casey Schaufler <>,
	David Howells <>,
	LuisChamberlain <>,
	Eric Biederman <>,
	Petr Tesarik <>,
	Christoph Hellwig <>,
	Petr Mladek <>,
	Peter Zijlstra <>,
	Thomas Gleixner <>, Tejun Heo <>
Subject: [QUESTION] Full user space process isolation?
Date: Thu, 22 Jun 2023 16:42:37 +0200	[thread overview]
Message-ID: <> (raw)

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
authenticity of the original format (that already exists and cannot

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?



             reply	other threads:[~2023-06-22 14:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 14:42 Roberto Sassu [this message]
2023-06-29  2:10 ` [QUESTION] Full user space process isolation? Serge E. Hallyn
2023-06-29  8:11   ` Roberto Sassu
2023-07-02 17:55     ` Dr. Greg
2023-07-03  7:57       ` Roberto Sassu
2023-07-03 14:43         ` Casey Schaufler
2023-07-03 15:38           ` Roberto Sassu
2023-07-04 17:26         ` Dr. Greg
2023-07-03 15:06 ` Jann Horn
2023-07-03 15:28   ` Roberto Sassu
2023-07-04 15:18     ` Petr Tesarik
2023-07-06 10:53       ` Dr. Greg
2023-07-06 11:35         ` Roberto Sassu
2023-07-06 15:04           ` Roberto Sassu
2023-07-03 18:47   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).