On Tue, May 05, 2020 at 05:31:52PM +0200, Mickaël Salaün wrote:
> This new MAY_EXECMOUNT flag enables to check if the underlying mount
> point of an inode is marked as executable.  This is useful to implement
> a security policy taking advantage of the noexec mount option.
> 
> This flag is set according to path_noexec(), which checks if a mount
> point is mounted with MNT_NOEXEC or if the underlying superblock is
> SB_I_NOEXEC.
> 
> Signed-off-by: Mickaël Salaün <[email protected]>
> Reviewed-by: Philippe Trébuchet <[email protected]>
> Reviewed-by: Thibaut Sautereau <[email protected]>
> Cc: Aleksa Sarai <[email protected]>
> Cc: Al Viro <[email protected]>
> Cc: Kees Cook <[email protected]>
> ---
>  fs/namei.c         | 2 ++
>  include/linux/fs.h | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index a320371899cf..33b6d372e74a 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2849,6 +2849,8 @@ static int may_open(const struct path *path, int 
> acc_mode, int flag)
>               break;
>       }
>  
> +     /* Pass the mount point executability. */
> +     acc_mode |= path_noexec(path) ? 0 : MAY_EXECMOUNT;
>       error = inode_permission(inode, MAY_OPEN | acc_mode);
>       if (error)
>               return error;
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 313c934de9ee..79435fca6c3e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -103,6 +103,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t 
> offset,
>  #define MAY_NOT_BLOCK                0x00000080
>  /* the inode is opened with O_MAYEXEC */
>  #define MAY_OPENEXEC         0x00000100
> +/* the mount point is marked as executable */
> +#define MAY_EXECMOUNT                0x00000200
>  
>  /*
>   * flags in file.f_mode.  Note that FMODE_READ and FMODE_WRITE must 
> correspond

I find this name unintuitive, but I cannot think of anything better,
since I think my problem is that "MAY" doesn't map to the language I
want to use to describe what this flag is indicating.

Reviewed-by: Kees Cook <[email protected]>

-- 
Kees Cook

Reply via email to