Debian Bug report logs - #702030
Please automatically enable AppArmor when the userspace tools are installed

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: adrelanos <adrelanos@riseup.net>

To: submit@bugs.debian.org

Subject: Please automatically enable AppArmor when the userspace tools are installed

Date: Fri, 01 Mar 2013 21:20:32 +0000

Package: apparmor
Severity: wishlist

Please add the required kernel parameter "apparmor=1 security=apparmor"
automatically if apparmor is installed.

It has been discussed in bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701714 and this bug
also contains some ideas/discussion on how it could be implemented.

Message #10 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Patrick Schleizer <adrelanos@riseup.net>

To: 702030@bugs.debian.org

Subject: ideas for implementation

Date: Mon, 09 Jun 2014 14:20:15 +0000

Dear AppArmor Maintainers,

I have two ideas on how to implement this and might eventually even be
able to submit patches for this.

1) A clean solution, that can be implemented in the grub-common package:

In /etc/grub.d/10_linux it could be attempted to run aa-status and if it
exits 0, the following line

   linux	${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}

could be extended with

   apparmor=1 security=apparmor

i.e. have some $maybe_apparmor before ${args}.

2) A less clean solution that can be implemented in the apparmor package:

Create a script /etc/grub.d/39_apparmor, that searches
/boot/grub/grub.cfg for

    menuentry 'Debian GNU/Linux, with Linux *' --class debian

    linux	/boot/vmlinuz-* root=UUID=* ro

and injects

   apparmor=1 security=apparmor

at the end.

Please tell me what you think.

Cheers,
Patrick

Message #15 received at 702030@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Patrick Schleizer <adrelanos@riseup.net>

Cc: 702030@bugs.debian.org

Subject: Re: Bug#702030: ideas for implementation

Date: Sun, 15 Jun 2014 11:54:44 +0200

Hi Patrick and anyone listening on the line,

Patrick Schleizer wrote (09 Jun 2014 14:20:15 GMT) :
> I have two ideas on how to implement this and might eventually even be
> able to submit patches for this.

I like reading this. Thanks for working on it! :)

> 1) A clean solution, that can be implemented in the grub-common package:

> In /etc/grub.d/10_linux it could be attempted to run aa-status and if it
> exits 0, the following line
> [...]
> could be extended with
>    apparmor=1 security=apparmor

It looks like the user story you have in mind to enable AppArmor
"permanently" would then be:

  * in GRUB menu, manually enable AppArmor
  * boot Debian
  * run update-grub
  * now AppArmor is enabled by default

Right?

My main problem with that it turns the current (possibly temporary,
e.g. for debugging) system state into the permanent one. This seems
potentially very confusing to users.

E.g. if I boot Debian while manually disabling AppArmor for some
reason, and then e.g. upgrade the Linux kernel, then update-grub is
automatically run, and AppArmor will be disabled for the following
boot. That's not what I would expect to happen. Same for the opposite
story, if I decide to try AppArmor once and run "apt upgrade", I don't
expect my one-shot decision to be silently turned into
a permanent one.

> 2) A less clean solution that can be implemented in the apparmor package:

> Create a script /etc/grub.d/39_apparmor, that searches
> /boot/grub/grub.cfg for [...]

I don't think we want to go into that: parsing and patching grub.cfg
in a safe and robust way is hard. Maybe the Augeas lens shipped in
augeas-lenses is good enough to do so *now*, but it's hard to be sure
that it will always remain that good.

