lkml.org 
[lkml]   [2020]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH v8 1/3] fs: Introduce AT_INTERPRETED flag for faccessat2(2)
    On Tue, Sep 8, 2020 at 8:43 AM Mickaël Salaün <mic@digikod.net> wrote:
    >
    >
    > On 08/09/2020 14:28, Mimi Zohar wrote:
    > > Hi Mickael,
    > >
    > > On Tue, 2020-09-08 at 09:59 +0200, Mickaël Salaün wrote:
    > >> + mode |= MAY_INTERPRETED_EXEC;
    > >> + /*
    > >> + * For compatibility reasons, if the system-wide policy
    > >> + * doesn't enforce file permission checks, then
    > >> + * replaces the execute permission request with a read
    > >> + * permission request.
    > >> + */
    > >> + mode &= ~MAY_EXEC;
    > >> + /* To be executed *by* user space, files must be readable. */
    > >> + mode |= MAY_READ;
    > >
    > > After this change, I'm wondering if it makes sense to add a call to
    > > security_file_permission(). IMA doesn't currently define it, but
    > > could.
    >
    > Yes, that's the idea. We could replace the following inode_permission()
    > with file_permission(). I'm not sure how this will impact other LSMs though.

    They are not equivalent at least as far as SELinux is concerned.
    security_file_permission() was only to be used to revalidate
    read/write permissions previously checked at file open to support
    policy changes and file or process label changes. We'd have to modify
    the SELinux hook if we wanted to have it check execute access even if
    nothing has changed since open time.

    \
     
     \ /
      Last update: 2020-09-08 19:41    [W:3.875 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site