| Message ID | 20201203173118.379271-1-mic@digikod.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add trusted_for(2) (was O_MAYEXEC) | expand |
Hello, As a user of SELinux I'm quite interested in the trusted_for / O_MAYEXEC changes in the kernel and userspace. However the last activity on this patch seems to be this email from 2020-12-03 with no replies, so what is the status of this patchset or is there something that I'm missing ? https://patchwork.kernel.org/project/linux-security-module/list/?series=395617 https://lore.kernel.org/linux-security-module/20201203173118.379271-1-mic@digikod.net/
Hi, There was no new reviews, probably because the FS maintainers were busy, and I was focused on Landlock (which is now in -next), but I plan to send a new patch series for trusted_for(2) soon. Thanks for letting know your interest, Mickaël On 09/04/2021 18:26, bauen1 wrote: > Hello, > > As a user of SELinux I'm quite interested in the trusted_for / O_MAYEXEC changes in the kernel and userspace. > However the last activity on this patch seems to be this email from 2020-12-03 with no replies, so what is the status of this patchset or is there something that I'm missing ? > > https://patchwork.kernel.org/project/linux-security-module/list/?series=395617 > > https://lore.kernel.org/linux-security-module/20201203173118.379271-1-mic@digikod.net/ > >
On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote: > There was no new reviews, probably because the FS maintainers were busy, > and I was focused on Landlock (which is now in -next), but I plan to > send a new patch series for trusted_for(2) soon. Hi! Did this ever happen? It looks like it's in good shape, and I think it's a nice building block for userspace to have. Are you able to rebase and re-send this? I've tended to aim these things at akpm if Al gets busy. (And since you've had past review from Al, that should be hopefully sufficient.) Thanks for chasing this! -Kees
On 07/10/2021 00:03, Kees Cook wrote: > On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote: >> There was no new reviews, probably because the FS maintainers were busy, >> and I was focused on Landlock (which is now in -next), but I plan to >> send a new patch series for trusted_for(2) soon. > > Hi! > > Did this ever happen? It looks like it's in good shape, and I think it's > a nice building block for userspace to have. Are you able to rebase and > re-send this? I just sent it: https://lore.kernel.org/all/20211007182321.872075-1-mic@digikod.net/ Some Signed-off-by would be appreciated. :) > > I've tended to aim these things at akpm if Al gets busy. (And since > you've had past review from Al, that should be hopefully sufficient.) > > Thanks for chasing this! > > -Kees >
On Thu, 2021-10-07 at 20:29 +0200, Mickaël Salaün wrote: > On 07/10/2021 00:03, Kees Cook wrote: > > On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote: > >> There was no new reviews, probably because the FS maintainers were busy, > >> and I was focused on Landlock (which is now in -next), but I plan to > >> send a new patch series for trusted_for(2) soon. > > > > Hi! > > > > Did this ever happen? It looks like it's in good shape, and I think it's > > a nice building block for userspace to have. Are you able to rebase and > > re-send this? > > I just sent it: > https://lore.kernel.org/all/20211007182321.872075-1-mic@digikod.net/ > > Some Signed-off-by would be appreciated. :) > From the cover letter, It is important to note that this can only enable to extend access control managed by the kernel. Hence it enables current access control mechanism to be extended and become a superset of what they can currently control. Indeed, the security policy could also be delegated to an LSM, either a MAC system or an integrity system. For instance, this is required to close a major IMA measurement/appraisal interpreter integrity gap by bringing the ability to check the use of scripts [1]. Other uses are expected, such as for magic-links [2], SGX integration [3], bpffs [4]. From a quick review of the code, I don't see a new security hook being defined to cover these use cases. thanks, Mimi > > > > I've tended to aim these things at akpm if Al gets busy. (And since > > you've had past review from Al, that should be hopefully sufficient.) > > > > Thanks for chasing this! > > > > -Kees > >
On 07/10/2021 20:37, Mimi Zohar wrote: > On Thu, 2021-10-07 at 20:29 +0200, Mickaël Salaün wrote: >> On 07/10/2021 00:03, Kees Cook wrote: >>> On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote: >>>> There was no new reviews, probably because the FS maintainers were busy, >>>> and I was focused on Landlock (which is now in -next), but I plan to >>>> send a new patch series for trusted_for(2) soon. >>> >>> Hi! >>> >>> Did this ever happen? It looks like it's in good shape, and I think it's >>> a nice building block for userspace to have. Are you able to rebase and >>> re-send this? >> >> I just sent it: >> https://lore.kernel.org/all/20211007182321.872075-1-mic@digikod.net/ >> >> Some Signed-off-by would be appreciated. :) >> > >>From the cover letter, > > It is important to note that this can only enable to extend access > control managed by the kernel. Hence it enables current access control > mechanism to be extended and become a superset of what they can > currently control. Indeed, the security policy could also be delegated > to an LSM, either a MAC system or an integrity system. For instance, > this is required to close a major IMA measurement/appraisal interpreter > integrity gap by bringing the ability to check the use of scripts [1]. > Other uses are expected, such as for magic-links [2], SGX integration > [3], bpffs [4]. > >>From a quick review of the code, I don't see a new security hook being > defined to cover these use cases. Indeed, there is no new hook because it would require to implement it with a current LSM. This first step is a standalone implementation that is useful as-is but open the way to add a new LSM hook in this new syscall. That would be a second step for any LSM developer to implement if interested. > > thanks, > > Mimi > >>> >>> I've tended to aim these things at akpm if Al gets busy. (And since >>> you've had past review from Al, that should be hopefully sufficient.) >>> >>> Thanks for chasing this! >>> >>> -Kees >>> > >