F41 Change Proposal: Reduce the amount of "dontaudit" rules pertaining to unlabeled_t (self-contained)

Reduce the amount of “dontaudit” rules pertaining to unlabeled_t

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki

:link: Summary

Reduce the amount of rules that prevent reporting of SELinux denials pertaining to unlabeled_t. This could influence the amount of SELinux-related logs on some systems, but will not cause any new permission denials.

:link: Owner

:link: Current status

:link: Detailed Description

The SELinux security policy primarily comprises allow rules, which permit specific operations on a confined system. However, there are also SELinux rules featuring the “dontaudit” keyword. In general, these rules signify that the described operation is not allowed and will not be logged as a permission denial in audit logs. The primary purpose of these rules is to hide certain false positives or code defects, such as leaked descriptors. The drawback is that, in certain instances, these rules might obscure hints that could expedite debugging and issue resolution. It is possible to disable all dontaudit rules using “semodule -DB”, but this usually leads to large amounts of benign denials being logged and hence is not practical for long term use.

The goal of this change is to significantly reduce the amount of dontaudit rules suppressing “unlabeled_t” denials, which are often caused by miss-labeled filesystems and can usually be easily fixed when noticed by the system administrator. The rules will not be completely removed from the policy, only disabled by default, so that the change can be reverted by the admin if needed (# setsebool -P dontaudit_unlabeled_files 1). The change could influence the amount of SELinux-related logs on some systems, but will not cause any new permission denials.

:link: Feedback

:link: Benefit to Fedora

Access denials caused by labeling issues will more likely be reported by SELinux.

:link: Scope

  • Proposal owners: Determine which dontaudit rules are safe to disable by default and wrap them in conditional statements in the policy sources – changes will be limited to SElinux policy (and possibly setroubleshoot) packages

  • Other developers: Report any unlabeled_t AVCs triggered by their software

  • Release engineering: N/A (not needed for this Change)

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy: The change aligns with the “accessibility” goal as it simplifies debugging of some labeling issues

:link: Upgrade/compatibility impact

No functionality impact, no configuration or data migration. The change could influence the amount of SELinux-related logs on some systems.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? - No

:link: How To Test

Run your testsuite with SELinux enabled (Enforcing or Permissive mode) and record any AVCs containing unlabeld_t keyword.

# ausearch -m AVC,USER_AVC | grep unlabeled_t

:link: User Experience

The change could increase the amount of SELinux-related logs on some systems.

:link: Dependencies

Changes will be limited to SElinux policy (and possibly setroubleshoot) packages.

:link: Contingency Plan

  • Contingency mechanism: Do not ship the updated SELinux-policy package
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No

:link: Documentation

Dontaudit rules can be added selectively using audit2allow:

# ausearch -m AVC | grep unlabeled_t | audit2allow -D -M dontaudit_unlabeled

# semodule -i dontaudit_unlabeled.pp

All the disabled rules can be re-enabled by switching the “dontaudit_unlabeled_files” boolean (will be added as part of the change).

# setsebool -P dontaudit_unlabeled_files 1

:link: Release Notes

Last edited by @amoloney 2024-07-01T20:46:45Z

1 Like

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

1 Like

This change proposal has now been submitted to FESCo with ticket #3245 for voting.

To find out more, please visit our Changes Policy documentation.