Re: unidentified audit msg
On Wed, 2006-06-21 at 08:42 -0400, David-Alexandre Davidson wrote:
Hi, I recently observed a strange behavior of selinux while serving
web content over a smb share. The result was some images not showing
with httpd returning a forbidden status. After verifying all other
possible issue. I found this strange entry in my audit.log file :
type=AVC msg=audit(1150863068.013:12309): avc: denied { 0x100000 }
for pid=14365 comm="httpd" name="stock" dev=cifs ino=361051
scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:cifs_t:s0
tclass=file
type=SYSCALL msg=audit(1150863068.013:12309): arch=40000003
syscall=196 success=no exit=-13 a0=9a76740 a1=bfece07c a2=2c8ff4
a3=2008171 items=1 pid=14365 auid=0 uid=48 gid=48 euid=48 suid=48
fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd"
type=CWD msg=audit(1150863068.013:12309): cwd="/"
type=PATH msg=audit(1150863068.013:12309): item=0
name="/home/testeur/var/www/manage/public_domains_icons/CrystalClear-GNOME-1.0.0/22x22/stock/stock-help.png"
flags=0
Is there someone who knows what this 0x100000 permission is? I tried
to compile a loadable module with the corresponding allow statement
(I'm on core 5) but the 0x100000 does not appear to be a valid element
and it fails to compile. I observed this behavior on different
files(for example in this msg the denial occur on the "stock" folder
of the path, but I've seen it on the 22x22 folder as well). Restarting
the system results in some file that were forbidden to show up without
reason and some that were ok to just stop being served by httpd
(always giving the 0x100000 dennial)
At first I suspected a problem with the smb (cifs) mount but
everything work perfectly if I try to access the mount directly. Then
I suspected apache but the forbidden status code seems directly
related to the audit msg.
Anyone is welcome to help, I'm quite lost on that matter.
Per your description, "stock" is a directory, but SELinux has
mis-classified it as a regular file (tclass=file), and thus can't
interpret the 0x100000 permission (which would be a search permission
check on a tclass=dir aka directory). SELinux sets the class from the
inode mode, so this means that the inode mode wasn't set correctly at
the point that SELinux set it up (upon d_instantiate). This is a kernel
bug, whether on the part of cifs (e.g. failure to set inode mode prior
to d_instantiate) or on the part of SELinux, so you should file a
bugzilla against the kernel, with details on your specific kernel.
--
Stephen Smalley
National Security Agency