[DSE-Dev] Re: Sid SELinux packages are now working

[Manoj Srivastava]

On Wed, 09 May 2007 00:09:12 +0200, Erich Schubert <erich at debian.org> said: 

> Hello Manoj,
>> I think we need to create a tool that can update your policy setup,
>> taking into account any new packages you might have installed in the
>> meanwhile and loading new modules as needed.  This is the first

> Like the "update-selinux-policy" command in my packages does?
> http://svn.debian.org/wsvn/selinux/refpolicy/branches/debian-pkg/debian/utils/update-selinux-policy

        Hmm. Python. I think I looked at that when I implemented the
 version in the policy postinst scripts -- I remember inverting the
 mapping.

        We do have something like this in the  postinst of the
 refpolicy packages -- something that is aware of the mapping between
 SELinux policy modules and debian packages, which discovers the
 relationships between modules and orders the policy load correctly,  so
 that it can pull in any dependency as required.

        I was just thinking of pulling it out of the postinst, and
 adding it into policycoreutils -- which is OK, since we already depend
 on policycoreutils.  I'll have to add the user interaction bits, like
 specifying a single package name on the command line, and concentrating
 only on that, as opposed to a general update, No options, you get a
 refresh of the policy. You can optionally specify the policy name, in
 case you have multiple policies installed on the system

>> An initial approach would be to have this utility be given a package
>> name on the command line, and it will see if there is a corresponding
>> selinux modular policy module, and install the policy or update it as
>> needed (if selinux is enabled, of course).  If the module is already
>> installed, it should do nothing.

> Actually it might also make sense to update the modules with the
> latest version in the same run.  What my script doesn't do yet is
> check version numbers. It will just re-run the autodetection and
> install any module that was already installed or that was
> automatically detected.

        I was thinking of looking at the module, and updating it if it
 was different -- whether or not the version changed. Yes, I am lazy.
,----
| __> sha1sum  /etc/selinux/refpolicy-strict/modules/active/modules/inetd.pp 
| 46cb627240b2637dae973fbf11ed744e246a991d  \
|        /etc/selinux/refpolicy-strict/modules/active/modules/inetd.pp
| __> sha1sum /usr/share/selinux/refpolicy-strict/inetd.pp 
| 46cb627240b2637dae973fbf11ed744e246a991d  \
|        /usr/share/selinux/refpolicy-strict/inetd.pp
| __> 
`----

        md5sum mismatch, refresh module.

> So you can't 'blacklist' a policy module, and if you replaced it with
> a modified custom one, it will also be replaced.  Local modifications
> in separate modules will of course be kept.

        Hmm. I had not thought about blacklisting modules. I think, if
 you have a local module that overrides a  refpolicy module, and so you
 don't want to have the module changed at all, it should be easy enough
 to implement a configuration file which sets a blacklist variable.

        manoj
-- 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C