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
