[PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)

Mickaël Salaün mic at digikod.net
Mon Oct 11 08:47:04 UTC 2021


On 10/10/2021 23:48, Andrew Morton wrote:
> On Fri,  8 Oct 2021 12:48:37 +0200 Mickaël Salaün <mic at digikod.net> wrote:
> 
>> The final goal of this patch series is to enable the kernel to be a
>> global policy manager by entrusting processes with access control at
>> their level.  To reach this goal, two complementary parts are required:
>> * user space needs to be able to know if it can trust some file
>>   descriptor content for a specific usage;
>> * and the kernel needs to make available some part of the policy
>>   configured by the system administrator.
> 
> Apologies if I missed this...
> 
> It would be nice to see a description of the proposed syscall interface
> in these changelogs!  Then a few questions I have will be answered...

I described this syscall and it's semantic in the first patch in
Documentation/admin-guide/sysctl/fs.rst
Do you want me to copy-paste this content in the cover letter?

> 
> long trusted_for(const int fd,
> 		 const enum trusted_for_usage usage,
> 		 const u32 flags)
> 
> - `usage' must be equal to TRUSTED_FOR_EXECUTION, so why does it
>   exist?  Some future modes are planned?  Please expand on this.

Indeed, the current use case is to check if the kernel would allow
execution of a file. But as Florian pointed out, we may want to add more
context in the future, e.g. to enforce signature verification, to check
if this is a legitimate (system) library, to check if the file is
allowed to be used as (trusted) configuration…

> 
> - `flags' is unused (must be zero).  So why does it exist?  What are
>   the plans here?

This is mostly to follow syscall good practices for extensibility. It
could be used in combination with the usage argument (which defines the
user space semantic), e.g. to check for extra properties such as
cryptographic or integrity requirements, origin of the file…

> 
> - what values does the syscall return and what do they mean?
> 

It returns 0 on success, or -EACCES if the kernel policy denies the
specified usage.



More information about the Linux-security-module-archive mailing list