Bug 430463 - AVC denial -- ntpd writing to /var/log/pm-suspend.log
Summary: AVC denial -- ntpd writing to /var/log/pm-suspend.log
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 8
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-28 09:08 UTC by Marketa Ceplova
Modified: 2018-04-11 09:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-26 22:44:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Marketa Ceplova 2008-01-28 09:08:17 UTC
Description of problem:

Summary:

SELinux is preventing ntpd(/usr/sbin/ntpd) (ntpd_t) "write" to
/var/log/pm-suspend.log (var_log_t).

Detailed Description:

SELinux is preventing ntpd(/usr/sbin/ntpd) (ntpd_t) "write" to
/var/log/pm-suspend.log (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
(/var/log/pm-suspend.log) 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 /var/log/pm-suspend.log. 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
/var/log/pm-suspend.log

The following command will allow this access:

restorecon /var/log/pm-suspend.log

Additional Information:

Source Context                system_u:system_r:ntpd_t
Target Context                system_u:object_r:var_log_t
Target Objects                /var/log/pm-suspend.log [ file ]
Source                        ntpd(/usr/sbin/ntpd)
Port                          <Unknown>
Host                          narcis
Source RPM Packages           
Target RPM Packages           pm-utils-0.99.4-6.fc8
Policy RPM                    selinux-policy-3.0.8-76.fc8
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   mislabeled_file
Host Name                     narcis
Platform                      Linux narcis 2.6.23.14-115.fc8 #1 SMP Mon Jan 21
                              14:20:50 EST 2008 i686 i686
Alert Count                   6
First Seen                    Fri 18 Jan 2008 08:36:52 AM CET
Last Seen                     Sun 27 Jan 2008 11:21:18 PM CET
Local ID                      ace2dc22-9a8c-4d38-94d2-9ac5e1d2fcc4
Line Numbers                  

Raw Audit Messages            

host=narcis type=AVC msg=audit(1201472478.275:254): avc:  denied  { write } for
 pid=8183 comm="ntpd" path="/var/log/pm-suspend.log" dev=dm-2 ino=819254
scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file

host=narcis type=AVC msg=audit(1201472478.275:254): avc:  denied  { write } for
 pid=8183 comm="ntpd" path="/var/log/pm-suspend.log" dev=dm-2 ino=819254
scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file

host=narcis type=SYSCALL msg=audit(1201472478.275:254): arch=40000003 syscall=11
success=yes exit=0 a0=97df948 a1=97def60 a2=97dfe80 a3=0 items=0 ppid=8182
pid=8183 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="ntpd" exe="/usr/sbin/ntpd" subj=system_u:system_r:ntpd_t:s0
key=(null)

Version-Release number of selected component (if applicable):
ntp-4.2.4p2-6.fc8
pm-utils-0.99.4-6.fc8
selinux-policy-targeted-3.0.8-81.fc8


How reproducible:
100%

Steps to Reproduce:
1.suspend to disk
2.
3.
  
Actual results:
setroubleshoot complains

Expected results:
everything goes smoothly

Additional info:
audit2allow generated me this local policy:


module crazyNTPWriteToSuspendLog 1.0;

require {
        type var_log_t;
        type ntpd_t;
        class file write;
}

#============= ntpd_t ==============
allow ntpd_t var_log_t:file write;
crazyNTPWriteToSuspendLog.te (END) 

However, I am almost 100% persuaded that creating such policy is wrong. When
looking into /var/log/pm-suspend.log it is obvious what is the problem -- the
log messages "Starting/Stopping ntpd: [OK]" are written to the log, which seems
to me wrong. However, I don't know exactly how to persuade /etc/init.d/ntp
script to be totally quiet, so filing this bug without any real resolution.

Comment 1 Till Maas 2008-01-28 09:39:24 UTC
Let's see what the selinux masters think about this.

Comment 2 Matěj Cepl 2008-01-28 14:06:00 UTC
I don't think this is Dan's problem -- I really think that printout is useless
and shouldn't be there in the first place.

Comment 3 Daniel Walsh 2008-01-28 16:14:42 UTC
restorecon -R -v /var/log

Whatever/Whoever create /var/log/pm-suspend.log created it with the wrong
context.  Allowing apps to write to var_log_t, would allow a compromised
applications to zero out /var/log/messages.

Comment 4 Matěj Cepl 2008-01-28 21:33:52 UTC
(In reply to comment #3)
> restorecon -R -v /var/log
> 
> Whatever/Whoever create /var/log/pm-suspend.log created it with the wrong
> context.  Allowing apps to write to var_log_t, would allow a compromised
> applications to zero out /var/log/messages.

Well,

[root@narcis ~]# restorecon -v -R /var/log/
[root@narcis ~]# ls -lZ /var/log/pm-suspend.log 
-rw-rw-r--  root root system_u:object_r:hald_log_t     /var/log/pm-suspend.log
[root@narcis ~]# 

if there is something which needs to be fixed by restorecon, it didn't happen
apparently.

Comment 5 Till Maas 2008-01-28 21:45:44 UTC
(In reply to comment #4)

> [root@narcis ~]# restorecon -v -R /var/log/
> [root@narcis ~]# ls -lZ /var/log/pm-suspend.log 
> -rw-rw-r--  root root system_u:object_r:hald_log_t     /var/log/pm-suspend.log
> [root@narcis ~]# 
> 
> if there is something which needs to be fixed by restorecon, it didn't happen
> apparently.

What do you mean? In the initial report /var/log/pm-suspend.log had type
var_log_t, at after restorecon it is hald_log_t. Do you experience problems now
after restorecon? 

Comment 6 Matěj Cepl 2008-01-28 22:44:20 UTC
Oh, I see -- I was confused by the silence of restorecon. OK, I will put myself
in NEEDINFO and will let you know if something bad happens.

Comment 7 Daniel Walsh 2008-01-29 13:53:35 UTC
This probably means that the file had already had it's file context corrected. 
pm-utils I believe runs restorecon when it recreates the file.


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