| Message ID | 20211008104840.1733385-1-mic@digikod.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add trusted_for(2) (was O_MAYEXEC) | expand |
On Fri, Oct 08, 2021 at 12:48:37PM +0200, Mickaël Salaün wrote: > This patch series is mainly a rebase on v5.15-rc4 with some cosmetic > changes suggested by Kees Cook. Andrew, can you please consider to > merge this into your tree? Thanks for staying on this series! This is a good step in the right direction for finally plugging the "interpreter" noexec hole. I'm pretty sure Chrome OS will immediately use this as they've been carrying similar functionality for a long time.
On Fri, 8 Oct 2021 12:48:37 +0200 Mickaël Salaün <mic@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... 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. - `flags' is unused (must be zero). So why does it exist? What are the plans here? - what values does the syscall return and what do they mean?
On 10/10/2021 23:48, Andrew Morton wrote: > On Fri, 8 Oct 2021 12:48:37 +0200 Mickaël Salaün <mic@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.
On Mon, 11 Oct 2021 10:47:04 +0200 Mickaël Salaün <mic@digikod.net> wrote: > > On 10/10/2021 23:48, Andrew Morton wrote: > > On Fri, 8 Oct 2021 12:48:37 +0200 Mickaël Salaün <mic@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 Well, kinda. It didn't explain why the `usage' and `flags' arguments exist and what are the plans for them. > Do you want me to copy-paste this content in the cover letter? That would be best please. It's basically the most important thing when reviewing the implementation. > > > > 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. And please document all of this in the changelog also.