Description of problem: AVC's generated on a F18 install with confined users. Version-Release number of selected component (if applicable): LXDE install, F18 DVD How reproducible: Firstboot Steps to Reproduce: 1. install 2. update 3. gui login (lxdm) Actual results: See attached AVC list. Expected results: No AVC's generated from unbind, dnssec-trigger, newaliases, or sysadm_t. Additional info: semanage login -a -S targeted -s sysadm_u -r 's0-s0:c0.c1023' root semanage login -a -S targeted -s staff_u -r s0-s0:c0.c1023 dj setsebool -P unconfined_login off semodule -d unconfined Change /etc/sudoers %wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL Change /etc/aliases root: dj Run "newaliases" Install "dnssec-trigger"
Created attachment 692591 [details] ausearch -m avc -ts 21:12 (last bootup time)
# restorecon -Rv /var restorecon: Warning no default label for /var/lib/nfs/rpc_pipefs
Logout / Login again: (no reboot, just a logout) # ausearch -m avc -ts recent ---- time->Sun Feb 3 22:38:57 2013 type=SYSCALL msg=audit(1359952737.113:443): arch=c000003e syscall=16 success=no exit=-25 a0=1 a1=5401 a2=7fffcd976ee0 a3=7fffcd976d00 items=0 ppid=2110 pid=2124 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=10 tty=(none) comm="grep" exe="/usr/bin/grep" subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1359952737.113:443): avc: denied { ioctl } for pid=2124 comm="grep" path="/var/log/lxdm.log" dev="sda2" ino=917551 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_log_t:s0 tclass=file It wants "allow staff_t xdm_log_t:file ioctl;" ? From ps: system_u:system_r:xdm_t:s0-s0:c0.c1023 root 493 1 0 21:32 ? 00:00:00 /usr/sbin/lxdm-binary
Are you able to do log in in enforcing mode?
No. I cannot login. If I set it to permissive, I can login. Change to enforcing, I can no longer logout.
Ok, I added fixes.
Not sure if you want a new BZ or not, but mock also fails: #============= mock_t ============== allow mock_t tmpfs_t:chr_file { setattr read create getattr write ioctl unlink open }; allow mock_t tmpfs_t:dir { rename setattr read create write rmdir remove_name add_name }; allow mock_t tmpfs_t:file { rename execute setattr read lock create getattr execute_no_trans write ioctl link unlink open append }; allow mock_t tmpfs_t:lnk_file { read getattr unlink create setattr }; allow mock_t user_home_t:lnk_file read; #============= mock_t ============== allow mock_t tmpfs_t:file { rename execute setattr read lock create getattr execute_no_trans write ioctl link unlink open append }; fs_manage_tmpfs_chr_files(mock_t) fs_manage_tmpfs_dirs(mock_t) fs_manage_tmpfs_symlinks(mock_t) userdom_read_user_home_content_symlinks(mock_t)
Could you also attach AVC msgs for these. Thank you.
Created attachment 693460 [details] AVC list from using mock fstab: tmpfs /var/lib/mock tmpfs size=4G,nosuid,dev 0 0 mock outputs to ~/mock Bool: mock_enable_homedirs --> on
Restorecon provided this: restorecon reset /var/lib/mock context staff_u:object_r:tmpfs_t:s0->staff_u:object_r:mock_var_lib_t:s0 I tried adding context= / fscontext= / rootcontext= .. but they all refused to mount the filesystem with this error: [75374.487036] SELinux: security_context_to_sid(system_u:object_r:mock_var_lib_t) failed for (dev tmpfs, type tmpfs) err no=-22 What is the proper option to use, and is that partially to blame for mock AVC's ?
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.