On 01/05/2020 06:22, James Morris wrote: > On Tue, 28 Apr 2020, Mickaël Salaün wrote: > >> Enable to either propagate the mount options from the underlying VFS >> mount to prevent execution, or to propagate the file execute permission. >> This may allow a script interpreter to check execution permissions >> before reading commands from a file. > > I'm finding the description of this patch difficult to understand. > > In the first case, this seems to mean: if you open a file with > RESOLVE_MAYEXEC from a noexec mount, then it will fail. Correct? Yes. > > In the second case, do you mean a RESOLVE_MAYEXEC open will fail if the > file does not have +x set for the user? Yes, and this is still in the hands sysadmins. As explain in the documentation patch, the sysctl takes a bitfield consisting of "mount !noexec" or "file exec permission". It is not an exclusive OR. The "file exec permission" could be seen as a more strict restriction than only the mount one. > > >> The main goal is to be able to protect the kernel by restricting >> arbitrary syscalls that an attacker could perform with a crafted binary >> or certain script languages. > > This sounds like the job of seccomp. Why is this part of MAYEXEC? The initial goal of O_MAYEXEC (in CLIP OS 4) is to prevent untrusted code execution. Code execution leads to system calls, which could lead to data access/modification, and kernel attacks. seccomp can't enable execution of only some files, it only enables an on/off execution policy (i.e. by filtering execve(2) ). > >> It also improves multilevel isolation >> by reducing the ability of an attacker to use side channels with >> specific code. These restrictions can natively be enforced for ELF >> binaries (with the noexec mount option) but require this kernel >> extension to properly handle scripts (e.g., Python, Perl). > > Again, not sure why you're talking about side channels and MAYEXEC and > mount options. Are you more generally talking about being able to prevent > execution of arbitrary script files included by an interpreter? Yes, I explain the thread model, especially the risk of scripts. Multilevel isolation can be bypassed simply by using CPU instructions (e.g. side channel attacks), not even syscalls. The ability to execute arbitrary code, including advanced scripting languages, can lead to this kind of CPU attacks. > >> Add a new sysctl fs.open_mayexec_enforce to control this behavior. >> Indeed, because of compatibility with installed systems, only the system >> administrator is able to check that this new enforcement is in line with >> the system mount points and file permissions. A following patch adds >> documentation. > > I don't like the idea of any of this feature set being configurable. > RESOLVE_MAYEXEC as a new flag should have well-defined, stable semantics. Unfortunately, as discussed in the v2 email thread [1], if we impose such restrictions with the O_MAYEXEC flag, then almost no userspace application will use it because it could cause unexpected behavior. Indeed, the application developers may not know the configuration of the system their applications will be run on. Only sysadmins know the mount points configuration (either they are have noexec or not), and if the set of application installed on the system works well with the set of files (e.g. according to their permissions). It is the same issue as with a system-wide LSM policy configuration. Processes should be able to tell their use of a file, but the sysadmin using common distro binaries should be able to control the execution policy according to the maturity of the current system installation. However, for fully controlled distros such as CLIP OS, it make sense to enforce such restrictions at kernel build time. I can add an alternative kernel configuration to enforce a particular policy at boot and disable this sysctl. [1] https://lore.kernel.org/lkml/1fbf54f6-7597-3633-a76c-11c4b2481add@xxxxxxxxxxx/
