Lukas Vrabec lvrabec@redhat.com wrote:
On 05/17/2018 09:12 PM, m.roth@5-cent.us wrote:
As systems are upgraded, we're getting a ton of complaints
(fortunately, we're in permissive mode) that would break everything. All of them involve rpc.gssd, and I see a number of bugs listed when I search.
Note that I first saw this on a RHEL system, but now I'm seeing it on
CentOS 7. I'm bringing it up here, because, given that there are multiple reported, that there's some bigger picture involving policy and rpc.gssd.
I'll note that some of the reported bugs were *closed last year, or
before, so it seems to me an old issue resurfaced.
Example. SELinux is preventing /usr/sbin/rpc.gssd from using the block_suspend capability.
While you won't send any logs, I'm not able to help you, but based on our example, it looks like kernel bug affecting SELinux. Solution is to dontaudit this SELinux denial.
Also, what version of Centos 7 are you using? Centos 7.5?
One system is LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: RedHatEnterpriseWorkstation Description: Red Hat Enterprise Linux Workstation release 7.5 (Maipo) Release: 7.5 Codename: Maipo
Another is LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.5.1804 (Core) Release: 7.5.1804 Codename: Core
What logs do you usually want, the results of running sealert? From that, I see, on the CentOS 7.5 system: excerpt: Raw Audit Messages type=AVC msg=audit(1526626994.989:9622): avc: denied { block_suspend } for pid=901 comm="rpc.gssd" capability=36 scontext=system_u:system_r:gssd_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=capability2
And on the RHEL system: Raw Audit Messages type=AVC msg=audit(1526626926.76:162255): avc: denied { block_suspend } for pid=1218 comm="rpc.gssd" capability=36 scontext=system_u:system_r:gssd_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=capability2
So, same policy, and same denials. Note that the RHEL system is set for enforcing, while the CentOS system is permissive.
mark
On 05/18/2018 04:37 PM, m.roth@5-cent.us wrote:
Lukas Vrabec lvrabec@redhat.com wrote:
On 05/17/2018 09:12 PM, m.roth@5-cent.us wrote:
As systems are upgraded, we're getting a ton of complaints
(fortunately, we're in permissive mode) that would break everything. All of them involve rpc.gssd, and I see a number of bugs listed when I search.
Note that I first saw this on a RHEL system, but now I'm seeing it on
CentOS 7. I'm bringing it up here, because, given that there are multiple reported, that there's some bigger picture involving policy and rpc.gssd.
I'll note that some of the reported bugs were *closed last year, or
before, so it seems to me an old issue resurfaced.
Example. SELinux is preventing /usr/sbin/rpc.gssd from using the block_suspend capability.
While you won't send any logs, I'm not able to help you, but based on our example, it looks like kernel bug affecting SELinux. Solution is to dontaudit this SELinux denial.
Also, what version of Centos 7 are you using? Centos 7.5?
One system is LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: RedHatEnterpriseWorkstation Description: Red Hat Enterprise Linux Workstation release 7.5 (Maipo) Release: 7.5 Codename: Maipo
Another is LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.5.1804 (Core) Release: 7.5.1804 Codename: Core
What logs do you usually want, the results of running sealert? From that, I see, on the CentOS 7.5 system: excerpt: Raw Audit Messages type=AVC msg=audit(1526626994.989:9622): avc: denied { block_suspend } for pid=901 comm="rpc.gssd" capability=36 scontext=system_u:system_r:gssd_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=capability2
And on the RHEL system: Raw Audit Messages type=AVC msg=audit(1526626926.76:162255): avc: denied { block_suspend } for pid=1218 comm="rpc.gssd" capability=36 scontext=system_u:system_r:gssd_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=capability2
So, same policy, and same denials. Note that the RHEL system is set for enforcing, while the CentOS system is permissive.
mark
Hi Mark,
Workaround from my previous mail should fix your issue.
Lukas.
selinux@lists.fedoraproject.org