Anyway, I eventually took time to look at how update-grub works, and
I think I've found a clean solution to this problem: grub-mkconfig
sources ${sysconfdir}/default/grub.d/*.cfg after sourcing
${sysconfdir}/default/grub, so all we have to do is ship
/etc/default/grub.d/apparmor.cfg, that would inject what we want into
GRUB_CMDLINE_LINUX. May you please test this?

Still, there's a potential issue with grounding the decision on
whether the apparmor package is installed: I've seen packages
gratuitously depend on apparmor (see e.g. #751452), merely because
they're shipping a profile, so this could cause more unexpected
behavior: I don't think we want to turn AppArmor on without at least
*one* conscious decision from the user, at least in the current state
of things. Maybe a Lintian warning raised when a package depends on
the apparmor one, and it's not on some whitelist of packages that
really need to depend on it, would be enough to catch most of these
problems, though.

What do you think?

Cheers,
-- 
intrigeri

Message #20 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Patrick Schleizer <adrelanos@riseup.net>

To: intrigeri <intrigeri@debian.org>

Cc: 702030@bugs.debian.org

Subject: Re: Bug#702030: ideas for implementation

Date: Fri, 20 Jun 2014 19:32:47 +0000

Hi!

intrigeri:
> Patrick Schleizer wrote (09 Jun 2014 14:20:15 GMT) :
>> I have two ideas on how to implement this and might eventually even be
>> able to submit patches for this.
> 
> I like reading this. Thanks for working on it! :)
> 
>> 1) A clean solution, that can be implemented in the grub-common package:
> 
>> In /etc/grub.d/10_linux it could be attempted to run aa-status and if it
>> exits 0, the following line
>> [...]
>> could be extended with
>>    apparmor=1 security=apparmor
> 
> It looks like the user story you have in mind to enable AppArmor
> "permanently" would then be:

>   * in GRUB menu, manually enable AppArmor

Absolutely not.

>   * boot Debian
>   * run update-grub
>   * now AppArmor is enabled by default
> 
> Right?

[Since your solution is simpler and better, and I had this already
written, this is just FYI maybe.]

No, I was proposing a patch for /etc/grub.d/10_linux in the grub-common.

Currently:

  message="$(gettext_printf "Loading Linux %s ..." ${version})"
  cat << EOF
	echo	'$message'
	linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion}
ro ${args}
EOF

Proposed:

I had something in mind like this. Untested. Needs more thought. Some
useless code just to express the idea.

  which aa-status >/dev/null 2>&1
  if [ $? = 0 ]; then
    aa-status >/dev/null 2>&1
      if [ $? = 0 ]; then
      # AppArmor enabled, let's keep it.
      maybe_apparmor="apparmor=1 security=apparmor"
    fi
    if [ $? = 2 ]; then
      # AppArmor disabled by user with "/etc/init.d/apparmor teardown".
      # Leave it disabled.
      maybe_apparmor=""
    fi
    if [ $? = 3 ]; then
      # AppArmor not enabled in kernel.
      # Let's enable it.
      maybe_apparmor="apparmor=1 security=apparmor"
    fi
  else
    maybe_apparmor=""
  fi
  message="$(gettext_printf "Loading Linux %s ..." ${version})"
  cat << EOF
	echo	'$message'
	linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion}
ro ${maybe_apparmor} ${args}

Imagined like this:
1) sudo apt-get install apparmor
2) apparmor automatically gets enabled. Seems to be the Debian way. If
you install any daemons, most are automatically started.
3) /etc/grub.d/10_linux does the magic to enable apparmor in grub.cfg,
so it gets enabled on next reboot.
4) Maybe users who want to disable apparmor while leaving the apparmor
package installed could use "apparmor=0 security=" in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT.
5) Maybe we can detect if users did run "/etc/init.d/apparmor teardown"
and not enable apparmor on next update-grub as well. Maybe
/etc/init.d/apparmor should run update-grub.

> My main problem with that it turns the current (possibly temporary,
> e.g. for debugging) system state into the permanent one. This seems
> potentially very confusing to users.
> 
> E.g. if I boot Debian while manually disabling AppArmor for some
> reason, and then e.g. upgrade the Linux kernel, then update-grub is
> automatically run, and AppArmor will be disabled for the following
> boot. That's not what I would expect to happen. Same for the opposite
> story, if I decide to try AppArmor once and run "apt upgrade", I don't
> expect my one-shot decision to be silently turned into
> a permanent one.

I am not sure I understand.

>> 2) A less clean solution that can be implemented in the apparmor package:
> 
>> Create a script /etc/grub.d/39_apparmor, that searches
>> /boot/grub/grub.cfg for [...]
> 
> I don't think we want to go into that: parsing and patching grub.cfg
> in a safe and robust way is hard. Maybe the Augeas lens shipped in
> augeas-lenses is good enough to do so *now*, but it's hard to be sure
> that it will always remain that good.

Valid point.

> Anyway, I eventually took time to look at how update-grub works, and
> I think I've found a clean solution to this problem: grub-mkconfig
> sources ${sysconfdir}/default/grub.d/*.cfg after sourcing
> ${sysconfdir}/default/grub, so all we have to do is ship
> /etc/default/grub.d/apparmor.cfg, that would inject what we want into
> GRUB_CMDLINE_LINUX. May you please test this?

Requires Debian Jessie.

It works! Great solution!

Shouldn't we use a number in front of the config file such as
/etc/default/grub.d/10_apparmor.cfg, to get a useful order and to make
it simpler for users to overrule it?

Could you add the /etc/default/grub.d/10_apparmor.cfg config file to the
apparmor package then please?

> I don't think we want to turn AppArmor on without at least
> *one* conscious decision from the user,

I view "sudo apt-get install apparmor" as my conscious decision and
would expect AppArmor getting enabled. As far I understand the debian
way is install a package = enable it's functionality (such as when you
install a package containing a daemon [ex: apache2] it usually gets
automatically started by default.

> I've seen packages
> gratuitously depend on apparmor (see e.g. #751452), merely because
> they're shipping a profile

Agreed with your bug report. Sounds like an easy to fix, grave bug
[making the package unfit for release] [but the experienced DD's are
better qualified to decide on that].

> Maybe a Lintian warning raised when a package depends on
> the apparmor one, and it's not on some whitelist of packages that
> really need to depend on it, would be enough to catch most of these
> problems, though.

Good idea. I don't understand the need for a whitelist, though. That's
what lintian overrides are for?

Cheers,
Patrick

Message #25 received at 702030@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Patrick Schleizer <adrelanos@riseup.net>

Cc: 702030@bugs.debian.org

Subject: Re: Bug#702030: ideas for implementation

Date: Sat, 21 Jun 2014 09:20:20 +0200

Hi,

Patrick Schleizer wrote (20 Jun 2014 19:32:47 GMT) :
> intrigeri:
>> Patrick Schleizer wrote (09 Jun 2014 14:20:15 GMT) :
>>> 1) A clean solution, that can be implemented in the grub-common package:
>> 
>>> In /etc/grub.d/10_linux it could be attempted to run aa-status and if it
>>> exits 0, the following line
>>> [...]
>>> could be extended with
>>>    apparmor=1 security=apparmor
> [...]
>     if [ $? = 3 ]; then
>       # AppArmor not enabled in kernel.
>       # Let's enable it.
>       maybe_apparmor="apparmor=1 security=apparmor"
>     fi

Ah, OK. That's the part that was not obvious to me in your initial
email. Thanks for clarifying. Anyway, let's forget that solution and
work on the other :)

>> Anyway, I eventually took time to look at how update-grub works, and
>> I think I've found a clean solution to this problem: grub-mkconfig
>> sources ${sysconfdir}/default/grub.d/*.cfg after sourcing
>> ${sysconfdir}/default/grub, so all we have to do is ship
>> /etc/default/grub.d/apparmor.cfg, that would inject what we want into
>> GRUB_CMDLINE_LINUX. May you please test this?

> Requires Debian Jessie.

> It works! Great solution!

Thanks for trying it!

> Shouldn't we use a number in front of the config file such as
> /etc/default/grub.d/10_apparmor.cfg, to get a useful order and to make
> it simpler for users to overrule it?

Yes, ordering requires more thought, and a survey of how other
packages that ship snippets into /etc/default/grub.d/ do. Are you up
to it?

> Could you add the /etc/default/grub.d/10_apparmor.cfg config file to the
> apparmor package then please?

Once someone has thought through the ordering thing, and the Lintian
warning is implemented, I'd personally be happy to provide a patch
against the apparmor package that implements this.

>> I don't think we want to turn AppArmor on without at least
>> *one* conscious decision from the user,

> I view "sudo apt-get install apparmor" as my conscious decision and
> would expect AppArmor getting enabled.

I tend to agree, but that's valid if, and only if, no package
gratuitously depend on the apparmor package, which we need to guard
against first.

>> Maybe a Lintian warning raised when a package depends on
>> the apparmor one, and it's not on some whitelist of packages that
>> really need to depend on it, would be enough to catch most of these
>> problems, though.

> Good idea.

Are you interested in working on this? At least filing a wishlist bug
against Lintian, describing the need, and marking #702030 as blocked
by that other bug would be a good start.

> I don't understand the need for a whitelist, though. That's
> what lintian overrides are for?

I would find it inelegant to add such an override in
apparmor-{utils,profiles,profiles-extra}. But probably that's merely
personal taste, and the Lintian maintainers might feel differently
about it.

Looking forward to see you take the next steps :)

Cheers,
-- 
intrigeri

Message #30 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Patrick Schleizer <adrelanos@riseup.net>

To: intrigeri <intrigeri@debian.org>

Cc: 702030@bugs.debian.org

Subject: Re: Bug#702030: ideas for implementation

Date: Sun, 13 Jul 2014 18:45:42 +0000

Hi!

intrigeri:
>> Shouldn't we use a number in front of the config file such as
>> /etc/default/grub.d/10_apparmor.cfg, to get a useful order and to make
>> it simpler for users to overrule it?
> 
> Yes, ordering requires more thought, and a survey of how other
> packages that ship snippets into /etc/default/grub.d/ do. Are you up
> to it?

Yes.

search engine:
site:debian.org "/etc/default/grub.d"

packages content search:
https://packages.debian.org/search?searchon=contents&keywords=grub.d&mode=filename&suite=unstable&arch=any

Looks like we're the first ones to ship a /etc/default/grub.d snippet. I
guess the arbitrarily chosen /etc/default/grub.d/10_apparmor.cfg is
fine. It allows others to easily hook into it earlier or later.

If you wish I can start a discussion on the Debian grub maintainers
mailing list.

>>> Maybe a Lintian warning raised when a package depends on
>>> the apparmor one, and it's not on some whitelist of packages that
>>> really need to depend on it, would be enough to catch most of these
>>> problems, though.
> 
>> Good idea.
> 
> Are you interested in working on this? At least filing a wishlist bug
> against Lintian, describing the need, and marking #702030 as blocked
> by that other bug would be a good start.

Done:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754730

Cheers,
Patrick

Message #35 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Patrick Schleizer <adrelanos@riseup.net>, 754744@bugs.debian.org

Cc: 702030@bugs.debian.org

Subject: Re: Bug#754744: forbid most packages to depend on or recommend apparmor

Date: Sun, 13 Jul 2014 22:44:44 -0700

[Message part 1 (text/plain, inline)]

On Sun, Jul 13, 2014 at 11:02:46PM +0000, Patrick Schleizer wrote:
> Package: debian-policy
> Severity: wishlist

> Suggested policy addition:

> Do not depend on or recommend the apparmor package

> Packages must neither depend on nor recommend apparmor, because it would
> not only enable AppArmor for this package, but for any packages shipping
> an AppArmor profile, which might have unwanted effects. Enabling
> AppArmor should require at least one conscious decision by the user.

> If you are shipping an AppArmor profile, add apparmor to Suggests.

> apparmor-{utils,profiles,profiles-extra} and other packages where this
> is useful are exceptions.

> Reason:

> Before we can automatically enable AppArmor when the userspace tools are
> installed, AppArmor maintainer intrigeri said, we must make sure, that
> no packages depend on AppArmor, so AppArmor does not get installed even
> though the user does not wish this. [1]

Why should apparmor be automatically enabled when the userspace tools are
installed?  AFAIK this is inconsistent with how selinux is handled, which is
only enabled via an explicit boot option.  Shouldn't we handle our LSMs
symmetrically?

(Also, what happens if someone has already enabled selinux, then installs
this apparmor package which is intended to automatically enable apparmor?)

Regardless, I don't think this rises to the level of something that needs
to be documented in policy, at least at this point.  It seems to me that
this should be dealt with by convention among the cooperating group of
packages, with hints from lintian, and doesn't require a statement in policy
itself.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 702030@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 702030@bugs.debian.org, Patrick Schleizer <adrelanos@riseup.net>, 754744@bugs.debian.org, selinux-devel@lists.alioth.debian.org

Subject: Re: Bug#702030: Bug#754744: forbid most packages to depend on or recommend apparmor

Date: Mon, 14 Jul 2014 19:13:29 +0200

Hi,

[adding the SELinux team into the loop]

Steve Langasek wrote (14 Jul 2014 05:44:44 GMT) :
> Why should apparmor be automatically enabled when the userspace tools are
> installed?

Usability: the idea is to lower the barrier for using AppArmor on
Debian. Learning how to install a package is one thing, learning how
to edit /etc/default/grub without any mistake is another. Patrick and
I want to make AppArmor available to the category of users who can
learn how to do the former, but won't learn how to perform the latter
any time soon.

Also, it would make things easier for derivatives to enable AppArmor
without messing with conffiles, and without patching the kernel to
enable it their preferred LSM by default.

> AFAIK this is inconsistent with how selinux is handled, which is
> only enabled via an explicit boot option.

I was not aware of that, thanks for pointing it out.

@SELinux maintainers: is this behavior on purpose, or is it due to the
historical lack of a facility (recently added by the
/etc/default/grub.d support) to easily have a package append arguments
to the kernel command-line?

> Shouldn't we handle our LSMs symmetrically?

Indeed, I think we should. I see several ways of keeping things
consistent while reaching the aforementioned AppArmor usability goal:

a) Having the SELinux equivalent of the apparmor package enable it by
   default too (and then, we'll need conflicts); I've no idea if this
   is feasible; one would need to look at the SELinux packages and
   their chain of reverse-dependencies.

b) Implementing the behavior proposed by Patrick via a dedicated
   apparmor-$something configuration package. ftp-masters likely won't
   be happy with it (understandably), unless we demonstrate it's the
   best available solution to reach a sensible goal. The SELinux team
   is then free to create a corresponding package.

c) A new package whose job is to select and enable a LSM (or none).
   Likely "none" would be the default for now. It's tempting to take
   benefit from debconf here.

d) An apparmor-activate command, very similar to selinux-activate
   (from the selinux-basics package). The resulting user experience
   would be less friendly than "just install the apparmor package",
   but perhaps that's acceptable for now.

Other ideas?

SELinux maintainers, any thoughts on this? I've no idea what's the
current situation wrt. SELinux policies in Debian — are they in
a shape that warrants thinking of usability matters for the target
userbase described above, or do potential users anyway have to play
with a terminal and text editor as root? In other words, should we
work on a shared solution to this problem, or should the AppArmor
folks do their bit on their side, merely being careful not to break
the SELinux usecases?

> (Also, what happens if someone has already enabled selinux, then installs
> this apparmor package which is intended to automatically enable apparmor?)

The *last* LSM activated on the kernel command-line is the one that's
enabled in practice (tested both ways). So, installing a apparmor
package, that automatically enables this LSM, would override the
previous manual enabling of SELinux. The reciprocal applies when
running selinux-activate (which is arguably a more explicit choice
made by the administrator than installing the apparmor package).

IMO, both should first check if another LSM is enabled.

> Regardless, I don't think this rises to the level of something that needs
> to be documented in policy, at least at this point.

Full ACK, we're not there yet. I suggest we drop 754744@ from the Cc
list on next reply.

Cheers,
-- 
intrigeri

Message #47 received at 702030@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Patrick Schleizer <adrelanos@riseup.net>

Cc: 702030@bugs.debian.org

Subject: Re: Bug#702030: ideas for implementation

Date: Tue, 15 Jul 2014 20:03:10 +0200

Hi,

Patrick Schleizer wrote (13 Jul 2014 18:45:42 GMT) :
> Looks like we're the first ones to ship a /etc/default/grub.d snippet. I
> guess the arbitrarily chosen /etc/default/grub.d/10_apparmor.cfg is
> fine. It allows others to easily hook into it earlier or later.

I suggest 50_apparmor.cfg, that leaves even more room before, and
enough after.

Cheers,
-- 
intrigeri

Message #52 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Patrick Schleizer <adrelanos@riseup.net>

To: intrigeri <intrigeri@debian.org>

Cc: 702030@bugs.debian.org

Subject: Re: Bug#702030: ideas for implementation

Date: Tue, 15 Jul 2014 18:05:33 +0000

intrigeri:
> Hi,
> 
> Patrick Schleizer wrote (13 Jul 2014 18:45:42 GMT) :
>> Looks like we're the first ones to ship a /etc/default/grub.d snippet. I
>> guess the arbitrarily chosen /etc/default/grub.d/10_apparmor.cfg is
>> fine. It allows others to easily hook into it earlier or later.
> 
> I suggest 50_apparmor.cfg, that leaves even more room before, and
> enough after.

This is more a question of artistic freedom. Fine with me either way. :)

Message #57 received at 702030@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: selinux-devel@lists.alioth.debian.org

Cc: Steve Langasek <vorlon@debian.org>, 702030@bugs.debian.org, Patrick Schleizer <adrelanos@riseup.net>

Subject: Re: forbid most packages to depend on or recommend apparmor

Date: Thu, 28 Aug 2014 17:50:19 -0700

Hi SELinux maintainers,

here's a friendly ping regarding what follows, as I think we're
currently blocked by lack of input from your side. Oh, and if any of
you is in Portland currently, I'd be delighted to meet and discuss
this in person :)

intrigeri wrote (14 Jul 2014 17:13:29 GMT) :
> Steve Langasek wrote (14 Jul 2014 05:44:44 GMT) :
>> Why should apparmor be automatically enabled when the userspace tools are
>> installed?

> Usability: the idea is to lower the barrier for using AppArmor on
> Debian. Learning how to install a package is one thing, learning how
> to edit /etc/default/grub without any mistake is another. Patrick and
> I want to make AppArmor available to the category of users who can
> learn how to do the former, but won't learn how to perform the latter
> any time soon.

> Also, it would make things easier for derivatives to enable AppArmor
> without messing with conffiles, and without patching the kernel to
> enable it their preferred LSM by default.

>> AFAIK this is inconsistent with how selinux is handled, which is
>> only enabled via an explicit boot option.

> I was not aware of that, thanks for pointing it out.

> @SELinux maintainers: is this behavior on purpose, or is it due to the
> historical lack of a facility (recently added by the
> /etc/default/grub.d support) to easily have a package append arguments
> to the kernel command-line?

>> Shouldn't we handle our LSMs symmetrically?

> Indeed, I think we should. I see several ways of keeping things
> consistent while reaching the aforementioned AppArmor usability goal:

> a) Having the SELinux equivalent of the apparmor package enable it by
>    default too (and then, we'll need conflicts); I've no idea if this
>    is feasible; one would need to look at the SELinux packages and
>    their chain of reverse-dependencies.

> b) Implementing the behavior proposed by Patrick via a dedicated
>    apparmor-$something configuration package. ftp-masters likely won't
>    be happy with it (understandably), unless we demonstrate it's the
>    best available solution to reach a sensible goal. The SELinux team
>    is then free to create a corresponding package.

> c) A new package whose job is to select and enable a LSM (or none).
>    Likely "none" would be the default for now. It's tempting to take
>    benefit from debconf here.

> d) An apparmor-activate command, very similar to selinux-activate
>    (from the selinux-basics package). The resulting user experience
>    would be less friendly than "just install the apparmor package",
>    but perhaps that's acceptable for now.

> Other ideas?

> SELinux maintainers, any thoughts on this? I've no idea what's the
> current situation wrt. SELinux policies in Debian — are they in
> a shape that warrants thinking of usability matters for the target
> userbase described above, or do potential users anyway have to play
> with a terminal and text editor as root? In other words, should we
> work on a shared solution to this problem, or should the AppArmor
> folks do their bit on their side, merely being careful not to break
> the SELinux usecases?

>> (Also, what happens if someone has already enabled selinux, then installs
>> this apparmor package which is intended to automatically enable apparmor?)

> The *last* LSM activated on the kernel command-line is the one that's
> enabled in practice (tested both ways). So, installing a apparmor
> package, that automatically enables this LSM, would override the
> previous manual enabling of SELinux. The reciprocal applies when
> running selinux-activate (which is arguably a more explicit choice
> made by the administrator than installing the apparmor package).

> IMO, both should first check if another LSM is enabled.

>> Regardless, I don't think this rises to the level of something that needs
>> to be documented in policy, at least at this point.

> Full ACK, we're not there yet. I suggest we drop 754744@ from the Cc
> list on next reply.

> Cheers,

--
intrigeri

Message #62 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Mika Pflüger <debian@mikapflueger.de>

To: intrigeri <intrigeri@debian.org>

Cc: selinux-devel@lists.alioth.debian.org, Patrick Schleizer <adrelanos@riseup.net>, 702030@bugs.debian.org, Steve Langasek <vorlon@debian.org>

Subject: Re: [DSE-Dev] forbid most packages to depend on or recommend apparmor

Date: Fri, 29 Aug 2014 13:29:32 +0200

[Message part 1 (text/plain, inline)]

Hi,

I certainly can't speak for the whole team, but can offer my thoughts
about the situation of SELinux at the moment.

intrigeri <intrigeri@debian.org> wrote:
> >> AFAIK this is inconsistent with how selinux is handled, which is
> >> only enabled via an explicit boot option.
> 
> > I was not aware of that, thanks for pointing it out.
> 
> > @SELinux maintainers: is this behavior on purpose, or is it due to
> > the historical lack of a facility (recently added by the
> > /etc/default/grub.d support) to easily have a package append
> > arguments to the kernel command-line?

I think both. Installing the default SELinux policy and enabling it
routinely breaks all kinds of stuff (avahi-things, booting with
systemd, obtaining IP addresses via dhcp, hotplugging of network
interfaces etc. just to name some things that popped up in testing or
stable during the last year), especially things not usually tested on
servers run by the more security-aware part of the linux admin
population. So for the regular user (unfortunately), enabling selinux
simply by installing the policy package would certainly feel a lot like
a grave bug ("breaks unrelated software").
> 
> >> Shouldn't we handle our LSMs symmetrically?
> 
> > Indeed, I think we should. I see several ways of keeping things
> > consistent while reaching the aforementioned AppArmor usability
> > goal:
> 
> > a) Having the SELinux equivalent of the apparmor package enable it
> > by default too (and then, we'll need conflicts); I've no idea if
> > this is feasible; one would need to look at the SELinux packages and
> >    their chain of reverse-dependencies.

However, I think this could be pretty reasonable, given
1) it would be e.g. a "selinux" binary package doing this, not the
library or selinux-basics/utils package. This binary package does not
exist at the moment, but could be created.
2) it would ask via debconf before enabling.
> 
> > b) Implementing the behavior proposed by Patrick via a dedicated
> >    apparmor-$something configuration package. ftp-masters likely
> > won't be happy with it (understandably), unless we demonstrate it's
> > the best available solution to reach a sensible goal. The SELinux
> > team is then free to create a corresponding package.

This is basically a) for selinux, as there is no "standard selinux
package".
> 
> > c) A new package whose job is to select and enable a LSM (or none).
> >    Likely "none" would be the default for now. It's tempting to take
> >    benefit from debconf here.
> 
> > d) An apparmor-activate command, very similar to selinux-activate
> >    (from the selinux-basics package). The resulting user experience
> >    would be less friendly than "just install the apparmor package",
> >    but perhaps that's acceptable for now.
> 
> > Other ideas?
> 
> > SELinux maintainers, any thoughts on this? I've no idea what's the
> > current situation wrt. SELinux policies in Debian — are they in
> > a shape that warrants thinking of usability matters for the target
> > userbase described above, or do potential users anyway have to play
> > with a terminal and text editor as root? In other words, should we
> > work on a shared solution to this problem, or should the AppArmor
> > folks do their bit on their side, merely being careful not to break
> > the SELinux usecases?

For the users we are currently targetting, selinux-activate is
adequate, but a debconf question would certainly be easier. We are
(slowly) working on getting better user experience, but yes, people
still have to play with a terminal as root for jessie, I'm afraid.
> 
> >> (Also, what happens if someone has already enabled selinux, then
> >> installs this apparmor package which is intended to automatically
> >> enable apparmor?)
> 
> > The *last* LSM activated on the kernel command-line is the one
> > that's enabled in practice (tested both ways). So, installing a
> > apparmor package, that automatically enables this LSM, would
> > override the previous manual enabling of SELinux. The reciprocal
> > applies when running selinux-activate (which is arguably a more
> > explicit choice made by the administrator than installing the
> > apparmor package).
> 
> > IMO, both should first check if another LSM is enabled.

That sounds like a good idea. It would be nice to have some kind of
standard way to tell if any other LSM is enabled, otherwise we all have
to maintain some 
selinuxenabled | $apparmorenabled | $whateverelseenabled
shell snippets on our own.

Cheers,

Mika

-- 

[signature.asc (application/pgp-signature, attachment)]

Message #67 received at 702030@bugs.debian.org (full text, mbox, reply):

From: u <u@451f.org>

To: 702030@bugs.debian.org

Subject: Re: [DSE-Dev] forbid most packages to depend on or recommend apparmor

Date: Tue, 21 Oct 2014 11:19:49 +0000

Hi,

after reading through
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702030 and the related
bugs, I think that there might be an easy way to get this to work.

>>>> (Also, what happens if someone has already enabled selinux, then
>>>> installs this apparmor package which is intended to automatically
>>>> enable apparmor?)

>>> The *last* LSM activated on the kernel command-line is the one
>>> that's enabled in practice (tested both ways). So, installing a
>>> apparmor package, that automatically enables this LSM, would
>>> override the previous manual enabling of SELinux. The reciprocal
>>> applies when running selinux-activate (which is arguably a more
>>> explicit choice made by the administrator than installing the
>>> apparmor package).

>>> IMO, both should first check if another LSM is enabled.

> That sounds like a good idea. It would be nice to have some kind of
> standard way to tell if any other LSM is enabled, otherwise we all
> have to maintain some
> selinuxenabled | $apparmorenabled | $whateverelseenabled
> shell snippets on our own.

I guess having "some kind of standard way to tell if any other LSM is
enabled" is easy to answer, right? Just check if in /etc/default/grub
there is an active "security" option set for GRUB_CMDLINE_LINUX.

Then, the proposed debconf option seems to be the easiest to implement,
from my point of view.
Just use a postinstall script in every LSM package, then check
GRUB_CMDLINE_LINUX to select the activated security module or set to
"none" if there is none.
(As intrigeri pointed out to me, the current selinux enablement tool
only supports Grub in any case.)

The script would still need to check if there are other security modules
installed and propose those as other possible options.

This could become "dh_enable_lsm".


From my understanding, this way, no change to lintian nor policy would
be required.

It would also solve the problem which intrigeri talks about in his
first comment on #702030 about making choices permanent.

And with those scripts, i suppose that it would be possible to run
dpkg-reconfigure on any of those packages at a later point in time,
making it easier for lambda users to select a LSM, add the relevant
lines to grub.cfg, and run update-grub.

Cheers,
u.

Message #72 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Russell Coker <russell@coker.com.au>

To: selinux-devel@lists.alioth.debian.org,Patrick Schleizer <adrelanos@riseup.net>

Cc: intrigeri <intrigeri@debian.org>,Steve Langasek <vorlon@debian.org>,702030@bugs.debian.org

Subject: Re: [DSE-Dev] Bug#702030: Bug#754744: forbid most packages to depend on or recommend apparmor

Date: Sun, 14 Dec 2014 16:55:23 +1100

On Mon, 14 Jul 2014 19:13:29 intrigeri wrote:
> > AFAIK this is inconsistent with how selinux is handled, which is
> > only enabled via an explicit boot option.
> 
> I was not aware of that, thanks for pointing it out.
> 
> @SELinux maintainers: is this behavior on purpose, or is it due to the
> historical lack of a facility (recently added by the
> /etc/default/grub.d support) to easily have a package append arguments
> to the kernel command-line?

The SE Linux support predates the /etc/default/grub.d support.  But even if it 
had been there I still probably wouldn't have done it automatically.  There 
are situations where you want to install things without activating them and 
there are situations where things get dragged in by dependencies but you don't 
want to use them.

> Indeed, I think we should. I see several ways of keeping things
> consistent while reaching the aforementioned AppArmor usability goal:
> 
> a) Having the SELinux equivalent of the apparmor package enable it by
>    default too (and then, we'll need conflicts); I've no idea if this
>    is feasible; one would need to look at the SELinux packages and
>    their chain of reverse-dependencies.

This doesn't sound like a good option.

> b) Implementing the behavior proposed by Patrick via a dedicated
>    apparmor-$something configuration package. ftp-masters likely won't
>    be happy with it (understandably), unless we demonstrate it's the
>    best available solution to reach a sensible goal. The SELinux team
>    is then free to create a corresponding package.
> 
> c) A new package whose job is to select and enable a LSM (or none).
>    Likely "none" would be the default for now. It's tempting to take
>    benefit from debconf here.

That would work.  The current selinux-activate is a hack that should go away.

> The *last* LSM activated on the kernel command-line is the one that's
> enabled in practice (tested both ways). So, installing a apparmor
> package, that automatically enables this LSM, would override the
> previous manual enabling of SELinux. The reciprocal applies when
> running selinux-activate (which is arguably a more explicit choice
> made by the administrator than installing the apparmor package).
> 
> IMO, both should first check if another LSM is enabled.

I'd be happy to have selinux-activate check for other LSMs and warn the user.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/
-- 
Sent from my Samsung Galaxy Note 3 with K-9 Mail.

Message #77 received at 702030@bugs.debian.org (full text, mbox, reply):

From: u <u@451f.org>

To: 702030@bugs.debian.org

Date: Mon, 15 Dec 2014 18:41:38 +0000

FYI: I will most probably work on this bug during round 9 of the GNOME
Outreach Program [1], which has just started :)

So if you have any other input for me, please go ahead.

Cheers!

[1] https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Debian

Message #82 received at 702030@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 702030@bugs.debian.org

Cc: selinux-devel@lists.alioth.debian.org

Subject: Re: [DSE-Dev] Bug#702030: Bug#754744: forbid most packages to depend on or recommend apparmor

Date: Mon, 09 May 2016 22:03:22 +0200

Hi,

Russell Coker wrote (14 Dec 2014 05:55:23 GMT) :
> On Mon, 14 Jul 2014 19:13:29 intrigeri wrote:
>> @SELinux maintainers: is this behavior on purpose, or is it due to the
>> historical lack of a facility (recently added by the
>> /etc/default/grub.d support) to easily have a package append arguments
>> to the kernel command-line?

> The SE Linux support predates the /etc/default/grub.d support.  But even if it 
> had been there I still probably wouldn't have done it automatically.  There 
> are situations where you want to install things without activating them and 
> there are situations where things get dragged in by dependencies but you don't 
> want to use them.

Got it, thanks for the insight!

>> Indeed, I think we should. I see several ways of keeping things
>> consistent while reaching the aforementioned AppArmor usability goal:
>> 
>> a) Having the SELinux equivalent of the apparmor package enable it by
>>    default too (and then, we'll need conflicts); I've no idea if this
>>    is feasible; one would need to look at the SELinux packages and
>>    their chain of reverse-dependencies.

> This doesn't sound like a good option.

Even taking into account Mika's note that "the SELinux equivalent of
the apparmor package" does not exist yet, and should be a new binary
package called e.g. selinux?

(I don't mean to insist, I just want to understand better why this
wouldn't be one of the options on the table :)

I've thought a bit about it, and here's the simplest solution I can
find, that can possibly suit everyone's use case, without any postinst
or dh tricks:

 * each package that adds support for a LSM, and is meant to enable it
   by default, ships a /etc/default/grub.d/50_$lsm file, that adjusts
   GRUB_CMDLINE_LINUX if, and only if, no other LSM is enabled via
   GRUB_CMDLINE_LINUX already;

 * each such package conflicts with all others;

 * for AppArmor, said package is the existing "apparmor" one, to
   achieve the usability goal that triggered this discussion;

 * for SELinux, said package would be a new binary one, called e.g.
   "selinux" as suggested by Mika;

 * at least on the AppArmor side, we'll want a Lintian check to ensure
   that no package mistakenly depends on the "apparmor" one.

The only problem I see with this KISS approach is that the code
snippet in /etc/default/grub.d/50_$lsm would be duplicated in various
$lsm_package:s, and any bugfix in it would require several uploads;
this is a downside compared to the dh_enable_lsm idea; arguably, that
code would be super simple, and would rarely have to change, so
perhaps it's no big deal?

One advantage of this plan is that it can be implemented
incrementally, with very little coordination; for example, this should
work:

1. we add this GRUB config snippet in the apparmor package
2. selinux-activate starts checking for other LSMs and warns the user,
   as proposed by Russell
3. whenever/if SELinux maintainers feel like it, they can switch to
   the GRUB approach and drop selinux-activate; and then, we can add
   the Conflicts on both sides

Another advantage of this plan is: it's compatible with existing or
future manual configuration, that is the snippets in
/etc/default/grub.d/50_$lsm will do nothing if the user decided to
configure their prefered LSM in a different way.

>> c) A new package whose job is to select and enable a LSM (or none).
>>    Likely "none" would be the default for now. It's tempting to take
>>    benefit from debconf here.

> That would work.  The current selinux-activate is a hack that should go away.

OK, so that's one valid option. Let's describe a bit more precisely
how it could work, and then we can compare it to (a) adjusted by u.'s
and Mika's input.

We would need one new binary package (let's call it select-lsm), and
likely the corresponding source package. Ideally, it would be
collaboratively maintained by members of the SELinux and
AppArmor teams.

select-lsm would manage a debconf setting, whose default value would
be "none".

The set of available values for this debconf setting would be
determined by what installed packages add support for a LSM: e.g.
if I have the apparmor package installed, but not selinux-utils, then
I would have to choose between "none" and "AppArmor"; and if I have
both apparmor and selinux-utils installed, then I get to choose
between "none", "AppArmor" and "SELinux".

Each package $lsm_package that adds support for a LSM, and that's
supported by select-lsm, should depend on select-lsm, and somehow we
need the select-lsm's debconf question to be asked again when a new
$lsm_package is installed, or when the $lsm_package corresponding to
the currently selected LSM is de-installed. [Can we do that at all
with debconf? Maybe with a dpkg trigger?]

The outcome of using select-lsm to pick a LSM (or none) is:

 * in the general case: adjust GRUB_CMDLINE_LINUX via
   /etc/default/grub.d/50_select-lsm, run update-grub

 * if a LSM is already enabled in /etc/default/grub:
   - cheap option, maybe good enough for a first iteration: suggest the
     user to drop their LSM config and `dpkg-reconfigure select-lsm'
   - ideally: ask the user if they want us to migrate their LSM kernel
     cmdline configuration from /etc/default/grub to
     /etc/default/grub.d/50_select-lsm

All this could work, but it feels it requires much more work, to get
it right and robust, than the other option I've discussed above.

Thoughts, feelings?

Cheers,
-- 
intrigeri

Message #87 received at 702030@bugs.debian.org (full text, mbox, reply):

From: Laurent Bigonville <bigon@debian.org>

To: intrigeri <intrigeri@debian.org>, 702030@bugs.debian.org

Cc: selinux-devel@lists.alioth.debian.org

Subject: Re: [DSE-Dev] Bug#702030: Bug#754744: forbid most packages to depend on or recommend apparmor

Date: Tue, 10 May 2016 13:24:24 +0200

Le 09/05/16 à 22:03, intrigeri a écrit :
> Hi,

Hey,

>
> Russell Coker wrote (14 Dec 2014 05:55:23 GMT) :
>> On Mon, 14 Jul 2014 19:13:29 intrigeri wrote:
> [...]
>>> Indeed, I think we should. I see several ways of keeping things
>>> consistent while reaching the aforementioned AppArmor usability goal:
>>>
>>> a) Having the SELinux equivalent of the apparmor package enable it by
>>>     default too (and then, we'll need conflicts); I've no idea if this
>>>     is feasible; one would need to look at the SELinux packages and
>>>     their chain of reverse-dependencies.
>> This doesn't sound like a good option.
> Even taking into account Mika's note that "the SELinux equivalent of
> the apparmor package" does not exist yet, and should be a new binary
> package called e.g. selinux?

Ubuntu actually has a selinux package already that probably predate them 
using apparmor :p

We already have a selinux-basics package (we could rename it of course). 
I removed all the functional part of SELinux from it (the initscript to 
automagically relabel files on reboot if needed has been moved to the 
policycoreutils package).

I personally now see this package as a metapackage even if we still have 
some executables in there, some are not updated for quite some times and 
other are not needed anymore. The selinux-activate is actually doing 
wrong things as now the calls to pam_selinux are already present in all 
the needed pam services. We could get rid of some of them I guess and 
try to update the others (ie check-selinux-installation).

I still see one or two things that needs to be done on the SELinux side 
to have a install-reboot-itworks workflow, like creating the 
/.autorelabel sentinel file when policycoreutils is initially installed.

There is still one concern, is the policy package. To ease the 
installation I don't mind to have Recommends against the default policy 
package, but I'm not sure we should have a hard dependency but if the 
user removes that policy package it will breaks everything. OTOH we 
could says that this metapackage is to have the debian experience with 
the debian policy and make it a hard requirement, I'm not sure... There 
is also the question about in which mode we should enable SELinux 
(permissive or enforcing) knowing that IMHO the policy is not working 
OFTB for all use cases.

> (I don't mean to insist, I just want to understand better why this
> wouldn't be one of the options on the table :)
>
> I've thought a bit about it, and here's the simplest solution I can
> find, that can possibly suit everyone's use case, without any postinst
> or dh tricks:
>
>   * each package that adds support for a LSM, and is meant to enable it
>     by default, ships a /etc/default/grub.d/50_$lsm file, that adjusts
>     GRUB_CMDLINE_LINUX if, and only if, no other LSM is enabled via
>     GRUB_CMDLINE_LINUX already;
>
>   * each such package conflicts with all others;
Don't forget that the conffiles will stay installed on disk if the 
package is not purged. If both are installed which one will take 
precedence? I guess it will be the apparmor one if the files are sorted 
alphabetically :p
>   * for AppArmor, said package is the existing "apparmor" one, to
>     achieve the usability goal that triggered this discussion;
>
>   * for SELinux, said package would be a new binary one, called e.g.
>     "selinux" as suggested by Mika;
>
>   * at least on the AppArmor side, we'll want a Lintian check to ensure
>     that no package mistakenly depends on the "apparmor" one.

There are quite several in ubuntu doing so, will you coordinate with 
them then?
> The only problem I see with this KISS approach is that the code
> snippet in /etc/default/grub.d/50_$lsm would be duplicated in various
> $lsm_package:s, and any bugfix in it would require several uploads;
> this is a downside compared to the dh_enable_lsm idea; arguably, that
> code would be super simple, and would rarely have to change, so
> perhaps it's no big deal?

The DM packages (gdm, lightdm,...) are already doing something similar 
to see which one should be started.
> One advantage of this plan is that it can be implemented
> incrementally, with very little coordination; for example, this should
> work:
>
> 1. we add this GRUB config snippet in the apparmor package
> 2. selinux-activate starts checking for other LSMs and warns the user,
>     as proposed by Russell
> 3. whenever/if SELinux maintainers feel like it, they can switch to
>     the GRUB approach and drop selinux-activate; and then, we can add
>     the Conflicts on both sides
>
> Another advantage of this plan is: it's compatible with existing or
> future manual configuration, that is the snippets in
> /etc/default/grub.d/50_$lsm will do nothing if the user decided to
> configure their prefered LSM in a different way.
>
>>> c) A new package whose job is to select and enable a LSM (or none).
>>>     Likely "none" would be the default for now. It's tempting to take
>>>     benefit from debconf here.
>> That would work.  The current selinux-activate is a hack that should go away.
> OK, so that's one valid option. Let's describe a bit more precisely
> how it could work, and then we can compare it to (a) adjusted by u.'s
> and Mika's input.
>
> We would need one new binary package (let's call it select-lsm), and
> likely the corresponding source package. Ideally, it would be
> collaboratively maintained by members of the SELinux and
> AppArmor teams.
>
> select-lsm would manage a debconf setting, whose default value would
> be "none".
>
> The set of available values for this debconf setting would be
> determined by what installed packages add support for a LSM: e.g.
> if I have the apparmor package installed, but not selinux-utils, then
> I would have to choose between "none" and "AppArmor"; and if I have
> both apparmor and selinux-utils installed, then I get to choose
> between "none", "AppArmor" and "SELinux".
>
> Each package $lsm_package that adds support for a LSM, and that's
> supported by select-lsm, should depend on select-lsm, and somehow we
> need the select-lsm's debconf question to be asked again when a new
> $lsm_package is installed, or when the $lsm_package corresponding to
> the currently selected LSM is de-installed. [Can we do that at all
> with debconf? Maybe with a dpkg trigger?]

Again something similar is done by the DM's, they are using a shared 
debconf question, not sure that we need an extra package. But this will 
mean code duplication in each LSM metapackages.

>
> The outcome of using select-lsm to pick a LSM (or none) is:
>
>   * in the general case: adjust GRUB_CMDLINE_LINUX via
>     /etc/default/grub.d/50_select-lsm, run update-grub
>
>   * if a LSM is already enabled in /etc/default/grub:
>     - cheap option, maybe good enough for a first iteration: suggest the
>       user to drop their LSM config and `dpkg-reconfigure select-lsm'
>     - ideally: ask the user if they want us to migrate their LSM kernel
>       cmdline configuration from /etc/default/grub to
>       /etc/default/grub.d/50_select-lsm
>
> All this could work, but it feels it requires much more work, to get
> it right and robust, than the other option I've discussed above.
>
> Thoughts, feelings?
>
> Cheers,

Send a report that this bug log contains spam.