On Thu, 2024-07-18 at 14:24 +0200, Mickaël Salaün wrote: > On Wed, Jul 17, 2024 at 07:08:17PM -0700, Jeff Xu wrote: > > On Wed, Jul 17, 2024 at 3:01 AM Mickaël Salaün <mic@xxxxxxxxxxx> > > wrote: > > > On Tue, Jul 16, 2024 at 11:33:55PM -0700, Jeff Xu wrote: [...] > > > > I'm still thinking execveat(AT_CHECK) vs faccessat(AT_CHECK) > > > > in different use cases: > > > > > > > > execveat clearly has less code change, but that also means: we > > > > can't add logic specific to exec (i.e. logic that can't be > > > > applied to config) for this part (from do_execveat_common to > > > > security_bprm_creds_for_exec) in future. This would require > > > > some agreement/sign-off, I'm not sure from whom. > > > > > > I'm not sure to follow. We could still add new flags, but for now > > > I don't see use cases. This patch series is not meant to handle > > > all possible "trust checks", only executable code, which makes > > > sense for the kernel. > > > > > I guess the "configfile" discussion is where I get confused, at one > > point, I think this would become a generic "trust checks" api for > > everything related to "generating executable code", e.g. > > javascript, java code, and more. We will want to clearly define the > > scope of execveat(AT_CHECK) > > The line between data and code is blurry. For instance, a > configuration file can impact the execution flow of a program. So, > where to draw the line? Having a way to have config files part of the trusted envelope, either by signing or measurement would be really useful. The current standard distro IMA deployment is signed executables, but not signed config because it's hard to construct a policy that doesn't force the signing of too many extraneous files (and files which might change often). > It might makes sense to follow the kernel and interpreter semantic: > if a file can be executed by the kernel (e.g. ELF binary, file > containing a shebang, or just configured with binfmt_misc), then this > should be considered as executable code. This applies to Bash, > Python, Javascript, NodeJS, PE, PHP... However, we can also make a > picture executable with binfmt_misc. So, again, where to draw the > line? Possibly by making open for config an indication executables can give? I'm not advocating doing it in this patch, but if we had an open for config indication, the LSMs could do much finer grained policy, especially if they knew which executable was trying to open the config file. It would allow things like an IMA policy saying if a signed executable is opening a config file, then that file must also be signed. James
