[DSE-Dev] base module

[Mika Pflüger]

Hi,

Russell Coker <russell at coker.com.au> wrote:
> I propose that every module which is required for a working system as
> well as some modules that are extremely common be included in base.pp.

This sounds like it has some clear advantages. While I do think we
should allow the administrator reasonable tweaking of the policy out of
the box, I also think that the administrator who is unhappy with our
choice of what should go into base.pp should just compile their own
policy. What you propose for the base module sounds very reasonable in
this regard, because only few users would need to compile their own
policy, while the whole thing gets far more manageable for most users.
> 
> Then we need to change the policy to remove any dependencies that the
> modules in base.pp may have on other modules.
> 
> tunable_policy(`init_upstart || init_systemd',`
>         corecmd_shell_domtrans(init_t, initrc_t)
> ',`
>        # Run the shell in the sysadm role for single-user mode.
>        # causes problems with upstart
>        sysadm_shell_domtrans(init_t)
> ')
> 
> For example we had the above in init.te.  This can't be made
> optional_policy as optional_policy and tunable_policy can't be used
> together.  So in my policy tree I replaced the second part of the
> above tunable with the following in sysadm.te.  That means that
> instead of init.te having a mandatory dependency on sysadm.te we have
> sysadm.te depending on init.te.
> 
> tunable_policy(`!init_upstart && !init_systemd',`
>         # Run the shell in the sysadm role for single-user mode.
>         # causes problems with upstart
>        init_shell_domtrans(sysadm_t)
> ')
> 
> Currently I'm experimenting with making init, logging, authlogin,
> application, userdomain, systemd, dmesg, dpkg, usermanage, libraries,
> fstools, miscfiles, mount, selinuxutil, and sysnetwork be base
> modules.

As this sounds like it was generally useful, we should try to get these
patches upstream when we have them. Dependencies from "core" modules on
"leaf" modules will confuse users (as in "why the hell do I need
the /obscure module/ policy enabled for my sysvinit policy to load?"),
even if policy is compiled entirely modular.

Cheers,

Mika

PS: from end of this week until february, I will have to do shift work
and most likely won't be able to read my debian mail let alone do
packaging work.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/selinux-devel/attachments/20140113/39075f10/attachment.sig>