You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It contains both SELinux and AppArmor, which are both major/exclusive LSMs. As shown by the logs below with lsm.debug set, AppArmor gets disabled because SELinux is listed first.
While the policy is "AppArmor is disabled by default", this works, but kind of by accident. It would be better stated as "Talos uses SELinux by default as its major LSM".
If the policy is "Talos does not enable a major LSM by default", then it is broken (SELinux is enabled).
If the policy in the future becomes "Talos uses AppArmor by default as its major LSM", then CONFIG_LSM will either be confusing or need to be changed.
The Talos documentation does recommend to set security=apparmor to enable AppArmor. This is arguably1 a legacy method, but the kernel still supports it and it will override CONFIG_LSM. It will not however override lsm= on the kernel cmdline (the kernel prefers lsm= over security= and will emit a warning).
Given all this, it may be better to remove both from CONFIG_LSM, and recommend setting lsm= in the kernel cmdline to enable the desired major LSM or continue recommending security= for its simplicity.
Talos 1.8.0 ships with experimental support for AppArmor for workloads (Kubernetes pods), but in Talos 1.9.0 we plan to ship a system-wide SELinux protection to isolate Talos core from the workloads.
In Talos 1.9.0 that would be off by default, but if enabled, it would disable AppArmor, even though users might decide to use AppArmor sill and switch off SELinux protection.
As it comes to workloads and SELinux, we don't have a definitive answer right now.
Sounds good. This is more feedback than an actionable issue indeed.
As I was experimenting with this yesterday, one other amusing thing I found is that the CONFIG_DEFAULT_SECURITY_ settings only alter the default value for CONFIG_LSM. So once you have a config, the next time you edit it, if you change those default security configs, they won't do anything since you'll already have a CONFIG_LSM value 😵💫
Talos's
CONFIG_LSM
does not entirely make sense currently.CONFIG_LSM="yama,selinux,loadpin,safesetid,integrity,bpf,apparmor"
It contains both SELinux and AppArmor, which are both major/exclusive LSMs. As shown by the logs below with
lsm.debug
set, AppArmor gets disabled because SELinux is listed first.While the policy is "AppArmor is disabled by default", this works, but kind of by accident. It would be better stated as "Talos uses SELinux by default as its major LSM".
If the policy is "Talos does not enable a major LSM by default", then it is broken (SELinux is enabled).
If the policy in the future becomes "Talos uses AppArmor by default as its major LSM", then
CONFIG_LSM
will either be confusing or need to be changed.The Talos documentation does recommend to set
security=apparmor
to enable AppArmor. This is arguably1 a legacy method, but the kernel still supports it and it will overrideCONFIG_LSM
. It will not however overridelsm=
on the kernel cmdline (the kernel preferslsm=
oversecurity=
and will emit a warning).Given all this, it may be better to remove both from
CONFIG_LSM
, and recommend settinglsm=
in the kernel cmdline to enable the desired major LSM or continue recommendingsecurity=
for its simplicity.Footnotes
https://docs.kernel.org/admin-guide/kernel-parameters.html
↩The text was updated successfully, but these errors were encountered: