On Wed, 1 May 2019 at 12:01, Sean smalder73@gmail.com wrote:
Hello CentOS / RedHat / IBM folks!
I am wondering if I can get a communication channel opened with someone who can affect changes win upstream RHEL? I don't have
File a bug in bugzilla.redhat.com.
support accounts with RHEL, and use CentOS almost exclusively. I did have a direct email conversation with Mr. Daniel Walsh regarding these problems, but his answer was to create custom policy to allow what's being denied, as there is no risk to doing so by his analysis. That said, I'm wondering if this isn't more of a bug or a need to adjust the selinux policy packages to allow the functionality.
The user story is this: Gnome3 user wants to burn a CD/DVD. The system is selinux enforcing, selinux boolean cdrecord_read_content is set to on, and the user is confined to staff_u. When the user runs Brasero to burn a disk, the burn operation fails.
/var/log/audit/audit.log contains the following: type=AVC msg=audit(1556724762.446:1133340): avc: denied { read } for pid=8296 comm="growisofs" name="devices" dev="proc" ino=4026532225 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=file permissive=0 type=AVC msg=audit(1556724762.446:1133341): avc: denied { read } for pid=8296 comm="growisofs" name="meminfo" dev="proc" ino=4026532040 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=file permissive=0 type=AVC msg=audit(1556724763.464:1133343): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/dm-1" dev="devtmpfs" ino=21192 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 type=AVC msg=audit(1556724763.464:1133344): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/sda2" dev="devtmpfs" ino=11888 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 type=AVC msg=audit(1556724763.464:1133345): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/dm-6" dev="devtmpfs" ino=39678 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 type=AVC msg=audit(1556724763.465:1133346): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/sda1" dev="devtmpfs" ino=11887 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 type=AVC msg=audit(1556724763.465:1133347): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/dm-7" dev="devtmpfs" ino=39681 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 type=AVC msg=audit(1556724763.465:1133348): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/dm-5" dev="devtmpfs" ino=39677 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 type=AVC msg=audit(1556724763.465:1133349): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/dm-4" dev="devtmpfs" ino=39676 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 type=AVC msg=audit(1556724763.465:1133350): avc: denied { getattr } for pid=8316 comm="growisofs" path="/dev/dm-3" dev="devtmpfs" ino=43433 scontext=staff_u:staff_r:cdrecord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0
This seems like a reasonable task for a Gnome user to do with out escalating privilege. I can't explain why growisofs needs getattr on all those disk devices, or why it "should" be denied. I have not
It is being denied because it doesn't need gettattr on those devices as that utility. So the utility is just sort of walking around looking for drives it could change.. and while getattr sounds ok, it is not expected so should be dropped. Which is where Daniel Walsh's analysis comes in.. if you want it, then write a custom selinux policy. If you don't then file a bug against brasero as it should not be walking around looking for devices it could access.. it should have a subset of ones it knows it can and not walk around.
texted extensively outside of the current scenario, but I do believe if the user is unconfined the burn process works as expected. There is a very old Fedora bug suggesting similar, but not identical behavior: https://bugzilla.redhat.com/show_bug.cgi?id=479014
--Sean _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos