On 5/7/25 15:04, Tetsuo Handa wrote:
On 2025/05/08 0:37, Maxime Bélair wrote:
Again, each module decides which operations to expose through this syscall. In
many cases
the operation will still require CAP_SYS_ADMIN or a similar capability, so
environments
that choose this interface remain secure while gaining its advantages.
If the interpretation of "flags" argument varies across LSMs, it sounds like
ioctl()'s
yes that does feel like ioctls(), on the other hand defining them at the LSM
level won't
offer LSMs flexibility making it so the syscall covers fewer use cases. I am
not opposed
to either, it just hashing out what people want, and what is acceptable.
"cmd" argument. Also, there is prctl() which can already carry string-ish
parameters
without involving open(). Why can't we use prctl() instead of
lsm_manage_policy() ?
prctl() can be used, I used it for the unprivileged policy demo. It has its own
set of
problems. While LSM policy could be associated with the process doing the
load/replacement
or what ever operation, it isn't necessarily tied to it. A lot of LSM policy is
not
process specific making prctl() a poor fit.
prctl() requires allocating a global prctl()
prctl() are already being filtered/controlled by LSMs making them a poort fit
for
use by an LSM in a stacking situation as it requires updating the policy of
other
LSMs on the system. Yes seccomp can filter the syscall but that still is an
easier
barrier to overcome than having to have instruction for how to allow your LSMs
prctl() in multiple LSMs.
Mickaël already argued the need for landlock to have syscalls. See
https://lore.kernel.org/lkml/[email protected]/
and the numerous iterations before that.
Ideally those could have been LSM syscalls, with landlock leveraging them.
AppArmor
is getting to where it has similar needs to landlock. Yes we can use ioctls,
prctls,
netlink, the fs, etc. it doesn't mean that those are the best interfaces to do
so,
and ideally any interface we use will be of benefit to some other LSMs in the
future.
