| Summary: | AVCs appear when a user derived from "Admin User Role" tries to log in via GDM | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Milos Malik <mmalik> |
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | dwalsh, mgrepl, syeghiay |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-06 11:12:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Here is the content of staff_admin.te file generated by selinux-polgengui ============================================ policy_module(staff_admin,1.0.0) ######################################## # # Declarations # userdom_admin_user_template(staff_admin) ######################################## # # staff_admin local policy # ######################################## # # staff_admin local policy # domain_use_interactive_fds(staff_admin_t) files_read_etc_files(staff_admin_t) miscfiles_read_localization(staff_admin_t) Something in /var/log/secure? Based on Miroslav's advice I replaced following line userdom_admin_user_template(staff_admin) by following line userdom_base_user_template(staff_admin) I recompiled and reloaded the policy module. Now when I try to log in as the same user I see following question in GDM window: Would you like to enter a security context ? [N] ____________ Following messages appeared in /var/log/secure before comment#4 modification was done: May 5 14:08:38 localhost useradd[3671]: new group: name=tulpas4, GID=505 May 5 14:08:38 localhost useradd[3671]: new user: name=tulpas4, UID=504, GID=505, home=/home/tulpas4, shell=/bin/bash May 5 14:09:00 localhost passwd: pam_unix(passwd:chauthtok): password changed for tulpas4 May 5 14:09:00 localhost passwd: gkr-pam: couldn't update the 'login' keyring password: no old password was entered May 5 14:09:16 localhost pam: gdm-password[3550]: pam_selinux(gdm-password:session): Error! Unable to set tulpas4 key creation context staff_admin_u:staff_admin_r:oddjob_mkhomedir_t:s0. May 5 14:09:16 localhost pam: gdm-password[3689]: gkr-pam: couldn't run gnome-keyring-daemon: Permission denied May 5 14:09:16 localhost pam: gdm-password[3550]: gkr-pam: gnome-keyring-daemon didn't start properly properly May 5 14:09:16 localhost pam: gdm-password[3550]: pam_unix(gdm-password:session): session opened for user tulpas4 by (uid=0) Milos, I meant userdom_unpriv_user_template() or userdom_restricted_xwindows_user_template() Also could you add # semanage login -l # semanage user -l # semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023
root unconfined_u s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
tulpas4 staff_admin_u s0
xguest xguest_u s0
# semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
git_shell_u user s0 s0 git_shell_r
guest_u user s0 s0 guest_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_admin_u user s0 s0 staff_admin_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0 user_r
xguest_u xguest s0 s0 xguest_r
#
Inspired by comment#6 I replaced following line userdom_admin_user_template(staff_admin) by following line userdom_unpriv_user_template(staff_admin) I recompiled the policy module, reloaded it and tried to log in via GDM. Result: the user is able to log in via GDM. Then I replaced following line userdom_unpriv_user_template(staff_admin) by following line userdom_restricted_xwindows_user_template(staff_admin) I recompiled the policy module again, reloaded it and tried to log in via GDM. Result: the user is able to log in via GDM. The question is why is the same user unable to log in via GDM if we use the original line generated by selinux-polgengui: userdom_admin_user_template(staff_admin) Milos, you will need to log in as staff_u via GDM for example and then use the newrole to reach staff_admin role. https://access.redhat.com/knowledge/techbriefs/confining-users-predefined-selinux-security-policies-red-hat-enterprise-linux-6 Milos, try the following. Milos if you are in BRNO I will be there on Thursday next week May 12th. I might do a talk on writing SELinux policy. |
Description of problem: Version-Release number of selected component (if applicable): selinux-policy-3.7.19-93.el6.noarch selinux-policy-targeted-3.7.19-93.el6.noarch selinux-policy-mls-3.7.19-93.el6.noarch selinux-policy-doc-3.7.19-93.el6.noarch selinux-policy-minimum-3.7.19-93.el6.noarch How reproducible: always Steps to Reproduce: 1. create a directory where you can save new policy (mkdir /root/staff_admin) 2. go to that directory (cd /root/staff_admin) 3. generate the new policy via selinux-polgengui (choose "Admin User Role", continue clicking "Forward" button till "Apply" button appears, then click "Apply", "OK", "Close" buttons) 4. run the staff_admin.sh script 5. add an staff_admin_u user (useradd -Z staff_admin_u USERNAME) 6. set a password for the user (passwd USERNAME) 7. try to log in as USERNAME via GDM 8. you will likely see "Unable to open session" message in GDM window Actual results: * the user in not able to log in via GDM * 2 AVCs: ---- time->Thu May 5 14:09:16 2011 type=SYSCALL msg=audit(1304597356.467:240): arch=40000003 syscall=4 success=no exit=-13 a0=8 a1=9d7f868 a2=32 a3=9d7f868 items=0 ppid=3489 pid=3550 auid=504 uid=0 gid=505 euid=0 suid=0 fsuid=0 egid=505 sgid=505 fsgid=505 tty=(none) ses=11 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1304597356.467:240): avc: denied { create } for pid=3550 comm="gdm-session-wor" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=staff_admin_u:staff_admin_r:oddjob_mkhomedir_t:s0 tclass=key ---- time->Thu May 5 14:09:16 2011 type=SYSCALL msg=audit(1304597356.473:241): arch=40000003 syscall=11 success=no exit=-13 a0=f94449 a1=bfec2400 a2=9d7fb00 a3=f9448c items=0 ppid=3550 pid=3689 auid=504 uid=504 gid=505 euid=504 suid=504 fsuid=504 egid=505 sgid=505 fsgid=505 tty=(none) ses=11 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1304597356.473:241): avc: denied { entrypoint } for pid=3689 comm="gdm-session-wor" path="/usr/bin/gnome-keyring-daemon" dev=dm-0 ino=26588 scontext=staff_admin_u:staff_admin_r:oddjob_mkhomedir_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file ---- Expected results: * no AVCs * the user is able to log in via GDM Additional information: It doesn't matter if packages oddjob and oddjob-mkhomedir are installed, these AVCs appear in both scenarios.