Bug 2053815

Summary:	enabled by default: selinuxuser_execstack?
Product:	Red Hat Enterprise Linux 8	Reporter:	morgan read <mstuff>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	CLOSED WONTFIX	QA Contact:	Milos Malik <mmalik>
Severity:	high	Docs Contact:
Priority:	high
Version:	8.5	CC:	lvrabec, mmalik, ssekidde
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.6
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:
Clones:	2055822 (view as bug list)		Environment:
Last Closed:	2022-02-25 18:24:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2055822

Description morgan read 2022-02-12 11:49:21 UTC

Description of problem:

I discovered selinuxuser_execstack=1 (via system-config-selinux)

I also discovered the description of that setting:
'allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla'

So, thought that sounded nasty and I turned it off:
# getsebool selinuxuser_execstack
selinuxuser_execstack --> off

Now,
The Cockpit SELinux policy page reports under 'System modifications':
'Disallow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla'

So, that suggests that the default for the system is selinuxuser_execstack=1 and that seems wrong, given the warnings above...

But:
# semanage boolean -l | grep selinuxuser_execstack
selinuxuser_execstack (off , off) Allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla

So, I'm a bit confused - perhaps this is a bug in Cockpit's reporting?

Version-Release number of selected component (if applicable):
libselinux-2.9-5
selinux-policy.noarch-3.14.3-80
cockpit-251.3-1

How reproducible:
Apparently always

Steps to Reproduce:
1. Install selinux & cockpit
2. Check on selinuxuser_execstack
3.

Actual results:
Confusing

Expected results:
Not confusing

Additional info:

Comment 1 Milos Malik 2022-02-14 08:18:53 UTC

Default value of the selinuxuser_execmod boolean is also an issue.

Comment 2 Zdenek Pytela 2022-02-21 12:45:32 UTC

Thank you for reporting the issue. Unfortunately changing a boolean in the middle of development cycle is not allowed:

Stability of the SELinux Policy API 
https://access.redhat.com/articles/4854201

The SELinux team strives to ensure that policy-related changes strictly follow these guidelines, with the exception of a security problem. If you think this is the case, please let us know, otherwise I'll close this bz.

It has already been cloned to RHEL 9 to have selinuxuser_execmod and selinuxuser_execstack set off since GA.

Comment 3 morgan read 2022-02-21 14:37:51 UTC

Is Comment #2 directed at me or Milos?  Thx

Comment 4 Zdenek Pytela 2022-02-21 15:10:06 UTC

(In reply to morgan read from comment #3)
> Is Comment #2 directed at me or Milos?  Thx

You as the reporter, I should have raised the needinfo flag.

Comment 5 morgan read 2022-02-21 15:53:03 UTC

No problem - you'll appreciate I'm just someone that tries to report what comes to my attention in a pretty unsophisticated way and I don't have an email address ending @redhat.com.

That said, in a pretty unsophisticated way, I reckon that:
"This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack."
Sounds pretty serious and, if it's not a 'security problem' then, the problem is an overly alarmist and badly written explanation of a less serious problem...

It might also be worth noting that guidelines are just that, guidelines.  And, strictly following them off the edge of a cliff is not advisable.  To me, the above quote reads like driving off the edge of a cliff.

When I reported this I anticipated it would be some misconfiguration I had introduced to my system, not some misconfiguration of the default redhat security policy with all the wider implications that flow from that.  I was quite intrigued to see the bug disappear behind a closed door when I first reported it, but it's back now.  So, perhaps I was not the only person overly alarmed - or, perhaps I'm not overly alarmed.

Comment 6 Zdenek Pytela 2022-02-25 18:24:58 UTC

I am grateful for your report, apparently this setting changed 9 years ago without questioning by anybody. And while I also agree with you, after a small team discussion I decided not to change the booleans default value: the reason is not the document, but customers expectations about stability in the middle of RHEL 8 lifecycle. As with other booleans, administrators have the option to disable them to improve security footprint of their system. Having said that, I will now close this BZ as WONTFIX.

Direct outcome is now visible in RHEL 9/Centos stream 9 though: the two booleans value will be changed since the beginning. Feel free to look for other suspicious settings or rules and report them in bugzilla, thank you foro your cooperation.

Comment 7 morgan read 2022-02-25 22:56:14 UTC

That all sounds very reasonable. Thanks for the explanation.