Re: [PATCH v5 1/6] fs: Add support for an O_MAYEXEC flag on openat2(2)

[Kees Cook <keescook@chromium.org>]

On Tue, May 12, 2020 at 11:40:35PM +0200, Christian Heimes wrote:
> On 12/05/2020 23.05, Kees Cook wrote:
> > On Tue, May 05, 2020 at 05:31:51PM +0200, Mickaël Salaün wrote:
> >> When the O_MAYEXEC flag is passed, openat2(2) may be subject to
> >> additional restrictions depending on a security policy managed by the
> >> kernel through a sysctl or implemented by an LSM thanks to the
> >> inode_permission hook.  This new flag is ignored by open(2) and
> >> openat(2).
> >>
> >> The underlying idea is to be able to restrict scripts interpretation
> >> according to a policy defined by the system administrator.  For this to
> >> be possible, script interpreters must use the O_MAYEXEC flag
> >> appropriately.  To be fully effective, these interpreters also need to
> >> handle the other ways to execute code: command line parameters (e.g.,
> >> option -e for Perl), module loading (e.g., option -m for Python), stdin,
> >> file sourcing, environment variables, configuration files, etc.
> >> According to the threat model, it may be acceptable to allow some script
> >> interpreters (e.g. Bash) to interpret commands from stdin, may it be a
> >> TTY or a pipe, because it may not be enough to (directly) perform
> >> syscalls.  Further documentation can be found in a following patch.
> > 
> > You touch on this lightly in the cover letter, but it seems there are
> > plans for Python to restrict stdin parsing? Are there patches pending
> > anywhere for other interpreters? (e.g. does CLIP OS have such patches?)
> > 
> > There's always a push-back against adding features that have external
> > dependencies, and then those external dependencies can't happen without
> > the kernel first adding a feature. :) I like getting these catch-22s
> > broken, and I think the kernel is the right place to start, especially
> > since the threat model (and implementation) is already proven out in
> > CLIP OS, and now with IMA. So, while the interpreter side of this is
> > still under development, this gives them the tool they need to get it
> > done on the kernel side. So showing those pieces (as you've done) is
> > great, and I think finding a little bit more detail here would be even
> > better.
> 
> Hi,
> 
> Python core dev here.
> 
> Yes, there are plans to use feature for Python in combination with
> additional restrictions. For backwards compatibility reasons we cannot
> change the behavior of the default Python interpreter. I have plans to
> provide a restricted Python binary that prohibits piping from stdin,
> disables -c "some_code()", restricts import locations, and a couple of
> other things. O_MAYEXEC flag makes it easier to block imports from
> noexec filesystems.
> 
> My PoC [1] for a talk [2] last year is inspired by IMA appraisal and a
> previous talk by Mickaël on O_MAYEXEC.
> 
> Christian
> 
> [1] https://github.com/zooba/spython/blob/master/linux_xattr/spython.c
> [2]
> https://speakerdeck.com/tiran/europython-2019-auditing-hooks-and-security-transparency-for-cpython

Ah, fantastic; thank you! Yes, this will go a long way for helping
demonstration to other folks that there are people who will be using
this feature. :)

-- 
Kees Cook