Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]

[intrigeri]

Hi,

intrigeri:
> Cyril Brulebois:
>> intrigeri  (2017-10-25):
>>> I'm working on the last blockers towards starting the experiment I've
>>> proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by
>>> default for a while in testing/sid.

>> Does it make sense to have it installed everywhere, including in
>> chroots, containers, etc., or should it be mainly installed in d-i
>> installed systems?

> It makes sense in any kind of system that runs its own Linux kernel:

Update: the next upload of the linux-image packages will "Recommends:
apparmor"
(https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=sid=bd1e10f8bd85adf182f122417a843bf6ffbac80c)

… so it might be that we don't need "Priority: standard" in the end.

Cheers,
-- 
intrigeri

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Hi,

intrigeri:
> Ben Hutchings:
>> On Mon, 2017-10-23 at 10:06 +0200, intrig...@debian.org wrote:
>>> A. Make AppArmor the default LSM in the kernel
>> [...]
>>> B. Configure bootloaders to enable AppArmor by default
>>>
>>>On https://bugs.debian.org/702030 a nice & flexible solution was
>>>designed; let's call it B.1.
>> [...]
>>>A short-term simpler option would be to drop a file in
>>>/etc/default/grub.d/ [...] Let's call this option B.2.
>> [...]

>>> My personal preference is A > B.1. Ben & others, what do you think?

>> I agree.

> OK. Thanks for the prompt reply!

For the record this was done in src:linux 4.13.10-1 whose changelog
entry reads:

   * security: Enable DEFAULT_SECURITY_APPARMOR

Cheers,
-- 
intrigeri

Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]

[intrigeri]

Hi KiBi!

Cyril Brulebois:
> intrigeri  (2017-10-25):
>> I'm working on the last blockers towards starting the experiment I've
>> proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by
>> default for a while in testing/sid.

> Does it make sense to have it installed everywhere, including in
> chroots, containers, etc., or should it be mainly installed in d-i
> installed systems?

It makes sense in any kind of system that runs its own Linux kernel:
not in chroots & containers (there's WIP upstream for allowing
containers to stack their own AppArmor policy on top of the host's one
but we're not there yet), but definitely in systems installed by d-i
(be it during initial installation or dist-upgrades, see the email
I've just sent to -devel@ about the latter).

>> Enabling AppArmor by default on new installations requires two
>> changes:
>> 
>> 1. enable the LSM in Linux: problem solved, Ben Hutchings is fine with
>>doing this in src:linux
>> 2. install the apparmor package by default.

> It seems it's built on non-Linux ports as well, does it make sense to
> have it installed there? Please poke debian-bsd@ and debian-hurd@ if in
> doubt.

No, it doesn't make sense to install it there; it shouldn't harm
either. So far I've kept src:apparmor building on non-Linux ports in
the hope some portability issues turn out to be real bugs that affect
Linux too, but this never happened. So if it simplifies the problem
let's build the package only on Linux ports.

>> My understanding is that making the apparmor package "Priority:
>> standard" i the way to go. Correct?

> Depends on the first question above.

Replied. Anything else you need from me to answer this question?

> Thanks for checking with us in any cases. :)

No problem, I don't want to cause issues that could easily be
prevented :)

Cheers,
-- 
intrigeri

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

intrigeri:
> But I'm not sure what's the best way to pull the apparmor package:

> 1. on testing/sid upgrades, during the Buster dev cycle: this would
>greatly increase the value of the "enable AppArmor by default for
>a while" experiment;
> 2. during Stretch to Buster upgrades: this seems necessary so every
>user gets the AppArmor benefits, regardless of when they installed
>their system initially.

> I could not find anything better so far than having another package,
> that's already installed by default, add a "Recommends: apparmor" (I'm
> assuming that APT installs newly recommended packages by default on
> upgrade). This feels artificial and rather ugly, but it might be the
> only option. I'll ask more people around.

I've just asked help on debian-devel@ about it.

Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]

[Cyril Brulebois]

Hi'ntrigeri,

