Looking for directory paths...

[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.