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

[Laurent Bigonville]

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,