Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI
Summary: Selinux: pwdhash fails if called via Admin Server CGI
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Security - General
Version: 1.2.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 434915 389_1.2.6
TreeView+ depends on / blocked
 
Reported: 2010-06-29 19:08 UTC by Noriko Hosoi
Modified: 2015-12-07 16:48 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-12-07 16:48:29 UTC


Attachments (Terms of Use)
git patch file (9.0) (1.59 KB, patch)
2010-06-29 19:08 UTC, Noriko Hosoi
nhosoi: review+
Details | Diff
Error_Screen (89.26 KB, image/png)
2011-06-22 11:21 UTC, Amita Sharma
no flags Details

Description Noriko Hosoi 2010-06-29 19:08:41 UTC
Created attachment 427765 [details]
git patch file (9.0)

Description of problem:
Attempt to create the second server instance from Console fails with this error:
pwdhash-bin: error while loading shared libraries: libslapd.so.0: cannot open shared object file: No such file or directory

Description by nkinder@redhat.com:
Our CGIs are very restricted in what they can access/run.  Most of the CGIs are self contained programs (they may use libraries, which is fine).  In this case, it looks like pwdhash-bin is called from the SELinux context used by CGIs (httpd_dirsrvadmin_script_t).  The pwdhash-bin program then tries to load libslapd.so.0, which is labeled as dirsrv_lib_t.  This should be allowed by our SELinux policy since we call this macro with the httpd_dirsrvadmin_script_t context:

interface(`dirsrv_exec_lib',`
        gen_require(`
                type dirsrv_lib_t;
        ')

        allow $1 dirsrv_lib_t:dir search_dir_perms;
        allow $1 dirsrv_lib_t:file exec_file_perms;
        # Not all platforms include ioctl in exec_file_perms
        allow $1 dirsrv_lib_t:file ioctl;
')

What seems to be the issue here is that libslapd.so.0 is a symlink, not a regular file.  SELinux considers this to be a class of "lnk_file", as can be seen in the raw AVC from /var/log/audit/audit.  We need to expand the dirsrv_exec_lib macro in dirsrv.if to have the following rule:

        allow $1 dirsrv_lib_t:lnk_file exec_file_perms;

Comment 1 Noriko Hosoi 2010-06-29 19:13:31 UTC
Comment on attachment 427765 [details]
git patch file (9.0)

The patch was proposed by nkinder and reviewed by nhosoi.

Comment 2 Noriko Hosoi 2010-06-29 19:14:23 UTC
I tested the fix on F-13.  I could create the second, third server instances without any problems.

Comment 3 Noriko Hosoi 2010-06-29 19:15:52 UTC
Pushed to master.

$ git merge work
Updating 7482698..1a47871
Fast-forward
 selinux/dirsrv.if |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

$ git push
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 853 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   7482698..1a47871  master -> master

Comment 7 Amita Sharma 2011-06-21 07:17:41 UTC
[root@testvm data]# getenforce
Enforcing

I am not able to create the DS instance with above steps while Selinux is enforced, also the existing instance can not be removed from DS console while Selinux is enforced.

As soon as, I set the selinux = Permissive - It allows me to create and remove the ds instance from DS console.

Comment 8 Rich Megginson 2011-06-21 14:18:36 UTC
(In reply to comment #7)
> [root@testvm data]# getenforce
> Enforcing
> 
> I am not able to create the DS instance with above steps while Selinux is
> enforced, also the existing instance can not be removed from DS console while
> Selinux is enforced.
> 
> As soon as, I set the selinux = Permissive - It allows me to create and remove
> the ds instance from DS console.

Please reproduce the problem with Selinux in Enforcing mode and attach your /var/log/audit/audit.log to this bug as an attachment.

Comment 11 Amita Sharma 2011-06-22 11:21:01 UTC
Created attachment 505972 [details]
Error_Screen

Error_Screen

Comment 12 Amita Sharma 2011-06-22 11:21:39 UTC
[root@testvm /]# tail -f /var/log/audit/audit.log
type=CRED_DISP msg=audit(1308741001.349:14935): user pid=4171 uid=0 auid=0 ses=2413 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=USER_END msg=audit(1308741001.349:14936): user pid=4171 uid=0 auid=0 ses=2413 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=MAC_STATUS msg=audit(1308741503.917:14937): enforcing=1 old_enforcing=0 auid=0 ses=2038
type=SYSCALL msg=audit(1308741503.917:14937): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fff995da810 a2=1 a3=fffffff8 items=0 ppid=27209 pid=4289 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2038 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=USER_ACCT msg=audit(1308741601.366:14938): user pid=4297 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=CRED_ACQ msg=audit(1308741601.367:14939): user pid=4297 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=LOGIN msg=audit(1308741601.370:14940): login pid=4297 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=2414
type=USER_START msg=audit(1308741601.371:14941): user pid=4297 uid=0 auid=0 ses=2414 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=CRED_DISP msg=audit(1308741601.392:14942): user pid=4297 uid=0 auid=0 ses=2414 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=USER_END msg=audit(1308741601.392:14943): user pid=4297 uid=0 auid=0 ses=2414 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'

Comment 14 Rich Megginson 2011-08-31 17:57:22 UTC
Can we verify this bug now?

Comment 15 Nathan Kinder 2011-08-31 19:37:05 UTC
(In reply to comment #14)
> Can we verify this bug now?

Yes, this can be verified if the latest selinux-policy package is installed from RHN.

Comment 16 Amita Sharma 2011-09-16 08:54:23 UTC
Nathan,

Request you to please verify the package name and version:
[root@snmaptest ~]# rpm -qa | grep selinux
selinux-policy-3.7.19-93.el6_1.7.noarch
libselinux-utils-2.0.94-5.el6.x86_64
selinux-policy-targeted-3.7.19-93.el6_1.7.noarch
libselinux-2.0.94-5.el6.x86_64
libselinux-python-2.0.94-5.el6.x86_64


Thanks and Regards,
Amita

Comment 17 Nathan Kinder 2011-09-16 16:48:26 UTC
(In reply to comment #16)
> Nathan,
> 
> Request you to please verify the package name and version:
> [root@snmaptest ~]# rpm -qa | grep selinux
> selinux-policy-3.7.19-93.el6_1.7.noarch
> selinux-policy-targeted-3.7.19-93.el6_1.7.noarch

Yes, theses packages should have the proper fixes in place.

Comment 18 Amita Sharma 2011-09-28 11:36:46 UTC
[root@snmaptest scripts]# getenforce
Enforcing
After configuring SSL on directory server and admin server and the console:
used the console to create a new instance of directory server
OUTPUT
========
Creating new server instance...

The operation was successful.


Hence VERIFIED.


Note You need to log in before you can comment on or make changes to this bug.