Bug 1887739
| Summary: | Any "boot.log" file created on the system gets label plymouthd_var_log_t | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> | |
| Component: | selinux-policy | Assignee: | Patrik Koncity <pkoncity> | |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 8.2 | CC: | bwelterl, lvrabec, mmalik, pierre-yves.goubet, pkoncity, plautrba, ssekidde, yferszt, zpytela | |
| Target Milestone: | rc | Keywords: | Reopened, Triaged | |
| Target Release: | 8.5 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-3.14.3-77.el8 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
A rule in selinux-policy exists to assigns the ldconfig_cache_t type for the /var/lib/debug directory, but SELinux is unable to discern paths.
Consequence:
Any directory with the name "debug" created in the /var/lib tree is assigned the ldconfig_cache_t type.
Fix:
The rule in question was removed from selinux-policy.
Result:
Directory with the name "debug" created in the /var/lib tree inherits its SELinux type from its parent directory.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1990813 (view as bug list) | Environment: | ||
| Last Closed: | 2021-11-09 19:42:29 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: | 1990813 | |||
Hi, It appears that the issue is wider: IMHO there is a design issue here. A customer noticed a similar problem with creating a directory "/var/lib/foo/debug", which ends up get a non-sense ldconfig_cache_t context on that directory. Reproducer: ~~~ # mkdir -p /var/lib/foo/debug # ls -Zd /var/lib/foo/debug unconfined_u:object_r:ldconfig_cache_t:s0 /var/lib/foo/debug ~~~ Reason: this happens because of the following transition rule: ~~~ # sesearch -T -s unconfined_t -t var_lib_t | grep debug type_transition unconfined_t var_lib_t:dir ldconfig_cache_t debug; ~~~ The above rule states that: if the processed in unconfined_t (e.g. bash for unconfined users) AND the process creates a directory named debug for which parent directory is labeled with var_lib_t THEN it gets the context ldconfig_cache_t This is pure non-sense. First, with current fcontext database, there is nothing that expects "debug" directories to be labeled with ldconfig_cache_t: ~~~ # semanage fcontext -l | grep ldconfig_cache_t /var/cache/ldconfig(/.*)? all files system_u:object_r:ldconfig_cache_t:s0 ~~~ Then, even if we fix this particular example, I would prefer a **real** solution be proposed. To solve this kind of oddity, we need an additional property in the transition rule that would let us specify the parent directory name the rule should apply on. Once this is implemented, it would then be possible to generate transition rules for files based on the content of the fcontext database, which would then guarantee everything remains in sync. Renaud. Hi Renaud, boot.log is labeled as plymouthd_var_log_t, because we have file transition for specific rule in policy. This file transition is here because otherwise the file created in /var/log would get into conflict due that this file is create by unconfined_t domain. So we need to specify object to get him proper label. As you can see bellow, here is a lot of named filetrans from unconfined_t domain. sesearch -T -s unconfined_t -t var_log_t type_transition unconfined_t var_log_t:dir snapperd_data_t .snapshots; type_transition unconfined_t var_log_t:dir sssd_var_log_t sssd; type_transition unconfined_t var_log_t:dir var_log_t anaconda; type_transition unconfined_t var_log_t:dir var_log_t remote; type_transition unconfined_t var_log_t:file NetworkManager_var_lib_t wpa_supplicant.log; type_transition unconfined_t var_log_t:file devicekit_var_log_t pm-powersave.log; type_transition unconfined_t var_log_t:file devicekit_var_log_t pm-suspend.log; type_transition unconfined_t var_log_t:file faillog_t btmp; type_transition unconfined_t var_log_t:file faillog_t faillog; type_transition unconfined_t var_log_t:file faillog_t tallylog; type_transition unconfined_t var_log_t:file lastlog_t lastlog; type_transition unconfined_t var_log_t:file plymouthd_var_log_t boot.log; type_transition unconfined_t var_log_t:file rpm_log_t hawkey.log; type_transition unconfined_t var_log_t:file rpm_log_t up2date; type_transition unconfined_t var_log_t:file rpm_log_t yum.log; type_transition unconfined_t var_log_t:file wtmp_t wtmp; Second reason is, that /var/log isn't only one place where can be placed boot.log file, also in /var/spool/plymouth can be placed, so wee need filetrans which specify object. It's unfortunate that a generic name like boot.log or debug is used by other services, but that's how the developers of those services came up with it. The solution would be for the developers to name these files with a less generic name. Regards, Patrik Hi Patrik, I disagree with this, the label for boot.log should only be applied for process "plymouthd" (running as "plymouthd_t"), not the other processes, it's not reasonable. For example "semanage", running as "semanage_t", will also have an hypothetical "boot.log" file labeled with "plymouthd_var_log_t", that's total non-sense. The same for "debug" directory that gets the label "ldconfig_cache_t", it's non-sense. Since for the latter ldconfig can run in any domain, then "ldconfig" should **rename** it's directory as something specific, such as "ldconfig_debug", **or** have a subdirectory created such as "ldconfig", which would be labeled differently (e.g. "var_ldconfig_t") and creating a "debug" directory inside the latter would transition to "ldconfig_cache_t", but only i n this case. Please reconsider. Renaud. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4420 |
Description of problem: Transitions rules are implemented in the policy to automatically label any "boot.log" file hosted on a "var_log_t" directory with "plymouthd_var_log_t". -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # sesearch -T -t var_log_t | grep -c boot.log 90 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- The rules include "unconfined_t" as source domain, which causes labeling improperly any "boot.log" file on the system, even if it's not "/var/log/boot.log". Since deleting rules is not possible, this creates issues for custom applications wanting to create their own "boot.log" file, as shown in the example below with "/myapp/log/boot.log" file: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # semanage fcontext -a "/myapp(/.*)?" -t usr_t # semanage fcontext -a "/myapp/log(/.*)?" -t var_log_t # mkdir /myapp # mkdir /myapp/log # restorecon -Rv /myapp # touch /myapp/log/{a,b,c,boot}.log # ls -Zl /myapp/log/ total 0 -rw-------. 1 unconfined_u:object_r:var_log_t:s0 root root 0 Oct 6 14:58 a.log -rw-------. 1 unconfined_u:object_r:var_log_t:s0 root root 0 Oct 6 14:58 b.log -rw-------. 1 unconfined_u:object_r:plymouthd_var_log_t:s0 root root 0 Oct 6 14:58 boot.log -rw-------. 1 unconfined_u:object_r:var_log_t:s0 root root 0 Oct 6 14:58 c.log -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- The root cause for all this is having this policy rule: policy/modules/kernel/domain.te: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- plymouthd_filetrans_named_content(named_filetrans_domain) -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Why is this implemented? Shouldn't there be a rule for "plymouthd_t" only and not "named_filetrans_domain" attribute ??? Version-Release number of selected component (if applicable): selinux-policy (RHEL7 + RHEL8) How reproducible: Always, see above "myapp" example.