On Tue, Sep 8, 2020 at 8:50 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Tue, Sep 8, 2020 at 8:43 AM Mickaël Salaün <mic@xxxxxxxxxxx> 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. Also Smack doesn't appear to implement file_permission at all, so it would skip Smack checking.
