Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 12, 2018 3:19 AM, John Johansen <john.johansen@xxxxxxxxxxxxx> wrote: > > It isn't perfect but it manages consistency across distros as best as > can be achieved atm. > > Its just a fact that some LSMs are not going to be built into some > kernels. The only way to deal with that is direct people to build > their own kernels. > > The other major problem is that the current LSM stacking patches do > not deal with "extreme" stacking. So doing > > lsm=+apparmor > > (I am going to stick with the + syntax atm to avoid confusion between > adding and setting) > > assuming apparmor is builtin will not necessarily get you apparmor if > another major lsm is enabled. Yes your specific proposal would as it > specifies it overrides the current major, except that ordering > important so if say landlock registers before apparmor, you may still > not get apparmor. > I think this will be solved with LSM_ORDER_LAST or something like that Kees proposed. > You proposal does not provide a means to ensure you have only a > specific set of LSMs enabled. As an LSM not explicitly listed in lsm= > lsm=! may still be enabled. So the user is going to have to be aware > of the initial LSMs list if they are trying to guarentee a specific > security arrangement. > What about special marker like "!!" which will mean "this string is explicit? lsm=!!,apparmor will enable apparmor and disable everything else. lsm=!!,!apparmor or lsm=!! will set the string empty and disable everything. "!!" in "CONFIG_LSM" will take precedence over "!!" in "lsm=" which will make "lsm=" totally ignored. This way distro could lock specific lsm set which isn't possible with current approach. CONFIG_LSM=!!,yama,loadpin,integrity,apparmor > This violates one of the hard asks, and I will tell you that this will > just mean there is going to be some distro patching to make sure it > exists. > I think I can quess who will make those patches :) > The current explicit list is more consistent, and it is amenable to > being extended with + or ! as selective add/remove so we are not > locked into only supporting an explicit list. > Jordan
