On 10/10/2021 23:48, Andrew Morton wrote: > On Fri, 8 Oct 2021 12:48:37 +0200 Mickaël Salaün <mic@xxxxxxxxxxx> 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.
