Bug 589404 - SELinux is preventing sshd (sshd_t) "write" to lastlog (var_log_t).
Summary: SELinux is preventing sshd (sshd_t) "write" to lastlog (var_log_t).
Status: CLOSED DUPLICATE of bug 589402
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 13
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:a9b710eae87...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-06 05:03 UTC by Naoki
Modified: 2010-05-06 07:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-06 07:46:24 UTC
Type: ---

Attachments (Terms of Use)

Description Naoki 2010-05-06 05:03:12 UTC

SELinux is preventing sshd (sshd_t) "write" to lastlog (var_log_t).

Detailed Description:

[SELinux is in permissive mode. This access was not denied.]

SELinux is preventing sshd (sshd_t) "write" to lastlog (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 (lastlog) 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 'lastlog'. If the file
context does not change from var_log_t, then this is probably a bug in policy.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against the selinux-policy package. If it does change, you can try your
application again to see if it works. The file context could have been
mislabeled by editing the file or moving the file from a different directory, if
the file keeps getting mislabeled, check the init scripts to see if they are
doing something to mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v 'lastlog'

Fix Command:

restorecon 'lastlog'

Additional Information:

Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:var_log_t:s0
Target Objects                lastlog [ file ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           openssh-server-5.2p1-2.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.10-4.fc11
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Plugin Name                   mislabeled_file
Host Name                     (removed)
Platform                      Linux (removed) 2.6.29-16.fc11.i586 #1 SMP
                              Fri Mar 27 21:07:59 EDT 2009 i686 i686
Alert Count                   1
First Seen                    Tue 31 Mar 2009 07:50:05 PM JST
Last Seen                     Tue 31 Mar 2009 07:50:05 PM JST
Local ID                      26e45bfe-8689-4d6f-bb0a-66b7993d2389
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1238496605.840:122): avc:  denied  { write } for  pid=4138 comm="sshd" name="lastlog" dev=dm-0 ino=50889174 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1238496605.840:122): arch=40000003 syscall=5 success=yes exit=8 a0=bf84a01c a1=8042 a2=180 a3=bf84a01c items=0 ppid=2128 pid=4138 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=17 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Hash String generated from  mislabeled_file,sshd,sshd_t,var_log_t,file,write
audit2allow suggests:

#============= sshd_t ==============
allow sshd_t var_log_t:file write;

Comment 1 Miroslav Grepl 2010-05-06 07:46:24 UTC

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

Note You need to log in before you can comment on or make changes to this bug.