Looking for directory paths...

[Arthur Dent]

Hello all,

When I get a SEL alert it refers only to to the actual directory and not
the full pathname. For example:

SELinux is preventing /usr/sbin/smbd from create access on the directory 05.

The advice for fixing this alert is probably useful but without knowing
the full path is actually completely useless:

If you want to allow smbd to have create access on the 05 directory
Then you need to change the label on '05'
Do
# semanage fcontext -a -t samba_share_t '05'
# restorecon  -v '05'

The problem is - I don't know where directory "05" is. It's probably
some temporary cache file or some such and trying to even find its
parent directory with a name like "05" makes using 'locate' or
'find'
really quite hard work.

In this case the alert(s) (there were several - each with a different
numerical directory name) were actually caused when I tried to sync my
iPhone using iTunes installed on a Windows XP virtual machine running
under VirtualBox on this Fedora 16 host, accessing the music library via
a Samba share on a separate partition on the Fedora 16 box.... Yeah... I
know....

But anyway - if I could find the full path of the directory in question
I *might* be able to take a closer look at where the problem lies...

Thanks in advance for any help or suggestions.

Mark

[Paul Howarth]

On 12/11/2011 01:49 PM, Arthur Dent wrote:
>  Hello all,
>
>  When I get a SEL alert it refers only to to the actual directory and not
>  the full pathname. For example:
>
>  SELinux is preventing /usr/sbin/smbd from create access on the directory 05.
>
>  The advice for fixing this alert is probably useful but without knowing
>  the full path is actually completely useless:
>
>  If you want to allow smbd to have create access on the 05 directory
>  Then you need to change the label on '05'
>  Do
>  # semanage fcontext -a -t samba_share_t '05'
>  # restorecon  -v '05'
>
>  The problem is - I don't know where directory "05" is. It's probably
>  some temporary cache file or some such and trying to even find its
>  parent directory with a name like "05" makes using 'locate' or
> 'find'
>  really quite hard work.
>
>  In this case the alert(s) (there were several - each with a different
>  numerical directory name) were actually caused when I tried to sync my
>  iPhone using iTunes installed on a Windows XP virtual machine running
>  under VirtualBox on this Fedora 16 host, accessing the music library via
>  a Samba share on a separate partition on the Fedora 16 box.... Yeah... I
>  know....
>
>  But anyway - if I could find the full path of the directory in question
>  I *might* be able to take a closer look at where the problem lies...
>
>  Thanks in advance for any help or suggestions. 
Standard advice here is to add an audit watch record for something that 
rarely happens, such as writing to /etc/shadow:

# auditctl -w /etc/shadow -p w

A happy side effect of this is that a PATH record is included in the 
audit log for subsequent AVCs, e.g.

type=AVC msg=audit(1316699607.377:150425): avc:  denied  { read } for 
pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876 
scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 
tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file

type=AVC msg=audit(1316699607.377:150425): avc:  denied  { open } for 
pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876 
scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 
tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file

type=SYSCALL msg=audit(1316699607.377:150425): arch=c000003e syscall=2 
success=yes exit=3 a0=14c60a0 a1=80900 a2=fffffffffffffed0 
a3=7ffffdee5c80 items=1 ppid=4150 pid=4151 auid=0 uid=0 gid=0 euid=0 
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9220 
comm="systemd-tty-ask" exe="/bin/systemd-tty-ask-password-agent" 
subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null)

type=CWD msg=audit(1316699607.377:150425):  cwd="/"

type=PATH msg=audit(1316699607.377:150425): item=0 
name="/run/systemd/ask-password-block/136:0" inode=209876 dev=00:12 
mode=010600 ouid=0 ogid=0 rdev=00:00 
obj=unconfined_u:object_r:init_var_run_t:s0

The watch rule can be turned off using auditctl's -W option:

# auditctl -l
LIST_RULES: exit,always watch=/etc/shadow perm=w
# auditctl  -W /etc/shadow -p w
# auditctl -l
No rules

Paul.

[Arthur Dent]

