This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 840956 - ns-slapd dirsrv_t netlink_route_socket denials
ns-slapd dirsrv_t netlink_route_socket denials
Status: CLOSED WORKSFORME
Product: 389
Classification: Community
Component: Security - General (Show other bugs)
1.2.8
All Linux
low Severity low
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
Depends On: 740925
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-17 13:04 EDT by Orion Poplawski
Modified: 2015-01-04 18:52 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 740925
Environment:
Last Closed: 2013-03-04 17:28:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2012-07-17 13:04:56 EDT
+++ This bug was initially created as a clone of Bug #740925 +++

Description of problem:

On directory server startup I'm seeing (in permissive mode):

type=AVC msg=audit(1316806800.921:105382): avc:  denied  { create } for  pid=2923 comm="ns-slapd" scontext=root:system_r:dirsrv_t:s0 tcontext=root:system_r:dirsrv_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1316806800.922:105383): avc:  denied  { bind } for  pid=2923 comm="ns-slapd" scontext=root:system_r:dirsrv_t:s0 tcontext=root:system_r:dirsrv_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1316806800.922:105384): avc:  denied  { getattr } for  pid=2923 comm="ns-slapd" scontext=root:system_r:dirsrv_t:s0 tcontext=root:system_r:dirsrv_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1316806800.922:105385): avc:  denied  { write } for  pid=2923 comm="ns-slapd" scontext=root:system_r:dirsrv_t:s0 tcontext=root:system_r:dirsrv_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1316806800.922:105385): avc:  denied  { nlmsg_read } for  pid=2923 comm="ns-slapd" scontext=root:system_r:dirsrv_t:s0 tcontext=root:system_r:dirsrv_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1316806800.922:105386): avc:  denied  { read } for  pid=2923 comm="ns-slapd" scontext=root:system_r:dirsrv_t:s0 tcontext=root:system_r:dirsrv_t:s0 tclass=netlink_route_socket

Did not appear to affect my operation so far.

Version-Release number of selected component (if applicable):
389-ds-base-1.2.9.9-1.el5
selinux-policy-2.4.6-316.el5

--- Additional comment from ksrot@redhat.com on 2011-10-06 09:58:55 EDT ---

> Did not appear to affect my operation so far.

Hi, 
do you say it did not appear to affect your operation when in enforcing, right?
Thank you.

--- Additional comment from dwalsh@redhat.com on 2011-10-06 10:30:17 EDT ---

These avc's are often related to using getpw calls, and usually end up needing
auth_use_nsswitch()

--- Additional comment from orion@cora.nwra.com on 2011-10-06 10:48:51 EDT ---

(In reply to comment #1)
> > Did not appear to affect my operation so far.
> 
> Hi, 
> do you say it did not appear to affect your operation when in enforcing, right?
> Thank you.

Correct, everything is apparently fine even in enforcing.

--- Additional comment from rmeggins@redhat.com on 2011-10-07 13:13:12 EDT ---

(In reply to comment #2)
> These avc's are often related to using getpw calls, and usually end up needing
> auth_use_nsswitch()

So is there something that needs to be fixed in package 389-ds-base?

--- Additional comment from nkinder@redhat.com on 2011-10-07 13:22:57 EDT ---

(In reply to comment #4)
> (In reply to comment #2)
> > These avc's are often related to using getpw calls, and usually end up needing
> > auth_use_nsswitch()
> 
> So is there something that needs to be fixed in package 389-ds-base?

It sounds like we need to add auth_use_nsswitch() to the dirsrv_t policy in selinux-policy, as we do call getpwnam() during startup of a DS instance.

--- Additional comment from mgrepl@redhat.com on 2011-10-18 14:41:01 EDT ---

Fixed in selinux-policy-3.7.19-118.el6.noarch

# sesearch -A -s dirsrv_t -t dirsrv_t -c netlink_route_socket
Found 1 semantic av rules:
   allow dirsrv_t dirsrv_t : netlink_route_socket { ioctl read write create getattr setattr lock append bind connect getopt setopt shutdown nlmsg_read } ;

--- Additional comment from errata-xmlrpc@redhat.com on 2011-12-06 05:19:26 EST ---

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
Comment 1 Orion Poplawski 2012-07-17 13:05:35 EDT
Seen in EL5 with selinux-policy-2.4.6-329.el5
Comment 2 RHEL Product and Program Management 2012-07-17 17:08:19 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 3 Miroslav Grepl 2012-07-18 05:11:14 EDT
We need to backport it.
Comment 5 RHEL Product and Program Management 2012-07-30 03:08:32 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 6 Karel Srot 2012-07-30 03:13:48 EDT
Hi,
could you please post a comment why this bug has been moved to nss_ldap and should be fixed here?
Thank you.
Comment 7 Miroslav Grepl 2012-07-30 03:39:21 EDT
dirsrv policy is not part of the base policy in RHEL5.
Comment 8 Jakub Hrozek 2012-07-30 04:34:36 EDT
There is no SELinux policy in nss_ldap either. Did you mean to reassign the bug to Directory Server?
Comment 9 Nathan Kinder 2012-07-30 11:30:40 EDT
I believe this was intended to be assigned to Directory Server.  Red Hat Directory Server on RHEL5 is not confined by SELinux at all.

The reporter appears to be using 389-ds-base bits from EPEL.  This is not a RHEL bug, but should be an upstream 389 bug/ticket.  Moving the bug to the appropriate product.
Comment 10 Miroslav Grepl 2012-07-30 15:40:04 EDT
(In reply to comment #9)
> I believe this was intended to be assigned to Directory Server.  Red Hat
> Directory Server on RHEL5 is not confined by SELinux at all.
> 

Yes, I apologize.
> The reporter appears to be using 389-ds-base bits from EPEL.  This is not a
> RHEL bug, but should be an upstream 389 bug/ticket.  Moving the bug to the
> appropriate product.
Comment 11 Rich Megginson 2012-07-31 13:52:30 EDT
Upstream ticket:
https://fedorahosted.org/389/ticket/420
Comment 12 Nathan Kinder 2013-03-04 17:28:18 EST
This was not reproducible by the upstream development team.  See the upstream ticket mentioned in comment#11 for details.  Closing this bug.

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