RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2053815 - enabled by default: selinuxuser_execstack?
Summary: enabled by default: selinuxuser_execstack?
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.5
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 8.6
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 2055822
TreeView+ depends on / blocked
 
Reported: 2022-02-12 11:49 UTC by morgan read
Modified: 2022-02-25 22:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 2055822 (view as bug list)
Environment:
Last Closed: 2022-02-25 18:24:58 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-112081 0 None None None 2022-02-12 11:56:08 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.