Bug 1627114 - sbd is unable to list watchdogs with selinux enabled
Summary: sbd is unable to list watchdogs with selinux enabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.6
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 1475318 1628988 1629017 1629020
TreeView+ depends on / blocked
 
Reported: 2018-09-10 13:20 UTC by Tomas Jelinek
Modified: 2018-10-30 10:10 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1628988 1629017 (view as bug list)
Environment:
Last Closed: 2018-10-30 10:09:41 UTC
Target Upstream Version:


Attachments (Terms of Use)
dump of avcs created during sbd traversing /dev (24.66 KB, text/plain)
2018-09-11 12:33 UTC, Klaus Wenninger
no flags Details
avcs with sys added to policy (23.14 KB, text/plain)
2018-09-11 12:38 UTC, Klaus Wenninger
no flags Details
avcs in permissive mode as a reply to comment #22 (19.64 KB, text/plain)
2018-09-11 14:53 UTC, Klaus Wenninger
no flags Details
ausearch output requested in comment 17 (18.98 KB, text/plain)
2018-09-11 14:56 UTC, Tomas Jelinek
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3111 None None None 2018-10-30 10:10:52 UTC

Description Tomas Jelinek 2018-09-10 13:20:51 UTC
Description of problem:
When running sbd from pcsd to get a list of watchdogs on a node, sbd does not list all the watchdogs available.


Version-Release number of selected component (if applicable):
sbd-1.3.1-8.el7.x86_64


How reproducible:
always, easily


Steps to Reproduce:
1. setenforce 1
2. pcs stonith sbd watchdog list
3. pcs stonith sbd enable --watchdog=/dev/watchdog0

detailed reproducer: bz1475318 comment 19


Actual results:
Step 2 lists two watchdogs:
/dev/watchdog
/dev/watchdog0 - this is a softdog

Step 3 says wathchdog0 does not exist:
Running SBD pre-enabling checks...
Error: Watchdog '/dev/watchdog0' does not exist on node 'light-03'
Error: Watchdog '/dev/watchdog0' does not exist on node 'light-02'
Error: Errors have occurred, therefore pcs is unable to continue


Expected results:
sbd should list the watchdogs


Additional info:
This seems to be related to selinux. When listing watchdogs from pcsd, this goes to audit.log:
type=AVC msg=audit(1536582672.280:500): avc:  denied  { read } for  pid=21824 comm="sbd" name="watchdog" dev="sysfs" ino=2968 scontext=system_u:system_r:sbd_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=SYSCALL msg=audit(1536582672.280:500): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=40d244 a2=90800 a3=0 items=0 ppid=21821 pid=21824 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sbd" exe="/usr/sbin/sbd" subj=system_u:system_r:sbd_t:s0 key=(null)
type=PROCTITLE msg=audit(1536582672.280:500): proctitle=2F7573722F7362696E2F7362640071756572792D7761746368646F67

There is also a bunch of similar lines mentioning the following paths: /dev/autofs /dev/btrfs-control /dev/cpu_dma_latency /dev/crash /dev/fb0 /dev/fuse /dev/hpet /dev/kmsg /dev/loop-control /dev/mcelog /dev/mem /dev/network_latency /dev/network_throughput /dev/nvram /dev/oldmem /dev/port /dev/ppp /dev/ptmx /dev/rtc0 /dev/rtc0 /dev/sg0 /dev/snapshot /dev/sr0 /dev/uhid /dev/uinput /dev/usbmon0 /dev/usbmon1 /dev/usbmon2 /dev/usbmon3 /dev/usbmon4 /dev/vga_arbiter /dev/vhci /dev/vhost-net /proc/kcore /run/systemd/initctl/fifo



find / -inum 2968
/usr/share/alsa/cards/GUS.conf
/sys/class/watchdog
/sys/kernel/debug/tracing/events/power/pm_qos_update_request_timeout/format

Comment 1 Jan Pokorný [poki] 2018-09-10 14:25:47 UTC
Three things:

1. on Linux, it shall not be needed to scan /dev tree manually when
   sysfs' class/watchdog listing managed to collect anything
   (rationale: watchdog device drivers need to follow the API/protocol
    to be usefully exposed through kernel, and that's what will get
    the actual devices registered, and in turn, exposed through sysfs)

