Date: Tue, 30 Nov 2021 21:27:15 +0100 From: Florian Weimer <fweimer@...hat.com> To: Mickaël Salaün <mic@...ikod.net> Cc: Al Viro <viro@...iv.linux.org.uk>, Andrew Morton <akpm@...ux-foundation.org>, Alejandro Colomar <alx.manpages@...il.com>, Aleksa Sarai <cyphar@...har.com>, Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>, Casey Schaufler <casey@...aufler-ca.com>, Christian Brauner <christian.brauner@...ntu.com>, Christian Heimes <christian@...hon.org>, Deven Bowers <deven.desai@...ux.microsoft.com>, Dmitry Vyukov <dvyukov@...gle.com>, Eric Biggers <ebiggers@...nel.org>, Eric Chiang <ericchiang@...gle.com>, Geert Uytterhoeven <geert@...ux-m68k.org>, James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>, Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>, Kees Cook <keescook@...omium.org>, Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>, "Madhavan T . Venkataraman" <madvenka@...ux.microsoft.com>, Matthew Garrett <mjg59@...gle.com>, Matthew Wilcox <willy@...radead.org>, Miklos Szeredi <mszeredi@...hat.com>, Mimi Zohar <zohar@...ux.ibm.com>, Paul Moore <paul@...l-moore.com>, Philippe Trébuchet <philippe.trebuchet@....gouv.fr>, Scott Shell <scottsh@...rosoft.com>, Shuah Khan <shuah@...nel.org>, Steve Dower <steve.dower@...hon.org>, Steve Grubb <sgrubb@...hat.com>, Thibaut Sautereau <thibaut.sautereau@....gouv.fr>, Vincent Strubel <vincent.strubel@....gouv.fr>, Yin Fengwei <fengwei.yin@...el.com>, kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org Subject: Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC) * Mickaël Salaün: > Primary goal of trusted_for(2) > ============================== > > This new syscall enables user space to ask the kernel: is this file > descriptor's content trusted to be used for this purpose? The set of > usage currently only contains execution, but other may follow (e.g. > configuration, sensitive data). If the kernel identifies the file > descriptor as trustworthy for this usage, user space should then take > this information into account. The "execution" usage means that the > content of the file descriptor is trusted according to the system policy > to be executed by user space, which means that it interprets the content > or (try to) maps it as executable memory. I sketched my ideas about “IMA gadgets” here: IMA gadgets <https://www.openwall.com/lists/oss-security/2021/11/30/1> I still don't think the proposed trusted_for interface is sufficient. The example I gave is a Perl module that does nothing (on its own) when loaded as a Perl module (although you probably don't want to sign it anyway, given what it implements), but triggers an unwanted action when sourced (using .) as a shell script. > @usage identifies the user space usage intended for @fd: only > TRUSTED_FOR_EXECUTION for now, but trusted_for_usage could be extended > to identify other usages (e.g. configuration, sensitive data). We would need TRUSTED_FOR_EXECUTION_BY_BASH, TRUSTED_FOR_EXECUTION_BY_PERL, etc. I'm not sure that actually works. Caller process context does not work because we have this confusion internally between glibc's own use (for the dynamic linker configuration), and for loading programs/shared objects (there seems to be a corner case where you can execute arbitrary code even without executable mappings in the ELF object), and the script interpreter itself (the primary target for trusted_for). But for generating auditing events, trusted_for seems is probably quite helpful. Thanks, Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.