[DSE-Dev] base module

[Laurent Bigonville]

Le Mon, 13 Jan 2014 23:24:30 +1100,
Russell Coker <russell at coker.com.au> a écrit :

Hello,

> A recent change to the policy package involve making every policy a
> separate module.
> 
> When modules depend on each other there is no compile time issue.
> You can compile multiple modules independently and create a mass that
> has lots of dependencies and I believe there's nothing stopping
> circular dependencies.  So making everything a module means that all
> the dependencies of init (of which there are many) can be separately
> compiled without issue.  But then managing those dependencies becomes
> a module load time issue.
> 
> Module dependencies makes upgrades difficult in the face of modules
> being renamed or made redundant.
> 
> 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.

We have followed the Fedora/Redhat way here. They are also compiling
everything as separate modules. We also changed the way the modules
were loaded, can we still get modules loop with this new way?

I personally like the fact that everything is a module, this makes it
easier (IMHO) to see immediately which one is enabled on the machine.
I'm not sure if it's possible to

When the modules are compiled in the base.pp, doesn't that mean that
the user cannot disabled the don't audit rules?

> 
> 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)
> ')

Well we need to see how upstream will do the integration of systemd in
the refpolicy. Fedora has completely dropped the init_systemd boolean
for example.

> 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.

I also really would like to stick with the "patches upstream first"
policy. My time an knowledge are limited and it's not easy to manage a
big delta over upstream code.

> Also I'm going to promose removing some modules from upstream.

Well I think that compiling all the modules doesn't really hurt. We
have chosen to disable by default the one that are obviously not for
debian, but install them on disk anyway. They can still be useful for
some people.

Cheers,

Laurent Bigonville