Bug 427150

Summary: SELinux is preventing sshd (sshd_t) "append" to (var_log_t).
Product: [Fedora] Fedora Reporter: astozzia <acmaeey>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: david
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-03 15:19:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description astozzia 2008-01-01 14:14:46 UTC 
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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
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
Comment 1 David Cornette 2008-01-01 15:49:33 UTC 
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 
system_u:object_r:var_log_t:s0->system_u:object_r:faillog_t:s0
restorecon reset /var/log/rpmpkgs context 
system_u:object_r:var_log_t:s0->system_u:object_r:rpm_log_t:s0
restorecon reset /var/log/yum.log context 
system_u:object_r:var_log_t:s0->system_u:object_r:rpm_log_t:s0

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.
Comment 2 Paul Howarth 2008-01-03 00:40:18 UTC 
Looks like a logrotate problem to me (Bug #427274)
Comment 3 Daniel Walsh 2008-01-03 15:19:45 UTC 
Yes nice catch.  Thanks Paul.



*** This bug has been marked as a duplicate of 427274 ***