Re: recommends for apparmor in newest linux-image-4.13
On Wed, Nov 29, 2017 at 12:03:08AM +0100, Marco d'Itri wrote: On Nov 28, Christoph Hellwig wrote: It's just a bad idea of a security model that implements ad-hoc and mostly path based restrictions instead of an actually verified security model. Using that by default makes it much harder to actually use a real MAC based security model, which not only is required for various security sensitive deployments but also a good idea in general. This may be true, but OTOH nobody cared enough about SELinux to actually make it work out of the box in Debian. By that criteria, it doesn't seem like anyone cares about apparmor either... FWIW, I also think apparmor a bad idea, but it's somehow morphed from "can we make it possible to turn apparmor on" to "let's make RC bugs for stuff that doesn't work with apparmor" without much real buy-in AFAICT. Mike Stone
Re: recommends for apparmor in newest linux-image-4.13
On Nov 28, Christoph Hellwig wrote: > It's just a bad idea of a security model that implements ad-hoc > and mostly path based restrictions instead of an actually verified > security model. Using that by default makes it much harder to actually > use a real MAC based security model, which not only is required for > various security sensitive deployments but also a good idea in general. This may be true, but OTOH nobody cared enough about SELinux to actually make it work out of the box in Debian. So, for the time being I would gladly accept an inferior solution. -- ciao, Marco signature.asc Description: PGP signature
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 03:43:10PM +0100, Lars Wirzenius wrote: > > do you think you could manage to either point the general -devel > reading population to a discussion of why using AppArmor by default is > horrible news, or write that yourself? That would seem to be more > constructive than you just showing up after months of discussion > saying it's horrible news. It's just a bad idea of a security model that implements ad-hoc and mostly path based restrictions instead of an actually verified security model. Using that by default makes it much harder to actually use a real MAC based security model, which not only is required for various security sensitive deployments but also a good idea in general. Last but not least apparmor had various issues where certain distros shipped non-upstream features that later turned out to be incompatible with what went upstream.
Re: recommends for apparmor in newest linux-image-4.13
maximilian attems writes ("Re: recommends for apparmor in newest
linux-image-4.13"):
> On Thu, Nov 23, 2017 at 03:00:49PM +0100, Wouter Verhelst wrote:
> > [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html
> > [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086
> > [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0
>
> This doesn't strike me as a discussion, but looks more like a predetermined
> setup.
The reason it doesn't look very discussion-ish is that no-one replied
to explain why the proposed approach was a bad idea. So there was a
bit of discussion of details, but general agreement. That's how
consensus works.
The tenor of the mails was very good and clearly invited discussion
and dissent. Nevertheless, if you can explain now why it's a bad
idea, please do so.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 03:00:49PM +0100, Wouter Verhelst wrote: > On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote: > > Hi all, > > > > is there any good reason for the recommends of apparmor in the latest > > linux packages? > > This is in response to a discussion that happened on this list. The > thread started in august last year[1], but really picked up speed last > month[2] and this one[3]. > > The idea is that, if no critical issues are found, buster would release > with AppArmor enabled by default. If critical issues are found, however, > I expect the decision will be reversed (or at the least, postponed). > > [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html > [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086 > [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0 > This doesn't strike me as a discussion, but looks more like a predetermined setup.
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 03:01:09PM +0100, Christoph Hellwig wrote: > That's still not an upstream default lsm. Looks like someone in > Debian just decided to make apparmor the default, which is horrible > news :( Hello, Christoph, do you think you could manage to either point the general -devel reading population to a discussion of why using AppArmor by default is horrible news, or write that yourself? That would seem to be more constructive than you just showing up after months of discussion saying it's horrible news. (If you need to, I can lend you my time machine so you can send the explantion last year and we can avoid escalating things to the current stage.) -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 01:59:44PM +, Ben Hutchings wrote: > On Thu, 2017-11-23 at 14:58 +0100, Christoph Hellwig wrote: > > On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote: > > > AppArmor is the default LSM. > > > > There is no such thing as a default LSM in Linux. > > $ grep DEFAULT_SECURITY /boot/config-4.13.0-1-amd64 > # CONFIG_DEFAULT_SECURITY_SELINUX is not set > # CONFIG_DEFAULT_SECURITY_TOMOYO is not set > CONFIG_DEFAULT_SECURITY_APPARMOR=y > # CONFIG_DEFAULT_SECURITY_DAC is not set > CONFIG_DEFAULT_SECURITY="apparmor" That's still not an upstream default lsm. Looks like someone in Debian just decided to make apparmor the default, which is horrible news :(
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote: > AppArmor is the default LSM. There is no such thing as a default LSM in Linux. > > The changelog suggests it was done that systemd units might use it, > > but in that case those systemd units should depend on apparmor. > > They don't depend on AppArmor unless it's enabled. Which is a decision > made in the kernel configuration (potentially overriden by the kernel > comamnd line). So we should not need the recommends.
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote: > Hi all, > > is there any good reason for the recommends of apparmor in the latest > linux packages? This is in response to a discussion that happened on this list. The thread started in august last year[1], but really picked up speed last month[2] and this one[3]. The idea is that, if no critical issues are found, buster would release with AppArmor enabled by default. If critical issues are found, however, I expect the decision will be reversed (or at the least, postponed). [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086 [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0 > apparomor is just one of many security modules, and > a fairly bogus one to start with. The kernel should not recommend it > as it doesn't add at all to the expected kernel functionality. If AppArmor is to become the default, then having it be recommended by the kernel is a proper way of implementing that; it would be pulled in by default, but if you don't want it it's still possible to remove it. (I won't comment on the "fairly bogus one" bit, I'm not that well versed in the specifics of AppArmor vs the other options there) > The changelog suggests it was done that systemd units might use it, > but in that case those systemd units should depend on apparmor. Perhaps the changelog could be clarified then, there are other reasons :-) > And to start with there probably should be a policty that no unit > file shall fail the boot for a missing security module (any of them). Yes, indeed. I haven't seen such a failure; but if you have, then please do file a bug -- that's not supposed to happen. Thanks, -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab signature.asc Description: PGP signature
Re: recommends for apparmor in newest linux-image-4.13
On Thu, 2017-11-23 at 14:58 +0100, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote: > > AppArmor is the default LSM. > > There is no such thing as a default LSM in Linux. $ grep DEFAULT_SECURITY /boot/config-4.13.0-1-amd64 # CONFIG_DEFAULT_SECURITY_SELINUX is not set # CONFIG_DEFAULT_SECURITY_TOMOYO is not set CONFIG_DEFAULT_SECURITY_APPARMOR=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="apparmor" > > > The changelog suggests it was done that systemd units might use it, > > > but in that case those systemd units should depend on apparmor. > > > > They don't depend on AppArmor unless it's enabled. Which is a decision > > made in the kernel configuration (potentially overriden by the kernel > > comamnd line). > > So we should not need the recommends. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Re: recommends for apparmor in newest linux-image-4.13
On Thu, 2017-11-23 at 14:18 +0100, Christoph Hellwig wrote: > Hi all, > > is there any good reason for the recommends of apparmor in the latest > linux packages? apparomor is just one of many security modules, and > a fairly bogus one to start with. The kernel should not recommend it > as it doesn't add at all to the expected kernel functionality. AppArmor is the default LSM. > The changelog suggests it was done that systemd units might use it, > but in that case those systemd units should depend on apparmor. They don't depend on AppArmor unless it's enabled. Which is a decision made in the kernel configuration (potentially overriden by the kernel comamnd line). Ben. > And to start with there probably should be a policty that no unit > file shall fail the boot for a missing security module (any of them). -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
recommends for apparmor in newest linux-image-4.13
Hi all, is there any good reason for the recommends of apparmor in the latest linux packages? apparomor is just one of many security modules, and a fairly bogus one to start with. The kernel should not recommend it as it doesn't add at all to the expected kernel functionality. The changelog suggests it was done that systemd units might use it, but in that case those systemd units should depend on apparmor. And to start with there probably should be a policty that no unit file shall fail the boot for a missing security module (any of them).
