linux-kernel - Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <880bb4ee-89a2-b9b0-747b-0f779ceda995@digikod.net>
Date:   Thu, 10 Sep 2020 20:38:21 +0200
From:   Mickaël Salaün <mic@...ikod.net>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        Matthew Wilcox <willy@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Aleksa Sarai <cyphar@...har.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        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 20:08, Mimi Zohar wrote:
> On Thu, 2020-09-10 at 19:21 +0200, Mickaël Salaün wrote:
>> On 10/09/2020 19:04, Matthew Wilcox wrote:
>>> On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote:
>>>> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC
>>>> series with a new syscall: introspect_access(2) .  Access check are now
>>>> only possible on a file descriptor, which enable to avoid possible race
>>>> conditions in user space.
>>>
>>> But introspection is about examining _yourself_.  This isn't about
>>> doing that.  It's about doing ... something ... to a script that you're
>>> going to execute.  If the script were going to call the syscall, then
>>> it might be introspection.  Or if the interpreter were measuring itself,
>>> that would be introspection.  But neither of those would be useful things
>>> to do, because an attacker could simply avoid doing them.
>>
> 
> Michael, is the confusion here that IMA isn't measuring anything, but
> verifying the integrity of the file?   The usecase, from an IMA
> perspective, is enforcing a system wide policy requiring everything
> executed to be signed.  In this particular use case, the interpreter is
> asking the kernel if the script is signed with a permitted key.  The
> signature may be an IMA signature or an EVM portable and immutable
> signature, based on policy.

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.

> 
>> Picking a good name other than "access" (or faccessat2) is not easy. The
>> idea with introspect_access() is for the calling task to ask the kernel
>> if this task should allows to do give access to a kernel resource which
>> is already available to this task. In this sense, we think that
>> introspection makes sense because it is the choice of the task to allow
>> or deny an access.
>>
>>>
>>> So, bad name.  What might be better?  sys_security_check()?
>>> sys_measure()?  sys_verify_fd()?  I don't know.
>>>
>>
>> "security_check" looks quite broad, "measure" doesn't make sense here,
>> "verify_fd" doesn't reflect that it is an access check. Yes, not easy,
>> but if this is the only concern we are on the good track. :)
> 
> Maybe replacing the term "measure" with "integrity", but rather than
> "integrity_check", something along the lines of fgetintegrity,
> freadintegrity, fcheckintegrity.

What about entrusted_access(2)? It reflects the fact that the kernel
delegate to (trusted) user space tasks some access enforcements.

> 
> Mimi
> 
>>
>>
>> Other ideas:
>> - interpret_access (mainly, but not only, for interpreters)
>> - indirect_access
>> - may_access
>> - faccessat3
> 
>