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?
--- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
On 06/06/2017 09:17 AM, Vanhorn, Mike wrote:
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?
Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
If you run this avc though audit2why what does it say?
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
--- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
On 6/6/17, 9:29 AM, "Daniel Walsh" dwalsh@redhat.com wrote:
If you run this avc though audit2why what does it say?
On 06/06/2017 09:41 AM, Vanhorn, Mike wrote:
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
Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
On 6/6/17, 9:29 AM, "Daniel Walsh" dwalsh@redhat.com wrote:
If you run this avc though audit2why what does it say?
I am asking if you run it again, does it change. If the boolean is set the audit2why should say that the AVC is allowed.
On 6/6/17, 12:38 PM, "Daniel Walsh" dwalsh@redhat.com wrote:
I am asking if you run it again, does it change. If the boolean is set the audit2why should say that the AVC is allowed.
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=2413 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: 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.
--- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
On 06/06/2017 01:19 PM, Vanhorn, Mike wrote:
On 6/6/17, 12:38 PM, "Daniel Walsh" dwalsh@redhat.com wrote:
I am asking if you run it again, does it change. If the boolean is set the audit2why should say that the AVC is allowed.
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=2413 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: 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.
Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
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?
On 6/6/17, 1:48 PM, "Daniel Walsh" dwalsh@redhat.com wrote:
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!
--- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
-
Daniel Walsh -
Vanhorn, Mike