intrigeri  (2017-10-25):
> I'm working on the last blockers towards starting the experiment I've
> proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by
> default for a while in testing/sid.

Does it make sense to have it installed everywhere, including in
chroots, containers, etc., or should it be mainly installed in d-i
installed systems?

> Enabling AppArmor by default on new installations requires two
> changes:
> 
> 1. enable the LSM in Linux: problem solved, Ben Hutchings is fine with
>doing this in src:linux
> 2. install the apparmor package by default.

It seems it's built on non-Linux ports as well, does it make sense to
have it installed there? Please poke debian-bsd@ and debian-hurd@ if in
doubt.

> This email is about (2).
> 
> Priority: standard?
> ===
> 
> My understanding is that making the apparmor package "Priority:
> standard" i the way to go. Correct?

Depends on the first question above.

> The package itself has "Installed-Size: 1803 kB".
> 
> I've trimmed the dependencies of this package a bit (just uploaded
> 2.11.1-2 as a result) so it seems to be an OK thing to do to me.
> The dependencies are now:
> 
>   libc6 (>= 2.17),
>   debconf (>= 0.5) | debconf-2.0,
>   python3:any,
>   lsb-base (>= 3.0-6),
>   debconf
> 
> … i.e. only stuff that's installed by default already anyway.
> 
> Would you folks have any problem with this change?
> 
> Once this is done I'll coordinate with Ben wrt. pushing the other big
> red button i.e. (1) once the other blockers have been resolved.

Thanks for checking with us in any cases. :)


KiBi.


signature.asc
Description: PGP signature

Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]

[intrigeri]

Hi debian-boot@!

tl;dr: can I make the apparmor package Priority: standard?

Context
===

I'm working on the last blockers towards starting the experiment I've
proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by
default for a while in testing/sid.

Enabling AppArmor by default on new installations requires two
changes:

1. enable the LSM in Linux: problem solved, Ben Hutchings is fine with
   doing this in src:linux
2. install the apparmor package by default.

This email is about (2).

Priority: standard?
===

My understanding is that making the apparmor package "Priority:
standard" i the way to go. Correct?

The package itself has "Installed-Size: 1803 kB".

I've trimmed the dependencies of this package a bit (just uploaded
2.11.1-2 as a result) so it seems to be an OK thing to do to me.
The dependencies are now:

  libc6 (>= 2.17),
  debconf (>= 0.5) | debconf-2.0,
  python3:any,
  lsb-base (>= 3.0-6),
  debconf

… i.e. only stuff that's installed by default already anyway.

Would you folks have any problem with this change?

Once this is done I'll coordinate with Ben wrt. pushing the other big
red button i.e. (1) once the other blockers have been resolved.

Cheers,
-- 
intrigeri

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Hi,

intrigeri:
> Next step: figure out how to actually pull AppArmor utilities & policy
> by default (enabling the LSM is not very useful if we don't install
> those too).

For new installations, making the apparmor package "Priority:
standard" seems to be the way to go. I've trimmed its dependencies
a bit (to be uploaded as 2.11.1-2) so it seems to be an OK thing to
do. I'll ask on -devel@ if there's a problem with that, once I have
something to propose for the following problem.

But I'm not sure what's the best way to pull the apparmor package:

1. on testing/sid upgrades, during the Buster dev cycle: this would
   greatly increase the value of the "enable AppArmor by default for
   a while" experiment;
2. during Stretch to Buster upgrades: this seems necessary so every
   user gets the AppArmor benefits, regardless of when they installed
   their system initially.

I could not find anything better so far than having another package,
that's already installed by default, add a "Recommends: apparmor" (I'm
assuming that APT installs newly recommended packages by default on
upgrade). This feels artificial and rather ugly, but it might be the
only option. I'll ask more people around.

FTR Ubuntu installs the apparmor package by default using something
that has a very similar definition to "Priority: standard":
http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.artful/view/head:/standard#L73
(the parenthesis around the package name means it'll be a Recommends,
not a Depends, so it gets installed by default but the user may choose
to remove it). But we don't use germinate so it's not useful for
Debian. They don't install apparmor-utils by default.

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Hi,

