Weird SELinux Denial

Home » CentOS » Weird SELinux Denial
CentOS 6 Comments

I keep seeing this in my audit.logs:

type=AVC msg=audit(1496336600.230:6): avc: denied { name_connect } for pid=2411 comm=”dbus-daemon” dest=111 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket

Was caused by:
The boolean allow_ypbind was set incorrectly. Description:
Allow system to run with NIS

Allow access by executing:
# setsebool -P allow_ypbind 1

The weirdness is that when I check allow_ypbind, it’s already on:

# getsebool allow_ypbind allow_ypbind –> on
#

Does anyone with more experience with SELinux than me have any idea why this is happening?

–

6 thoughts on - Weird SELinux Denial

  • It says what it is my original post; that’s the output from audit2allow –w (which is audit2why):

    Was caused by:
    The boolean allow_ypbind was set incorrectly. Description:
    Allow system to run with NIS

    Allow access by executing:
    # setsebool -P allow_ypbind 1

    –

  • Well, if I just run audit2why again, it always tells me the same thing. However, I have now discovered that if I unset allow_ypbind, and then reset it to 1, audit2why then says

    type=AVC msg=audit(1496768649.872:1338): avc: denied { name_connect } for pid$13 comm=”dbus-daemon” dest1 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket

    Was caused by:
    Unknown – would be allowed by active policy
    Possible mismatch between this policy and the one under which the audit message was generated.

    Possible mismatch between current in-memory boolean settings vs. permanent ones.

    –

  • Ok, that works then. The way I read your email indicated that setting the boolean did not allow the access. I take it you are not running with NIS/Yellow pages and yet you see dbus connecting to port 111?

  • Well, previously, I didn’t have to set it, because it already was set, but the denial was still happening (apparently). NIS has been working, which makes it even more confusing.

    But, now that I unset it (set it to 0) and then set it back (to 1), now allow2why seems to understand that the boolean is set (whereas before it seemed to think that the boolean was not set), so I guess I’ll what the log and see what happens.

    Thanks!

    –