Bug 715038

This appears to be happening with 389 on F14 as well.  I have opened an
upstream Fedora bug for this issue as bug 715039.  I suppose we should work the
issue there and backport the fix here once we figure out what needs to change.

You have a apache script that is running as root?  And trying to read the /etc/shadow file and doing something in /root, probably looking at its Homed Dir.

(In reply to comment #3)
> You have a apache script that is running as root?

Yes.  A perl CGI script.

> And trying to read the
> /etc/shadow file and doing something in /root, probably looking at its Homed
> Dir.

It is not explicitly trying to read /etc/shadow or /root.

What SEManage commands is it running and why?  Can't we do this in the install?

(In reply to comment #5)
> What SEManage commands is it running and why?  Can't we do this in the install?

Install (of the 389 RPMs) does not create an instance of directory server.  After installing the RPMs, a setup script is run as root to create the first instance.  This setup script uses semanage to label the port if needed, as well as calling restorecon to get some path labels fixed up.  This all works fine currently.

We allow an administrator to use our Console GUI application (389-console) to remotely manage 389 instances.  One of the things that we allow is the creation (and removal) of additional 389 instances (you can run many on the same system).  This is the process that is generating these AVCs.  The administrator specifies a port and instance names that are used as part of the paths for the instance.  This requires us to use semanage at instance creation time since we can't predict the values that the administrator will provide.

The semanage commands we run are:

    semanage port -l | grep ldap_port_t | grep tcp
    semanage port -a -t ldap_port_t -p tcp <portnum>
    semanage port -d -t ldap_port_t -p tcp <portnum>

We also run 'restorecon -R' on a number of directories that we create as a part of instance creation.

I should also note that we had this working in enforcing mode prior to moving the dirsrv and dirsrv-admin policy from a standalone package into selinux-policy-targeted.  I believe that the uid/gid validation was added since then, but the semanage stuff was definitely there and working before.

Then cgi scripts could be running as uncofnined (dirsrvadmin_unconfined_script_t).

httpd_t ->  dirsrvadmin_unconfined_script_exec_t -> dirsrvadmin_unconfined_script_t

(In reply to comment #9)
> Then cgi scripts could be running as uncofnined
> (dirsrvadmin_unconfined_script_t).
> 
> httpd_t ->  dirsrvadmin_unconfined_script_exec_t ->
> dirsrvadmin_unconfined_script_t

Is that what we want to do?  I know that some of the CGIs need a lot of access, but wouldn't it still be a good idea to restrict them somewhat?

when start admin server using "service dirsrv-admin start/restart", some function under tasktab is broken (please check screenshot). Below is AVC log msg in audit.log file

type=AVC msg=audit(1309540853.194:21546): avc:  denied  { write } for  pid=9309 comm="sh" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
type=SYSCALL msg=audit(1309540853.194:21546): arch=c000003e syscall=2 success=no exit=-13 a0=a85e90 a1=241 a2=1b6 a3=e items=0 ppid=9308 pid=9309 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=165 comm="sh" exe="/bin/bash" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null)
/bin/sh: /startup.9307: Permission denied

Created attachment 510901 [details]
restart ds console failed if "service dirsrv-admin restart/start/stop" used

(In reply to comment #10)
> (In reply to comment #9)
> > Then cgi scripts could be running as uncofnined
> > (dirsrvadmin_unconfined_script_t).
> > 
> > httpd_t ->  dirsrvadmin_unconfined_script_exec_t ->
> > dirsrvadmin_unconfined_script_t
> 
> Is that what we want to do?  I know that some of the CGIs need a lot of access,
> but wouldn't it still be a good idea to restrict them somewhat?

Which cgi script does these setup stuff?

(In reply to comment #13)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Then cgi scripts could be running as uncofnined
> > > (dirsrvadmin_unconfined_script_t).
> > > 
> > > httpd_t ->  dirsrvadmin_unconfined_script_exec_t ->
> > > dirsrvadmin_unconfined_script_t
> > 
> > Is that what we want to do?  I know that some of the CGIs need a lot of access,
> > but wouldn't it still be a good idea to restrict them somewhat?
> 
> Which cgi script does these setup stuff?

The CGI that does setup is /usr/lib<64>/dirsrv/cgi-bin/ds_create.  The ds_remove CGI in the same directory will need similar access (it removes port labels).

I suggest to add dirsrvadmin_unconfined_script_t domain for these ds_create and ds_remove CGI scripts. 

Can we test it in Fedora?


Dan,
what do you think?

(In reply to comment #15)
> I suggest to add dirsrvadmin_unconfined_script_t domain for these ds_create and
> ds_remove CGI scripts. 
> 
> Can we test it in Fedora?

If you make me a scratch build for F14, I can test it out.

Sounds good to me.

(In reply to comment #16)
> (In reply to comment #15)
> > I suggest to add dirsrvadmin_unconfined_script_t domain for these ds_create and
> > ds_remove CGI scripts. 
> > 
> > Can we test it in Fedora?
> 
> If you make me a scratch build for F14, I can test it out.


I added fixes to this scratch build 

http://koji.fedoraproject.org/koji/taskinfo?taskID=3208710

Thanks for testing.

The test package looks much better, though I still see a different AVC when creating a new DS instance through Console:

------------------------------------------------------------------------
type=AVC msg=audit(1311098615.144:31251): avc:  denied  { read } for  pid=3831 comm="ns-slapd" name="ldif_5vg0U.ldif" dev=dm-0 ino=930336 scontext=system_u:system_r:dirsrv_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dirsrvadmin_tmp_t:s0 tclass=file
type=AVC msg=audit(1311098615.144:31251): avc:  denied  { open } for  pid=3831 comm="ns-slapd" name="ldif_5vg0U.ldif" dev=dm-0 ino=930336 scontext=system_u:system_r:dirsrv_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dirsrvadmin_tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1311098615.144:31251): arch=c000003e syscall=2 success=yes exit=10 a0=218a6e0 a1=0 a2=0 a3=7fae79911960 items=0 ppid=3829 pid=3831 auid=500 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=1 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0-s0:c0.c1023 key=(null)
------------------------------------------------------------------------

The CGI creates an LDIF file that ns-slapd needs to read and import.  This LDIF is labelled as dirsrvadmin_tmp_t, but ns-slapd (dirsrv_t) is not allowed to open it.  I think we should be OK if we add this access, though I'd like another test package just to verify it.

Great, I will do another test package.

There is a new scratch build

http://koji.fedoraproject.org/koji/taskinfo?taskID=3217654

(In reply to comment #21)
> There is a new scratch build
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3217654

This build seems to work.  I can create and remove DS instances through Console in enforcing mode with no AVC messages.

How about #710357 bug.

(In reply to comment #23)
> How about #710357 bug.

I didn't test that, as it doesn't look like you changed the label on the ds_start, ds_restart, or start_config_ds CGIs.

Ah, yes .. could you test it using chcon

# chcon -t dirsrvadmin_unconfined_script_exec_t PATHTO/ds_start
# chcon -t dirsrvadmin_unconfined_script_exec_t PATHTO/ds_restart
# chcon -t dirsrvadmin_unconfined_script_exec_t PATHTO/start_config_ds

(In reply to comment #25)
> Ah, yes .. could you test it using chcon
> 
> # chcon -t dirsrvadmin_unconfined_script_exec_t PATHTO/ds_start
> # chcon -t dirsrvadmin_unconfined_script_exec_t PATHTO/ds_restart
> # chcon -t dirsrvadmin_unconfined_script_exec_t PATHTO/start_config_ds

See my update in bug#710357.  I don't believe that making these 3 start scripts dirsrvadmin_unconfined_script_exec_t is the right approach.

Fixed in selinux-policy-3.7.19-105.el6

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, several labels were incorrect and rules for creating new 389-ds instances were missing. As a result, access vector caches (AVC) appeared when a new 389-ds instance was created through the 389-console. This update fixes the labels and adds the missing rules. Now, new 389-ds instances are created without further errors.

389-ds folks,
could you re-test it because we see 

https://bugzilla.redhat.com/show_bug.cgi?id=750934#c9

is this the correct testing?

(In reply to comment #31)
> 389-ds folks,
> could you re-test it because we see 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=750934#c9
> 
> is this the correct testing?

Need more info from the above bug.  Specifically, was setup-ds-admin.pl run to set up the directory server/admin server?  If so, were there any errors?

(In reply to comment #31)
> 389-ds folks,
> could you re-test it because we see 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=750934#c9
> 
> is this the correct testing?

I just tested instance creation via redhat-idm-console on an updated RHEL 6.2 system using the latest RHDS 9.0 packages and selinux-policy-3.7.19-123.el6 in enforcing mode.  Everything worked fine with no AVC messages reported.  I did not remove unconfined as mentioned in bug 750934.

Thanks Nathan.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1511.html