Red Hat Bugzilla – Bug 427150
SELinux is preventing sshd (sshd_t) "append" to (var_log_t).
Last modified: 2008-01-03 10:19:45 EST
Description of problem:
SELinux is preventing sshd (sshd_t) "append" to (var_log_t)
The SELinux type var_log_t, is a generic type for all files in the directory and
very few processes (SELinux Domains) are allowed to write to this SELinux type.
This type of denial usual indicates a mislabeled file. By default a file created
in a directory has the gets the context of the parent directory, but SELinux
policy has rules about the creation of directories, that say if a process
running in one SELinux Domain (D1) creates a file in a directory with a
particular SELinux File Context (F1) the file gets a different File Context
(F2). The policy usually allows the SELinux Domain (D1) the ability to write,
unlink, and append on (F2). But if for some reason a file () was created with
the wrong context, this domain will be denied. The usual solution to this
problem is to reset the file context on the target file, restorecon -v . If the
file context does not change from var_log_t, then this is probably a bug in policy.
Version-Release number of selected component (if applicable):setroubleshoot 1.10.7
Steps to Reproduce:
Source Context: system_u:system_r:sshd_t:s0-s0:c0.c1023Target
Context: system_u:object_r:var_log_t:s0Target Objects: None [ file ]Affected
RPM Packages: Policy RPM: selinux-policy-3.0.8-72.fc8Selinux
Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing
Mode: EnforcingPlugin Name: plugins.mislabeled_file
I had the same problem on my newly installed Fedora 8 system. This is
actually a fairly big problem, because the every few seconds, it causes the
denial notification message to pop up with no obvious way to stop it apparent.
I got the messages to stop by doing "restorecon -v /var/log/*" as root. the
output was as follows:
restorecon reset /var/log/btmp context
restorecon reset /var/log/rpmpkgs context
restorecon reset /var/log/yum.log context
Since there are some yum and rpm related things there, it may be worth
mentioning that I had left yumex open overnight. As I said, this is a newly
installed, last night was the first time cron.monthly would have run.
Looks like a logrotate problem to me (Bug #427274)
Yes nice catch. Thanks Paul.
*** This bug has been marked as a duplicate of 427274 ***