Jeff Holt wrote:
> I just copied mod_slam.so to /etc/httpd/modules, executed chcon -r
> mod_alias.so mod_slam.so, and edited /etc/httpd/httpd.conf to load the
> new module. As a result, I get the following avc error in my
> /var/log/messages.
>
>
>
> Aug 2 13:28:00 build02 kernel: audit(1186079280.127:7): avc: denied {
> execmod } for pid=18939 comm="httpd" name="mod_slam.so" dev=dm-0
> ino=8847362 scontext=user_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:httpd_modules_t:s0 tclass=file
execmod error means that your DSO is not built correctly, which
need text relocation. you can test it by:
readelf -d PROGRAMS | fgrep TEXTREL
if yes, you can label the DSO with:
chcon -t textrel_shlib_t mod_slam.so
or if your want to make it forever:
semanage fcontext -a -t textrel_shlib_t mod_slam.so
but i recommend that you should build the DSO from scratch in right way,
i.e. compiled with -fpic/-fPIC
>
>
>
> When I pass this text to audit2allow I get very little help.
>
>
>
> $ tail -1 /var/log/messages | audit2allow
>
>
>
>
>
> #============= httpd_t ==============
>
> allow httpd_t httpd_modules_t:file execmod;
>
> #
>
>
>
> When I pass it to audit2why I get no more help still.
>
>
>
> Aug 2 14:17:07 build02 kernel: audit(1186082227.562:10): avc: denied
> { execmod } for pid=19707 comm="httpd" name="mod_slam.so" dev=dm-0
> ino=8847362 scontext=user_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:httpd_modules_t:s0 tclass=file
>
> Was caused by:
>
> Missing or disabled TE allow rule.
>
> Allow rules may exist but be disabled by boolean
> settings; check boolean settings.
>
> You can see the necessary allow rules by running
> audit2allow with this audit message as input.
>
>
>
>
>
> What I find frustrating is that loading the installed modules (i.e.,
> installed with the httpd package) do not cause avc errors. In fact, if I
> rename, say, mod_alias.so to something else it still loads after I
> temporarily edit httpd.conf. And so, I find it hard to believe that the
> security policy knows about specific file names. When I copy
> mod_alias.so to something else (i.e., to give it a new inode) it still
> loads and so I think that proves the security policy also knows nothing
> about inodes. These two tests of renaming/copying mod_alias.so
> demonstrate to me that rebooting the server or some other
> "configuration" action is not necessary.
i don't understand what you said completely, but as i know, if your
file is in fs that support extended attribute, e.g. ext3, the security
context is stored in inode with the extended attribute.
and before you cp the file, if it had existed, cp will remain the
context of previous file, but if the file did not exist, the context
of the file will be labeled based on policy. of course, cp has the
option to remain context.
finally, mv will attempt to remain the context of the file.
>
>
>
> My actual first question, since I know so little about selinux, is this:
> if my module has the same security context as other modules, then why
> does an attempt to load it cause that avc error?
>
>
>
> Can anyone render assistance?
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
