| Message ID | 20181011001846.30964-1-keescook@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | LSM: Explict ordering | expand |
On Wed, 10 Oct 2018, Kees Cook wrote: > v5: > - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling > - dropped various Reviewed-bys due to rather large refactoring Patches 1-10 applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general and next-testing.
On Wed, Oct 10, 2018 at 8:45 PM, James Morris <jmorris@namei.org> wrote: > On Wed, 10 Oct 2018, Kees Cook wrote: > >> v5: >> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling >> - dropped various Reviewed-bys due to rather large refactoring > > Patches 1-10 applied to > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general > and next-testing. Very cool; thanks! As for the rest, I could post some examples of how the new CONFIG_LSM and "lsm=..." work (and how they mix with the "legacy" options). Would that be helpful? -Kees
On Thu, 11 Oct 2018, Kees Cook wrote: > On Wed, Oct 10, 2018 at 8:45 PM, James Morris <jmorris@namei.org> wrote: > > On Wed, 10 Oct 2018, Kees Cook wrote: > > > >> v5: > >> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling > >> - dropped various Reviewed-bys due to rather large refactoring > > > > Patches 1-10 applied to > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general > > and next-testing. > > Very cool; thanks! > > As for the rest, I could post some examples of how the new CONFIG_LSM > and "lsm=..." work (and how they mix with the "legacy" options). Would > that be helpful? Yes, thanks.
On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook <keescook@chromium.org> wrote: > v5: > - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling > - dropped various Reviewed-bys due to rather large refactoring Here's a tl;dr of the behavioral changes... Right now, we have: - hard-coded special LSM: capability which cannot be disabled. - hard-coded "minor" LSMs: they are enabled in a static order based on whether they are built into the kernel or not: yama, loadpin. - a single LSM without a specified order because it only uses the early-init position: integrity. - "major" LSMs that are selected via CONFIG_DEFAULT_SECURITY= or "security=" boot param. - SELinux and AppArmor each can enable/disable themselves via CONFIG_..._BOOTPARAM_VALUE= and selinux=/apparmor=. So, right now, systems will have all the minor LSMs and integrity initialized if they are built into the kernel without any way to control their order or disable them at boot time. To select a major LSM, the pattern is: selinux=1 security=selinux Note that both are used here because if you built with CONFIG_SELINUX_BOOTPARAM_VALUE=0 and CONFIG_DEFAULT_SECURITY=apparmor, just booting with "security=selinux" just disables AppArmor but SELinux stays disabled. So the documented way to switch majors is with "selinux=1 security=selinux". *However* Tomoyo and Smack do not have separate enable/disable logic. They will work fine with just "security=smack". Now, in order to gain arbitrary LSM ordering, this series introduces CONFIG_LSM= (to replace CONFIG_DEFAULT_SECURITY=) and "lsm=" (to replace "security="). Note that "security=" has not been removed -- it will still work. Mixing it with "lsm=" can lead to situations where "security=" becomes effectively ignored, though. In the rest of this I'm going to ignore capability: it will always be first and it will always be enabled. Assuming that all LSMs are built in (e.g. yama, loadpin, selinux, smack, tomoyo, apparmor, integrity), here are the changes: To choose the "default major LSM" of AppArmor before: CONFIG_DEFAULT_SECURITY=apparmor To choose the "default major LSM" of AppArmor _without_ extreme stacking now: CONFIG_LSM=yama,loadpin,integrity,apparmor To choose the "default major LSM" of AppArmor with future extreme stacking now: CONFIG_LSM=yama,loadpin,integrity,apparmor,tomoyo,selinux,smack Whichever exclusive LSM is listed _first_ will be the first to attempt initialization. Any non-conflicting LSMs following it will initialize too. This means a distro can disable the "blob-sharing" behavior by just providing a CONFIG_LSM= that includes a single major LSM. To switch to SELinux at boot time with "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to work: selinux=1 security=selinux This will work still, since it will enable selinux (selinux=1) and disable all other major LSMs (security=selinux). The new way to enable selinux would be using "lsm=yama,loadpin,integrity,selinux". To see the behaviors, you can boot with "lsm.debug". (Note that CONFIG_LSM= and "lsm=" are handled exactly the same, so a boot with "lsm=" would see the same results as a boot without "lsm=", but with CONFIG_LSM= set to that string.) An example: lsm.debug lsm=integrity,cows,loadpin,capability,apparmor,tomoyo selinux=1 security=selinux produces: [ 0.292502] LSM: Security Framework initializing [ 0.293109] LSM: security=selinux disabled: smack [ 0.293464] LSM: security=selinux disabled: tomoyo [ 0.294464] LSM: security=selinux disabled: apparmor [ 0.295109] LSM: first ordering: capability (enabled) [ 0.295464] LSM: cmdline ordering: integrity (enabled) [ 0.296464] LSM: cmdline ignored: cows [ 0.296953] LSM: cmdline ordering: loadpin (enabled) [ 0.297464] LSM: cmdline ignored: capability [ 0.298464] LSM: cmdline ordering: apparmor (disabled) [ 0.299136] LSM: cmdline ordering: tomoyo (disabled) [ 0.299464] LSM: security= ordering: selinux (enabled) [ 0.300464] LSM: cmdline disabled: smack [ 0.300979] LSM: cmdline disabled: yama [ 0.301464] LSM: exclusive chosen: selinux [ 0.302008] LSM: initializing capability [ 0.302464] LSM: initializing integrity [ 0.302968] LSM: initializing loadpin [ 0.303464] LoadPin: ready to pin (currently not enforcing) [ 0.304464] LSM: initializing selinux [ 0.304946] SELinux: Initializing. With yama left out of lsm=, it is disabled. Invalid, non-mutable-order, or unbuilt LSMs are ignored (i.e. "cows" and "capability" above). "security=selinux" disables all the other majors (their ordering is left alone) and things not mentioned in lsm= and[1] security= are explicitly disabled (and left out of the ordering). Another example, without "security="... lsm.debug lsm=integrity,yama,cows,loadpin,capability,apparmor,tomoyo,selinux,smack [ 0.291697] LSM: Security Framework initializing [ 0.292660] LSM: first ordering: capability (enabled) [ 0.293337] LSM: cmdline ordering: integrity (enabled) [ 0.293659] LSM: cmdline ordering: yama (enabled) [ 0.294659] LSM: cmdline ignored: cows [ 0.295169] LSM: cmdline ordering: loadpin (enabled) [ 0.295659] LSM: cmdline ignored: capability [ 0.296231] LSM: cmdline ordering: apparmor (enabled) [ 0.296659] LSM: cmdline ordering: tomoyo (enabled) [ 0.297659] LSM: cmdline ordering: selinux (enabled) [ 0.298659] LSM: cmdline ordering: smack (enabled) [ 0.299309] LSM: exclusive chosen: apparmor [ 0.299659] LSM: exclusive disabled: tomoyo [ 0.300216] LSM: exclusive disabled: selinux [ 0.300659] LSM: exclusive disabled: smack [ 0.301208] LSM: initializing capability [ 0.301659] LSM: initializing integrity [ 0.302662] LSM: initializing yama [ 0.303124] Yama: becoming mindful. [ 0.303666] LSM: initializing loadpin [ 0.304164] LoadPin: ready to pin (currently not enforcing) [ 0.304660] LSM: initializing apparmor [ 0.305179] AppArmor: AppArmor initialized Given that apparmor is listed first, its exclusivity disables the other exclusive LSMs, and initialization proceeds. So, this should work for all the cases we've got coming, as far as I can see! :) -Kees [1] In testing v5, I did discover one glitch in my "security=" handling, which I've fixed locally now for v6.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@chromium.org> wrote: > On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook keescook@chromium.org wrote: > > > v5: > > > > - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling > > - dropped various Reviewed-bys due to rather large refactoring > > Here's a tl;dr of the behavioral changes... > > Right now, we have: > > - hard-coded special LSM: capability which cannot be disabled. > - hard-coded "minor" LSMs: they are enabled in a static order based on > whether they are built into the kernel or not: yama, loadpin. > > - a single LSM without a specified order because it only uses the > early-init position: integrity. > > - "major" LSMs that are selected via CONFIG_DEFAULT_SECURITY= or > "security=" boot param. > > - SELinux and AppArmor each can enable/disable themselves via > CONFIG_..._BOOTPARAM_VALUE= and selinux=/apparmor=. > > So, right now, systems will have all the minor LSMs and integrity > initialized if they are built into the kernel without any way to > control their order or disable them at boot time. To select a major > LSM, the pattern is: > > selinux=1 security=selinux > > Note that both are used here because if you built with > CONFIG_SELINUX_BOOTPARAM_VALUE=0 and CONFIG_DEFAULT_SECURITY=apparmor, > just booting with "security=selinux" just disables AppArmor but > SELinux stays disabled. So the documented way to switch majors is with > "selinux=1 security=selinux". However Tomoyo and Smack do not have > separate enable/disable logic. They will work fine with just > "security=smack". > > Now, in order to gain arbitrary LSM ordering, this series introduces > CONFIG_LSM= (to replace CONFIG_DEFAULT_SECURITY=) and "lsm=" (to > replace "security="). Note that "security=" has not been removed -- it > will still work. Mixing it with "lsm=" can lead to situations where > "security=" becomes effectively ignored, though. > > In the rest of this I'm going to ignore capability: it will always be > first and it will always be enabled. > > Assuming that all LSMs are built in (e.g. yama, loadpin, selinux, > smack, tomoyo, apparmor, integrity), here are the changes: > > To choose the "default major LSM" of AppArmor before: > CONFIG_DEFAULT_SECURITY=apparmor > > To choose the "default major LSM" of AppArmor without extreme stacking now: > CONFIG_LSM=yama,loadpin,integrity,apparmor > > To choose the "default major LSM" of AppArmor with future extreme stacking now: > CONFIG_LSM=yama,loadpin,integrity,apparmor,tomoyo,selinux,smack > > Whichever exclusive LSM is listed first will be the first to attempt > initialization. Any non-conflicting LSMs following it will initialize > too. > > This means a distro can disable the "blob-sharing" behavior by just > providing a CONFIG_LSM= that includes a single major LSM. > > To switch to SELinux at boot time with > "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to > work: > > selinux=1 security=selinux > > This will work still, since it will enable selinux (selinux=1) and > disable all other major LSMs (security=selinux). > > The new way to enable selinux would be using > "lsm=yama,loadpin,integrity,selinux". > It seems to me that legacy way is more user friendly than the new one. AppArmor and SElinux are households names but the rest may be enigmatic for most users and the need for explicit passing them all may be troublesome. Especially when the new ones like sara,landlock or cows :) will be incoming. Moreover to knew what you have to pass there, you need to look at CONFIG_LSM in kernel config (which will vary across distros and also mean copy-paste from the web source may won't work as expected) which again most users don't do. I think there is risk that users will end up with "lsm=selinux" without realizing that they may disable something along the way. I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with below assumptions: I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme stacking it will also remove the other major (explicit) lsm from it. II. lsm="!$lsm" will remove "$lsm" from the string. III. If "$lsm" already exist in the string, it's moved at the end of it (this will cover ordering). Examples: 1. Without extreme stacking. a) Enable selinux, disable apparmor and leave the rest untouched. CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux = yama,loadpin,integrity,selinux b) Enable selinux, disable apparmor and disable loadpin. CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!loadpin = yama,integrity,selinux 2. With extreme stacking. a) Enable selinux, disable apparmor and leave the rest untouched. CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!apparmor = yama,loadpin,integrity,selinux b) Enable selinux, disable apparmor and disable loadpin. CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!apparmor,!loadpin = yama,integrity,selinux c) Enable selinux and order it after apparmor. CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux = yama,loadpin,integrity,apparmor,selinux d) Enable selinux and order it before apparmor. CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,apparmor = yama,loadpin,integrity,selinux,apparmor IMO above will be easier to handle for users. At worst case with full ordering all existing lsm's it will look the same as what Kees proposes but I assume that ordering is rather for more advanced people. It's possible that something lime this was discussed already but without full examples it was hard to me for tracking things. Jordan
On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover <Golden_Miller83@protonmail.ch> wrote: > On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@chromium.org> wrote: >> To switch to SELinux at boot time with >> "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to >> work: >> >> selinux=1 security=selinux >> >> This will work still, since it will enable selinux (selinux=1) and >> disable all other major LSMs (security=selinux). >> >> The new way to enable selinux would be using >> "lsm=yama,loadpin,integrity,selinux". >> > > It seems to me that legacy way is more user friendly than the new one. > AppArmor and SElinux are households names but the rest may be enigmatic > for most users and the need for explicit passing them all may be > troublesome. Especially when the new ones like sara,landlock or cows :) > will be incoming. Moreover to knew what you have to pass there, you need > to look at CONFIG_LSM in kernel config (which will vary across distros > and also mean copy-paste from the web source may won't work as expected) > which again most users don't do. > > I think there is risk that users will end up with "lsm=selinux" without > realizing that they may disable something along the way. > > I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with > below assumptions: > > I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme > stacking it will also remove the other major (explicit) lsm from it. > > II. lsm="!$lsm" will remove "$lsm" from the string. > > III. If "$lsm" already exist in the string, it's moved at the end of it > (this will cover ordering). 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. Now, in the future blob and extreme stacking world, having the explicit lsm= list shouldn't be too bad since LSMs will effectively ALL be initialized -- but they'll be inactive since they have no policy loaded. But I still agree with you: I'd like a friendlier way to disable/enable specific LSMs, but an explicit lsm= seems to be the only way. > It's possible that something lime this was discussed already > but without full examples it was hard to me for tracking things. It's been a painful thread. ;) -Kees
On 10/11/2018 04:09 PM, Kees Cook wrote: > On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover > <Golden_Miller83@protonmail.ch> wrote: >> On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@chromium.org> wrote: >>> To switch to SELinux at boot time with >>> "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to >>> work: >>> >>> selinux=1 security=selinux >>> >>> This will work still, since it will enable selinux (selinux=1) and >>> disable all other major LSMs (security=selinux). >>> >>> The new way to enable selinux would be using >>> "lsm=yama,loadpin,integrity,selinux". >>> >> >> It seems to me that legacy way is more user friendly than the new one. >> AppArmor and SElinux are households names but the rest may be enigmatic >> for most users and the need for explicit passing them all may be >> troublesome. Especially when the new ones like sara,landlock or cows :) >> will be incoming. Moreover to knew what you have to pass there, you need >> to look at CONFIG_LSM in kernel config (which will vary across distros >> and also mean copy-paste from the web source may won't work as expected) >> which again most users don't do. >> >> I think there is risk that users will end up with "lsm=selinux" without >> realizing that they may disable something along the way. >> >> I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with >> below assumptions: >> >> I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme >> stacking it will also remove the other major (explicit) lsm from it. >> >> II. lsm="!$lsm" will remove "$lsm" from the string. >> >> III. If "$lsm" already exist in the string, it's moved at the end of it >> (this will cover ordering). > > 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. > Its certainly a point that could confuse the user. I do have concerns about it, but not something that is on a must haves list > Now, in the future blob and extreme stacking world, having the > explicit lsm= list shouldn't be too bad since LSMs will effectively > ALL be initialized -- but they'll be inactive since they have no > policy loaded. > you are more optimistic about this than I am, but there will be at least some movement towards this. > But I still agree with you: I'd like a friendlier way to > disable/enable specific LSMs, but an explicit lsm= seems to be the > only way. > Hrmmm, I don't know about the only way, but a way to provide the explicit list, and also set a specific set as the default in the Kconfig is a hard requirement. The initial lsm.ebable, lsm.disable had too many issues, and for various reasons I never managed to get back to kees' proposal for using +. That said, I do think the right approach for the initial pass is the explicit list. It moves the arguments to the side and allows this work to move forward. >> It's possible that something lime this was discussed already >> but without full examples it was hard to me for tracking things. > > It's been a painful thread. ;) > Indeed
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 12, 2018 1:09 AM, Kees Cook <keescook@chromium.org> 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. 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. I it's better to assume that average user has rather vague knowledge about lsm and don't delve deep into Kconfig's of their chosen distro. If they want to use "lsm=" their goal is to disable/enable on or more things. My proposition will work better for those. More advanced users still will may pass any "lsm=" string as they like, this having full control. Jordan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 12, 2018 1:48 AM, John Johansen <john.johansen@canonical.com> wrote: > On 10/11/2018 04:09 PM, Kees Cook wrote: > > > On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover > > Golden_Miller83@protonmail.ch wrote: > > > > > On Thursday, October 11, 2018 7:57 PM, Kees Cook keescook@chromium.org wrote: > > > > > > > To switch to SELinux at boot time with > > > > "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to > > > > work: > > > > > > > > selinux=1 security=selinux > > > > > > > > This will work still, since it will enable selinux (selinux=1) and > > > > disable all other major LSMs (security=selinux). > > > > > > > > The new way to enable selinux would be using > > > > "lsm=yama,loadpin,integrity,selinux". > > > > > > > > > > It seems to me that legacy way is more user friendly than the new one. > > > AppArmor and SElinux are households names but the rest may be enigmatic > > > for most users and the need for explicit passing them all may be > > > troublesome. Especially when the new ones like sara,landlock or cows :) > > > will be incoming. Moreover to knew what you have to pass there, you need > > > to look at CONFIG_LSM in kernel config (which will vary across distros > > > and also mean copy-paste from the web source may won't work as expected) > > > which again most users don't do. > > > I think there is risk that users will end up with "lsm=selinux" without > > > realizing that they may disable something along the way. > > > I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with > > > below assumptions: > > > I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme > > > stacking it will also remove the other major (explicit) lsm from it. > > > II. lsm="!$lsm" will remove "$lsm" from the string. > > > III. If "$lsm" already exist in the string, it's moved at the end of it > > > (this will cover ordering). > > > > 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. > > Its certainly a point that could confuse the user. I do have concerns > about it, but not something that is on a must haves list > > > Now, in the future blob and extreme stacking world, having the > > explicit lsm= list shouldn't be too bad since LSMs will effectively > > ALL be initialized -- but they'll be inactive since they have no > > policy loaded. > > you are more optimistic about this than I am, but there will be at > least some movement towards this. > > > But I still agree with you: I'd like a friendlier way to > > disable/enable specific LSMs, but an explicit lsm= seems to be the > > only way. > > Hrmmm, I don't know about the only way, but a way to provide the > explicit list, and also set a specific set as the default in the > Kconfig is a hard requirement. > My proposition allows for explicit "lsm=" list but also accepts non explicit list. This is it's advantage above current approach. The current approach works but it seems to target the very same people who designed it :) > The initial lsm.ebable, lsm.disable had too many issues, and for > various reasons I never managed to get back to kees' proposal > for using +. > > That said, I do think the right approach for the initial pass is > the explicit list. It moves the arguments to the side and allows > this work to move forward. > I'm afraid when it hits stable kernel and people will rely on it, then it will be too late. Things will be even more hard to change than now when we have to keep legacy syntax of security=xxx. I added explanation why explicit list doesn't solve consistency across distros in the other reply > > > It's possible that something lime this was discussed already > > > but without full examples it was hard to me for tracking things. > > > > It's been a painful thread. ;) > > Indeed Jordan
On 10/11/2018 04:53 PM, Jordan Glover wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, October 12, 2018 1:09 AM, Kees Cook <keescook@chromium.org> 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. 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 is possible some of the LSMs in the list are not available for a given kernel, but that is a problem with even the additive approach. That is lsm=+apparmor will not add apparmor to the set of LSMs available at run time if apparmor has not been built into the kernel. > I it's better to assume that average user has rather vague knowledge > about lsm and don't delve deep into Kconfig's of their chosen distro. > If they want to use "lsm=" their goal is to disable/enable on or more > things. My proposition will work better for those. More advanced users > still will may pass any "lsm=" string as they like, this having full > control. > > Jordan >
On 10/11/2018 05:11 PM, Jordan Glover wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, October 12, 2018 1:48 AM, John Johansen <john.johansen@canonical.com> wrote: > >> On 10/11/2018 04:09 PM, Kees Cook wrote: >> >>> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover >>> Golden_Miller83@protonmail.ch wrote: >>> >>>> On Thursday, October 11, 2018 7:57 PM, Kees Cook keescook@chromium.org wrote: >>>> >>>>> To switch to SELinux at boot time with >>>>> "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to >>>>> work: >>>>> >>>>> selinux=1 security=selinux >>>>> >>>>> This will work still, since it will enable selinux (selinux=1) and >>>>> disable all other major LSMs (security=selinux). >>>>> >>>>> The new way to enable selinux would be using >>>>> "lsm=yama,loadpin,integrity,selinux". >>>>> >>>> >>>> It seems to me that legacy way is more user friendly than the new one. >>>> AppArmor and SElinux are households names but the rest may be enigmatic >>>> for most users and the need for explicit passing them all may be >>>> troublesome. Especially when the new ones like sara,landlock or cows :) >>>> will be incoming. Moreover to knew what you have to pass there, you need >>>> to look at CONFIG_LSM in kernel config (which will vary across distros >>>> and also mean copy-paste from the web source may won't work as expected) >>>> which again most users don't do. >>>> I think there is risk that users will end up with "lsm=selinux" without >>>> realizing that they may disable something along the way. >>>> I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with >>>> below assumptions: >>>> I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme >>>> stacking it will also remove the other major (explicit) lsm from it. >>>> II. lsm="!$lsm" will remove "$lsm" from the string. >>>> III. If "$lsm" already exist in the string, it's moved at the end of it >>>> (this will cover ordering). >>> >>> 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. >> >> Its certainly a point that could confuse the user. I do have concerns >> about it, but not something that is on a must haves list >> >>> Now, in the future blob and extreme stacking world, having the >>> explicit lsm= list shouldn't be too bad since LSMs will effectively >>> ALL be initialized -- but they'll be inactive since they have no >>> policy loaded. >> >> you are more optimistic about this than I am, but there will be at >> least some movement towards this. >> >>> But I still agree with you: I'd like a friendlier way to >>> disable/enable specific LSMs, but an explicit lsm= seems to be the >>> only way. >> >> Hrmmm, I don't know about the only way, but a way to provide the >> explicit list, and also set a specific set as the default in the >> Kconfig is a hard requirement. >> > > My proposition allows for explicit "lsm=" list but also accepts non > explicit list. This is it's advantage above current approach. > > The current approach works but it seems to target the very same people > who designed it :) > >> The initial lsm.ebable, lsm.disable had too many issues, and for >> various reasons I never managed to get back to kees' proposal >> for using +. >> >> That said, I do think the right approach for the initial pass is >> the explicit list. It moves the arguments to the side and allows >> this work to move forward. >> > > I'm afraid when it hits stable kernel and people will rely on it, > then it will be too late. Things will be even more hard to change > than now when we have to keep legacy syntax of security=xxx. > > I added explanation why explicit list doesn't solve consistency > across distros in the other reply > 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. 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. 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. 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. >>>> It's possible that something lime this was discussed already >>>> but without full examples it was hard to me for tracking things. >>> >>> It's been a painful thread. ;) >> >> Indeed > > Jordan >
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 12, 2018 2:26 AM, John Johansen <john.johansen@canonical.com> wrote: > On 10/11/2018 04:53 PM, Jordan Glover wrote: > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, October 12, 2018 1:09 AM, Kees Cook keescook@chromium.org 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
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 12, 2018 3:19 AM, John Johansen <john.johansen@canonical.com> 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
On 10/12/2018 04:31 AM, Jordan Glover wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, October 12, 2018 2:26 AM, John Johansen <john.johansen@canonical.com> wrote: > >> On 10/11/2018 04:53 PM, Jordan Glover wrote: >> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Friday, October 12, 2018 1:09 AM, Kees Cook keescook@chromium.org 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. > the current behavior is problematic leads to a configuration nightmare, and is the reason lsm= is proposed instead of just sticking with security= > With explicit list, the question will be "why is yama disabled when I > enabled AppArmor with lsm=apparmor". > yes that will happen as well > To ask both questions user have to know that something like "yama" exist > in first place. > yes. However when it comes to security I don't think its too insane to want to vet new modules before they become part of your configuration. This is something distros want to be able to do and something some users want. I am not claiming this is what all users will want, and it certainly isn't the best situation for the adoption of new lsms. But is a very understandable security policy stance. > 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. > yes, that is a problem and it highlights the complexity of the problem we are dealing with. Your proposal tries to hide the ordering issues from the user but they still suffer from the potentially different behavior of list ordering as it is moving the lsm around in the list. fwiw kees finally convinced me that having the order set separate from enablement in the kconfig is better for the user because of problems like this.
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@canonical.com> 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 >
On Friday, October 12, 2018 3:19 AM, John Johansen <john.johansen@canonical.com> wrote: > It isn't perfect but it manages consistency across distros as best as > can be achieved atm. Yeah, this is why I'm okay with the current series: it provides as consistent a view as possible, but leaves room for future improvements (like adding "+" or "!" or "all" or whatever). I'm curious to see what SELinux folks think of v5, though. I *think* I addressed all the concerns there, even Paul's "I want my distro default to not have extreme stacking" case too. -Kees
On 10/12/2018 12:01 PM, Kees Cook wrote: > On Friday, October 12, 2018 3:19 AM, John Johansen > <john.johansen@canonical.com> wrote: >> It isn't perfect but it manages consistency across distros as best as >> can be achieved atm. > Yeah, this is why I'm okay with the current series: it provides as > consistent a view as possible, but leaves room for future improvements > (like adding "+" or "!" or "all" or whatever). > > I'm curious to see what SELinux folks think of v5, though. I *think* I > addressed all the concerns there, even Paul's "I want my distro > default to not have extreme stacking" case too. > > -Kees Looks like I should go on vacation more often. :) I am generally opposed to fancy specification languages. I support the explicit lsm= list specification because you don't have to know any context to create a boot line that will work, and be as close to what you've specified as possible for the kernel configuration. One need look no further than the mechanisms for setting POSIX ACLs for an example of how to ensure a feature isn't used. Had we the foresight to make security= take a list of modules when Yama was added we might have avoided some of this brouhaha, but there was no reason to expect that stacking was ever going to happen back then.
On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 10/12/2018 12:01 PM, Kees Cook wrote: >> On Friday, October 12, 2018 3:19 AM, John Johansen >> <john.johansen@canonical.com> wrote: >>> It isn't perfect but it manages consistency across distros as best as >>> can be achieved atm. >> Yeah, this is why I'm okay with the current series: it provides as >> consistent a view as possible, but leaves room for future improvements >> (like adding "+" or "!" or "all" or whatever). >> >> I'm curious to see what SELinux folks think of v5, though. I *think* I >> addressed all the concerns there, even Paul's "I want my distro >> default to not have extreme stacking" case too. >> >> -Kees > > Looks like I should go on vacation more often. :) > > I am generally opposed to fancy specification languages. > I support the explicit lsm= list specification because you > don't have to know any context to create a boot line that > will work, and be as close to what you've specified as possible > for the kernel configuration. One need look no further than > the mechanisms for setting POSIX ACLs for an example of > how to ensure a feature isn't used. > > Had we the foresight to make security= take a list of > modules when Yama was added we might have avoided some of > this brouhaha, but there was no reason to expect that stacking > was ever going to happen back then. This sounds like an "Ack" for you? :) I'll harass everyone in person in a couple days. Did you poke around at my combined series? https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing -Kees
On 10/23/2018 11:50 AM, Kees Cook wrote: > On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 10/12/2018 12:01 PM, Kees Cook wrote: >>> On Friday, October 12, 2018 3:19 AM, John Johansen >>> <john.johansen@canonical.com> wrote: >>>> It isn't perfect but it manages consistency across distros as best as >>>> can be achieved atm. >>> Yeah, this is why I'm okay with the current series: it provides as >>> consistent a view as possible, but leaves room for future improvements >>> (like adding "+" or "!" or "all" or whatever). >>> >>> I'm curious to see what SELinux folks think of v5, though. I *think* I >>> addressed all the concerns there, even Paul's "I want my distro >>> default to not have extreme stacking" case too. >>> >>> -Kees >> Looks like I should go on vacation more often. :) >> >> I am generally opposed to fancy specification languages. >> I support the explicit lsm= list specification because you >> don't have to know any context to create a boot line that >> will work, and be as close to what you've specified as possible >> for the kernel configuration. One need look no further than >> the mechanisms for setting POSIX ACLs for an example of >> how to ensure a feature isn't used. >> >> Had we the foresight to make security= take a list of >> modules when Yama was added we might have avoided some of >> this brouhaha, but there was no reason to expect that stacking >> was ever going to happen back then. > This sounds like an "Ack" for you? :) I'll harass everyone in person > in a couple days. Acked-by: Casey Schaufler <casey@schaufler-ca.com> > Did you poke around at my combined series? > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing I hope to do that on the plane later today. > -Kees
On 10/23/2018 12:05 PM, Casey Schaufler wrote: > On 10/23/2018 11:50 AM, Kees Cook wrote: > >> Did you poke around at my combined series? >> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing > I hope to do that on the plane later today. I had a chance to poke at the combined series and it all seems to work as advertised.
On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 10/23/2018 12:05 PM, Casey Schaufler wrote: >> On 10/23/2018 11:50 AM, Kees Cook wrote: >> >>> Did you poke around at my combined series? >>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing >> I hope to do that on the plane later today. > > I had a chance to poke at the combined series and it > all seems to work as advertised. /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;) -Kees
On 10/24/2018 1:12 PM, Kees Cook wrote: > On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 10/23/2018 12:05 PM, Casey Schaufler wrote: >>> On 10/23/2018 11:50 AM, Kees Cook wrote: >>> >>>> Did you poke around at my combined series? >>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing >>> I hope to do that on the plane later today. >> I had a chance to poke at the combined series and it >> all seems to work as advertised. > /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;) > > -Kees > Now that we have next-general updated I'm porting these forward.
On 11/14/2018 1:04 PM, Casey Schaufler wrote: > On 10/24/2018 1:12 PM, Kees Cook wrote: >> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>> On 10/23/2018 12:05 PM, Casey Schaufler wrote: >>>> On 10/23/2018 11:50 AM, Kees Cook wrote: >>>> >>>>> Did you poke around at my combined series? >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing >>>> I hope to do that on the plane later today. >>> I had a chance to poke at the combined series and it >>> all seems to work as advertised. >> /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;) >> >> -Kees >> > Now that we have next-general updated I'm porting these forward. I have ported Kees' set forward to 4.20-rc2: https://github.com/cschaufler/lsm-stacking.git#after-kees-4.20-rc2 There's one bug fix in ordered_lsm_parse() but otherwise just mechanical. The infrastructure blob management required for TOMOYO, Landlock and SARA is available: https://github.com/cschaufler/lsm-stacking.git#blobs-4.20-rc2 There's nothing new here, although I had to make a few changes to account for Kees' changes in the preceding patches. I will post the patches shortly. The full stacking changes based on this are still in the works. Netfilter has added a whole new use of secmarks and I'm working to make the individual patches smaller for easier review.
v5: - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling - dropped various Reviewed-bys due to rather large refactoring v4: - add Reviewed-bys. - cosmetic tweaks. - New patches to fully centralize LSM "enable" decisions: LSM: Finalize centralized LSM enabling logic apparmor: Remove boot parameter selinux: Remove boot parameter v3: - add CONFIG_LSM_ENABLE and refactor resulting logic v2: - add "lsm.order=" and CONFIG_LSM_ORDER instead of overloading "security=" - reorganize introduction of ordering logic code Overview: This refactors the LSM registration and initialization infrastructure to more centrally support different LSM types for more cleanly supporting the future expansion of LSM stacking via the "blob-sharing" patch series. What was considered a "major" LSM is kept for legacy use of the "security=" boot parameter, and now overlaps with the new class of "exclusive" LSMs for the future blob sharing. The "minor" LSMs become more well defined as a result of the refactoring. Approach: To better show LSMs activation some debug reporting was added (enabled with the "lsm.debug" boot commandline option). I added a WARN() around LSM initialization failures, which appear to have always been silently ignored. (Realistically any LSM init failures would have only been due to catastrophic kernel issues that would render a system unworkable anyway, but it'd be better to expose the problem as early as possible.) Instead of continuing to (somewhat improperly) overload the kernel's initcall system, this changes the LSM infrastructure to store a registration structure (struct lsm_info) table instead, where metadata about each LSM can be recorded (name, flags, order, enable flag, init function). This can be extended in the future to include things like required blob size for the coming "blob sharing" LSMs. The "major" LSMs had to individually negotiate which of them should be enabled. This didn't provide a way to negotiate combinations of other LSMs (as will be needed for "blob sharing" LSMs). This is solved by providing the LSM infrastructure with all the details needed to make the choice (exposing the per-LSM "enabled" flag, if used, the LSM characteristics, and ordering expectations). As a result of the refactoring, the "minor" LSMs are able to remove the open-coded security_add_hooks() calls for "capability", "yama", and "loadpin", and to redefine "integrity" properly as a general LSM. (Note that "integrity" actually defined _no_ hooks, but needs the early initialization). With all LSMs being proessed centrally, it was possible to implement a new boot parameter "lsm=" to provide explicit ordering, which is helpful for the future "blob sharing" LSMs. Matching this is the new CONFIG_LSM, which effectively replaces CONFIG_DEFAULT_SECURITY, as it provides a higher granularity of control. Breakdown of patches: Infrastructure improvements (no logical changes): LSM: Correctly announce start of LSM initialization vmlinux.lds.h: Avoid copy/paste of security_init section LSM: Rename .security_initcall section to .lsm_info LSM: Remove initcall tracing LSM: Convert from initcall to struct lsm_info vmlinux.lds.h: Move LSM_TABLE into INIT_DATA LSM: Convert security_initcall() into DEFINE_LSM() LSM: Record LSM name in struct lsm_info LSM: Provide init debugging infrastructure LSM: Don't ignore initialization failures Split "integrity" out into "ordered initialization" (no logical changes): LSM: Introduce LSM_FLAG_LEGACY_MAJOR LSM: Provide separate ordered initialization Provide centralized LSM enable/disable infrastructure: LoadPin: Rename boot param "enabled" to "enforce" LSM: Plumb visibility into optional "enabled" state LSM: Lift LSM selection out of individual LSMs Provide centralized LSM ordering infrastructure: LSM: Build ordered list of LSMs to initialize LSM: Introduce CONFIG_LSM LSM: Introduce "lsm=" for boottime LSM selection LSM: Tie enabling logic to presence in ordered list Refactor legacy "security=" handling to map to new infrastructure: LSM: Prepare for reorganizing "security=" logic LSM: Refactor "security=" in terms of enable/disable Move major LSMs into ordered initialization: LSM: Separate idea of "major" LSM from "exclusive" LSM apparmor: Remove SECURITY_APPARMOR_BOOTPARAM_VALUE selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE LSM: Add all exclusive LSMs to ordered initialization LSM: Split LSM preparation from initialization Move minor LSMs into ordered initialization: LoadPin: Initialize as ordered LSM Yama: Initialize as ordered LSM LSM: Introduce enum lsm_order capability: Initialize as LSM_ORDER_FIRST -Kees .../admin-guide/kernel-parameters.txt | 6 + arch/arc/kernel/vmlinux.lds.S | 1 - arch/arm/kernel/vmlinux-xip.lds.S | 1 - arch/arm64/kernel/vmlinux.lds.S | 1 - arch/h8300/kernel/vmlinux.lds.S | 1 - arch/microblaze/kernel/vmlinux.lds.S | 2 - arch/powerpc/kernel/vmlinux.lds.S | 2 - arch/um/include/asm/common.lds.S | 2 - arch/xtensa/kernel/vmlinux.lds.S | 1 - include/asm-generic/vmlinux.lds.h | 25 +- include/linux/init.h | 2 - include/linux/lsm_hooks.h | 36 ++- include/linux/module.h | 1 - security/Kconfig | 41 +-- security/apparmor/Kconfig | 16 - security/apparmor/lsm.c | 17 +- security/commoncap.c | 9 +- security/integrity/iint.c | 6 +- security/loadpin/Kconfig | 4 +- security/loadpin/loadpin.c | 29 +- security/security.c | 288 ++++++++++++++---- security/selinux/Kconfig | 15 - security/selinux/hooks.c | 22 +- security/smack/smack_lsm.c | 9 +- security/tomoyo/tomoyo.c | 8 +- security/yama/yama_lsm.c | 8 +- 26 files changed, 343 insertions(+), 210 deletions(-)