[CentOS] Brasero/cdrecord/growisofs with selinux users confined to staff_u

Wed May 1 16:13:18 UTC 2019

On Wed, 1 May 2019 at 12:01, Sean <smalder73 at 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 at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

-- 
Stephen J Smoogen.