Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Sep 2020 17:15:10 +0300
From: Igor Zhbanov <>
To: Matthew Wilcox <>, Al Viro <>
CC: Mickaël Salaün <>, Mimi Zohar
	<>, <>, Aleksa Sarai
	<>, Alexei Starovoitov <>, Andrew Morton
	<>, Andy Lutomirski <>, Arnd Bergmann
	<>, Casey Schaufler <>, Christian Brauner
	<>, Christian Heimes <>,
	Daniel Borkmann <>, Deven Bowers
	<>, Dmitry Vyukov <>, Eric
 Biggers <>, Eric Chiang <>, Florian
 Weimer <>, James Morris <>, Jan Kara
	<>, Jann Horn <>, Jonathan Corbet
	<>, Kees Cook <>, Lakshmi Ramasubramanian
	<>, Matthew Garrett <>, Michael
 Kerrisk <>, Miklos Szeredi <>,
	Philippe Trébuchet <>, Scott
 Shell <>, Sean Christopherson
	<>, Shuah Khan <>, Steve Dower
	<>, Steve Grubb <>, Tetsuo Handa
	<>, Thibaut Sautereau
	<>, Vincent Strubel
	<>, <>,
	<>, <>,
	<>, <>
Subject: Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

On 10.09.2020 23:05, Matthew Wilcox wrote:
> On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote:
>> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote:
>>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
>>>> There is also the use case of noexec mounts and file permissions. From
>>>> user space point of view, it doesn't matter which kernel component is in
>>>> charge of defining the policy. The syscall should then not be tied with
>>>> a verification/integrity/signature/appraisal vocabulary, but simply an
>>>> access control one.
>>> permission()?
>> int lsm(int fd, const char *how, char *error, int size);
>> Seriously, this is "ask LSM to apply special policy to file"; let's
>> _not_ mess with flags, etc. for that; give it decent bandwidth
>> and since it's completely opaque for the rest of the kernel,
>> just a pass a string to be parsed by LSM as it sees fit.
> Hang on, it does have some things which aren't BD^W^WLSM.  It lets
> the interpreter honour the mount -o noexec option.  I presume it's
> not easily defeated by
> 	cat /home/salaun/bin/ | perl -


It could be bypassed this way. There are several ways of executing some

1) / (Already handled by IMA)
2) bash / (Not handled. Works even with "-o noexec" mount)
3) bash < / (Not handled. Works even with "-o noexec" mount)
4) cat / | bash (Not handled. Works even with "-o noexec" mount)

AFAIK, the proposed syscall solves #2 and may be #3. As for #4 in security
critical environments there should be system-wide options to disable
interpreting scripts from the standard input. I suppose, executing commands
from the stdin is a rare case, and could be avoided entirely in security
critical environments. And yes, some help from the interpreters is needed
for that.

As for the usage of the system call, I have a proposal to extend its usage
to validate systemd unit files. Because a unit file could specify what UID
to use for a service, also it contains ExecStartPre which is actually a script
and is running as root (for the system session services).

For the syscall name it could be:
- trusted_file()
- trusted_file_content()
- valid_file()
- file_integrity()
because what we are checking here is the file content integrity (IMA) and
may be file permissions/attrs integrity (EVM).

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.