Bad file access on the rise

[Steve Grubb]

Hello,

Every now and then I look at the distribution to see that from an auditing 
perspective the OS is nicely behaving in the absence of intrusion. Meaning we 
are not getting audit events unnecessarily. One of the typical rules required 
by the DISA STIG is to watch for file access being denied due to permissions. 
This could be indicative of someone trying to access something they shouldn't. 
The rule is:

-a always,exit -F arch=b64 -S creat -S open -S openat -S truncate -S ftruncate 
-F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access

Lately F18 has been showing lots of audit events where access is being denied 
opening a file:

# aureport --start today --key --summary

Key Summary Report
===========================
total  key
===========================
537  access
25  module-load
6  container-config
6  system-locale
6  bypass

This is after using the system for 2 hours. Let's see what files were trying to 
be accessed:

]# ausearch --start today -k access --raw | aureport --file --summary | head

File Summary Report
===========================
total  file
===========================
88  /dev/shm/pulse-shm-838240362
88  /dev/shm/pulse-shm-191856280
88  /dev/shm/pulse-shm-3756395503
7  /dev/shm/pulse-shm-1545675388
6  /usr/share/icons/hicolor/48x48/apps/firefox.png


Let's look at one of these pule-shm events:
# ausearch --start today -k access -f pulse-shm -i --just-one
----
type=PATH msg=audit(06/07/2013 07:13:46.377:215) : item=0 name=/dev/shm/pulse-
shm-3756395503 inode=25089 dev=00:10 mode=file,400 ouid=gdm ogid=gdm rdev=00:00 
obj=system_u:object_r:user_tmpfs_t:s0 
type=CWD msg=audit(06/07/2013 07:13:46.377:215) :  cwd=/ 
type=SYSCALL msg=audit(06/07/2013 07:13:46.377:215) : arch=x86_64 syscall=open 
success=no exit=-13(Permission denied) a0=0x7fffbeda83c0 a1=O_RDONLY|
O_NOFOLLOW|O_CLOEXEC a2=0x0 a3=0x0 items=1 ppid=2369 pid=2370 auid=sgrubb 
uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb 
sgid=sgrubb fsgid=sgrubb ses=2 tty=(none) comm=pulseaudio 
exe=/usr/bin/pulseaudio subj=unconfined_u:system_r:unconfined_t:s0 key=access 

So, gdm is creating a file 400 and pulse-audio can't open it. Is it suppose to 
be like that?

What about the firefox one?

type=PATH msg=audit(06/07/2013 08:13:52.465:633) : item=0 
name=/usr/share/icons/hicolor/22x22/apps/firefox.png inode=16943495 dev=09:01 
mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:usr_t:s0 
type=CWD msg=audit(06/07/2013 08:13:52.465:633) :  cwd=/home/sgrubb 
type=SYSCALL msg=audit(06/07/2013 08:13:52.465:633) : arch=x86_64 syscall=open 
success=no exit=-1(Operation not permitted) a0=0x7fc3be80e880 a1=O_RDONLY|
O_NOATIME a2=0x0 a3=0x0 items=1 ppid=2395 pid=2670 auid=sgrubb uid=sgrubb 
gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb sgid=sgrubb 
fsgid=sgrubb ses=2 tty=(none) comm=firefox exe=/usr/lib64/firefox/firefox 
subj=unconfined_u:unconfined_r:unconfined_t:s0 key=access 

It is using the O_NOATIME flag. To use O_NOATIME requires CAP_FOWNER and firefox 
should no have capabilities. So, how bad is the NOATIME problem?

# ausearch --start today -k access -i | grep NOATIME | awk '{ print $30 }' | 
~sgrubb/working/BUILD/numeric-tools/summary
exe=/usr/bin/cinnamon                      193
exe=/usr/lib64/firefox/firefox             31
exe=/usr/bin/gnome-terminal                12
exe=/usr/bin/nautilus                      10
exe=/usr/bin/xchat                         4
exe=/usr/bin/nm-applet                     2
exe=/usr/bin/kontact                       2

This seems to account for a good number of the problematic accesses. Anything 
except backup programs using O_NOATIME is probably thinking they are making 
the program faster, but instead is failing to open files.

-Steve