I'm trying to run scripts via httpd from a trusted nfs server, but selinux is preventing me:
kernel: audit(1106703013.728:0): avc: denied { execute } for pid=28425 exe=/usr/sbin/httpd name=sanity_server.pl dev=0:12 ino=32407792 scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t tclass=file
So I umounted the nfs volume, and added the following to the mount options in /etc/fstab: context=system_u:object_r:httpd_sys_content_t
I mounted the volume again, and re-tried. That failed with:
kernel: audit(1106705663.904:0): avc: denied { execute_no_trans } for pid=28573 exe=/usr/sbin/httpd path=/mnt/myserver/testing-scripts/sanity_server.pl dev=0:12 ino=3 2407792 scontext=root:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file
Now, there's a lot of miscellaneous stuff on /mnt/myserver, not just the web scripts. I need to figure out how to get the scripts working again (preferably without breaking anything else)... they worked fine under RHEL3, but are failing as above under the current RHEL4 candidate.
kernel is: 2.6.9-5.EL #1 SMP Wed Jan 5 19:23:24 EST 2005 ia64 ia64 ia64 GNU/Linux
(The script fails on other architectures, as well; I just happened to be using the ia64 box tonight.)
Any/all words of wisdom appreciated,
-- John
On Tue, 2005-01-25 at 21:34 -0500, John W. Lockhart wrote:
I'm trying to run scripts via httpd from a trusted nfs server, but selinux is preventing me:
kernel: audit(1106703013.728:0): avc: denied { execute } for pid=28425 exe=/usr/sbin/httpd name=sanity_server.pl dev=0:12 ino=32407792 scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t tclass=file
Yeah; we have a few booleans for NFS home dirs and the like, but it's difficult to support arbitrarily placement of nfs_t in policy.
So I umounted the nfs volume, and added the following to the mount options in /etc/fstab: context=system_u:object_r:httpd_sys_content_t
This is the best approach, IMO.
I mounted the volume again, and re-tried. That failed with:
kernel: audit(1106705663.904:0): avc: denied { execute_no_trans } for pid=28573 exe=/usr/sbin/httpd path=/mnt/myserver/testing-scripts/sanity_server.pl dev=0:12 ino=3 2407792 scontext=root:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file
Weird. What's the output of "getsebool httpd_unified"?
John W. Lockhart wrote:
Colin Walters wrote:
Weird. What's the output of "getsebool httpd_unified"?
# getsebool httpd_unified httpd_unified --> active
Policy does not have a can_exec(httpd_t, httpdcontent) Only can_exec(httpd_$1_script_t, httpdcontent)
-- John
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Wed, 2005-01-26 at 13:46 -0500, Daniel J Walsh wrote:
John W. Lockhart wrote:
Colin Walters wrote:
Weird. What's the output of "getsebool httpd_unified"?
# getsebool httpd_unified httpd_unified --> active
Policy does not have a can_exec(httpd_t, httpdcontent) Only can_exec(httpd_$1_script_t, httpdcontent)
Right; but why isn't it trying to transition, via the domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t)?
Colin Walters wrote:
On Wed, 2005-01-26 at 13:46 -0500, Daniel J Walsh wrote:
John W. Lockhart wrote:
Colin Walters wrote:
Weird. What's the output of "getsebool httpd_unified"?
# getsebool httpd_unified httpd_unified --> active
Policy does not have a can_exec(httpd_t, httpdcontent) Only can_exec(httpd_$1_script_t, httpdcontent)
Right; but why isn't it trying to transition, via the domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t)?
Ah, good point, I wonder if this might be a bug? Is the kernel not seeing the file as httpdcontent but as nfs_t even though the mount option was specified.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Thu, 2005-01-27 at 10:36, Daniel J Walsh wrote:
Ah, good point, I wonder if this might be a bug? Is the kernel not seeing the file as httpdcontent but as nfs_t even though the mount option was specified.
Is the filesystem mounted nosuid? If so, the kernel will ignore domain transitions on it for the same reason as it ignores setuid programs.
Stephen Smalley wrote:
On Thu, 2005-01-27 at 10:36, Daniel J Walsh wrote:
Ah, good point, I wonder if this might be a bug? Is the kernel not seeing the file as httpdcontent but as nfs_t even though the mount option was specified.
Is the filesystem mounted nosuid? If so, the kernel will ignore domain transitions on it for the same reason as it ignores setuid programs.
Aha! It is indeed mounted nosuid: rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t
Any other options I should or shouldn't have in there?
-- John
On Thu, 2005-01-27 at 11:25, John W. Lockhart wrote:
Aha! It is indeed mounted nosuid: rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t
Any other options I should or shouldn't have in there?
Not clear you want to just remove nosuid, as that obviously has other security implications. If policy allowed httpd_t to set its exec context, then you could use a wrapper script that just does a runcon -t httpd_sys_script_t <realscript> to manually transition to the new domain.
Stephen Smalley wrote:
On Thu, 2005-01-27 at 11:25, John W. Lockhart wrote:
Aha! It is indeed mounted nosuid: rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t
Not clear you want to just remove nosuid, as that obviously has other security implications. If policy allowed httpd_t to set its exec context, then you could use a wrapper script that just does a runcon -t httpd_sys_script_t <realscript> to manually transition to the new domain.
For now, since the nfs server contains trusted materials, I got rid of the nosuid. Got a little farther, but hit:
kernel: audit(1106858631.779:0): avc: denied { search } for pid=22886 exe=/usr/bin/perl name=mnt dev=dm-0 ino=3932161 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:mnt_t tclass=dir
-- John
On Thu, 2005-01-27 at 15:49 -0500, John W. Lockhart wrote:
Stephen Smalley wrote:
On Thu, 2005-01-27 at 11:25, John W. Lockhart wrote:
Aha! It is indeed mounted nosuid: rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t
Not clear you want to just remove nosuid, as that obviously has other security implications. If policy allowed httpd_t to set its exec context, then you could use a wrapper script that just does a runcon -t httpd_sys_script_t <realscript> to manually transition to the new domain.
For now, since the nfs server contains trusted materials, I got rid of the nosuid. Got a little farther, but hit:
kernel: audit(1106858631.779:0): avc: denied { search } for pid=22886 exe=/usr/bin/perl name=mnt dev=dm-0 ino=3932161 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:mnt_t tclass=dir
Wouldn't be harmful to allow by default, I think.
selinux@lists.fedoraproject.org