Created attachment 347235 [details]
perl-NOCpulse-Scheduler rpm

Created attachment 347237 [details]
spacewalk-monitoring-selinux

Created attachment 347238 [details]
spacewalk-monitoring

Created attachment 347239 [details]
SRPM of perl-NOCpulse-Scheduler

Created attachment 347240 [details]
SRPM of spacewalk-monitoring-selinux

Created attachment 347242 [details]
SRPM of spacewalk-monitoring

This is not an SELinux bug but a packaging bug.  You need to make sure the selinux policy package is installed first  Or run the restorecon on all files covered by the context when the package gets installed.

Notice that in %post section of spacewalk-monitoring-selinux is called script spacewalk-monitoring-selinux-enable, which contains:

# Install SELinux policy modules
for selinuxvariant in mls strict targeted
  do
    /usr/sbin/semodule -s ${selinuxvariant} -l > /dev/null 2>&1 \
      && /usr/sbin/semodule -s ${selinuxvariant} -i \
        /usr/share/selinux/${selinuxvariant}/spacewalk-monitoring.pp || :
  done

/sbin/restorecon -rv /etc/rc.d/np.d /etc/notification /var/lib/nocpulse /var/lib/notification /var/log/nocpulse
/sbin/restorecon -rvi /var/log/SysVStep.* /var/run/SysVStep.*

So the selinux policy module is loaded before perl-NOCpulse-Scheduler is installed. Therefore I assume that file from perl-NOCpulse-Scheduler should have scontext as defined in that module. 
Or I understand it wrong?

(In reply to comment #7)
> This is not an SELinux bug but a packaging bug.  You need to make sure the
> selinux policy package is installed first

We might consider doing that with Spacewalk/Satellite packages in the future.

> Or run the restorecon on all files
> covered by the context when the package gets installed.

Well, the trouble is, matchpathcon_init() seems to be called at the beginning of the rpm transaction and matchpathcon_fini() at the end, so the newly loaded module (or semanage fcontext, I assume) is not seen by rpm. External restorecon fixes that, yes.

Still, shouldn't rpm detect that the state of SELinux has changed while the package was installed, and rerun that matchpathcon_init() ? Obviously, this bugzilla should probably be aligned to rpm/rpmlib.

I think this is an RPM problem.    Maybe call matchpathcon_init after each post install, but the files might be already on disk before any post installs run.

Daniel, is there an libsyslinux API call that rpm could use to track SELinux policy changes? security_policyvers() seems like a potential candidate but does the policy version change if a package loads a module of its own like spacewalk is doing here, or is there a better way to detect policy changes? I'd rather not do matchpathcon_ini() and _fini() after each and every package "just in case", the transaction is slow enough as it is :)

Of course that still leaves a lot uncovered: the policy should optimally be loaded before laying down the files, which gets us to the chicken and egg problem in bug 185434. For "pure" policy packages that contain nothing but a policy, it would help ordering them early in the transaction currently there's no way for rpm to know whether something has selinux policies or not (well, there's %policy files but AFAIK nothing uses them as other pieces are missing to make any use of it)

Yep, a way of detecting either the "incarnation" sequence number of the policy state, or timestamp of the last policy load, could help in rerunning matchpathcon_ini only if the package has actually changed something.

Alternatively, amending rpm behaviour to do the matchpathcon_ini reload if it just installed %policy files (and if the .rpm had some %post script, meaning there is a chance that the .rpm actually did something with those %policy files) could be the way. I admit that my SELinux policy module files are not marked as %policy as of now but I can easily update my .rpms if that would be the preferred way.

Marking policy files with %policy has a side-effect: such files get stuffed into the header too, where policy size might become an issue wrt current header size limits. Hmm... looking at F11 selinux-policy-targeted, /usr/share/selinux/targeted/ is 2.7M which wouldn't be a problem to store in the header, uncompressed that becomes 43MB which *is* a problem.

Another problem with %policy is that it expects plaintext .te files, rpm doesn't support arrays of binary data so the data is stored as array of \0-terminated strings, which would blow up big time if you try to include binary policies there. So rpm would need to base64 encode them (it should probably do it anyway for its own safety), which means a fair increase in data size but maybe not prohibitive, the F11 targeted policy compressed "only" becomes 3.5MB base64-encoded.

So while %policy would provide the necessary hint for rpm to reload selinux contexts, and actually even preload the policies from there, it's not usable as it is now.

Hmm, selinux_set_callback() with SELINUX_CB_POLICYLOAD seems even better than manually polling policy version, especially if that callback occurs on any semodule load.

Steven you have any ideas?

Yes, selinux_set_callback() with SELINUX_CB_POLICYLOAD should get notification of policy reloads, which will happen upon semodule -i.

With regard to %policy, Tresys is looking into migrating away from binary policy modules to a text representation and into improved rpm-selinux integration.

Actually, you may need to call the avc_netlink* interfaces as well, as rpm doesn't presently use the AVC and that callback only gets called from the AVC (right Eamon?).

Man avc_netlink_open(3).  You can set up the POLICYLOAD callback with
selinux_set_callback(), then open-code a loop using the avc_netlink
functions, or use avc_netlink_loop() to enter a blocking loop (in a
thread, for example).  The POLICYLOAD callback will be called, and calling avc_open() to set up the AVC is not required.

...Although you need libselinux 2.0.80 for these functions, not sure what is in RHEL.

Moving this to 5.5 although I'm not sure the scope of these proposed changes makes it feasible for the RHEL5 stream at all. But lets keep the discussion going and Panu is looking at this for upstream.

This could possibly be solved by 

1. rpm being able to reload the policy
2. policy packages being required by the main package (filesystem if in doubt). This means that we'd need to create -nopolicy policy packages that can be chosen if no selinux policy is wanted. I really don't see a more beautiful way of getting the ordering right.

As both together is a too big change for an update release I close this bug as DEFFRRED. For now there is still the possibility of calling restorecon in a %posttrans scriptlet or and %post scriptlet and set a Requires: to the -selinux package.

PS: RHEL 5 still has libselinux-1.33.4
PPS: As the first installation is happening into a install root calling restorecon from within scriptlets could still be required. SElinux and install roots do not mix very well.