Hi all,
After an F7 -> F8 upgrade, I can't start the xorg server in enforcing mode. Logs say things like:
type=AVC msg=audit(1195824979.681:23): avc: denied { getattr } for pid=2585 comm="gdm-binary" path="/tmp/.X11-unix" dev=dm-0 ino=8871462 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1195824979.681:23): arch=40000003 syscall=196 success=yes exit=0 a0=8090daf a1=bfb4d320 a2=c2bff4 a3=3 items=0 ppid=1 pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="gdm-binary" exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
audit2allow says:
#============= cupsd_t ============== allow cupsd_t nscd_t:nscd shmemserv;
#============= iptables_t ============== allow iptables_t nscd_t:nscd shmemserv;
#============= nfsd_t ============== allow nfsd_t nscd_t:nscd { shmemserv getserv };
#============= ntpd_t ============== allow ntpd_t nscd_t:nscd shmemserv;
#============= sendmail_t ============== allow sendmail_t fail2ban_log_t:file append; allow sendmail_t initrc_t:unix_stream_socket { read write }; allow sendmail_t nscd_t:nscd shmemserv;
#============= system_mail_t ============== allow system_mail_t nscd_t:nscd shmemserv;
#============= xdm_t ============== allow xdm_t initrc_tmp_t:dir { getattr setattr };
#============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file create;
Now... how would this have happened? Should I just run the above commands to fix everything, or is there a deeper bug / issue?
Help appreciated!
- Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dr. Michael J. Chudobiak wrote:
Hi all,
After an F7 -> F8 upgrade, I can't start the xorg server in enforcing mode. Logs say things like:
type=AVC msg=audit(1195824979.681:23): avc: denied { getattr } for pid=2585 comm="gdm-binary" path="/tmp/.X11-unix" dev=dm-0 ino=8871462 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1195824979.681:23): arch=40000003 syscall=196 success=yes exit=0 a0=8090daf a1=bfb4d320 a2=c2bff4 a3=3 items=0 ppid=1 pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="gdm-binary" exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
audit2allow says:
#============= cupsd_t ============== allow cupsd_t nscd_t:nscd shmemserv;
#============= iptables_t ============== allow iptables_t nscd_t:nscd shmemserv;
#============= nfsd_t ============== allow nfsd_t nscd_t:nscd { shmemserv getserv };
#============= ntpd_t ============== allow ntpd_t nscd_t:nscd shmemserv;
#============= sendmail_t ============== allow sendmail_t fail2ban_log_t:file append; allow sendmail_t initrc_t:unix_stream_socket { read write }; allow sendmail_t nscd_t:nscd shmemserv;
#============= system_mail_t ============== allow system_mail_t nscd_t:nscd shmemserv;
#============= xdm_t ============== allow xdm_t initrc_tmp_t:dir { getattr setattr };
#============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file create;
Now... how would this have happened? Should I just run the above commands to fix everything, or is there a deeper bug / issue?
Help appreciated!
- Mike
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Looks like you might have some labeliing problems, but first update to the latest version of selinux-policy
yum -y upgrade selinux-policy
And see if most of these have been fixed.
#============= xdm_t ============== allow xdm_t initrc_tmp_t:dir { getattr setattr };
#============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file create;
Now... how would this have happened? Should I just run the above commands to fix everything, or is there a deeper bug / issue?
Looks like you might have some labeliing problems, but first update to the latest version of selinux-policy
yum -y upgrade selinux-policy
And see if most of these have been fixed.
Daniel,
After updating another machine (F7 -> F8), I still get gdm failures due to selinux, as originally reported. The problem has not be fixed by recent rpms. See below:
[root@titus log]# rpm -qa | grep selinux libselinux-python-2.0.43-1.fc8 selinux-policy-devel-3.0.8-64.fc8 libselinux-devel-2.0.43-1.fc8 selinux-policy-3.0.8-64.fc8 selinux-policy-targeted-3.0.8-64.fc8 libselinux-2.0.43-1.fc8
[root@titus log]# ps ax | grep gdm 2264 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon 2355 ? Ss 0:00 /bin/sh /etc/gdm/XKeepsCrashing 2372 ? S 0:00 /usr/libexec/gdmopen -l /bin/sh -c /etc/gdm/XKeepsCrashing -noopen 2373 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen 2779 pts/0 S+ 0:00 grep gdm
[root@titus log]# audit2allow -i messages ...snip... #============= xdm_t ============== allow xdm_t default_t:file write; allow xdm_t initrc_tmp_t:dir { getattr search setattr }; #============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write remove_name getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file { create unlink };
Disabling selinux lets gdm / xorg run correctly.
I tried removing all selinux rpms, rm -rf /etc/selinux, re-installing selinux, and touching /.autorelabel. No better.
- Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dr. Michael J. Chudobiak wrote:
#============= xdm_t ============== allow xdm_t initrc_tmp_t:dir { getattr setattr };
#============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file create;
Now... how would this have happened? Should I just run the above commands to fix everything, or is there a deeper bug / issue?
Looks like you might have some labeliing problems, but first update to the latest version of selinux-policy
yum -y upgrade selinux-policy
And see if most of these have been fixed.
Daniel,
After updating another machine (F7 -> F8), I still get gdm failures due to selinux, as originally reported. The problem has not be fixed by recent rpms. See below:
[root@titus log]# rpm -qa | grep selinux libselinux-python-2.0.43-1.fc8 selinux-policy-devel-3.0.8-64.fc8 libselinux-devel-2.0.43-1.fc8 selinux-policy-3.0.8-64.fc8 selinux-policy-targeted-3.0.8-64.fc8 libselinux-2.0.43-1.fc8
[root@titus log]# ps ax | grep gdm 2264 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon 2355 ? Ss 0:00 /bin/sh /etc/gdm/XKeepsCrashing 2372 ? S 0:00 /usr/libexec/gdmopen -l /bin/sh -c /etc/gdm/XKeepsCrashing -noopen 2373 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen 2779 pts/0 S+ 0:00 grep gdm
[root@titus log]# audit2allow -i messages ...snip... #============= xdm_t ============== allow xdm_t default_t:file write; allow xdm_t initrc_tmp_t:dir { getattr search setattr }; #============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write remove_name getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file { create unlink };
Disabling selinux lets gdm / xorg run correctly.
I tried removing all selinux rpms, rm -rf /etc/selinux, re-installing selinux, and touching /.autorelabel. No better.
- Mike
Please attach your audit.log?
ps -eZ | grep initrc_t
selinux@lists.fedoraproject.org