-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/19/2011 07:18 PM, Trevor Hemsley wrote:
> Hi
>
> I'm running Centos 5.5 with all the most recent patches applied and am
> seeing a strange problem with a file in my home directory called
> .recently-used.xbel. It keeps getting the wrong selinux context assigned
> to it though I have no idea what is changing it or when.
>
> [trevor@trevor4 ]$ ls -aZl ~/.recently-used.xbel
> -rw-rw-r-- 1 user_u:object_r:user_home_dir_t trevor trevor 148481 Feb
> 18 20:22 /home/trevor/.recently-used.xbel
> [trevor@trevor4 ]$ chcon --reference=/home/trevor/.recently-used
> ~/.recently-used.xbel
> [trevor@trevor4 ]$ ls -aZl ~/.recently-used.xbel
> -rw-rw-r-- 1 user_u:object_r:user_home_t trevor trevor 148481 Feb
> 18 20:22 /home/trevor/.recently-used.xbel
It is a gnome-panel thing i believe. gnome-aware applications create
these files in your home directory so that your recently used files show
up on your gnome-panel under places -> Recent documents.
When users create files in their home directories, these creates files
"type transition" from user_home_dir_t to user_home_t. Without this
specified typ_transition, these files would be created with the type
inherited from their parent directory, which incidentally is
user_home_dir_t.
This leads me to believe that some gnome-aware application does not run
it the user domain. Which means that the rules that apply to you as a
user do not apply to this application.
The rules that do apply to this application do not include said type
transition. Thus the application seems allowed to create files in
user_home_dir_t directories but there is no rule that says, if it does
then type transition from user_home_dir_t to user_home_t.
I am not aware of any gnome-aware user application confined, and so i do
not know what created this file.
There are ways to figure this out but it may flood your logs, kill
setroubleshoot and cause increased load.
One could force SELinux to audit all domain creating files with type
user_home_dir_t. Then wait for the event to occur again and see if the
forced audit shows information about this event that can be used to
investigate further.
mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest,1.0.0)
gen_require(\` attribute domain, userdomain; type user_home_dir_t; ')
auditallow { domain userdomain } user_home_dir_t:file create;" > mytest.te;
yum install selinux-policy-devel
make -f /usr/share/selinux/devel/Makefile mytest.pp
semodule -i mytest.pp
<< reproduce or wait for re-occurance >>
<< see/enclose avc "grants" ( grep -i grant /var/log/audit/audit.log ) >>
semodule -r mytest.pp
> It's a file not a directory yet it is being labelled as home_dir_t not
> home_t and this causes avc messages. I change it back using the chcon
> command above and it stays that way for a while and a few
> days/hour/weeks later, it comes back as home_dir_t again. I'm not sure
> what it is that triggers the re-mislabelling but I do know that I
> 'fixed' this via chcon about a week ago and now it's back again and it's
> not the first time that this has happened. Looking at these two avcs it
> would appear that I 'fixed' it shortly after the 13th and it came back
> sometime today or yesterday at a guess.
>
> 63. 13/02/11 02:12:53 smbd user_u:system_r:smbd_t:s0 4 file getattr
> user_u:object_r:user_home_dir_t:s0 denied 47358
> 64. 19/02/11 17:39:10 smbd user_u:system_r:smbd_t:s0 4 file getattr
> user_u:object_r:user_home_dir_t:s0 denied 54205
>
> [root@trevor4 ~]# ausearch -i -a 54205
> ----
> type=SYSCALL msg=audit(19/02/11 17:39:10.711:54205) : arch=x86_64
> syscall=stat success=yes exit=0 a0=7fffe6a808d0 a1=7fffe6a80000
> a2=7fffe6a80000 a3=7fffe6a804d0 items=0 ppid=2533 pid=15831 auid=trevor
> uid=trevor gid=root euid=trevor suid=root fsuid=trevor egid=trevor
> sgid=root fsgid=trevor tty=(none) ses=2 comm=smbd exe=/usr/sbin/smbd
> subj=user_u:system_r:smbd_t:s0 key=(null)
> type=AVC msg=audit(19/02/11 17:39:10.711:54205) : avc: denied {
> getattr } for pid=15831 comm=smbd path=/home/trevor/.recently-used.xbel
> dev=dm-5 ino=10453859 scontext=user_u:system_r:smbd_t:s0
> tcontext=user_u:object_r:user_home_dir_t:s0 tclass=file
>
> I haven't run a relabel of my system recently and even if I had it
> hasn't been since the machine was last rebooted..
>
> [root@trevor4 ~]# uptime
> 18:10:11 up 52 days, 7:58, 15 users, load average: 0.43, 0.43, 0.25
> [root@trevor4 ~]#
>
> [trevor@trevor4 ~]$ rpm -q selinux-policy
> selinux-policy-2.4.6-279.el5_5.2
>
> Anyone got any ideas what could be causing this? I can't see anything in
> semanage fcontext that could be doing it...
>
> [root@trevor4 ~]# semanage fcontext -l | grep home
> /usr/sbin/genhomedircon regular file
> system_u:object_r:semanage_exec_t:s0
> /usr/lib/oddjob/mkhomedir regular file
> system_u:object_r:oddjob_mkhomedir_exec_t:s0
>
> Yours
> Baffled of Brighton :)
>
>
> --
> selinux mailing list
> selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1gDooACgkQMlxVo39jgT+edwCghYmd4hlq+xxVdQ73QT2eqj6+
hRsAn3b5G8d7Sr9UwRfE5TSoIpxINkyZ
=v6L9
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
