Messages in this thread | | | Subject | Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC) | From | Igor Zhbanov <> | Date | Fri, 11 Sep 2020 17:15:10 +0300 |
| |
On 10.09.2020 23:05, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote: >> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote: >>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: >>>> 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. >>> >>> permission()? >> >> int lsm(int fd, const char *how, char *error, int size); >> >> Seriously, this is "ask LSM to apply special policy to file"; let's >> _not_ mess with flags, etc. for that; give it decent bandwidth >> and since it's completely opaque for the rest of the kernel, >> just a pass a string to be parsed by LSM as it sees fit. > > Hang on, it does have some things which aren't BD^W^WLSM. It lets > the interpreter honour the mount -o noexec option. I presume it's > not easily defeated by > cat /home/salaun/bin/bad.pl | perl -
Hi!
It could be bypassed this way. There are several ways of executing some script:
1) /unsigned.sh (Already handled by IMA) 2) bash /unsigned.sh (Not handled. Works even with "-o noexec" mount) 3) bash < /unsigned.sh (Not handled. Works even with "-o noexec" mount) 4) cat /unsigned.sh | bash (Not handled. Works even with "-o noexec" mount)
AFAIK, the proposed syscall solves #2 and may be #3. As for #4 in security critical environments there should be system-wide options to disable interpreting scripts from the standard input. I suppose, executing commands from the stdin is a rare case, and could be avoided entirely in security critical environments. And yes, some help from the interpreters is needed for that.
As for the usage of the system call, I have a proposal to extend its usage to validate systemd unit files. Because a unit file could specify what UID to use for a service, also it contains ExecStartPre which is actually a script and is running as root (for the system session services).
For the syscall name it could be: - trusted_file() - trusted_file_content() - valid_file() - file_integrity() because what we are checking here is the file content integrity (IMA) and may be file permissions/attrs integrity (EVM).
| |