Hi, Russell Coker <[email protected]> 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. --
signature.asc
Description: PGP signature
_______________________________________________ SELinux-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/selinux-devel