Ben Hutchings:
> On Mon, 2017-10-23 at 10:06 +0200, intrig...@debian.org wrote:
>> A. Make AppArmor the default LSM in the kernel
> [...]
>> B. Configure bootloaders to enable AppArmor by default
>>
>>On https://bugs.debian.org/702030 a nice & flexible solution was
>>designed; let's call it B.1.
> [...]
>>A short-term simpler option would be to drop a file in
>>/etc/default/grub.d/ [...] Let's call this option B.2.
> [...]

>> My personal preference is A > B.1. Ben & others, what do you think?

> I agree.

OK. Thanks for the prompt reply!

> We really should have a common way to append things to the kernel
> command line, which would allow a more general B.2, but this shouldn't
> have to wait for that.

ACK.

So we're done wrt. LSM activation.

Next step: figure out how to actually pull AppArmor utilities & policy
by default (enabling the LSM is not very useful if we don't install
those too). I think I can propose something about it this week.

Cheers,
-- 
intrigeri

Bug#879590: apparmor: Decide how we enable AppArmor by default

[Ben Hutchings]

On Mon, 2017-10-23 at 10:06 +0200, intrig...@debian.org wrote:
> Package: apparmor
> Version: 2.11.0-11
> Severity: normal
> X-Debbugs-Cc: Ben Hutchings 
> 
> Hi,
> 
> we're discussing whether to enable AppArmor by default during the
> Buster cycle, but we have no actual plan wrt. how to do it.
> There are several options:
> 
> A. Make AppArmor the default LSM in the kernel
> 
>i.e. set CONFIG_DEFAULT_SECURITY="apparmor"
>and CONFIG_DEFAULT_SECURITY_APPARMOR=y.
[...]
> B. Configure bootloaders to enable AppArmor by default
>
>On https://bugs.debian.org/702030 a nice & flexible solution was
>designed; let's call it B.1.
[...]
>A short-term simpler option would be to drop a file in
>/etc/default/grub.d/ [...] Let's call this option B.2.
[...]
> C. Anything else?
> 
> My personal preference is A > B.1. Ben & others, what do you think?

I agree.

We really should have a common way to append things to the kernel
command line, which would allow a more general B.2, but this shouldn't
have to wait for that.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg



signature.asc
Description: This is a digitally signed message part

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Package: apparmor
Version: 2.11.0-11
Severity: normal
X-Debbugs-Cc: Ben Hutchings 

Hi,

we're discussing whether to enable AppArmor by default during the
Buster cycle, but we have no actual plan wrt. how to do it.
There are several options:

A. Make AppArmor the default LSM in the kernel

   i.e. set CONFIG_DEFAULT_SECURITY="apparmor"
   and CONFIG_DEFAULT_SECURITY_APPARMOR=y.

   That's what Ubuntu and openSUSE have been doing for ages.
   It's easy, straightforward, and compatible with how
   [selinux-activate] currently works, i.e. if a user has manually
   enabled SELinux, it'll remain the default and AppArmor will remain
   disabled. Passing security= on the kernel command line is enough to
   disable AppArmor.

B. Configure bootloaders to enable AppArmor by default

   On https://bugs.debian.org/702030 a nice & flexible solution was
   designed; let's call it B.1. However it requires quite some work in
   a number of packages, so IMO it does not fit the timeline of the
   proposed experiment (while Buster == testing).

   A short-term simpler option would be to drop a file in
   /etc/default/grub.d/ that injects what we want into
   GRUB_CMDLINE_LINUX unless another LSM is already enabled in there
   (selinux-activate directly modifies /etc/default/grub). Let's call
   this option B.2.

   The major disadvantage of this option is that it only supports GRUB
   (just like selinux-activate by the way). I haven't looked at how
   much work would be required to achieve the same result with the
   other major bootloaders Debian supports.

C. Anything else?

My personal preference is A > B.1. Ben & others, what do you think?

[selinux-activate] 
https://sources.debian.net/src/selinux-basics/0.5.6/selinux-activate/

Cheers,
-- 
intrigeri