That would prevent unnecessary /dev lookups (at least singly redundant
since /dev/watchdog is merely a compatibility miscdev) and hence SELinux
complaining about /dev/[random device] accesses.

2. when on Linux and the sysfs scan is fruitless, as an extension
   of what's been said already, there's no point in trying further
   (unless very old Linux compatibility is needed, which likely it
   is not?)

3. to solve sysfs access guarded by SELinux alone, this looks like
   a viable solution:

--- sbd.te.orig	2018-09-10 16:20:26.346312881 +0200
+++ sbd.te	2018-09-10 16:20:31.664376819 +0200
@@ -44,6 +44,7 @@
 
 dev_read_rand(sbd_t)
 dev_write_watchdog(sbd_t)
+dev_read_sysfs(sbd_t)
 
 domain_read_all_domains_state(sbd_t)

Comment 2 Jan Pokorný [poki] 2018-09-10 14:42:19 UTC
Rechecked, and sorry for confusion, there are also "legacy" watchdog
devices, but there can only be one and only one (exactly /dev/watchdog).

So replace unconditional redundancy with conditional one at 1.,
and make only /dev/watchdog checked in addition at 2.

Comment 3 Klaus Wenninger 2018-09-10 15:24:36 UTC
(In reply to Jan Pokorný from comment #2)
> Rechecked, and sorry for confusion, there are also "legacy" watchdog
> devices, but there can only be one and only one (exactly /dev/watchdog).
> 
> So replace unconditional redundancy with conditional one at 1.,
> and make only /dev/watchdog checked in addition at 2.

The idea of the approach is to require as little as possible regarding how the device-nodes do get into the /dev-directory.
Main thing in mind are fancy udev-rules (like the ones for persistent netdevice naming e.g.) or anything created there manually.
Scanning of sysfs and storage into user-space is done so that what is found under /dev can be matched efficiently.

Comment 4 Klaus Wenninger 2018-09-10 15:31:52 UTC
(In reply to Klaus Wenninger from comment #3)
> (In reply to Jan Pokorný from comment #2)
> > Rechecked, and sorry for confusion, there are also "legacy" watchdog
> > devices, but there can only be one and only one (exactly /dev/watchdog).
> > 
> > So replace unconditional redundancy with conditional one at 1.,
> > and make only /dev/watchdog checked in addition at 2.
> 
> The idea of the approach is to require as little as possible regarding how
> the device-nodes do get into the /dev-directory.
> Main thing in mind are fancy udev-rules (like the ones for persistent
> netdevice naming e.g.) or anything created there manually.
> Scanning of sysfs and storage into user-space is done so that what is found
> under /dev can be matched efficiently.

Poor performance should be acceptable as the discovery is just done when the cluster is setup and not on each and every start or even more often.

Comment 6 Klaus Wenninger 2018-09-10 17:35:38 UTC
For RHEL-7.5 patch as proposed by poki seems to do the trick:

diff --git a/policy-rhel-7.5-contrib.patch b/policy-rhel-7.5-contrib.patch
index 44d3736..f343fc1 100644
--- a/policy-rhel-7.5-contrib.patch
+++ b/policy-rhel-7.5-contrib.patch
@@ -99355,7 +99355,7 @@ new file mode 100644
 index 0000000000..7d54ef1d63
 --- /dev/null
 +++ b/sbd.te
-@@ -0,0 +1,62 @@
+@@ -0,0 +1,63 @@
 +policy_module(sbd, 1.0.0)
 +
 +########################################
@@ -99402,6 +99402,7 @@ index 0000000000..7d54ef1d63
 +
 +dev_read_rand(sbd_t)
 +dev_write_watchdog(sbd_t)
++dev_read_sysfs(sbd_t)
 +
 +domain_read_all_domains_state(sbd_t)
 +

Comment 11 Milos Malik 2018-09-11 11:56:21 UTC
Please collect SELinux denials which are triggered by the reproducer:

# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

Thank you.

Comment 12 Klaus Wenninger 2018-09-11 12:33:52 UTC
Created attachment 1482348 [details]
dump of avcs created during sbd traversing /dev

Comment 13 Klaus Wenninger 2018-09-11 12:38:31 UTC
Created attachment 1482349 [details]
avcs with sys added to policy

Comment 14 Klaus Wenninger 2018-09-11 12:40:20 UTC
took the freedom to add the avc-lists from my setup.
First without and afterwards with dev_read_sysfs(sbd_t) added.
Traversing /dev still adds a lot of avcs but the watchdog-ones are missing after the modification.

Comment 15 Klaus Wenninger 2018-09-11 12:49:00 UTC
Tried the following:

[root@node2 ~]# ls -l /dev/watch*
crw-------. 1 root root  10, 130 Sep 10 19:29 /dev/watchdog
crw-------. 1 root root 252,   1 Sep 10 19:29 /dev/watchdog1

[root@node2 ~]# mknod /dev/testwatch c 10 130
[root@node2 ~]# mknod /dev/testwatch1 c 252 1
[root@node2 ~]# sbd query-watchdog

Discovered 4 watchdog devices:

[1] /dev/watchdog
Identity: i6300ESB timer
Driver: <unknown>

[2] /dev/watchdog1
Identity: Software Watchdog
Driver: softdog
CAUTION: Not recommended for use with sbd.

[3] /dev/testwatch
Identity: i6300ESB timer
Driver: <unknown>

[4] /dev/testwatch1
Identity: Software Watchdog
Driver: softdog
CAUTION: Not recommended for use with sbd.

fine that far ...

both

pcs stonith sbd enable --watchdog=/dev/testwatch
pcs stonith sbd enable --watchdog=/dev/testwatch1

are failing with selinux enabled showing that adding 
dev_read_sysfs(sbd_t) to the policy is not enough :-(

Comment 16 Chris Feist 2018-09-11 13:44:18 UTC
Milos,

Comment #12 should have the output of that command, let us know if you need anything else from there.

Thanks,
Chris

Comment 17 Milos Malik 2018-09-11 14:17:37 UTC
Please run following command:

# semanage permissive -a sbd_t

The command will switch the sbd_t domain (which causes denials) to permissive mode while the rest of system stays in enforcing mode. Re-run the reproducer and collect SELinux denials via ausearch:

# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

Following command switches the sbd_t back to enforcing mode:

# semanage permissive -d sbd_t

Thank you.

Comment 18 Jan Pokorný [poki] 2018-09-11 14:27:38 UTC
re [comment 3]:

> (In reply to Jan Pokorný from comment #2)
>> Rechecked, and sorry for confusion, there are also "legacy" watchdog
>> devices, but there can only be one and only one (exactly
>> /dev/watchdog).
>> 
>> So replace unconditional redundancy with conditional one at 1.,
>> and make only /dev/watchdog checked in addition at 2.

> The idea of the approach is to require as little as possible regarding
> how the device-nodes do get into the /dev-directory.
> Main thing in mind are fancy udev-rules (like the ones for persistent
> netdevice naming e.g.) or anything created there manually.
> Scanning of sysfs and storage into user-space is done so that what is
> found under /dev can be matched efficiently.

Is there any issue in reading respective `uevent` file from sysfs
hierarchy right away and parsing `DEVNAME` variable there?  It appears
as if later `/dev` scanning could be skipped altogether, just perhaps
reassuring the device ID matches.  That would be true minimalistic
(regarding overhead) solution as opposed to visiting every and each
`/dev` file, triggering all these security alarms (SELinux, audit rules,
...) for the special ones of them.


re [comment 4]:

> Poor performance should be acceptable as the discovery is just done
> when the cluster is setup and not on each and every start or even
> more often.

Every extra step poses a risk of doing something wrong (see the
security alarms above), not necessarily just in terms of performance.

Comment 19 Jan Pokorný [poki] 2018-09-11 14:32:02 UTC
re [comment 15]:

> failing with selinux enabled showing that adding 
> dev_read_sysfs(sbd_t) to the policy is not enough :-(

Entirely expected, since the likely avoidable (see previous discussion)
extensive `/dev` scan...

re [comment 0]:

> There is also a bunch of similar lines mentioning the following paths:
> /dev/autofs /dev/btrfs-control /dev/cpu_dma_latency /dev/crash /dev/fb0
> /dev/fuse /dev/hpet /dev/kmsg /dev/loop-control /dev/mcelog /dev/mem
> /dev/network_latency /dev/network_throughput /dev/nvram /dev/oldmem
> /dev/port /dev/ppp /dev/ptmx /dev/rtc0 /dev/rtc0 /dev/sg0 /dev/snapshot
> /dev/sr0 /dev/uhid /dev/uinput /dev/usbmon0 /dev/usbmon1 /dev/usbmon2
> /dev/usbmon3 /dev/usbmon4 /dev/vga_arbiter /dev/vhci /dev/vhost-net
> /proc/kcore /run/systemd/initctl/fifo

^ I assume these are also of dedicated contexts different from watchdog
  reifications and hence triggering AVCs

Comment 20 Klaus Wenninger 2018-09-11 14:36:24 UTC
(In reply to Jan Pokorný from comment #19)
> re [comment 15]:
> 
> > failing with selinux enabled showing that adding 
> > dev_read_sysfs(sbd_t) to the policy is not enough :-(
> 
> Entirely expected, since the likely avoidable (see previous discussion)
> extensive `/dev` scan...
> 
> re [comment 0]:
> 
> > There is also a bunch of similar lines mentioning the following paths:
> > /dev/autofs /dev/btrfs-control /dev/cpu_dma_latency /dev/crash /dev/fb0
> > /dev/fuse /dev/hpet /dev/kmsg /dev/loop-control /dev/mcelog /dev/mem
> > /dev/network_latency /dev/network_throughput /dev/nvram /dev/oldmem
> > /dev/port /dev/ppp /dev/ptmx /dev/rtc0 /dev/rtc0 /dev/sg0 /dev/snapshot
> > /dev/sr0 /dev/uhid /dev/uinput /dev/usbmon0 /dev/usbmon1 /dev/usbmon2
> > /dev/usbmon3 /dev/usbmon4 /dev/vga_arbiter /dev/vhci /dev/vhost-net
> > /proc/kcore /run/systemd/initctl/fifo
> 
> ^ I assume these are also of dedicated contexts different from watchdog
>   reifications and hence triggering AVCs

Of course other approaches are possible.
But everything coming to my mind is making more assumptions.
See e.g. my example as of above.
Performance wise it is done once when the cluster is setup ...

Comment 21 Klaus Wenninger 2018-09-11 14:37:40 UTC
(In reply to Milos Malik from comment #17)
> Please run following command:
> 
> # semanage permissive -a sbd_t
> 
> The command will switch the sbd_t domain (which causes denials) to
> permissive mode while the rest of system stays in enforcing mode. Re-run the
> reproducer and collect SELinux denials via ausearch:
> 
> # ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today
> 
> Following command switches the sbd_t back to enforcing mode:
> 
> # semanage permissive -d sbd_t
> 
> Thank you.

setting the sbd_t domain to permissive doesn't show any denials when I repeat the reproduce afterwards.

Comment 22 Milos Malik 2018-09-11 14:45:35 UTC
It seems that we need to switch whole machine to permissive mode to discover all SELinux denials. To be sure that nothing is hidden from us, let's get rid of dontaudit rules too:

1. # setenforce 0
2. # semodule -DB
3. re-run the reproducer
4. collect SELinux denials
5. # semodule -B
6. # setenforce 1

Thanks again. Unfortunately, SELinux troubleshooting sometimes needs more steps.

Comment 23 Klaus Wenninger 2018-09-11 14:53:48 UTC
Created attachment 1482390 [details]
avcs in permissive mode as a reply to comment #22

Comment 24 Tomas Jelinek 2018-09-11 14:56:30 UTC
Created attachment 1482391 [details]
ausearch output requested in comment 17

Data requested in comment 17. This is from a different machine than what Klaus provided, with selinux-policy-3.13.1-192.el7.noarch, no custom policies in place.

Comment 25 Milos Malik 2018-09-11 15:00:44 UTC
Here is the output of audit2allow when collected SELinux denials are piped into it:

#============= sbd_t ==============
allow sbd_t apm_bios_t:chr_file getattr;
allow sbd_t autofs_device_t:chr_file getattr;
allow sbd_t clock_device_t:chr_file getattr;
allow sbd_t crash_device_t:chr_file getattr;
allow sbd_t event_device_t:chr_file getattr;
allow sbd_t framebuf_device_t:chr_file getattr;
allow sbd_t fuse_device_t:chr_file getattr;
allow sbd_t initctl_t:fifo_file getattr;

#!!!! This avc can be allowed using the boolean 'domain_can_write_kmsg'
allow sbd_t kmsg_device_t:chr_file getattr;
allow sbd_t kvm_device_t:chr_file getattr;
allow sbd_t loop_control_device_t:chr_file getattr;
allow sbd_t lvm_control_t:chr_file getattr;
allow sbd_t memory_device_t:chr_file getattr;
allow sbd_t netcontrol_device_t:chr_file getattr;
allow sbd_t nvram_device_t:chr_file getattr;
allow sbd_t ppp_device_t:chr_file getattr;
allow sbd_t proc_kcore_t:file getattr;
allow sbd_t ptmx_t:chr_file getattr;
allow sbd_t sysfs_t:dir read;
allow sbd_t sysfs_t:file { getattr open read };
allow sbd_t sysfs_t:lnk_file read;

#!!!! This avc can be allowed using the boolean 'daemons_use_tty'
allow sbd_t tty_device_t:chr_file getattr;
allow sbd_t uhid_device_t:chr_file getattr;
allow sbd_t usb_device_t:chr_file getattr;
allow sbd_t usbmon_device_t:chr_file getattr;
allow sbd_t vhost_device_t:chr_file getattr;
allow sbd_t xserver_misc_device_t:chr_file getattr;

SELinux denials were collected in permissive mode and after removing dontaudit rules, therefore I believe the list of policy rules to fix this bug is complete.

Thank you.

Comment 27 Milos Malik 2018-09-11 15:07:05 UTC
The are slight differences in the list of policy rules:

#============= sbd_t ==============
allow sbd_t apm_bios_t:chr_file getattr;
allow sbd_t autofs_device_t:chr_file getattr;
allow sbd_t clock_device_t:chr_file getattr;
allow sbd_t crash_device_t:chr_file getattr;
allow sbd_t event_device_t:chr_file getattr;
allow sbd_t framebuf_device_t:chr_file getattr;
allow sbd_t fuse_device_t:chr_file getattr;
allow sbd_t initctl_t:fifo_file getattr;

#!!!! This avc can be allowed using the boolean 'domain_can_write_kmsg'
allow sbd_t kmsg_device_t:chr_file getattr;
allow sbd_t loop_control_device_t:chr_file getattr;
allow sbd_t lvm_control_t:chr_file getattr;
allow sbd_t memory_device_t:chr_file getattr;
allow sbd_t netcontrol_device_t:chr_file getattr;
allow sbd_t nvram_device_t:chr_file getattr;
allow sbd_t ppp_device_t:chr_file getattr;
allow sbd_t proc_kcore_t:file getattr;
allow sbd_t ptmx_t:chr_file getattr;
>> allow sbd_t removable_device_t:blk_file getattr;
>> allow sbd_t scsi_generic_device_t:chr_file getattr;
allow sbd_t sysfs_t:dir read;
allow sbd_t sysfs_t:file { getattr open read };
allow sbd_t sysfs_t:lnk_file read;
allow sbd_t uhid_device_t:chr_file getattr;
allow sbd_t usbmon_device_t:chr_file getattr;
allow sbd_t vhost_device_t:chr_file getattr;
allow sbd_t xserver_misc_device_t:chr_file getattr;

Comment 28 Klaus Wenninger 2018-09-11 15:14:02 UTC
(In reply to Milos Malik from comment #27)
> The are slight differences in the list of policy rules:
> 
> #============= sbd_t ==============
> allow sbd_t apm_bios_t:chr_file getattr;
> allow sbd_t autofs_device_t:chr_file getattr;
> allow sbd_t clock_device_t:chr_file getattr;
> allow sbd_t crash_device_t:chr_file getattr;
> allow sbd_t event_device_t:chr_file getattr;
> allow sbd_t framebuf_device_t:chr_file getattr;
> allow sbd_t fuse_device_t:chr_file getattr;
> allow sbd_t initctl_t:fifo_file getattr;
> 
> #!!!! This avc can be allowed using the boolean 'domain_can_write_kmsg'
> allow sbd_t kmsg_device_t:chr_file getattr;
> allow sbd_t loop_control_device_t:chr_file getattr;
> allow sbd_t lvm_control_t:chr_file getattr;
> allow sbd_t memory_device_t:chr_file getattr;
> allow sbd_t netcontrol_device_t:chr_file getattr;
> allow sbd_t nvram_device_t:chr_file getattr;
> allow sbd_t ppp_device_t:chr_file getattr;
> allow sbd_t proc_kcore_t:file getattr;
> allow sbd_t ptmx_t:chr_file getattr;
> >> allow sbd_t removable_device_t:blk_file getattr;
> >> allow sbd_t scsi_generic_device_t:chr_file getattr;
> allow sbd_t sysfs_t:dir read;
> allow sbd_t sysfs_t:file { getattr open read };
> allow sbd_t sysfs_t:lnk_file read;
> allow sbd_t uhid_device_t:chr_file getattr;
> allow sbd_t usbmon_device_t:chr_file getattr;
> allow sbd_t vhost_device_t:chr_file getattr;
> allow sbd_t xserver_misc_device_t:chr_file getattr;

Well when querying for watchdog devices it is traversing what is found under /dev. So dependent on the setup and which devices are physically present e.g. you will get differences.
This is as well why I'm not so sure if it is wise to add a large list like that.
Would it be possible to allow just any char-device? (Which you would be doing with that list anyway somehow and even more ...)

Comment 29 Milos Malik 2018-09-11 20:45:43 UTC
Lukas, can you answer the question in comment#28?

Comment 30 Klaus Wenninger 2018-09-12 08:55:39 UTC
(In reply to Klaus Wenninger from comment #28)

> Would it be possible to allow just any char-device? (Which you would be
> doing with that list anyway somehow and even more ...)

Just to explain that a little further ...

If it is no strict requirement somewhere to keep the avc-log clean I wouldn't have any problems if a watchdog-query creates some entries when accessing /dev-files that are anyway no valid watchdog-devices.
The current policy for accessing these device-files might even be enough for now (remember adding sys-access-stuff to the policy makes the pcs-testcase succeed).
Of course it would have been nice to be able to use /dev-files with arbitrary names that reference watchdog-devices (see my test with /dev/testwatch above) but as I got it for now this is no strict requirement. Though being able to find  these files easier was part of the intention why the query-mechanism in sbd is implemented the way it is atm.

Comment 31 Lukas Vrabec 2018-09-12 11:57:03 UTC
Hi All, 

I added all needed rules and issue should be fixed. I'll try to get all needed flags and create build today. 

Thanks,
Lukas.

Comment 32 Klaus Wenninger 2018-09-12 12:13:23 UTC
(In reply to Lukas Vrabec from comment #31)
> Hi All, 
> 
> I added all needed rules and issue should be fixed. I'll try to get all
> needed flags and create build today. 
> 
> Thanks,
> Lukas.

Thanks!
Do you have a link to a scratch-build or something?

Regards,
Klaus

Comment 35 Klaus Wenninger 2018-09-13 09:21:07 UTC
(In reply to Klaus Wenninger from comment #32)
> (In reply to Lukas Vrabec from comment #31)
> > Hi All, 
> > 
> > I added all needed rules and issue should be fixed. I'll try to get all
> > needed flags and create build today. 
> > 
> > Thanks,
> > Lukas.
> 
> Thanks!
> Do you have a link to a scratch-build or something?
> 
> Regards,
> Klaus

Just for completeness ... it now covers what I've tested in comment #15 as well.

Comment 37 Milos Malik 2018-09-13 10:43:52 UTC
Please update the selinux-policy to the latest version (now 3.13.1-225.el7) and re-run your scenario. If the scenario still triggers any SELinux denials, please switch the bug to ASSIGNED.

Comment 38 Klaus Wenninger 2018-09-14 11:08:32 UTC
(In reply to Milos Malik from comment #37)
> Please update the selinux-policy to the latest version (now 3.13.1-225.el7)
> and re-run your scenario. If the scenario still triggers any SELinux
> denials, please switch the bug to ASSIGNED.

Interesting ... I would have expected more SELinux denials to files other than chr but this is the only stuff left:

[root@node2 ~]# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts 12:54:22
----
type=PROCTITLE msg=audit(09/14/2018 12:54:32.419:1029) : proctitle=/usr/sbin/sbd query-watchdog 
type=SYSCALL msg=audit(09/14/2018 12:54:32.419:1029) : arch=x86_64 syscall=stat success=no exit=EACCES(Permission denied) a0=0x7fff5b2c03f0 a1=0x7fff5b2c0050 a2=0x7fff5b2c0050 a3=0x2 items=0 ppid=28507 pid=28510 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=sbd exe=/usr/sbin/sbd subj=system_u:system_r:sbd_t:s0 key=(null) 
type=AVC msg=audit(09/14/2018 12:54:32.419:1029) : avc:  denied  { getattr } for  pid=28510 comm=sbd path=/run/systemd/initctl/fifo dev="tmpfs" ino=11536 scontext=system_u:system_r:sbd_t:s0 tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file 
----
type=PROCTITLE msg=audit(09/14/2018 12:54:32.419:1030) : proctitle=/usr/sbin/sbd query-watchdog 
type=SYSCALL msg=audit(09/14/2018 12:54:32.419:1030) : arch=x86_64 syscall=stat success=no exit=EACCES(Permission denied) a0=0x7fff5b2c03f0 a1=0x7fff5b2c0050 a2=0x7fff5b2c0050 a3=0x2 items=0 ppid=28507 pid=28510 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=sbd exe=/usr/sbin/sbd subj=system_u:system_r:sbd_t:s0 key=(null) 
type=AVC msg=audit(09/14/2018 12:54:32.419:1030) : avc:  denied  { getattr } for  pid=28510 comm=sbd path=/proc/kcore dev="proc" ino=4026532033 scontext=system_u:system_r:sbd_t:s0 tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file 

As already said above: If we don't have a strategy to fully prevent SELinux denial entries this is perfectly fine.
The two files are referenced via symlinks from /dev.
Not sure if it exactly makes sense to give more rights to sbd because of that.
I would explicitly like to support symlinks (as they might be used to have persistent ordering of watchdog-devices) but I could of course leave aside everything that points outside of /dev in sbd.

Comment 39 Klaus Wenninger 2018-09-14 11:25:27 UTC
(In reply to Klaus Wenninger from comment #38)

> 
> Interesting ... I would have expected more SELinux denials to files other
> than chr but this is the only stuff left:
> 

Ok, do understand why we don't have more - just getting the denial on stat and that is skipped for anything else but DT_CHR or DT_LNK.

Comment 40 Klaus Wenninger 2018-09-14 14:00:24 UTC
(In reply to Klaus Wenninger from comment #38)

> I would explicitly like to support symlinks (as they might be used to have
> persistent ordering of watchdog-devices) but I could of course leave aside
> everything that points outside of /dev in sbd.

Tried with sbd skipping symlinks not pointing into /dev and that leads to empty avs-log as expected.

But actually there is a little bit more to it:

In my example I'm using a symlink of arbitrary name that points to a kernel-created watchdog-file. That is working as access will first follow the symlink and then selinux checks the context of the target (watchdog_device_t in that case).
If somebody on the other hand creates a node of arbitrary name using the major:minor of a watchdog device that is gonna land in the unconfined-context and thus sbd won't be allowed to access the file.
Unless of course it is added to the watchdog_device_t-context.

Comment 42 errata-xmlrpc 2018-10-30 10:09:41 UTC
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.

https://access.redhat.com/errata/RHBA-2018:3111


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