unidentified audit msg

[Stephen Smalley]

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