>  On 12/11/2011 01:49 PM, Arthur Dent wrote:
> > Hello all,
> >
> > When I get a SEL alert it refers only to to the actual directory and not
> > the full pathname. For example:
> >
> > SELinux is preventing /usr/sbin/smbd from create access on the directory
> > 05.
> >
> > The advice for fixing this alert is probably useful but without knowing
> > the full path is actually completely useless:
> >
> > If you want to allow smbd to have create access on the 05 directory
> > Then you need to change the label on '05'
> > Do
> > # semanage fcontext -a -t samba_share_t '05'
> > # restorecon  -v '05'
> >
> > The problem is - I don't know where directory "05" is. It's
> probably
> > some temporary cache file or some such and trying to even find its
> > parent directory with a name like "05" makes using 'locate' or
> 'find'
> > really quite hard work.
> >
> > In this case the alert(s) (there were several - each with a different
> > numerical directory name) were actually caused when I tried to sync my
> > iPhone using iTunes installed on a Windows XP virtual machine running
> > under VirtualBox on this Fedora 16 host, accessing the music library via
> > a Samba share on a separate partition on the Fedora 16 box.... Yeah... I
> > know....
> >
> > But anyway - if I could find the full path of the directory in question
> > I *might* be able to take a closer look at where the problem lies...
> >
> > Thanks in advance for any help or suggestions.
>
>  Standard advice here is to add an audit watch record for something that
>  rarely happens, such as writing to /etc/shadow:
>
>  # auditctl -w /etc/shadow -p w
>
>  A happy side effect of this is that a PATH record is included in the
>  audit log for subsequent AVCs, e.g.
>
>  type=AVC msg=audit(1316699607.377:150425): avc:  denied  { read } for
>  pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876
>  scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0
>  tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
>
>  type=AVC msg=audit(1316699607.377:150425): avc:  denied  { open } for
>  pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876
>  scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0
>  tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
>
>  type=SYSCALL msg=audit(1316699607.377:150425): arch=c000003e syscall=2
>  success=yes exit=3 a0=14c60a0 a1=80900 a2=fffffffffffffed0
>  a3=7ffffdee5c80 items=1 ppid=4150 pid=4151 auid=0 uid=0 gid=0 euid=0
>  suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9220
>  comm="systemd-tty-ask" exe="/bin/systemd-tty-ask-password-agent"
>  subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null)
>
>  type=CWD msg=audit(1316699607.377:150425):  cwd="/"
>
>  type=PATH msg=audit(1316699607.377:150425): item=0
>  name="/run/systemd/ask-password-block/136:0" inode=209876 dev=00:12
>  mode=010600 ouid=0 ogid=0 rdev=00:00
>  obj=unconfined_u:object_r:init_var_run_t:s0
>
>  The watch rule can be turned off using auditctl's -W option:
>
>  # auditctl -l
>  LIST_RULES: exit,always watch=/etc/shadow perm=w
>  # auditctl  -W /etc/shadow -p w
>  # auditctl -l
>  No rules 
Thanks for that... That looks like a useful approach. I'm just wondering
however, what would the target for the watch be in my case?
Would it be /usr/sbin/smbd? - Which of course is the executable. Does
"watch" work on executables or just on files? If it only works I files I
am no better off as I don't know where the files are...

Thanks again...

Mark

[Paul Howarth]

