Bug 1406470
Summary: | SELinux "preventing rpc.mountd from ioctl access on the blk_file /dev/rbd1" when sharing rbd device over NFS and mounting as v3 on a client | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Kyle Squizzato <ksquizza> |
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | branto, ceph-eng-bugs, cww, gmeno, hnallurv, jpr, kdreyer, lvrabec, mgrepl, mmalik, plautrba, pvrabec, ssekidde, vumrao |
Target Milestone: | rc | ||
Target Release: | 7.3 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-10-30 09:59:46 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1477664 |
Description
Kyle Squizzato
2016-12-20 15:43:50 UTC
Hi, thanks for the detailed report. It is true that we do not set a specific label for the rbd devices. This just means that they will inherit the label from their parent directory (i.e. they will be device_t). We could change this and provide a new label for these files so that people can fine-tune their policy specifically for the rbd files but we did not do it simply because we did not need it so far. Even if we do that, I do not think we want to allow the generic ioctl access to these files for rpc/nfs daemons in our policy (we are not the ones that need it). If I understand it correctly, the customer is building an application on top of our product and the application itself needs this permission. Therefore, it is their application that should handle these SELinux permissions in its own SELinux policy -- they can easily generate the policy with audit2allow from the avc denials or they can simply manage these rules (semi-)manually as described in the 'Plugin device' suggestion. btw: The fact that you could not reproduce this can very well be related to the fact that you are running these commands from the terminal, i.e. in an unconfined mode, while they might be running them in a confined mode. [1] probably we even should change the label at some point in the future -- we did not do it simply because we did not need it so far Regards, Boris (In reply to Boris Ranto from comment #1) > If I understand it correctly, the customer is building an application on top > of our product and the application itself needs this permission. From my understanding, it's not any specialized application it's just kernel NFS that we ship which has it's own SELinux policy. (In reply to Kyle Squizzato from comment #2) > (In reply to Boris Ranto from comment #1) > > If I understand it correctly, the customer is building an application on top > > of our product and the application itself needs this permission. > > From my understanding, it's not any specialized application it's just kernel > NFS that we ship which has it's own SELinux policy. Well, kinda. The SELinux does not allow the rpc.mountd daemon to access the files in /dev but I believe this is by design. The nfs usually exports regular directories (and files), not /dev (or files under /dev). The whole point of SELinux is to not give hacked daemons too much kernel over the system -- if we allowed the access by default then a hacked rpc.mountd could access the block devices which is definitely not good. However, the customer seems to be building an application where exporting /dev is a common scenario. It is their application that requires this access and hence, it is that application that should handle it by a policy. (In reply to Boris Ranto from comment #4) > (In reply to Kyle Squizzato from comment #2) > > (In reply to Boris Ranto from comment #1) > > > If I understand it correctly, the customer is building an application on top > > > of our product and the application itself needs this permission. > > > > From my understanding, it's not any specialized application it's just kernel > > NFS that we ship which has it's own SELinux policy. > > Well, kinda. The SELinux does not allow the rpc.mountd daemon to access the > files in /dev but I believe this is by design. The nfs usually exports > regular directories (and files), not /dev (or files under /dev). The whole > point of SELinux is to not give hacked daemons too much kernel over the > system -- if we allowed the access by default then a hacked rpc.mountd could > access the block devices which is definitely not good. > > However, the customer seems to be building an application where exporting > /dev is a common scenario. It is their application that requires this access > and hence, it is that application that should handle it by a policy. Well in reality they're not really exporting /dev, they're utilizing rbd in the same way that you'd use a traditional block device. They've mapped the rbd device to the NFS server as /dev/rbd0, formatted it with XFS and then mounted that to a directory such as /mnt/export then exported /mnt/export. That's what makes it odd (and my SELinux foo is poor so maybe I'm just missing something) I would expect NFS's services to be none the wiser and just think that it's any other block device. Now, that makes much more sense. It could be that this is caused by us not labelling the /dev/rbdX files properly and using a generic device_t label instead of fixed_disk_device_t (that is the one that most mountable devices like sd or dm use) or creating our own label (probably preferred). Will running something like this # chcon -t fixed_disk_device_t /dev/rbd* help you in this case (if it does then please note that it is just a temporary fix/workaround)? In any case, since this is kernel/client-side and we ship the kernel/client bits in RHEL, we might need to fix it there (reassigning). SELinux policy already contains correct file labeling patterns: # rpm -qa selinux\* selinux-policy-3.13.1-102.el7.noarch selinux-policy-targeted-3.13.1-102.el7.noarch # matchpathcon /dev/rdb0 /dev/rdb0 system_u:object_r:fixed_disk_device_t:s0 # matchpathcon /dev/rdb1 /dev/rdb1 system_u:object_r:fixed_disk_device_t:s0 # How are the /dev/rdb* devices created? Do they exist since the boot? @Milos: They are created at runtime through CLI or via an init script at boot time (the script runs rbdmap command that reads /etc/ceph/rbdmap and maps the described devices). This should both be created well after the kernel is initiated. Here are is the matchpathcon con info for some of the relevant files (included /home for comparison, not currently sharing /home). $ matchpathcon /dev/rbd0 /storage/ceph/rstore/user/testuser/default /dev/mapper/rhel_ceph--admin--01-home /home /dev/rbd0 system_u:object_r:device_t:s0 /storage/ceph/rstore/user/testuser/default system_u:object_r:default_t:s0 /dev/mapper/rhel_ceph--admin--01-home system_u:object_r:device_t:s0 /home system_u:object_r:home_root_t:s0 And the df: Filesystem Size Used Avail Use% Mounted on /dev/rbd0 1.0T 34M 1.0T 1% /storage/ceph/rstore/user/testuser/default /dev/mapper/rhel_ceph--admin--01-home 1.1T 133M 1.1T 1% /home And the relevant lines from mount: nfsd on /proc/fs/nfsd type nfsd (rw,relatime) /dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota) /dev/mapper/rhel_ceph--admin--01-home on /home type xfs (rw,relatime,seclabel,attr2,inode64,noquota) /dev/rbd0 on /storage/ceph/rstore/user/testuser/default type xfs (rw,relatime,seclabel,attr2,inode64,sunit=8192,swidth=8192,noquota) The rbd device gets mapped at boot. During create it is formatted and then mounted. The problem I see is only with rpc.mountd TCP listener. The UDP listener appears to start fine. Here's the output from rpcinfo: $ rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 10002 status 100005 1 udp 10004 mountd 100005 2 udp 10004 mountd 100005 3 udp 10004 mountd 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 3 tcp 2049 nfs_acl 100021 1 udp 10006 nlockmgr 100021 3 udp 10006 nlockmgr 100021 4 udp 10006 nlockmgr 100021 1 tcp 10006 nlockmgr 100021 3 tcp 10006 nlockmgr 100021 4 tcp 10006 nlockmgr I'll test the proposed work around. [root@rhel7 ~]# sesearch -A -s nfsd_t -t fixed_disk_device_t -c blk_file Found 3 semantic av rules: allow nfsd_t fixed_disk_device_t : blk_file { ioctl read getattr lock open } ; allow nfsd_t device_node : blk_file getattr ; allow nfsd_t device_node : blk_file getattr ; [root@rhel7 ~]# matchpathcon /dev/rdb0 /dev/rdb0 system_u:object_r:fixed_disk_device_t:s0 [root@rhel7 ~]# matchpathcon /dev/rdb1 /dev/rdb1 system_u:object_r:fixed_disk_device_t:s0 This issue looks fixed from my POV. Could somebody test this? # rpm -qa selinux\* selinux-policy-targeted-3.13.1-189.el7.noarch selinux-policy-3.13.1-189.el7.noarch # There is a typo error in file context patterns: # matchpathcon /dev/rbd0 /dev/rbd0 system_u:object_r:device_t:s0 # matchpathcon /dev/rdb0 /dev/rdb0 system_u:object_r:fixed_disk_device_t:s0 # Please notice that "rbd" and "rdb" are different strings. This bug is NOT fixed. 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 |