recently-used.xbel wrong context

Sat Feb 19 18:40:10 UTC 2011

-----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 at 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 at trevor4 ]$ chcon --reference=/home/trevor/.recently-used 
> ~/.recently-used.xbel
> [trevor at 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 at 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 at trevor4 ~]# uptime
>  18:10:11 up 52 days,  7:58, 15 users,  load average: 0.43, 0.43, 0.25
> [root at trevor4 ~]#
> 
> [trevor at 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 at 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 at lists.fedoraproject.org
> 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-----