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?
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.
Dan
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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.
selinux@lists.fedoraproject.org