Packaging hotfixes

[Axel Thimm]

On Mon, Apr 03, 2006 at 02:36:51PM -0400, Daniel J Walsh wrote:
> Axel Thimm wrote:
> >Hi,
> >
> >is there a way to have policy enhancements per packages? I'm asking
> >this because both fedora's and upstream handling of new selinux rules
> >works great, still the upgraded selinux-policy packages need some time
> >to hit the users and while they wait for their nvidia, avidemux,
> >whatever fix, they always seem to need it instantaneously and prefer
> >to turn off selinx altogether instead of waiting for a fix.
> >
> >If there is a way to locally add rules from packages, then the
> >problematic app foo could carry an selinux snippet with itself and
> >install it until the policy package catches up.
> >
> >Or would such a mechanism allow any package to overthrow selinux
> >altogether thus making this more of a security risk than a feature?
> >  
> modular policy allows for customization to local policy.  You can look 
> at policy generated by audit2allow -M  to see this.  Most of the 
> problems you are talking about are from libraries requesting more privs 
> then they require execmod.  You can change the file context on those 
> files to tell selinux to allow the access.   chcon -t textrel_shlib_t 
> LIBRARY
> 
> http://people.redhat.com/drepper/selinux-mem.html
> 
> Explains the risks of the exec* accesses.
> 
> Any time you see this, it should be reported as a problem with SELinux 
> policy but also reported back to the package maintainer, as they might 
> have a problem with their library.

Ok, thanks a lot for the info. As the package maintainer I will
forward the issue to upstream and hope to see it fixed in the next
upstream release. But it's good to have a local workaround/fix until
this happens.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20060403/2ce15e50/attachment.sig>