Bug 677802

Easy to reproduce:

Feb 16 03:24:43 pogolinux-2 kernel: type=1400 audit(1297844683.520:4): avc:  denied  { search } for  pid=5888 comm="fenced" name="dbus" dev=dm-0 ino=654841 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir

So is this needed also for other cluster services?

It looks there is a lot of changes related to cluster services.

Nate, 
could you run 

# semanage permissive -a $cluster_service

if you see some AVC msgs for a cluster service to collect all AVC. 

I wish we could catch these issues in the devel time.

(In reply to comment #2)
> So is this needed also for other cluster services?
> 
> It looks there is a lot of changes related to cluster services.
> 
> Nate, 
> could you run 
> 
> # semanage permissive -a $cluster_service
> 
> if you see some AVC msgs for a cluster service to collect all AVC. 
> 
> I wish we could catch these issues in the devel time.

Not sure what is going on here:

# semanage permissive -a fenced
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 556, in <module>
    process_args(sys.argv[1:])
  File "/usr/sbin/semanage", line 433, in process_args
    OBJECT.add(target)
  File "/usr/lib64/python2.6/site-packages/seobject.py", line 373, in add
    mc.create_module_package(filename, 1)
  File "/usr/lib64/python2.6/site-packages/sepolgen/module.py", line 172, in create_module_package
    self.refpol_build(sourcename)
  File "/usr/lib64/python2.6/site-packages/sepolgen/module.py", line 186, in refpol_build
    raise RuntimeError("compilation failed:\n%s" % self.last_output)
RuntimeError: compilation failed:
find: unknown predicate `-D.te'
/usr/share/selinux/devel/include/Makefile:211: warning: overriding commands for target `permissive_fenced'
/usr/share/selinux/devel/include/Makefile:208: warning: ignoring old commands for target `permissive_fenced'
make: *** No rule to make target `-D.pp', needed by `all'.  Stop.

# setenforce 0
# service cman start

From /var/log/audit/audit.log

type=AVC msg=audit(1297884146.090:22577): avc:  denied  { search } for  pid=2786 comm="fenced" name="dbus" dev=dm-0 ino=393854 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir
type=AVC msg=audit(1297884146.090:22577): avc:  denied  { write } for  pid=2786 comm="fenced" name="system_bus_socket" dev=dm-0 ino=396077 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file
type=AVC msg=audit(1297884146.090:22577): avc:  denied  { connectto } for  pid=2786 comm="fenced" path="/var/run/dbus/system_bus_socket" scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=unix_stream_socket
type=SYSCALL msg=audit(1297884146.090:22577): arch=c000003e syscall=42 success=yes exit=0 a0=5 a1=7ffff8d35d60 a2=21 a3=7ffff8d35ad0 items=0 ppid=1 pid=2786 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="fenced" exe="/usr/sbin/fenced" subj=unconfined_u:system_r:fenced_t:s0 key=(null)
type=USER_AVC msg=audit(1297884146.098:22578): user pid=1484 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=2786 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

optional_policy(`
	dbus_system_bus_client(cluster_domain)
')

We can add this, but do we need more, are the cluster daemons going to be sending each other dbus messages.

	allow cluster_domain cluster_domain:dbus send_msg;


Are any of the cluster domains going to be started on demand by dbus?

I do expect the cluster daemons to be sending each other dbus messages.  I do not expect cluster daemons to be started via dbus.

Lon or Ryan, is that correct?

(In reply to comment #5)
> optional_policy(`
>  dbus_system_bus_client(cluster_domain)
> ')
> 
> We can add this, but do we need more, are the cluster daemons going to be
> sending each other dbus messages.

Only fenced and rgmanager will be sending dbus signals. Those signals aren't actually to each other, since dbus signals are broadcast. There is a new service called 'foghorn' that listens for these signals and generates SNMP traps from them. I've not seen any selinux problems with the foghorn service.

Actually there is a third component that can/will talk to dbus -- corosync-notifyd. The corosync developers have not mentioned any problems with selinux when using dbus, but I will verify.

>  allow cluster_domain cluster_domain:dbus send_msg;
> 
> 
> Are any of the cluster domains going to be started on demand by dbus?

No.

Well corosync-notifyd and foghorn are probably running as initrc_t which would mean they are unconfined.

(In reply to comment #3)
> (In reply to comment #2)
> > So is this needed also for other cluster services?
> > 
> > It looks there is a lot of changes related to cluster services.
> > 
> > Nate, 
> > could you run 
> > 
> > # semanage permissive -a $cluster_service
> > 
> > if you see some AVC msgs for a cluster service to collect all AVC. 
> > 
> > I wish we could catch these issues in the devel time.
> 
> Not sure what is going on here:
> 
> # semanage permissive -a fenced
> Traceback (most recent call last):
>   File "/usr/sbin/semanage", line 556, in <module>
>     process_args(sys.argv[1:])

Oops, I meant this format

# semanage permissive -a fenced_t

(In reply to comment #7)
> (In reply to comment #5)
> > optional_policy(`
> >  dbus_system_bus_client(cluster_domain)
> > ')
> > 
> > We can add this, but do we need more, are the cluster daemons going to be
> > sending each other dbus messages.
> 
> Only fenced and rgmanager will be sending dbus signals. Those signals aren't
> actually to each other, since dbus signals are broadcast. There is a new
> service called 'foghorn' that listens for these signals and generates SNMP
> traps from them. I've not seen any selinux problems with the foghorn service.
> 
> Actually there is a third component that can/will talk to dbus --
> corosync-notifyd. The corosync developers have not mentioned any problems with
> selinux when using dbus, but I will verify.
> 

Thanks. I would imagine there will be other avc msgs.

Fixed in selinux-policy-3.7.19-71.el6

(In reply to comment #10)
> (In reply to comment #7)
> > (In reply to comment #5)
> > > optional_policy(`
> > >  dbus_system_bus_client(cluster_domain)
> > > ')
> > > 
> > > We can add this, but do we need more, are the cluster daemons going to be
> > > sending each other dbus messages.
> > 
> > Only fenced and rgmanager will be sending dbus signals. Those signals aren't
> > actually to each other, since dbus signals are broadcast. There is a new
> > service called 'foghorn' that listens for these signals and generates SNMP
> > traps from them. I've not seen any selinux problems with the foghorn service.
> > 
> > Actually there is a third component that can/will talk to dbus --
> > corosync-notifyd. The corosync developers have not mentioned any problems with
> > selinux when using dbus, but I will verify.
> > 
> 
> Thanks. I would imagine there will be other avc msgs.

Yes, I assume that is the case.

Lon and I did not see any avc denials when running rgmanager, which is surprising. I'll test this latest policy and post the results. Thanks.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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