From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0492EB64D7 for ; Thu, 29 Jun 2023 02:10:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 503298D0002; Wed, 28 Jun 2023 22:10:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B3998D0001; Wed, 28 Jun 2023 22:10:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37C278D0002; Wed, 28 Jun 2023 22:10:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 24CEA8D0001 for ; Wed, 28 Jun 2023 22:10:05 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EA976160873 for ; Thu, 29 Jun 2023 02:10:04 +0000 (UTC) X-FDA: 80954155128.13.99BAE84 Received: from mail.hallyn.com (mail.hallyn.com [178.63.66.53]) by imf20.hostedemail.com (Postfix) with ESMTP id 41F901C000B for ; Thu, 29 Jun 2023 02:10:01 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of serge@mail.hallyn.com designates 178.63.66.53 as permitted sender) smtp.mailfrom=serge@mail.hallyn.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688004602; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LrrICl5djO/9pFdl8MaYpSYU2Au6c+aXR9Pj/2pbB+M=; b=j+Bc5vtIEhG5LmI1i0tCyamRyLrmOKLimXGdNYt3htwr7dbMWZ3tRqDpVNryRxd5qaXetF +HOxQ+GXd7t5RTveEY5plJAfvPFLJ+xkqn0Pr6im5Y7GXdMZ6N4DyT8Hr/1/9+wNyMfPpX 5SFD9q65X96Dxk7ZGeD/Xq6F539fULg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688004602; a=rsa-sha256; cv=none; b=dQbAAB2YJwH1AvxYpPyJ/1P0OL+v0bpvLEFg8qAjYTf3TYc/5leSLLuDUGd4TRjU/q++7U mgFicTOmCNPlAbfN11s0eVzsp0gmVVLimvBZM6sjtEE580IaSYrb2nRvttjwFrLq5FD7wl qQPaVSB09C6FMi2F9/3cH6gtyC5kEj0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of serge@mail.hallyn.com designates 178.63.66.53 as permitted sender) smtp.mailfrom=serge@mail.hallyn.com; dmarc=none Received: by mail.hallyn.com (Postfix, from userid 1001) id 479A1579; Wed, 28 Jun 2023 21:10:00 -0500 (CDT) Date: Wed, 28 Jun 2023 21:10:00 -0500 From: "Serge E. Hallyn" To: Roberto Sassu Cc: 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 , linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [QUESTION] Full user space process isolation? Message-ID: <20230629021000.GA368825@mail.hallyn.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 5tnkouay1bkb6qjqwbp4jr3oy6s5fxto X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 41F901C000B X-Rspam-User: X-HE-Tag: 1688004601-780973 X-HE-Meta: U2FsdGVkX1+bqZl0jf9FPVyfiu6mfWVbwdz7qa3IUvkf7Mm2lQ+BMO/6vNmAKlakYUNsV6T68NQKoKgqTXCh0ch36kRejewzQo9YiuExhFthGMscrX0KkTywru+Wol+e2NC5b7ee5aQiUlabuO7Zhe3LgZNJqcsddnBIxZEes9eggLiPLcIYd9lWvUT2cdLcXqaYwBWtqyh2mc18fD7bPChwz/xkWju2rTD/+eAZZ37WGv33qtsd29OpF7+sUfedJ/C8hyQ14uIZhJyCq3XoDmcHkOMwMqbpfZJoqjvikYMQcOovpA0nG2gPS1f4n1cXiwm0UHi1OEz3sy3Gpcm/E2Can4BDFp1N72w1dKHajsdlxfd/MgKRP67u+p0GjjaqVHv42q/30Sp+Zma6GVouSO/9KiyQ/6p/yTULXY7Xa59feNznhmIPnR2aGPPm51BNwo0urxWfcLSjqggX6al+cH6ejYgesmlsXTGHWyoxZRTItt5cOcfGJSXfD7mX17tS1+NFI/8cQ/bYkx29IKUVcfteOiAtHLC+H4jBvUJ89NVbW/0M4tqxAuOtk9SLCwemUW4tC5Z6sbTWiByCWbMWexBgzvkutB9cUhK5D6qTkJfdp0ff4O+BQdDy6leFSGhTHKRNVH22B3hlZFuba+Wx2P+KWdiv1rvHafecRhYZDo9qfLvXghFBxx7MRL8OT1/eLqa86O8M4eIsu8bYaA/NBWhsIQ0yaAOGhcCRqGJE5E227VYwNjGWnaZQ/wtbxkdO4rtRGZv4sFoaHTUVhaYm6FMzMhQGXGOkx/MBL+rRsSku8Cxt93EuLRum3c+Dl7p9n+CT5E3V0SXgmsNtGxp32ajUeyvN1j3BsCCsyqfQQYDmA7cvbfxy39HQ1m4NgKN+ss+r1/2GlGQUprVNrrLh1mkhZdEQdUjDedOOmpPuC+oi/d0/BhSQ51mBOW1QZXmfQBC+pTGNqsF2cSnIPlw 0JL9oU1K m1o2wo9gZUAzsTm5zwVpRYaT3CBubxrpqcj6QeL8v5IkTOIxxXBx1GutU60gQZPYUpLMcUbVXrNX3WyvEBXBRE/SALARggkhtpP66Z4qDk/rcCsDuZlGEX1+fwQi7jJ6yOly8UUzdYVVnjy45f0ZSAwiU+W/k3K4aHJzCG5Rj6E/k45rEpmAjjPzLrC5xTdbt+CcHGCM3en1DffG/U2/V2hoVjA6xOYLkTmxQ2Gegxf0I+XnP5tEsLzOrXz5tDu1bktOJhKXhiePoQeWuafmZFmyWuyre4dP3wC2icqkL4eyZSs/KeIQNay634A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. > 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