[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Sep 2020 14:16:23 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Matthew Wilcox <willy@...radead.org>, Al Viro <viro@...iv.linux.org.uk>
Cc: Mimi Zohar <zohar@...ux.ibm.com>, linux-kernel@...r.kernel.org,
Aleksa Sarai <cyphar@...har.com>, Alexei Starovoitov <ast@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski
<luto@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Casey Schaufler <casey@...aufler-ca.com>,
Christian Brauner <christian.brauner@...ntu.com>,
Christian Heimes <christian@...hon.org>,
Daniel Borkmann <daniel@...earbox.net>,
Deven Bowers <deven.desai@...ux.microsoft.com>,
Dmitry Vyukov <dvyukov@...gle.com>, Eric Biggers <ebiggers@...nel.org>,
Eric Chiang <ericchiang@...gle.com>, Florian Weimer <fweimer@...hat.com>,
James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>,
Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>,
Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
Matthew Garrett <mjg59@...gle.com>, Michael Kerrisk
<mtk.manpages@...il.com>, Miklos Szeredi <mszeredi@...hat.com>,
Philippe Trébuchet <philippe.trebuchet@....gouv.fr>,
Scott Shell <scottsh@...rosoft.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Shuah Khan <shuah@...nel.org>, Steve Dower <steve.dower@...hon.org>,
Steve Grubb <sgrubb@...hat.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Thibaut Sautereau <thibaut.sautereau@...p-os.org>,
Vincent Strubel <vincent.strubel@....gouv.fr>,
kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
linux-integrity@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)
On 10/09/2020 22: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.
Well, I don't know why you're so angry against LSM, but as noticed by
Matthew, the main focus of this patch series is not about LSM (no hook,
no security/* code, only file permission and mount option checks,
nothing fancy). Moreover, the syscall you're proposing doesn't make
sense, but I guess it's yet another sarcastic reply. Please, cool down.
We asked for constructive comments and already followed your previous
requests (even if we didn't get answers for some questions), but
seriously, this one is nonsense.
>
> 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/bad.pl | perl -
>
Funny. I know there is a lot of text and links but please read the
commit messages before further comments.
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.
