Description of problem: Any user confined as a user_u or xguest_u may not log into XFCE. These user types may log in to KDE. (I have not tried Gnome3) Upon login the user receives the following error: Unable to determine failsafe session name. Possible causes: xfconfd isn't running (D-Bus setup problem), environment variable $XDG_CONFIG_DIRS is set incorrectly (must include "/etc") or xfce4-session is installed incorrectly. Upon digging for information, setting the SELinux enforcement to Permissive allows the user to log in without issue. The following AVCs are generated: type=AVC msg=audit(1312030331.330:252): avc: denied { execute_no_trans } for pid=3799 comm="dbus-daemon" path="/usr/lib/xfce4/xfconf/xfconfd" dev=sda6 ino=1587670 scontext=user_u:user_r:user_dbusd_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file type=AVC msg=audit(1312030331.333:253): avc: denied { connectto } for pid=3799 comm="xfconfd" path=*PATH* scontext=user_u:user_r:user_dbusd_t:s0 tcontext=user_u:user_r:user_dbusd_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1312030331.722:254): avc: denied { write } for pid=3862 comm="gpg-agent" name=".cache" dev=sda8 ino=788193 scontext=user_u:user_r:gpg_agent_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=dir type=AVC msg=audit(1312030331.722:254): avc: denied { add_name } for pid=3862 comm="gpg-agent" name="gpg-agent-info" scontext=user_u:user_r:gpg_agent_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=dir type=AVC msg=audit(1312030331.722:254): avc: denied { create } for pid=3862 comm="gpg-agent" name="gpg-agent-info" scontext=user_u:user_r:gpg_agent_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file type=AVC msg=audit(1312030331.722:254): avc: denied { write open } for pid=3862 comm="gpg-agent" name="gpg-agent-info" dev=sda8 ino=###### scontext=user_u:user_r:gpg_agent_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file type=AVC msg=audit(1312030352.14:255): avc: denied { read write } for pid=3715 comm="gnome-keyring-d" name="user" dev=sda8 ino=###### scontext=user_u:user_r:user_gkeyringd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file type=AVC msg=audit(1312030352.14:255): avc: denied { open } for pid=3715 comm="gnome-keyring-d" name="user" dev=sda8 ino=###### scontext=user_u:user_r:user_gkeyringd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file To be absolutely sure that I don't have a file labelling issue, I executed 'fixfiles onboot' and rebooted the system and tried again. Version-Release number of selected component (if applicable): xfce4-settings-4.8.2-1.fc15.i686 xfce4-session-4.8.1-4.fc15.i686 selinux-policy-3.9.16-34.fc15.noarch selinux-policy-targeted-3.9.16-34.fc15.noarch How reproducible: 100% (Always) when SELinux is in Enforcing Mode Steps to Reproduce: 1. Create a user and confine the user to the user_u context: $ useradd newuser $ passwd newuser $ /usr/sbin/semanage login -a -s user_u newuser 2. Log out and log back in as the new user 3. Notice the error message when logging in. Clicking the button in the popup box kicks you back to either gdm or kdm depending on what you have installed. Actual results: Blocked from logging in Expected results: Should log in normally Additional info:
Looks like policy needs adjustment here. A user needs to be able to dbus-launch xfconfd and possibly gnome-keyring and gpg-agent (if they desire to use them). Adding selinux policy folks here for comment.
Try to execute these steps # chcon -t bin_t /usr/lib/xfce4/xfconf/xfconfd # setsebool -P gpg_agent_env_file 1 and where is name="user" exactly located in your home directory.
(In reply to comment #2) > Try to execute these steps > > # chcon -t bin_t /usr/lib/xfce4/xfconf/xfconfd > # setsebool -P gpg_agent_env_file 1 > I made the changes recommended above. I am now able to log into XFCE. There's some behavior I don't expect, but I'm going to try the same tasks with SELinux in permissive mode and see if it is just my lack of knowledge with XFCE. (I'm sort of new to the DE) > > and where is name="user" exactly located in your home directory. I'm sorry, I don't follow what you are asking here. Do you want to know what file this is trying to access?
(In reply to comment #3) > (In reply to comment #2) > > Try to execute these steps > > > > # chcon -t bin_t /usr/lib/xfce4/xfconf/xfconfd > > # setsebool -P gpg_agent_env_file 1 > > > > I made the changes recommended above. I am now able to log into XFCE. There's > some behavior I don't expect, but I'm going to try the same tasks with SELinux > in permissive mode and see if it is just my lack of knowledge with XFCE. (I'm > sort of new to the DE) > > > > > and where is name="user" exactly located in your home directory. > > I'm sorry, I don't follow what you are asking here. Do you want to know what > file this is trying to access? Yes.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Try to execute these steps > > > > > > # chcon -t bin_t /usr/lib/xfce4/xfconf/xfconfd > > > # setsebool -P gpg_agent_env_file 1 > > > > > > > I made the changes recommended above. I am now able to log into XFCE. There's > > some behavior I don't expect, but I'm going to try the same tasks with SELinux > > in permissive mode and see if it is just my lack of knowledge with XFCE. (I'm > > sort of new to the DE) > > > > > > > > and where is name="user" exactly located in your home directory. > > > > I'm sorry, I don't follow what you are asking here. Do you want to know what > > file this is trying to access? > > Yes. The filename is /home/newuser/.cache/gpg-agent-info, cannot also write to .cache for the same reason. The directory /home/newuser/.cache is labelled as user_u:object_r:cache_home_t:s0 here as is the gpg-agent-info file. Thanks in advance.
Actually I was asking for the file from this AVC type=AVC msg=audit(1312030352.14:255): avc: denied { read write } for pid=3715 comm="gnome-keyring-d" name="user" dev=sda8 ino=###### scontext=user_u:user_r:user_gkeyringd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file where name of the file is "user".
I did a find /home -inum ###### (sda8 is /home) and got the following result: /home/newuser/.local/share/akonadi/db_data/localhost.pid
Did I do something wrong with providing the info? The system in question was reinstalled w/ F15 XFCE... the two commands above allow me to get in in the user_u context. The only other issue I see running as user_u is: type=AVC msg=audit(1313364714.128:48): avc: denied { create } for pid=1355 comm="gpg-agent" name=".gnupg" scontext=user_u:user_r:gpg_agent_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir
Could you try to execute # restorecon -R -v /home/newuser
I ran the command, logged out, and logged back in. I am still getting the message: type=AVC msg=audit(1314394338.755:48): avc: denied { create } for pid=1379 comm="gpg-agent" name=".gnupg" scontext=user_u:user_r:gpg_agent_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir If I do an ls -alhZ I see: drwx------. newuser newuser user_u:object_r:gpg_secret_t:s0 .gnupg However, with the chcon and booleans previously set above, I can log in reliably now.
ok, it looks like a bug in the policy. If you execute # grep create /var/log/audit/audit.log |audit2allow -M mypol # semodule -i mypol.pp does it work together with the enabled boolean?
I completed those commands. I tried to run gpg-agent directly, and got the following: type=SYSCALL msg=audit(1314663692.503:70): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfa84860 a2=4876f3b4 a3=8387210 items=0 ppid=1637 pid=1730 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=pts2 ses=1 comm="gpg-agent" exe="/usr/bin/gpg-agent" subj=user_u:user_r:gpg_agent_t:s0 key=(null) type=AVC msg=audit(1314663692.503:70): avc: denied { connectto } for pid=1730 comm="gpg-agent" path="/tmp/gpg-lzxtMb/S.gpg-agent" scontext=user_u:user_r:gpg_agent_t:s0 tcontext=user_u:user_r:gpg_agent_t:s0 tclass=unix_stream_socket Using the commands you provided to generate the allow policy, everything else came up fine. At this point, things seem to be well here. Thanks for all of your help.
Great. I am fixing the policy.
Since this was a policy change, changing component from xfce4.
I reloaded a box w/ XFCE, F15, ran all updates, confined a user as user_u and the user is still not able to log in. Which policy update contains the fix? I don't see this bug listed in the change log. I made the changes necessary in comment 2, and the user is able to log in.
(In reply to comment #15) > I reloaded a box w/ XFCE, F15, ran all updates, confined a user as user_u and > the user is still not able to log in. Which policy update contains the fix? I > don't see this bug listed in the change log. I made the changes necessary in > comment 2, and the user is able to log in. There was bug in the labeling. Fixed in selinux-policy-3.9.16-46.fc15
selinux-policy-3.9.16-48.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-48.fc15
Package selinux-policy-3.9.16-48.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-48.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16023/selinux-policy-3.9.16-48.fc15 then log in and leave karma (feedback).
selinux-policy-3.9.16-48.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.