On 5/12/25 03:20, Mickaël Salaün wrote:

On Sun, May 11, 2025 at 03:47:21AM -0700, John Johansen wrote:

quoted

On 5/9/25 03:26, Mickaël Salaün wrote:

quoted

On Thu, May 08, 2025 at 01:18:20AM -0700, John Johansen wrote:

quoted

On 5/7/25 23:06, Song Liu wrote:

quoted

On Wed, May 7, 2025 at 8:37 AM Maxime Bélair
[off-list ref] wrote:
[...]

quoted

quoted

quoted

quoted

permission check to each pseudo file. The downside of the syscall, however,
is that all the permission checks are hard-coded in the kernel (except for

The permission checks don't have to be hard coded. Each LSM can define how it handles
or manages the syscall. The default is that it isn't supported, but if an lsm decides
to support it, there is now reason that its policy can't determine the use of the
syscall.

  From an interface design point of view, it would be better to clearly
specify the scope of a command (e.g. which components could be impacted
by a command), and make sure the documentation reflect that as well.
Even better, have a syscalls per required privileges and impact (e.g.
privileged or unprivileged).  Going this road, I'm not sure if a
privileged syscall would make sense given the existing filesystem
interface.

uhhhmmm, not just privileged. As you well know we are looking to use
this for unprivileged policy. The LSM can limit to privileged if it
wants but it doesn't have to limit it to privileged policy.

Yes, I meant to say having a syscall for unprivileged actions, and maybe
another one for privileged ones, but this might be a hard sell. :)

indeed, in the apparmor case context would be important. Just exactly
what is privileged. It may be a privileged operation to load policy to one
namespace, but not to another that you are setting up for a child.

To say it another way, for your use case, do you need this syscall(s)
for privileged operations?  Do you plan to drop (or stop extending) the

need, probably. That is to say, loading of policy have varying levels
of privilege. root within the container has privilege to load policy
to its namespace, but it might have authority to setup a child namespace
that does not require privilege for it to load policy into, and it
will determine if the child has privilege or unprivleged policy within
it.

Ideally we won't have to use the fs interface within the "privileged"
container, as there are cases where this is currently not done or
undesirable.

filesystem interface or do you think it would be good for (AppArmor)
privileged operations too?  I know syscalls might be attractive and
could be used for everything, but it's good to have a well-defined plan
and semantic to avoid using such syscall as another multiplexer with
unrelated operations and required privileges.

sure. But the privilege level is use case dependent, to which policy
namespace is policy being loaded, replaced, ...  The privilege level
very much will depend on what is in the stack/bounding of policy.

If this syscall should also be a way to do privileged operations, should
we also agree on a common set of permissions (e.g. global CAP_MAC_ADMIN
or user namespace one)?

I think requiring something like CAP_MAC_ADMIN would be a per LSM
decision.

[...]

quoted

quoted

quoted

quoted

Overall, I am still not convinced a syscall for all LSMs is needed. To
justify such

its not needed by all LSMs, just a subset of them, and some nebulous
subset of potentially future LSMs that is entirely undefinable.

If we had had appropriate LSM syscalls landlock wouldn't have needed
to have landlock specific syscalls. Having another LSM go that route
feels wrong especially now that we have some LSM syscalls.

I don't agree.  Dedicated syscalls are a good thing.  See my other
reply.

I think we can just disagree on this point.

quoted

quoted

If a
syscall is needed by an LSM its better to try hashing something out
that might have utility for multiple LSMs or at the very least,
potentially have utility in the future.

quoted

a syscall, I think we need to show that it is useful in multiple LSMs.
Also, if we
really want to have single set of APIs for all LSMs, we may also need
get_policy,

We are never going to get a single set of APIs for all LSMs. I will
settle for an api that has utility for a subset

quoted

remove_policy, etc. This set as-is appears to be an incomplete design. The

To have a complete design, there needs to be feedback and discussion
from multiple LSMs. This is a starting point.

quoted

implementation, with call_int_hook, is also problematic. It can easily
cause some> controversial behaviors.

agreed it shouldn't be doing a straight call_int_hook, it should only
call it against the lsm identified by the lsmid

Yes, but then, I don't see the point of a "generic" LSM syscall.

its not a generic LSM syscall. Its a syscall or maybe a set of syscalls
for a specific scoped problem of loading/managing policy.

Can we come to something acceptable? I don't know but we are going to
look at it before trying for an apparmor specific syscall.

I understand and it's good to have this discussion.