Bug 715039

Summary: AVCs when trying to create new 389-ds instance through 389-console
Product: [Fedora] Fedora Reporter: Nathan Kinder <nkinder>
Component: selinux-policy-targetedAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: high Docs Contact:
Priority: high    
Version: 14CC: dwalsh, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: selinux-policy-3.9.7-46.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-30 00:33:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Permissive audit log
none
audit2allow output none

Description Nathan Kinder 2011-06-21 17:01:27 UTC
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.

Comment 1 Nathan Kinder 2011-06-21 17:03:38 UTC
Created attachment 505866 [details]
Permissive audit log

Comment 2 Nathan Kinder 2011-06-21 17:09:33 UTC
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.

Comment 4 Daniel Walsh 2011-06-22 14:46:22 UTC
Why is an apache script running as root? Executing SELinux commands?  reading /etc/shadow

Comment 5 Rich Megginson 2011-06-22 14:52:36 UTC
(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.

Comment 6 Nathan Kinder 2011-06-22 15:06:38 UTC
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

Comment 7 Miroslav Grepl 2011-08-04 08:25:04 UTC
I added fixes from RHEL6 to selinux-policy-3.9.7-44.fc14

Comment 8 Fedora Update System 2011-10-20 11:57:34 UTC
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

Comment 9 Fedora Update System 2011-10-22 08:20:47 UTC
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).

Comment 10 Fedora Update System 2011-10-30 00:33:31 UTC
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.