What makes contexts different for audit.log and ls -Z?

[Göran Uddeborg]

What could cause the context shown with "ls" and the context reported
for an denied AVC check to differ?

After a recent upgrade, Samba stopped working for us.  Trying
smbclient user adb is not allowed to access it's home directory.  From
an strace of smbd I see that a stat() call fails:

    8307  stat64("/home/adb", 0xbff08334)   = -1 EACCES (Permission denied)

I believe I found the reason in audit.log:

    type=AVC msg=audit(1139403413.095:1782): avc:  denied  { search } for  pid=8647
comm="smbd" name="home" dev=hda2 ino=966657
scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir
    type=SYSCALL msg=audit(1139403413.095:1782): arch=40000003 syscall=195 success=no
exit=-13 a0=90f7110 a1=bff08334 a2=5baff4 a3=bff08334 items=1 pid=8647 auid=504 uid=734
gid=0 euid=734 suid=0 fsuid=734 egid=734 sgid=734 fsgid=734 comm="smbd"
exe="/usr/sbin/smbd"
    type=CWD msg=audit(1139403413.095:1782):  cwd="/"
    type=PATH msg=audit(1139403413.095:1782): item=0 name="/home/adb" flags=1 
inode=966657 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00

"home_root_t" for /home/adb seems incorrect to me.  But when I do ls
-ldZ on /home/adb, it has a different context:

    server2# ls -lZd /home/adb
    drwx------  adb      adb      user_u:object_r:user_home_dir_t  /home/adb

"user_home_dir_t" makes a lot more sense.

The context of the smbd daemon looks right with ps.

    server2$ ps -ZC smbd
    LABEL                             PID TTY          TIME CMD
    root:system_r:smbd_t             7737 ?        00:00:00 smbd
    root:system_r:smbd_t             7735 ?        00:00:00 smbd

Somewhat blindly, I have done a "fixfiles -F relabel", and I've done
an extra "load_policy policy.19", and neither makes any difference.

[Todd Merritt]

You need to be able to search / to find /home.

Göran Uddeborg wrote:
>  What could cause the context shown with "ls" and the
> context reported
>  for an denied AVC check to differ?
>
>  After a recent upgrade, Samba stopped working for us.  Trying
>  smbclient user adb is not allowed to access it's home directory.  From
>  an strace of smbd I see that a stat() call fails:
>
>      8307  stat64("/home/adb", 0xbff08334)   = -1 EACCES (Permission denied)
>
>  I believe I found the reason in audit.log:
>
>      type=AVC msg=audit(1139403413.095:1782): avc:  denied  { search } for  pid=8647
> comm="smbd" name="home" dev=hda2 ino=966657
> scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir
>      type=SYSCALL msg=audit(1139403413.095:1782): arch=40000003 syscall=195 success=no
> exit=-13 a0=90f7110 a1=bff08334 a2=5baff4 a3=bff08334 items=1 pid=8647 auid=504 uid=734
> gid=0 euid=734 suid=0 fsuid=734 egid=734 sgid=734 fsgid=734 comm="smbd"
> exe="/usr/sbin/smbd"
>      type=CWD msg=audit(1139403413.095:1782):  cwd="/"
>      type=PATH msg=audit(1139403413.095:1782): item=0 name="/home/adb" flags=1 
> inode=966657 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00
>
>  "home_root_t" for /home/adb seems incorrect to me.  But when I do ls
>  -ldZ on /home/adb, it has a different context:
>
>      server2# ls -lZd /home/adb
>      drwx------  adb      adb      user_u:object_r:user_home_dir_t  /home/adb
>
>  "user_home_dir_t" makes a lot more sense.
>
>  The context of the smbd daemon looks right with ps.
>
>      server2$ ps -ZC smbd
>      LABEL                             PID TTY          TIME CMD
>      root:system_r:smbd_t             7737 ?        00:00:00 smbd
>      root:system_r:smbd_t             7735 ?        00:00:00 smbd
>
>  Somewhat blindly, I have done a "fixfiles -F relabel", and I've done
>  an extra "load_policy policy.19", and neither makes any difference.
>
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>

[Stephen Smalley]

On Wed, 2006-02-08 at 14:32 +0100, Göran Uddeborg wrote:
>  What could cause the context shown with "ls" and the
> context reported
>  for an denied AVC check to differ?
>  
>  After a recent upgrade, Samba stopped working for us.  Trying
>  smbclient user adb is not allowed to access it's home directory.  From
>  an strace of smbd I see that a stat() call fails:
>  
>      8307  stat64("/home/adb", 0xbff08334)   = -1 EACCES (Permission denied)
>  
>  I believe I found the reason in audit.log:
>  
>      type=AVC msg=audit(1139403413.095:1782): avc:  denied  { search } for  pid=8647
> comm="smbd" name="home" dev=hda2 ino=966657
> scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir
>      type=SYSCALL msg=audit(1139403413.095:1782): arch=40000003 syscall=195 success=no
> exit=-13 a0=90f7110 a1=bff08334 a2=5baff4 a3=bff08334 items=1 pid=8647 auid=504 uid=734
> gid=0 euid=734 suid=0 fsuid=734 egid=734 sgid=734 fsgid=734 comm="smbd"
> exe="/usr/sbin/smbd"
>      type=CWD msg=audit(1139403413.095:1782):  cwd="/"
>      type=PATH msg=audit(1139403413.095:1782): item=0 name="/home/adb" flags=1 
> inode=966657 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00 
If you look closely at the AVC audit message (which admittedly is
inscrutable ;), you'll see that the component on which search failed was
for "home", not "/home/adb".  You have to be able to search /home to
reach /home/adb.  Try 'man samba_selinux' and following the instructions
there for modifying the relevant boolean.

-- 
Stephen Smalley
National Security Agency

[Göran Uddeborg]

Stephen Smalley writes:
>  If you look closely at the AVC audit message (which admittedly is
>  inscrutable ;), you'll see that the component on which search failed was
>  for "home", not "/home/adb". 
Aha, the PATH audit entry doesn't mean what I thought it meant.  Guess
I should have checked the inode too.

Thanks for the pointer, it works now! :-)