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
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.
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
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.
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.”
-----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
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=
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
-----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
On Sun, Dec 11, 2011 at 2:49 PM, Arthur Dent misc.lists@blueyonder.co.ukwrote:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Arthur Dent -
Daniel J Walsh -
Moray Henderson -
Paul Howarth -
yersinia