Message-ID: <55b4f6291e8d83d420c7d08f4233b3d304ce683d.camel@linux.ibm.com>
Date: Mon, 08 Jul 2024 16:35:38 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Mickaël Salaün <mic@...ikod.net>,
        Al Viro
 <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Kees
 Cook <keescook@...omium.org>,
        Linus Torvalds
 <torvalds@...ux-foundation.org>,
        Paul Moore <paul@...l-moore.com>, "Theodore Ts'o" <tytso@....edu>
Cc: Alejandro Colomar <alx.manpages@...il.com>,
        Aleksa Sarai
 <cyphar@...har.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy
 Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Casey
 Schaufler <casey@...aufler-ca.com>,
        Christian Heimes
 <christian@...hon.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Eric Biggers
 <ebiggers@...nel.org>,
        Eric Chiang <ericchiang@...gle.com>,
        Fan Wu
 <wufan@...ux.microsoft.com>,
        Florian Weimer <fweimer@...hat.com>,
        Geert
 Uytterhoeven <geert@...ux-m68k.org>,
        James Morris
 <jamorris@...ux.microsoft.com>, Jan Kara <jack@...e.cz>,
        Jann Horn
 <jannh@...gle.com>, Jeff Xu <jeffxu@...gle.com>,
        Jonathan Corbet
 <corbet@....net>,
        Jordan R Abrahams <ajordanr@...gle.com>,
        Lakshmi
 Ramasubramanian <nramas@...ux.microsoft.com>,
        Luca Boccassi
 <bluca@...ian.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        "Madhavan T .
 Venkataraman" <madvenka@...ux.microsoft.com>,
        Matt Bobrowski
 <mattbobrowski@...gle.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Matthew
 Wilcox <willy@...radead.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        Nicolas
 Bouchinet <nicolas.bouchinet@....gouv.fr>,
        Scott Shell
 <scottsh@...rosoft.com>, Shuah Khan <shuah@...nel.org>,
        Stephen Rothwell
 <sfr@...b.auug.org.au>,
        Steve Dower <steve.dower@...hon.org>, Steve Grubb
 <sgrubb@...hat.com>,
        Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
        Vincent Strubel <vincent.strubel@....gouv.fr>,
        Xiaoming Ni
 <nixiaoming@...wei.com>,
        Yin Fengwei <fengwei.yin@...el.com>,
        kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)

Hi Mickaël,

On Thu, 2024-07-04 at 21:01 +0200, Mickaël Salaün wrote:
> Hi,
> 
> The ultimate goal of this patch series is to be able to ensure that
> direct file execution (e.g. ./script.sh) and indirect file execution
> (e.g. sh script.sh) lead to the same result, especially from a security
> point of view.
> 
> Overview
> --------
> 
> This patch series is a new approach of the initial O_MAYEXEC feature,
> and a revamp of the previous patch series.  Taking into account the last
> reviews [1], we now stick to the kernel semantic for file executability.
> One major change is the clear split between access check and policy
> management.
> 
> The first patch brings the AT_CHECK flag to execveat(2).  The goal is to
> enable user space to check if a file could be executed (by the kernel).
> Unlike stat(2) that only checks file permissions, execveat2(2) +
> AT_CHECK take into account the full context, including mount points
> (noexec), caller's limits, and all potential LSM extra checks (e.g.
> argv, envp, credentials).
> 
> The second patch brings two new securebits used to set or get a security
> policy for a set of processes.  For this to be meaningful, all
> executable code needs to be trusted.  In practice, this means that
> (malicious) users can be restricted to only run scripts provided (and
> trusted) by the system.
> 
> [1] https://lore.kernel.org/r/CAHk-=wjPGNLyzeBMWdQu+kUdQLHQugznwY7CvWjmvNW47D5sog@mail.gmail.com
> 
> Script execution
> ----------------
> 
> One important thing to keep in mind is that the goal of this patch
> series is to get the same security restrictions with these commands:
> * ./script.py
> * python script.py
> * python < script.py
> * python -m script.pyT

This is really needed, but is it the "only" purpose of this patch set or can it
be used to also monitor files the script opens (for read) with the intention of
executing.

> 
> However, on secure systems, we should be able to forbid these commands
> because there is no way to reliably identify the origin of the script:
> * xargs -a script.py -d '\r' -- python -c
> * cat script.py | python
> * python
> 
> Background
> ----------
> 
> Compared to the previous patch series, there is no more dedicated
> syscall nor sysctl configuration.  This new patch series only add new
> flags: one for execveat(2) and four for prctl(2).
> 
> This kind of script interpreter restriction may already be used in
> hardened systems, which may need to fork interpreters and install
> different versions of the binaries.  This mechanism should enable to
> avoid the use of duplicate binaries (and potential forked source code)
> for secure interpreters (e.g. secure Python [2]) by making it possible
> to dynamically enforce restrictions or not.
> 
> The ability to control script execution is also required to close a
> major IMA measurement/appraisal interpreter integrity [3].

Definitely.  But it isn't limited to controlling script execution, but also
measuring the script.  Will it be possible to measure and appraise the indirect
script calls with this patch set?

Mimi

> This new execveat + AT_CHECK should not be confused with the O_EXEC flag
> (for open) which is intended for execute-only, which obviously doesn't
> work for scripts.
> 
> I gave a talk about controlling script execution where I explain the
> previous approaches [4].  The design of the WIP RFC I talked about
> changed quite a bit since then.
> 
> [2] https://github.com/zooba/spython
> [3] https://lore.kernel.org/lkml/20211014130125.6991-1-zohar@linux.ibm.com/
> [4] https://lssna2023.sched.com/event/1K7bO
> 

Powered by blists - more mailing lists