On 12/12/2011 03:13 PM, Arthur Dent wrote:
> > On 12/11/2011 01:49 PM, Arthur Dent wrote:
> >> Hello all,
> >>
> >> When I get a SEL alert it refers only to to the actual directory and not
> >> the full pathname. For example:
> >>
> >> SELinux is preventing /usr/sbin/smbd from create access on the directory
> >> 05.
> >>
> >> The advice for fixing this alert is probably useful but without knowing
> >> the full path is actually completely useless:
> >>
> >> If you want to allow smbd to have create access on the 05 directory
> >> Then you need to change the label on '05'
> >> Do
> >> # semanage fcontext -a -t samba_share_t '05'
> >> # restorecon  -v '05'
> >>
> >> The problem is - I don't know where directory "05" is. It's
> probably
> >> some temporary cache file or some such and trying to even find its
> >> parent directory with a name like "05" makes using 'locate' or
> 'find'
> >> really quite hard work.
> >>
> >> In this case the alert(s) (there were several - each with a different
> >> numerical directory name) were actually caused when I tried to sync my
> >> iPhone using iTunes installed on a Windows XP virtual machine running
> >> under VirtualBox on this Fedora 16 host, accessing the music library via
> >> a Samba share on a separate partition on the Fedora 16 box.... Yeah... I
> >> know....
> >>
> >> But anyway - if I could find the full path of the directory in question
> >> I *might* be able to take a closer look at where the problem lies...
> >>
> >> Thanks in advance for any help or suggestions.
> >
> > Standard advice here is to add an audit watch record for something that
> > rarely happens, such as writing to /etc/shadow:
> >
> > # auditctl -w /etc/shadow -p w
> >
> > A happy side effect of this is that a PATH record is included in the
> > audit log for subsequent AVCs, e.g.
> >
> > type=AVC msg=audit(1316699607.377:150425): avc:  denied  { read } for
> > pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs
> ino=209876
> > scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0
> > tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
> >
> > type=AVC msg=audit(1316699607.377:150425): avc:  denied  { open } for
> > pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs
> ino=209876
> > scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0
> > tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
> >
> > type=SYSCALL msg=audit(1316699607.377:150425): arch=c000003e syscall=2
> > success=yes exit=3 a0=14c60a0 a1=80900 a2=fffffffffffffed0
> > a3=7ffffdee5c80 items=1 ppid=4150 pid=4151 auid=0 uid=0 gid=0 euid=0
> > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9220
> > comm="systemd-tty-ask" exe="/bin/systemd-tty-ask-password-agent"
> > subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null)
> >
> > type=CWD msg=audit(1316699607.377:150425):  cwd="/"
> >
> > type=PATH msg=audit(1316699607.377:150425): item=0
> > name="/run/systemd/ask-password-block/136:0" inode=209876 dev=00:12
> > mode=010600 ouid=0 ogid=0 rdev=00:00
> > obj=unconfined_u:object_r:init_var_run_t:s0
> >
> > The watch rule can be turned off using auditctl's -W option:
> >
> > # auditctl -l
> > LIST_RULES: exit,always watch=/etc/shadow perm=w
> > # auditctl  -W /etc/shadow -p w
> > # auditctl -l
> > No rules
>
>  Thanks for that... That looks like a useful approach. I'm just wondering
>  however, what would the target for the watch be in my case?
>  Would it be /usr/sbin/smbd? - Which of course is the executable. Does
>  "watch" work on executables or just on files? If it only works I files I
>  am no better off as I don't know where the files are... 
The /etc/shadow watch in the example above will be fine. The presence of 
*any* watch triggers the PATH record in the audit logs for all events. 
Choosing an event that rarely happens just keeps the growth rate of the 
logs down.

Paul.

[Moray Henderson]

>  From: Arthur Dent
>  Sent: 11 December 2011 13:49
>  
>  Hello all,
>  
>  When I get a SEL alert it refers only to to the actual directory and
>  not the full pathname. For example:
>  
>  SELinux is preventing /usr/sbin/smbd from create access on the
>  directory 05.
>  
>  The advice for fixing this alert is probably useful but without knowing
>  the full path is actually completely useless:
>  
>  If you want to allow smbd to have create access on the 05 directory
>  Then you need to change the label on '05'
>  Do
>  # semanage fcontext -a -t samba_share_t '05'
>  # restorecon  -v '05'
>  
>  The problem is - I don't know where directory "05" is. It's probably
>  some temporary cache file or some such and trying to even find its
>  parent directory with a name like "05" makes using 'locate' or
> 'find'
>  really quite hard work.
>  
>  In this case the alert(s) (there were several - each with a different
>  numerical directory name) were actually caused when I tried to sync my
>  iPhone using iTunes installed on a Windows XP virtual machine running
>  under VirtualBox on this Fedora 16 host, accessing the music library
>  via a Samba share on a separate partition on the Fedora 16 box....
>  Yeah... I know....
>  
>  But anyway - if I could find the full path of the directory in question
>  I *might* be able to take a closer look at where the problem lies...
>  
>  Thanks in advance for any help or suggestions.
>  
>  Mark 
If you get the device and inode from the the AVC message you can use find's -inum
option to look for the inode number on the device's filesystem rather than -name.



Moray.
“To err is human; to purr, feline.”

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/11/2011 08:49 AM, Arthur Dent wrote:
>  Hello all,
>  
>  When I get a SEL alert it refers only to to the actual directory
>  and not the full pathname. For example:
>  
>  SELinux is preventing /usr/sbin/smbd from create access on the
>  directory 05= 
http://danwalsh.livejournal.com/34903.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk7mJYUACgkQrlYvE4MpobP30ACeI+HTEsComzz6R79yge5PWRvu
> Z4AAn3L7QIEm/f8GMsO9ahSC1QvCdV66
> =jwGO
> -----END PGP SIGNATURE-----

[Arthur Dent]

