We are encountering some AVCs when attempting to create a new 389 instance through the 389-console application. The instance creation is handled by a Perl CGI that is run through the389-admin server (httpd_t process that has been extended with the dirsrv-admin policy). In enforcing mode, I see the following AVC messages: ---------------------------------------------------------------------------- type=AVC msg=audit(1308675214.345:100): avc: denied { read } for pid=6763 comm="perl" name="shadow" dev=dm-0 ino=2496195 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=SYSCALL msg=audit(1308675214.345:100): arch=c000003e syscall=2 success=no exit=-13 a0=7f4ad1ac14bb a1=80000 a2=1b6 a3=0 items=0 ppid=6615 pid=6763 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="perl" exe="/usr/bin/perl" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null) type=AVC msg=audit(1308675214.345:101): avc: denied { search } for pid=6763 comm="perl" name="root" dev=dm-0 ino=1048577 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir type=SYSCALL msg=audit(1308675214.345:101): arch=c000003e syscall=4 success=no exit=-13 a0=118bc60 a1=1149138 a2=1149138 a3=1151ca8 items=0 ppid=6615 pid=6763 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="perl" exe="/usr/bin/perl" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null) ---------------------------------------------------------------------------- In permissive mode, I see many more AVC messages when creating a new 389-ds instance through 389-console. I will add those AVC messages as an attachment.
Created attachment 505866 [details] Permissive audit log
Created attachment 505868 [details] audit2allow output Here are the many rules generated by audit2allow against the permissive audit log. Hopefully there are some macros that can be used instead to reduce the number of policy rules that need to be added.
Why is an apache script running as root? Executing SELinux commands? reading /etc/shadow
(In reply to comment #4) > Why is an apache script running as root? Executing SELinux commands? reading > /etc/shadow It is running as root because it is trying to create a new instance of directory server, which may use a low port (port 389/636), so needs to be root in order to bind to that port, then it drops privs.
As Rich said, the admin server needs the ability to create new directory server instances on the system. This process includes labeling of the port that the new DS instance is going to listen on (it needs to be ldap_port_t). It uses semanage to do this. I believe that the /etc/shadow stuff is something that Perl must be doing when we check if the user and group that the new DS instance should run as is passed to the CGI and validated. We use the following Perl subroutines to do this: getpwuid getgrgid getpwnam
I added fixes from RHEL6 to selinux-policy-3.9.7-44.fc14
selinux-policy-3.9.7-46.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-46.fc14
Package selinux-policy-3.9.7-46.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.7-46.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14734 then log in and leave karma (feedback).
selinux-policy-3.9.7-46.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.