Sean
2019-May-01 16:00 UTC
[CentOS] Brasero/cdrecord/growisofs with selinux users confined to staff_u
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
Stephen John Smoogen
2019-May-01 16:13 UTC
[CentOS] Brasero/cdrecord/growisofs with selinux users confined to staff_u
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.