Re: [CentOS] Brasero/cdrecord/growisofs with selinux users confined to staff_u
On Wed, 1 May 2019 at 12:01, Sean 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
>
--
Stephen J Smoogen.
[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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS-announce] IRC Meeting Changes
For the past few years the CentOS Project has been holding IRC meetings for our various Special Interest Groups (SIGs) and other projects in the #centos-devel channel on the freenode IRC network. This has, for the most part, worked out fairly well. However, as this is a shared channel, at times things can become a bit hectic and confusing as people occasionally interrupt a meeting in progress. Not only does this break the flow of the meeting but it also injects noise into the logs that the project maintains for historical reference. This policy was also different from most other projects which have a dedicated "meetings" channel to be used for these purposes. In order to address the issue the project has made the decision to transition meetings to the #centos-meeting channel. This is a dedicated channel to be used solely for meetings. We feel this will help alleviate any potential issues with interruptions and other distractions. This channel is managed by the same group of people, our IRC Ops Team, as is #centos-devel and our channel bots are present to help as necessary. An additional bonus of this transition will be that the meeting bot (centbot) responsible for meeting oversight and logging will now be able to set the channel topic to reflect meeting status. This was not previously possible due to policy as we did not want to have the bot op'd unless absolutely necessary in a shared channel. We are planning this transition for June 1st in order to give the stakeholders involved ample time to alert their communities of the change and to ensure we have made the necessary changes on our end to ensure a smooth transition for people who access the logs via the https://www.centos.org/minutes/ interface. Any questions regarding this transition should be addressed either via the centos-devel mailing list or on the #centos-devel IRC channel on freenode. Additionally people can reach out to me personally on IRC (Bahhumbug on freenode) or via email if they have questions or concerns regarding this or other CentOS IRC matters. Thanks and see you in #centos-meeting :) -- The good-enough father is not simply a knight in shining armor galloping to the occasional rescue; he is there through good times and bad, insisting on and delighting in his paternity every pleasurable and painful step of the way. -- Victoria Secunda, American psychologist and author, Women and Their Fathers, ch. 4 (1992) pgplvuqmQG98u.pgp Description: PGP signature ___ CentOS-announce mailing list CentOS-announce@centos.org https://lists.centos.org/mailman/listinfo/centos-announce
[CentOS] CentOS-announce Digest, Vol 171, Issue 1
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CESA-2019:0818 Important CentOS 7 kernel Security Update
(Johnny Hughes)
2. CEBA-2019:0811 CentOS 7 selinux-policy BugFix Update
(Johnny Hughes)
3. CESA-2019:0809 Important CentOS 7 ovmf Security Update
(Johnny Hughes)
4. CEBA-2019:0820 CentOS 7 systemd BugFix Update (Johnny Hughes)
5. CEBA-2019:0817 CentOS 7 mutter BugFix Update (Johnny Hughes)
6. CEBA-2019:0816 CentOS 7 sssd BugFix Update (Johnny Hughes)
7. CEEA-2019:0045 CentOS 7 rsync Enhancement Update (Johnny Hughes)
8. CEBA-2019:0815 CentOS 7 pango BugFix Update (Johnny Hughes)
9. CEBA-2019:0807 CentOS 7 gcc BugFix Update (Johnny Hughes)
10. CEBA-2019:0824 CentOS 7 gdm BugFix Update (Johnny Hughes)
11. CEBA-2019:0808 CentOS 7 iproute BugFix Update (Johnny Hughes)
12. CEBA-2019:0825 CentOS 7 gnome-shell-extensionsBugFix Update
(Johnny Hughes)
13. CEBA-2019:0810 CentOS 7 kexec-tools BugFix Update (Johnny Hughes)
14. CEBA-2019:0826 CentOS 7 scap-security-guide BugFix Update
(Johnny Hughes)
15. CEBA-2019:0819 CentOS 7 sos BugFix Update (Johnny Hughes)
16. CEBA-2019:0821 CentOS 7 libvirt BugFix Update (Johnny Hughes)
17. CEBA-2019:0814 CentOS 7 lvm2 BugFix Update (Johnny Hughes)
18. CESA-2019:0638 Important CentOS 7 openwsman Security Update
(Johnny Hughes)
19. CEBA-2019:0812 CentOS 7 httpd BugFix Update (Johnny Hughes)
20. CEBA-2019:0813 CentOS 7 nss-pam-ldapd BugFix Update
(Johnny Hughes)
--
Message: 1
Date: Tue, 30 Apr 2019 12:00:45 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2019:0818 Important CentOS 7 kernel
SecurityUpdate
Message-ID: <20190430120045.ga21...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2019:0818 Important
Upstream details at : https://access.redhat.com/errata/RHSA-2019:0818
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
22232a43a89006952c1ef37039017e82c39117f805eeedd345f7edacac65abc0
bpftool-3.10.0-957.12.1.el7.x86_64.rpm
99dab9875a92cf1a556d664dfaa5a69143d9f96f2c3c6fe7a10fc35964cee088
kernel-3.10.0-957.12.1.el7.x86_64.rpm
528f3c2583c838e348cfaa028989d9d9aa048b50af722849d5845fa4076b0f02
kernel-abi-whitelists-3.10.0-957.12.1.el7.noarch.rpm
b7c9c340201085a7a301aef37305e4deea85e4eb60dbd2586af6e78547a84b4a
kernel-debug-3.10.0-957.12.1.el7.x86_64.rpm
a164fbf1e13f4e4c8378d72a575b1ee2617d1c78e1a37f464ff5f1871552d302
kernel-debug-devel-3.10.0-957.12.1.el7.x86_64.rpm
da14623036ae7069d8d8df04f2832d2bb8b2da291d13b4cccd4f3b31276f6782
kernel-devel-3.10.0-957.12.1.el7.x86_64.rpm
d7d549ce61627264b2263eb9975f4a933c20340d96eba917e45f55bf6e1ec752
kernel-doc-3.10.0-957.12.1.el7.noarch.rpm
1eecf424270d55de5de3c417b540f992f3be5489bb0f029aae65137565d0a838
kernel-headers-3.10.0-957.12.1.el7.x86_64.rpm
5d2020bd11dfb87283b2b1a56bc65012a4ed653f4dda4730511f5e4f9d57fbbc
kernel-tools-3.10.0-957.12.1.el7.x86_64.rpm
793ae8c03006f2ff49d159e6a6f28b2a144a61a98e581c0623962a398450
kernel-tools-libs-3.10.0-957.12.1.el7.x86_64.rpm
36fa2420a7a5875022c88e7f768780c5faf7ac8e69d6b1959f7a491e249a701e
kernel-tools-libs-devel-3.10.0-957.12.1.el7.x86_64.rpm
8e43ff52c9e1d6b472a0fa768505540d9668bf73b1ba5bf7605f65391669b619
perf-3.10.0-957.12.1.el7.x86_64.rpm
5dea4497afdba7fde6444966b30efb998ec55cdb3b16e0f8e894e7ac065d2e77
python-perf-3.10.0-957.12.1.el7.x86_64.rpm
Source:
79f62ec35df6222e9e7be4f9d002ac8822b43cacefa6e4fed96747183961fb1d
kernel-3.10.0-957.12.1.el7.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
--
Message: 2
Date: Tue, 30 Apr 2019 12:01:13 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2019:0811 CentOS 7 selinux-policy
BugFix Update
Message-ID: <20190430120113.ga21...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2019:0811
Upstream details at : https://access.redhat.com/errata/RHBA-2019:0811
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
4fc115f34bb5961dc2ff905dfde26ed42f60e9817f6624a80b9630afb1b7ce78
