Thread (2 messages) 2 messages, 2 authors, 2020-07-27

Re: [PATCH v7 4/7] fs: Introduce O_MAYEXEC flag for openat2(2)

From: Florian Weimer <hidden>
Date: 2020-07-27 05:27:22
Also in: linux-fsdevel, linux-integrity, linux-security-module, lkml

Possibly related (same subject, not in this thread)

* Al Viro:
On Thu, Jul 23, 2020 at 07:12:24PM +0200, Mickaël Salaün wrote:
quoted
When the O_MAYEXEC flag is passed, openat2(2) may be subject to
additional restrictions depending on a security policy managed by the
kernel through a sysctl or implemented by an LSM thanks to the
inode_permission hook.  This new flag is ignored by open(2) and
openat(2) because of their unspecified flags handling.  When used with
openat2(2), the default behavior is only to forbid to open a directory.
Correct me if I'm wrong, but it looks like you are introducing a magical
flag that would mean "let the Linux S&M take an extra special whip
for this open()".

Why is it done during open?  If the caller is passing it deliberately,
why not have an explicit request to apply given torture device to an
already opened file?  Why not sys_masochism(int fd, char *hurt_flavour),
for that matter?
While I do not think this is appropriate language for a workplace, Al
has a point: If the auditing event can be generated on an already-open
descriptor, it would also cover scenarios like this one:

  perl < /path/to/script

Where the process that opens the file does not (and cannot) know that it
will be used for execution purposes.

Thanks,
Florian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help