On 10/12/2018 04:31 AM, Jordan Glover wrote: > 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. > possibly, though that was proposed with a config patchset different than the current proposal. >> 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? > what about a special marker like "+" which means the string is addative ;) > 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 :) > :) Maybe but I am not the only one who is asking for it, and the majority of the user bases I represent don't have this requirement. But with my distro hat on it really is a requirement for a distro that wants to enable users to have access to every lsm, but have a sane default set that can be supported. Its really not an insane security policy that new security measures are vetted before they are enabled. >> 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 >
