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
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
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@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
