‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 12, 2018 2:26 AM, John Johansen <john.johansen@xxxxxxxxxxxxx> wrote: > On 10/11/2018 04:53 PM, Jordan Glover wrote: > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, October 12, 2018 1:09 AM, Kees Cook keescook@xxxxxxxxxxxx wrote: > > > > > We've had things sort of like this proposed, but if you can convince > > > James and others, I'm all for it. I think the standing objection from > > > James and John about this is that the results of booting with > > > "lsm=something" ends up depending on CONFIG_LSM= for that distro. So > > > you end up with different behaviors instead of a consistent behavior > > > across all distros. > > > > Ok, I'll try :) > > The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot > > param "lsm=". Changing even only one of those parts also changes the > > final string. > > In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm=" > > stays constant, the behavior will be different, example: > > Distro A has: CONFIG_LSM=loadpin,integrity,selinux > > Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux > > User on distro A wants to enable apparmor with: > > lsm=loadpin,integrity,apparmor > > which they do and add it to howto on wiki. > > User on distro B want to enable apparmor, they found info on some wiki and do: > > lsm=loadpin,integrity,apparmor > > Puff, yama got disabled! > > Above example shows why I think "consistent behavior across all distros" > > argument for current approach is flawed - because distros aren't > > consistent. In my proposition the user will just use "lsm=apparmor" and > > it will consistently enable apparmor on all distros which is what they > > really wanted, but all pre-existing differences across distros will > > remain unchanged. > > Are you sure about that? I have had more than one question about > security=X resulting in a system with more than just X enabled. Ie why > is yama enabled when I specifically set security to X. > So, non-explicit list will match current "security=" behavior which users are more familiar with. The current answer for this question is "because your distro enabled it and you didn't disabled it. With non-explcit list that answer will stay the same. With explicit list, the question will be "why is yama disabled when I enabled AppArmor with lsm=apparmor". To ask both questions user have to know that something like "yama" exist in first place. As for question what users typically want you may look at search results for "disable/enable yama" and "disable/enable apparmor/selinux". The difference is several orders of magnitude. That's why I think typical user just want to switch on/off one major lsm. I don't think anecdotal evidence is representative here. > There will certainly be cases where what you describe is exactly what > the user wants. The problem is an explosion of options isn't good > for the user either. > > What I want at the moment is the discussion about different ways to > enable LSMs to be split off so this work can move forward. > > > The current approach requires that everyone who dares to touch "lsm=" > > knows about existence of all lsm, their enabled/disabled status on > > target distro and their order. I doubt there are many people other > > than recipients of this mail who fit for the above. > > Without having gotten a chance to review the current set of patches > that was not what was discussed, it should only requires they know the > set that they want. > "it should only requires they know the set that they want" is very hard requirement and I don't think most users will pass this. Especially when sets like: lsm=yama,loadpin,integrity,apparmor lsm=loadpin,integrity,yama,apparmor will behave differently. Jordan