On Mon, 2011-12-12 at 11:02 -0500, Daniel J Walsh wrote:
>  On 12/11/2011 08:49 AM, Arthur Dent wrote:
>  > Hello all,
>  > 
>  > When I get a SEL alert it refers only to to the actual directory
>  > and not the full pathname. For example:
>  > 
>  > SELinux is preventing /usr/sbin/smbd from create access on the
>  > directory 05=
>  
>  http://danwalsh.livejournal.com/34903.html 
Hi Dan,

That's a really useful blog entry. I have bookmarked it for future
reference. However, I'm not sure it helps me here. This is the raw avc
output:

Raw Audit Messages
type=AVC msg=audit(1323609255.771:112): avc:  denied  { create } for  pid=2618
comm="smbd" name="05" scontext=system_u:system_r:smbd_t:s0
tcontext=system_u:object_r:dosfs_t:s0 tclass=dir


type=SYSCALL msg=audit(1323609255.771:112): arch=i386 syscall=mkdir success=no exit=EACCES
a0=213e7cf0 a1=1ed a2=e49ff4 a3=bf90f3fc items=0 ppid=1039 pid=2618 auid=4294967295 uid=0
gid=0 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none)
ses=4294967295 comm=smbd exe=/usr/sbin/smbd subj=system_u:system_r:smbd_t:s0 key=(null)

Hash: smbd,smbd_t,dosfs_t,dir,create

The partition where the music files are kept is a FAT drive (historical
accident). Does that explain why there are no inode numbers?

Thanks for the help...

Mark

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/12/2011 05:01 PM, Arthur Dent wrote:
>  Raw Audit Messages type=AVC msg=audit(1323609255.771:112): avc:
>  denied  { create } for  pid=2618 comm="smbd" name="05"
>  scontext=system_u:system_r:smbd_t:s0
>  tcontext=system_u:object_r:dosfs_t:s0 tclass=dir
>  
>  
>  type=SYSCALL msg=audit(1323609255.771:112): arch=i386 syscall=mkdir
>  success=no exit=EACCES a0=213e7cf0 a1=1ed a2=e49ff4 a3=bf90f3fc
>  items=0 ppid=1039 pid=2618 auid=4294967295 uid=0 gid=0 euid=1000
>  suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none)
>  ses=4294967295 comm=smbd exe=/usr/sbin/smbd
>  subj=system_u:system_r:smbd_t:s0 key=(null)
>  
>  Hash: smbd,smbd_t,dosfs_t,dir,create 

Yes this looks like you want to share samba on a dos file system,  you
will need to write a custom policy module to allow this.


# cat > mysamba.te << _EOF
policy_module(mysamba, 1.0)
gen_require(`
type smbd_t;
')

fs_manage_dos_dirs(smbd_t)
fs_manage_dos_files(smbd_t)
_EOF
# make -f /usr/share/selinux/devel/Makefile
# semodule -i mysamba.pp
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk7nnncACgkQrlYvE4MpobOW3QCfWt5qn2i9ShI6+hxQLN4s8CWc
> gXkAoOK3jYuud4+e0169uQx1ED2c94nj
> =y//Y
> -----END PGP SIGNATURE-----

[yersinia]

On Sun, Dec 11, 2011 at 2:49 PM, Arthur Dent <misc.lists(a)blueyonder.co.uk&gt;wrote:

>  Hello all,
>
>  When I get a SEL alert it refers only to to the actual directory and not
>  the full pathname. For example:
>
>  SELinux is preventing /usr/sbin/smbd from create access on the directory
>  05.
>
>  The advice for fixing this alert is probably useful but without knowing
>  the full path is actually completely useless:
>
>  If you want to allow smbd to have create access on the 05 directory
>  Then you need to change the label on '05'
>  Do
>  # semanage fcontext -a -t samba_share_t '05'
>  # restorecon  -v '05'
>
>  The problem is - I don't know where directory "05" is. It's probably
>  some temporary cache file or some such and trying to even find its
>  parent directory with a name like "05" makes using 'locate' or
> 'find'
>  really quite hard work.
>
>  In this case the alert(s) (there were several - each with a different
>  numerical directory name) were actually caused when I tried to sync my
>  iPhone using iTunes installed on a Windows XP virtual machine running
>  under VirtualBox on this Fedora 16 host, accessing the music library via
>  a Samba share on a separate partition on the Fedora 16 box.... Yeah... I
>  know....
>
>  But anyway - if I could find the full path of the directory in question
>  I *might* be able to take a closer look at where the problem lies...
>
>  Thanks in advance for any help or suggestions.
>
>  Mark
>
>
>  In this post Dan Walsh describe the issue, and the resolutions, in more 
details.

hth

>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>