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,
