FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 12-11-2011, 12:49 PM
Arthur Dent
 
Default Looking for directory paths...

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

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 08:36 AM
Paul Howarth
 
Default Looking for directory paths...

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_agen t_t:s0
tcontext=unconfined_ubject_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_agen t_t:s0
tcontext=unconfined_ubject_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_ubject_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.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 09:16 AM
Moray Henderson
 
Default Looking for directory paths...

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




--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 02:13 PM
"Arthur Dent"
 
Default Looking for directory paths...

> 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_agen t_t:s0
> tcontext=unconfined_ubject_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_agen t_t:s0
> tcontext=unconfined_ubject_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_ubject_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


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 02:17 PM
"Arthur Dent"
 
Default Looking for directory paths...

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

Ha! That looks useful. I can't try it at the moment because, although I
can ssh into that machine from work - I can't reproduce the event from the
command line. I will try as soon as I can...

Thanks again...

Mark


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 02:23 PM
Paul Howarth
 
Default Looking for directory paths...

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_agen t_t:s0
>> tcontext=unconfined_ubject_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_agen t_t:s0
>> tcontext=unconfined_ubject_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_ubject_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.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 03:02 PM
Daniel J Walsh
 
Default Looking for directory paths...

-----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+HTEsComz z6R79yge5PWRvu
Z4AAn3L7QIEm/f8GMsO9ahSC1QvCdV66
=jwGO
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 03:11 PM
yersinia
 
Default Looking for directory paths...

On Sun, Dec 11, 2011 at 2:49 PM, Arthur Dent <misc.lists@blueyonder.co.uk> 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@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/selinux


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-12-2011, 09:01 PM
Arthur Dent
 
Default Looking for directory paths...

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_ubject_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

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 12-13-2011, 05:50 PM
Daniel J Walsh
 
Default Looking for directory paths...

-----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_ubject_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/

iEYEARECAAYFAk7nnncACgkQrlYvE4MpobOW3QCfWt5qn2i9Sh I6+hxQLN4s8CWc
gXkAoOK3jYuud4+e0169uQx1ED2c94nj
=y//Y
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 03:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org