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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
