From drn_temp2 at rogers.com Fri Jul 1 11:26:21 2005 From: drn_temp2 at rogers.com (David Niemi) Date: Fri, 01 Jul 2005 07:26:21 -0400 Subject: Firestarter startup and FC4 SE Linux Errors - LONG Message-ID: <1120217181.15020.21.camel@Jenny> (Sorry for the length, I included all error messages) With the version of Firestarter from FC4 Extras myself and other users are experiencing starter up error messages with SE Linux though firestarter appears to start. There messages during bootup that permission is denied to: touch - touch /var/lock/firestarter remove - rm /var/lock/firestarter and that there is a "fatal error, your kernel does not support iptables". At the end of this message is the errors from messages and I couldn't locate any corresponding entries in audit. There could be audit entries but I couldn't tell from my VERY LIMITED SE Linux and audit knowledge. The latest policies update does not appear to have made a difference. The quick fix of coarse is to set enforcing=0 or using SELINUX=disabled in /etc/selinux/config, but this sort of defeats the purpose. As a test I set enforcing=0 during a reboot and didn't get the boot errors though there was still many messages (appended) about permission denied in /var/log/messages. Messages during regular boot Jul 1 06:17:50 localhost kernel: audit(1120213067.173:2): avc: denied { execute } for pid=1832 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.173:3): avc: denied { getattr } for pid=1832 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.173:4): avc: denied { getattr } for pid=1832 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.174:5): avc: denied { execute } for pid=1833 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.174:6): avc: denied { getattr } for pid=1833 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.174:7): avc: denied { getattr } for pid=1833 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.174:8): avc: denied { execute } for pid=1834 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.174:9): avc: denied { getattr } for pid=1834 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.174:10): avc: denied { getattr } for pid=1834 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.175:11): avc: denied { execute } for pid=1835 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.175:12): avc: denied { getattr } for pid=1835 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.175:13): avc: denied { getattr } for pid=1835 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.176:14): avc: denied { execute } for pid=1836 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.176:15): avc: denied { getattr } for pid=1836 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.176:16): avc: denied { getattr } for pid=1836 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.176:17): avc: denied { execute } for pid=1837 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.176:18): avc: denied { getattr } for pid=1837 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.176:19): avc: denied { getattr } for pid=1837 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.177:20): avc: denied { execute } for pid=1838 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.177:21): avc: denied { getattr } for pid=1838 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.177:22): avc: denied { getattr } for pid=1838 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.177:23): avc: denied { execute } for pid=1839 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.177:24): avc: denied { getattr } for pid=1839 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.177:25): avc: denied { getattr } for pid=1839 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.178:26): avc: denied { execute } for pid=1840 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.178:27): avc: denied { getattr } for pid=1840 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.178:28): avc: denied { getattr } for pid=1840 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.179:29): avc: denied { execute } for pid=1841 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.179:30): avc: denied { getattr } for pid=1841 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.179:31): avc: denied { getattr } for pid=1841 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.179:32): avc: denied { execute } for pid=1842 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.179:33): avc: denied { getattr } for pid=1842 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.179:34): avc: denied { getattr } for pid=1842 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.180:35): avc: denied { execute } for pid=1843 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.180:36): avc: denied { getattr } for pid=1843 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.180:37): avc: denied { getattr } for pid=1843 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.180:38): avc: denied { execute } for pid=1844 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.180:39): avc: denied { getattr } for pid=1844 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.180:40): avc: denied { getattr } for pid=1844 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.181:41): avc: denied { execute } for pid=1845 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.181:42): avc: denied { getattr } for pid=1845 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.181:43): avc: denied { getattr } for pid=1845 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.181:44): avc: denied { execute } for pid=1846 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.182:45): avc: denied { getattr } for pid=1846 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.182:46): avc: denied { getattr } for pid=1846 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.192:47): avc: denied { create } for pid=1847 comm="iptables" scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 06:17:50 localhost kernel: audit(1120213067.192:48): avc: denied { read } for pid=1847 comm="iptables" name=modprobe dev=proc ino=-268435402 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_modprobe_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.193:49): avc: denied { create } for pid=1848 comm="iptables" scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 06:17:50 localhost kernel: audit(1120213067.193:50): avc: denied { read } for pid=1848 comm="iptables" name=modprobe dev=proc ino=-268435402 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_modprobe_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.194:51): avc: denied { create } for pid=1849 comm="iptables" scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 06:17:50 localhost kernel: audit(1120213067.194:52): avc: denied { read } for pid=1849 comm="iptables" name=modprobe dev=proc ino=-268435402 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_modprobe_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.195:53): avc: denied { create } for pid=1850 comm="iptables" scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 06:17:50 localhost kernel: audit(1120213067.195:54): avc: denied { read } for pid=1850 comm="iptables" name=modprobe dev=proc ino=-268435402 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_modprobe_t tclass=file Jul 1 06:17:50 localhost kernel: audit(1120213067.202:55): avc: denied { create } for pid=1852 comm="iptables" scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 06:17:50 localhost kernel: audit(1120213067.202:56): avc: denied { read } for pid=1852 comm="iptables" name=modprobe dev=proc ino=-268435402 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_modprobe_t tclass=file ******************************************************************* Messages with enforcing=0 Jul 1 07:05:38 localhost kernel: audit(1120215935.141:2): avc: denied { read } for pid=1792 comm="cp" name=config dev=hda3 ino=681198 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.141:3): avc: denied { getattr } for pid=1792 comm="cp" name=config dev=hda3 ino=681198 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.223:4): avc: denied { getattr } for pid=1800 comm="sh" name=subsys dev=hda3 ino=940095 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:var_lock_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215935.224:5): avc: denied { write } for pid=1829 comm="touch" name=subsys dev=hda3 ino=940095 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:var_lock_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215935.224:6): avc: denied { add_name } for pid=1829 comm="touch" name=firestarter scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:var_lock_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215935.224:7): avc: denied { create } for pid=1829 comm="touch" name=firestarter scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:var_lock_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.224:8): avc: denied { write } for pid=1829 comm="touch" name=firestarter dev=hda3 ino=940966 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:var_lock_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.233:9): avc: denied { execute } for pid=1832 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.233:10): avc: denied { execute_no_trans } for pid=1832 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.233:11): avc: denied { read } for pid=1832 comm="sh" name=modprobe dev=hda3 ino=129716 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:insmod_exec_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.234:12): avc: denied { read } for pid=1832 comm="modprobe" name=modprobe.conf.dist dev=hda3 ino=680929 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_conf_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.234:13): avc: denied { getattr } for pid=1832 comm="modprobe" name=modprobe.conf.dist dev=hda3 ino=680929 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_conf_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.235:14): avc: denied { search } for pid=1832 comm="modprobe" name=modules dev=hda3 ino=453828 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_object_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215935.235:15): avc: denied { read } for pid=1832 comm="modprobe" name=modules.dep dev=hda3 ino=454981 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_object_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.235:16): avc: denied { getattr } for pid=1832 comm="modprobe" name=modules.dep dev=hda3 ino=454981 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_object_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.258:17): avc: denied { write } for pid=1832 comm="modprobe" name=ip_tables.ko dev=hda3 ino=486540 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_object_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.258:18): avc: denied { lock } for pid=1832 comm="modprobe" name=ip_tables.ko dev=hda3 ino=486540 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_object_t tclass=file Jul 1 07:05:38 localhost kernel: ip_tables: (C) 2000-2002 Netfilter core team Jul 1 07:05:38 localhost kernel: audit(1120215935.284:19): avc: denied { read } for pid=1836 comm="modprobe" name=modprobe.conf.dist dev=hda3 ino=680929 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_conf_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.284:20): avc: denied { getattr } for pid=1836 comm="modprobe" name=modprobe.conf.dist dev=hda3 ino=680929 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:modules_conf_t tclass=file Jul 1 07:05:38 localhost kernel: ip_conntrack version 2.1 (7935 buckets, 63480 max) - 272 bytes per conntrack Jul 1 07:05:38 localhost kernel: audit(1120215935.635:21): avc: denied { create } for pid=1889 comm="iptables" scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 07:05:38 localhost kernel: audit(1120215935.635:22): avc: denied { getopt } for pid=1889 comm="iptables" lport=255 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 07:05:38 localhost kernel: audit(1120215935.645:23): avc: denied { setopt } for pid=1894 comm="iptables" lport=255 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=rawip_socket Jul 1 07:05:38 localhost kernel: audit(1120215935.747:24): avc: denied { search } for pid=1800 comm="sh" name=net dev=proc ino=-268435350 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_net_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215935.747:25): avc: denied { getattr } for pid=1800 comm="sh" name=ip_forward dev=proc ino=-268435327 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_net_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.747:26): avc: denied { write } for pid=1800 comm="sh" name=ip_forward dev=proc ino=-268435327 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_net_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215935.749:27): avc: denied { read } for pid=1800 comm="sh" name=conf dev=proc ino=-268435027 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_net_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215935.749:28): avc: denied { getattr } for pid=1800 comm="sh" name=conf dev=proc ino=-268435027 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sysctl_net_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.012:29): avc: denied { write } for pid=2094 comm="mv" name=dhcpd.conf dev=hda3 ino=684556 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:etc_runtime_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.012:30): avc: denied { unlink } for pid=2094 comm="mv" name=dhcpd.conf dev=hda3 ino=684556 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:etc_runtime_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.045:31): avc: denied { getattr } for pid=2095 comm="dhcpd" name=dhcpd dev=hda3 ino=2473744 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_exec_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.057:32): avc: denied { getattr } for pid=2095 comm="dhcpd" name=dhcpd.leases dev=hda3 ino=940974 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_state_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.058:33): avc: denied { execute } for pid=2098 comm="dhcpd" name=dhcpd dev=hda3 ino=2473744 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_exec_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.058:34): avc: denied { execute_no_trans } for pid=2098 comm="dhcpd" name=dhcpd dev=hda3 ino=2473744 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_exec_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.058:35): avc: denied { read } for pid=2098 comm="dhcpd" name=dhcpd dev=hda3 ino=2473744 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_exec_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.098:36): avc: denied { read } for pid=2099 comm="dhcpd" name=pidof dev=hda3 ino=129747 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:sbin_t tclass=lnk_file Jul 1 07:05:38 localhost kernel: audit(1120215936.099:37): avc: denied { search } for pid=2100 comm="pidof" name=1 dev=proc ino=65538 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:init_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.099:38): avc: denied { read } for pid=2100 comm="pidof" name=stat dev=proc ino=65550 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:init_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.099:39): avc: denied { getattr } for pid=2100 comm="pidof" name=stat dev=proc ino=65550 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:init_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.099:40): avc: denied { read } for pid=2100 comm="pidof" name=exe dev=proc ino=65545 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:init_t tclass=lnk_file Jul 1 07:05:38 localhost kernel: audit(1120215936.099:41): avc: denied { search } for pid=2100 comm="pidof" name=2 dev=proc ino=131074 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.099:42): avc: denied { read } for pid=2100 comm="pidof" name=stat dev=proc ino=131086 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.100:43): avc: denied { getattr } for pid=2100 comm="pidof" name=stat dev=proc ino=131086 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.100:44): avc: denied { read } for pid=2100 comm="pidof" name=exe dev=proc ino=131081 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t tclass=lnk_file Jul 1 07:05:38 localhost kernel: audit(1120215936.100:45): avc: denied { search } for pid=2100 comm="pidof" name=901 dev=proc ino=59047938 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:udev_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.100:46): avc: denied { read } for pid=2100 comm="pidof" name=stat dev=proc ino=59047950 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:udev_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.100:47): avc: denied { getattr } for pid=2100 comm="pidof" name=stat dev=proc ino=59047950 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:udev_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.100:48): avc: denied { read } for pid=2100 comm="pidof" name=exe dev=proc ino=59047945 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:udev_t tclass=lnk_file Jul 1 07:05:38 localhost kernel: audit(1120215936.101:49): avc: denied { search } for pid=2100 comm="pidof" name=1013 dev=proc ino=66387970 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:initrc_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.101:50): avc: denied { read } for pid=2100 comm="pidof" name=stat dev=proc ino=66387982 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:initrc_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.101:51): avc: denied { getattr } for pid=2100 comm="pidof" name=stat dev=proc ino=66387982 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:initrc_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.101:52): avc: denied { read } for pid=2100 comm="pidof" name=exe dev=proc ino=66387977 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:initrc_t tclass=lnk_file Jul 1 07:05:38 localhost kernel: audit(1120215936.102:53): avc: denied { search } for pid=2100 comm="pidof" name=1833 dev=proc ino=120127490 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:hotplug_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.102:54): avc: denied { read } for pid=2100 comm="pidof" name=stat dev=proc ino=120127502 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:hotplug_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.102:55): avc: denied { getattr } for pid=2100 comm="pidof" name=stat dev=proc ino=120127502 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:hotplug_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.102:56): avc: denied { read } for pid=2100 comm="pidof" name=cwd dev=proc ino=120127495 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:hotplug_t tclass=lnk_file Jul 1 07:05:38 localhost kernel: audit(1120215936.114:57): avc: denied { search } for pid=2102 comm="rhgb-client" name=rhgb dev=hda3 ino=682523 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:mnt_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.114:58): avc: denied { search } for pid=2102 comm="rhgb-client" name=/ dev=ramfs ino=4327 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:ramfs_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.114:59): avc: denied { write } for pid=2102 comm="rhgb-client" name=rhgb-socket dev=ramfs ino=4335 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:ramfs_t tclass=sock_file Jul 1 07:05:38 localhost kernel: audit(1120215936.114:60): avc: denied { connectto } for pid=2102 comm="rhgb-client" name=rhgb-socket scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:initrc_t tclass=unix_stream_socket Jul 1 07:05:38 localhost kernel: audit(1120215936.177:61): avc: denied { search } for pid=2103 comm="dhcpd" name=gdm dev=hda3 ino=940237 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:xserver_log_t tclass=dir Jul 1 07:05:38 localhost kernel: audit(1120215936.205:62): avc: denied { read } for pid=2107 comm="dhcpd" name=dhcpd.leases dev=hda3 ino=940974 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_state_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.212:63): avc: denied { append } for pid=2107 comm="dhcpd" name=dhcpd.leases dev=hda3 ino=940974 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_state_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.224:64): avc: denied { unlink } for pid=2107 comm="dhcpd" name=dhcpd.leases~ dev=hda3 ino=940970 scontext=system_u:system_r:dhcpc_t tcontext=root:object_r:dhcpd_state_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.224:65): avc: denied { link } for pid=2107 comm="dhcpd" name=dhcpd.leases dev=hda3 ino=940974 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_state_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.224:66): avc: denied { unlink } for pid=2107 comm="dhcpd" name=dhcpd.leases dev=hda3 ino=940974 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:dhcpd_state_t tclass=file Jul 1 07:05:38 localhost kernel: audit(1120215936.229:67): avc: denied { name_bind } for pid=2107 comm="dhcpd" s From michael.es.carney at sbcglobal.net Fri Jul 1 14:45:26 2005 From: michael.es.carney at sbcglobal.net (Michael W. Carney) Date: Fri, 01 Jul 2005 07:45:26 -0700 Subject: FC3: selinux-policy-targeted-1.17.30-3.15 seems to have broken gpg... Message-ID: 49# uname -a Linux lucy-01 2.6.11-1.35_FC3smp #1 SMP Mon Jun 13 01:17:35 EDT 2005 i686 i686 i386 GNU/Linux 50# 45# gpg --list-keys gpg: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied 46# Jul 1 07:40:13 lucy-01 kernel: audit(1120228813.336:0): avc: denied { execmod } for pid=5567 comm=gpg path=/usr/bin/gpg dev=sdb5 ino=67343 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:bin_t tclass=file Any suggestions? From tibbs at math.uh.edu Fri Jul 1 16:00:28 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 01 Jul 2005 11:00:28 -0500 Subject: FC3: selinux-policy-targeted-1.17.30-3.15 seems to have broken gpg... In-Reply-To: (Michael W. Carney's message of "Fri, 01 Jul 2005 07:45:26 -0700") References: Message-ID: >>>>> "MWC" == Michael W Carney writes: MWC> Jul 1 07:40:13 lucy-01 kernel: audit(1120228813.336:0): avc: MWC> denied { execmod } for pid=5567 comm=gpg path=/usr/bin/gpg MWC> dev=sdb5 ino=67343 scontext=user_u:system_r:unconfined_t MWC> tcontext=system_u:object_r:bin_t tclass=file I'm seeing the same thing. If I do chcon system_u:object_r:shlib_t /usr/bin/gpg then things work again, but that's probably the wrong thing to do. Here's an strace of a failing call: > strace gpg execve("/usr/bin/gpg", ["gpg"], [/* 44 vars */]) = 0 uname({sys="Linux", node="ld83.math.uh.edu", ...}) = 0 brk(0) = 0x9798000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=88038, ...}) = 0 old_mmap(NULL, 88038, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f53000 close(3) = 0 open("/usr/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\245"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=63528, ...}) = 0 old_mmap(NULL, 65028, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb8a000 old_mmap(0xb99000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0xb99000 close(3) = 0 open("/usr/lib/libbz2.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3000\205"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=71724, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f52000 old_mmap(NULL, 69220, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x1c7000 old_mmap(0x1d7000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10000) = 0x1d7000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260+@\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=16816, ...}) = 0 old_mmap(NULL, 12388, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xef8000 old_mmap(0xefa000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xefa000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20_,\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1521500, ...}) = 0 old_mmap(NULL, 1219740, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x1d8000 mprotect(0x2fb000, 27804, PROT_NONE) = 0 old_mmap(0x2fc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123000) = 0x2fc000 old_mmap(0x300000, 7324, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x300000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f51000 mprotect(0x2fc000, 8192, PROT_READ) = 0 mprotect(0xefa000, 4096, PROT_READ) = 0 mprotect(0x4d7000, 663552, PROT_READ|PROT_WRITE) = 0 mprotect(0x4d7000, 663552, PROT_READ|PROT_EXEC) = -1 EACCES (Permission denied) writev(2, [{"gpg", 3}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"", 0}, {"", 0}, {"cannot restore segment prot afte"..., 39}, {": ", 2}, {"Permission denied", 17}, {"\n", 1}], 10gpg: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied ) = 102 exit_group(127) From jreiser at BitWagon.com Fri Jul 1 17:16:13 2005 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 01 Jul 2005 10:16:13 -0700 Subject: FC3: selinux-policy-targeted-1.17.30-3.15 seems to have broken gpg... In-Reply-To: References: Message-ID: <42C57A5D.1080409@BitWagon.com> Jason L Tibbitts III wrote: >>>>>>"MWC" == Michael W Carney writes: > > > MWC> Jul 1 07:40:13 lucy-01 kernel: audit(1120228813.336:0): avc: > MWC> denied { execmod } for pid=5567 comm=gpg path=/usr/bin/gpg > MWC> dev=sdb5 ino=67343 scontext=user_u:system_r:unconfined_t > MWC> tcontext=system_u:object_r:bin_t tclass=file > > I'm seeing the same thing. If I do > > chcon system_u:object_r:shlib_t /usr/bin/gpg > > then things work again, but that's probably the wrong thing to do. That is an acceptable workaround. /usr/bin/gpg from FC3 has two relocations to .text, which targeted policy does not allow. -----selected lines from: readelf --all /usr/bin/gpg LOAD 0x000000 0x00000000 0x00000000 0xa1920 0xa1920 R E 0x1000 LOAD 0x0a2000 0x000a2000 0x000a2000 0x031e4 0x04768 RW 0x1000 0x00000016 (TEXTREL) 0x0 ## the clue Relocation section '.rel.dyn' at offset 0x2194 contains 794 entries: Offset Info Type Sym.Value Sym. Name 0007922e 00000008 R_386_RELATIVE ## 0x7933e < 0xa1920 000792be 00000008 R_386_RELATIVE 000a20fc 00000008 R_386_RELATIVE ----- Those .text relocations are not present in FC4. It is possible to find all such cases of brokenness by using readelf --dynamic main_or_.so | grep TEXTREL for all executable modules (main programs, shared libraries, dynamic modules). The maintainers of selinux-policy-targeted should have done so, and warned in the changelog. -- From michael.es.carney at sbcglobal.net Fri Jul 1 18:48:51 2005 From: michael.es.carney at sbcglobal.net (Michael W. Carney) Date: Fri, 01 Jul 2005 11:48:51 -0700 Subject: FC3: selinux-policy-targeted-1.17.30-3.15 seems to have broken gpg... References: <42C57A5D.1080409@BitWagon.com> Message-ID: John Reiser wrote: > Jason L Tibbitts III wrote: >>>>>>>"MWC" == Michael W Carney writes: >> >> >> MWC> Jul 1 07:40:13 lucy-01 kernel: audit(1120228813.336:0): avc: >> MWC> denied { execmod } for pid=5567 comm=gpg path=/usr/bin/gpg >> MWC> dev=sdb5 ino=67343 scontext=user_u:system_r:unconfined_t >> MWC> tcontext=system_u:object_r:bin_t tclass=file >> >> I'm seeing the same thing. If I do >> >> chcon system_u:object_r:shlib_t /usr/bin/gpg >> >> then things work again, but that's probably the wrong thing to do. > > That is an acceptable workaround. /usr/bin/gpg from FC3 has two > relocations to .text, which targeted policy does not allow. > > -----selected lines from: readelf --all /usr/bin/gpg > LOAD 0x000000 0x00000000 0x00000000 0xa1920 0xa1920 R E 0x1000 > LOAD 0x0a2000 0x000a2000 0x000a2000 0x031e4 0x04768 RW 0x1000 > > 0x00000016 (TEXTREL) 0x0 ## the clue > > Relocation section '.rel.dyn' at offset 0x2194 contains 794 entries: > Offset Info Type Sym.Value Sym. Name > 0007922e 00000008 R_386_RELATIVE ## 0x7933e < 0xa1920 > 000792be 00000008 R_386_RELATIVE > 000a20fc 00000008 R_386_RELATIVE > ----- > > Those .text relocations are not present in FC4. > It is possible to find all such cases of brokenness by using > readelf --dynamic main_or_.so | grep TEXTREL > for all executable modules (main programs, shared libraries, dynamic > modules). The maintainers of selinux-policy-targeted should have done so, > and warned in the changelog. > > -- Hi John, Thanks for the explanation and workaround. From drn_temp2 at rogers.com Fri Jul 1 19:43:24 2005 From: drn_temp2 at rogers.com (David Niemi) Date: Fri, 01 Jul 2005 15:43:24 -0400 Subject: Firestarter startup and FC4 SE Linux Errors - LONG In-Reply-To: <1120217181.15020.21.camel@Jenny> References: <1120217181.15020.21.camel@Jenny> Message-ID: <1120247004.16551.11.camel@Jenny> On Fri, 2005-01-07 at 07:26 -0400, David Niemi wrote: > (Sorry for the length, I included all error messages) > > With the version of Firestarter from FC4 Extras myself and other users > are experiencing starter up error messages with SE Linux though > firestarter appears to start. > > There messages during bootup that permission is denied to: > > touch - touch /var/lock/firestarter > remove - rm /var/lock/firestarter > > and that there is a "fatal error, your kernel does not support > iptables". At the end of this message is the errors from messages and I > couldn't locate any corresponding entries in audit. There could be > audit entries but I couldn't tell from my VERY LIMITED SE Linux and > audit knowledge. > > The latest policies update does not appear to have made a difference. > > The quick fix of coarse is to set enforcing=0 or using SELINUX=disabled > in /etc/selinux/config, but this sort of defeats the purpose. As a test > I set enforcing=0 during a reboot and didn't get the boot errors though > there was still many messages (appended) about permission denied > in /var/log/messages. > Looks like this is not an SE Linux error. Sorry guys. On Fri, 2005-01-07 at 14:33 -0400, Mark Bidewell wrote: > I tracked the problem with firestarter down to /etc/dhclient-exit-hooks > which contains the line "sh /etc/firestarter/firestarter.sh start" which > starts firestarter independed of the firestater init script. Removing > this line solves the selinux errors and the firewall policy still seems > to be in effect. I am theroizing that the line above is executed when > the dhclient daemon attempts to shutdown as well as start thus > attempting to start the firewall while closing the interface. I think > this is what selinux is flagging. I haven't checked to see if there is > a reason for that command yet. From tibbs at math.uh.edu Sun Jul 3 17:27:14 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 03 Jul 2005 12:27:14 -0500 Subject: selinux fedora 3 selinux-policy-targeted-1.17.30-3.15 update breaks some programs In-Reply-To: <1120152774.4326.160.camel@tiger.byworks.com> (alberto passariello's message of "Thu, 30 Jun 2005 19:32:54 +0200") References: <1120152774.4326.160.camel@tiger.byworks.com> Message-ID: >>>>> "ap" == alberto passariello writes: ap> Jun 30 17:14:58 tiger kernel: audit(1120144498.202:0): avc: denied ap> { execmod } for pid=6950 comm=python ap> path=/usr/lib/wingide2.0/bin/2.3/external/pyscintilla2/_scintilla.so ap> dev=sda2 ino=8555070 scontext=user_u:system_r:unconfined_t ap> tcontext=system_u:object_r:bin_t tclass=file The program shouldn't be putting libraries under a bin directory. Try: chcon system_u:object_r:shlib_t /usr/lib/wingide2.0/bin/2.3/external/pyscintilla2/*.so as a workaround, and then work to get the package fixed so that it puts libraries separate from binaries. - J< From mjs at ces.clemson.edu Sun Jul 3 20:27:43 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Sun, 3 Jul 2005 16:27:43 -0400 (EDT) Subject: SELinux and Thinkpad ACPI (part 1: screen blank) Message-ID: The ACPI scripts that I use to turn off the screen and suspend to RAM no longer function in FC4 (worked fine in FC3). The screen blank script is invoked on Fn-F3 and contains: #!/bin/sh if [ -f /var/tmp/acpi-lightoff ]; then /usr/sbin/radeontool light on /bin/rm /var/tmp/acpi-lightoff else /usr/sbin/radeontool light off /bin/touch /var/tmp/acpi-lightoff When the script is invoked, the following messages are generated in /var/log/acpid: [Sun Jul 3 16:15:50 2005] received event "ibm/hotkey HKEY 00000080 00001003" [Sun Jul 3 16:15:50 2005] notifying client 2531[0:0] [Sun Jul 3 16:15:50 2005] notifying client 3068[500:500] [Sun Jul 3 16:15:50 2005] executing action "/etc/acpi/actions/Fn-F3.sh" [Sun Jul 3 16:15:50 2005] BEGIN HANDLER MESSAGES Radeon hardware not found in lspci output. /bin/touch: cannot touch `/var/tmp/acpi-lightoff': Permission denied [Sun Jul 3 16:15:50 2005] END HANDLER MESSAGES [Sun Jul 3 16:15:50 2005] action exited with status 1 [Sun Jul 3 16:15:50 2005] completed event "ibm/hotkey HKEY 00000080 00001003" And the following are generated in /var/log/audit/audit.log: type=PATH msg=audit(1120421750.387:2653913): item=0 name="/var/tmp/acpi-lightoff" flags=1 inode=906756 dev=fd:00 mode=041777 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120421750.387:2653913): cwd="/" type=SYSCALL msg=audit(1120421750.387:2653913): arch=40000003 syscall=195 success=no exit=-13 a0=9a02228 a1=bfef4278 a2=4bfff4 a3=9a022b8 items=1 pid=27793 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="Fn-F3.sh" exe="/bin/bash" type=AVC msg=audit(1120421750.387:2653913): avc: denied { search } for pid=27793 comm="Fn-F3.sh" name="tmp" dev=dm-0 ino=906756 scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:tmp_t tclass=dir type=PATH msg=audit(1120421750.466:2654723): item=0 name="/usr/share/hwdata/pci.ids" flags=101 inode=809685 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120421750.466:2654723): cwd="/" type=SYSCALL msg=audit(1120421750.466:2654723): arch=40000003 syscall=5 success=no exit=-13 a0=8054e5c a1=0 a2=fbad8001 a3=0 items=1 pid=27795 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="lspci" exe="/sbin/lspci" type=AVC msg=audit(1120421750.466:2654723): avc: denied { read } for pid=27795 comm="lspci" name="pci.ids" dev=dm-0 ino=809685 scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:usr_t tclass=file type=PATH msg=audit(1120421750.481:2654836): item=0 name="/var/tmp/acpi-lightoff" flags=310 inode=906756 dev=fd:00 mode=041777 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120421750.481:2654836): cwd="/" type=SYSCALL msg=audit(1120421750.481:2654836): arch=40000003 syscall=5 success=no exit=-13 a0=bfefdeef a1=8941 a2=1b6 a3=8941 items=1 pid=27796 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="touch" exe="/bin/touch" type=AVC msg=audit(1120421750.481:2654836): avc: denied { search } for pid=27796 comm="touch" name="tmp" dev=dm-0 ino=906756 scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:tmp_t tclass=dir type=PATH msg=audit(1120421750.481:2654837): item=0 name="/var/tmp/acpi-lightoff" flags=1 inode=906756 dev=fd:00 mode=041777 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120421750.481:2654837): cwd="/" type=SYSCALL msg=audit(1120421750.481:2654837): arch=40000003 syscall=30 success=no exit=-13 a0=bfefdeef a1=0 a2=804f8bc a3=bfefdeef items=1 pid=27796 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="touch" exe="/bin/touch" type=AVC msg=audit(1120421750.481:2654837): avc: denied { search } for pid=27796 comm="touch" name="tmp" dev=dm-0 ino=906756 scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:tmp_t tclass=dir I'll post the suspend script results separately. Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mjs at ces.clemson.edu Sun Jul 3 20:47:32 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Sun, 3 Jul 2005 16:47:32 -0400 (EDT) Subject: SELinux and Thinkpad ACPI (part 2: suspend to RAM) Message-ID: The ACPI script that I use to suspend to RAM stopped functioning when I upgraded to FC4 (worked fine in FC3). This time (selinux-policy-targeted-1.23.18-17--forgot to mention that in my previous message on screen blanking), the script does actually supend and resume, but it appears not to update the hardware clock. The suspend script is invoked on Fn-F4 and contains: #!/bin/sh # test script for measuring power drain during suspend-to-ram with ACPI # from http://www.thinkwiki.org # Changelog: # added sync before S3 # changed sign of difference (positive drain) # remove USB for external mouse before sleeping if lsmod | grep '^usbhid' >/dev/null ; then /sbin/modprobe -r -s usbhid fi if lsmod | grep '^uhci_hcd' >/dev/null ; then /sbin/modprobe -r -s uhci_hcd fi if lsmod | grep '^ehci_hcd' >/dev/null ; then /sbin/modprobe -r -s ehci_hcd fi hwclock --systohc LOG=/var/log/battery.log date >> $LOG DATE_BEFORE=`date +%s` BAT_BEFORE=`grep 'remaining capacity' /proc/acpi/battery/BAT0/state | awk '{print $3}'` echo "before: $BAT_BEFORE mWh" >> $LOG sync echo 3 > /proc/acpi/sleep DATE_AFTER=`date +%s` BAT_AFTER=`grep 'remaining capacity' /proc/acpi/battery/BAT0/state | awk '{print $3}'` echo "after: $BAT_AFTER mWh" >> $LOG DIFF=`echo "$BAT_AFTER - $BAT_BEFORE" | bc` SECONDS=`echo "$DATE_AFTER - $DATE_BEFORE" | bc` echo "diff: $DIFF mWh" >> $LOG echo "seconds: $SECONDS sec" >> $LOG USAGE=`echo "(-1 * $DIFF * 60 * 60) / ($SECONDS)" | bc` echo "result: $USAGE mW" >> $LOG if [ $USAGE -lt 1000 ] then echo "Congratulations, your model seems NOT to be affected." >> $LOG else echo "Your model seems to be affected." >> $LOG fi if [ $SECONDS -lt 1200 ] then echo "!!! The notebook was suspended less than 20 minutes." >> $LOG echo "!!! To get representative values please let the notebook sleep" >> $LOG echo "!!! for at least 20 minutes." >> $LOG fi echo "" >> $LOG if !(lsmod | grep '^ehci_hcd') >/dev/null ; then /sbin/modprobe -s ehci_hcd fi if !(lsmod | grep '^uhci_hcd') >/dev/null ; then /sbin/modprobe -s uhci_hcd fi if !(lsmod | grep '^usbhid') >/dev/null ; then /sbin/modprobe -s usbhid fi hwclock --hctosys When the script is invoked, the following messages are generated in /var/log/acpid: [Sun Jul 3 16:33:39 2005] received event "ibm/hotkey HKEY 00000080 00001004" [Sun Jul 3 16:33:39 2005] notifying client 2531[0:0] [Sun Jul 3 16:33:39 2005] notifying client 3068[500:500] [Sun Jul 3 16:33:39 2005] executing action "/etc/acpi/actions/thinkpad-T4x-suspend" [Sun Jul 3 16:33:39 2005] BEGIN HANDLER MESSAGES [Sun Jul 3 16:34:15 2005] END HANDLER MESSAGES [Sun Jul 3 16:34:15 2005] action exited with status 0 [Sun Jul 3 16:34:15 2005] completed event "ibm/hotkey HKEY 00000080 00001004" [Sun Jul 3 16:34:15 2005] received event "processor CPU 00000081 00000000" [Sun Jul 3 16:34:15 2005] notifying client 2531[0:0] [Sun Jul 3 16:34:15 2005] notifying client 3068[500:500] [Sun Jul 3 16:34:15 2005] completed event "processor CPU 00000081 00000000" And the following are generated in /var/log/audit/audit.log: type=PATH msg=audit(1120422820.446:4072964): item=1 flags=101 inode=357483 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1120422820.446:4072964): item=0 name="/sbin/hwclock" flags=101 inode=194377 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120422820.446:4072964): cwd="/" type=AVC_PATH msg=audit(1120422820.446:4072964): path="/var/log/acpid" type=AVC_PATH msg=audit(1120422820.446:4072964): path="/var/log/acpid" type=AVC_PATH msg=audit(1120422820.446:4072964): path="socket:[7894]" type=AVC_PATH msg=audit(1120422820.446:4072964): path="socket:[10575]" type=SYSCALL msg=audit(1120422820.446:4072964): arch=40000003 syscall=11 success=yes exit=0 a0=9533338 a1=9533dd8 a2=9533738 a3=0 items=2 pid=28046 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hwclock" exe="/sbin/hwclock" type=AVC msg=audit(1120422820.446:4072964): avc: denied { read write } for pid=28046 comm="hwclock" name="[10575]" dev=sockfs ino=10575 scontext=system_u:system_r:hwclock_t tcontext=system_u:system_r:apmd_t tclass=unix_stream_socket type=AVC msg=audit(1120422820.446:4072964): avc: denied { read write } for pid=28046 comm="hwclock" name="[7894]" dev=sockfs ino=7894 scontext=system_u:system_r:hwclock_t tcontext=system_u:system_r:apmd_t tclass=unix_stream_socket type=AVC msg=audit(1120422820.446:4072964): avc: denied { append } for pid=28046 comm="hwclock" name="acpid" dev=dm-0 ino=909761 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:apmd_log_t tclass=file type=AVC msg=audit(1120422820.446:4072964): avc: denied { append } for pid=28046 comm="hwclock" name="acpid" dev=dm-0 ino=909761 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:apmd_log_t tclass=file type=PATH msg=audit(1120422852.678:4306524): item=1 flags=101 inode=357483 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1120422852.678:4306524): item=0 name="/sbin/hwclock" flags=101 inode=194377 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120422852.678:4306524): cwd="/" type=AVC_PATH msg=audit(1120422852.678:4306524): path="/var/log/acpid" type=AVC_PATH msg=audit(1120422852.678:4306524): path="/var/log/acpid" type=AVC_PATH msg=audit(1120422852.678:4306524): path="socket:[7894]" type=AVC_PATH msg=audit(1120422852.678:4306524): path="socket:[10575]" type=SYSCALL msg=audit(1120422852.678:4306524): arch=40000003 syscall=11 success=yes exit=0 a0=9534440 a1=95344d8 a2=9533738 a3=0 items=2 pid=28207 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hwclock" exe="/sbin/hwclock" type=AVC msg=audit(1120422852.678:4306524): avc: denied { read write } for pid=28207 comm="hwclock" name="[10575]" dev=sockfs ino=10575 scontext=system_u:system_r:hwclock_t tcontext=system_u:system_r:apmd_t tclass=unix_stream_socket type=AVC msg=audit(1120422852.678:4306524): avc: denied { read write } for pid=28207 comm="hwclock" name="[7894]" dev=sockfs ino=7894 scontext=system_u:system_r:hwclock_t tcontext=system_u:system_r:apmd_t tclass=unix_stream_socket type=AVC msg=audit(1120422852.678:4306524): avc: denied { append } for pid=28207 comm="hwclock" name="acpid" dev=dm-0 ino=909761 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:apmd_log_t tclass=file type=AVC msg=audit(1120422852.678:4306524): avc: denied { append } for pid=28207 comm="hwclock" name="acpid" dev=dm-0 ino=909761 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:apmd_log_t tclass=file Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From alex at milivojevic.org Mon Jul 4 15:58:40 2005 From: alex at milivojevic.org (alex at milivojevic.org) Date: Mon, 04 Jul 2005 10:58:40 -0500 Subject: selinux and logrotate Message-ID: <20050704105840.uaf6rtrhdwos0ksc@www.milivojevic.org> I've asked once earlier about this, but was never able to fix it. I have tried so far versions 1.17.30-2.52.1 and 1.17.30-3.6 of targeted policy. Basically, each night logrotate fails with following logged to /var/log/messages: kernel: audit(1120381322.870:0): avc: denied { associate } for pid=28612 exe=/usr/sbin/logrotate name=logrotate.OEFymP scontext=system_u:object_r:var_log_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem My /tmp is tmpfs mounted filesystem (as might be guessed by the above output. Logrotate seems to save pre/post-rotate scripts into /tmp/logrotate.xxxxxx files prior to executing them, so I guess the problem is that those get labeled as tmpfs_t. Most of pre/post-rotate scripts are just the standard ones (as installed by distribution RPM packages). On some systems I also have some custom post rotate scripts that write some info into files in /var/log/mystuff directory and execute logwatch filters on it for creating and mailing reports. I'm finding the same audit messages on both the systems with only the standard logrotate configuration and on the system with additional custom postrotate scripts. However, I'm still curious if I need to allow anything additional for my custom postrotate scripts? Thanks for any and all help, Aleksandar Milivojevic ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From ejtr at layer3.co.uk Mon Jul 4 18:35:17 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Mon, 04 Jul 2005 19:35:17 +0100 Subject: selinux and logrotate Message-ID: <1120502117.2939.52.camel@topaz.bugfinder.co.uk> I found a similar set of problems with FC3/FC4 strict policy arising from my local decision to make /tmp a noexec partition. It led me to find various nasty interactions between cups, logrotate, and glibc-secure-mode when running with and without SELinux in enforcing mode. My current solution goes as follows: a) Modify /etc/cron.daily/logrotate to explicitly set TMPDIR to a new logrotate specific location $ cat /etc/cron.daily/logrotate #!/bin/sh # Use EXEC capable temp area for logrotate to run scripts within. if [ -d /var/spool/logrotate/tmp ]; then if [ -w /var/spool/logrotate/tmp ]; then # SELinux currently forbids chmod on the tmp dir itself #chmod 700 /var/spool/logrotate/tmp export TMPDIR=/var/spool/logrotate/tmp else exit 1 fi else exit 1 fi /usr/sbin/logrotate -v /etc/logrotate.conf $ b) Label the Cron Daily script as logrotate_exec_t and the new tmp area as tmp_t. Without this, the script suffers a secure mode transition as it executes /usr/sbin/logrotate, and the TMPDIR env variable setting is lost. The temporary script is already dynamically created as logrotate_tmp_t by the policy, and the policy already has "can_exec(logrotate_t, logrotate_tmp_t)" to allow logrotate to exec its own creations. $ cat /etc/selinux/strict/src/policy/file_contexts/program/logrotate.fc # logrotate /usr/sbin/logrotate -- system_u:object_r:logrotate_exec_t /usr/sbin/logcheck -- system_u:object_r:logrotate_exec_t ifdef(`distro_debian', ` /usr/bin/savelog -- system_u:object_r:logrotate_exec_t /var/lib/logrotate(/.*)? system_u:object_r:logrotate_var_lib_t ', ` /var/lib/logrotate\.status -- system_u:object_r:logrotate_var_lib_t ') # For TMPDIR workround ifdef(`distro_redhat', ` /etc/cron.daily/logrotate -- system_u:object_r:logrotate_exec_t ') /etc/cron\.(daily|weekly)/sysklogd -- system_u:object_r:logrotate_exec_t /var/lib/logcheck(/.*)? system_u:object_r:logrotate_var_lib_t # using a hard-coded name under /var/tmp is a bug - new version fixes it /var/tmp/logcheck -d system_u:object_r:logrotate_tmp_t # For TMPDIR workround /var/spool/logrotate/tmp -d system_u:object_r:tmp_t $ c) Add policy to SELinux to allow logrotate_exec_t to exec itself under Fedora/Redhat so as to allow the cron.daily script to exec /usr/sbin/logrotate $ sudo diff -u logrotate.te.strict.fc4.orig logrotate.te.strict.fc4.patched --- logrotate.te.strict.fc4.orig 2005-05-20 19:53:12.000000000 +0100 +++ logrotate.te.strict.fc4.patched 2005-06-23 13:38:38.000000000 +0100 @@ -33,6 +33,11 @@ can_exec(logrotate_t, logrotate_exec_t) ') +ifdef(`distro_redhat', ` +# for /etc/cron.daily/logrotate TMPDIR workround +can_exec(logrotate_t, logrotate_exec_t) +') + # for perl allow logrotate_t usr_t:file { getattr read ioctl }; allow logrotate_t usr_t:lnk_file read; $ d) Make sure cups logrotate uses service. FC4 default /etc/logrotate.d/cups has /var/log/cups/*_log { missingok notifempty sharedscripts postrotate /etc/init.d/cups condrestart >/dev/null 2>&1 || true endscript } my one has: $ cat /etc/logrotate.d/cups /var/log/cups/*_log { missingok notifempty sharedscripts postrotate /sbin/service cups condrestart >/dev/null 2>&1 || true endscript } $ The problem here is that cups ALSO interprets TMPDIR. If restarted with /sbin/service, the environment is cleansed by /sbin/service itself before launching cups irrespective of SELinux mode, so that the overnight restart has the same environment as the boot sequence. If restarted with /etc/init.d/cups, cups inherits TMPDIR rom /etc/cron.daily/logrotate if SELinux is not enforcing, and all sorts of nonsense arises. Another safety measure here is to explicitly set the tmp directory in cupsd.conf so that it doesn't even try to use TMPDIR. A longer term thought is that logrotate should allow the setting of the tmp directory directly in logrotate.conf and should ignore TMPDIR, Likewise cups should ignore TMPDIR and cupsd.conf should have an explicit tmp dir setting uncommented as distributed in the rpm. Similary, persons should avoid using calls to /etc/init.d/xxxx in logrotate scripts and always use /sbin/service so that the environment is clean even when SELinux is not enforcing. A wider feeling I got from investigating this on my machine is that the SELinux FAQ should contain some more explicit information on what is and isn't saved across a secure-mode transition. As far as I could tell, SELinux doesn't perform a secure-mode transition when running in permissive mode; the consequence is that when a program passes environment variables to a child process, the child will see a different environment depending on whether running permissive or enforcing - this had me very confused until I realised what was going on. Perhaps there could be a global setting (boolean?) to force permissive mode to perform secure-mode transitions so that programs always see the same environment? -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From netdxr at gmail.com Mon Jul 4 22:20:48 2005 From: netdxr at gmail.com (Tom Lisjac) Date: Mon, 4 Jul 2005 16:20:48 -0600 Subject: FC4 cyrus-imapd socket issues... Message-ID: <863ff452050704152072f952da@mail.gmail.com> I'm getting the following avc's on FC4 when starting cyrus-imapd with selinux-policy-targeted-1.23.18-17. As a result, it can't listen on ports 110, 143 and 993. Do I need to toggle cyrus_disable_trans to make this daemon work? Best regards, -Tom --------------------------------- >From /var/log/audit/audit.log. In addition to 993, an avc is also generated for ports 110 and 143: type=AVC msg=audit(1120506529.586:145746): avc: denied { name_bind } for pid=2919 comm="cyrus-master" src=993 scontext=system_u:system_r:cyrus_t tcontext=system_u: type=SOCKETCALL msg=audit(1120506529.662:145983): nargs=3 a0=7 a1=9e18aa8 a2=10 type=SOCKADDR msg=audit(1120506529.662:145983): saddr=0200006E000000000000000000000000 type=SYSCALL msg=audit(1120506529.662:145983): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfc61440 a2=8054164 a3=9e18c40 items=0 pid=2919 auid=4294967295 u ... which causes the following in /var/log/messages Jul 4 15:54:13 test master[6295]: unable to create imap listener socket: Address family not supported by protocol Jul 4 15:54:13 test master[6295]: unable to create imaps listener socket: Address family not supported by protocol Jul 4 15:54:13 test master[6295]: unable to create pop3 listener socket: Address family not supported by protocol Jul 4 15:54:13 test master[6295]: unable to create pop3s listener socket: Address family not supported by protocol From dwalsh at redhat.com Tue Jul 5 02:07:33 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Jul 2005 22:07:33 -0400 Subject: avc denied about hwclock. In-Reply-To: References: <42C2F3D1.7010006@redhat.com> Message-ID: <42C9EB65.4010303@redhat.com> Vinicius wrote: > Vinicius escreveu: > >> Daniel J Walsh escreveu: >> >>> Vinicius wrote: >>> >>>> Hello, >>>> >>>> I'm getting the following on FC4: >>>> "audit(1119989359.942:2): avc: denied { read } for pid=1427 >>>> comm="hwclock" name=localtime dev=dm-0 ino=1502961 scontext=s >>>> ystem_u:system_r:hwclock_t tcontext=root:object_r:etc_t tclass=file >>>> audit(1119989359.942:3): avc: denied { read } for pid=1427 >>>> comm="hwclock" name=localtime dev=dm-0 ino=1502961 scontext=s >>>> ystem_u:system_r:hwclock_t tcontext=root:object_r:etc_t tclass=file" >>>> >>>> How to resolve this problem, please? >>> >>> >>> >>> >>> restorecon /etc/localtime >>> >>> Any idea how this file is getting created? >>> >>> >>>> >>>> >>>> TIA, >>>> >>>> Vinicius. >>>> >> >> through the program *zic*, we can create a file that contains time >> zone information. The output of the zic is renamed to /etc/localtime. >> It's very useful on Brazil because of the daylight time savings. >> >> I have the source information in brazilian portuguese if you wish. >> >> Best regards, >> >> Vinicius. >> > > instead of "daylight time savings", I mean "summer time" (I think). > > Bad translation, sorry :-(. > We call it "Daylight Savings Time" Simple fix to the script would be to add restorecon /etc/localtime in the script to correct the file context. > Vinicius. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 5 02:43:43 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 5 Jul 2005 04:43:43 +0200 (CEST) Subject: more latest selinux policy change problems In-Reply-To: <1119469274.13181.210.camel@moss-spartans.epoch.ncsc.mil> References: <1119469274.13181.210.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Wed, 22 Jun 2005, Stephen Smalley wrote: > Per earlier postings on this list, have you tried: > setsebool -P httpd_builtin_scripting=1 httpd_unified=1 Nope, but the latest selinux-policy-targeted (1.17.30-3.15) fixed all problems. I got alot of other problems, rndc reload didnt work for bind for example. But now everything works. >> Did the fedora team expect problems like this to be created with the latest >> selinux policy change or is it a suprise for you? Its fine to have it by >> default in new release of fedora but not CHANGE it in a update. > > I think it was a bug in the spec file's handling of the booleans file. Ok. From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 5 02:58:01 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 5 Jul 2005 04:58:01 +0200 (CEST) Subject: How do I tell if SELinux is working? In-Reply-To: <1119482955.4541.7.camel@nexus.verbum.private> References: <35025D43-3EC7-481B-9DE1-A0CCF91B49F6@internection.com> <1119479734.3842.4.camel@nexus.verbum.private> <9072D912-84D1-4FB8-BCAB-4A7F4479B199@internection.com> <1119482955.4541.7.camel@nexus.verbum.private> Message-ID: On Wed, 22 Jun 2005, Colin Walters wrote: > On Wed, 2005-06-22 at 18:45 -0400, Jon August wrote: >> httpd is running with type: >> >> root:system_r:unconfined_t >> >> What does this mean? Is httpd a vulnerability on this machine? > > This means that httpd is not confined by the SELinux policy. This means > you have less protection against a compromise or misconfiguration of > httpd or CGI scripts. > > Since the default is for it to be enabled, someone (possibly you) > disabled SELinux protection for httpd; you can reenable it by using > system-config-securitylevel (or > "setsebool -P httpd_disable_trans=false"). Strange, on one computer httpd runs with: root:system_r:httpd_t 11845 ? Ss 0:00 /usr/sbin/httpd but if I do setsebool -P httpd_disable_trans 0 on an other computer I get [root at flashdance ny]# /etc/init.d/httpd restart Stopping httpd: [ OK ] Starting httpd: /usr/sbin/httpd: error while loading shared libraries: libpcre.so.0: cannot open shared object file: Permission denied [FAILED] On both computers the selinux perms are: [iocc at flashdance texts]$ ll -Z /lib/libpcre.so.0* lrwxrwxrwx root system_u:object_r:lib_t /lib/libpcre.so.0 -> libpcre.so.0.0.1 -rwxr-xr-x root system_u:object_r:shlib_t /lib/libpcre.so.0.0.1 Im not sure that I get that :) Just to get it working I did this on the other computer: [root at flashdance ny]# setsebool -P httpd_disable_trans 1 [root at flashdance ny]# /etc/init.d/httpd restart Stopping httpd: [FAILED] Starting httpd: [ OK ] Why doesnt httpd_disable_trans 0 work with apache on one computer? From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 5 04:07:49 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 5 Jul 2005 06:07:49 +0200 (CEST) Subject: NSA motives In-Reply-To: <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Thu, 23 Jun 2005, Stephen Smalley wrote: > But remember that SELinux is: > - upstream (in the mainline Linux 2.6 kernel), When was SELinux included in the mainline Linux 2.6, what version? > - open source (kernel code and userland and policy), > - a truly community-based project (with significant contributions by > external developers and users) ever since its initial release by the NSA > in 2000, I feel that its interesting that NSA, famous for spying on other nations, is helping to make linux more secure. Isnt that counterproductive? :) I remember the NSA keys in the early windows versions. Not possible to use netscape with more than 40 bit encryption, so I had to run fortify on it to unlock it to 128 bit. What if some with evil reasons uses SELinux? Or have NSA realized that the old tactic doesnt work and its better to secure so many systems as possible instead. To help millions to have a more secure system is worth more than to possible prevent a few bad guys to also have secure systems. Probably leading that it will be more complicated or impossible for NSA to break in? Im sure NSA would love to have backdoor to SELinux if someone with evil reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open source it cant be something obviously because it will be found very quickly. Must be something that its really, really well hidden. I guess you have heard opinions like this before :) It was the first things I thought about when I first heard about SELinux several years ago. From rhally at mindspring.com Tue Jul 5 04:30:38 2005 From: rhally at mindspring.com (Richard Hally) Date: Tue, 05 Jul 2005 00:30:38 -0400 Subject: NSA motives In-Reply-To: References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <42CA0CEE.5010307@mindspring.com> Peter Magnusson wrote: > On Thu, 23 Jun 2005, Stephen Smalley wrote: > >> But remember that SELinux is: >> - upstream (in the mainline Linux 2.6 kernel), > > > When was SELinux included in the mainline Linux 2.6, what version? 2.6.0 IIRC > >> - open source (kernel code and userland and policy), >> - a truly community-based project (with significant contributions by >> external developers and users) ever since its initial release by the NSA >> in 2000, > > > I feel that its interesting that NSA, famous for spying on other > nations, is helping to make linux more secure. Isnt that > counterproductive? :) NSA has two main missions. See their site http://www.nsa.gov/home_html.cfm > > Im sure NSA would love to have backdoor to SELinux if someone with evil > reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open > source it cant be something obviously because it will be found very > quickly. Must be something that its really, really well hidden. Think about it... It is probably the most examined code in the whole open source world. "many eyes" carried to the extreme! > > I guess you have heard opinions like this before :) > It was the first things I thought about when I first heard about SELinux > several years ago. > Just because you are paranoid doesn't mean someone is not out to get you. Richard From ivg2 at cornell.edu Tue Jul 5 04:35:05 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 05 Jul 2005 00:35:05 -0400 Subject: NSA motives In-Reply-To: References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1120538105.2644.9.camel@localhost.localdomain> On Tue, 2005-07-05 at 06:07 +0200, Peter Magnusson wrote: > On Thu, 23 Jun 2005, Stephen Smalley wrote: > > > But remember that SELinux is: > > - upstream (in the mainline Linux 2.6 kernel), > > When was SELinux included in the mainline Linux 2.6, what version? It was merged in 2.6.0-test3, according to kerneltrap.org: http://kerneltrap.org/node/724 > Im sure NSA would love to have backdoor to SELinux if someone with evil > reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open > source it cant be something obviously because it will be found very > quickly. Must be something that its really, really well hidden. Have you found a bug in Fedora or RHEL SELinux? If so, please file a bugzilla, and we will try our best to fix it. From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 5 05:11:53 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 5 Jul 2005 07:11:53 +0200 (CEST) Subject: NSA motives In-Reply-To: <42CA0CEE.5010307@mindspring.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <42CA0CEE.5010307@mindspring.com> Message-ID: On Tue, 5 Jul 2005, Richard Hally wrote: >> When was SELinux included in the mainline Linux 2.6, what version? > 2.6.0 IIRC Ok. > NSA has two main missions. See their site > http://www.nsa.gov/home_html.cfm "The ability to understand the secret communications of our foreign adversaries while protecting our own communications -- a capability in which the United States leads the world -- gives our nation a unique advantage." hmm, ok. SELinux still sounds counterproductive :) >> Im sure NSA would love to have backdoor to SELinux if someone with evil >> reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open >> source it cant be something obviously because it will be found very >> quickly. Must be something that its really, really well hidden. > Think about it... It is probably the most examined code in the whole open > source world. "many eyes" carried to the extreme! Good to hear. >> I guess you have heard opinions like this before :) >> It was the first things I thought about when I first heard about SELinux >> several years ago. > Just because you are paranoid doesn't mean someone is not out to get you. I'll have my tinfoil hat on for the rest of the day ;) From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 5 05:13:18 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 5 Jul 2005 07:13:18 +0200 (CEST) Subject: NSA motives In-Reply-To: <1120538105.2644.9.camel@localhost.localdomain> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <1120538105.2644.9.camel@localhost.localdomain> Message-ID: On Tue, 5 Jul 2005, Ivan Gyurdiev wrote: >> When was SELinux included in the mainline Linux 2.6, what version? > > It was merged in 2.6.0-test3, according to kerneltrap.org: > http://kerneltrap.org/node/724 Oki. >> Im sure NSA would love to have backdoor to SELinux if someone with evil >> reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open >> source it cant be something obviously because it will be found very >> quickly. Must be something that its really, really well hidden. > > Have you found a bug in Fedora or RHEL SELinux? If so, please > file a bugzilla, and we will try our best to fix it. No, I havent. From Valdis.Kletnieks at vt.edu Tue Jul 5 06:05:02 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 05 Jul 2005 02:05:02 -0400 Subject: NSA motives In-Reply-To: Your message of "Tue, 05 Jul 2005 06:07:49 +0200." References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200507050605.j65654am001807@turing-police.cc.vt.edu> On Tue, 05 Jul 2005 06:07:49 +0200, Peter Magnusson said: > Im sure NSA would love to have backdoor to SELinux if someone with evil > reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open > source it cant be something obviously because it will be found very > quickly. Must be something that its really, really well hidden. No, SELinux is designed properly to be bulletproof, because the NSA has *two* charges, only one of which is spying on others. The SELinux work is for the charge of securing *our* systems. The back door is elsewhere, where you'll never find it, especially if you're busy looking at the SELinux code looking for backdoors. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From christofer.c.bell at gmail.com Tue Jul 5 09:11:14 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Tue, 5 Jul 2005 04:11:14 -0500 Subject: avc denied about hwclock. In-Reply-To: <42C9EB65.4010303@redhat.com> References: <42C2F3D1.7010006@redhat.com> <42C9EB65.4010303@redhat.com> Message-ID: <143f0f6c050705021126318cdb@mail.gmail.com> On 7/4/05, Daniel J Walsh wrote: > > We call it "Daylight Savings Time" Just to make sure everyone is on the same (and correct) page, the term in the United States is "Daylight Saving Time" not "Daylight Savings Time." Most of the rest of the world does, indeed, refer to it as "Summer Time." I'm sure anyone interested in the history of the practise (at least it in the United States) can find a wealth of information via google. -- Chris "With the way things are starting to go in this country, if forced to choose between being caught with a van full of pirated DVDs or heroin you'd actually have to pause and think about it." -- Michael Bell, drunkenblog.com From angela at kahealani.com Tue Jul 5 11:39:53 2005 From: angela at kahealani.com (Angela Kahealani) Date: Tue, 5 Jul 2005 01:39:53 -1000 Subject: NSA motives In-Reply-To: References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <42CA0CEE.5010307@mindspring.com> Message-ID: <200507050139.53555.angela@kahealani.com> On Mon, 2005-07-04 19:11, Peter Magnusson wrote: > On Tue, 5 Jul 2005, Richard Hally wrote: > > NSA has two main missions. See their site > > http://www.nsa.gov/home_html.cfm > > "The ability to understand the secret communications of our foreign > adversaries while protecting our own communications -- a capability > in which the United States leads the world -- gives our nation a > unique advantage." > > hmm, ok. SELinux still sounds counterproductive :) apparently you fail to understand the implications of "foreign adversaries". This means their primary mission is interception of the traffic (which doesn't exist) between the aliens (which don't exist) and decoding it into a human language (which does exist, but is classified, called NEWSPEAK, composed primarily of cute acronyms. > I'll have my tinfoil hat on for the rest of the day ;) I doubt it... you probably meant aluminum foil. If you've got actual tin foil, where do I get some? -- All information and transactions are non negotiable and are private between the parties. All rights reserved without prejudice, Copyright 2005 Angela Kahealani http://www.kahealani.com/ From alex at milivojevic.org Tue Jul 5 13:58:40 2005 From: alex at milivojevic.org (alex at milivojevic.org) Date: Tue, 05 Jul 2005 08:58:40 -0500 Subject: NSA motives In-Reply-To: References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20050705085840.loqdlzfckkwc0kwc@www.milivojevic.org> Quoting Peter Magnusson : > What if some with evil reasons uses SELinux? Or have NSA realized > that the old tactic doesnt work and its better to secure so many > systems as possible instead. To help millions to have a more secure > system is worth more than to possible prevent a few bad guys to also > have secure systems. Probably leading that it will be more > complicated or impossible for NSA to break in? Actually, the NSA came to correct conclusion that if they give out the tool (be it SELinux or encryption algorithm), most people don't have technical knowledge (and will never bother to obtain it) to use it in a secure way. So basically, their systems (or communications) are not that much more secure (or harder to break) than they were before they were given the tool. They will have false sense of security, so they will store more sensitive information on their systems (or transfer it through communication channels). Bruce Schneier wrote something similar in one of his books (I believe it was "Secrets and Lies: Digital Security in a Networked World"). From what I remember (somebody with a copy of the book can correct me if I remembered wrong), he wrote that his biggest mistake was publishing the book "Applied Crypthography". While the algorithms in the book and the math behind them were perfect, the way people were implementing them made systems actually less secure. To summarize, if somebody has false sense of security (he has perfect tools, but used in a wrong way), it will be actually easier for you to spy on him. This is especially true with complex subsystems such as SELinux (what do you think, how many system administrators out there *really* understand it?). I'm not sure if this is the actual (real) backdoor Vladis was refering to in his reply ;-) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From sds at tycho.nsa.gov Tue Jul 5 14:30:39 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 05 Jul 2005 10:30:39 -0400 Subject: NSA motives In-Reply-To: References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1120573839.2644.65.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-07-05 at 06:07 +0200, Peter Magnusson wrote: > When was SELinux included in the mainline Linux 2.6, what version? 2.6.0-test3. And the LSM framework, which we helped to develop, was merged during the 2.5 development series, starting with 2.5.27 iirc. > I feel that its interesting that NSA, famous for spying on other nations, > is helping to make linux more secure. Isnt that counterproductive? :) See http://www.nsa.gov/selinux/info/faq.cfm#I10 > What if some with evil reasons uses SELinux? Or have NSA realized that the > old tactic doesnt work and its better to secure so many systems as possible > instead. To help millions to have a more secure system is worth more than > to possible prevent a few bad guys to also have secure systems. Probably > leading that it will be more complicated or impossible for NSA to break in? Improving the security of COTS (commercial off the shelf) systems is necessary to meet the security needs of our customers. Yes, there is the potential for abuse, but such tradeoffs are inevitable. > Im sure NSA would love to have backdoor to SELinux if someone with evil > reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open > source it cant be something obviously because it will be found very > quickly. Must be something that its really, really well hidden. That would be a rather foolish strategy, given that SELinux is publically associated with NSA and the code is open. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Jul 5 14:38:59 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 05 Jul 2005 10:38:59 -0400 Subject: NSA motives In-Reply-To: <20050705085840.loqdlzfckkwc0kwc@www.milivojevic.org> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <20050705085840.loqdlzfckkwc0kwc@www.milivojevic.org> Message-ID: <1120574339.2644.72.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-07-05 at 08:58 -0500, alex at milivojevic.org wrote: > To summarize, if somebody has false sense of security (he has perfect > tools, but > used in a wrong way), it will be actually easier for you to spy on him. > This is > especially true with complex subsystems such as SELinux (what do you > think, how > many system administrators out there *really* understand it?). I'm not > sure if > this is the actual (real) backdoor Vladis was refering to in his reply ;-) There is quite a bit of work ongoing to help solve that problem (understanding and configuring SELinux policies effectively). SELinux doesn't create complexity, it just reveals it and allows you to control it. The SELinux mechanism itself isn't very complex; the complexity comes in trying to specify what you want to allow to happen on your computing system, because of the highly complex interactions of existing software on that system (not because of something added by SELinux). Classic case of blaming the messenger - SELinux tells you about all of the complex activity on your system and forces you to think about what you want to allow to happen, so you blame it for creating complexity tht was already there... -- Stephen Smalley National Security Agency From christofer.c.bell at gmail.com Tue Jul 5 14:40:37 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Tue, 5 Jul 2005 09:40:37 -0500 Subject: NSA motives In-Reply-To: References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <143f0f6c0507050740792c1e27@mail.gmail.com> Quick show of hands, please: how many of you are wearing a tin foil hat[1], right now, at this moment? How many of you are members of The Lone Gunmen[2]? [1] http://en.wikipedia.org/wiki/Tinfoil_hat, http://tinfoilhat.shmoo.com/ [2] Do Frohike, Byers, or Langley read this list? This talk of nefarious NSA meddling in Linux to further their aims of keeping tabs on the underworld dealings of the less than scrupulous has me in stitches! Are you all for real? -- Chris "With the way things are starting to go in this country, if forced to choose between being caught with a van full of pirated DVDs or heroin you'd actually have to pause and think about it." -- Michael Bell, drunkenblog.com From alex at milivojevic.org Tue Jul 5 15:42:56 2005 From: alex at milivojevic.org (alex at milivojevic.org) Date: Tue, 05 Jul 2005 10:42:56 -0500 Subject: NSA motives In-Reply-To: <1120574339.2644.72.camel@moss-spartans.epoch.ncsc.mil> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <20050705085840.loqdlzfckkwc0kwc@www.milivojevic.org> <1120574339.2644.72.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20050705104256.1jfaxrylmoksc4o8@www.milivojevic.org> Quoting Stephen Smalley : > There is quite a bit of work ongoing to help solve that problem > (understanding and configuring SELinux policies effectively). SELinux > doesn't create complexity, it just reveals it and allows you to control > it. The SELinux mechanism itself isn't very complex; the complexity > comes in trying to specify what you want to allow to happen on your > computing system, because of the highly complex interactions of existing > software on that system (not because of something added by SELinux). > Classic case of blaming the messenger - SELinux tells you about all of > the complex activity on your system and forces you to think about what > you want to allow to happen, so you blame it for creating complexity tht > was already there... Sorry, it wasn't my intention to blame the messanger. All I wanted to say (and as usually badly expressing myself) was that making system secure is a complex task. Simply having SELinux enabled on the system does not make the system ultimately secure. Making changes to default policies without fully understanding what the changes will introduce just makes it even less secure. Example: On several Linux-end-users type of lists I already saw posters with good intentions giving advice to include this or that rules into the policy to solve various problems, just to have other people screeming in replies that those including such rules into their policy could just as well disable SELinux completely with about the same effects. If somebody Googles around to find solution to the specific problem and finds advice to do "chmod -R a+rw /", (s)he is not likely to actually do it. On the other hand, there is many more people that will include some random set of rules into their SELinux policy, giving application(s) way more access then they really need. Nothing to do with SELinux as such, and it would be wrong to blame it. But rather with human nature (which is the weakest link of any security system). ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From Valdis.Kletnieks at vt.edu Tue Jul 5 16:10:38 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 05 Jul 2005 12:10:38 -0400 Subject: NSA motives In-Reply-To: Your message of "Tue, 05 Jul 2005 09:40:37 CDT." <143f0f6c0507050740792c1e27@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <143f0f6c0507050740792c1e27@mail.gmail.com> Message-ID: <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> On Tue, 05 Jul 2005 09:40:37 CDT, "Christofer C. Bell" said: > This talk of nefarious NSA meddling in Linux to further their aims of > keeping tabs on the underworld dealings of the less than scrupulous > has me in stitches! Are you all for real? As a matter of fact, some of us (myself included) *don't* trust our government to keep our best interests in mind. On the other hand, I'm not worried about the NSA sneaking in backdoors when the *real* problem is things like the Patriot Act and standardized driver's licenses..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at tycho.nsa.gov Tue Jul 5 16:14:42 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 05 Jul 2005 12:14:42 -0400 Subject: NSA motives In-Reply-To: <20050705104256.1jfaxrylmoksc4o8@www.milivojevic.org> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <20050705085840.loqdlzfckkwc0kwc@www.milivojevic.org> <1120574339.2644.72.camel@moss-spartans.epoch.ncsc.mil> <20050705104256.1jfaxrylmoksc4o8@www.milivojevic.org> Message-ID: <1120580082.2644.138.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-07-05 at 10:42 -0500, alex at milivojevic.org wrote: > Sorry, it wasn't my intention to blame the messanger. All I wanted to > say (and > as usually badly expressing myself) was that making system secure is a complex > task. Simply having SELinux enabled on the system does not make the system > ultimately secure. Making changes to default policies without fully > understanding what the changes will introduce just makes it even less secure. > > Example: On several Linux-end-users type of lists I already saw posters with > good intentions giving advice to include this or that rules into the policy to > solve various problems, just to have other people screeming in replies that > those including such rules into their policy could just as well disable > SELinux > completely with about the same effects. > > If somebody Googles around to find solution to the specific problem and finds > advice to do "chmod -R a+rw /", (s)he is not likely to actually do it. On the > other hand, there is many more people that will include some random set of > rules into their SELinux policy, giving application(s) way more access then > they really need. Nothing to do with SELinux as such, and it would be > wrong to > blame it. But rather with human nature (which is the weakest link of any > security system). Yes, understood. And as I say, there is ongoing work to make (correct) policy configuration much more accessible to typical end users. -- Stephen Smalley National Security Agency From christofer.c.bell at gmail.com Tue Jul 5 16:36:45 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Tue, 5 Jul 2005 11:36:45 -0500 Subject: NSA motives In-Reply-To: <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <143f0f6c0507050740792c1e27@mail.gmail.com> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> Message-ID: <143f0f6c05070509364a836c50@mail.gmail.com> On 7/5/05, Valdis.Kletnieks at vt.edu wrote: > > As a matter of fact, some of us (myself included) *don't* trust our government > to keep our best interests in mind. On the other hand, I'm not worried about > the NSA sneaking in backdoors when the *real* problem is things like the Patriot > Act and standardized driver's licenses..... I don't see the big deal about standardized driver licenses, but as for the Patriot Act, if you think it's a bad thing, you're in the minority. 51% of Americans feel it's a good thing. They re-elected George W. Bush 2004 in a Patriot Act America, and they re-elected their representives in Congress that passed the legislation in the first place. We live in a very conservative America now and that America wants laws like the Patriot Act on the books. It's nothing to do with some nefarious gov't conspiracy to make your life miserable. Remember, it's not the government you need to worry about "trusting to keep your best interests in mind" it's your fellow voter. Regardless, I think this "tin foil hat" pontificating about the NSA putting backdoor holes in SELinux hysterical. I have a hard time believing there are people that suspect this is what's going on. I'm sure the guys involved in coding that backdoor are the ones that helped stage the moon landings, also. Of course, all the NSA guys are laughing at the snow job they've pulled over on me, as well. -- Chris "With the way things are starting to go in this country, if forced to choose between being caught with a van full of pirated DVDs or heroin you'd actually have to pause and think about it." -- Michael Bell, drunkenblog.com From steve at szmidt.org Tue Jul 5 16:39:04 2005 From: steve at szmidt.org (steve szmidt) Date: Tue, 5 Jul 2005 12:39:04 -0400 Subject: NSA motives - OT In-Reply-To: <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <143f0f6c0507050740792c1e27@mail.gmail.com> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> Message-ID: <200507051239.04843.steve@szmidt.org> On Tuesday 05 July 2005 12:10, Valdis.Kletnieks at vt.edu wrote: > On Tue, 05 Jul 2005 09:40:37 CDT, "Christofer C. Bell" said: > > This talk of nefarious NSA meddling in Linux to further their aims of > > keeping tabs on the underworld dealings of the less than scrupulous > > has me in stitches! Are you all for real? > > As a matter of fact, some of us (myself included) *don't* trust our > government to keep our best interests in mind. On the other hand, I'm not > worried about the NSA sneaking in backdoors when the *real* problem is > things like the Patriot Act and standardized driver's licenses..... Yes, and the worst part of it is that their idea of security is not in fact doing anything to make security any better, but actually worse. (Not talking about SELinux, but laws (like Patriot Act) that supposedly makes the country safer after 9/11.) Now if we could just get these guys to apply some common sense a'la Bruce Schneier, Founder of Counterpane Internet Security, Inc . there would be some hope for improvements... (Somebody wake me up I'm dreaming!) -- Steve Szmidt "They that would give up essential liberty for temporary safety deserve neither liberty nor safety." Benjamin Franklin From steve at szmidt.org Tue Jul 5 16:54:24 2005 From: steve at szmidt.org (steve szmidt) Date: Tue, 5 Jul 2005 12:54:24 -0400 Subject: NSA motives - OT In-Reply-To: <143f0f6c05070509364a836c50@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> <143f0f6c05070509364a836c50@mail.gmail.com> Message-ID: <200507051254.24093.steve@szmidt.org> On Tuesday 05 July 2005 12:36, Christofer C. Bell wrote: > first place. We live in a very conservative America now and that > America wants laws like the Patriot Act on the books. It's nothing to > do with some nefarious gov't conspiracy to make your life miserable. > Remember, it's not the government you need to worry about "trusting to > keep your best interests in mind" it's your fellow voter. (No, not the fellow voter but the fellow NOT voting. ) Have you ever tried to make a decision about something, for other people, where you were geographically not in the vicinity of the situation? You're bound to make some serious mistakes. The gov is acting nefarious as they often think of themselves above the people, not working for the people. Conspiracies are aplenty. People are all the times found guilty of plotting this and that. Many companies have people plotting to get rid of someone they don't like. Gov people are no different. Except they are supposed to be in charge and have this idea how things would be so much easier if they could stop everyone. Which is where the problem lies. No doubt if NSA felt they could get away with it they would take their steps to do what they feel is in national security interest. Hopefully we have enough educated people looking at code that THAT's one thing we don't have to worry about. In no way am I trying to say that's what all gov's do or all their employee's. But there is a certain amount of people who do. As I said the only difference is that they are in a position of power, and may not necessarily have the education to match. Well, that is very nicely off list topic... -- Steve Szmidt "They that would give up essential liberty for temporary safety deserve neither liberty nor safety." Benjamin Franklin From rirving at antient.org Tue Jul 5 17:20:43 2005 From: rirving at antient.org (Richard Irving) Date: Tue, 05 Jul 2005 12:20:43 -0500 Subject: NSA motives In-Reply-To: <143f0f6c05070509364a836c50@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <143f0f6c0507050740792c1e27@mail.gmail.com> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> <143f0f6c05070509364a836c50@mail.gmail.com> Message-ID: <42CAC16B.3000900@antient.org> Christofer C. Bell wrote: >On 7/5/05, Valdis.Kletnieks at vt.edu wrote: > > >>As a matter of fact, some of us (myself included) *don't* trust our government >>to keep our best interests in mind. On the other hand, I'm not worried about >>the NSA sneaking in backdoors when the *real* problem is things like the Patriot >>Act and standardized driver's licenses..... >> >> > > > >I don't see the big deal about standardized driver licenses, > Bet you don't know why your Vote is anonymous, either, huh ? > but as >for the Patriot Act, if you think it's a bad thing, you're in the >minority. 51% of Americans feel it's a good thing. > Oh ? I hear approval is -much- lower. And, BTW, realizing that 50% of the US have an IQ of about 100.... I am not sure this is really a "mob-rules" thing. Most of the same people can't even conceive why the 1st and 5th amendment even exist. Really. Thank God for Quorums. > They re-elected >George W. Bush 2004 in a Patriot Act America, and they re-elected >their representives in Congress that passed the legislation in the >first place. > Only because of FUD, GW is now at the 40% approval mark, a new all time low... and the Congress that rode Diebold in, is down to 28% approval rating. Something you don't hear much about. So the delusion that "everyone approves" is mere propaganda. > We live in a very conservative America now and that >America wants laws like the Patriot Act on the books. > So did Nazi Germany, with its new efficient Government, called the Third Reich. It too couldn't understand the need for Civil Rights. Matter of fact, it even created a slogan for the Nazi Youth, "Only Criminals don't want to be monitored" that, and another one you might have heard, "If you aren't for us, your against us". > It's nothing to >do with some nefarious gov't conspiracy to make your life miserable. >Remember, it's not the government you need to worry about "trusting to >keep your best interests in mind" it's your fellow voter. > > Wrong. Government cannot really be trusted, it is not a human, and it is not a person, that it -can- be trusted. It is a bureaucracy, with fiefdoms all over the place. Remember Ruby Ridge. "Government is not reason; it is not eloquence; it is force! Like fire, it is a dangerous servant and a fearful master." - George Washington. >Regardless, I think this "tin foil hat" pontificating about the NSA >putting backdoor holes in SELinux hysterical. I have a hard time >believing there are people that suspect this is what's going on. I'm >sure the guys involved in coding that backdoor are the ones that >helped stage the moon landings, also. > > Here, you and I concur. >Of course, all the NSA guys are laughing at the snow job they've >pulled over on me, as well. > > > I doubt they have even noticed you. Most people assume they count in the big picture of things, and they usually don't. My suggestion is to support the Constitution, and any document that attempts to supersede it, without proper acceptance and ratification by 3/4th the States, as mere trash. The Constitution is the Rule of Law, in America. Something several Supreme Court Judges have pointed out, already. http://www.cnn.com/2004/LAW/01/26/patriot.act.ap/ From walters at redhat.com Tue Jul 5 21:17:10 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 05 Jul 2005 17:17:10 -0400 Subject: SELinux and Thinkpad ACPI (part 1: screen blank) In-Reply-To: References: Message-ID: <1120598231.16262.17.camel@nexus.verbum.private> On Sun, 2005-07-03 at 16:27 -0400, Matthew Saltzman wrote: > The ACPI scripts that I use to turn off the screen and suspend to RAM no > longer function in FC4 (worked fine in FC3). Hopefully for FC5 we'll get suspend working out of the box. We don't really want our users to be in the business of having to write custom suspend scripts. > The screen blank script is > invoked on Fn-F3 and contains: > > #!/bin/sh > > if [ -f /var/tmp/acpi-lightoff ]; then > /usr/sbin/radeontool light on As a workaround, try: chcon -t initrc_exec_t /usr/local/bin/my-custom-blank-script.sh Same thing for the suspend. From mjs at ces.clemson.edu Wed Jul 6 00:18:19 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Tue, 5 Jul 2005 20:18:19 -0400 (EDT) Subject: SELinux and Thinkpad ACPI (part 1: screen blank) In-Reply-To: <1120598231.16262.17.camel@nexus.verbum.private> References: <1120598231.16262.17.camel@nexus.verbum.private> Message-ID: On Tue, 5 Jul 2005, Colin Walters wrote: > On Sun, 2005-07-03 at 16:27 -0400, Matthew Saltzman wrote: >> The ACPI scripts that I use to turn off the screen and suspend to RAM no >> longer function in FC4 (worked fine in FC3). > > Hopefully for FC5 we'll get suspend working out of the box. We don't > really want our users to be in the business of having to write custom > suspend scripts. Hopefully, indeed. But it's a challenge. My Thinkpad requires a custom initrd with radeonfb installed, and entries in /proc/acpi/ibm/hotkey in order to work correctly. I imagine most other laptops (at least) are similarly arcane. > >> The screen blank script is >> invoked on Fn-F3 and contains: >> >> #!/bin/sh >> >> if [ -f /var/tmp/acpi-lightoff ]; then >> /usr/sbin/radeontool light on > > As a workaround, try: > > chcon -t initrc_exec_t /usr/local/bin/my-custom-blank-script.sh That did it, thanks! > > Same thing for the suspend. Still can't communicate with hwclock. > > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From obi at unixkiste.org Wed Jul 6 00:43:22 2005 From: obi at unixkiste.org (Stefan Held) Date: Wed, 06 Jul 2005 02:43:22 +0200 Subject: Abnormal Apache behavior. Message-ID: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> Hi guys. Dunno if this is not new to you, but i am experiencing a strange behavior of the apache in FC4 with selinux enabled. Ok. What have i done? First i wrote some php stuff and was wondering why the Server did not allow to get some files in /css and does not allow to connect via an network socket to the postgresql server. Then i restarted the Server with apachectl stop and apachectl start. From now on everything worked fine and like expected. Then i did an Kernel update rebooted the machine and my Site was not reachable again. So i did some investigation and saw in the audit.log that selinux is disabling some stuff. Then i restarted again with apachectl stop and start. And like expected the httpd started working again. Is this an issue? I think this behavior is not normal :-) -- Stefan Held VI has only 2 Modes: obi at unixkiste.org The first one is for beeping all the time, IRCNet: Obi_Wan the second destroys the text. --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = EAF2 6A65 D102 F2DB 4970 2A67 455B 98F2 572C 3FA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Wed Jul 6 02:47:15 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 05 Jul 2005 22:47:15 -0400 Subject: Abnormal Apache behavior. In-Reply-To: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> Message-ID: <1120618035.29103.5.camel@nexus.verbum.private> On Wed, 2005-07-06 at 02:43 +0200, Stefan Held wrote: > Hi guys. > > Dunno if this is not new to you, but i am experiencing a strange > behavior of the apache in FC4 with selinux enabled. > > Ok. What have i done? > > First i wrote some php stuff and was wondering why the Server did not > allow to get some files in /css and does not allow to connect via an > network socket to the postgresql server. Did you have a look at this guide? http://fedora.redhat.com/docs/selinux-apache-fc3/ It needs to be updated for FC4, but should be helpful nonetheless. > Then i restarted the Server with apachectl stop and apachectl start. > From now on everything worked fine and like expected. The reason I believe is because apachectl restarts the Apache httpd daemon on its own. The way the Fedora targeted policy works for daemons is that they are only confined when executed via the /etc/init.d/* scripts, so when apachectl executes httpd it stays in unconfined_t. This is to prevent issues such as the system administrator executing "httpd -t" and causing a domain transition to httpd_t which isn't allowed access to the administrator's terminal. Probably we shouldn't ship the apachectl command in Fedora, instead requiring using "service httpd restart". From christofer.c.bell at gmail.com Wed Jul 6 14:41:34 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Wed, 6 Jul 2005 09:41:34 -0500 Subject: NSA motives In-Reply-To: <42CAC16B.3000900@antient.org> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <143f0f6c0507050740792c1e27@mail.gmail.com> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> <143f0f6c05070509364a836c50@mail.gmail.com> <42CAC16B.3000900@antient.org> Message-ID: <143f0f6c05070607416dc0b42@mail.gmail.com> On 7/5/05, Richard Irving wrote: > > So did Nazi Germany, with its new efficient Government, called the > Third Reich. It too couldn't understand the need for Civil Rights. Goodwin's Law[1] has been reached. "As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1." [1] http://en.wikipedia.org/wiki/Godwin's_law -- Chris "With the way things are starting to go in this country, if forced to choose between being caught with a van full of pirated DVDs or heroin you'd actually have to pause and think about it." -- Michael Bell, drunkenblog.com From rirving at antient.org Wed Jul 6 21:02:30 2005 From: rirving at antient.org (Richard Irving) Date: Wed, 06 Jul 2005 16:02:30 -0500 Subject: NSA motives In-Reply-To: <143f0f6c05070607416dc0b42@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <143f0f6c0507050740792c1e27@mail.gmail.com> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> <143f0f6c05070509364a836c50@mail.gmail.com> <42CAC16B.3000900@antient.org> <143f0f6c05070607416dc0b42@mail.gmail.com> Message-ID: <42CC46E6.1040105@antient.org> Christofer C. Bell wrote: >On 7/5/05, Richard Irving wrote: > >> So did Nazi Germany, with its new efficient Government, called the >>Third Reich. It too couldn't understand the need for Civil Rights. >> > >Goodwin's Law[1] has been reached. > To the literate, that is spelled "Godwin". * yawn * The *is* an selinux list, got anything useful, *and* on topic ? .TIA. .... ... .. , >"As an online discussion grows longer, the probability of a comparison >involving Nazis or Hitler approaches 1." >[1] http://en.wikipedia.org/wiki/Godwin's_law > > http://www.livejournal.com/users/bellatrys/2004/05/17/ From netdxr at gmail.com Wed Jul 6 21:34:24 2005 From: netdxr at gmail.com (Tom Lisjac) Date: Wed, 6 Jul 2005 15:34:24 -0600 Subject: Shorewall startup issues on FC4... Message-ID: <863ff4520507061434136348d3@mail.gmail.com> Getting back to selinux... :) When using nat and multiple ISP providers on Shorewall 2.4.0, the following error is produced on boot with FC4: Cannot open "/proc/sys/net/ipv4/route/flush The box is running the latest update: selinux-policy-targeted-1.23.18-17. Adding the following to local.te will fix it... but I don't want to have to install policy sources on my servers like I did with FC3.: allow ifconfig_t initrc_tmp_t:file read; allow ifconfig_t sysctl_net_t:file write; allow ifconfig_t var_lib_t:file read; Best regards, -Tom ----------------------------------------------------------------------------- >From /var/log/audit/audit.log: type=PATH msg=audit(1120675555.415:78677): item=0 name="/sbin/ip" type=AVC_PATH msg=audit(1120675555.415:78677): path="/var/lib/shorewall/nat" type=AVC msg=audit(1120675555.415:78677): avc: denied { read } for pid=2430 comm="ip" name="nat" dev=hda2 ino=4406613 scontext=system_u:system_r:ifconfig_t tcontext=system_u:object_r:var_lib_t tclass=file type=AVC msg=audit(1120675556.084:95462): avc: denied { write } for pid=2641 comm="ip" name="flush" dev=proc ino=-268435296 scontext=system_u:system_r:ifconfig_t tcontext=system_u:object_r:sysctl_net_t tclass=file type=PATH msg=audit(1120675555.879:90329): item=0 name="/sbin/ip" type=AVC_PATH msg=audit(1120675555.879:90329): path="/tmp/shorewall.Gh1879/providers" type=AVC msg=audit(1120675555.879:90329): avc: denied { read } for pid=2588 comm="ip" name="providers" dev=hda2 ino=3068205 scontext=system_u:system_r:ifconfig_t tcontext=system_u:object_r:initrc_tmp_t tclass=file From christofer.c.bell at gmail.com Wed Jul 6 21:36:48 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Wed, 6 Jul 2005 16:36:48 -0500 Subject: NSA motives In-Reply-To: <42CC46E6.1040105@antient.org> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <143f0f6c0507050740792c1e27@mail.gmail.com> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> <143f0f6c05070509364a836c50@mail.gmail.com> <42CAC16B.3000900@antient.org> <143f0f6c05070607416dc0b42@mail.gmail.com> <42CC46E6.1040105@antient.org> Message-ID: <143f0f6c05070614363defcc59@mail.gmail.com> On 7/6/05, Richard Irving wrote: > Christofer C. Bell wrote: > > >On 7/5/05, Richard Irving wrote: > > > >> So did Nazi Germany, with its new efficient Government, called the > >>Third Reich. It too couldn't understand the need for Civil Rights. > >> > > > >Goodwin's Law[1] has been reached. > > > To the literate, that is spelled "Godwin". > > * yawn * > > The *is* an selinux list, got anything useful, *and* on topic ? The thread is about the motives of the NSA in providing / assisting with the development of SELinux so yeah, it's on topic. Your references comparison of the US gov't to Hitler's Germany really does show you're not capable of engaging in a meaningful conversation about it. > .TIA. You're welcome. Have fun with your shiney tinfoil hat. -- Chris "With the way things are starting to go in this country, if forced to choose between being caught with a van full of pirated DVDs or heroin you'd actually have to pause and think about it." -- Michael Bell, drunkenblog.com From dwalsh at redhat.com Wed Jul 6 22:23:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 06 Jul 2005 18:23:31 -0400 Subject: Shorewall startup issues on FC4... In-Reply-To: <863ff4520507061434136348d3@mail.gmail.com> References: <863ff4520507061434136348d3@mail.gmail.com> Message-ID: <42CC59E3.8040608@redhat.com> Tom Lisjac wrote: >Getting back to selinux... :) > >When using nat and multiple ISP providers on Shorewall 2.4.0, the >following error is produced on boot with FC4: > >Cannot open "/proc/sys/net/ipv4/route/flush > >The box is running the latest update: selinux-policy-targeted-1.23.18-17. > >Adding the following to local.te will fix it... but I don't want to >have to install policy sources on my servers like I did with FC3.: > >allow ifconfig_t initrc_tmp_t:file read; >allow ifconfig_t sysctl_net_t:file write; >allow ifconfig_t var_lib_t:file read; > >Best regards, > >-Tom >----------------------------------------------------------------------------- >>From /var/log/audit/audit.log: > >type=PATH msg=audit(1120675555.415:78677): item=0 name="/sbin/ip" >type=AVC_PATH msg=audit(1120675555.415:78677): path="/var/lib/shorewall/nat" >type=AVC msg=audit(1120675555.415:78677): avc: denied { read } for pid=2430 >comm="ip" name="nat" dev=hda2 ino=4406613 >scontext=system_u:system_r:ifconfig_t >tcontext=system_u:object_r:var_lib_t tclass=file > >type=AVC msg=audit(1120675556.084:95462): avc: denied { write } for >pid=2641 comm="ip" name="flush" dev=proc ino=-268435296 >scontext=system_u:system_r:ifconfig_t >tcontext=system_u:object_r:sysctl_net_t tclass=file > >type=PATH msg=audit(1120675555.879:90329): item=0 name="/sbin/ip" >type=AVC_PATH msg=audit(1120675555.879:90329): >path="/tmp/shorewall.Gh1879/providers" >type=AVC msg=audit(1120675555.879:90329): avc: denied { read } for pid=2588 >comm="ip" name="providers" dev=hda2 ino=3068205 >scontext=system_u:system_r:ifconfig_t >tcontext=system_u:object_r:initrc_tmp_t tclass=file > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Is this running from a script? Could you attach it? -- From dwalsh at redhat.com Wed Jul 6 22:27:40 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 06 Jul 2005 18:27:40 -0400 Subject: FC4 cyrus-imapd socket issues... In-Reply-To: <863ff452050704152072f952da@mail.gmail.com> References: <863ff452050704152072f952da@mail.gmail.com> Message-ID: <42CC5ADC.5050200@redhat.com> Tom Lisjac wrote: >I'm getting the following avc's on FC4 when starting cyrus-imapd with >selinux-policy-targeted-1.23.18-17. As a result, it can't listen on >ports 110, 143 and 993. Do I need to toggle cyrus_disable_trans to >make this daemon work? > >Best regards, > >-Tom >--------------------------------- >>From /var/log/audit/audit.log. In addition to 993, an avc is also >generated for ports 110 and 143: > >type=AVC msg=audit(1120506529.586:145746): avc: denied { name_bind } >for pid=2919 comm="cyrus-master" src=993 >scontext=system_u:system_r:cyrus_t tcontext=system_u: >type=SOCKETCALL msg=audit(1120506529.662:145983): nargs=3 a0=7 a1=9e18aa8 a2=10 >type=SOCKADDR msg=audit(1120506529.662:145983): >saddr=0200006E000000000000000000000000 >type=SYSCALL msg=audit(1120506529.662:145983): arch=40000003 >syscall=102 success=no exit=-13 a0=2 a1=bfc61440 a2=8054164 a3=9e18c40 >items=0 pid=2919 auid=4294967295 u > >... which causes the following in /var/log/messages > >Jul 4 15:54:13 test master[6295]: unable to create imap listener >socket: Address family not supported by protocol >Jul 4 15:54:13 test master[6295]: unable to create imaps listener >socket: Address family not supported by protocol >Jul 4 15:54:13 test master[6295]: unable to create pop3 listener >socket: Address family not supported by protocol >Jul 4 15:54:13 test master[6295]: unable to create pop3s listener >socket: Address family not supported by protocol > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Does policy 1.24-3 fix your problem? -- From netdxr at gmail.com Wed Jul 6 22:43:57 2005 From: netdxr at gmail.com (Tom Lisjac) Date: Wed, 6 Jul 2005 16:43:57 -0600 Subject: Shorewall startup issues on FC4... In-Reply-To: <42CC59E3.8040608@redhat.com> References: <863ff4520507061434136348d3@mail.gmail.com> <42CC59E3.8040608@redhat.com> Message-ID: <863ff452050706154371f9c369@mail.gmail.com> On 7/6/05, Daniel J Walsh wrote: > Tom Lisjac wrote: > >When using nat and multiple ISP providers on Shorewall 2.4.0, the > >following error is produced on boot with FC4: > Is this running from a script? Could you attach it? Yes, Shorewall is a large collection of bash scripts. The complete package is nearly a megabyte, so it would probably be most practical for me to post the sections around the problem /sbin/ip calls. I'll try to isolate them later this evening. Previous versions of Shorewall worked fine under FC3. The shorewall main site is here: http://shorewall.net/. Best regards, -Tom From netdxr at gmail.com Wed Jul 6 22:56:35 2005 From: netdxr at gmail.com (Tom Lisjac) Date: Wed, 6 Jul 2005 16:56:35 -0600 Subject: FC4 cyrus-imapd socket issues... In-Reply-To: <42CC5ADC.5050200@redhat.com> References: <863ff452050704152072f952da@mail.gmail.com> <42CC5ADC.5050200@redhat.com> Message-ID: <863ff45205070615567ee2f338@mail.gmail.com> On 7/6/05, Daniel J Walsh wrote: > Tom Lisjac wrote: > > >I'm getting the following avc's on FC4 when starting cyrus-imapd with > >selinux-policy-targeted-1.23.18-17. As a result, it can't listen on > >ports 110, 143 and 993. > Does policy 1.24-3 fix your problem? Yes... no avc's on startup and the three ports are now open. Thanks much! -Tom From stewartetcie at canada.com Wed Jul 6 20:01:58 2005 From: stewartetcie at canada.com (stewartetcie at canada.com) Date: Wed, 06 Jul 2005 13:01:58 -0700 (PDT) Subject: NSA motives Message-ID: <20050706200159.27844.fh049.wm@smtp.sc0.cp.net> Waiting for the other shoe to drop? On 5 Jul 07:11 (CEST) Peter Magnusson iocc at fedora-selinux.lists.flashdance.cx> wrote: >I'll have my tinfoil hat on for the rest of the day On 5 Jul 04:39 (PDT) Angela Kahealani wrote: >I doubt it... you probably meant aluminum foil. >If you've got actual tin foil, where do I get some? So the real conspiracy is about who has replaced all the tin foil with aluminum foil? I don't think so. This belief appears to have arisen as a result of a simple misunderstanding. Many people who've heard the same voices you two claim to hear have been diagnosed with tinnitus. Whether or not these diagnoses are accurate, tin probably won't help. It sure is funny about all that aluminum foil though... On 4 Jul 23:05 (PDT) Valdis Kletnieks wrote: >The back door is elsewhere, where you'll never find >it, especially if you're busy looking at the SELinux >code looking for backdoors. Interesting, if true, but I'm more concerned that the mandatory access control of SE Linux, combined with a digital rights management policy, provides a strategy to control the flow of information on the internet. Digital rights management policies require a unique ID for information access that can also provide the "internet DNA" to track users online. Distributing software that's used to restrict access to information under non-restrictive licenses like the GPL seems to be counter-productive. It is inappropriate for the open source community to be co-opted by a strategy that runs counter to their motives. Now that SE Linux has been merged into Linux 2.6, without digital rights management policies, are we waiting for the other shoe to drop? The thing to remember about SE Linux is just because it is merged with the Linux 2.6 kernel does not mean that it is mandatory. It can be removed with a some effort, just like those tin foil hats. From rirving at antient.org Wed Jul 6 23:36:04 2005 From: rirving at antient.org (Richard Irving) Date: Wed, 06 Jul 2005 18:36:04 -0500 Subject: NSA motives In-Reply-To: <143f0f6c05070614363defcc59@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <143f0f6c0507050740792c1e27@mail.gmail.com> <200507051610.j65GAdqo011162@turing-police.cc.vt.edu> <143f0f6c05070509364a836c50@mail.gmail.com> <42CAC16B.3000900@antient.org> <143f0f6c05070607416dc0b42@mail.gmail.com> <42CC46E6.1040105@antient.org> <143f0f6c05070614363defcc59@mail.gmail.com> Message-ID: <42CC6AE4.6030905@antient.org> Christofer C. Bell wrote: >On 7/6/05, Richard Irving wrote: > >>Christofer C. Bell wrote: >> >>>On 7/5/05, Richard Irving wrote: >>> >>>> So did Nazi Germany, with its new efficient Government, called the >>>>Third Reich. It too couldn't understand the need for Civil Rights. >>>> >>>Goodwin's Law[1] has been reached. >>> >> To the literate, that is spelled "Godwin". >> >> * yawn * >> >> The *is* an selinux list, got anything useful, *and* on topic ? >> > >The thread is about the motives of the NSA in providing / assisting >with the development of SELinux so yeah, it's on topic. > A better question perhaps is, "..is this thread *really* on topic" ? Tinfoil Beanie trolls belong elsewhere, *really*. > Your >references comparison of the US gov't to Hitler's Germany really does >show you're not capable of engaging in a meaningful conversation about >it. > Personally, I consider spelling the citation -correctly-, the first sign of a potentially intelligent *meaningful* conversation impending... * cough * "neverallow domain domain:goodwin_tinfoil_beanie_class_set ~rw_file_perms;" > > >>.TIA. >> > >You're welcome. Have fun with your shiney tinfoil hat. > Ahhh... Ad Homonym, the sign of the lack of any contrary facts, or a valid counter-argument. Thanks for conceding. I take it you are not a professional, but a RR zealot, and like the rest of your pseudo-cult movement, not very insightful, -nor- educated on the facts... ... mostly full of propaganda, deflection, distortion, lies, subversion, ad homonym, and utterly unable to control yourself, or restrain your context to the appropriate time and place, such as the recent posts here to a professional list demonstrate. But, this list does not exist for you to spread your RR propaganda, nor as a tool to satisfy your now personal vendetta. It is for discussion of selinux implementation issue's. Ever heard the expression: "Get a Blog!" ? It applies. Now returning you to your regular S/N ratio. (Hopefully) 8-) .TIA.. .... ... .. , PPS: 51% approved that the Patriot should be "amended", and _limited_. That is NOT the same as 51% of the people "approving of the Patriot Act". (So much so, the limitation bill -passed- the vote in the House.) http://www.washingtonpost.com/wp-dyn/content/article/2005/06/15/AR2005061501953.html ---- "There are liars, damned liars, and statisticians!" :-P From angela at kahealani.com Thu Jul 7 04:01:05 2005 From: angela at kahealani.com (Angela Kahealani) Date: Wed, 6 Jul 2005 18:01:05 -1000 Subject: NSA motives In-Reply-To: <143f0f6c05070614363defcc59@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <42CC46E6.1040105@antient.org> <143f0f6c05070614363defcc59@mail.gmail.com> Message-ID: <200507061801.05979.angela@kahealani.com> On Wed, 2005-07-06 11:36, Christofer C. Bell wrote: > You're welcome. Have fun with your shiney tinfoil hat. No, tin foil is dull. And even on aluminum foil, only one side is shiny. -- All information and transactions are non negotiable and are private between the parties. All rights reserved without prejudice, Copyright 2005 Angela Kahealani http://www.kahealani.com/ From tony.molloy at ul.ie Thu Jul 7 11:08:29 2005 From: tony.molloy at ul.ie (Tony Molloy) Date: Thu, 7 Jul 2005 12:08:29 +0100 Subject: Problem with SELinux and NIS Message-ID: <200507071208.29947.tony.molloy@ul.ie> Hi, My test system runs FC4 updated to the latest rpm's as of today. I'm trying to get SELinux working and am having a slight problem I've gotten nfs, samba and ntpd working OK, but I have a problem with NIS running yppasswd to set passwords. With SELinux disabled it work's, with SELinux enabled, in enforcing mode and targetted policy it doesn't. The errors I get are as follows: /var/log/messages ( edited ) beta rpc.yppasswdd[1778]: update testacc1 (uid=9001) from host 10.220.1.151 failed beta rpc.yppasswdd[1778]: password file locked ^^^^^^^^^^^^^^^^^^^^ /var/log/audit/audit.log type=PATH msg=audit(1120732794.982:341722): item=0 name="/etc/.pwd.lock" flags=310 inode=62249 dev=03:01 mode=040755 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120732794.982:341722): cwd="/" type=SYSCALL msg=audit(1120732794.982:341722): arch=40000003 syscall=5 success=no exit=-13 a0=acf181 a1=41 a2=180 a3=ffffffff items=1 pid=1778 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="rpc.yppasswdd" exe="/usr/sbin/rpc.yppasswdd" type=AVC msg=audit(1120732794.982:341722): avc: denied { write } for pid=1778 comm="rpc.yppasswdd" name=".pwd.lock" dev=hda1 ino=62391 scontext=system_u:system_r:rpcd_t tcontext=system_u:object_r:shadow_t tclass=file So it seems that SELinux is denying rpc.yppasswdd writing to /etc/.pwd.lock How do I allow it to write to that file. Thank's in advance Tony -- Tony Molloy. Dept. of Comp. Sci. University of Limerick From dwalsh at redhat.com Thu Jul 7 12:32:25 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 07 Jul 2005 08:32:25 -0400 Subject: Problem with SELinux and NIS In-Reply-To: <200507071208.29947.tony.molloy@ul.ie> References: <200507071208.29947.tony.molloy@ul.ie> Message-ID: <42CD20D9.8080402@redhat.com> Tony Molloy wrote: >Hi, > >My test system runs FC4 updated to the latest rpm's as of today. I'm >trying to get SELinux working and am having a slight problem > >I've gotten nfs, samba and ntpd working OK, but I have a problem with NIS >running yppasswd to set passwords. > >With SELinux disabled it work's, with SELinux enabled, in enforcing mode >and targetted policy it doesn't. > >The errors I get are as follows: > >/var/log/messages ( edited ) > >beta rpc.yppasswdd[1778]: update testacc1 (uid=9001) from host >10.220.1.151 failed >beta rpc.yppasswdd[1778]: password file locked > ^^^^^^^^^^^^^^^^^^^^ > >/var/log/audit/audit.log > >type=PATH msg=audit(1120732794.982:341722): item=0 name="/etc/.pwd.lock" >flags=310 inode=62249 dev=03:01 mode=040755 ouid=0 ogid=0 rdev=00:00 > >type=Unknown msg=audit(1120732794.982:341722): cwd="/" > >type=SYSCALL msg=audit(1120732794.982:341722): arch=40000003 syscall=5 >success=no exit=-13 a0=acf181 a1=41 a2=180 a3=ffffffff items=1 pid=1778 >auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 >comm="rpc.yppasswdd" exe="/usr/sbin/rpc.yppasswdd" > >type=AVC msg=audit(1120732794.982:341722): avc: denied { write } for >pid=1778 comm="rpc.yppasswdd" name=".pwd.lock" dev=hda1 ino=62391 >scontext=system_u:system_r:rpcd_t tcontext=system_u:object_r:shadow_t >tclass=file > >So it seems that SELinux is denying rpc.yppasswdd writing >to /etc/.pwd.lock > >How do I allow it to write to that file. > >Thank's in advance > >Tony > > > Please submit a bugzilla. Looks like we need policy for yppasswdd. Dan -- From christofer.c.bell at gmail.com Thu Jul 7 14:53:21 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Thu, 7 Jul 2005 09:53:21 -0500 Subject: NSA motives In-Reply-To: <200507061801.05979.angela@kahealani.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <42CC46E6.1040105@antient.org> <143f0f6c05070614363defcc59@mail.gmail.com> <200507061801.05979.angela@kahealani.com> Message-ID: <143f0f6c05070707535c257848@mail.gmail.com> On 7/6/05, Angela Kahealani wrote: > On Wed, 2005-07-06 11:36, Christofer C. Bell wrote: > > You're welcome. Have fun with your shiney tinfoil hat. > > No, tin foil is dull. > And even on aluminum foil, only one side is shiny. Ha! Good one. :-) I'm not sure what tinfoil hat boy's issue is. He seems to think I'm some sort of right wing extremist for pointing out that 51% of America voted for George Bush. Truth must be painful when you're frothing at the mouth. Unfortunately for me, I'm part of the other 49% :-( Anyway, he's free to keep looking for conspiracies where none exist. -- Chris "With the way things are starting to go in this country, if forced to choose between being caught with a van full of pirated DVDs or heroin you'd actually have to pause and think about it." -- Michael Bell, drunkenblog.com From jon at internection.com Thu Jul 7 15:15:05 2005 From: jon at internection.com (Jon August) Date: Thu, 7 Jul 2005 11:15:05 -0400 Subject: NSA motives In-Reply-To: <143f0f6c05070707535c257848@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <42CC46E6.1040105@antient.org> <143f0f6c05070614363defcc59@mail.gmail.com> <200507061801.05979.angela@kahealani.com> <143f0f6c05070707535c257848@mail.gmail.com> Message-ID: <93E522DA-6FA5-4FC4-A005-68C2A6487F5E@internection.com> Is this the SELinux list? On Jul 7, 2005, at 10:53 AM, Christofer C. Bell wrote: > On 7/6/05, Angela Kahealani wrote: > >> On Wed, 2005-07-06 11:36, Christofer C. Bell wrote: >> >>> You're welcome. Have fun with your shiney tinfoil hat. >>> >> >> No, tin foil is dull. >> And even on aluminum foil, only one side is shiny. >> > > Ha! Good one. :-) I'm not sure what tinfoil hat boy's issue is. He > seems to think I'm some sort of right wing extremist for pointing out > that 51% of America voted for George Bush. Truth must be painful when > you're frothing at the mouth. > > Unfortunately for me, I'm part of the other 49% :-( > > Anyway, he's free to keep looking for conspiracies where none exist. > > -- > Chris > > "With the way things are starting to go in this country, if forced to > choose between being caught with a van full of pirated DVDs or heroin > you'd actually have to pause and think about it." -- Michael Bell, > drunkenblog.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From rirving at antient.org Thu Jul 7 16:18:58 2005 From: rirving at antient.org (Richard Irving) Date: Thu, 07 Jul 2005 11:18:58 -0500 Subject: NSA motives In-Reply-To: <143f0f6c05070707535c257848@mail.gmail.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <42CC46E6.1040105@antient.org> <143f0f6c05070614363defcc59@mail.gmail.com> <200507061801.05979.angela@kahealani.com> <143f0f6c05070707535c257848@mail.gmail.com> Message-ID: <42CD55F2.5020005@antient.org> Christofer C. Bell wrote: > On 7/6/05, Angela Kahealani wrote: > >> On Wed, 2005-07-06 11:36, Christofer C. Bell wrote: >> >>> You're welcome. Have fun with your shiney tinfoil hat. >> >> No, tin foil is dull. >> And even on aluminum foil, only one side is shiny. > > Ha! Good one. :-) I'm not sure what tinfoil hat boy's issue is. I love the name calling, public and private, helps put you into perspective... > He > seems to think I'm some sort of right wing extremist for pointing out > that 51% of America voted for George Bush. Please stick to the truth, You didn't make that statement, you stated 51% of the United States approved of the Patriot act. Here are your own words: > "but as for the Patriot Act, if you think it's a bad thing, you're in the > minority. 51% of Americans feel it's a good thing." And that statistic is *not* correct. That is what is called a "distortion", it is a form of a "lie". I know the difference is hard to comprehend, but give it your best, ok ? Shoot, 51% don't even approve of "W", -or -the congress' actions. 51% was back during the height of the "chicken little" effect, *much* water has passed under the bridge since then. For example, it was determined conclusively that there were no WMD's, and that Iraq had nothing to do with 911. >Truth must be painful when >you're frothing at the mouth. See above, what does your statement have to do with truth ? You published bad information, I correct it, and now *I* am "frothing" ? Anything but accept and acknowledge that you are *wrong*, I guess, or let this list be used for selinux, instead of a political pulpit. Don't you have anything better than Ad Homonym ? Or, are you just a "one trick" pony ? > > Unfortunately for me, I'm part of the other 49% :-( > > Anyway, he's free to keep looking for conspiracies where none exist. You mean like the Downing Street Memo ? :-P Now, back to "Get a Blog!", this list is about selinux, not the ones fools nutty fear that someone has put a back door in the core of selinux, or yours that the Majority of America approves of the assault on Civil Rights, and the Constitution, inherent in the Patriot, and this Administration. *Neither* are true. More Signal, Less Noise. .TIA. .... ... .. . From i.pilcher at comcast.net Thu Jul 7 16:26:06 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 07 Jul 2005 11:26:06 -0500 Subject: Bug 160292 (cups-lpd) - back in 1.23.18-16? (SOLVED) In-Reply-To: References: Message-ID: I'm not sure what did the trick (possibly relabeling the whole root filesystem), but this problem has gone away. I do still get the following in /var/log/audit/audit.log when I print, but it doesn't seem to make a difference. type=PATH msg=audit(1120753044.639:1494072): item=0 name="/etc/cups/lpoptions" flags=101 inode=3081109 dev=09:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 type=Unknown msg=audit(1120753044.639:1494072): cwd="/" type=SYSCALL msg=audit(1120753044.639:1494072): arch=40000003 syscall=5 success=no exit=-13 a0=261e8a a1=0 a2=1b6 a3=98a8798 items=1 pid=3208 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 comm="cups-lpd" exe="/usr/lib/cups/daemon/cups-lpd" type=AVC msg=audit(1120753044.639:1494072): avc: denied { read } for pid=3208 comm="cups-lpd" name="lpoptions" dev=md3 ino=3081109 scontext=system_u:system_r:cupsd_lpd_t tcontext=system_u:object_r:cupsd_rw_etc_t tclass=file -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From mayerf at tresys.com Thu Jul 7 17:52:46 2005 From: mayerf at tresys.com (Frank Mayer) Date: Thu, 7 Jul 2005 13:52:46 -0400 Subject: ANN: Dates set of Second SELinux Symposium Message-ID: <200507071752.j67HqmQ4011181@gotham.columbia.tresys.com> The Second Security Enhanced Linux Symposium is scheduled for 28 February - 2 March 2006 in Baltimore, Maryland, USA. Last year's inaugural symposium was a tremendous success providing the SELinux development and user community the opportunity to discuss related research results, development plans, and applications. In the second Symposium, we will build upon that success with a special focus on applications of SELinux to solve real-world security challenges. The Symposium is an opportunity to learn about SELinux and share technical and application experiences. The Symposium is a 3-day conference, with one day for tutorials and two days for technical presentations and interchange. The call for papers will be released in the coming days. For additional information see the Symposium's web site at www.selinux-symposium.org or e-mail at info at selinux-symposium.org. Technical Committee: Joshua Brindle, Tresys Russell Coker, Red Hat Chad Hanson, TCS Trent Jaeger, IBM Pete Loscocco, NSA Karl MacMillan, Tresys Frank Mayer (Chair), Tresys James Morris, Red Hat Doc Shankar, IBM Stephen Smalley, NSA Daniel Walsh, Red Hat From preetimalakar at yahoo.co.in Fri Jul 8 04:44:25 2005 From: preetimalakar at yahoo.co.in (Preeti Malakar) Date: Fri, 8 Jul 2005 05:44:25 +0100 (BST) Subject: Fedora 3 and SELinux Message-ID: <20050708044426.45040.qmail@web8602.mail.in.yahoo.com> Sir, I installed Fedora core 3 with firewall enabled and selinux active option during installation but there is no source code anywhere in the system tree. The /usr/src directory contains redhat directory but no linux-2.6.5-1.358 which is there in fedora 2. Some SELinux commands are also missing like change_bool, setsebool -P option. Can anyone tell me what am I missing. Thanking you Preeti MTech (CSE) IITGuwahati _______________________________________________________ Too much spam in your inbox? Yahoo! Mail gives you the best spam protection for FREE! http://in.mail.yahoo.com From mattdm at mattdm.org Fri Jul 8 12:21:06 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 8 Jul 2005 08:21:06 -0400 Subject: Fedora 3 and SELinux In-Reply-To: <20050708044426.45040.qmail@web8602.mail.in.yahoo.com> References: <20050708044426.45040.qmail@web8602.mail.in.yahoo.com> Message-ID: <20050708122106.GA16548@jadzia.bu.edu> On Fri, Jul 08, 2005 at 05:44:25AM +0100, Preeti Malakar wrote: > I installed Fedora core 3 with firewall enabled > and selinux active option during installation but > there is no source code anywhere in the system tree. > The /usr/src directory contains redhat directory but > no linux-2.6.5-1.358 which is there in fedora 2. This part has nothing to do with SELinux. Read the FC3 release notes. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From tony.molloy at ul.ie Fri Jul 8 13:04:21 2005 From: tony.molloy at ul.ie (Tony Molloy) Date: Fri, 8 Jul 2005 14:04:21 +0100 Subject: Problem with SELinux and NIS In-Reply-To: <42CD20D9.8080402@redhat.com> References: <200507071208.29947.tony.molloy@ul.ie> <42CD20D9.8080402@redhat.com> Message-ID: <200507081404.21506.tony.molloy@ul.ie> On Thursday 07 July 2005 13:32, you wrote: > Tony Molloy wrote: > >Hi, > > > >My test system runs FC4 updated to the latest rpm's as of today. I'm > >trying to get SELinux working and am having a slight problem > > > >I've gotten nfs, samba and ntpd working OK, but I have a problem with > > NIS running yppasswd to set passwords. > > > >With SELinux disabled it work's, with SELinux enabled, in enforcing > > mode and targetted policy it doesn't. > > > >The errors I get are as follows: > > > >/var/log/messages ( edited ) > > > >beta rpc.yppasswdd[1778]: update testacc1 (uid=9001) from host > >10.220.1.151 failed > >beta rpc.yppasswdd[1778]: password file locked > > ^^^^^^^^^^^^^^^^^^^^ > > > >/var/log/audit/audit.log > > > >type=PATH msg=audit(1120732794.982:341722): item=0 > > name="/etc/.pwd.lock" flags=310 inode=62249 dev=03:01 mode=040755 > > ouid=0 ogid=0 rdev=00:00 > > > >type=Unknown msg=audit(1120732794.982:341722): cwd="/" > > > >type=SYSCALL msg=audit(1120732794.982:341722): arch=40000003 syscall=5 > >success=no exit=-13 a0=acf181 a1=41 a2=180 a3=ffffffff items=1 > > pid=1778 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > sgid=0 fsgid=0 comm="rpc.yppasswdd" exe="/usr/sbin/rpc.yppasswdd" > > > >type=AVC msg=audit(1120732794.982:341722): avc: denied { write } for > >pid=1778 comm="rpc.yppasswdd" name=".pwd.lock" dev=hda1 ino=62391 > >scontext=system_u:system_r:rpcd_t tcontext=system_u:object_r:shadow_t > >tclass=file > > > >So it seems that SELinux is denying rpc.yppasswdd writing > >to /etc/.pwd.lock > > > >How do I allow it to write to that file. > > > >Thank's in advance > > > >Tony > > Please submit a bugzilla. Looks like we need policy for yppasswdd. > > Dan Done. Bugzilla bug 162746 Tony -- Tony Molloy. Dept. of Comp. Sci. University of Limerick From jorton at redhat.com Fri Jul 8 13:15:58 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 8 Jul 2005 14:15:58 +0100 Subject: Abnormal Apache behavior. In-Reply-To: <1120618035.29103.5.camel@nexus.verbum.private> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> <1120618035.29103.5.camel@nexus.verbum.private> Message-ID: <20050708131558.GA22850@redhat.com> On Tue, Jul 05, 2005 at 10:47:15PM -0400, Colin Walters wrote: > On Wed, 2005-07-06 at 02:43 +0200, Stefan Held wrote: > > Then i restarted the Server with apachectl stop and apachectl start. > > From now on everything worked fine and like expected. > > The reason I believe is because apachectl restarts the Apache httpd > daemon on its own. The way the Fedora targeted policy works for daemons > is that they are only confined when executed via the /etc/init.d/* > scripts, so when apachectl executes httpd it stays in unconfined_t. Eh? I thought the transition happens upon exec of httpd regardless of who performs the exec. Empirical evidence suggests that's the case anyway... [root at tango ~]# service httpd stop Stopping httpd: [ OK ] [root at tango ~]# apachectl start [root at tango ~]# ps axZ | grep httpd root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start joe From sds at tycho.nsa.gov Fri Jul 8 13:43:30 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 08 Jul 2005 09:43:30 -0400 Subject: Abnormal Apache behavior. In-Reply-To: <20050708131558.GA22850@redhat.com> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> <1120618035.29103.5.camel@nexus.verbum.private> <20050708131558.GA22850@redhat.com> Message-ID: <1120830210.19035.50.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote: > Eh? I thought the transition happens upon exec of httpd regardless of > who performs the exec. Empirical evidence suggests that's the case > anyway... > > [root at tango ~]# service httpd stop > Stopping httpd: [ OK ] > [root at tango ~]# apachectl start > [root at tango ~]# ps axZ | grep httpd > root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start On FC4, apachectl start leaves it running in unconfined_t. In FC3, since the system starts in unconfined_t (so both rc scripts and user shells are in the same domain), there is no distinction, so you wouldn't see a difference there. -- Stephen Smalley National Security Agency From hongwei at wustl.edu Fri Jul 8 13:42:18 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 8 Jul 2005 08:42:18 -0500 (CDT) Subject: mysql error Message-ID: <1206.128.252.85.103.1120830138.squirrel@morpheus.wustl.edu> Hi, I have a fc3 system: kernel 2.6.11-1.35_FC3, selinux enforced with target policy 1.17.30-2.96, mysql 3.23.58-16.FC3.1, php 4.3.10-3.2. After I updated mysql from 3.23.4x to the above version, I cannot connect mysql database from web by using localhost although I can do it from ssh command. The error message is: Could not connect: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13) If I run setenforce 0, then everything works. The mysql.sock shows: # ls -lZ /var/lib/mysql/mysql.sock srwxrwxrwx mysql mysql root:object_r:mysqld_db_t /var/lib/mysql/mysql.sock How to fix the problem? Thanks! Hongwei Li From paul.moore at hp.com Fri Jul 8 19:19:10 2005 From: paul.moore at hp.com (Paul Moore) Date: Fri, 08 Jul 2005 15:19:10 -0400 Subject: Question regarding /etc/rc.d/rc.sysinit Message-ID: <42CED1AE.3080906@hp.com> Is there any reason for keeping lines 75 - 85 of /etc/rc.d/rc.sysinit (from initscripts-8.11.1-1)? The reason I ask is that these ten lines are causing AVC denial messages when using Dan Walsh's MLS policy and as far as I can tell these lines don't do anything useful. In my limited testing removing these lines from rc.sysinit has not caused any problems - am I missing something? --- rc.sysinit.orig-06082005 2005-07-08 14:42:39.000000000 -0400 +++ rc.sysinit 2005-07-08 15:09:02.000000000 -0400 @@ -70,20 +70,6 @@ relabel_selinux() { fi } - - -if [ "$HOSTTYPE" != "s390" -a "$HOSTTYPE" != "s390x" ]; then - last=0 - for i in `LC_ALL=C grep '^[0-9].*respawn:/sbin/mingetty' /etc/inittab | sed 's/^.* tty\([0-9][0-9]*\).*/\1/g'`; do - > /dev/tty$i - last=$i - done - if [ $last -gt 0 ]; then - > /dev/tty$((last+1)) - > /dev/tty$((last+2)) - fi -fi - if [ "$CONSOLETYPE" = "vt" -a -x /sbin/setsysfont ]; then echo -n "Setting default font ($SYSFONT): " /sbin/setsysfont -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From notting at redhat.com Fri Jul 8 19:23:06 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 8 Jul 2005 15:23:06 -0400 Subject: Question regarding /etc/rc.d/rc.sysinit In-Reply-To: <42CED1AE.3080906@hp.com> References: <42CED1AE.3080906@hp.com> Message-ID: <20050708192306.GA26992@nostromo.devel.redhat.com> Paul Moore (paul.moore at hp.com) said: > Is there any reason for keeping lines 75 - 85 of /etc/rc.d/rc.sysinit > (from initscripts-8.11.1-1)? The reason I ask is that these ten lines > are causing AVC denial messages when using Dan Walsh's MLS policy and as > far as I can tell these lines don't do anything useful. In my limited > testing removing these lines from rc.sysinit has not caused any problems > - am I missing something? They're a workaround for a kernel bug that wasn't fixed until 2.6.12. Bill From kcarr at tresys.com Fri Jul 8 19:25:12 2005 From: kcarr at tresys.com (Kevin Carr) Date: Fri, 8 Jul 2005 15:25:12 -0400 Subject: seaudit crashes with segmentation fault Message-ID: <200507081925.j68JPCvx004951@gotham.columbia.tresys.com> > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of John Bray > i'm posting this per stephen's request: > > On Mon, 2005-06-27 at 14:32 -0400, Stephen Smalley wrote: > > On Mon, 2005-06-27 at 13:15 -0500, John Bray wrote: > > > every time i try to run seaudit, it immediately crashes with a > > > segmentation fault. the following errors appear, with or without any > > > arguments on the commandline: > > > > > > [root at junior setools-2.1.0]# seaudit -l /var/log/messages > > > -p /etc/selinux/targeted/src/policy/policy.conf > > > > > > > > wonder if anyone has any ideas or suggestions? > > > > - Post to fedora-selinux-list for SELinux questions. > > - What is your base system, FC3 or FC4? > > - In FC4, unless you disable auditd, audit messages are sent by the > > kernel to auditd and are written by auditd to /var/log/audit/audit.log. > > - Not sure that seaudit has been updated for the associated changes. > > > > thanks stephen. i didn't even know that there was such a list. :-) > > its FC4. clean install. auditd is running. > > i guess i'd misunderstood. i'd thought that with it running, the > audit.log as well as to messages. > > however, if i point at audit.log instead, it does NOT segfault, but > finds no messages either. :-) > > thanks for your help. i will see about getting to the selinux list. > > hope your day is going well. > > john FYI - The latest release of setools has addressed this problem. Version 2.1.1 of setools is available at www.tresys.com. Kevin Carr Tresys Technology From hongwei at wustl.edu Fri Jul 8 19:49:24 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 8 Jul 2005 14:49:24 -0500 (CDT) Subject: policy updated, then selinux error? Message-ID: <2581.128.252.85.103.1120852164.squirrel@morpheus.wustl.edu> Hi, I just updated selinux target policy (including the source) from 1.17.30-2.96 to 1.17.30-3.16 on my fc3 linux system (kernel 2.6.11-1.35_FC3), and also updated checkpolicy-1.17.5-1.2. The updating process did not show any error. Then, I reboot the system that showed a lot of error message like: invalid ... in /etc/selinux/targeted/src/policy/file_contexts/... (it went though so fast that I could not catch all the words). The system is running, then I go to /etc/selinux/targeted/src/policy and run make load and got: # make load mkdir -p /etc/selinux/targeted/policy /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf domains/unconfined.te:19:ERROR 'syntax error' at token '{' on line 3897: typealias unconfined_t alias { kernel_t init_t initrc_t logrotate_t sendmail_t sshd_t secadm_t sysadm_t rpm_t rpm_script_t xdm_t }; typeattribute tty_device_t { tty_device_t devpts_t }; /usr/bin/checkpolicy: error(s) encountered while parsing configuration make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 I tried touch /.autorelable and reboot, the same error. Can somebody tell what's wrong? how to fix it? Thanks! Hongwei Li From paul at city-fan.org Fri Jul 8 20:43:50 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 08 Jul 2005 21:43:50 +0100 Subject: policy updated, then selinux error? In-Reply-To: <2581.128.252.85.103.1120852164.squirrel@morpheus.wustl.edu> References: <2581.128.252.85.103.1120852164.squirrel@morpheus.wustl.edu> Message-ID: <1120855430.15736.300.camel@laurel.intra.city-fan.org> On Fri, 2005-07-08 at 14:49 -0500, Hongwei Li wrote: > Hi, > > I just updated selinux target policy (including the source) from 1.17.30-2.96 > to 1.17.30-3.16 on my fc3 linux system (kernel 2.6.11-1.35_FC3), and also > updated checkpolicy-1.17.5-1.2. The updating process did not show any error. > > Then, I reboot the system that showed a lot of error message like: > invalid ... in /etc/selinux/targeted/src/policy/file_contexts/... (it went > though so fast that I could not catch all the words). The system is running, > then I go to /etc/selinux/targeted/src/policy and run make load and got: > > # make load > mkdir -p /etc/selinux/targeted/policy > /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > domains/unconfined.te:19:ERROR 'syntax error' at token '{' on line 3897: > typealias unconfined_t alias { kernel_t init_t initrc_t logrotate_t sendmail_t > sshd_t secadm_t sysadm_t rpm_t rpm_script_t xdm_t }; > typeattribute tty_device_t { tty_device_t devpts_t }; > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 > > I tried touch /.autorelable and reboot, the same error. > > Can somebody tell what's wrong? how to fix it? # cd /etc/selinux/targeted/src/policy # rm -f policy.conf # make reload Paul. -- Paul Howarth From hongwei at wustl.edu Fri Jul 8 21:15:20 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 8 Jul 2005 16:15:20 -0500 (CDT) Subject: policy updated, then selinux error? In-Reply-To: <1120855430.15736.300.camel@laurel.intra.city-fan.org> References: <2581.128.252.85.103.1120852164.squirrel@morpheus.wustl.edu> <1120855430.15736.300.camel@laurel.intra.city-fan.org> Message-ID: <4017.128.252.85.103.1120857320.squirrel@morpheus.wustl.edu> > On Fri, 2005-07-08 at 14:49 -0500, Hongwei Li wrote: >> Hi, >> >> I just updated selinux target policy (including the source) from >> 1.17.30-2.96 >> to 1.17.30-3.16 on my fc3 linux system (kernel 2.6.11-1.35_FC3), and also >> updated checkpolicy-1.17.5-1.2. The updating process did not show any error. >> >> Then, I reboot the system that showed a lot of error message like: >> invalid ... in /etc/selinux/targeted/src/policy/file_contexts/... (it went >> though so fast that I could not catch all the words). The system is >> running, >> then I go to /etc/selinux/targeted/src/policy and run make load and got: >> >> # make load >> mkdir -p /etc/selinux/targeted/policy >> /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf >> /usr/bin/checkpolicy: loading policy configuration from policy.conf >> domains/unconfined.te:19:ERROR 'syntax error' at token '{' on line 3897: >> typealias unconfined_t alias { kernel_t init_t initrc_t logrotate_t >> sendmail_t >> sshd_t secadm_t sysadm_t rpm_t rpm_script_t xdm_t }; >> typeattribute tty_device_t { tty_device_t devpts_t }; >> /usr/bin/checkpolicy: error(s) encountered while parsing configuration >> make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 >> >> I tried touch /.autorelable and reboot, the same error. >> >> Can somebody tell what's wrong? how to fix it? > > # cd /etc/selinux/targeted/src/policy > # rm -f policy.conf > # make reload > > Paul. > -- > Paul Howarth > I got: # make reload mkdir -p tmp m4 -Imacros -s flask/security_classes ...... ...... mv policy.conf.tmp policy.conf mkdir -p /etc/selinux/targeted/policy /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf security: 3 users, 4 roles, 343 types, 30 bools security: 55 classes, 14894 rules /usr/bin/checkpolicy: policy configuration loaded /usr/bin/checkpolicy: writing binary representation (version 18) to /etc/selinux/targeted/policy/policy.18 /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 unknown boolean use_syslogng /usr/sbin/load_policy: Warning! Error while setting booleans: Invalid argument touch tmp/load # What else should I do? or just leave it as is? Thanks! Hongwei From hongwei at wustl.edu Fri Jul 8 21:40:54 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 8 Jul 2005 16:40:54 -0500 (CDT) Subject: policy updated, then selinux error? In-Reply-To: <4017.128.252.85.103.1120857320.squirrel@morpheus.wustl.edu> References: <2581.128.252.85.103.1120852164.squirrel@morpheus.wustl.edu> <1120855430.15736.300.camel@laurel.intra.city-fan.org> <4017.128.252.85.103.1120857320.squirrel@morpheus.wustl.edu> Message-ID: <4564.128.252.85.103.1120858854.squirrel@morpheus.wustl.edu> >> On Fri, 2005-07-08 at 14:49 -0500, Hongwei Li wrote: >>> Hi, >>> >>> I just updated selinux target policy (including the source) from >>> 1.17.30-2.96 >>> to 1.17.30-3.16 on my fc3 linux system (kernel 2.6.11-1.35_FC3), and also >>> updated checkpolicy-1.17.5-1.2. The updating process did not show any >>> error. >>> >>> Then, I reboot the system that showed a lot of error message like: >>> invalid ... in /etc/selinux/targeted/src/policy/file_contexts/... (it went >>> though so fast that I could not catch all the words). The system is >>> running, >>> then I go to /etc/selinux/targeted/src/policy and run make load and got: >>> >>> # make load >>> mkdir -p /etc/selinux/targeted/policy >>> /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf >>> /usr/bin/checkpolicy: loading policy configuration from policy.conf >>> domains/unconfined.te:19:ERROR 'syntax error' at token '{' on line 3897: >>> typealias unconfined_t alias { kernel_t init_t initrc_t logrotate_t >>> sendmail_t >>> sshd_t secadm_t sysadm_t rpm_t rpm_script_t xdm_t }; >>> typeattribute tty_device_t { tty_device_t devpts_t }; >>> /usr/bin/checkpolicy: error(s) encountered while parsing configuration >>> make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 >>> >>> I tried touch /.autorelable and reboot, the same error. >>> >>> Can somebody tell what's wrong? how to fix it? >> >> # cd /etc/selinux/targeted/src/policy >> # rm -f policy.conf >> # make reload >> >> Paul. >> -- >> Paul Howarth >> > > I got: > > # make reload > mkdir -p tmp > m4 -Imacros -s flask/security_classes ...... > ...... > mv policy.conf.tmp policy.conf > mkdir -p /etc/selinux/targeted/policy > /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > security: 3 users, 4 roles, 343 types, 30 bools > security: 55 classes, 14894 rules > /usr/bin/checkpolicy: policy configuration loaded > /usr/bin/checkpolicy: writing binary representation (version 18) to > /etc/selinux/targeted/policy/policy.18 > /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 > unknown boolean use_syslogng > /usr/sbin/load_policy: Warning! Error while setting booleans: Invalid > argument > touch tmp/load > # > > What else should I do? or just leave it as is? > > Thanks! > > Hongwei > > I rebooted the system, and run make load again. No error message, it seems working normal. Thanks! Hongwei From kwade at redhat.com Sat Jul 9 00:30:24 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 08 Jul 2005 17:30:24 -0700 Subject: the labeling procedure In-Reply-To: <60D45469A1AAD311A04C009027B6BF68059142AC@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF68059142AC@server20.inside.oracorp.com> Message-ID: <1120869025.5937.246.camel@erato.phig.org> On Mon, 2005-06-27 at 13:35 -0400, Steve Brueckner wrote: > Aha, I think the O'Reilly book is just out of date. Not surprising > considering the moving target that is SELinux. Unfortunately it was somewhat out of date when it was published. It is based on FC2, which has a different architecture than FC3/FC4. For FC3, the Red Hat SELinux Guide[1] is a fairly good reference choice. Note that it matches FC3 as released, not with updates, so there is a difference for FC3 current. There is going to be another correlation between FC releases and the RHEL documentation on SELinux, whenever that occurs. :) - Karsten [1] http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From netdxr at gmail.com Sat Jul 9 00:59:11 2005 From: netdxr at gmail.com (Tom Lisjac) Date: Fri, 8 Jul 2005 18:59:11 -0600 Subject: FC4 Samba AD authentication fails... Message-ID: <863ff45205070817595ece2870@mail.gmail.com> Setting up samba-3.0.14a-2 under FC4 for AD authentication produces the following errors with selinux-policy-targeted-1.24-3. Should these reports be posted in bugzilla rather then here? -Tom ------------------------------------------ type=AVC msg=audit(1120802622.535:235021): avc: denied { getattr } for pid=3163 comm="smbd" name="winbindd" dev=hda2 ino=1045907 scontext=root:system_r:smbd_t tcontext=system_u:object_r:winbind_var_run_t tclass=dir type=AVC msg=audit(1120802623.036:236399): avc: denied { name_connect } for pid=3164 comm="smbd" dest=389 scontext=root:system_r:smbd_t type=AVC msg=audit(1120802682.605:241497): avc: denied { search } for pid=3175 comm="winbindd" name="tmp" dev=hda2 ino=3463233 scontext=root:system_r:winbind_t tcontext=system_u:object_r:tmp_t tclass=dir type=AVC msg=audit(1120802682.637:241645): avc: denied { name_connect } for pid=3175 comm="winbindd" dest=389 scontext=root:system_r:winbind_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket From mattdm at mattdm.org Sat Jul 9 13:42:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 9 Jul 2005 09:42:59 -0400 Subject: Fedora 3 and SELinux In-Reply-To: <20050709074322.24839.qmail@web8608.mail.in.yahoo.com> References: <20050708122106.GA16548@jadzia.bu.edu> <20050709074322.24839.qmail@web8608.mail.in.yahoo.com> Message-ID: <20050709134259.GA29789@jadzia.bu.edu> On Sat, Jul 09, 2005 at 08:43:22AM +0100, Preeti Malakar wrote: > the SE Linux commans such as show_bools is missing and also there are no .te files and .fc files , Can you please help show_bools is getsebool in newer SE linux, and the policy sources are in selinux-policy-targeted-sources. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From findpreeti at gmail.com Sun Jul 10 12:54:19 2005 From: findpreeti at gmail.com (Preeti Malakar) Date: Sun, 10 Jul 2005 18:24:19 +0530 Subject: fedora 2 and SELinux Message-ID: Sir, When I installed fedora2 without selinux support, it installed properly, but with linux selinux at the boot prompt , the graphical display is not coming, a modal window displays that "gnome-daemon-settings quitted unexpectedly" and is in hung state .... however I can log into text mode, and i saw in /var/log/mesages many audit denial mesages for gnome session by SELinux such as avc : denied { write } for pid=3129 exe=/usr/bin/gnome-session name=linc-a6c-0-c66f92clble9 dev=sda8 ino=4080019 scontext=root:staff_r:staff_t tcontext=system_u:object_r:tmp_t tclass=sock_file what should i do? thanking you Preeti Malakar MTech CSE From drn_temp2 at rogers.com Sun Jul 10 16:15:39 2005 From: drn_temp2 at rogers.com (David Niemi) Date: Sun, 10 Jul 2005 12:15:39 -0400 Subject: seLinux, Squid and adzap Message-ID: <1121012139.32622.15.camel@Jenny> I am trying to get squid to run as an accelerator and also do ad zapping with Cameron Simpson's AdZap routine. I am getting lots of SELinux errors for the zapping script to be run by squid and also that squid do something with swap.state and swap log setting the SELinux protection off for squid still results in the error about the swap.state and swap log. so it seems that I need to change something with the SELinux context for squid and the adzap scripts but have no real idea how to go about. I tried relabeling but that didn't do it. What can I do to remedy this? from messages Jul 10 11:33:08 rhonda ntpd[2467]: frequency initialized -12.030 PPM from /var/lib/ntp/drift Jul 10 11:33:08 rhonda squid[2519]: Squid Parent: child process 2522 started Jul 10 11:33:09 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open swap log. Jul 10 11:33:09 rhonda squid[2519]: Squid Parent: child process 2522 exited due to signal 6 Jul 10 11:33:12 rhonda squid[2519]: Squid Parent: child process 2533 started Jul 10 11:33:12 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open swap log. Jul 10 11:33:12 rhonda squid[2519]: Squid Parent: child process 2533 exited due to signal 6 Jul 10 11:33:15 rhonda squid[2519]: Squid Parent: child process 2544 started Jul 10 11:33:15 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open swap log. Jul 10 11:33:15 rhonda squid[2519]: Squid Parent: child process 2544 exited due to signal 6 Jul 10 11:33:18 rhonda squid[2519]: Squid Parent: child process 2555 started Jul 10 11:33:18 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open swap log. Jul 10 11:33:18 rhonda squid[2519]: Squid Parent: child process 2555 exited due to signal 6 Jul 10 11:33:21 rhonda squid[2519]: Squid Parent: child process 2569 started Jul 10 11:33:22 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open swap log. Jul 10 11:33:22 rhonda squid[2519]: Squid Parent: child process 2569 exited due to signal 6 Jul 10 11:33:22 rhonda squid[2519]: Exiting due to repeated, frequent failures from audit type=SYSCALL msg=audit(1121009601.928:43072): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" type=AVC msg=audit(1121009601.928:43072): avc: denied { name_connect } for pid=2569 comm="squid" dest=32811 scontext=system_u:system_r:squid_t tcontext=system_u:object_r:port_t tclass=tcp_socket type=SOCKETCALL msg=audit(1121009601.929:43096): nargs=3 a0=7 a1=bfcc06ec a2=10 type=SOCKADDR msg=audit(1121009601.929:43096): saddr=0200802D7F0000010000000000000000 type=SYSCALL msg=audit(1121009601.929:43096): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" type=AVC msg=audit(1121009601.929:43096): avc: denied { name_connect } for pid=2569 comm="squid" dest=32813 scontext=system_u:system_r:squid_t tcontext=system_u:object_r:port_t tclass=tcp_socket type=SOCKETCALL msg=audit(1121009601.930:43120): nargs=3 a0=7 a1=bfcc06ec a2=10 type=SOCKADDR msg=audit(1121009601.930:43120): saddr=0200802F7F0000010000000000000000 type=SYSCALL msg=audit(1121009601.930:43120): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" type=AVC msg=audit(1121009601.930:43120): avc: denied { name_connect } for pid=2569 comm="squid" dest=32815 scontext=system_u:system_r:squid_t tcontext=system_u:object_r:port_t tclass=tcp_socket type=SOCKETCALL msg=audit(1121009601.930:43144): nargs=3 a0=7 a1=bfcc06ec a2=10 type=SOCKADDR msg=audit(1121009601.930:43144): saddr=020080317F0000010000000000000000 type=SYSCALL msg=audit(1121009601.930:43144): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" type=AVC msg=audit(1121009601.930:43144): avc: denied { name_connect } for pid=2569 comm="squid" dest=32817 scontext=system_u:system_r:squid_t tcontext=system_u:object_r:port_t tclass=tcp_socket from cache.log 2005/07/10 11:33:21| Starting Squid Cache version 2.5.STABLE9 for i386-redhat-linux-gnu... 2005/07/10 11:33:21| Process ID 2569 2005/07/10 11:33:21| With 1024 file descriptors available 2005/07/10 11:33:21| DNS Socket created at 0.0.0.0, port 32775, FD 5 2005/07/10 11:33:21| Adding nameserver 24.153.22.67 from /etc/resolv.conf 2005/07/10 11:33:21| Adding nameserver 24.153.23.66 from /etc/resolv.conf 2005/07/10 11:33:21| helperOpenServers: Starting 5 'squid_redirect' processes 2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' process. 2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' process. 2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' process. 2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' process. 2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' process. 2005/07/10 11:33:21| User-Agent logging is disabled. 2005/07/10 11:33:21| Referer logging is disabled. 2005/07/10 11:33:21| Unlinkd pipe opened on FD 10 2005/07/10 11:33:21| Swap maxSize 102400 KB, estimated 7876 objects 2005/07/10 11:33:21| Target number of buckets: 393 2005/07/10 11:33:21| Using 8192 Store buckets 2005/07/10 11:33:21| Max Mem size: 8192 KB 2005/07/10 11:33:21| Max Swap size: 102400 KB 2005/07/10 11:33:21| /var/spool/squid/swap.state: (13) Permission denied FATAL: storeUfsDirOpenSwapLog: Failed to open swap log. Squid Cache (Version 2.5.STABLE9): Terminated abnormally. CPU Usage: 0.019 seconds = 0.006 user + 0.013 sys Maximum Resident Size: 0 KB Page faults with physical i/o: 0 from squid.out squid: ERROR: Could not send signal 0 to process 31876: (3) No such process /var/spool/ drwxr-x--- squid squid system_u:object_r:squid_cache_t squid /usr/local/bin/ [root at rhonda bin]# ls -alZ drwxr-xr-x root root system_u:object_r:bin_t . drwxr-xr-x root root system_u:object_r:usr_t .. -rwxr-xr-x root root system_u:object_r:bin_t squid_redirect -rwxr-xr-x root root system_u:object_r:bin_t wrapzap From paul.lacatus at emon.ro Sun Jul 10 16:37:32 2005 From: paul.lacatus at emon.ro (Paul Lacatus) Date: Sun, 10 Jul 2005 19:37:32 +0300 Subject: Selinux and bluetooth Message-ID: <42D14ECC.6000309@emon.ro> I just installed FC4 on a laptop . Fresh install not upgrade. I was trying to start my GPRS connection over bluetooth as I did in FC3. The bluetooth service does not seem like working. Looking in the logs ( messages) I found: Jul 9 23:56:02 fujitsu1020 hcid[3934]: Bluetooth HCI daemon Jul 9 23:56:02 fujitsu1020 hcid[3934]: Can not open /etc/bluetooth/hcid.conf Jul 9 23:56:02 fujitsu1020 hcid[3934]: Config load failed Jul 9 23:56:02 fujitsu1020 hcid[3934]: Can't open PIN file /etc/bluetooth/pin: Permission denied (13) Jul 9 23:56:02 fujitsu1020 sdpd[3936]: Bluetooth SDP daemon All this files exist, have 644 permissions and corect in format since I start hcid and run "rfcomm bind all" by hand the bluetooth connection start working. The problem is selinux since I modify to "permissive" all is working as expected. In "enforcing" is not working anymore. I think that selinux is preventing access to configuration files. I have all updates to the day. Paul From eparis at redhat.com Sun Jul 10 16:54:52 2005 From: eparis at redhat.com (Eric Paris) Date: Sun, 10 Jul 2005 12:54:52 -0400 Subject: Selinux and bluetooth In-Reply-To: <42D14ECC.6000309@emon.ro> References: <42D14ECC.6000309@emon.ro> Message-ID: <1121014492.28208.0.camel@localhost.localdomain> What do you have in /var/log/audit/audit.log when you got the failure? -Eric On Sun, 2005-07-10 at 19:37 +0300, Paul Lacatus wrote: > I just installed FC4 on a laptop . Fresh install not upgrade. I was > trying to start my GPRS connection over bluetooth as I did in FC3. The > bluetooth service does not seem like working. Looking in the logs ( > messages) I found: > > Jul 9 23:56:02 fujitsu1020 hcid[3934]: Bluetooth HCI daemon > Jul 9 23:56:02 fujitsu1020 hcid[3934]: Can not open > /etc/bluetooth/hcid.conf > Jul 9 23:56:02 fujitsu1020 hcid[3934]: Config load failed > Jul 9 23:56:02 fujitsu1020 hcid[3934]: Can't open PIN file > /etc/bluetooth/pin: Permission denied (13) > Jul 9 23:56:02 fujitsu1020 sdpd[3936]: Bluetooth SDP daemon > > All this files exist, have 644 permissions and corect in format since I start hcid and run "rfcomm bind all" by hand the bluetooth connection start working. > > The problem is selinux since I modify to "permissive" all is working as expected. In "enforcing" is not working anymore. I think that selinux is preventing access to configuration files. I have all updates to the day. > > Paul > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul.lacatus at emon.ro Sun Jul 10 18:09:14 2005 From: paul.lacatus at emon.ro (Paul Lacatus) Date: Sun, 10 Jul 2005 21:09:14 +0300 Subject: Selinux and bluetooth In-Reply-To: <1121014492.28208.0.camel@localhost.localdomain> References: <42D14ECC.6000309@emon.ro> <1121014492.28208.0.camel@localhost.localdomain> Message-ID: <42D1644A.2040103@emon.ro> Eric Paris wrote: > What do you have in /var/log/audit/audit.log when you got the failure? > > > I think that a interesting part of the log is folowing. You can see the "denied {read}" . If you need some more informations from the log I can send you the complete log. Is only 90KB. PL. type=PATH msg=audit(1120937471.981:9226823): item=0 name="/etc/bluetooth/hcid.conf" inode=69410 dev=03:05 mode=0100644 ouid=0 ogid=0 rdev=00:00 type=SYSCALL msg=audit(1120937471.981:9226823): arch=40000003 syscall=5 success=no exit=-13 a0=5a4211 a1=0 a2=1b6 a3=9bd1130 items=1 pid=11886 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hcid" exe="/usr/sbin/hcid" type=PATH msg=audit(1120937471.994:9227122): item=0 name="/etc/bluetooth/pin" inode=69411 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=0 0:00 type=SYSCALL msg=audit(1120937471.994:9227122): arch=40000003 syscall=5 success=no exit=-13 a0=9bd1018 a1=0 a2=1b6 a3=9bd2e60 items=1 pid=11886 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hcid" exe="/usr/sbin/hcid" type=AVC msg=audit(1120937471.994:9227122): avc: denied { read } for pid=11886 comm="hcid" name=pin dev=hda5 ino=69411 scontext=ro ot:system_r:bluetooth_t tcontext=root:object_r:etc_t tclass=file type=AVC msg=audit(1120937471.981:9226823): avc: denied { read } for pid=11886 comm="hcid" name=hcid.conf dev=hda5 ino=69410 scont ext=root:system_r:bluetooth_t tcontext=root:object_r:etc_t tclass=file type=PATH msg=audit(1120937472.107:9227750): item=0 name="/etc/bluetooth/rfcomm.conf" inode=69413 dev=03:05 mode=0100644 ouid=0 ogid= 0 rdev=00:00 type=SYSCALL msg=audit(1120937472.107:9227750): arch=40000003 syscall=5 success=no exit=-13 a0=bfd26655 a1=0 a2=1b6 a3=8ad9008 items= 1 pid=11893 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="rfcomm" exe="/usr/bin/rfcomm" type=AVC msg=audit(1120937472.107:9227750): avc: denied { read } for pid=11893 comm="rfcomm" name=rfcomm.conf dev=hda5 ino=69413 s context=root:system_r:bluetooth_t tcontext=root:object_r:etc_t tclass=file type=AVC_PATH msg=audit(1120938151.449:14857979): path="socket:[76227]" type=SYSCALL msg=audit(1120938151.449:14857979): arch=40000003 syscall=3 success=no exit=-13 a0=4 a1=bfc2ecc8 a2=404 a3=404 items=0 p id=11886 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hcid" exe="/usr/sbin/hcid" type=AVC msg=audit(1120938151.449:14857979): avc: denied { read } for pid=11886 comm="hcid" name=[76227] dev=sockfs ino=76227 scon text=root:system_r:bluetooth_t tcontext=root:system_r:bluetooth_t tclass=socket : From tim_kossack at web.de Mon Jul 11 04:22:12 2005 From: tim_kossack at web.de (tim kossack) Date: Sun, 10 Jul 2005 21:22:12 -0700 Subject: problems switching from targeted to strict policy... Message-ID: <1121055732.4282.20.camel@tk1.tim-kossack.homelinux.org> hi, i just installed fc3 (with selinux=permissive and configuration=minimal) in order to get familiar with selinux. after updating the system and installing the strict-policy as well as the strict and targeted sources via yum, i edited /etc/selinux/config to "strict" and rebooted. since then, during boot, i'm getting flodded with "avc denied" for nearly every service (didn't happen while i had "targeted" enabled), even when i login. i tried to fix it with executing "make load/reload/relabel" in the strict-src-directory, but that doesn't work. after second glance at the selinux-faq i discovered that i forgot to do "touch/.autorelabel" before first reboot. did this cause my problems, or is it a problem with the strict policy itself? how do i fix it (if still possible)? thx! From tim_kossack at web.de Mon Jul 11 04:44:49 2005 From: tim_kossack at web.de (tim kossack) Date: Sun, 10 Jul 2005 21:44:49 -0700 Subject: problems switching from targeted to strict policy... In-Reply-To: <1121055732.4282.20.camel@tk1.tim-kossack.homelinux.org> References: <1121055732.4282.20.camel@tk1.tim-kossack.homelinux.org> Message-ID: <1121057090.4282.26.camel@tk1.tim-kossack.homelinux.org> On Sun, 2005-07-10 at 21:22 -0700, tim kossack wrote: [snip] > i tried to fix it with executing "make load/reload/relabel" in the > strict-src-directory, but that doesn't work. [/snip] tried it in /etc/selinux/strict/src/policy/, of course. From dwalsh at redhat.com Mon Jul 11 12:58:22 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Jul 2005 08:58:22 -0400 Subject: fedora 2 and SELinux In-Reply-To: References: Message-ID: <42D26CEE.80809@redhat.com> Preeti Malakar wrote: >Sir, > When I installed fedora2 without selinux support, it installed >properly, but with linux selinux at the boot prompt , the graphical >display is not coming, a modal window displays that >"gnome-daemon-settings quitted unexpectedly" and is in hung state >.... however I can log into text mode, and i saw in /var/log/mesages >many audit denial mesages for gnome session by SELinux such as >avc : denied { write } for pid=3129 exe=/usr/bin/gnome-session >name=linc-a6c-0-c66f92clble9 dev=sda8 ino=4080019 >scontext=root:staff_r:staff_t tcontext=system_u:object_r:tmp_t >tclass=sock_file > >what should i do? > > > >thanking you >Preeti Malakar >MTech CSE > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Use Fedora 3 or Fedora 4. The SELinux support in Fedora 2 is not very good. -- From dwalsh at redhat.com Mon Jul 11 12:59:50 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Jul 2005 08:59:50 -0400 Subject: problems switching from targeted to strict policy... In-Reply-To: <1121057090.4282.26.camel@tk1.tim-kossack.homelinux.org> References: <1121055732.4282.20.camel@tk1.tim-kossack.homelinux.org> <1121057090.4282.26.camel@tk1.tim-kossack.homelinux.org> Message-ID: <42D26D46.7050103@redhat.com> tim kossack wrote: >On Sun, 2005-07-10 at 21:22 -0700, tim kossack wrote: >[snip] > > >>i tried to fix it with executing "make load/reload/relabel" in the >>strict-src-directory, but that doesn't work. >> >> >[/snip] > >tried it in /etc/selinux/strict/src/policy/, of course. > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Update to the latest strict policy from the devel branch. Dan -- From dwalsh at redhat.com Mon Jul 11 13:06:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Jul 2005 09:06:13 -0400 Subject: Selinux and bluetooth In-Reply-To: <42D1644A.2040103@emon.ro> References: <42D14ECC.6000309@emon.ro> <1121014492.28208.0.camel@localhost.localdomain> <42D1644A.2040103@emon.ro> Message-ID: <42D26EC5.6030908@redhat.com> Paul Lacatus wrote: > Eric Paris wrote: > >> What do you have in /var/log/audit/audit.log when you got the failure? >> >> >> > I think that a interesting part of the log is folowing. You can see > the "denied {read}" . If you need some more informations from the log > I can send you the complete log. Is only 90KB. > > PL. > > > > type=PATH msg=audit(1120937471.981:9226823): item=0 > name="/etc/bluetooth/hcid.conf" inode=69410 dev=03:05 mode=0100644 > ouid=0 ogid=0 > rdev=00:00 > type=SYSCALL msg=audit(1120937471.981:9226823): arch=40000003 > syscall=5 success=no exit=-13 a0=5a4211 a1=0 a2=1b6 a3=9bd1130 items=1 > pid=11886 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="hcid" exe="/usr/sbin/hcid" > type=PATH msg=audit(1120937471.994:9227122): item=0 > name="/etc/bluetooth/pin" inode=69411 dev=03:05 mode=0100600 ouid=0 > ogid=0 rdev=0 > 0:00 > type=SYSCALL msg=audit(1120937471.994:9227122): arch=40000003 > syscall=5 success=no exit=-13 a0=9bd1018 a1=0 a2=1b6 a3=9bd2e60 items=1 > pid=11886 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="hcid" exe="/usr/sbin/hcid" > type=AVC msg=audit(1120937471.994:9227122): avc: denied { read } > for pid=11886 comm="hcid" name=pin dev=hda5 ino=69411 scontext=ro > ot:system_r:bluetooth_t tcontext=root:object_r:etc_t tclass=file > type=AVC msg=audit(1120937471.981:9226823): avc: denied { read } > for pid=11886 comm="hcid" name=hcid.conf dev=hda5 ino=69410 scont > ext=root:system_r:bluetooth_t tcontext=root:object_r:etc_t tclass=file > type=PATH msg=audit(1120937472.107:9227750): item=0 > name="/etc/bluetooth/rfcomm.conf" inode=69413 dev=03:05 mode=0100644 > ouid=0 ogid= > 0 rdev=00:00 > type=SYSCALL msg=audit(1120937472.107:9227750): arch=40000003 > syscall=5 success=no exit=-13 a0=bfd26655 a1=0 a2=1b6 a3=8ad9008 items= > 1 pid=11893 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="rfcomm" exe="/usr/bin/rfcomm" > type=AVC msg=audit(1120937472.107:9227750): avc: denied { read } > for pid=11893 comm="rfcomm" name=rfcomm.conf dev=hda5 ino=69413 s > context=root:system_r:bluetooth_t tcontext=root:object_r:etc_t > tclass=file > type=AVC_PATH msg=audit(1120938151.449:14857979): path="socket:[76227]" > type=SYSCALL msg=audit(1120938151.449:14857979): arch=40000003 > syscall=3 success=no exit=-13 a0=4 a1=bfc2ecc8 a2=404 a3=404 items=0 p > id=11886 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="hcid" exe="/usr/sbin/hcid" > type=AVC msg=audit(1120938151.449:14857979): avc: denied { read } > for pid=11886 comm="hcid" name=[76227] dev=sockfs ino=76227 scon > text=root:system_r:bluetooth_t tcontext=root:system_r:bluetooth_t > tclass=socket > : > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list First off you need to relabel your etc directory restorecon -R -v /etc Also what version of policy are you running? rpm -q selinux-policy-targeted -- From dwalsh at redhat.com Mon Jul 11 13:09:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Jul 2005 09:09:08 -0400 Subject: seLinux, Squid and adzap In-Reply-To: <1121012139.32622.15.camel@Jenny> References: <1121012139.32622.15.camel@Jenny> Message-ID: <42D26F74.1050508@redhat.com> David Niemi wrote: >I am trying to get squid to run as an accelerator and also do ad zapping >with Cameron Simpson's AdZap routine. I am getting lots of SELinux >errors for the zapping script to be run by squid and also that squid do >something with swap.state and swap log > >setting the SELinux protection off for squid still results in the error >about the swap.state and swap log. > >so it seems that I need to change something with the SELinux context for >squid and the adzap scripts but have no real idea how to go about. I >tried relabeling but that didn't do it. > >What can I do to remedy this? > >from messages >Jul 10 11:33:08 rhonda ntpd[2467]: frequency initialized -12.030 PPM >from /var/lib/ntp/drift >Jul 10 11:33:08 rhonda squid[2519]: Squid Parent: child process 2522 >started >Jul 10 11:33:09 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open >swap log. >Jul 10 11:33:09 rhonda squid[2519]: Squid Parent: child process 2522 >exited due to signal 6 >Jul 10 11:33:12 rhonda squid[2519]: Squid Parent: child process 2533 >started >Jul 10 11:33:12 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open >swap log. >Jul 10 11:33:12 rhonda squid[2519]: Squid Parent: child process 2533 >exited due to signal 6 >Jul 10 11:33:15 rhonda squid[2519]: Squid Parent: child process 2544 >started >Jul 10 11:33:15 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open >swap log. >Jul 10 11:33:15 rhonda squid[2519]: Squid Parent: child process 2544 >exited due to signal 6 >Jul 10 11:33:18 rhonda squid[2519]: Squid Parent: child process 2555 >started >Jul 10 11:33:18 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open >swap log. >Jul 10 11:33:18 rhonda squid[2519]: Squid Parent: child process 2555 >exited due to signal 6 >Jul 10 11:33:21 rhonda squid[2519]: Squid Parent: child process 2569 >started >Jul 10 11:33:22 rhonda (squid): storeUfsDirOpenSwapLog: Failed to open >swap log. >Jul 10 11:33:22 rhonda squid[2519]: Squid Parent: child process 2569 >exited due to signal 6 >Jul 10 11:33:22 rhonda squid[2519]: Exiting due to repeated, frequent >failures > >from audit >type=SYSCALL msg=audit(1121009601.928:43072): arch=40000003 syscall=102 >success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 >pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 >sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" >type=AVC msg=audit(1121009601.928:43072): avc: denied { name_connect } >for pid=2569 comm="squid" dest=32811 scontext=system_u:system_r:squid_t >tcontext=system_u:object_r:port_t tclass=tcp_socket >type=SOCKETCALL msg=audit(1121009601.929:43096): nargs=3 a0=7 >a1=bfcc06ec a2=10 >type=SOCKADDR msg=audit(1121009601.929:43096): >saddr=0200802D7F0000010000000000000000 >type=SYSCALL msg=audit(1121009601.929:43096): arch=40000003 syscall=102 >success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 >pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 >sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" >type=AVC msg=audit(1121009601.929:43096): avc: denied { name_connect } >for pid=2569 comm="squid" dest=32813 scontext=system_u:system_r:squid_t >tcontext=system_u:object_r:port_t tclass=tcp_socket >type=SOCKETCALL msg=audit(1121009601.930:43120): nargs=3 a0=7 >a1=bfcc06ec a2=10 >type=SOCKADDR msg=audit(1121009601.930:43120): >saddr=0200802F7F0000010000000000000000 >type=SYSCALL msg=audit(1121009601.930:43120): arch=40000003 syscall=102 >success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 >pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 >sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" >type=AVC msg=audit(1121009601.930:43120): avc: denied { name_connect } >for pid=2569 comm="squid" dest=32815 scontext=system_u:system_r:squid_t >tcontext=system_u:object_r:port_t tclass=tcp_socket >type=SOCKETCALL msg=audit(1121009601.930:43144): nargs=3 a0=7 >a1=bfcc06ec a2=10 >type=SOCKADDR msg=audit(1121009601.930:43144): >saddr=020080317F0000010000000000000000 >type=SYSCALL msg=audit(1121009601.930:43144): arch=40000003 syscall=102 >success=no exit=-13 a0=3 a1=bfcc0670 a2=2318d0 a3=b7fb36a0 items=0 >pid=2569 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 >sgid=23 fsgid=23 comm="squid" exe="/usr/sbin/squid" >type=AVC msg=audit(1121009601.930:43144): avc: denied { name_connect } >for pid=2569 comm="squid" dest=32817 scontext=system_u:system_r:squid_t >tcontext=system_u:object_r:port_t tclass=tcp_socket > >from cache.log >2005/07/10 11:33:21| Starting Squid Cache version 2.5.STABLE9 for >i386-redhat-linux-gnu... >2005/07/10 11:33:21| Process ID 2569 >2005/07/10 11:33:21| With 1024 file descriptors available >2005/07/10 11:33:21| DNS Socket created at 0.0.0.0, port 32775, FD 5 >2005/07/10 11:33:21| Adding nameserver 24.153.22.67 >from /etc/resolv.conf >2005/07/10 11:33:21| Adding nameserver 24.153.23.66 >from /etc/resolv.conf >2005/07/10 11:33:21| helperOpenServers: Starting 5 'squid_redirect' >processes >2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' >process. >2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' >process. >2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' >process. >2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' >process. >2005/07/10 11:33:21| WARNING: Cannot run '/usr/local/bin/squid_redirect' >process. >2005/07/10 11:33:21| User-Agent logging is disabled. >2005/07/10 11:33:21| Referer logging is disabled. >2005/07/10 11:33:21| Unlinkd pipe opened on FD 10 >2005/07/10 11:33:21| Swap maxSize 102400 KB, estimated 7876 objects >2005/07/10 11:33:21| Target number of buckets: 393 >2005/07/10 11:33:21| Using 8192 Store buckets >2005/07/10 11:33:21| Max Mem size: 8192 KB >2005/07/10 11:33:21| Max Swap size: 102400 KB >2005/07/10 11:33:21| /var/spool/squid/swap.state: (13) Permission denied >FATAL: storeUfsDirOpenSwapLog: Failed to open swap log. >Squid Cache (Version 2.5.STABLE9): Terminated abnormally. >CPU Usage: 0.019 seconds = 0.006 user + 0.013 sys >Maximum Resident Size: 0 KB >Page faults with physical i/o: 0 > >from squid.out >squid: ERROR: Could not send signal 0 to process 31876: (3) No such >process > >/var/spool/ >drwxr-x--- squid squid system_u:object_r:squid_cache_t squid > >/usr/local/bin/ >[root at rhonda bin]# ls -alZ >drwxr-xr-x root root system_u:object_r:bin_t . >drwxr-xr-x root root system_u:object_r:usr_t .. >-rwxr-xr-x root root system_u:object_r:bin_t >squid_redirect >-rwxr-xr-x root root system_u:object_r:bin_t wrapzap > > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Turn on boolean squid_connect_any setsebool -P squid_connect_any=1 -- From paul.lacatus at emon.ro Mon Jul 11 13:24:54 2005 From: paul.lacatus at emon.ro (Paul Lacatus) Date: Mon, 11 Jul 2005 16:24:54 +0300 Subject: Selinux and bluetooth In-Reply-To: <42D26EC5.6030908@redhat.com> References: <42D14ECC.6000309@emon.ro> <1121014492.28208.0.camel@localhost.localdomain> <42D1644A.2040103@emon.ro> <42D26EC5.6030908@redhat.com> Message-ID: <42D27326.4000605@emon.ro> Daniel J Walsh wrote: > > First off you need to relabel your etc directory > > restorecon -R -v /etc > > Also what version of policy are you running? > > rpm -q selinux-policy-targeted > > > selinux-policy-targeted-1.24-3 > From dwalsh at redhat.com Mon Jul 11 15:26:00 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Jul 2005 11:26:00 -0400 Subject: Selinux and bluetooth In-Reply-To: <42D27326.4000605@emon.ro> References: <42D14ECC.6000309@emon.ro> <1121014492.28208.0.camel@localhost.localdomain> <42D1644A.2040103@emon.ro> <42D26EC5.6030908@redhat.com> <42D27326.4000605@emon.ro> Message-ID: <42D28F88.50206@redhat.com> Paul Lacatus wrote: > Daniel J Walsh wrote: > >> >> First off you need to relabel your etc directory >> >> restorecon -R -v /etc >> >> Also what version of policy are you running? >> >> rpm -q selinux-policy-targeted >> >> >> selinux-policy-targeted-1.24-3 >> > > Try selinux-policy-targeted-1.25.1-7 ftp://people.redhat.com/dwalsh/SELinux/FC4 -- From dax at gurulabs.com Mon Jul 11 21:35:41 2005 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 11 Jul 2005 15:35:41 -0600 Subject: Should file permissions match SELinux policy? Message-ID: <1121117742.3325.39.camel@mentorng.gurulabs.com> I was porting some DNS courseware lab exercises to RHEL4 and FC3/4 and the following came up. In the file: /etc/selinux/targeted/src/policy/domains/program/named.te There exists policy so that only "named" can read named configuration files. # A type for configuration files of named. type named_conf_t, file_type, sysadmfile; [snip] #read configuration files r_dir_file(named_t, named_conf_t) This is fine and works. The question comes then that the standard file owner and group and permission are more open (and have been historically). -rw-r--r-- 1 root root 1323 Aug 25 2004 /etc/named.conf Should the owner and group and permissions be made to match up with the SELinux policy? ie: chgrp named /etc/named.conf chmod 640 /etc/named.conf ala -rw-r----- 1 root named 1323 Aug 25 2004 /etc/named.conf How about this same question at a more general level. What is the current practice regarding syncing up and matching SELinux policy with the file owner/group and permissions? Is there a current defined practice? If not, should there be? :) Dax Kelson Guru Labs From obi at unixkiste.org Mon Jul 11 23:41:53 2005 From: obi at unixkiste.org (Stefan Held) Date: Tue, 12 Jul 2005 01:41:53 +0200 Subject: Abnormal Apache behavior. In-Reply-To: <20050708131558.GA22850@redhat.com> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> <1120618035.29103.5.camel@nexus.verbum.private> <20050708131558.GA22850@redhat.com> Message-ID: <1121125313.8072.1.camel@lt-sh.intern.pcservice.de> Am Freitag, den 08.07.2005, 14:15 +0100 schrieb Joe Orton: [root at extranet ~]# service httpd restart httpd beenden: [ OK ] httpd starten: [ OK ] [root at extranet ~]# ps auxZ | grep httpd root:system_r:httpd_t root 25934 2.9 0.4 19080 9252 ? Ss 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25936 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25937 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25938 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25939 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd [root at extranet ~]# apachectl stop [root at extranet ~]# apachectl start [root at extranet ~]# ps auxZ | grep httpd root:system_r:unconfined_t root 25956 14.3 0.4 21160 9244 ? Ss 01:40 0:00 /usr/sbin/httpd -k start root:system_r:unconfined_t apache 25957 0.0 0.4 21292 9264 ? S 01:40 0:00 /usr/sbin/httpd -k start root:system_r:unconfined_t apache 25958 0.0 0.4 21292 9264 ? S 01:40 0:00 /usr/sbin/httpd -k start root:system_r:unconfined_t apache 25959 0.0 0.4 21292 9264 ? S 01:40 0:00 /usr/sbin/httpd -k start -- Stefan Held VI has only 2 Modes: obi at unixkiste.org The first one is for beeping all the time, IRCNet: Obi_Wan the second destroys the text. --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = EAF2 6A65 D102 F2DB 4970 2A67 455B 98F2 572C 3FA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From byronkeys at inxpress.net Tue Jul 12 01:14:04 2005 From: byronkeys at inxpress.net (Brian) Date: Mon, 11 Jul 2005 20:14:04 -0500 Subject: soundcards, anyone? Message-ID: <42D3195C.9090503@inxpress.net> Hello: A book I am reading suggests that to find out what soundcards are well-supported for Fedora and Red Hat Enterprise, to visit "http://www.hardware.redhat.com". An interesting site, to be sure, but it does not offer the list I would like to see. Does anyone know of such a list? Brian From cra at WPI.EDU Tue Jul 12 02:33:32 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 11 Jul 2005 22:33:32 -0400 Subject: soundcards, anyone? In-Reply-To: <42D3195C.9090503@inxpress.net> References: <42D3195C.9090503@inxpress.net> Message-ID: <20050712023332.GB9759@angus.ind.WPI.EDU> On Mon, Jul 11, 2005 at 08:14:04PM -0500, Brian wrote: > A book I am reading suggests that to find out what soundcards are > well-supported for Fedora and Red Hat Enterprise, to visit > "http://www.hardware.redhat.com". An interesting site, to be sure, but > it does not offer the list I would like to see. Does anyone know of such > a list? 1. You sent this request to the wrong mailing list. fedora-list is the proper list for such questions. This list is for discussion on the Security Enhanced Linux component of Fedora. 2. See http://www.alsa-project.org/ for supported soundcard hardware. From russell at coker.com.au Tue Jul 12 12:59:37 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 12 Jul 2005 22:59:37 +1000 Subject: using selinux to control user access to files In-Reply-To: <200505091525.j49FP9Mg014935@turing-police.cc.vt.edu> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <200505091525.j49FP9Mg014935@turing-police.cc.vt.edu> Message-ID: <200507122259.42570.russell@coker.com.au> On Tuesday 10 May 2005 01:25, Valdis.Kletnieks at vt.edu wrote: > I remember seeing a statement on a RedHat page that their "lack of support" > would basically mean "replicate your issue with enforcing=0 and then we'll > talk", so things may not be as bad as all that... It's a matter of reproduce with targeted policy, reproduce with selinux=0 or maybe reproduce with enforcing=0 (NB enforcing=0 still has some small potential to break things). Also the exact details of how the problem must be reproduced will be negotiated with the support person. For example if "ls" didn't display file details correctly you should not be required to reboot with enforcing=0. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 12 13:38:35 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 12 Jul 2005 15:38:35 +0200 (CEST) Subject: NSA motives In-Reply-To: <200507050139.53555.angela@kahealani.com> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <42CA0CEE.5010307@mindspring.com> <200507050139.53555.angela@kahealani.com> Message-ID: On Tue, 5 Jul 2005, Angela Kahealani wrote: > apparently you fail to understand the implications of > "foreign adversaries". This means their primary mission is interception > of the traffic (which doesn't exist) between the aliens (which don't > exist) and decoding it into a human language (which does exist, but is > classified, called NEWSPEAK, composed primarily of cute acronyms. hehe :PPpp >> I'll have my tinfoil hat on for the rest of the day ;) > I doubt it... you probably meant aluminum foil. > If you've got actual tin foil, where do I get some? Yes I ment aluminum foil. However, its almost the same thing: http://en.wikipedia.org/wiki/Tinfoil Almost all say "tinfoil hat" and not "aluminumfoil hat". Tinfoil hat sounds much better. And its shorter. From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 12 13:44:34 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 12 Jul 2005 15:44:34 +0200 (CEST) Subject: NSA motives In-Reply-To: <20050705085840.loqdlzfckkwc0kwc@www.milivojevic.org> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <20050705085840.loqdlzfckkwc0kwc@www.milivojevic.org> Message-ID: On Tue, 5 Jul 2005, alex at milivojevic.org wrote: > To summarize, if somebody has false sense of security (he has perfect tools, > but > used in a wrong way), it will be actually easier for you to spy on him. This > is > especially true with complex subsystems such as SELinux (what do you think, > how > many system administrators out there *really* understand it?). I'm not sure > if > this is the actual (real) backdoor Vladis was refering to in his reply ;-) Well, thats one way to interpret it :) From iocc at fedora-selinux.lists.flashdance.cx Tue Jul 12 13:52:45 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Tue, 12 Jul 2005 15:52:45 +0200 (CEST) Subject: NSA motives In-Reply-To: <1120573839.2644.65.camel@moss-spartans.epoch.ncsc.mil> References: <20050623185818.23976.fh047.wm@smtp.sc0.cp.net> <1119557549.28493.270.camel@moss-spartans.epoch.ncsc.mil> <1120573839.2644.65.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Tue, 5 Jul 2005, Stephen Smalley wrote: >> What if some with evil reasons uses SELinux? Or have NSA realized that the >> old tactic doesnt work and its better to secure so many systems as possible >> instead. To help millions to have a more secure system is worth more than >> to possible prevent a few bad guys to also have secure systems. Probably >> leading that it will be more complicated or impossible for NSA to break in? > > Improving the security of COTS (commercial off the shelf) systems is > necessary to meet the security needs of our customers. Yes, there is > the potential for abuse, but such tradeoffs are inevitable. Ok, that was the answer I was looking for. >> Im sure NSA would love to have backdoor to SELinux if someone with evil >> reasons (what NSA thinks is evil) uses SELinux. Since SELinux is open >> source it cant be something obviously because it will be found very >> quickly. Must be something that its really, really well hidden. > That would be a rather foolish strategy, given that SELinux is > publically associated with NSA and the code is open. Yes it would. From findpreeti at gmail.com Tue Jul 12 14:45:59 2005 From: findpreeti at gmail.com (Preeti Malakar) Date: Tue, 12 Jul 2005 20:15:59 +0530 Subject: user_u identity Message-ID: Sir user_u is a generic user identity for Linux users who have no SELinux user identity defined why is user_u authorized for roles sysadm_r and system_r why is the user_r allowed to make a transition to sysadm_r and system_r ( as in rbac file) Thanking you From Valdis.Kletnieks at vt.edu Tue Jul 12 16:04:33 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Jul 2005 12:04:33 -0400 Subject: Should file permissions match SELinux policy? In-Reply-To: Your message of "Mon, 11 Jul 2005 15:35:41 MDT." <1121117742.3325.39.camel@mentorng.gurulabs.com> References: <1121117742.3325.39.camel@mentorng.gurulabs.com> Message-ID: <200507121604.j6CG4XkI011656@turing-police.cc.vt.edu> On Mon, 11 Jul 2005 15:35:41 MDT, Dax Kelson said: > Should the owner and group and permissions be made to match up with the > SELinux policy? ie: > > chgrp named /etc/named.conf > chmod 640 /etc/named.conf No. First off, there's the distinction between strict and targeted policy - if you *really* wanted to mirror that, strict should have chmod 640, but targeted should have chmod 644 (because Joe User running in unconfined_t will be allowed to 'more /etc/named.conf'). Secondly, you want to keep the Unix permissions/owners consistent with systems that *don't* run SELinux. Otherwise, you *will* go nuts trying to troubleshoot a permissions problem as systems get divergent settings on them. Of course, if 'chmod 640 /etc/named.conf' makes sense *even on a non-SELinux* system (are there any sensitive passwords/etc in there? I don't remember BIND having any such, but...) then by all means the change should be made... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at tycho.nsa.gov Tue Jul 12 16:21:23 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Jul 2005 12:21:23 -0400 Subject: user_u identity In-Reply-To: References: Message-ID: <1121185283.16209.113.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-07-12 at 20:15 +0530, Preeti Malakar wrote: > user_u is a generic user identity for Linux users who have no > SELinux user identity defined > why is user_u authorized for roles sysadm_r and system_r > why is the user_r allowed to make a transition to sysadm_r and > system_r ( as in rbac file) - Which release of Fedora Core (2, 3, 4)? cat /etc/redhat-release - Which policy (targeted, strict)? grep ^SELINUXTYPE /etc/selinux/config - Which version of policy? rpm -q selinux-policy-targeted or rpm -q selinux-policy-strict Under targeted policy, users are not confined, only specific daemons are confined. The user/role support is effectively unused, and only TE is used to confine daemons based on allowed domain transitions. The same basic set of users and roles from the strict policy are defined for security context compatibility, but they are not used for enforcement and are not restricted. Under strict policy, users are confined (along with daemons and some user programs), and user_u should only be authorized for user_r. user_r may be allowed to transition to sysadm_r (via su/sudo/userhelper if the user knows the root password) if the user_canbe_sysadm tunable is enabled; otherwise, you have to explicitly add users and authorize them for staff_r. -- Stephen Smalley National Security Agency From Ruth.Ivimey-Cook at ivimey.org Wed Jul 13 14:06:07 2005 From: Ruth.Ivimey-Cook at ivimey.org (Ruth Ivimey-Cook) Date: Wed, 13 Jul 2005 15:06:07 +0100 (BST) Subject: Help with avc's on /init Message-ID: Hi, I've just updated my desktop to FC4, have updated the policy to latest available versions, and am having problems with selinux denying access to a file I can't even find! Hoping someone can help. OS: FC4, updated today. Policy 1-25-1 Mode Targeted kernel 2.6.12.1 (kernel.org) Jul 13 14:35:25 filestore kernel: [4294782.219000] audit(1121261725.182:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:i18n_input_t tcontext=system_u:system_r:kernel_t tclass=fd Jul 13 14:35:28 filestore iiimd[2511]: started. Jul 13 14:35:39 filestore kernel: [4294796.393000] audit(1121261739.353:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:system_dbusd_t tcontext=system_u:system_r:kernel_t tclass=fd Jul 13 14:35:40 filestore kernel: [4294797.090000] audit(1121261740.050:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:system_r:kernel_t tclass=fd Jul 13 14:35:40 filestore kernel: [4294797.580000] audit(1121261740.540:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:hald_t tcontext=system_u:system_r:kernel_t tclass=fd I've tried a general relabeling (admittedly, not since the most recent update, but then it did something similar in the update itself). I'm not quite sure what effect the denials are having, but the system is not very stable at present. Ruth -- Ruth Ivimey-Cook Software engineer and technical writer. From sds at tycho.nsa.gov Wed Jul 13 14:11:56 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 13 Jul 2005 10:11:56 -0400 Subject: Help with avc's on /init In-Reply-To: References: Message-ID: <1121263917.1547.97.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-07-13 at 15:06 +0100, Ruth Ivimey-Cook wrote: > I've just updated my desktop to FC4, have updated the policy to latest > available versions, and am having problems with selinux denying access to a > file I can't even find! Hoping someone can help. > > OS: FC4, updated today. > Policy 1-25-1 > Mode Targeted > kernel 2.6.12.1 (kernel.org) > > > Jul 13 14:35:25 filestore kernel: [4294782.219000] > audit(1121261725.182:0): avc: denied { use } for path=/init > dev=rootfs ino=42 scontext=system_u:system_r:i18n_input_t > tcontext=system_u:system_r:kernel_t tclass=fd This is a file from the "rootfs", i.e. the in-memory filesystem exploded from the initramfs image by the kernel during initialization. It isn't an on-disk file. The kernel is improperly leaving a descriptor to it open when it executes /sbin/init, and this is then being inherited by all processes. SELinux rechecks access to open descriptors during execve, and if in enforcing mode, should be closing the descriptor and re-opening it to the null device due to the denial. Normally this stops the flow of such audit messages early on, as it is no longer inherited after that point. > I'm not quite sure what effect the denials are having, but the system is not > very stable at present. That particular denial should have no impact on stability. -- Stephen Smalley National Security Agency From Ruth.Ivimey-Cook at ivimey.org Wed Jul 13 14:23:12 2005 From: Ruth.Ivimey-Cook at ivimey.org (Ruth Ivimey-Cook) Date: Wed, 13 Jul 2005 15:23:12 +0100 Subject: Help with avc's on /init In-Reply-To: <1121263917.1547.97.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200507131459.j6DExETF012061@mx2.redhat.com> Stephen, > > Jul 13 14:35:25 filestore kernel: [4294782.219000] > > audit(1121261725.182:0): avc: denied { use } for path=/init > > dev=rootfs ino=42 scontext=system_u:system_r:i18n_input_t > > tcontext=system_u:system_r:kernel_t tclass=fd > > This is a file from the "rootfs", i.e. the in-memory > filesystem exploded from the initramfs image by the kernel > during initialization. It isn't an on-disk file. The kernel > is improperly leaving a descriptor to it open when it > executes /sbin/init, and this is then being inherited by all > processes. SELinux rechecks access to open descriptors > during execve, and if in enforcing mode, should be closing > the descriptor and re-opening it to the null device due to > the denial. Normally this stops the flow of such audit > messages early on, as it is no longer inherited after that point. > > > I'm not quite sure what effect the denials are having, but > the system > > is not very stable at present. > > That particular denial should have no impact on stability. Thanks. I wondered if it was in initramfs, but it's hard to check. Is there anything I can do to shut it up? Ruth From sds at tycho.nsa.gov Wed Jul 13 14:32:38 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 13 Jul 2005 10:32:38 -0400 Subject: Help with avc's on /init In-Reply-To: <200507131423.j6DENEvl002326@jazzdrum.ncsc.mil> References: <200507131423.j6DENEvl002326@jazzdrum.ncsc.mil> Message-ID: <1121265158.1547.115.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-07-13 at 15:23 +0100, Ruth Ivimey-Cook wrote: > Thanks. I wondered if it was in initramfs, but it's hard to check. Is there > anything I can do to shut it up? Looks like there is already a dontaudit rule in init.te for file descriptors inherited from the rootfs, but that dontaudit rule only deals with the file checks, not the descriptor use check. So I'd add: dontaudit init_t kernel_t:fd use; But I also see that init_t is unconfined in targeted policy (unlike strict), so that would mean that /sbin/init is being allowed to inherit the descriptor, so it is then passed along to all of its children. Which means you'd have to essentially dontaudit it for all domains to suppress, e.g. dontaudit domain kernel_t:fd use; Regardless, it should be bracketed with some ifdef, e.g. hide_broken_symptoms, because this does reflect a base kernel bug (not a bug in SELinux, but descriptor leakage by the base kernel) that needs to be fixed. -- Stephen Smalley National Security Agency From paul at city-fan.org Thu Jul 14 11:44:02 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 14 Jul 2005 12:44:02 +0100 Subject: pptp Message-ID: <1121341442.25207.151.camel@laurel.intra.city-fan.org> I'm currently using pptp (from Extras) for two different purposes: 1. to connect to my ADSL provider 2. to connect to $EMPLOYER's network pptp is a point-to-point tunnelling protocol client tightly integrated with pppd. It uses the GRE TCP protocol field to encapsulate packets to be sent down the tunnel. Some diagrams are available at http://pptpclient.sourceforge.net/diagrams.phtml Detailed information about the protocol (RFCs etc.) can be found in the pptp tarball in the SRPM. The way I start pptp is from an initscript, which does: pppd call filename where /etc/ppp/peers/filename contains the pppd options for the call, typically: pty "/usr/sbin/pptp ip.of.pptp.server --nolaunchpppd" user my.username usepeerdns updetach ... usual sorts of pppd options So pptp gets called from pppd, and hence runs as pppd_t Since pptp sends all sorts of packets down a tunnel, I find I need to add SELinux rules like these to get it to work: allow pppd_t var_log_t:file { append getattr }; allow pppd_t var_run_t:sock_file { create setattr unlink write }; allow pppd_t initrc_var_run_t:file { lock read write }; (these are standard pidfile/logfile issues I think) allow pppd_t self:rawip_socket { create connect read write }; allow pppd_t self:tcp_socket connect; allow pppd_t self:unix_stream_socket { accept connectto listen }; allow pppd_t fingerd_port_t:tcp_socket name_connect; allow pppd_t port_t:tcp_socket name_connect; allow pppd_t hostname_exec_t:file { execute execute_no_trans getattr read }; allow pppd_t pppd_etc_rw_t:file { execute execute_no_trans }; allow pppd_t smtp_port_t:tcp_socket name_connect; allow pppd_t devpts_t:chr_file ioctl; Given that I may wish to connect to arbitrary ports down the tunnel, I decided to cut my losses and do: # setsebool -P pppd_disable_trans 1 Would it be possible to separate pptp from pppd_t and specify different rules for it? Paul. -- Paul Howarth From Ruth.Ivimey-Cook at ivimey.org Thu Jul 14 13:16:09 2005 From: Ruth.Ivimey-Cook at ivimey.org (Ruth Ivimey-Cook) Date: Thu, 14 Jul 2005 14:16:09 +0100 (BST) Subject: FC4 policy: problems with /home Message-ID: Folks, I've updated a fileserver to FC4, and have a problem with the policy settings for /home. Under /home I have directories for: - users home directories - samba, also containing some windows user profiles - the server's web hierachy (what RH likes to put in /var/www) - general shared files (e.g. mp3s) Under FC3 all I had to do to get everything working was to include a line equivalent to that for /var/www, but for /web (why not /home/web ? because /web is a softlink to /home web). Now, it rejects /web, so I tried adding /home/web to apache.fc, but that has no noticeable effect when I do "restorecon -R /home/web". In addition, something is now preventing access to /home/samba/*, I think because it's called from in home_root_t and the files there are in user_home_t. See below for the log messages. Can anyone help me with pointers out of this mess? Thanks, Ruth Jul 14 14:07:49 filestore kernel: [4379544.608000] audit(1121346469.104:0): avc: denied { getattr } for path=/home dev=md2 ino=2 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir Jul 14 14:07:49 filestore kernel: [4379544.608000] audit(1121346469.104:0): avc: denied { read } for name=/ dev=md2 ino=2 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir Jul 14 14:07:49 filestore kernel: [4379544.609000] audit(1121346469.105:0): avc: denied { getattr } for path=/home/rivimey/.kde dev=md2 ino=6508546 scontext=system_u:system_r:smbd_t tcontext=user_u:object_r:user_home_t tclass=dir Jul 14 14:07:49 filestore kernel: [4379544.609000] audit(1121346469.105:0): avc: denied { getattr } for path=/home/rivimey/.ICEauthority dev=md2 ino=6508597 scontext=system_u:system_r:smbd_t tcontext=user_u:object_r:user_home_t tclass=file -- Ruth Ivimey-Cook Software engineer and technical writer. From dwalsh at redhat.com Thu Jul 14 14:58:11 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Jul 2005 10:58:11 -0400 Subject: FC4 policy: problems with /home In-Reply-To: References: Message-ID: <42D67D83.1050206@redhat.com> Ruth Ivimey-Cook wrote: > Folks, > > I've updated a fileserver to FC4, and have a problem with the policy > settings for /home. > > Under /home I have directories for: > - users home directories > - samba, also containing some windows user profiles > - the server's web hierachy (what RH likes to put in /var/www) > - general shared files (e.g. mp3s) > > Under FC3 all I had to do to get everything working was to include a > line equivalent to that for /var/www, but for /web (why not /home/web > ? because /web is a softlink to /home web). > > Now, it rejects /web, so I tried adding /home/web to apache.fc, but > that has no noticeable effect when I do "restorecon -R /home/web". > > In addition, something is now preventing access to /home/samba/*, I > think because it's called from in home_root_t and the files there are > in user_home_t. See below for the log messages. > > Can anyone help me with pointers out of this mess? > > Thanks, > > Ruth > > > Jul 14 14:07:49 filestore kernel: [4379544.608000] > audit(1121346469.104:0): avc: denied { getattr } for path=/home > dev=md2 ino=2 scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:home_root_t tclass=dir > Jul 14 14:07:49 filestore kernel: [4379544.608000] > audit(1121346469.104:0): avc: denied { read } for name=/ dev=md2 > ino=2 scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:home_root_t tclass=dir > Jul 14 14:07:49 filestore kernel: [4379544.609000] > audit(1121346469.105:0): avc: denied { getattr } for > path=/home/rivimey/.kde dev=md2 ino=6508546 > scontext=system_u:system_r:smbd_t tcontext=user_u:object_r:user_home_t > tclass=dir > Jul 14 14:07:49 filestore kernel: [4379544.609000] > audit(1121346469.105:0): avc: denied { getattr } for > path=/home/rivimey/.ICEauthority dev=md2 ino=6508597 > scontext=system_u:system_r:smbd_t tcontext=user_u:object_r:user_home_t > tclass=file > does setsebool -P samba_enable_home_dirs=1 help? -- From dwalsh at redhat.com Thu Jul 14 15:20:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Jul 2005 11:20:42 -0400 Subject: pptp In-Reply-To: <1121341442.25207.151.camel@laurel.intra.city-fan.org> References: <1121341442.25207.151.camel@laurel.intra.city-fan.org> Message-ID: <42D682CA.30500@redhat.com> Paul Howarth wrote: >I'm currently using pptp (from Extras) for two different purposes: > >1. to connect to my ADSL provider >2. to connect to $EMPLOYER's network > >pptp is a point-to-point tunnelling protocol client tightly integrated >with pppd. It uses the GRE TCP protocol field to encapsulate packets to >be sent down the tunnel. Some diagrams are available at >http://pptpclient.sourceforge.net/diagrams.phtml > >Detailed information about the protocol (RFCs etc.) can be found in the >pptp tarball in the SRPM. > >The way I start pptp is from an initscript, which does: > >pppd call filename > >where /etc/ppp/peers/filename contains the pppd options for the call, >typically: > >pty "/usr/sbin/pptp ip.of.pptp.server --nolaunchpppd" >user my.username >usepeerdns >updetach >... usual sorts of pppd options > >So pptp gets called from pppd, and hence runs as pppd_t > >Since pptp sends all sorts of packets down a tunnel, I find I need to >add SELinux rules like these to get it to work: > >allow pppd_t var_log_t:file { append getattr }; >allow pppd_t var_run_t:sock_file { create setattr unlink write }; >allow pppd_t initrc_var_run_t:file { lock read write }; > >(these are standard pidfile/logfile issues I think) > >allow pppd_t self:rawip_socket { create connect read write }; >allow pppd_t self:tcp_socket connect; >allow pppd_t self:unix_stream_socket { accept connectto listen }; >allow pppd_t fingerd_port_t:tcp_socket name_connect; >allow pppd_t port_t:tcp_socket name_connect; >allow pppd_t hostname_exec_t:file { execute execute_no_trans getattr >read }; >allow pppd_t pppd_etc_rw_t:file { execute execute_no_trans }; >allow pppd_t smtp_port_t:tcp_socket name_connect; >allow pppd_t devpts_t:chr_file ioctl; > >Given that I may wish to connect to arbitrary ports down the tunnel, I >decided to cut my losses and do: > ># setsebool -P pppd_disable_trans 1 > >Would it be possible to separate pptp from pppd_t and specify different >rules for it? > >Paul. > > Add the following to pppd.te, (I will also) daemon_domain(pptp) can_network_client_tcp(pptp_t) allow pptp_t { reserved_port_type port_t }:tcp_socket name_connect; can_exec(pptp_t, hostname_exec_t) domain_auto_trans(pppd_t, pptp_exec_t, pptp_t) allow pptp_t self:rawip_socket create_socket_perms; allow pptp_t self:unix_stream_socket create_stream_socket_perms; can_exec(pptp_t, pppd_etc_rw_t) allow pptp_t devpts_t:chr_file ioctl; r_dir_file(pptp_t, pppd_etc_rw_t) r_dir_file(pptp_t, pppd_etc_t) And add /usr/sbin/pptp -- system_u:object_r:pptp_exec_t to pppd.fc Make load restorecon /usr/sbin/pptp Then try it. I am sure there will need to be rules to allow pptp to communicate with pppd files? -- From paul at city-fan.org Fri Jul 15 10:15:35 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 15 Jul 2005 11:15:35 +0100 Subject: pptp In-Reply-To: <42D682CA.30500@redhat.com> References: <1121341442.25207.151.camel@laurel.intra.city-fan.org> <42D682CA.30500@redhat.com> Message-ID: <42D78CC7.70904@city-fan.org> Daniel J Walsh wrote: > Paul Howarth wrote: > >> I'm currently using pptp (from Extras) for two different purposes: >> >> 1. to connect to my ADSL provider >> 2. to connect to $EMPLOYER's network >> >> pptp is a point-to-point tunnelling protocol client tightly integrated >> with pppd. It uses the GRE TCP protocol field to encapsulate packets to >> be sent down the tunnel. Some diagrams are available at >> http://pptpclient.sourceforge.net/diagrams.phtml >> >> Detailed information about the protocol (RFCs etc.) can be found in the >> pptp tarball in the SRPM. >> >> The way I start pptp is from an initscript, which does: >> >> pppd call filename >> >> where /etc/ppp/peers/filename contains the pppd options for the call, >> typically: >> >> pty "/usr/sbin/pptp ip.of.pptp.server --nolaunchpppd" >> user my.username >> usepeerdns >> updetach >> ... usual sorts of pppd options >> >> So pptp gets called from pppd, and hence runs as pppd_t >> >> Since pptp sends all sorts of packets down a tunnel, I find I need to >> add SELinux rules like these to get it to work: >> >> allow pppd_t var_log_t:file { append getattr }; >> allow pppd_t var_run_t:sock_file { create setattr unlink write }; >> allow pppd_t initrc_var_run_t:file { lock read write }; >> >> (these are standard pidfile/logfile issues I think) >> >> allow pppd_t self:rawip_socket { create connect read write }; >> allow pppd_t self:tcp_socket connect; >> allow pppd_t self:unix_stream_socket { accept connectto listen }; >> allow pppd_t fingerd_port_t:tcp_socket name_connect; >> allow pppd_t port_t:tcp_socket name_connect; >> allow pppd_t hostname_exec_t:file { execute execute_no_trans getattr >> read }; >> allow pppd_t pppd_etc_rw_t:file { execute execute_no_trans }; >> allow pppd_t smtp_port_t:tcp_socket name_connect; >> allow pppd_t devpts_t:chr_file ioctl; >> >> Given that I may wish to connect to arbitrary ports down the tunnel, I >> decided to cut my losses and do: >> >> # setsebool -P pppd_disable_trans 1 >> >> Would it be possible to separate pptp from pppd_t and specify different >> rules for it? >> >> Paul. >> >> > Add the following to pppd.te, (I will also) > > daemon_domain(pptp) > can_network_client_tcp(pptp_t) > allow pptp_t { reserved_port_type port_t }:tcp_socket name_connect; > can_exec(pptp_t, hostname_exec_t) > domain_auto_trans(pppd_t, pptp_exec_t, pptp_t) > allow pptp_t self:rawip_socket create_socket_perms; > allow pptp_t self:unix_stream_socket create_stream_socket_perms; > can_exec(pptp_t, pppd_etc_rw_t) > allow pptp_t devpts_t:chr_file ioctl; > r_dir_file(pptp_t, pppd_etc_rw_t) > r_dir_file(pptp_t, pppd_etc_t) > > > And add > /usr/sbin/pptp -- system_u:object_r:pptp_exec_t > to pppd.fc > > > Make load > restorecon /usr/sbin/pptp > > Then try it. I am sure there will need to be rules to allow pptp to > communicate with pppd files? So far I've needed to add the following rules: allow pppd_t devpts_t:chr_file ioctl; allow pppd_t pptp_t:process signal; allow pppd_t var_log_t:file { append getattr }; allow pptp_t devpts_t:dir search; allow pptp_t self:capability net_raw; allow pptp_t self:fifo_file { read write }; allow pptp_t self:unix_dgram_socket { connect create write }; allow pptp_t self:unix_stream_socket connectto; allow pptp_t ptmx_t:chr_file { ioctl read write }; allow pptp_t var_log_t:file append; allow pptp_t var_run_t:sock_file { create setattr unlink write }; I can investigate the audit messages leading to these rules to try to find the actual thing being accessed if it's useful. Paul. From lfarkas at bppiac.hu Fri Jul 15 10:46:46 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 15 Jul 2005 12:46:46 +0200 Subject: a few more problem with the latest policy Message-ID: <42D79416.2040708@bppiac.hu> hi, a few problem with the latest policy file. ------------------------------------------ # audit2allow -i /var/log/messages -l allow apmd_t proc_t:file ioctl; allow dhcpc_t etc_t:file { unlink write }; allow ifconfig_t initrc_t:udp_socket { read write }; ------------------------------------------ and here is the relevant part of the log file ------------------------------------------ audit(1121423510.841:2): avc: denied { read write } for pid=2215 comm="ip" name="[6542]" dev=sockfs ino=6542 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:initrc_t tclass=udp_socket audit(1121423510.846:3): avc: denied { read write } for pid=2218 comm="ip" name="[6542]" dev=sockfs ino=6542 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:initrc_t tclass=udp_socket audit(1121423655.473:4): avc: denied { write } for pid=2888 comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file audit(1121423655.473:5): avc: denied { unlink } for pid=2888 comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file audit(1121423736.907:6): avc: denied { ioctl } for pid=2982 comm="awk" name="state" dev=proc ino=-268434831 scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:proc_t tclass=file ------------------------------------------ yours. -- Levente "Si vis pacem para bellum!" From dwalsh at redhat.com Fri Jul 15 12:37:00 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 15 Jul 2005 08:37:00 -0400 Subject: a few more problem with the latest policy In-Reply-To: <42D79416.2040708@bppiac.hu> References: <42D79416.2040708@bppiac.hu> Message-ID: <42D7ADEC.8070301@redhat.com> Farkas Levente wrote: > hi, > a few problem with the latest policy file. > ------------------------------------------ > # audit2allow -i /var/log/messages -l > allow apmd_t proc_t:file ioctl; Added, > allow dhcpc_t etc_t:file { unlink write }; restorecon /etc/resolv.conf* > allow ifconfig_t initrc_t:udp_socket { read write }; No idea what is causing this. > > ------------------------------------------ > and here is the relevant part of the log file > ------------------------------------------ > audit(1121423510.841:2): avc: denied { read write } for pid=2215 > comm="ip" name="[6542]" dev=sockfs ino=6542 > scontext=system_u:system_r:ifconfig_t > tcontext=system_u:system_r:initrc_t tclass=udp_socket > audit(1121423510.846:3): avc: denied { read write } for pid=2218 > comm="ip" name="[6542]" dev=sockfs ino=6542 > scontext=system_u:system_r:ifconfig_t > tcontext=system_u:system_r:initrc_t tclass=udp_socket > audit(1121423655.473:4): avc: denied { write } for pid=2888 > comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 > scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file > audit(1121423655.473:5): avc: denied { unlink } for pid=2888 > comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 > scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file > audit(1121423736.907:6): avc: denied { ioctl } for pid=2982 > comm="awk" name="state" dev=proc ino=-268434831 > scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:proc_t > tclass=file > ------------------------------------------ > yours. > -- From lfarkas at bppiac.hu Fri Jul 15 15:25:32 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 15 Jul 2005 17:25:32 +0200 Subject: a few more problem with the latest policy In-Reply-To: <42D7ADEC.8070301@redhat.com> References: <42D79416.2040708@bppiac.hu> <42D7ADEC.8070301@redhat.com> Message-ID: <42D7D56C.7040502@bppiac.hu> Daniel J Walsh wrote: > Farkas Levente wrote: > >> hi, >> a few problem with the latest policy file. >> allow dhcpc_t etc_t:file { unlink write }; > > > restorecon /etc/resolv.conf* there is a few more strange thing. first of all there is no restorecon, os i install policycoreutils (but it cna be another bug since how is it possible that policycoreutils is not among the required packages?) anyway this do not change anything so probaly this won't solve the problem: ----------------------------------------- [root at eagle ~]# ls -aZ /etc/resolv.conf* -rw-rw-r-- root root /etc/resolv.conf -rw-rw-r-- root root user_u:object_r:file_t /etc/resolv.conf.bak -rw-rw-r-- root root user_u:object_r:file_t /etc/resolv.conf.predhclient [root at eagle ~]# restorecon /etc/resolv.conf* [root at eagle ~]# ls -aZ /etc/resolv.conf* -rw-rw-r-- root root /etc/resolv.conf -rw-rw-r-- root root user_u:object_r:file_t /etc/resolv.conf.bak -rw-rw-r-- root root user_u:object_r:file_t /etc/resolv.conf.predhclient ----------------------------------------- >> allow ifconfig_t initrc_t:udp_socket { read write }; > > > No idea what is causing this. when i got it i issue an ifdown eth0; ifup eth0 and from the log file it seems there is an awk somewhere in ifdown of ifup... >> ------------------------------------------ >> and here is the relevant part of the log file >> ------------------------------------------ >> audit(1121423510.841:2): avc: denied { read write } for pid=2215 >> comm="ip" name="[6542]" dev=sockfs ino=6542 >> scontext=system_u:system_r:ifconfig_t >> tcontext=system_u:system_r:initrc_t tclass=udp_socket >> audit(1121423510.846:3): avc: denied { read write } for pid=2218 >> comm="ip" name="[6542]" dev=sockfs ino=6542 >> scontext=system_u:system_r:ifconfig_t >> tcontext=system_u:system_r:initrc_t tclass=udp_socket >> audit(1121423655.473:4): avc: denied { write } for pid=2888 >> comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 >> scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file >> audit(1121423655.473:5): avc: denied { unlink } for pid=2888 >> comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 >> scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file >> audit(1121423736.907:6): avc: denied { ioctl } for pid=2982 >> comm="awk" name="state" dev=proc ino=-268434831 >> scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:proc_t >> tclass=file >> ------------------------------------------ >> yours. >> > > -- Levente "Si vis pacem para bellum!" From lfarkas at bppiac.hu Fri Jul 15 15:53:50 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 15 Jul 2005 17:53:50 +0200 Subject: a few more problem with the latest policy In-Reply-To: <42D7D56C.7040502@bppiac.hu> References: <42D79416.2040708@bppiac.hu> <42D7ADEC.8070301@redhat.com> <42D7D56C.7040502@bppiac.hu> Message-ID: <42D7DC0E.7030100@bppiac.hu> Farkas Levente wrote: > Daniel J Walsh wrote: > >> Farkas Levente wrote: >> >>> hi, >>> a few problem with the latest policy file. >>> allow dhcpc_t etc_t:file { unlink write }; >> >> >> >> restorecon /etc/resolv.conf* > > > there is a few more strange thing. first of all there is no restorecon, > os i install policycoreutils (but it cna be another bug since how is it > possible that policycoreutils is not among the required packages?) > anyway this do not change anything so probaly this won't solve the problem: > ----------------------------------------- > [root at eagle ~]# ls -aZ /etc/resolv.conf* > -rw-rw-r-- root root /etc/resolv.conf > -rw-rw-r-- root root user_u:object_r:file_t /etc/resolv.conf.bak > -rw-rw-r-- root root user_u:object_r:file_t > /etc/resolv.conf.predhclient > [root at eagle ~]# restorecon /etc/resolv.conf* > [root at eagle ~]# ls -aZ /etc/resolv.conf* > -rw-rw-r-- root root /etc/resolv.conf > -rw-rw-r-- root root user_u:object_r:file_t /etc/resolv.conf.bak > -rw-rw-r-- root root user_u:object_r:file_t > /etc/resolv.conf.predhclient > ----------------------------------------- forget about this part (this was on an other machine:-() >>> allow ifconfig_t initrc_t:udp_socket { read write }; >> >> >> >> No idea what is causing this. > > > when i got it i issue an ifdown eth0; ifup eth0 and from the log file it > seems there is an awk somewhere in ifdown of ifup... > >>> ------------------------------------------ >>> and here is the relevant part of the log file >>> ------------------------------------------ >>> audit(1121423510.841:2): avc: denied { read write } for pid=2215 >>> comm="ip" name="[6542]" dev=sockfs ino=6542 >>> scontext=system_u:system_r:ifconfig_t >>> tcontext=system_u:system_r:initrc_t tclass=udp_socket >>> audit(1121423510.846:3): avc: denied { read write } for pid=2218 >>> comm="ip" name="[6542]" dev=sockfs ino=6542 >>> scontext=system_u:system_r:ifconfig_t >>> tcontext=system_u:system_r:initrc_t tclass=udp_socket >>> audit(1121423655.473:4): avc: denied { write } for pid=2888 >>> comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 >>> scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file >>> audit(1121423655.473:5): avc: denied { unlink } for pid=2888 >>> comm="cp" name="resolv.conf.predhclient" dev=hda2 ino=3997781 >>> scontext=root:system_r:dhcpc_t tcontext=root:object_r:etc_t tclass=file >>> audit(1121423736.907:6): avc: denied { ioctl } for pid=2982 >>> comm="awk" name="state" dev=proc ino=-268434831 >>> scontext=system_u:system_r:apmd_t tcontext=system_u:object_r:proc_t >>> tclass=file >>> ------------------------------------------ >>> yours. >>> >> >> > > -- Levente "Si vis pacem para bellum!" From cviniciusm at terra.com.br Sat Jul 16 01:42:37 2005 From: cviniciusm at terra.com.br (Vinicius) Date: Fri, 15 Jul 2005 22:42:37 -0300 Subject: The HP PSC 1315 is recognized by FC4, print but no scan yet. Message-ID: Hello, Please see https://www.redhat.com/archives/fedora-list/2005-July/msg03159.html Any suggestions, please? TIA, Vinicius. From findpreeti at gmail.com Sat Jul 16 10:09:32 2005 From: findpreeti at gmail.com (Preeti Malakar) Date: Sat, 16 Jul 2005 15:39:32 +0530 Subject: sysadm_r role Message-ID: Sir, Can anyone explain the following result, why root has to change the type along with role sysadm_r role . Why does it say "couldnt get default type" in the first case [root at pryber ~]# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:system_r:unconfined_t [root at pryber ~]# id -Z root:system_r:unconfined_t [root at pryber ~]# grep ^role /etc/selinux/targeted/src/policy/policy.conf | cut -f2 "-d " | sort -u sysadm_r system_r user_r [root at pryber ~]# newrole -r sysadm_r Couldn't get default type. [root at pryber ~]# newrole -r sysadm_r -t sysadm_t Authenticating root. Password: [root at pryber ~]# id -Z root:sysadm_r:unconfined_t -- Thanks in advance Regards Preeti Malakar MTech CSE IIT Guwahati From dwalsh at redhat.com Sat Jul 16 11:17:52 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 16 Jul 2005 07:17:52 -0400 Subject: The HP PSC 1315 is recognized by FC4, print but no scan yet. In-Reply-To: References: Message-ID: <42D8ECE0.9020307@redhat.com> Vinicius wrote: > Hello, > > Please see > https://www.redhat.com/archives/fedora-list/2005-July/msg03159.html > > Any suggestions, please? Well first put in a bugzilla. Secondly what port is it trying to connect to? Did you change the port number of the hpssd? > > > TIA, > > Vinicius. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Sat Jul 16 11:21:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 16 Jul 2005 07:21:32 -0400 Subject: sysadm_r role In-Reply-To: References: Message-ID: <42D8EDBC.20205@redhat.com> Preeti Malakar wrote: >Sir, > > Can anyone explain the following result, why root has to change >the type along with role sysadm_r role . Why does it say "couldnt get >default type" in the first case > > >[root at pryber ~]# id >uid=0(root) gid=0(root) >groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) >context=root:system_r:unconfined_t >[root at pryber ~]# id -Z >root:system_r:unconfined_t >[root at pryber ~]# grep ^role >/etc/selinux/targeted/src/policy/policy.conf | cut -f2 "-d " | sort -u >sysadm_r >system_r >user_r >[root at pryber ~]# newrole -r sysadm_r >Couldn't get default type. >[root at pryber ~]# newrole -r sysadm_r -t sysadm_t >Authenticating root. >Password: >[root at pryber ~]# id -Z >root:sysadm_r:unconfined_t > > > > Because we don't really use roles in targeted policy. Newrole uses the default_type file for discovering the default type for a particular role in strict policy the file looks like: > more /etc/selinux/strict/contexts/default_type secadm_r:secadm_t sysadm_r:sysadm_t staff_r:staff_t user_r:user_t nurse_r:user_t In targeted > more /etc/selinux/targeted/contexts/default_type system_r:unconfined_t -- From exinor at exinor.net Sat Jul 16 13:28:53 2005 From: exinor at exinor.net (Nicklas Norling) Date: Sat, 16 Jul 2005 15:28:53 +0200 Subject: A few permission problems Message-ID: <42D90B95.1090104@exinor.net> Hi. I've got a system updated from old redhat releases to FC2-3 and now 4. I've just downloaded selinux-policy-targeted and have been able to fix most of my problems with setsebool etc. while in permissive mode. However a few more difficult issues still intrigues me and I'd love it if someone would offer some help. First: [root at spock ~]# audit2allow -i /var/log/messages -l allow dovecot_auth_t selinux_config_t:file { getattr read }; allow httpd_sys_script_t var_t:dir getattr; allow named_t unconfined_t:fifo_file read; allow smbd_t selinux_config_t:dir search; allow smbd_t selinux_config_t:file { getattr read }; allow webalizer_t home_root_t:dir search; allow webalizer_t user_home_dir_t:dir search; The dovecot-auth problem seems to occur with every new connection to dovecot: Jul 16 14:00:16 spock kernel: audit(1121515216.305:122): avc: denied { read } for pid=21686 comm="dovecot-auth" name="config" dev=hda3 ino=394549 scontext=root:system_r:dovecot_auth_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 16 14:00:16 spock kernel: audit(1121515216.305:123): avc: denied { getattr } for pid=21686 comm="dovecot-auth" name="config" dev=hda3 ino=394549 scontext=root:system_r:dovecot_auth_t tcontext=system_u:object_r:selinux_config_t tclass=file The httpd problem appears to be python related. Not sure which of my web applications is triggering it (if any). Maybe MoinMoin Wiki but I can't seem to trigger it myself, maybe a search spider is triggering it. Jul 16 02:00:54 spock kernel: audit(1121472054.557:119): avc: denied { getattr } for pid=20378 comm="python" name="var" dev=hda3 ino=163841 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:var_t tclass=dir named is denied some fun? Jul 14 15:39:10 spock named[1771]: exiting Jul 14 15:39:12 spock kernel: audit(1121348352.535:98): avc: denied { read } for pid=16108 comm="named-checkconf" name ="[196624]" dev=pipefs ino=196624 scontext=root:system_r:named_t tcontext=root:system_r:unconfined_t tclass=fifo_file Jul 14 15:39:12 spock named[16110]: starting BIND 9.3.1 -u named Samba appears to wan't to read in the selinux config file? Every access to a home directory triggers this despite the correct sebool is set. Jul 15 02:43:18 spock kernel: audit(1121388198.077:104): avc: denied { search } for pid=17122 comm="smbd" name="selinu x" dev=hda3 ino=394114 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:selinux_config_t tclass=dir Jul 15 02:43:18 spock kernel: audit(1121388198.077:105): avc: denied { read } for pid=17122 comm="smbd" name="config" dev=hda3 ino=394549 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 15 02:43:18 spock kernel: audit(1121388198.078:106): avc: denied { getattr } for pid=17122 comm="smbd" name="config" dev=hda3 ino=394549 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:selinux_config_t tclass=file webalizer is being asked to put it's resulting webpages into a local users web directory in support of per user usage stat. The users webfolder has the correct objects set for httpd security. Jul 11 04:02:17 spock kernel: audit(1121047337.762:57): avc: denied { search } for pid=3409 comm="webalizer" name="home" dev=hda3 ino=819203 scontext=system_u:system_r:webalizer_t tcontext=system_u:object_r:home_root_t tclass=dir Jul 11 04:02:17 spock kernel: audit(1121047337.762:58): avc: denied { search } for pid=3409 comm="webalizer" name="joakim" dev=hda3 ino=458781 scontext=system_u:system_r:webalizer_t tcontext=user_u:object_r:user_home_dir_t tclass=dir In addition to this I have a shared folder with 'public' material, files that I offer to for download/upload. This folder is shared to my users with ftp as well as samba. Is this even possible to do with selinux? Jul 16 15:24:31 spock kernel: audit(1121520271.993:127): avc: denied { search } for pid=21818 comm="smbd" name="/" dev=hdc1 ino=2 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:ftpd_anon_t tclass=dir Jul 16 15:24:32 spock kernel: audit(1121520272.060:128): avc: denied { getattr } for pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:ftpd_anon_t tclass=dir Jul 16 15:24:32 spock kernel: audit(1121520272.156:129): avc: denied { read } for pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:ftpd_anon_t tclass=dir audit2allow suggests: allow smbd_t ftpd_anon_t:dir { getattr read search }; Greatful for any tips, hoping to enforce soon! /Nicke From cviniciusm at terra.com.br Sat Jul 16 14:03:03 2005 From: cviniciusm at terra.com.br (Vinicius) Date: Sat, 16 Jul 2005 11:03:03 -0300 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: <42D8ECE0.9020307@redhat.com> References: <42D8ECE0.9020307@redhat.com> Message-ID: Daniel J Walsh wrote: > Vinicius wrote: > >> Hello, >> >> Please see >> https://www.redhat.com/archives/fedora-list/2005-July/msg03159.html >> >> Any suggestions, please? > > > Well first put in a bugzilla. > Secondly what port is it trying to connect to? > > Did you change the port number of the hpssd? > > >> >> >> TIA, >> >> Vinicius. >> >> -- Hello, I filled the bug report number 163434 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163434). The port is 32774. No, I didn't change the port number of the hpssd. And I don't know how to do this. from /var/log/messages: Jul 16 10:02:54 ronin hpiod: 0.9.3 accepting connections at 32774... Jul 16 10:03:04 ronin python: hpssd [ERROR] Unable to connect to hpiod. from /var/log/audit/audit.log: type=CWD msg=audit(1121518984.285:13005806): cwd="/usr/share/hplip" type=PATH msg=audit(1121518984.285:13005806): item=0 name="/usr/share/hplip/base/strings.pyc" flags=310 inode=1181808 dev= fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1121518984.905:13008633): avc: denied { name_connect } for pid=4841 comm="python" dest=32774 scontext =root:system_r:hplip_t tcontext=system_u:object_r:port_t tclass=tcp_socket type=SYSCALL msg=audit(1121518984.905:13008633): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd6cf50 a2=98b114 a 3=b7c99b48 items=0 pid=4841 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="python" exe="/usr /bin/python" type=SOCKADDR msg=audit(1121518984.905:13008633): saddr=020080067F0000010000000000000000 type=SOCKETCALL msg=audit(1121518984.905:13008633): nargs=3 a0=5 a1=b7c99b60 a2=10 TIA, Vinicius. From dwalsh at redhat.com Mon Jul 18 18:39:39 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 18 Jul 2005 14:39:39 -0400 Subject: A few permission problems In-Reply-To: <42D90B95.1090104@exinor.net> References: <42D90B95.1090104@exinor.net> Message-ID: <42DBF76B.1040708@redhat.com> Nicklas Norling wrote: > Hi. > > I've got a system updated from old redhat releases to FC2-3 and now 4. > I've just downloaded selinux-policy-targeted and have been able to fix > most of > my problems with setsebool etc. while in permissive mode. However a > few more > difficult issues still intrigues me and I'd love it if someone would > offer some help. > > First: > [root at spock ~]# audit2allow -i /var/log/messages -l > allow dovecot_auth_t selinux_config_t:file { getattr read }; > allow httpd_sys_script_t var_t:dir getattr; > allow named_t unconfined_t:fifo_file read; > allow smbd_t selinux_config_t:dir search; > allow smbd_t selinux_config_t:file { getattr read }; > allow webalizer_t home_root_t:dir search; > allow webalizer_t user_home_dir_t:dir search; > > > The dovecot-auth problem seems to occur with every new connection to > dovecot: > > Jul 16 14:00:16 spock kernel: audit(1121515216.305:122): avc: denied > { read } for pid=21686 comm="dovecot-auth" name="config" dev=hda3 > ino=394549 scontext=root:system_r:dovecot_auth_t > tcontext=system_u:object_r:selinux_config_t tclass=file > Jul 16 14:00:16 spock kernel: audit(1121515216.305:123): avc: denied > { getattr } for pid=21686 comm="dovecot-auth" name="config" dev=hda3 > ino=394549 scontext=root:system_r:dovecot_auth_t > tcontext=system_u:object_r:selinux_config_t tclass=file > The would be suppressed by a dontaudit rule if you were running in enforcing. Always attempt to reproduce AVC messages in enforcing mode, since these are the ones we will fix. Permissive mode should only be run temporarily to get around a problem. Targeted policy gives a lot of "False" avc messages. > > The httpd problem appears to be python related. Not sure which of my > web applications is triggering it > (if any). Maybe MoinMoin Wiki but I can't seem to trigger it myself, > maybe a search spider is triggering it. > > Jul 16 02:00:54 spock kernel: audit(1121472054.557:119): avc: denied > { getattr } for pid=20378 comm="python" name="var" dev=hda3 > ino=163841 scontext=root:system_r:httpd_sys_script_t > tcontext=system_u:object_r:var_t tclass=dir > Yes the question would be which file/dir is it trying to read under /var > > named is denied some fun? > > Jul 14 15:39:10 spock named[1771]: exiting > Jul 14 15:39:12 spock kernel: audit(1121348352.535:98): avc: denied > { read } for pid=16108 comm="named-checkconf" name > ="[196624]" dev=pipefs ino=196624 scontext=root:system_r:named_t > tcontext=root:system_r:unconfined_t tclass=fifo_file > Jul 14 15:39:12 spock named[16110]: starting BIND 9.3.1 -u named > Is this only happening on a yum update/RPM install? > > Samba appears to wan't to read in the selinux config file? Every > access to a home directory triggers this despite the correct sebool is > set. > > Jul 15 02:43:18 spock kernel: audit(1121388198.077:104): avc: denied > { search } for pid=17122 comm="smbd" name="selinu > x" dev=hda3 ino=394114 scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:selinux_config_t tclass=dir > Jul 15 02:43:18 spock kernel: audit(1121388198.077:105): avc: denied > { read } for pid=17122 comm="smbd" name="config" > dev=hda3 ino=394549 scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:selinux_config_t tclass=file > Jul 15 02:43:18 spock kernel: audit(1121388198.078:106): avc: denied > { getattr } for pid=17122 comm="smbd" name="config" dev=hda3 > ino=394549 scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:selinux_config_t tclass=file > These should be dontaudited. Again run under enforcing mode. > > webalizer is being asked to put it's resulting webpages into a local > users web directory in support of per user usage stat. The users > webfolder has the correct objects set for httpd security. > > Jul 11 04:02:17 spock kernel: audit(1121047337.762:57): avc: denied > { search } for pid=3409 comm="webalizer" name="home" dev=hda3 > ino=819203 scontext=system_u:system_r:webalizer_t > tcontext=system_u:object_r:home_root_t tclass=dir > Jul 11 04:02:17 spock kernel: audit(1121047337.762:58): avc: denied > { search } for pid=3409 comm="webalizer" name="joakim" dev=hda3 > ino=458781 scontext=system_u:system_r:webalizer_t > tcontext=user_u:object_r:user_home_dir_t tclass=dir > You will need to write your own policy for this. Alternatively you could create a directory under /var/www with the label httpd_sys_content_t and allow webalizer to write their and allow users to read it. > tclass=file > In addition to this I have a shared folder with 'public' material, > files that I offer to for download/upload. This folder is shared to my > users with ftp as well as samba. Is this even possible to do with > selinux? > > Jul 16 15:24:31 spock kernel: audit(1121520271.993:127): avc: denied > { search } for pid=21818 comm="smbd" name="/" dev=hdc1 ino=2 > scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:ftpd_anon_t tclass=dir > Jul 16 15:24:32 spock kernel: audit(1121520272.060:128): avc: denied > { getattr } for pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769 > scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:ftpd_anon_t tclass=dir > Jul 16 15:24:32 spock kernel: audit(1121520272.156:129): avc: denied > { read } for pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769 > scontext=system_u:system_r:smbd_t > tcontext=system_u:object_r:ftpd_anon_t tclass=dir > > audit2allow suggests: > allow smbd_t ftpd_anon_t:dir { getattr read search }; > You could add this rule to your local.te file. We have discussed this in the past and maybe a boolean allowing all apps to read "shared data" would work. > Greatful for any tips, hoping to enforce soon! > /Nicke > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dragoran at feuerpokemon.de Tue Jul 19 07:53:04 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 19 Jul 2005 09:53:04 +0200 Subject: Problems with selinux-policy-targeted-1.25.2-4 (user_ping boolean) Message-ID: <42DCB160.6050104@feuerpokemon.de> During boot I get an error : error reading /etc/selinux/targeted/booleans because there is no user_ping bool I had allowed user_ping in the older policy in system-config-securitylevel but now it disappered? is this a bug or a feature? (ping still works) if it is a feature how can I get rid of this message? From exinor at exinor.net Tue Jul 19 11:12:53 2005 From: exinor at exinor.net (Nicklas Norling) Date: Tue, 19 Jul 2005 13:12:53 +0200 Subject: A few permission problems In-Reply-To: <42DBF76B.1040708@redhat.com> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> Message-ID: <42DCE035.4080206@exinor.net> Daniel J Walsh wrote: > Nicklas Norling wrote: > >> Hi. >> >> I've got a system updated from old redhat releases to FC2-3 and now 4. >> I've just downloaded selinux-policy-targeted and have been able to >> fix most of >> my problems with setsebool etc. while in permissive mode. However a >> few more >> difficult issues still intrigues me and I'd love it if someone would >> offer some help. >> >> > >> >> The httpd problem appears to be python related. Not sure which of my >> web applications is triggering it >> (if any). Maybe MoinMoin Wiki but I can't seem to trigger it myself, >> maybe a search spider is triggering it. >> >> Jul 16 02:00:54 spock kernel: audit(1121472054.557:119): avc: >> denied { getattr } for pid=20378 comm="python" name="var" dev=hda3 >> ino=163841 scontext=root:system_r:httpd_sys_script_t >> tcontext=system_u:object_r:var_t tclass=dir >> > Yes the question would be which file/dir is it trying to read under /var > Indeed, I shall keep my eyes open and report back if I can figure it out. >> >> named is denied some fun? >> >> Jul 14 15:39:10 spock named[1771]: exiting >> Jul 14 15:39:12 spock kernel: audit(1121348352.535:98): avc: denied >> { read } for pid=16108 comm="named-checkconf" name >> ="[196624]" dev=pipefs ino=196624 scontext=root:system_r:named_t >> tcontext=root:system_r:unconfined_t tclass=fifo_file >> Jul 14 15:39:12 spock named[16110]: starting BIND 9.3.1 -u named >> > Is this only happening on a yum update/RPM install? > Yes it does. I read between the line(s) that is expected. Still looks worrying to a noob like myself. > > >> >> webalizer is being asked to put it's resulting webpages into a local >> users web directory in support of per user usage stat. The users >> webfolder has the correct objects set for httpd security. >> >> Jul 11 04:02:17 spock kernel: audit(1121047337.762:57): avc: denied >> { search } for pid=3409 comm="webalizer" name="home" dev=hda3 >> ino=819203 scontext=system_u:system_r:webalizer_t >> tcontext=system_u:object_r:home_root_t tclass=dir >> Jul 11 04:02:17 spock kernel: audit(1121047337.762:58): avc: denied >> { search } for pid=3409 comm="webalizer" name="joakim" dev=hda3 >> ino=458781 scontext=system_u:system_r:webalizer_t >> tcontext=user_u:object_r:user_home_dir_t tclass=dir >> > You will need to write your own policy for this. Alternatively you > could create a directory under /var/www with the > label httpd_sys_content_t and allow webalizer to write their and allow > users to read it. > Hmm, ok. Maybe webalizer should have a boolean for accessing http home dir provided httpd_enable_homedirs=1? Or maybe my way of doing this is so odd it's worth the trouble. >> tclass=file >> In addition to this I have a shared folder with 'public' material, >> files that I offer to for download/upload. This folder is shared to >> my users with ftp as well as samba. Is this even possible to do with >> selinux? >> >> Jul 16 15:24:31 spock kernel: audit(1121520271.993:127): avc: >> denied { search } for pid=21818 comm="smbd" name="/" dev=hdc1 ino=2 >> scontext=system_u:system_r:smbd_t >> tcontext=system_u:object_r:ftpd_anon_t tclass=dir >> Jul 16 15:24:32 spock kernel: audit(1121520272.060:128): avc: >> denied { getattr } for pid=21818 comm="smbd" name="pub" dev=hdc1 >> ino=32769 scontext=system_u:system_r:smbd_t >> tcontext=system_u:object_r:ftpd_anon_t tclass=dir >> Jul 16 15:24:32 spock kernel: audit(1121520272.156:129): avc: >> denied { read } for pid=21818 comm="smbd" name="pub" dev=hdc1 >> ino=32769 scontext=system_u:system_r:smbd_t >> tcontext=system_u:object_r:ftpd_anon_t tclass=dir >> >> audit2allow suggests: >> allow smbd_t ftpd_anon_t:dir { getattr read search }; >> > You could add this rule to your local.te file. We have discussed this > in the past and maybe a boolean allowing all apps to read "shared > data" would work. > Ok, I think adding the rule is the way to go for me. Some more learning to do. I would encourage a boolean for shared data location. I think labeling a folder and it's subcontent with a specific label and then have different services be able to use it might be a start. That way I could disallow smb the rights but allow ftpd and httpd (as an example). I think that would be a great improvment from my point of view. Since 01:22:00 this day my server is in enforce mode. The only thing I've found so far is sendmail being denied access to urandom and random. I have sendmail setup with SMTP AUTH as well as certs for performing STARTTLS with any TLS-able connecting MTA. /var/log/messages Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc: denied { getattr } for pid=20520 comm="sendmail" name="urandom" dev=tmpfs ino=846 scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t tclass=chr_file Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc: denied { getattr } for pid=20520 comm="sendmail" name="random" dev=tmpfs ino=844 scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t tclass=chr_file /var/log/maillog Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: from=, size=874, class=0, nrcpts=1, msgid=, bodytype=8BITMIME, relay=apache at localhost Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: STARTTLS=client, error: connect failed=-1, SSL_error=5, timedout=0, errno=2 Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake. Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=, ctladdr= (48/48), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake. Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: accept failed=0, SSL_error=5, timedout=0,errno=0 Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA audit2allow -d -l allow system_mail_t random_device_t:chr_file getattr; allow system_mail_t urandom_device_t:chr_file getattr; Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm Apart from this DoS on sendmail my system appears to be working as expected. Personally I'd love to see permissive mode similar to enforcing when it come's to avc's. I don't like the idea of turning on enforcing to see things not work and then turn it off. Much rather would I use permissive mode to investigate what will go wrong so I can fix problems before I DoS myself. Thanks a lot for all your help Daniel, I sure appretiate it! /Nicke From exinor at exinor.net Tue Jul 19 13:59:12 2005 From: exinor at exinor.net (Nicklas Norling) Date: Tue, 19 Jul 2005 15:59:12 +0200 Subject: A few permission problems In-Reply-To: <42DCE035.4080206@exinor.net> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> Message-ID: <42DD0730.9060409@exinor.net> Nicklas Norling wrote: > > Since 01:22:00 this day my server is in enforce mode. The only thing > I've found so far is sendmail being denied access to urandom and > random. I have sendmail setup with SMTP AUTH as well as certs for > performing STARTTLS with any TLS-able connecting MTA. > > /var/log/messages > Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc: denied > { getattr } for pid=20520 comm="sendmail" name="urandom" dev=tmpfs > ino=846 > scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t > tclass=chr_file > Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc: denied > { getattr } for pid=20520 comm="sendmail" name="random" dev=tmpfs > ino=844 > scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t > tclass=chr_file > > /var/log/maillog > Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: from=, > size=874, class=0, nrcpts=1, > msgid=, > bodytype=8BITMIME, relay=apache at localhost > Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: > STARTTLS=client, error: connect failed=-1, SSL_error=5, timedout=0, > errno=2 > Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, > arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake. > Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=, > ctladdr= (48/48), delay=00:00:00, xdelay=00:00:00, > mailer=relay, pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, > stat=Deferred: 403 4.7.0 TLS handshake. > Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: accept > failed=0, SSL_error=5, timedout=0,errno=0 > Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost > [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA > > audit2allow -d -l > allow system_mail_t random_device_t:chr_file getattr; > allow system_mail_t urandom_device_t:chr_file getattr; > > Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm > I've installed selinux-policy-targeted-sources-1.25.1-9.noarch.rpm, edited /etc/selinux/targeted/src/policy/domains/misc/local.te to contain: allow system_mail_t random_device_t:chr_file getattr; allow system_mail_t urandom_device_t:chr_file getattr; Then did a 'make reload' in /etc/selinux/targeted/src/policy as per instructions I found on the net. This made the sendmail TLS errors go away, however, trying smtp auth saslauthd complains instead: Jul 19 14:14:19 spock saslauthd[22499]: do_auth : auth failure: [user=] [service=smtp] [realm=] [mech=shadow] [reason=Unknown] Jul 19 14:14:19 spock saslauthd[22500]: do_auth : auth failure: [user=] [service=smtp] [realm=] [mech=shadow] [reason=Unknown] 'setenforce 0' makes it all work. No avc's in the logs during enforcing mode. I guess my pathetic attempts at creating local rules failed misserably :( I'm in way over my head here I think... Any pointers? /Nicke From dwalsh at redhat.com Tue Jul 19 15:54:55 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Jul 2005 11:54:55 -0400 Subject: A few permission problems In-Reply-To: <42DD0730.9060409@exinor.net> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <42DD0730.9060409@exinor.net> Message-ID: <42DD224F.3090007@redhat.com> Nicklas Norling wrote: > Nicklas Norling wrote: > >> >> Since 01:22:00 this day my server is in enforce mode. The only thing >> I've found so far is sendmail being denied access to urandom and >> random. I have sendmail setup with SMTP AUTH as well as certs for >> performing STARTTLS with any TLS-able connecting MTA. >> >> /var/log/messages >> Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc: >> denied { getattr } for pid=20520 comm="sendmail" name="urandom" >> dev=tmpfs ino=846 >> scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t >> tclass=chr_file >> Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc: >> denied { getattr } for pid=20520 comm="sendmail" name="random" >> dev=tmpfs ino=844 >> scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t >> tclass=chr_file >> >> /var/log/maillog >> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: from=, >> size=874, class=0, nrcpts=1, >> msgid=, >> bodytype=8BITMIME, relay=apache at localhost >> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: >> STARTTLS=client, error: connect failed=-1, SSL_error=5, timedout=0, >> errno=2 >> Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, >> arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake. >> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=, >> ctladdr= (48/48), delay=00:00:00, xdelay=00:00:00, >> mailer=relay, pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, >> stat=Deferred: 403 4.7.0 TLS handshake. >> Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: accept >> failed=0, SSL_error=5, timedout=0,errno=0 >> Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost >> [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA >> >> audit2allow -d -l >> allow system_mail_t random_device_t:chr_file getattr; >> allow system_mail_t urandom_device_t:chr_file getattr; >> >> Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm >> > > > I've installed selinux-policy-targeted-sources-1.25.1-9.noarch.rpm, > edited > /etc/selinux/targeted/src/policy/domains/misc/local.te to contain: > > allow system_mail_t random_device_t:chr_file getattr; > allow system_mail_t urandom_device_t:chr_file getattr; > > Then did a 'make reload' in /etc/selinux/targeted/src/policy as per > instructions I found on the net. > This made the sendmail TLS errors go away, however, trying smtp auth > saslauthd complains instead: > > Jul 19 14:14:19 spock saslauthd[22499]: do_auth : auth > failure: [user=] [service=smtp] [realm=] [mech=shadow] > [reason=Unknown] > Jul 19 14:14:19 spock saslauthd[22500]: do_auth : auth > failure: [user=] [service=smtp] [realm=] [mech=shadow] > [reason=Unknown] > > 'setenforce 0' makes it all work. No avc's in the logs during > enforcing mode. > > I guess my pathetic attempts at creating local rules failed misserably :( > I'm in way over my head here I think... Any pointers? > /Nicke > No, you are seeing a new problem. See if you can do the following setsebool -P allow_saslauthd_read_shadow=1 If that is not in your current policy you might need to update it. Dan -- From dwalsh at redhat.com Tue Jul 19 15:56:01 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Jul 2005 11:56:01 -0400 Subject: Problems with selinux-policy-targeted-1.25.2-4 (user_ping boolean) In-Reply-To: <42DCB160.6050104@feuerpokemon.de> References: <42DCB160.6050104@feuerpokemon.de> Message-ID: <42DD2291.7080609@redhat.com> dragoran wrote: > During boot I get an error : > error reading /etc/selinux/targeted/booleans because there is no > user_ping bool > I had allowed user_ping in the older policy in > system-config-securitylevel but now it disappered? > is this a bug or a feature? (ping still works) > if it is a feature how can I get rid of this message? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list user_ping bool has been removed. Please remove it from that file. -- From exinor at exinor.net Tue Jul 19 16:07:02 2005 From: exinor at exinor.net (Nicklas Norling) Date: Tue, 19 Jul 2005 18:07:02 +0200 Subject: A few permission problems In-Reply-To: <42DD224F.3090007@redhat.com> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <42DD0730.9060409@exinor.net> <42DD224F.3090007@redhat.com> Message-ID: <42DD2526.4060201@exinor.net> Daniel J Walsh wrote: > Nicklas Norling wrote: > >> Nicklas Norling wrote: >> >>> >>> Since 01:22:00 this day my server is in enforce mode. The only thing >>> I've found so far is sendmail being denied access to urandom and >>> random. I have sendmail setup with SMTP AUTH as well as certs for >>> performing STARTTLS with any TLS-able connecting MTA. >>> >>> /var/log/messages >>> Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc: >>> denied { getattr } for pid=20520 comm="sendmail" name="urandom" >>> dev=tmpfs ino=846 >>> scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t >>> tclass=chr_file >>> Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc: >>> denied { getattr } for pid=20520 comm="sendmail" name="random" >>> dev=tmpfs ino=844 >>> scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t >>> tclass=chr_file >>> >>> /var/log/maillog >>> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: >>> from=, size=874, class=0, nrcpts=1, >>> msgid=, >>> bodytype=8BITMIME, relay=apache at localhost >>> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: >>> STARTTLS=client, error: connect failed=-1, SSL_error=5, timedout=0, >>> errno=2 >>> Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, >>> arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake. >>> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=, >>> ctladdr= (48/48), delay=00:00:00, xdelay=00:00:00, >>> mailer=relay, pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, >>> stat=Deferred: 403 4.7.0 TLS handshake. >>> Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: >>> accept failed=0, SSL_error=5, timedout=0,errno=0 >>> Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost >>> [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA >>> >>> audit2allow -d -l >>> allow system_mail_t random_device_t:chr_file getattr; >>> allow system_mail_t urandom_device_t:chr_file getattr; >>> >>> Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm >>> >> >> >> I've installed selinux-policy-targeted-sources-1.25.1-9.noarch.rpm, >> edited >> /etc/selinux/targeted/src/policy/domains/misc/local.te to contain: >> >> allow system_mail_t random_device_t:chr_file getattr; >> allow system_mail_t urandom_device_t:chr_file getattr; >> >> Then did a 'make reload' in /etc/selinux/targeted/src/policy as per >> instructions I found on the net. >> This made the sendmail TLS errors go away, however, trying smtp auth >> saslauthd complains instead: >> >> Jul 19 14:14:19 spock saslauthd[22499]: do_auth : auth >> failure: [user=] [service=smtp] [realm=] [mech=shadow] >> [reason=Unknown] >> Jul 19 14:14:19 spock saslauthd[22500]: do_auth : auth >> failure: [user=] [service=smtp] [realm=] [mech=shadow] >> [reason=Unknown] >> >> 'setenforce 0' makes it all work. No avc's in the logs during >> enforcing mode. >> >> I guess my pathetic attempts at creating local rules failed >> misserably :( >> I'm in way over my head here I think... Any pointers? >> /Nicke >> > No, you are seeing a new problem. > > See if you can do the following > setsebool -P allow_saslauthd_read_shadow=1 > > If that is not in your current policy you might need to update it. > > Dan > I've set the boolean and turned enforcing back on. Mail works as expected :) Thanks a lot for all the help Daniel! Yet another system securer :) /Nicke From kwade at redhat.com Tue Jul 19 19:33:13 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 19 Jul 2005 12:33:13 -0700 Subject: call for FAQs Message-ID: <1121801593.5590.62.camel@erato.phig.org> Better late than never, eh? If you have an FAQ about Fedora and SELinux: * Something not covered in the FAQ already * An FAQ in FC3 is different or not needed for FC4 * An entry that needs to be expanded Here is the best (and only) way to get in the queue. 1. Use this easy-to-fill-out bug: http://tinyurl.com/7p9mt * Make the Summary meaningful * Fill out the description * _Do not_ remove the blocking bug 118757 Okay, wait, there is another way. If you send me an email with a collection of pointers to specific messages/threads in online archives on this or other mailing lists, I'll make the bug report myself. Thanks, Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Tue Jul 19 19:38:25 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Jul 2005 15:38:25 -0400 Subject: call for FAQs In-Reply-To: <1121801593.5590.62.camel@erato.phig.org> References: <1121801593.5590.62.camel@erato.phig.org> Message-ID: <42DD56B1.9060303@redhat.com> Karsten Wade wrote: >Better late than never, eh? > >If you have an FAQ about Fedora and SELinux: > >* Something not covered in the FAQ already >* An FAQ in FC3 is different or not needed for FC4 >* An entry that needs to be expanded > >Here is the best (and only) way to get in the queue. > >1. Use this easy-to-fill-out bug: http://tinyurl.com/7p9mt > * Make the Summary meaningful > * Fill out the description > * _Do not_ remove the blocking bug 118757 > > I am or need to write up a man page for all policy files that have file_context of booleans specific to the context. man httpd_selinux is an example. These descriptions should probably also be put into the FAQ. Since a lot of new users don't seem to look for man pages. >Okay, wait, there is another way. If you send me an email with a >collection of pointers to specific messages/threads in online archives >on this or other mailing lists, I'll make the bug report myself. > >Thanks, > >Karsten > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From mayerf at tresys.com Tue Jul 19 20:04:40 2005 From: mayerf at tresys.com (Frank Mayer) Date: Tue, 19 Jul 2005 16:04:40 -0400 Subject: Call for Paper - 2nd SELinux Symposium Message-ID: <200507192004.j6JK4evx015326@gotham.columbia.tresys.com> SECOND SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org) Call for Papers The call for papers for the Second Security Enhanced Linux (SELinux) Symposium is now open. The Symposium is scheduled for February 28-March 2, 2006, at the Wyndham Hotel, Baltimore, Maryland, USA. The event is the only of its kind to examine SELinux and the power of the flexible mandatory access control security it brings to Linux. Last year's inaugural symposium was a tremendous success providing the SELinux development and user community the opportunity to discuss related research results, development plans, and applications. Any topics relating to SELinux technology, flexible mandatory access control, and its application to real-world problem are of interest for this symposium. Such topic include: + Innovations and advancement in SELinux technology + Use and application of SELinux and Type Enforcement + SELinux development experiences and tools + Use and Configuration of MLS and RBAC in securing systems + Updates on the various Linux distributions using SELinux + Practical "root"-less system administration policies + Case studies and application experience SELinux + Related research and development activities + Tools and products supporting/using SELinux + Security evaluation and certification issues + User and customers concerns and needs + Tutorials No marketing pitches will be accepted. The call for papers is open until September 19, 2005. For additional information and submittal requirements, see www.selinux-symposium.org. Technical Committee: Joshua Brindle, Tresys Russell Coker, Red Hat Chad Hanson, TCS Trent Jaeger, IBM Pete Loscocco, NSA Karl MacMillan, Tresys Frank Mayer (Chair), Tresys James Morris, Red Hat Doc Shankar, IBM Stephen Smalley, NSA Daniel Walsh, Red Hat From dragoran at feuerpokemon.de Wed Jul 20 05:13:02 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 20 Jul 2005 07:13:02 +0200 Subject: Problems with selinux-policy-targeted-1.25.2-4 (user_ping boolean) In-Reply-To: <42DD2291.7080609@redhat.com> References: <42DCB160.6050104@feuerpokemon.de> <42DD2291.7080609@redhat.com> Message-ID: <42DDDD5E.3010508@feuerpokemon.de> Daniel J Walsh wrote: > dragoran wrote: > >> During boot I get an error : >> error reading /etc/selinux/targeted/booleans because there is no >> user_ping bool >> I had allowed user_ping in the older policy in >> system-config-securitylevel but now it disappered? >> is this a bug or a feature? (ping still works) >> if it is a feature how can I get rid of this message? >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > user_ping bool has been removed. Please remove it from that file. > found it it was in booleans.local From paul at city-fan.org Wed Jul 20 06:58:49 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 20 Jul 2005 07:58:49 +0100 Subject: Shared data are (was: A few permission problems) In-Reply-To: <42DCE035.4080206@exinor.net> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> Message-ID: <1121842729.25207.344.camel@laurel.intra.city-fan.org> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote: > I would encourage a boolean for shared data location. I think labeling a > folder and it's subcontent with a specific label and then have different > services be able to use it might be a start. That way I could disallow > smb the rights but allow ftpd and httpd (as an example). I think that > would be a great improvment from my point of view. I think this is a great idea. I have a file server at home where I stick all the software I've downloaded, some for Linux and some for Windows. The Windows box accesses the area using samba and Linux uses httpd as I've set up a local yum repo for the Linux software. So in Niklas' idea I'd be enabling httpd and smb for this and not ftp. This type might be a good one to use for everything under /srv... Paul. -- Paul Howarth From dwalsh at redhat.com Wed Jul 20 12:44:12 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Jul 2005 08:44:12 -0400 Subject: Shared data are In-Reply-To: <1121842729.25207.344.camel@laurel.intra.city-fan.org> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <1121842729.25207.344.camel@laurel.intra.city-fan.org> Message-ID: <42DE471C.6050000@redhat.com> Paul Howarth wrote: >On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote: > > >>I would encourage a boolean for shared data location. I think labeling a >>folder and it's subcontent with a specific label and then have different >>services be able to use it might be a start. That way I could disallow >>smb the rights but allow ftpd and httpd (as an example). I think that >>would be a great improvment from my point of view. >> >> > >I think this is a great idea. I have a file server at home where I stick >all the software I've downloaded, some for Linux and some for Windows. >The Windows box accesses the area using samba and Linux uses httpd as >I've set up a local yum repo for the Linux software. So in Niklas' idea >I'd be enabling httpd and smb for this and not ftp. > >This type might be a good one to use for everything under /srv... > >Paul. > > Ok. I am allowing ftpd, samba, apache and/or apache scripts, rsync to read ftpd_anon_t. So if you want files shared by these services, you can change the context to ftpd_anon_t. -- From paul at city-fan.org Wed Jul 20 15:20:44 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 20 Jul 2005 16:20:44 +0100 Subject: Shared data area In-Reply-To: <42DE471C.6050000@redhat.com> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <1121842729.25207.344.camel@laurel.intra.city-fan.org> <42DE471C.6050000@redhat.com> Message-ID: <42DE6BCC.9000602@city-fan.org> Daniel J Walsh wrote: > Paul Howarth wrote: > >> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote: >> >> >>> I would encourage a boolean for shared data location. I think >>> labeling a folder and it's subcontent with a specific label and then >>> have different services be able to use it might be a start. That way >>> I could disallow smb the rights but allow ftpd and httpd (as an >>> example). I think that would be a great improvment from my point of >>> view. >>> >> >> >> I think this is a great idea. I have a file server at home where I stick >> all the software I've downloaded, some for Linux and some for Windows. >> The Windows box accesses the area using samba and Linux uses httpd as >> I've set up a local yum repo for the Linux software. So in Niklas' idea >> I'd be enabling httpd and smb for this and not ftp. >> >> This type might be a good one to use for everything under /srv... >> >> Paul. >> >> > Ok. I am allowing ftpd, samba, apache and/or apache scripts, rsync to > read ftpd_anon_t. > > So if you want files shared by these services, you can change the > context to ftpd_anon_t. Would it not be better to create a new type for a shared data area (e.g. srv_data_t), with booleans allowing read/write access to this data for each daemon, rather than overloading an existing type? After all, some process has to set up this data area, and for some people that will be done using ftp, some sftp, some rsync, some samba etc... Obviously this is much harder to do but I thought I'd ask anyway :-) Paul. From dwalsh at redhat.com Wed Jul 20 17:34:43 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Jul 2005 13:34:43 -0400 Subject: Shared data area In-Reply-To: <42DE6BCC.9000602@city-fan.org> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <1121842729.25207.344.camel@laurel.intra.city-fan.org> <42DE471C.6050000@redhat.com> <42DE6BCC.9000602@city-fan.org> Message-ID: <42DE8B33.3020108@redhat.com> Paul Howarth wrote: > Daniel J Walsh wrote: > >> Paul Howarth wrote: >> >>> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote: >>> >>> >>>> I would encourage a boolean for shared data location. I think >>>> labeling a folder and it's subcontent with a specific label and >>>> then have different services be able to use it might be a start. >>>> That way I could disallow smb the rights but allow ftpd and httpd >>>> (as an example). I think that would be a great improvment from my >>>> point of view. >>>> >>> >>> >>> >>> I think this is a great idea. I have a file server at home where I >>> stick >>> all the software I've downloaded, some for Linux and some for Windows. >>> The Windows box accesses the area using samba and Linux uses httpd as >>> I've set up a local yum repo for the Linux software. So in Niklas' idea >>> I'd be enabling httpd and smb for this and not ftp. >>> >>> This type might be a good one to use for everything under /srv... >>> >>> Paul. >>> >>> >> Ok. I am allowing ftpd, samba, apache and/or apache scripts, rsync >> to read ftpd_anon_t. >> >> So if you want files shared by these services, you can change the >> context to ftpd_anon_t. > > > Would it not be better to create a new type for a shared data area > (e.g. srv_data_t), with booleans allowing read/write access to this > data for each daemon, rather than overloading an existing type? After > all, some process has to set up this data area, and for some people > that will be done using ftp, some sftp, some rsync, some samba etc... > I could do that, but I was already sharing the type between rsync and ftp. Basically I think of this type, as data available on the network requiring no authorization to read or for ftpd_anon_rw_t, to write. Creating a bunch of booleans for each daemon that might use the type, seems like a complexity for limited additional security. If I have a server running apache and ftpd, I can't see what the difference if allowing them to read the data via the ftp protocol, but not via the http protocol. But I am willing to be persuaded. > Obviously this is much harder to do but I thought I'd ask anyway :-) > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From marko.bauhardt at web.de Wed Jul 20 19:30:25 2005 From: marko.bauhardt at web.de (Marko Bauhardt) Date: Wed, 20 Jul 2005 21:30:25 +0200 Subject: apache mod_jk Message-ID: <42DEA651.6020705@web.de> Hello all, i have a question about selinux and apache/mod_jk. I use Fedora Core 3. The apache runs flawless (The files in /var/www/html are available). But the connection to the tomcat dont work. The debug output in /var/log/messages: audit(1121888291.180:0): avc: denied { connect } for pid=3388 exe=/usr/sbin/httpd scontext=root:system_r:httpd_t tcontext=root:system_r:httpd_t tclass=tcp_socket if i turned off the selinux with "setenforce 0",the jsps in the tomcat are available. But i think this is a bad workaround to set the enforce to 0. If i execute "setenforce 1" the connection to the tomcat fails. Exist another solution to connect the apache with the tomcat? Must i use the command chcon for the files in my tomcat? From dwalsh at redhat.com Wed Jul 20 19:42:02 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Jul 2005 15:42:02 -0400 Subject: apache mod_jk In-Reply-To: <42DEA651.6020705@web.de> References: <42DEA651.6020705@web.de> Message-ID: <42DEA90A.6040708@redhat.com> Marko Bauhardt wrote: > Hello all, > i have a question about selinux and apache/mod_jk. > I use Fedora Core 3. > The apache runs flawless (The files in /var/www/html are available). > > But the connection to the tomcat dont work. The debug output in > /var/log/messages: > audit(1121888291.180:0): avc: denied { connect } for pid=3388 > exe=/usr/sbin/httpd scontext=root:system_r:httpd_t > tcontext=root:system_r:httpd_t tclass=tcp_socket > > if i turned off the selinux with "setenforce 0",the jsps in the tomcat > are available. But i think this is a bad workaround to set the enforce > to 0. If i execute "setenforce 1" the connection to the tomcat fails. > Exist another solution to connect the apache with the tomcat? > > Must i use the command chcon for the files in my tomcat? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Set boolean httpd_can_network_connect to true. setsebool -P httpd_can_network_connect=1 -- From marko.bauhardt at web.de Wed Jul 20 20:00:19 2005 From: marko.bauhardt at web.de (marko bauhardt) Date: Wed, 20 Jul 2005 22:00:19 +0200 Subject: apache mod_jk In-Reply-To: <42DEA90A.6040708@redhat.com> References: <42DEA651.6020705@web.de> <42DEA90A.6040708@redhat.com> Message-ID: <42DEAD53.5070806@web.de> Daniel J Walsh schrieb: > Set boolean httpd_can_network_connect to true. > setsebool -P httpd_can_network_connect=1 > Thanks a lot for your quick response. I execute these and it works fine. THANKS. From bdouglas at synyati.com.au Thu Jul 21 06:31:49 2005 From: bdouglas at synyati.com.au (Brad Douglas) Date: Thu, 21 Jul 2005 16:31:49 +1000 Subject: Network drop out problem Message-ID: <20050721063012.55B0014077EC@postoffice.omnis.com> Hi, This is my first post here - please be gentle 8). Yesterday I installed FC4 on a HP ML110 proliant server. The plan is to use it as out file server, so I've got samba running on it, along with vnc. The problem I've run into is that the box appears to be running fine, but every now and then _all_ the network connections to my laptop (running XP) disappear and can not reconnect for a few seconds: ssh, samba, vnc - everything. A few seconds later everything is fine again (till the next time). The weirdest thing is that I don't see any disruption pinging the box. I've gone through the samba, message and secure logs and can't see anything obviously wrong. If anyone has an idea what's going on, or even where I could look to diagnose the cause I'd be very grateful. Thanks, B -------------- next part -------------- An HTML attachment was scrubbed... URL: From Igor.Wawrzyniak at shenick.com Thu Jul 21 10:05:52 2005 From: Igor.Wawrzyniak at shenick.com (Igor Wawrzyniak) Date: Thu, 21 Jul 2005 11:05:52 +0100 Subject: Java apps can't use network Message-ID: <200507211105.53034.Igor.Wawrzyniak@shenick.com> Hi, I tried running some Java apps on Fedora Core 4 with SELinux enabled and they can't connect to network. The symptoms are strange (at least for me, I'm new to SELinux): 1) I use TARGETED policy - I thought it shouldn't restrict applications unless they were explicitly listed? 2) I tried setting SELINUX to PERMISSIVE - the apps still couldn't use network. 3) The apps are blocked silently - no info in syslog, regardless of SELINUX mode. All non-Java apps can use the network. All non-network related Java functions seem to work just fine. I tried 2 versions of Sun JRE. Am I doing something wrong or is it a bug? Can I use my Java software without totally disabling SELinux? Regards, Igor Wawrzyniak From paul at city-fan.org Thu Jul 21 10:04:56 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 21 Jul 2005 11:04:56 +0100 Subject: Shared data area In-Reply-To: <42DE8B33.3020108@redhat.com> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <1121842729.25207.344.camel@laurel.intra.city-fan.org> <42DE471C.6050000@redhat.com> <42DE6BCC.9000602@city-fan.org> <42DE8B33.3020108@redhat.com> Message-ID: <1121940296.25207.455.camel@laurel.intra.city-fan.org> On Wed, 2005-07-20 at 13:34 -0400, Daniel J Walsh wrote: > Paul Howarth wrote: > > > Daniel J Walsh wrote: > > > >> Paul Howarth wrote: > >> > >>> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote: > >>> > >>> > >>>> I would encourage a boolean for shared data location. I think > >>>> labeling a folder and it's subcontent with a specific label and > >>>> then have different services be able to use it might be a start. > >>>> That way I could disallow smb the rights but allow ftpd and httpd > >>>> (as an example). I think that would be a great improvment from my > >>>> point of view. > >>>> > >>> > >>> > >>> > >>> I think this is a great idea. I have a file server at home where I > >>> stick > >>> all the software I've downloaded, some for Linux and some for Windows. > >>> The Windows box accesses the area using samba and Linux uses httpd as > >>> I've set up a local yum repo for the Linux software. So in Niklas' idea > >>> I'd be enabling httpd and smb for this and not ftp. > >>> > >>> This type might be a good one to use for everything under /srv... > >>> > >>> Paul. > >>> > >>> > >> Ok. I am allowing ftpd, samba, apache and/or apache scripts, rsync > >> to read ftpd_anon_t. > >> > >> So if you want files shared by these services, you can change the > >> context to ftpd_anon_t. > > > > > > Would it not be better to create a new type for a shared data area > > (e.g. srv_data_t), with booleans allowing read/write access to this > > data for each daemon, rather than overloading an existing type? After > > all, some process has to set up this data area, and for some people > > that will be done using ftp, some sftp, some rsync, some samba etc... > > > I could do that, but I was already sharing the type between rsync and > ftp. Basically I think of this type, as data available on the network > requiring no authorization to read or for ftpd_anon_rw_t, to write. > Creating a bunch of booleans for each daemon that might use the type, > seems like a complexity for limited additional security. If I have a > server running apache and ftpd, I can't see what the difference if > allowing them to read the data via the ftp protocol, but not via the > http protocol. But I am willing to be persuaded. I'd agree on the read side of the discussion. But if you want to maintain this data area using, say, rsync, then you'd need to use ftpd_anon_rw_t to enable writing in the first place, and that would then open up the area to be written by *all* of the daemons unless there were separate write-enable booleans for each daemon. I can certainly see benefits in doing that. Paul. -- Paul Howarth From dragoran at feuerpokemon.de Thu Jul 21 10:16:09 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 21 Jul 2005 12:16:09 +0200 Subject: Java apps can't use network In-Reply-To: <200507211105.53034.Igor.Wawrzyniak@shenick.com> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> Message-ID: <42DF75E9.7040600@feuerpokemon.de> Igor Wawrzyniak wrote: >Hi, > >I tried running some Java apps on Fedora Core 4 with SELinux enabled and they >can't connect to network. The symptoms are strange (at least for me, I'm new >to SELinux): >1) I use TARGETED policy - I thought it shouldn't restrict applications unless >they were explicitly listed? >2) I tried setting SELINUX to PERMISSIVE - the apps still couldn't use >network. >3) The apps are blocked silently - no info in syslog, regardless of SELINUX >mode. > >All non-Java apps can use the network. All non-network related Java functions >seem to work just fine. I tried 2 versions of Sun JRE. > >Am I doing something wrong or is it a bug? Can I use my Java software without >totally disabling SELinux? > >Regards, > >Igor Wawrzyniak > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > which java app? when it still does not work in permissive mode than it isn't an selinux issue. might be a firewall/nat problem which ports are this apps trying to use? From gyurdiev at redhat.com Thu Jul 21 10:28:00 2005 From: gyurdiev at redhat.com (Ivan Gyurdiev) Date: Thu, 21 Jul 2005 06:28:00 -0400 Subject: Java apps can't use network In-Reply-To: <200507211105.53034.Igor.Wawrzyniak@shenick.com> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> Message-ID: <1121941680.19340.30.camel@localhost.localdomain> > 2) I tried setting SELINUX to PERMISSIVE - the apps still couldn't use > network. So what evidence do you have that the problem is caused by SELinux at all? > 3) The apps are blocked silently - no info in syslog, regardless of SELINUX > mode. It sounds like SElinux is not the problem. Permissive mode should not cause any SELinux-related failures unless your applications are directly integrated with SELinux (in which case they should check if selinux is enabled manually). Have you tried if the problem occurs with selinux=disabled? Beware that you might need to relabel the filesystem afterwards if you try that. From Igor.Wawrzyniak at shenick.com Thu Jul 21 10:40:10 2005 From: Igor.Wawrzyniak at shenick.com (Igor Wawrzyniak) Date: Thu, 21 Jul 2005 11:40:10 +0100 Subject: Java apps can't use network In-Reply-To: <1121941680.19340.30.camel@localhost.localdomain> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> <1121941680.19340.30.camel@localhost.localdomain> Message-ID: <200507211140.10651.Igor.Wawrzyniak@shenick.com> On Thursday 21 July 2005 11:28, Ivan Gyurdiev wrote: > > 2) I tried setting SELINUX to PERMISSIVE - the apps still couldn't use > > network. > > So what evidence do you have that the problem is caused > by SELinux at all? Everything works when I disable SELinux. > Have you tried if the problem occurs with selinux=disabled? Of course - I tried all 3 options. Doesn't work with permissive and enforcing, works with disabled. Igor Wawrzyniak From ivg2 at cornell.edu Thu Jul 21 10:50:06 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 21 Jul 2005 06:50:06 -0400 Subject: Java apps can't use network In-Reply-To: <200507211140.10651.Igor.Wawrzyniak@shenick.com> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> <1121941680.19340.30.camel@localhost.localdomain> <200507211140.10651.Igor.Wawrzyniak@shenick.com> Message-ID: <1121943006.19675.16.camel@localhost.localdomain> On Thu, 2005-07-21 at 11:40 +0100, Igor Wawrzyniak wrote: > On Thursday 21 July 2005 11:28, Ivan Gyurdiev wrote: > > > 2) I tried setting SELINUX to PERMISSIVE - the apps still couldn't use > > > network. > > > > So what evidence do you have that the problem is caused > > by SELinux at all? > > Everything works when I disable SELinux. Are the application you're testing open-sourced? If so, which applications... Have you tested with a free JRE, such as gij. > > Have you tried if the problem occurs with selinux=disabled? > > Of course - I tried all 3 options. Doesn't work with permissive and enforcing, > works with disabled. Sounds like a possible kernel bug. Which kernel is this? Did the problem begin to occur on a kernel upgrade or a policy upgrade, or a library upgrade? Are you absolutely sure you tested permissive mode (enforcing=0)? What does /usr/sbin/getenforce say? Try /usr/sbin/setenforce 0. From Igor.Wawrzyniak at shenick.com Thu Jul 21 11:31:37 2005 From: Igor.Wawrzyniak at shenick.com (Igor Wawrzyniak) Date: Thu, 21 Jul 2005 12:31:37 +0100 Subject: Java apps can't use network In-Reply-To: <1121943006.19675.16.camel@localhost.localdomain> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> <200507211140.10651.Igor.Wawrzyniak@shenick.com> <1121943006.19675.16.camel@localhost.localdomain> Message-ID: <200507211231.37365.Igor.Wawrzyniak@shenick.com> On Thursday 21 July 2005 11:50, Ivan Gyurdiev wrote: > Are the application you're testing open-sourced? > If so, which applications... Unfortunately, it's a commercial product. I tried some other Java software and it seems to work. Strange... > Have you tested with a free JRE, such as gij. It doesn't run with gij. > Sounds like a possible kernel bug. Which kernel is this? I tried 2 standard Fedora kernels: kernel-2.6.11-1.1369_FC4 kernel-2.6.12-1.1398_FC4 Other related software: libselinux-1.23.10-2 selinux-policy-targeted-1.25.2-4 > Did the problem begin to occur on a kernel upgrade or a policy > upgrade, or a library upgrade? I only tried it a few days ago, there was no policy or library update since then. Should I try older versions of kernel/library/policy/all of them? > Are you absolutely sure you tested permissive mode (enforcing=0)? > What does /usr/sbin/getenforce say? [root at dhcp-46 ~]# /usr/sbin/getenforce Permissive > Try /usr/sbin/setenforce 0. Tried - nothing changed. Igor Wawrzyniak From russell at coker.com.au Thu Jul 21 11:42:23 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 21 Jul 2005 21:42:23 +1000 Subject: ainit Message-ID: <200507212142.28830.russell@coker.com.au> The attached patch is needed for correct functionality of ainit with the latest strict policy when running reasonably recent rawhide packages. Is this really what we want? Having a system process allocate shared memory that can be used by any user processes? Also it seems likely that other sound programs will need to access the shared memory in question. There are three possible assumptions that we could make: 1) Anyone who is serious about security doesn't use ALSA so such access doesn't matter that much. 2) Sound devices are a channel for communication anyway so it doesn't really grant any new access. NB I don't know enough about sound programming to know whether this assumption is correct. Does ALSA require that a shared memory segment be available to all programs that are accessing the sound device? If so the assumption holds for ALSA. Can an application stuff some data into the sound hardware without using the user-space code from ALSA in such a way that another application can read it? 3) We need to have pam_console launch programs such as ainit in a context determined by the user role. Option 3 might be the best one long-term. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: alsa.diff Type: text/x-diff Size: 1033 bytes Desc: not available URL: From gyurdiev at redhat.com Thu Jul 21 12:19:19 2005 From: gyurdiev at redhat.com (Ivan Gyurdiev) Date: Thu, 21 Jul 2005 08:19:19 -0400 Subject: Java apps can't use network In-Reply-To: <200507211231.37365.Igor.Wawrzyniak@shenick.com> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> <200507211140.10651.Igor.Wawrzyniak@shenick.com> <1121943006.19675.16.camel@localhost.localdomain> <200507211231.37365.Igor.Wawrzyniak@shenick.com> Message-ID: <1121948360.3072.2.camel@celtics.boston.redhat.com> > > Sounds like a possible kernel bug. Which kernel is this? > > I tried 2 standard Fedora kernels: > kernel-2.6.11-1.1369_FC4 > kernel-2.6.12-1.1398_FC4 > > Other related software: > libselinux-1.23.10-2 > selinux-policy-targeted-1.25.2-4 > > > Did the problem begin to occur on a kernel upgrade or a policy > > upgrade, or a library upgrade? > > I only tried it a few days ago, there was no policy or library update since > then. Should I try older versions of kernel/library/policy/all of them? Did you try it multiple times... are you sure there's a correlation between enforcing status and app working/not working? From Igor.Wawrzyniak at shenick.com Thu Jul 21 13:05:56 2005 From: Igor.Wawrzyniak at shenick.com (Igor Wawrzyniak) Date: Thu, 21 Jul 2005 14:05:56 +0100 Subject: Java apps can't use network In-Reply-To: <1121948360.3072.2.camel@celtics.boston.redhat.com> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> <200507211231.37365.Igor.Wawrzyniak@shenick.com> <1121948360.3072.2.camel@celtics.boston.redhat.com> Message-ID: <200507211405.56461.Igor.Wawrzyniak@shenick.com> On Thursday 21 July 2005 13:19, Ivan Gyurdiev wrote: > Did you try it multiple times... are you sure there's a correlation > between enforcing status and app working/not working? I did. Every time I reboot with selinux disabled, it works, everytime it's enabled - it doesn't. I also tried the app with the newest JRE from Sun - and it works even in enforcing mode. The deeper I dig into it, the stranger it gets. Looks like the bug is only triggered by a very specific software combination, probably it would be hard to reproduce for anyone else. How can I got more information? Any way to look into kernel internals? Igor Wawrzyniak From exinor at exinor.net Thu Jul 21 14:09:49 2005 From: exinor at exinor.net (Nicklas Norling) Date: Thu, 21 Jul 2005 16:09:49 +0200 Subject: Shared data area In-Reply-To: <1121940296.25207.455.camel@laurel.intra.city-fan.org> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <1121842729.25207.344.camel@laurel.intra.city-fan.org> <42DE471C.6050000@redhat.com> <42DE6BCC.9000602@city-fan.org> <42DE8B33.3020108@redhat.com> <1121940296.25207.455.camel@laurel.intra.city-fan.org> Message-ID: <42DFACAD.8030407@exinor.net> Paul Howarth wrote: >On Wed, 2005-07-20 at 13:34 -0400, Daniel J Walsh wrote: > > >>Paul Howarth wrote: >> >> >> >>>Daniel J Walsh wrote: >>> >>> >>> >>>>Paul Howarth wrote: >>>> >>>> >>>> >>>>>On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>I would encourage a boolean for shared data location. I think >>>>>>labeling a folder and it's subcontent with a specific label and >>>>>>then have different services be able to use it might be a start. >>>>>>That way I could disallow smb the rights but allow ftpd and httpd >>>>>>(as an example). I think that would be a great improvment from my >>>>>>point of view. >>>>>> >>>>>> >>>>>> >>>>> >>>>>I think this is a great idea. I have a file server at home where I >>>>>stick >>>>>all the software I've downloaded, some for Linux and some for Windows. >>>>>The Windows box accesses the area using samba and Linux uses httpd as >>>>>I've set up a local yum repo for the Linux software. So in Niklas' idea >>>>>I'd be enabling httpd and smb for this and not ftp. >>>>> >>>>>This type might be a good one to use for everything under /srv... >>>>> >>>>>Paul. >>>>> >>>>> >>>>> >>>>> >>>>Ok. I am allowing ftpd, samba, apache and/or apache scripts, rsync >>>>to read ftpd_anon_t. >>>> >>>>So if you want files shared by these services, you can change the >>>>context to ftpd_anon_t. >>>> >>>> >>>Would it not be better to create a new type for a shared data area >>>(e.g. srv_data_t), with booleans allowing read/write access to this >>>data for each daemon, rather than overloading an existing type? After >>>all, some process has to set up this data area, and for some people >>>that will be done using ftp, some sftp, some rsync, some samba etc... >>> >>> >>> >>I could do that, but I was already sharing the type between rsync and >>ftp. Basically I think of this type, as data available on the network >>requiring no authorization to read or for ftpd_anon_rw_t, to write. >>Creating a bunch of booleans for each daemon that might use the type, >>seems like a complexity for limited additional security. If I have a >>server running apache and ftpd, I can't see what the difference if >>allowing them to read the data via the ftp protocol, but not via the >>http protocol. But I am willing to be persuaded. >> >> > >I'd agree on the read side of the discussion. But if you want to >maintain this data area using, say, rsync, then you'd need to use >ftpd_anon_rw_t to enable writing in the first place, and that would then >open up the area to be written by *all* of the daemons unless there were >separate write-enable booleans for each daemon. I can certainly see >benefits in doing that. > >Paul. > > I suppose one could argue that the daemon in question should be set up correctly. read-only or read-write as appropriate. Selinux should not do the applications job or there would be dual systems to keep in sync when policies changes. But I do see your point. I'm afraid I don't know enough about selinux to comment further. Just wanteded to play the devils advocate for awhile. /Nicke From exinor at exinor.net Thu Jul 21 14:15:52 2005 From: exinor at exinor.net (Nicklas Norling) Date: Thu, 21 Jul 2005 16:15:52 +0200 Subject: Squirrelmail forward plugin Message-ID: <42DFAE18.6090307@exinor.net> Hi. Just noted a user tried to add .forward by using the forwarding module in squirrelmail. Jul 20 00:56:52 spock kernel: audit(1121813812.917:1844): avc: denied { setgid } for pid=24466 comm="wfwd" capability=6 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability httpd log: /usr/local/sbin/wfwd: Operation not permitted [root at spock html]# audit2allow -d -l allow httpd_sys_script_t self:capability setgid; The tool used is wfwd. httpd booleans: httpd_builtin_scripting active httpd_can_network_connect active httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_suexec_disable_trans inactive httpd_tty_comm inactive httpd_unified active I wonder what will happen when a user tries to change the password using the change password plugin... /Nicke From cpebenito at tresys.com Thu Jul 21 14:50:24 2005 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Thu, 21 Jul 2005 10:50:24 -0400 Subject: ainit In-Reply-To: <200507212142.28830.russell@coker.com.au> References: <200507212142.28830.russell@coker.com.au> Message-ID: <1121957424.13068.53.camel@sgc.columbia.tresys.com> On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote: > Is this really what we want? Having a system process allocate shared memory > that can be used by any user processes? Also it seems likely that other > sound programs will need to access the shared memory in question. > > There are three possible assumptions that we could make: > > 1) Anyone who is serious about security doesn't use ALSA so such > access doesn't matter that much. This isn't the case. ALSA isn't any different then OSS from a SELinux viewpoint. I don't have ainit on any of my Gentoo machines; after a few minutes on Google, it seems that this is a Redhat/Fedora specific program. > 2) Sound devices are a channel for communication anyway so it doesn't > really grant any new access. I don't see any SysV IPC objects on my machines that use ALSA, so it seems that ALSA has an optional feature that uses IPC, but it is not required for playing or recording sound. > Does ALSA require that a shared memory segment be available to all > programs that are accessing the sound device? This is the important question to ask of this feature. > Can an application stuff some data into the sound hardware without > using the user-space code from ALSA in such a way that another > application can read it? Adding in shared memory access between all user domains is a much easier channel for communication then a sound device is; it doesn't need to go through the hardware since all user domains can read and write the segments. > 3) We need to have pam_console launch programs such as ainit in a context > determined by the user role. Probably the right answer if the shared memory doesn't have to be shared between all user domains. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From walters at redhat.com Thu Jul 21 14:55:46 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 21 Jul 2005 10:55:46 -0400 Subject: ainit In-Reply-To: <200507212142.28830.russell@coker.com.au> References: <200507212142.28830.russell@coker.com.au> Message-ID: <1121957746.15247.5.camel@nexus.verbum.private> On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote: > Does ALSA require that a shared > memory segment be available to all programs that are accessing the sound > device? This is a consequence of switching to the ALSA "dmix" device by default, which does transparent sound mixing in userspace via the shared memory. This fixes the extremely user-visible bug of multiple applications not being able to use the sound card at the same time. Fundamentally though the IPC key doesn't have to be allocated by the system; I wrote some code a while back that would have allocated it as part of the X login, all in the normal user session so there was no "system" part involved. I'm still not sure why our ALSA maintainer chose the ainit/PAM route given that you don't care about sound mixing for any other means of logging in like ssh or virtual terminal. Or at least, I don't think we should care. From walters at redhat.com Thu Jul 21 14:59:57 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 21 Jul 2005 10:59:57 -0400 Subject: ainit In-Reply-To: <1121957424.13068.53.camel@sgc.columbia.tresys.com> References: <200507212142.28830.russell@coker.com.au> <1121957424.13068.53.camel@sgc.columbia.tresys.com> Message-ID: <1121957997.15247.9.camel@nexus.verbum.private> On Thu, 2005-07-21 at 10:50 -0400, Christopher J. PeBenito wrote: > On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote: > > Is this really what we want? Having a system process allocate shared memory > > that can be used by any user processes? Also it seems likely that other > > sound programs will need to access the shared memory in question. > > > > There are three possible assumptions that we could make: > > > > 1) Anyone who is serious about security doesn't use ALSA so such > > access doesn't matter that much. > > This isn't the case. ALSA isn't any different then OSS from a SELinux > viewpoint. I don't have ainit on any of my Gentoo machines; after a few > minutes on Google, it seems that this is a Redhat/Fedora specific > program. At the moment possibly, but I'm sure other systems will want to unbreak their sound eventually too :) > Probably the right answer if the shared memory doesn't have to be shared > between all user domains. It needs to be accessible to any program that wants to play sound. From dwalsh at redhat.com Fri Jul 22 12:41:10 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 22 Jul 2005 08:41:10 -0400 Subject: Shared data area In-Reply-To: <42DFACAD.8030407@exinor.net> References: <42D90B95.1090104@exinor.net> <42DBF76B.1040708@redhat.com> <42DCE035.4080206@exinor.net> <1121842729.25207.344.camel@laurel.intra.city-fan.org> <42DE471C.6050000@redhat.com> <42DE6BCC.9000602@city-fan.org> <42DE8B33.3020108@redhat.com> <1121940296.25207.455.camel@laurel.intra.city-fan.org> <42DFACAD.8030407@exinor.net> Message-ID: <42E0E966.1080602@redhat.com> Nicklas Norling wrote: > Paul Howarth wrote: > >> On Wed, 2005-07-20 at 13:34 -0400, Daniel J Walsh wrote: >> >> >>> Paul Howarth wrote: >>> >>> >>> >>>> Daniel J Walsh wrote: >>>> >>>> >>>> >>>>> Paul Howarth wrote: >>>>> >>>>> >>>>> >>>>>> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I would encourage a boolean for shared data location. I think >>>>>>> labeling a folder and it's subcontent with a specific label and >>>>>>> then have different services be able to use it might be a start. >>>>>>> That way I could disallow smb the rights but allow ftpd and >>>>>>> httpd (as an example). I think that would be a great improvment >>>>>>> from my point of view. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> I think this is a great idea. I have a file server at home where >>>>>> I stick >>>>>> all the software I've downloaded, some for Linux and some for >>>>>> Windows. >>>>>> The Windows box accesses the area using samba and Linux uses >>>>>> httpd as >>>>>> I've set up a local yum repo for the Linux software. So in >>>>>> Niklas' idea >>>>>> I'd be enabling httpd and smb for this and not ftp. >>>>>> >>>>>> This type might be a good one to use for everything under /srv... >>>>>> >>>>>> Paul. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Ok. I am allowing ftpd, samba, apache and/or apache scripts, >>>>> rsync to read ftpd_anon_t. >>>>> >>>>> So if you want files shared by these services, you can change the >>>>> context to ftpd_anon_t. >>>>> >>>> >>>> Would it not be better to create a new type for a shared data area >>>> (e.g. srv_data_t), with booleans allowing read/write access to this >>>> data for each daemon, rather than overloading an existing type? >>>> After all, some process has to set up this data area, and for some >>>> people that will be done using ftp, some sftp, some rsync, some >>>> samba etc... >>>> >>>> >>> >>> I could do that, but I was already sharing the type between rsync >>> and ftp. Basically I think of this type, as data available on the >>> network requiring no authorization to read or for ftpd_anon_rw_t, to >>> write. Creating a bunch of booleans for each daemon that might use >>> the type, seems like a complexity for limited additional security. >>> If I have a server running apache and ftpd, I can't see what the >>> difference if allowing them to read the data via the ftp protocol, >>> but not via the http protocol. But I am willing to be persuaded. >>> >> >> >> I'd agree on the read side of the discussion. But if you want to >> maintain this data area using, say, rsync, then you'd need to use >> ftpd_anon_rw_t to enable writing in the first place, and that would then >> open up the area to be written by *all* of the daemons unless there were >> separate write-enable booleans for each daemon. I can certainly see >> benefits in doing that. >> >> Paul. >> >> > I suppose one could argue that the daemon in question should be set up > correctly. read-only or read-write as appropriate. Selinux should not > do the applications job or there would be dual systems to keep in sync > when policies changes. But I do see your point. I'm afraid I don't > know enough about selinux to comment further. Just wanteded to play > the devils advocate for awhile. > /Nicke > Ok, I will add booleans for all "shared" domains to write to ftpd_anon_rw_t > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From fedora at grifent.com Fri Jul 22 16:44:28 2005 From: fedora at grifent.com (John Griffiths) Date: Fri, 22 Jul 2005 12:44:28 -0400 Subject: users public_html access In-Reply-To: <20050722160052.5BC6873CBD@hormel.redhat.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> Message-ID: <42E1226C.9000305@grifent.com> I cannot get users public_html content to publish in FC4. I keep getting "You don't have permission to access /~/ on this server." I can access the user's public_html when I change SELinux to Permissive. I searched the archives and did not find anything, and I followed the direction in section 4 of "Understanding and Customizing the Apache HTTP SELinux Policy" which was written for FC3. The httpd booleans are: httpd_builtin_scripting active httpd_can_network_connect active httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_suexec_disable_trans inactive httpd_tty_comm inactive httpd_unified active The security setting on the user's public_html and the files in the directory is user_u:object_r:httpd_sys_content_t . Obviously the standard UGW permissions are OK since turning off SELinux allows the content to be accessed. What am I missing, or is this a bug? Thanks, John Griffiths From dwalsh at redhat.com Fri Jul 22 17:21:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 22 Jul 2005 13:21:24 -0400 Subject: users public_html access In-Reply-To: <42E1226C.9000305@grifent.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> Message-ID: <42E12B14.3010605@redhat.com> John Griffiths wrote: > I cannot get users public_html content to publish in FC4. I keep > getting "You don't have permission to access /~/ on this > server." I can access the user's public_html when I change SELinux to > Permissive. > > I searched the archives and did not find anything, and I followed the > direction in section 4 of "Understanding and Customizing the Apache > HTTP SELinux Policy" which was written for FC3. > > The httpd booleans are: > httpd_builtin_scripting active > httpd_can_network_connect active > httpd_disable_trans inactive > httpd_enable_cgi active > httpd_enable_homedirs active > httpd_ssi_exec active > httpd_suexec_disable_trans inactive > httpd_tty_comm inactive > httpd_unified active > > The security setting on the user's public_html and the files in the > directory is user_u:object_r:httpd_sys_content_t . Obviously the > standard UGW permissions are OK since turning off SELinux allows the > content to be accessed. > > What am I missing, or is this a bug? > > Thanks, > John Griffiths > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Any avc messages? -- From fedora at grifent.com Fri Jul 22 18:42:22 2005 From: fedora at grifent.com (John Griffiths) Date: Fri, 22 Jul 2005 14:42:22 -0400 Subject: users public_html access In-Reply-To: <42E12B14.3010605@redhat.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> <42E12B14.3010605@redhat.com> Message-ID: <42E13E0E.4040503@grifent.com> An HTML attachment was scrubbed... URL: From ktl at bornet.net Sat Jul 23 17:33:47 2005 From: ktl at bornet.net (Tomas Larsson) Date: Sat, 23 Jul 2005 19:33:47 +0200 Subject: Is selinux breaking up syslogd Message-ID: As mentioned before, I cant get syslogd to run properly. It seems that selinux is blocking syslogd. type=AVC msg=audit(1122120398.858:801833): avc: denied { read } for pid=4595 comm="syslogd" name="syslog.conf" dev=dm-0 ino=653814 scontext=root:system_r:syslogd_t tcontext=system_u:object_r:etc_runtime_t tclass=file type=SYSCALL msg=audit(1122120398.858:801833): arch=40000003 syscall=5 success=no exit=-13 a0=d448c6 a1=0 a2=1b6 a3=9cd1298 items=1 pid=4595 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="syslogd" exe="/sbin/syslogd" If I understand this correctly selinux is stopping syslogd to read syslog.conf. How do I do to get it to work, there is no reference in the selinux man-pages to syslogd. With best regards Tomas Larsson Sweden Verus Amicus Est Tamquam Alter Idem -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3018 bytes Desc: not available URL: From bobk at ocf.berkeley.edu Sat Jul 23 18:30:38 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Sat, 23 Jul 2005 11:30:38 -0700 Subject: Is selinux breaking up syslogd In-Reply-To: References: Message-ID: <1122143439.27942.3.camel@chaucer> On Sat, 2005-07-23 at 19:33 +0200, Tomas Larsson wrote: > As mentioned before, I cant get syslogd to run properly. > > It seems that selinux is blocking syslogd. > > type=AVC msg=audit(1122120398.858:801833): avc: denied { read } for > pid=4595 comm="syslogd" name="syslog.conf" dev=dm-0 ino=653814 > scontext=root:system_r:syslogd_t tcontext=system_u:object_r:etc_runtime_t > tclass=file > type=SYSCALL msg=audit(1122120398.858:801833): arch=40000003 syscall=5 > success=no exit=-13 a0=d448c6 a1=0 a2=1b6 a3=9cd1298 items=1 pid=4595 > auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > comm="syslogd" exe="/sbin/syslogd" > > If I understand this correctly selinux is stopping syslogd to read > syslog.conf. > > How do I do to get it to work, there is no reference in the selinux > man-pages to syslogd. > With best regards The file context that I have for /etc/syslog.conf on FC3 & FC4: [medieval at chaucer etc]$ ls -Z /etc/syslog.conf -rw-r--r-- root root system_u:object_r:etc_t /etc/syslog.conf Have you tried doing a "touch /.autorelabel" and rebooting? Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From bdouglas at synyati.com.au Sun Jul 24 22:49:58 2005 From: bdouglas at synyati.com.au (Brad Douglas) Date: Mon, 25 Jul 2005 08:49:58 +1000 Subject: Network drop out problem Message-ID: <20050724224816.3C03C1880C39@postoffice.omnis.com> Found the problem. Someone had set up a Maxtor network storage device on the same IP addr I was getting through DHCP. Many thanks to those who responded. >From: Brad Douglas >Sent: Thursday, 21 July 2005 4:32 PM >To: 'fedora-selinux-list at redhat.com' >Subject: Network drop out problem >Hi, >This is my first post here - please be gentle 8). >Yesterday I installed FC4 on a HP ML110 proliant server. The plan is to use it as out file server, so I've got samba running on it, along with vnc. >The problem I've run into is that the box appears to be running fine, but every now and then _all_ the network connections to my >laptop (running XP) disappear and can not reconnect for a few seconds: ssh, samba, vnc - everything. A few seconds later everything is fine again (till the next time). The weirdest thing is that I don't see any disruption pinging the box. >I've gone through the samba, message and secure logs and can't see anything obviously wrong. >If anyone has an idea what's going on, or even where I could look to diagnose the cause I'd be very grateful. >Thanks, >B -------------- next part -------------- An HTML attachment was scrubbed... URL: From ejtr at layer3.co.uk Mon Jul 25 08:36:39 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Mon, 25 Jul 2005 09:36:39 +0100 Subject: pam-0.79-9.1 breakage with FC4 strict policy. Message-ID: <1122280599.3371.62.camel@topaz.bugfinder.co.uk> I have recently updated the pam rpm on my FC4 machine from: pam-0.79-8 to pam-0.79-9.1 The machine was orginally built as FC3 running SELinux strict/enforcing, upgraded to FC4, "/.autorelabel"'ed, and thereafter gradually patched up with FC4 updates using yum. The SELinux policy is using: selinux-policy-strict-1.23.16-6 The current pam misbehaviour for a variety of authentication sequences is as follows: ======================================== With SELinux enforcing and pam-0.79-9.1: "su -" works Ok. ( both su-ing to root and non-root users. ) "sudo" fails every time with: sudo: pam_authenticate: System error "/bin/login" fails every time with only these messages in syslog: Jul 25 08:45:31 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, System error Jul 25 08:45:31 topaz kernel: audit(1122277531.083:24): avc: denied { lock } for pid=5704 comm="login" name="btmp" dev=hda7 ino=339558 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:faillog_t tclass=file "ssh localhost" fails every time with: Jul 25 08:48:31 topaz sshd[14927]: error: Could not get shadow information for ejtr Jul 25 08:48:31 topaz sshd[14927]: Failed password for ejtr from 127.0.0.1 port 50117 ssh2 ========================================= With SELinux permissive and pam-0.79-9.1: "su -" works Ok. ( both su-ing to root and non-root users. ) "sudo" fails 1st time with: sudo: pam_authenticate: System error and then succeeds 2nd time - but still asks for password. On the 3rd attempt it caches the authentication from the 2nd attempt and works Ok. "/bin/login" appears to fail twice and then succeed. Jul 25 08:53:07 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, System error Jul 25 08:53:07 topaz kernel: audit(1122277987.276:26): avc: denied { lock } for pid=5767 comm="login" name="btmp" dev=hda7 ino=339558 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:faillog_t tclass=file Jul 25 08:53:11 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, System error Jul 25 08:53:11 topaz kernel: audit(1122277991.339:27): avc: denied { lock } for pid=10278 comm="login" name="btmp" dev=hda7 ino=339558 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:faillog_t tclass=file Jul 25 08:53:15 topaz login(pam_unix)[10621]: session opened for user ejtr by (uid=0) Jul 25 08:53:15 topaz -- ejtr[10621]: LOGIN ON tty2 BY ejtr Jul 25 08:53:19 topaz login(pam_unix)[10621]: session closed for user ejtr Jul 25 08:53:25 topaz login(pam_unix)[11502]: session opened for user ejtr by (uid=0) Jul 25 08:53:25 topaz -- ejtr[11502]: LOGIN ON tty2 BY ejtr Jul 25 08:53:27 topaz login(pam_unix)[11502]: session closed for user ejtr "ssh localhost" works 1st time. =============================================== When I saw the "shadow" error on sshd, I tried adding some "debug" to SELinux policy to double check that the correct domain was trying to read shadow_t. That proved to be a red-herring, as did tracking the lock access denial on /var/log/btmp. I've checked SELinux file_contexts on the pam installed files - seems Ok. I've tried downgrading pam to 0.79-8 and back to 0.79-9.1 again. The system consistently works every time with 0.79-8 and misbehaves every time with 0.79-9.1 Amongst the trail of debugging, I've found a couple of pam errors which are seemingly unrelated to the overall failure, but probably need fixing: This: allow crond_t self:capability { audit_control } ; seems to be needed to allow per-user crontab's to audit correctly. There seems to be some inconsistency in the use and non-use of pam_loginuid.so and pam_selinux.so in /etc/pam.d/XXXX as between /etc/pam.d/su /etc/pam.d/sudo /etc/pam.d/login /etc/pam.d/gdm /etc/pam.d/sshd I would have thought that most, if not all, of the pam.d configurations should have pam_loginuid.so and pam_selinux.so references, but I could so easily be wrong about this. I also noticed that the FC3 -> FC4 upgrade process failed to automatically install the "audit" rpm. I manually added it via yum whilst tracking the pam problem, but the lack of the auditd service also seems to be a red-herring. I currently have it installed but chkconfig'ed off - mainly so as to ensure all the logs are in one place for ease of debugging. I've tried temporarily disabling various clauses in /etc/pam.d/login - such as pam_console - to try and isolate the issue, but I haven't had much luck with that either. With "debug" enabled on the pam_stack.so entry in /etc/pam.d/login, it seems that "system-auth" always returns SUCCESS, which seems to eliminate most of pam as a source of error. Can anyone throw any light on the problem or give me some other ideas for debugging the issue? Thanks, -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From sds at tycho.nsa.gov Mon Jul 25 14:12:23 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 25 Jul 2005 10:12:23 -0400 Subject: Java apps can't use network In-Reply-To: <200507211405.56461.Igor.Wawrzyniak@shenick.com> References: <200507211105.53034.Igor.Wawrzyniak@shenick.com> <200507211231.37365.Igor.Wawrzyniak@shenick.com> <1121948360.3072.2.camel@celtics.boston.redhat.com> <200507211405.56461.Igor.Wawrzyniak@shenick.com> Message-ID: <1122300743.2351.37.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-07-21 at 14:05 +0100, Igor Wawrzyniak wrote: > I did. Every time I reboot with selinux disabled, it works, everytime it's > enabled - it doesn't. > > I also tried the app with the newest JRE from Sun - and it works even in > enforcing mode. The deeper I dig into it, the stranger it gets. > > Looks like the bug is only triggered by a very specific software combination, > probably it would be hard to reproduce for anyone else. How can I got more > information? Any way to look into kernel internals? Can you run it under strace and reproduce the failure there, and then bugzilla it and attach the strace output to the bugzilla report? -- Stephen Smalley National Security Agency From tmerritt at email.arizona.edu Mon Jul 25 14:16:34 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Mon, 25 Jul 2005 07:16:34 -0700 Subject: strict policy Message-ID: <1122300995.4494.32.camel@hive.ccit.arizona.edu> I'm getting started with selinux on FC 4. I'm using the strict policy, but I'd like to restrict it further so that users can only execute a handful of commands. I've tried replacing full_user_role(user_t) with limit_user role, but the drew assertion errors when trying to load the policy, and I tried removing restricting the can_exec in both full and limited_user_role macros in macros/user_macros.te, but (at least from looking at audit to allow) none of this seems to be getting me where I want to be. What is the beast way to remove all access from user_t so that I can add in the commands I want them to be able to run ? Thanks, Todd From sds at tycho.nsa.gov Mon Jul 25 14:18:53 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 25 Jul 2005 10:18:53 -0400 Subject: ainit In-Reply-To: <200507212142.28830.russell@coker.com.au> References: <200507212142.28830.russell@coker.com.au> Message-ID: <1122301133.2351.44.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote: > The attached patch is needed for correct functionality of ainit with the > latest strict policy when running reasonably recent rawhide packages. > > Is this really what we want? Having a system process allocate shared memory > that can be used by any user processes? Also it seems likely that other > sound programs will need to access the shared memory in question. Not a good idea. Look at nscd handling for its shmem interface; we use an attribute to allow certain domains such access, but most domains are limited to the socket IPC-based interface. This program should likewise have some kind of fallback to an IPC-based interface if the shmem interface isn't allowed. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Jul 25 14:24:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Jul 2005 10:24:13 -0400 Subject: users public_html access In-Reply-To: <42E13E0E.4040503@grifent.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> <42E12B14.3010605@redhat.com> <42E13E0E.4040503@grifent.com> Message-ID: <42E4F60D.1030405@redhat.com> John Griffiths wrote: > None when I try to access the user's public_html. There are some from > when I turned enforcing off and back on. > > Jul 22 12:35:07 gei dbus: avc: received setenforce notice > (enforcing=0) > Jul 22 12:35:07 gei dbus: avc: received setenforce notice > (enforcing=0) > Jul 22 12:36:01 gei dbus: avc: received setenforce notice > (enforcing=1) > Jul 22 12:36:01 gei dbus: avc: received setenforce notice > (enforcing=1) > > That was when I was confirming that I could see the user's public_html. > You looked in both /var/log/audit/audit.log and /var/log/messages? > John > > Daniel J Walsh wrote: > >> John Griffiths wrote: >> >>> I cannot get users public_html content to publish in FC4. I keep >>> getting "You don't have permission to access /~/ on this >>> server." I can access the user's public_html when I change SELinux >>> to Permissive. >>> >>> I searched the archives and did not find anything, and I followed >>> the direction in section 4 of "Understanding and Customizing the >>> Apache HTTP SELinux Policy" which was written for FC3. >>> >>> The httpd booleans are: >>> httpd_builtin_scripting active >>> httpd_can_network_connect active >>> httpd_disable_trans inactive >>> httpd_enable_cgi active >>> httpd_enable_homedirs active >>> httpd_ssi_exec active >>> httpd_suexec_disable_trans inactive >>> httpd_tty_comm inactive >>> httpd_unified active >>> >>> The security setting on the user's public_html and the files in the >>> directory is user_u:object_r:httpd_sys_content_t . Obviously the >>> standard UGW permissions are OK since turning off SELinux allows the >>> content to be accessed. >>> >>> What am I missing, or is this a bug? >>> >>> Thanks, >>> John Griffiths >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> Any avc messages? >> -- From dwalsh at redhat.com Mon Jul 25 14:27:28 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Jul 2005 10:27:28 -0400 Subject: Is selinux breaking up syslogd In-Reply-To: References: Message-ID: <42E4F6D0.2000900@redhat.com> Tomas Larsson wrote: >As mentioned before, I cant get syslogd to run properly. > >It seems that selinux is blocking syslogd. > >type=AVC msg=audit(1122120398.858:801833): avc: denied { read } for >pid=4595 comm="syslogd" name="syslog.conf" dev=dm-0 ino=653814 >scontext=root:system_r:syslogd_t tcontext=system_u:object_r:etc_runtime_t >tclass=file >type=SYSCALL msg=audit(1122120398.858:801833): arch=40000003 syscall=5 >success=no exit=-13 a0=d448c6 a1=0 a2=1b6 a3=9cd1298 items=1 pid=4595 >auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 >comm="syslogd" exe="/sbin/syslogd" > >If I understand this correctly selinux is stopping syslogd to read >syslog.conf. > >How do I do to get it to work, there is no reference in the selinux >man-pages to syslogd. >With best regards > > > You can just restorecon /etc/syslog.conf. Is there some startup script that is rewriting this file? Context of syslog.conf is supposed to be etc_t, if a startup script was creating the file it would be etc_runtime_t. I can add the permissision if this is a normal occurrance. >Tomas Larsson >Sweden > >Verus Amicus Est Tamquam Alter Idem > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From dwalsh at redhat.com Mon Jul 25 14:32:26 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Jul 2005 10:32:26 -0400 Subject: pam-0.79-9.1 breakage with FC4 strict policy. In-Reply-To: <1122280599.3371.62.camel@topaz.bugfinder.co.uk> References: <1122280599.3371.62.camel@topaz.bugfinder.co.uk> Message-ID: <42E4F7FA.8010106@redhat.com> Ted Rule wrote: >I have recently updated the pam rpm on my FC4 machine from: > > pam-0.79-8 > >to > > pam-0.79-9.1 > >The machine was orginally built as FC3 running SELinux strict/enforcing, >upgraded to FC4, "/.autorelabel"'ed, and thereafter gradually patched up >with FC4 updates using yum. The SELinux policy is using: > > selinux-policy-strict-1.23.16-6 > >The current pam misbehaviour for a variety of authentication sequences >is as follows: > >======================================== >With SELinux enforcing and pam-0.79-9.1: > >"su -" works Ok. ( both su-ing to root and non-root users. ) > >"sudo" fails every time with: > > sudo: pam_authenticate: System error > >"/bin/login" fails every time with only these messages in syslog: > >Jul 25 08:45:31 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, >System error >Jul 25 08:45:31 topaz kernel: audit(1122277531.083:24): avc: denied >{ lock } for pid=5704 comm="login" name="btmp" dev=hda7 ino=339558 >scontext=system_u:system_r:local_login_t >tcontext=system_u:object_r:faillog_t tclass=file > >"ssh localhost" fails every time with: > >Jul 25 08:48:31 topaz sshd[14927]: error: Could not get shadow >information for ejtr >Jul 25 08:48:31 topaz sshd[14927]: Failed password for ejtr from >127.0.0.1 port 50117 ssh2 > >========================================= >With SELinux permissive and pam-0.79-9.1: > >"su -" works Ok. ( both su-ing to root and non-root users. ) > >"sudo" fails 1st time with: > > sudo: pam_authenticate: System error > >and then succeeds 2nd time - but still asks for password. On the 3rd >attempt it caches the authentication from the 2nd attempt and works Ok. > > >"/bin/login" appears to fail twice and then succeed. > >Jul 25 08:53:07 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, >System error >Jul 25 08:53:07 topaz kernel: audit(1122277987.276:26): avc: denied >{ lock } for pid=5767 comm="login" name="btmp" dev=hda7 ino=339558 >scontext=system_u:system_r:local_login_t >tcontext=system_u:object_r:faillog_t tclass=file >Jul 25 08:53:11 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, >System error >Jul 25 08:53:11 topaz kernel: audit(1122277991.339:27): avc: denied >{ lock } for pid=10278 comm="login" name="btmp" dev=hda7 ino=339558 >scontext=system_u:system_r:local_login_t >tcontext=system_u:object_r:faillog_t tclass=file >Jul 25 08:53:15 topaz login(pam_unix)[10621]: session opened for user >ejtr by (uid=0) >Jul 25 08:53:15 topaz -- ejtr[10621]: LOGIN ON tty2 BY ejtr >Jul 25 08:53:19 topaz login(pam_unix)[10621]: session closed for user >ejtr >Jul 25 08:53:25 topaz login(pam_unix)[11502]: session opened for user >ejtr by (uid=0) >Jul 25 08:53:25 topaz -- ejtr[11502]: LOGIN ON tty2 BY ejtr >Jul 25 08:53:27 topaz login(pam_unix)[11502]: session closed for user >ejtr > > >"ssh localhost" works 1st time. > >=============================================== > > >When I saw the "shadow" error on sshd, I tried adding some "debug" to >SELinux policy to double check that the correct domain was trying to >read shadow_t. That proved to be a red-herring, as did tracking the lock >access denial on /var/log/btmp. > >I've checked SELinux file_contexts on the pam installed files - seems >Ok. I've tried downgrading pam to 0.79-8 and back to 0.79-9.1 again. The >system consistently works every time with 0.79-8 and misbehaves every >time with 0.79-9.1 > >Amongst the trail of debugging, I've found a couple of pam errors which >are seemingly unrelated to the overall failure, but probably need >fixing: > >This: > > allow crond_t self:capability { audit_control } ; > >seems to be needed to allow per-user crontab's to audit correctly. > >There seems to be some inconsistency in the use and non-use of >pam_loginuid.so and pam_selinux.so in /etc/pam.d/XXXX as between > > /etc/pam.d/su > /etc/pam.d/sudo > /etc/pam.d/login > /etc/pam.d/gdm > /etc/pam.d/sshd > >I would have thought that most, if not all, of the pam.d configurations >should have pam_loginuid.so and pam_selinux.so references, but I could >so easily be wrong about this. > >I also noticed that the FC3 -> FC4 upgrade process failed to >automatically install the "audit" rpm. I manually added it via yum >whilst tracking the pam problem, but the lack of the auditd service also >seems to be a red-herring. I currently have it installed but >chkconfig'ed off - mainly so as to ensure all the logs are in one place >for ease of debugging. > >I've tried temporarily disabling various clauses in /etc/pam.d/login - >such as pam_console - to try and isolate the issue, but I haven't had >much luck with that either. With "debug" enabled on the pam_stack.so >entry in /etc/pam.d/login, it seems that "system-auth" always returns >SUCCESS, which seems to eliminate most of pam as a source of error. > >Can anyone throw any light on the problem or give me some other ideas >for debugging the issue? > > >Thanks, > > > > All of these fixes are in the latest policy available for FC4 -- From dwalsh at redhat.com Mon Jul 25 14:39:12 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Jul 2005 10:39:12 -0400 Subject: strict policy In-Reply-To: <1122300995.4494.32.camel@hive.ccit.arizona.edu> References: <1122300995.4494.32.camel@hive.ccit.arizona.edu> Message-ID: <42E4F990.3030803@redhat.com> Todd Merritt wrote: >I'm getting started with selinux on FC 4. I'm using the strict policy, >but I'd like to restrict it further so that users can only execute a >handful of commands. I've tried replacing full_user_role(user_t) with >limit_user role, but the drew assertion errors when trying to load the >policy, and I tried removing restricting the can_exec in both full and >limited_user_role macros in macros/user_macros.te, but (at least from >looking at audit to allow) none of this seems to be getting me where I >want to be. What is the beast way to remove all access from user_t so >that I can add in the commands I want them to be able to run ? > > > First update to the latest rawhide strict policy. We have not been updating strict policy for FC4. Then you probably need to remove can_exec lines from base_user_macros. Problem is eliminating them might set you up with a solution where a user can not login. Are you doing this with a X Windows System, or a server? >Thanks, >Todd > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From tmerritt at email.arizona.edu Mon Jul 25 14:42:43 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Mon, 25 Jul 2005 07:42:43 -0700 Subject: strict policy In-Reply-To: <42E4F990.3030803@redhat.com> References: <1122300995.4494.32.camel@hive.ccit.arizona.edu> <42E4F990.3030803@redhat.com> Message-ID: <1122302563.4494.37.camel@hive.ccit.arizona.edu> On Mon, 2005-07-25 at 10:39 -0400, Daniel J Walsh wrote: > Todd Merritt wrote: > > >I'm getting started with selinux on FC 4. I'm using the strict policy, > >but I'd like to restrict it further so that users can only execute a > >handful of commands. I've tried replacing full_user_role(user_t) with > >limit_user role, but the drew assertion errors when trying to load the > >policy, and I tried removing restricting the can_exec in both full and > >limited_user_role macros in macros/user_macros.te, but (at least from > >looking at audit to allow) none of this seems to be getting me where I > >want to be. What is the beast way to remove all access from user_t so > >that I can add in the commands I want them to be able to run ? > > > > > > > First update to the latest rawhide strict policy. We have not been > updating strict policy for FC4. > Then you probably need to remove can_exec lines from base_user_macros. > Problem is eliminating > them might set you up with a solution where a user can not login. Are > you doing this with a X Windows System, or > a server? > server. I have it set up as permissive right now, I'm planning on running audit2allow to add access to the few commands that users should be allowed to run. Thanks, Todd From fedora at grifent.com Mon Jul 25 15:30:59 2005 From: fedora at grifent.com (John Griffiths) Date: Mon, 25 Jul 2005 11:30:59 -0400 Subject: users public_html access In-Reply-To: <42E4F60D.1030405@redhat.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> <42E12B14.3010605@redhat.com> <42E13E0E.4040503@grifent.com> <42E4F60D.1030405@redhat.com> Message-ID: <42E505B3.8090004@grifent.com> An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Mon Jul 25 15:53:45 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Jul 2005 11:53:45 -0400 Subject: users public_html access In-Reply-To: <42E505B3.8090004@grifent.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> <42E12B14.3010605@redhat.com> <42E13E0E.4040503@grifent.com> <42E4F60D.1030405@redhat.com> <42E505B3.8090004@grifent.com> Message-ID: <42E50B09.6030009@redhat.com> John Griffiths wrote: > Sorry. I'm new to Fedora and SE Linux. Forgot to look in > /var/log/audit/audit.log. There are many avc messages in > /var/log/audit/audit.log, but the ones that I think are relevant to > this are repeats of: > > type=AVC msg=audit(1122050110.135:15537760): avc: denied { > getattr } for pid= > 3517 comm="httpd" name="//" > dev=hdc1 ino=10780673 scontext=root:system_r:httpd > _t tcontext=root:object_r:file_t tclass=dir > file_t means that you have a labeling problem. touch /.autorelabel reboot > The user's home directory does not have the same security permissions > as the user's public_html directory since the How To did not specify > that it needed to be any more than have the permissions of 711. > > Regards, > John > > Daniel J Walsh wrote: > >> John Griffiths wrote: >> >>> None when I try to access the user's public_html. There are some >>> from when I turned enforcing off and back on. >>> >>> Jul 22 12:35:07 gei dbus: avc: received setenforce notice >>> (enforcing=0) >>> Jul 22 12:35:07 gei dbus: avc: received setenforce notice >>> (enforcing=0) >>> Jul 22 12:36:01 gei dbus: avc: received setenforce notice >>> (enforcing=1) >>> Jul 22 12:36:01 gei dbus: avc: received setenforce notice >>> (enforcing=1) >>> >>> That was when I was confirming that I could see the user's public_html. >>> >> You looked in both /var/log/audit/audit.log and /var/log/messages? >> >>> John >>> >>> Daniel J Walsh wrote: >>> >>>> John Griffiths wrote: >>>> >>>>> I cannot get users public_html content to publish in FC4. I keep >>>>> getting "You don't have permission to access /~/ on this >>>>> server." I can access the user's public_html when I change SELinux >>>>> to Permissive. >>>>> >>>>> I searched the archives and did not find anything, and I followed >>>>> the direction in section 4 of "Understanding and Customizing the >>>>> Apache HTTP SELinux Policy" which was written for FC3. >>>>> >>>>> The httpd booleans are: >>>>> httpd_builtin_scripting active >>>>> httpd_can_network_connect active >>>>> httpd_disable_trans inactive >>>>> httpd_enable_cgi active >>>>> httpd_enable_homedirs active >>>>> httpd_ssi_exec active >>>>> httpd_suexec_disable_trans inactive >>>>> httpd_tty_comm inactive >>>>> httpd_unified active >>>>> >>>>> The security setting on the user's public_html and the files in >>>>> the directory is user_u:object_r:httpd_sys_content_t . Obviously >>>>> the standard UGW permissions are OK since turning off SELinux >>>>> allows the content to be accessed. >>>>> >>>>> What am I missing, or is this a bug? >>>>> >>>>> Thanks, >>>>> John Griffiths >>>>> >>>>> -- >>>>> fedora-selinux-list mailing list >>>>> fedora-selinux-list at redhat.com >>>>> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> >>>> >>>> >>>> Any avc messages? >>>> >> >> -- From tmerritt at email.arizona.edu Mon Jul 25 16:44:29 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Mon, 25 Jul 2005 09:44:29 -0700 Subject: strict policy In-Reply-To: <42E4F990.3030803@redhat.com> References: <1122300995.4494.32.camel@hive.ccit.arizona.edu> <42E4F990.3030803@redhat.com> Message-ID: <1122309869.4494.61.camel@hive.ccit.arizona.edu> I've updated to the devel version of the strict policy, I tried commenting out the can_execs from the base_user_macro.te and user_macros.te, but I still don't see anything in the audit log when I try running a number of programs in the bin_t domain. Is the some sort of tracing that I can enable to see what policy is permitting execution of a particular program ? Thanks, Todd On Mon, 2005-07-25 at 10:39 -0400, Daniel J Walsh wrote: > Todd Merritt wrote: > > >I'm getting started with selinux on FC 4. I'm using the strict policy, > >but I'd like to restrict it further so that users can only execute a > >handful of commands. I've tried replacing full_user_role(user_t) with > >limit_user role, but the drew assertion errors when trying to load the > >policy, and I tried removing restricting the can_exec in both full and > >limited_user_role macros in macros/user_macros.te, but (at least from > >looking at audit to allow) none of this seems to be getting me where I > >want to be. What is the beast way to remove all access from user_t so > >that I can add in the commands I want them to be able to run ? > > > > > > > First update to the latest rawhide strict policy. We have not been > updating strict policy for FC4. > Then you probably need to remove can_exec lines from base_user_macros. > Problem is eliminating > them might set you up with a solution where a user can not login. Are > you doing this with a X Windows System, or > a server? > > >Thanks, > >Todd > > > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > From fedora at grifent.com Mon Jul 25 18:43:17 2005 From: fedora at grifent.com (John Griffiths) Date: Mon, 25 Jul 2005 14:43:17 -0400 Subject: users public_html access In-Reply-To: <42E50B09.6030009@redhat.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> <42E12B14.3010605@redhat.com> <42E13E0E.4040503@grifent.com> <42E4F60D.1030405@redhat.com> <42E505B3.8090004@grifent.com> <42E50B09.6030009@redhat.com> Message-ID: <42E532C5.4080208@grifent.com> Daniel J Walsh wrote: > John Griffiths wrote: > >> Sorry. I'm new to Fedora and SE Linux. Forgot to look in >> /var/log/audit/audit.log. There are many avc messages in >> /var/log/audit/audit.log, but the ones that I think are relevant to >> this are repeats of: >> >> type=AVC msg=audit(1122050110.135:15537760): avc: denied { >> getattr } for pid= >> 3517 comm="httpd" name="//" >> dev=hdc1 ino=10780673 scontext=root:system_r:httpd >> _t tcontext=root:object_r:file_t tclass=dir >> > file_t means that you have a labeling problem. > > touch /.autorelabel > reboot That did it. Thanks. I have another question but different topic, so I address it in a new post. From fedora at grifent.com Mon Jul 25 19:02:04 2005 From: fedora at grifent.com (John Griffiths) Date: Mon, 25 Jul 2005 15:02:04 -0400 Subject: Allowing port ranges in the firewall In-Reply-To: <42E50B09.6030009@redhat.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> <42E12B14.3010605@redhat.com> <42E13E0E.4040503@grifent.com> <42E4F60D.1030405@redhat.com> <42E505B3.8090004@grifent.com> <42E50B09.6030009@redhat.com> Message-ID: <42E5372C.1090303@grifent.com> I don't know if this is the correct list or not. Please advise correct list if not. I want to open the range of bittorant ports 6881-6999:tcp. I used /usr/bin/system-config-securitylevel and tried to open a port range using 6881-6999:tcp. system-config-securitylevel accepted the command, but when I checked it, only port 6881:tcp was opened. Am I missing something? I looked for a man page or help for system-config-securitylevel and couldn't find one. I did a google search for system-config-securitylevel and "port range" and got some stuff on ftp but nothing on actually opening a range. TIA, John From dwalsh at redhat.com Mon Jul 25 19:29:25 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Jul 2005 15:29:25 -0400 Subject: Allowing port ranges in the firewall In-Reply-To: <42E5372C.1090303@grifent.com> References: <20050722160052.5BC6873CBD@hormel.redhat.com> <42E1226C.9000305@grifent.com> <42E12B14.3010605@redhat.com> <42E13E0E.4040503@grifent.com> <42E4F60D.1030405@redhat.com> <42E505B3.8090004@grifent.com> <42E50B09.6030009@redhat.com> <42E5372C.1090303@grifent.com> Message-ID: <42E53D95.6090507@redhat.com> John Griffiths wrote: > I don't know if this is the correct list or not. Please advise correct > list if not. > > I want to open the range of bittorant ports 6881-6999:tcp. I used > /usr/bin/system-config-securitylevel and tried to open a port range > using 6881-6999:tcp. system-config-securitylevel accepted the command, > but when I checked it, only port 6881:tcp was opened. Am I missing > something? I looked for a man page or help for > system-config-securitylevel and couldn't find one. I did a google > search for system-config-securitylevel and "port range" and got some > stuff on ftp but nothing on actually opening a range. > > TIA, > John Not really the right list since this is not SELinux related, but this looks like a bug in system-config-securitylevel. Please file a bugzilla. -- From ynakam at gwu.edu Tue Jul 26 14:36:03 2005 From: ynakam at gwu.edu (Yuichi Nakamura) Date: Tue, 26 Jul 2005 10:36:03 -0400 Subject: ANN: SELinux Policy Editor 1.0 Message-ID: <3un3qj$3ptdhc@iron2-mx.tops.gwu.edu> We are glad to announce that SELinux Policy Editor 1.0 has been released. In this release, our policy called "Simplified policy" can be used without GUI. To try, visit http://seedit.sourceforge.net/ . Install manual, how to and specification documentations are ready. SELinux Policy Editor and Simplified policy works on Fedora Core4 and 3. Our tool does not affect existing SELinux, you can go back to default SELinux easily. Feel free to try. If you have question, suggestion or something email to seedit-admin at lists.sourceforge.net. * About SELinux Policy Editor SELinux Policy Editor is a tool to edit and view SELinux policy, originally developed by Hitachi Softwarek, not developed in SELinux Policy Editor Project(seedit.sourceforge.net). The tool is composed of simplified policy and GUI. Simplified policy hides detail of SELinux configuration, and GUI makes configuration much easier. It is not just a GUI tool, the important component is simplified policy. You can also configure simplified policy without GUI. Following is example of simplified policy for Apache. domain httpd_t; domain_trans initrc_t /usr/sbin/httpd; allow /var/www r,s; allownet -tcp -port 80; As you see, type is not used. You can use file name, port number in configuration. For detail about simplified policy, see http://seedit.sourceforge.net/doc/simplified_policy_manual.pdf * TODO - Review the security of simplified policy - Extend syntax of simplified policy for detailed configuration - Auto generation of simplified policy - Write more policy by simplified policy - Test on other distributions --- Yuichi Nakamura Hitachi Software, The George Washington University Japan SELinux Users Group(JSELUG) Japan Open Source Advocacy Organization(JOSAO) SELinux Policy Editor: http://seedit.sourceforge.net/ From james.zheng.li at gmail.com Wed Jul 27 15:34:54 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Wed, 27 Jul 2005 11:34:54 -0400 Subject: HOME_DIR in apache.fc Message-ID: <8a239a56050727083437df11d8@mail.gmail.com> Hi all, I am using targeted policy on FC4. In the apache.fc file, the first line is HOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t I want to know where "HOME_DIR" is defined? The "apol" tool did not show the definition of HOME_DIR. Btw, is HOME_DIR related to attribute user_home_dir_type; attribute home_dir_type; type user_home_dir_t; Thanks, James From gyurdiev at redhat.com Wed Jul 27 15:43:43 2005 From: gyurdiev at redhat.com (Ivan Gyurdiev) Date: Wed, 27 Jul 2005 11:43:43 -0400 Subject: HOME_DIR in apache.fc In-Reply-To: <8a239a56050727083437df11d8@mail.gmail.com> References: <8a239a56050727083437df11d8@mail.gmail.com> Message-ID: <1122479023.31326.52.camel@celtics.boston.redhat.com> > I want to know where "HOME_DIR" is defined? HOME_DIR is expanded to all user home directories by the genhomedircon tool. It's an interpreted pattern (despite having no distinguishing characteristics of any kind, which is a mistake). > Btw, is HOME_DIR related to > attribute user_home_dir_type; > attribute home_dir_type; > type user_home_dir_t; No..those are policy types and attributes, which have nothing to do with regexp matching for labeling. From claude_jones at levitjames.com Wed Jul 27 17:00:08 2005 From: claude_jones at levitjames.com (Claude Jones) Date: Wed, 27 Jul 2005 13:00:08 -0400 Subject: audit errors on shutdown in FC4 Message-ID: <200507271300.08652.claude_jones@levitjames.com> First post here (my apology to the moderator - first post actually was from the wrong email address and is awaiting your approval) I hope someone knows what the following is about. When I shutdown or reboot, I'm getting the following messages: --------------------- Selinux Audit Begin ------------------------ ?**Unmatched Entries** (Only first 10 out of 24 are printed) ? The audit daemon is exiting. ? audit: *NO* daemon at audit_pid=1920 ? audit(1122429286.858:9676498): arch=40000003 syscall=102 success=no exit=-22 a0=b a1=bf9e3470 a2=80510f8 a3=0 items=0 pid=29548 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" ? audit(1122429286.858:9676498): saddr=100000000000000000000000 ? audit(1122429286.858:9676498): nargs=6 a0=3 a1=bf9e55cc a2=10 a3=0 a4=bf9e7768 a5=c ? audit(1122429286.959:9676518): SELinux: ?unrecognized netlink message type=1009 for sclass=49 ? audit(1122429286.959:9676518): arch=40000003 syscall=102 success=no exit=-22 a0=b a1=bf9e3450 a2=80510f8 a3=0 items=0 pid=29548 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" ? audit(1122429286.959:9676518): saddr=100000000000000000000000 ? audit(1122429286.959:9676518): nargs=6 a0=3 a1=bf9e55ac a2=10 a3=0 a4=bf9e7748 a5=c ? Init complete, auditd 0.9.15 listening for events This is from my logs, but it looks just like this on my screen as the shutdown is occurring. I did some research on this and have gained a layman's understanding of netlink, but I couldn't figure out how to troubleshoot the problem. -- Claude Jones Bluemont, VA, USA From linux_4ever at yahoo.com Wed Jul 27 17:29:50 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 27 Jul 2005 10:29:50 -0700 (PDT) Subject: audit errors on shutdown in FC4 In-Reply-To: <200507271300.08652.claude_jones@levitjames.com> Message-ID: <20050727172950.29493.qmail@web51501.mail.yahoo.com> >but it looks just like this on my screen as the shutdown >is occurring. This is "normal". The userspace utilities are waiting for some kernel patches to be applied. This should all sync up eventually. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ejtr at layer3.co.uk Wed Jul 27 17:36:05 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Wed, 27 Jul 2005 18:36:05 +0100 Subject: pam-0.79-9.1 breakage with FC4 strict policy. In-Reply-To: <42E4F7FA.8010106@redhat.com> References: <1122280599.3371.62.camel@topaz.bugfinder.co.uk> <42E4F7FA.8010106@redhat.com> Message-ID: <1122485765.2964.18.camel@topaz.bugfinder.co.uk> Thanks for the hint. To avoid a complete /.autorelabel at this time, I found that a minimal set of local tweaks to my default FC4 strict policy gave me back local login, as in: allow auth_chkpwd self:capability { audit_write audit_control }; allow pam_console_t console_device_t:chr_file { setattr }; allow local_login_t faillog_t:file { lock } ; allow local_login_t self:capability { audit_control }; The ssh login problem proved to be related to SELinux, but not a policy issue per se. I had somehow amended the sshd_config whilst the machine was in FC3, and when it was upgraded to FC4 it failed to pick up the critical UsePAM yes setting in the current FC4 sshd_config default settings. As a consequence, FC4 sshd appears to assume UsePAM no, and SELinux naturally breaks the authentication as it assumes all access to shadow_t is via the PAM modules. Perhaps it might be worth patching sshd itself so that the lack of an explicit UsePAM setting in the configuration file is treated as "UsePAM yes" rather than "UsePAM no" on an SELinux capable system? Ted On Mon, 2005-07-25 at 10:32 -0400, Daniel J Walsh wrote: > Ted Rule wrote: > > >I have recently updated the pam rpm on my FC4 machine from: > > > > pam-0.79-8 > > > >to > > > > pam-0.79-9.1 > > > >The machine was orginally built as FC3 running SELinux strict/enforcing, > >upgraded to FC4, "/.autorelabel"'ed, and thereafter gradually patched up > >with FC4 updates using yum. The SELinux policy is using: > > > > selinux-policy-strict-1.23.16-6 > > > >The current pam misbehaviour for a variety of authentication sequences > >is as follows: > > > >======================================== > >With SELinux enforcing and pam-0.79-9.1: > > > >"su -" works Ok. ( both su-ing to root and non-root users. ) > > > >"sudo" fails every time with: > > > > sudo: pam_authenticate: System error > > > >"/bin/login" fails every time with only these messages in syslog: > > > >Jul 25 08:45:31 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, > >System error > >Jul 25 08:45:31 topaz kernel: audit(1122277531.083:24): avc: denied > >{ lock } for pid=5704 comm="login" name="btmp" dev=hda7 ino=339558 > >scontext=system_u:system_r:local_login_t > >tcontext=system_u:object_r:faillog_t tclass=file > > > >"ssh localhost" fails every time with: > > > >Jul 25 08:48:31 topaz sshd[14927]: error: Could not get shadow > >information for ejtr > >Jul 25 08:48:31 topaz sshd[14927]: Failed password for ejtr from > >127.0.0.1 port 50117 ssh2 > > > >========================================= > >With SELinux permissive and pam-0.79-9.1: > > > >"su -" works Ok. ( both su-ing to root and non-root users. ) > > > >"sudo" fails 1st time with: > > > > sudo: pam_authenticate: System error > > > >and then succeeds 2nd time - but still asks for password. On the 3rd > >attempt it caches the authentication from the 2nd attempt and works Ok. > > > > > >"/bin/login" appears to fail twice and then succeed. > > > >Jul 25 08:53:07 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, > >System error > >Jul 25 08:53:07 topaz kernel: audit(1122277987.276:26): avc: denied > >{ lock } for pid=5767 comm="login" name="btmp" dev=hda7 ino=339558 > >scontext=system_u:system_r:local_login_t > >tcontext=system_u:object_r:faillog_t tclass=file > >Jul 25 08:53:11 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, > >System error > >Jul 25 08:53:11 topaz kernel: audit(1122277991.339:27): avc: denied > >{ lock } for pid=10278 comm="login" name="btmp" dev=hda7 ino=339558 > >scontext=system_u:system_r:local_login_t > >tcontext=system_u:object_r:faillog_t tclass=file > >Jul 25 08:53:15 topaz login(pam_unix)[10621]: session opened for user > >ejtr by (uid=0) > >Jul 25 08:53:15 topaz -- ejtr[10621]: LOGIN ON tty2 BY ejtr > >Jul 25 08:53:19 topaz login(pam_unix)[10621]: session closed for user > >ejtr > >Jul 25 08:53:25 topaz login(pam_unix)[11502]: session opened for user > >ejtr by (uid=0) > >Jul 25 08:53:25 topaz -- ejtr[11502]: LOGIN ON tty2 BY ejtr > >Jul 25 08:53:27 topaz login(pam_unix)[11502]: session closed for user > >ejtr > > > > > >"ssh localhost" works 1st time. > > > >=============================================== > > > > > >When I saw the "shadow" error on sshd, I tried adding some "debug" to > >SELinux policy to double check that the correct domain was trying to > >read shadow_t. That proved to be a red-herring, as did tracking the lock > >access denial on /var/log/btmp. > > > >I've checked SELinux file_contexts on the pam installed files - seems > >Ok. I've tried downgrading pam to 0.79-8 and back to 0.79-9.1 again. The > >system consistently works every time with 0.79-8 and misbehaves every > >time with 0.79-9.1 > > > >Amongst the trail of debugging, I've found a couple of pam errors which > >are seemingly unrelated to the overall failure, but probably need > >fixing: > > > >This: > > > > allow crond_t self:capability { audit_control } ; > > > >seems to be needed to allow per-user crontab's to audit correctly. > > > >There seems to be some inconsistency in the use and non-use of > >pam_loginuid.so and pam_selinux.so in /etc/pam.d/XXXX as between > > > > /etc/pam.d/su > > /etc/pam.d/sudo > > /etc/pam.d/login > > /etc/pam.d/gdm > > /etc/pam.d/sshd > > > >I would have thought that most, if not all, of the pam.d configurations > >should have pam_loginuid.so and pam_selinux.so references, but I could > >so easily be wrong about this. > > > >I also noticed that the FC3 -> FC4 upgrade process failed to > >automatically install the "audit" rpm. I manually added it via yum > >whilst tracking the pam problem, but the lack of the auditd service also > >seems to be a red-herring. I currently have it installed but > >chkconfig'ed off - mainly so as to ensure all the logs are in one place > >for ease of debugging. > > > >I've tried temporarily disabling various clauses in /etc/pam.d/login - > >such as pam_console - to try and isolate the issue, but I haven't had > >much luck with that either. With "debug" enabled on the pam_stack.so > >entry in /etc/pam.d/login, it seems that "system-auth" always returns > >SUCCESS, which seems to eliminate most of pam as a source of error. > > > >Can anyone throw any light on the problem or give me some other ideas > >for debugging the issue? > > > > > >Thanks, > > > > > > > > > All of these fixes are in the latest policy available for FC4 -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From casey at schaufler-ca.com Thu Jul 21 15:10:46 2005 From: casey at schaufler-ca.com (Casey Schaufler) Date: Thu, 21 Jul 2005 08:10:46 -0700 (PDT) Subject: ainit In-Reply-To: <200507212142.28830.russell@coker.com.au> Message-ID: <20050721151046.87199.qmail@web31606.mail.mud.yahoo.com> --- Russell Coker wrote: > 1) Anyone who is serious about security doesn't use > ALSA so such access > doesn't matter that much. This is always a bad assumption, regardless of the facility in question. Casey Schaufler casey at schaufler-ca.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From claude_jones at levitjames.com Wed Jul 27 16:33:58 2005 From: claude_jones at levitjames.com (Claude Jones) Date: Wed, 27 Jul 2005 12:33:58 -0400 Subject: audit errors on FC4 shutdown Message-ID: <200507271233.58995.claude_jones@levitjames.com> First post here - hope someone knows what the following is about. When I shutdown or reboot, I'm getting the following messages: --------------------- Selinux Audit Begin ------------------------ ?**Unmatched Entries** (Only first 10 out of 24 are printed) ? The audit daemon is exiting. ? audit: *NO* daemon at audit_pid=1920 ? audit(1122429286.858:9676498): arch=40000003 syscall=102 success=no exit=-22 a0=b a1=bf9e3470 a2=80510f8 a3=0 items=0 pid=29548 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" ? audit(1122429286.858:9676498): saddr=100000000000000000000000 ? audit(1122429286.858:9676498): nargs=6 a0=3 a1=bf9e55cc a2=10 a3=0 a4=bf9e7768 a5=c ? audit(1122429286.959:9676518): SELinux: ?unrecognized netlink message type=1009 for sclass=49 ? audit(1122429286.959:9676518): arch=40000003 syscall=102 success=no exit=-22 a0=b a1=bf9e3450 a2=80510f8 a3=0 items=0 pid=29548 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" ? audit(1122429286.959:9676518): saddr=100000000000000000000000 ? audit(1122429286.959:9676518): nargs=6 a0=3 a1=bf9e55ac a2=10 a3=0 a4=bf9e7748 a5=c ? Init complete, auditd 0.9.15 listening for events This is from my logs, but it looks just like this on my screen as the shutdown is occurring. I did some research on this and have gained a layman's understanding of netlink, but I couldn't figure out how to troubleshoot the problem. -- Claude Jones Bluemont, VA, USA From mandreiana.lists at gmail.com Wed Jul 27 19:43:18 2005 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Wed, 27 Jul 2005 22:43:18 +0300 Subject: audit errors on FC4 shutdown In-Reply-To: <200507271233.58995.claude_jones@levitjames.com> References: <200507271233.58995.claude_jones@levitjames.com> Message-ID: <1122493398.3283.2.camel@marte.biciclete.ro> On Wed, 2005-07-27 at 12:33 -0400, Claude Jones wrote: > First post here - hope someone knows what the following is about. When I > shutdown or reboot, I'm getting the following messages: Do you have all FC4 updates? Newer kernel solved printing audit messages to screen. -- Marius Andreiana From cviniciusm at terra.com.br Thu Jul 28 01:22:29 2005 From: cviniciusm at terra.com.br (Vinicius) Date: Wed, 27 Jul 2005 22:22:29 -0300 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: References: <42D8ECE0.9020307@redhat.com> Message-ID: Vinicius wrote: > Daniel J Walsh wrote: > >> Vinicius wrote: >> >>> Hello, >>> >>> Please see >>> https://www.redhat.com/archives/fedora-list/2005-July/msg03159.html >>> >>> Any suggestions, please? >> >> >> >> Well first put in a bugzilla. >> Secondly what port is it trying to connect to? >> >> Did you change the port number of the hpssd? >> >> >>> >>> >>> TIA, >>> >>> Vinicius. >>> >>> -- > > > Hello, > > I filled the bug report number 163434 > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163434). > > The port is 32774. > > No, I didn't change the port number of the hpssd. And I don't know how > to do this. > > from /var/log/messages: > Jul 16 10:02:54 ronin hpiod: 0.9.3 accepting connections at 32774... > Jul 16 10:03:04 ronin python: hpssd [ERROR] Unable to connect to hpiod. > > from /var/log/audit/audit.log: > type=CWD msg=audit(1121518984.285:13005806): cwd="/usr/share/hplip" > type=PATH msg=audit(1121518984.285:13005806): item=0 > name="/usr/share/hplip/base/strings.pyc" flags=310 inode=1181808 dev= > fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1121518984.905:13008633): avc: denied { > name_connect } for pid=4841 comm="python" dest=32774 scontext > =root:system_r:hplip_t tcontext=system_u:object_r:port_t tclass=tcp_socket > type=SYSCALL msg=audit(1121518984.905:13008633): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bfd6cf50 a2=98b114 a > 3=b7c99b48 items=0 pid=4841 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 comm="python" exe="/usr > /bin/python" > type=SOCKADDR msg=audit(1121518984.905:13008633): > saddr=020080067F0000010000000000000000 > type=SOCKETCALL msg=audit(1121518984.905:13008633): nargs=3 a0=5 > a1=b7c99b60 a2=10 > > > TIA, > > Vinicius. > Hello, after the recent FC4 updates such as gcc and libtool (thanks to them, I think), hplip 0.9.4 from http://sourceforge.net/projects/hpinkjet/ is working fine with FC4, printing e scanning. I think the hplip component from the Fedora development team will work too. But I'm running with SELinux disabled, so I will turn it on and to see what happens. Cheers, Vinicius. From claude_jones at levitjames.com Thu Jul 28 01:45:16 2005 From: claude_jones at levitjames.com (Claude Jones) Date: Wed, 27 Jul 2005 21:45:16 -0400 Subject: audit errors on shutdown in FC4 In-Reply-To: <20050727172950.29493.qmail@web51501.mail.yahoo.com> References: <20050727172950.29493.qmail@web51501.mail.yahoo.com> Message-ID: <200507272145.16578.claude_jones@levitjames.com> On Wed July 27 2005 1:29 pm, Steve G wrote: > >but it looks just like this on my screen as the shutdown > >is occurring. > > This is "normal". The userspace utilities are waiting for some kernel > patches to be applied. This should all sync up eventually. > Thanks, Steve. I'm going to make an attempt to start understanding Selinux over the next period, so if I ask uninformed questions, forgive me. I have been reading up on it but it's still a very murky subject for me. I understand the concept of it fairly well, but the devil's in the implementation. Tonight, a yum update picked up new versions of audit, audit-libs, and audit-libs-devel. Are these the kinds of patches you're referring to? -- Claude Jones Bluemont, VA, USA From dragoran at feuerpokemon.de Thu Jul 28 13:30:26 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 28 Jul 2005 15:30:26 +0200 Subject: audit update breaks hwclock Message-ID: <42E8DDF2.1080308@feuerpokemon.de> After updating audit today I get an error after udev is started that says that it can't connot to the audit system. I found this in the audit logs: > type=AVC msg=audit(1122549673.001:7418105): avc: denied { create } > for pid=34 19 comm="hwclock" scontext=root:system_r:hwclock_t > tcontext=root:system_r:hwcloc k_t tclass=netlink_audit_socket > type=SYSCALL msg=audit(1122549673.001:7418105): arch=c000003e > syscall=41 success =no exit=-13 a0=10 a1=3 a2=9 a3=42e8bfa9 items=0 > pid=3419 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="hwclock" exe="/sbin/hwclock" this results in an incorrect clock (+2h) I am not using ntpd. Timezonesettings are correct and it worked fine after the update. From dragoran at feuerpokemon.de Thu Jul 28 11:32:30 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 28 Jul 2005 13:32:30 +0200 Subject: audit update breaks hwclock In-Reply-To: <42E8DDF2.1080308@feuerpokemon.de> References: <42E8DDF2.1080308@feuerpokemon.de> Message-ID: <42E8C24E.5060804@feuerpokemon.de> dragoran wrote: > After updating audit today I get an error after udev is started that > says that it can't connot to the audit system. > I found this in the audit logs: > >> type=AVC msg=audit(1122549673.001:7418105): avc: denied { create } >> for pid=34 19 comm="hwclock" scontext=root:system_r:hwclock_t >> tcontext=root:system_r:hwcloc k_t tclass=netlink_audit_socket >> type=SYSCALL msg=audit(1122549673.001:7418105): arch=c000003e >> syscall=41 success =no exit=-13 a0=10 a1=3 a2=9 a3=42e8bfa9 items=0 >> pid=3419 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >> sgid=0 fsgid=0 comm="hwclock" exe="/sbin/hwclock" > > > this results in an incorrect clock (+2h) > I am not using ntpd. > Timezonesettings are correct and it worked fine after the update. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > setiing the clock with system-config-date works but I get this in the logs: > type=AVC msg=audit(1122550262.001:698688): avc: denied { create } > for pid=3211 comm="hwclock" scontext=root:system_r:hwclock_t > tcontext=root:system_r:hwclock_t tclass=netlink_audit_socket > type=SYSCALL msg=audit(1122550262.001:698688): arch=c000003e > syscall=41 success=no exit=-13 a0=10 a1=3 a2=9 a3=42e8c1f6 items=0 > pid=3211 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="hwclock" exe="/sbin/hwclock" and after reboot the time is incorrect again. From linux_4ever at yahoo.com Thu Jul 28 12:18:38 2005 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 28 Jul 2005 05:18:38 -0700 (PDT) Subject: audit errors on shutdown in FC4 In-Reply-To: <200507272145.16578.claude_jones@levitjames.com> Message-ID: <20050728121838.51351.qmail@web51504.mail.yahoo.com> >Tonight, a yum update picked up new versions of audit, audit-libs, and >audit-libs-devel. Are these the kinds of patches you're referring to? Not really. The main thing about this round of updates is that it quietens messages that are caused by delete file system watches not being supported by current kernels. We have a reference audit implementation that I work to. We have just begun to get the filesystem watch implementation upstream. It was pointed out that there is some overlap between inotify and the audit system. So, we are trying to create a common framework that both audit and inotify can clip into. Then when this gets accepted upstream, Fedora will pick up the new kernel and all will be better. This process may take a month. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From linux_4ever at yahoo.com Thu Jul 28 12:26:28 2005 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 28 Jul 2005 05:26:28 -0700 (PDT) Subject: audit update breaks hwclock In-Reply-To: <42E8DDF2.1080308@feuerpokemon.de> Message-ID: <20050728122628.69259.qmail@web51505.mail.yahoo.com> >After updating audit today I get an error after udev is started that >says that it can't connot to the audit system. Are you sure that you didn't update util-linux, too? I did submit a patch to util-linux to make hwclock log its actions as this is required by CAPP. I guess that got pushed out. -Steve ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From claude_jones at levitjames.com Thu Jul 28 13:36:31 2005 From: claude_jones at levitjames.com (Claude Jones) Date: Thu, 28 Jul 2005 09:36:31 -0400 Subject: audit errors on shutdown in FC4 In-Reply-To: <20050728121838.51351.qmail@web51504.mail.yahoo.com> References: <20050728121838.51351.qmail@web51504.mail.yahoo.com> Message-ID: <200507280936.31670.claude_jones@levitjames.com> On Thursday 28 July 2005 8:18 am, Steve G wrote: > >Tonight, a yum update picked up new versions of audit, audit-libs, and > >audit-libs-devel. Are these the kinds of patches you're referring to? > > Not really. The main thing about this round of updates is that it quietens > messages that are caused by delete file system watches not being supported > by current kernels. > > We have a reference audit implementation that I work to. We have just begun > to get the filesystem watch implementation upstream. It was pointed out > that there is some overlap between inotify and the audit system. So, we are > trying to create a common framework that both audit and inotify can clip > into. Then when this gets accepted upstream, Fedora will pick up the new > kernel and all will be better. This process may take a month. > I need to learn more - I'm afraid you've gone over my head - but thanks. After the cited round of updates, I got this in my overnight logwatch: is there anything I need to get worried about? --------------------- Selinux Audit Begin ------------------------ ?*** Denials *** ? system_u system_u (dir): 22 times ? system_u system_u (file): 34 times ? system_u system_u (netif): 2 times ? system_u system_u (netlink_audit_socket): 1 times ? system_u system_u (netlink_route_socket): 1 times ? system_u system_u (node): 2 times ? system_u system_u (sock_file): 3 times ? system_u system_u (tcp_socket): 5 times ? system_u system_u (udp_socket): 10 times ? system_u user_u (sock_file): 1 times ? ?**Unmatched Entries** (Only first 10 out of 89 are printed) ? The audit daemon is exiting. ? audit: *NO* daemon at audit_pid=1920 ? audit(1122440737.973:10895603): arch=40000003 syscall=102 success=no exit=-22 a0=b a1=bf909cc0 a2=80510f8 a3=0 items=0 pid=17997 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" ? audit(1122440737.973:10895603): saddr=100000000000000000000000 ? audit(1122440737.973:10895603): nargs=6 a0=3 a1=bf90be1c a2=10 a3=0 a4=bf90dfb8 a5=c ? audit(1122440738.074:10895623): SELinux: ?unrecognized netlink message type=1009 for sclass=49 ? audit(1122440738.074:10895623): arch=40000003 syscall=102 success=no exit=-22 a0=b a1=bf909ca0 a2=80510f8 a3=0 items=0 pid=17997 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="auditctl" exe="/sbin/auditctl" ? audit(1122440738.074:10895623): saddr=100000000000000000000000 ? audit(1122440738.074:10895623): nargs=6 a0=3 a1=bf90bdfc a2=10 a3=0 a4=bf90df98 a5=c ? Init complete, auditd 0.9.15 listening for events ?---------------------- Selinux Audit End ------------------------- ?--------------------- Cron Begin ------------------------ ? ?**Unmatched Entries** ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/crontab) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mrtg) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/sysstat) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mailman) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/crontab) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mrtg) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/sysstat) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mailman) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/crontab) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mrtg) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/sysstat) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mailman) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/crontab) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mrtg) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/sysstat) ?ENTRYPOINT FAILED but SELinux in permissive mode, continuing (/etc/cron.d/mailman) ? ?---------------------- Cron End ------------------------- -- Claude Jones Bluemont, VA, USA From tmerritt at email.arizona.edu Thu Jul 28 13:45:03 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Thu, 28 Jul 2005 06:45:03 -0700 Subject: strict policy In-Reply-To: <1122309869.4494.61.camel@hive.ccit.arizona.edu> References: <1122300995.4494.32.camel@hive.ccit.arizona.edu> <42E4F990.3030803@redhat.com> <1122309869.4494.61.camel@hive.ccit.arizona.edu> Message-ID: <1122558303.6675.96.camel@hive.ccit.arizona.edu> On Mon, 2005-07-25 at 09:44 -0700, Todd Merritt wrote: > I've updated to the devel version of the strict policy, I tried > commenting out the can_execs from the base_user_macro.te and > user_macros.te, but I still don't see anything in the audit log when I > try running a number of programs in the bin_t domain. Is the some sort > of tracing that I can enable to see what policy is permitting execution > of a particular program ? > Now that I've gotten this working and understand the policy build process a little better, I realize that was a stupid question. I thought I'd post my solution just for posterity's sake. I had to move can_exec_any from base_user_macros.te into admin_macros.te, then comment out the can_execs from user_macros and then add the commands that I wanted. Todd > Thanks, > Todd > On Mon, 2005-07-25 at 10:39 -0400, Daniel J Walsh wrote: > > Todd Merritt wrote: > > > > >I'm getting started with selinux on FC 4. I'm using the strict policy, > > >but I'd like to restrict it further so that users can only execute a > > >handful of commands. I've tried replacing full_user_role(user_t) with > > >limit_user role, but the drew assertion errors when trying to load the > > >policy, and I tried removing restricting the can_exec in both full and > > >limited_user_role macros in macros/user_macros.te, but (at least from > > >looking at audit to allow) none of this seems to be getting me where I > > >want to be. What is the beast way to remove all access from user_t so > > >that I can add in the commands I want them to be able to run ? > > > > > > > > > > > First update to the latest rawhide strict policy. We have not been > > updating strict policy for FC4. > > Then you probably need to remove can_exec lines from base_user_macros. > > Problem is eliminating > > them might set you up with a solution where a user can not login. Are > > you doing this with a X Windows System, or > > a server? > > > > >Thanks, > > >Todd > > > > > > > > >-- > > >fedora-selinux-list mailing list > > >fedora-selinux-list at redhat.com > > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From cviniciusm at terra.com.br Thu Jul 28 11:21:48 2005 From: cviniciusm at terra.com.br (Vinicius) Date: Thu, 28 Jul 2005 08:21:48 -0300 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: References: <42D8ECE0.9020307@redhat.com> Message-ID: Vinicius wrote: > Vinicius wrote: > >>Daniel J Walsh wrote: >> >> >>>Vinicius wrote: >>> >>> >>>>Hello, >>>> >>>>Please see >>>>https://www.redhat.com/archives/fedora-list/2005-July/msg03159.html >>>> >>>>Any suggestions, please? >>> >>> >>> >>>Well first put in a bugzilla. >>>Secondly what port is it trying to connect to? >>> >>>Did you change the port number of the hpssd? >>> >>> >>> >>>> >>>>TIA, >>>> >>>>Vinicius. >>>> >>>>-- >> >> >>Hello, >> >>I filled the bug report number 163434 >>(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163434). >> >>The port is 32774. >> >>No, I didn't change the port number of the hpssd. And I don't know how >>to do this. >> >>from /var/log/messages: >>Jul 16 10:02:54 ronin hpiod: 0.9.3 accepting connections at 32774... >>Jul 16 10:03:04 ronin python: hpssd [ERROR] Unable to connect to hpiod. >> >>from /var/log/audit/audit.log: >>type=CWD msg=audit(1121518984.285:13005806): cwd="/usr/share/hplip" >>type=PATH msg=audit(1121518984.285:13005806): item=0 >>name="/usr/share/hplip/base/strings.pyc" flags=310 inode=1181808 dev= >>fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 >>type=AVC msg=audit(1121518984.905:13008633): avc: denied { >>name_connect } for pid=4841 comm="python" dest=32774 scontext >>=root:system_r:hplip_t tcontext=system_u:object_r:port_t tclass=tcp_socket >>type=SYSCALL msg=audit(1121518984.905:13008633): arch=40000003 >>syscall=102 success=no exit=-13 a0=3 a1=bfd6cf50 a2=98b114 a >>3=b7c99b48 items=0 pid=4841 auid=4294967295 uid=0 gid=0 euid=0 suid=0 >>fsuid=0 egid=0 sgid=0 fsgid=0 comm="python" exe="/usr >>/bin/python" >>type=SOCKADDR msg=audit(1121518984.905:13008633): >>saddr=020080067F0000010000000000000000 >>type=SOCKETCALL msg=audit(1121518984.905:13008633): nargs=3 a0=5 >>a1=b7c99b60 a2=10 >> >> >>TIA, >> >>Vinicius. >> > > > Hello, > > after the recent FC4 updates such as gcc and libtool (thanks to them, I > think), hplip 0.9.4 from http://sourceforge.net/projects/hpinkjet/ is > working fine with FC4, printing e scanning. I think the hplip component > from the Fedora development team will work too. But I'm running with > SELinux disabled, so I will turn it on and to see what happens. > > > Cheers, > > Vinicius. > I think I have to thank to the SELinux policies updates too. Just to make the things clear, I compiled the hplip 0.9.4 after the recents updates under. After SELinux enabled with "enforcing" and "targeted", the PSC 1315 prints but no scans. I see the following avc's: "type=AVC msg=audit(1122548966.016:259603): avc: denied { rename } for pid=2103 comm="cupsd" name="classes.conf" dev=dm-0 ino=3692813 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:cupsd_etc_t tclass=file type=AVC msg=audit(1122548966.016:259604): avc: denied { write } for pid=2103 comm="cupsd" name="classes.conf" dev=dm-0 ino=3692813 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:cupsd_etc_t tclass=file" Vinicius. From dwalsh at redhat.com Thu Jul 28 15:16:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Jul 2005 11:16:31 -0400 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: References: <42D8ECE0.9020307@redhat.com> Message-ID: <42E8F6CF.7050307@redhat.com> Vinicius wrote: >Vinicius wrote: > > >>Vinicius wrote: >> >> >> >>>Daniel J Walsh wrote: >>> >>> >>> >>> >>>>Vinicius wrote: >>>> >>>> >>>> >>>> >>>>>Hello, >>>>> >>>>>Please see >>>>>https://www.redhat.com/archives/fedora-list/2005-July/msg03159.html >>>>> >>>>>Any suggestions, please? >>>>> >>>>> >>>> >>>>Well first put in a bugzilla. >>>>Secondly what port is it trying to connect to? >>>> >>>>Did you change the port number of the hpssd? >>>> >>>> >>>> >>>> >>>> >>>>>TIA, >>>>> >>>>>Vinicius. >>>>> >>>>>-- >>>>> >>>>> >>>Hello, >>> >>>I filled the bug report number 163434 >>>(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163434). >>> >>>The port is 32774. >>> >>>No, I didn't change the port number of the hpssd. And I don't know how >>>to do this. >>> >>> >>> >>>from /var/log/messages: >> >> >>>Jul 16 10:02:54 ronin hpiod: 0.9.3 accepting connections at 32774... >>>Jul 16 10:03:04 ronin python: hpssd [ERROR] Unable to connect to hpiod. >>> >>> >>> >>>from /var/log/audit/audit.log: >> >> >>>type=CWD msg=audit(1121518984.285:13005806): cwd="/usr/share/hplip" >>>type=PATH msg=audit(1121518984.285:13005806): item=0 >>>name="/usr/share/hplip/base/strings.pyc" flags=310 inode=1181808 dev= >>>fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 >>>type=AVC msg=audit(1121518984.905:13008633): avc: denied { >>>name_connect } for pid=4841 comm="python" dest=32774 scontext >>>=root:system_r:hplip_t tcontext=system_u:object_r:port_t tclass=tcp_socket >>>type=SYSCALL msg=audit(1121518984.905:13008633): arch=40000003 >>>syscall=102 success=no exit=-13 a0=3 a1=bfd6cf50 a2=98b114 a >>>3=b7c99b48 items=0 pid=4841 auid=4294967295 uid=0 gid=0 euid=0 suid=0 >>>fsuid=0 egid=0 sgid=0 fsgid=0 comm="python" exe="/usr >>>/bin/python" >>>type=SOCKADDR msg=audit(1121518984.905:13008633): >>>saddr=020080067F0000010000000000000000 >>>type=SOCKETCALL msg=audit(1121518984.905:13008633): nargs=3 a0=5 >>>a1=b7c99b60 a2=10 >>> >>> >>>TIA, >>> >>>Vinicius. >>> >>> >>> >>Hello, >> >>after the recent FC4 updates such as gcc and libtool (thanks to them, I >>think), hplip 0.9.4 from http://sourceforge.net/projects/hpinkjet/ is >>working fine with FC4, printing e scanning. I think the hplip component >>from the Fedora development team will work too. But I'm running with >>SELinux disabled, so I will turn it on and to see what happens. >> >> >>Cheers, >> >>Vinicius. >> >> >> > >I think I have to thank to the SELinux policies updates too. > >Just to make the things clear, I compiled the hplip 0.9.4 after the >recents updates under. > >After SELinux enabled with "enforcing" and "targeted", the PSC 1315 >prints but no scans. >I see the following avc's: >"type=AVC msg=audit(1122548966.016:259603): avc: denied { rename } for > pid=2103 comm="cupsd" name="classes.conf" dev=dm-0 > ino=3692813 scontext=system_u:system_r:cupsd_t >tcontext=system_u:object_r:cupsd_etc_t tclass=file >type=AVC msg=audit(1122548966.016:259604): avc: denied { write } for >pid=2103 comm="cupsd" name="classes.conf" dev=dm-0 >ino=3692813 scontext=system_u:system_r:cupsd_t >tcontext=system_u:object_r:cupsd_etc_t tclass=file" > > > Can you change classes.conf to cupsd_etc_rw_t? chcon -t cupsd_etc_rw_t classes.conf And see if it works? >Vinicius. > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From twaugh at redhat.com Thu Jul 28 15:50:20 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 28 Jul 2005 16:50:20 +0100 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: <42E8F6CF.7050307@redhat.com> References: <42D8ECE0.9020307@redhat.com> <42E8F6CF.7050307@redhat.com> Message-ID: <20050728155020.GG1950@redhat.com> On Thu, Jul 28, 2005 at 11:16:31AM -0400, Daniel J Walsh wrote: > Can you change classes.conf to cupsd_etc_rw_t? > > chcon -t cupsd_etc_rw_t classes.conf > > And see if it works? It's worth pointing out that I finally gave up and changed the way that system-config-printer writes out configuration files, just to make selinux happy. This week's Fedora Update contains that change, so possibly the reporter did not have that package updated. I had been getting it to write to a new file in the correct directory, then rename over the original file. The new way is to overwrite the original file and cross our fingers that CUPS doesn't want to read the file before we've finished writing it. Daniel, for the record: what is the recommended way for system tools to write configuration files? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Thu Jul 28 15:56:48 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Jul 2005 11:56:48 -0400 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: <20050728155020.GG1950@redhat.com> References: <42D8ECE0.9020307@redhat.com> <42E8F6CF.7050307@redhat.com> <20050728155020.GG1950@redhat.com> Message-ID: <42E90040.8030604@redhat.com> Tim Waugh wrote: >On Thu, Jul 28, 2005 at 11:16:31AM -0400, Daniel J Walsh wrote: > > > >>Can you change classes.conf to cupsd_etc_rw_t? >> >>chcon -t cupsd_etc_rw_t classes.conf >> >>And see if it works? >> >> > >It's worth pointing out that I finally gave up and changed the way >that system-config-printer writes out configuration files, just to >make selinux happy. This week's Fedora Update contains that change, >so possibly the reporter did not have that package updated. > >I had been getting it to write to a new file in the correct directory, >then rename over the original file. The new way is to overwrite the >original file and cross our fingers that CUPS doesn't want to read the >file before we've finished writing it. > >Daniel, for the record: what is the recommended way for system tools >to write configuration files? > > Is system-config-printer or the backend server rewrting the file? Changing classes.conf to cupsd_etc_rw_t should allow the backend to rewrite the file. >Tim. >*/ > > -- From sds at tycho.nsa.gov Thu Jul 28 15:56:17 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Jul 2005 11:56:17 -0400 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: <20050728155020.GG1950@redhat.com> References: <42D8ECE0.9020307@redhat.com> <42E8F6CF.7050307@redhat.com> <20050728155020.GG1950@redhat.com> Message-ID: <1122566177.6573.30.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-07-28 at 16:50 +0100, Tim Waugh wrote: > On Thu, Jul 28, 2005 at 11:16:31AM -0400, Daniel J Walsh wrote: > > > Can you change classes.conf to cupsd_etc_rw_t? > > > > chcon -t cupsd_etc_rw_t classes.conf > > > > And see if it works? > > It's worth pointing out that I finally gave up and changed the way > that system-config-printer writes out configuration files, just to > make selinux happy. This week's Fedora Update contains that change, > so possibly the reporter did not have that package updated. > > I had been getting it to write to a new file in the correct directory, > then rename over the original file. The new way is to overwrite the > original file and cross our fingers that CUPS doesn't want to read the > file before we've finished writing it. > > Daniel, for the record: what is the recommended way for system tools > to write configuration files? Creating a new file and renaming it over the old one is obviously safer. As far as the security context goes, you can either define an automatic file type transition if the (process domain, parent directory type) is sufficient to distinguish the file or you can have the program do an explicit setfscreatecon() before creating the new file, either using the result of a getfilecon() on the original file to get the old context or using matchpathcon() to get it from the policy based on the path. -- Stephen Smalley National Security Agency From twaugh at redhat.com Thu Jul 28 16:00:52 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 28 Jul 2005 17:00:52 +0100 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: <42E90040.8030604@redhat.com> References: <42D8ECE0.9020307@redhat.com> <42E8F6CF.7050307@redhat.com> <20050728155020.GG1950@redhat.com> <42E90040.8030604@redhat.com> Message-ID: <20050728160052.GI1950@redhat.com> On Thu, Jul 28, 2005 at 11:56:48AM -0400, Daniel J Walsh wrote: > Is system-config-printer or the backend server rewrting the file? > Changing classes.conf to cupsd_etc_rw_t should allow the backend to > rewrite the file. The backend is doing it -- printconf-backend. As I mentioned before, the previous behaviour had been to create a new file and rename it over the old file, and the SELinux policy does not seem to allow that. Can you clarify what the correct procedure is for system tools that want to write configuration files for running daemons? Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cviniciusm at terra.com.br Thu Jul 28 17:15:25 2005 From: cviniciusm at terra.com.br (Vinicius) Date: Thu, 28 Jul 2005 14:15:25 -0300 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: <20050728160052.GI1950@redhat.com> References: <42D8ECE0.9020307@redhat.com> <42E8F6CF.7050307@redhat.com> <20050728155020.GG1950@redhat.com> <42E90040.8030604@redhat.com> <20050728160052.GI1950@redhat.com> Message-ID: Tim Waugh escreveu: > On Thu, Jul 28, 2005 at 11:56:48AM -0400, Daniel J Walsh wrote: > > >>Is system-config-printer or the backend server rewrting the file? >>Changing classes.conf to cupsd_etc_rw_t should allow the backend to >>rewrite the file. > > > The backend is doing it -- printconf-backend. > > As I mentioned before, the previous behaviour had been to create a new > file and rename it over the old file, and the SELinux policy does not > seem to allow that. Can you clarify what the correct procedure is for > system tools that want to write configuration files for running > daemons? > > Thanks, > Tim. > */ > Excuse me, I was confusing, because the avc message that I saw is related to when I changed the default printer using the cups web interface, one printer uses the hplip driver the another one no. I think that's it. But, I did do strace xsane with SELinux enabled and with it disabled, and I get the following: "$ grep 32770 strace_xsane_with_selinux.txt read(6, "32770\n", 4096) = 6 connect(6, {sa_family=AF_INET, sin_port=htons(32770), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 $ grep 32770 strace_xsane_without_selinux.txt read(6, "32770\n", 4096) = 6 connect(6, {sa_family=AF_INET, sin_port=htons(32770), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 $ grep 32771 strace_xsane_with_selinux.txt read(6, "32771\n", 4096) = 6 connect(7, {sa_family=AF_INET, sin_port=htons(32771), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused) $ grep 32771 strace_xsane_without_selinux.txt read(6, "32771\n", 4096) = 6 connect(7, {sa_family=AF_INET, sin_port=htons(32771), sin_addr=inet_addr("127.0.0.1")}, 16) = 0" And the audit log doesn't show nothing about the port 32771, with SELinux enabled. I'm lost. Any ideas, please? Vinicius. From bobk at ocf.berkeley.edu Thu Jul 28 18:36:46 2005 From: bobk at ocf.berkeley.edu (Bobby Kashani) Date: Thu, 28 Jul 2005 11:36:46 -0700 Subject: audit update breaks hwclock In-Reply-To: <20050728122628.69259.qmail@web51505.mail.yahoo.com> References: <20050728122628.69259.qmail@web51505.mail.yahoo.com> Message-ID: <1122575806.2611.3.camel@chaucer> On Thu, 2005-07-28 at 05:26 -0700, Steve G wrote: > >After updating audit today I get an error after udev is started that > >says that it can't connot to the audit system. > > Are you sure that you didn't update util-linux, too? I did submit a patch to > util-linux to make hwclock log its actions as this is required by CAPP. I guess > that got pushed out. I get the same error and my clock is whacked too. util-linux-2.12p-9.7 audit-0.9.19-2.FC4 audit-libs-0.9.19-2.FC4 type=SELINUX_ERR msg=audit(1122574921.986:5): SELinux: unrecognized netlink message type=1009 for sclass=49 [medieval at chaucer ~]$ audit2allow -d allow hwclock_t self:netlink_audit_socket create; Bob -- Bobby Kashani http://www.ocf.berkeley.edu/~bobk/garnome From james.zheng.li at gmail.com Fri Jul 29 02:42:21 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Thu, 28 Jul 2005 22:42:21 -0400 Subject: SElinux policy for pine Message-ID: <8a239a560507281942ef33e59@mail.gmail.com> Hi all, First, sorry for my English. I wrote a set of SELinux policy rules for pine ( pine-4.63-1.i386.rpm) on FC4 (targeted). It works well IF no email attachments involved. As root, you are able to browse the whole filesystem: get a file from anywhere as the attachment or save the attachment to anywhere you like. Does this make the security policy totally broken? At the same time, I was also evaluating LIDS (lids.org). As for pine under LIDS, it has same problem: it requires WRITE (including READ) permission to "/" (inode number of "/"). For SELinux, since the policy is based on domain/type, it is even worse in the sense of policy writing: it requires one rw_dir_file rule for each of several hundreds of types on the whole filesystem, so several hundreds of rules will be added. I was thinking if there is a chroot mode for pine but I could not find any useful info. Another potential way to solve this problem is that to create a directory under user's (root's) home direcroty, which is only used to store email attachments: you need copy files from everywhere else to this directory before you can upload them as outgoing attachments; and all incoming attachments will be saved to this directory first, then you can copy or move them to somewhere else. By doing this, we can write corresponding policy to label this directory and grant permissions. Any suggestions? James Enclosed pls find my pine.fc and pine.te files ################################ #/etc/selinux/targeted/src/policy/file_contexts/program/pine.fc # pine.fc # Authors: james.zheng.li at gmail.com ################################ /usr/bin/mailutil -- system_u:object_r:pine_exec_t /usr/bin/pico -- system_u:object_r:pine_exec_t /usr/bin/pilot -- system_u:object_r:pine_exec_t /usr/bin/pine -- system_u:object_r:pine_exec_t /usr/bin/rpdump -- system_u:object_r:pine_exec_t /usr/bin/rpload -- system_u:object_r:pine_exec_t /usr/sbin/mlock -- system_u:object_r:pine_exec_t /etc/pine\.info -- system_u:object_r:pine_etc_t /etc/pine\.conf -- system_u:object_r:pine_etc_t /etc/pine\.conf\.fixed -- system_u:object_r:pine_etc_t HOME_DIR/mail(/.*)? system_u:object_r:pine_user_home_t HOME_DIR/\.addressbook(\.lu)? -- system_u:object_r:pine_user_home_t HOME_DIR/\.pine-debug[1-4] -- system_u:object_r:pine_user_home_t HOME_DIR/\.pinerc -- system_u:object_r:pine_user_home_t HOME_DIR/\.newsrc -- system_u:object_r:pine_user_home_t HOME_DIR/\.signature -- system_u:object_r:pine_user_home_t HOME_DIR/\.mailcap -- system_u:object_r:pine_user_home_t HOME_DIR/\.mime\.types -- system_u:object_r:pine_user_home_t HOME_DIR/\.pine-interrupted-mail -- system_u:object_r:pine_user_home_t HOME_DIR/dead\.letter -- system_u:object_r:pine_user_home_t ################################# #/etc/selinux/targeted/src/policy/domains/program/pine.te # pine.te # Authors: james.zheng.li at gmail.com ################################# # # Rules for the pine domain. # # pine_t is the domain for the pine program # pine_exec_t is the type of the corresponding program. # type pine_t, domain,privmail,nscd_client_domain; type pine_exec_t, file_type, sysadmfile, exec_type; type pine_user_home_t, file_type, sysadmfile, customizable; type pine_etc_t, file_type, sysadmfile; role sysadm_r types pine_t; role system_r types pine_t; #role user_r types pine_t; domain_auto_trans(sysadm_t, pine_exec_t, pine_t) #domain_auto_trans(initrc_t, pine_exec_t, pine_t) file_type_auto_trans(pine_t,user_home_dir_t,pine_user_home_t,dir_file_class_set) general_domain_access(pine_t) tmp_domain(pine) can_exec(pine_t, pine_exec_t) read_sysctl(pine_t) uses_shlib(pine_t) allow pine_t devpts_t:chr_file create_file_perms; allow pine_t devpts_t:dir search; allow pine_t etc_t:file { getattr read }; allow pine_t etc_t:lnk_file read; read_locale(pine_t) allow pine_t mail_spool_t:dir rw_dir_perms; allow pine_t mail_spool_t:file create_file_perms; allow pine_t proc_t:dir search; allow pine_t proc_t:lnk_file read; allow pine_t urandom_device_t:chr_file getattr; allow pine_t usr_t:file read; allow pine_t var_spool_t:dir search; allow pine_t fs_t:filesystem getattr; allow pine_t net_conf_t:file r_file_perms; allow pine_t sbin_t:dir search; allow pine_t sbin_t:lnk_file read; allow system_mail_t pine_tmp_t:file { read write }; allow system_mail_t pine_user_home_t:file { read write }; allow pine_t home_root_t:dir { getattr search }; allow pine_t self:capability { fsetid fowner}; From dragoran at feuerpokemon.de Fri Jul 29 06:23:20 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 29 Jul 2005 08:23:20 +0200 Subject: audit update breaks hwclock In-Reply-To: <1122575806.2611.3.camel@chaucer> References: <20050728122628.69259.qmail@web51505.mail.yahoo.com> <1122575806.2611.3.camel@chaucer> Message-ID: <42E9CB58.20306@feuerpokemon.de> Bobby Kashani wrote: >On Thu, 2005-07-28 at 05:26 -0700, Steve G wrote: > > >>>After updating audit today I get an error after udev is started that >>>says that it can't connot to the audit system. >>> >>> >>Are you sure that you didn't update util-linux, too? I did submit a patch to >>util-linux to make hwclock log its actions as this is required by CAPP. I guess >>that got pushed out. >> >> > >I get the same error and my clock is whacked too. > >util-linux-2.12p-9.7 >audit-0.9.19-2.FC4 >audit-libs-0.9.19-2.FC4 > >type=SELINUX_ERR msg=audit(1122574921.986:5): SELinux: unrecognized >netlink message type=1009 for sclass=49 > >[medieval at chaucer ~]$ audit2allow -d >allow hwclock_t self:netlink_audit_socket create; > >Bob > > > I filled a bugzilla for this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164603 yes I updated util-linux too: util-linux-2.12p-9.7 From dragoran at feuerpokemon.de Fri Jul 29 06:43:16 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 29 Jul 2005 08:43:16 +0200 Subject: audit update breaks hwclock In-Reply-To: <42E9CB58.20306@feuerpokemon.de> References: <20050728122628.69259.qmail@web51505.mail.yahoo.com> <1122575806.2611.3.camel@chaucer> <42E9CB58.20306@feuerpokemon.de> Message-ID: <42E9D004.5050709@feuerpokemon.de> dragoran wrote > Bobby Kashani wrote: > >> On Thu, 2005-07-28 at 05:26 -0700, Steve G wrote: >> >> >>>> After updating audit today I get an error after udev is started >>>> that says that it can't connot to the audit system. >>>> >>> >>> Are you sure that you didn't update util-linux, too? I did submit a >>> patch to >>> util-linux to make hwclock log its actions as this is required by >>> CAPP. I guess >>> that got pushed out. >>> >> >> >> I get the same error and my clock is whacked too. >> >> util-linux-2.12p-9.7 >> audit-0.9.19-2.FC4 >> audit-libs-0.9.19-2.FC4 >> >> type=SELINUX_ERR msg=audit(1122574921.986:5): SELinux: unrecognized >> netlink message type=1009 for sclass=49 >> >> [medieval at chaucer ~]$ audit2allow -d >> allow hwclock_t self:netlink_audit_socket create; >> >> Bob >> >> >> > I filled a bugzilla for this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164603 > yes I updated util-linux too: util-linux-2.12p-9.7 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > updating to selinux-policy-targeted from updates testing fixes this problem. From exinor at exinor.net Fri Jul 29 09:44:36 2005 From: exinor at exinor.net (Nicklas Norling) Date: Fri, 29 Jul 2005 11:44:36 +0200 Subject: Squirrelmail forward plugin In-Reply-To: <42DFAE18.6090307@exinor.net> References: <42DFAE18.6090307@exinor.net> Message-ID: <42E9FA84.4060609@exinor.net> Hi, I've compiled a local policy for the squirrel plugin mail_fwd found at http://www.squirrelmail.org/plugin_view.php?id=16. The minimum required for creating and removing a users .forward file is: allow httpd_sys_script_t self:capability { setgid setuid }; allow httpd_sys_script_t user_home_dir_t:dir { write add_name remove_name }; allow httpd_sys_script_t user_home_dir_t:file { write create getattr unlink }; Are these appropriate for inclusion in the next targetted policy or should I send this info for inclusion in the plugins docs? Seems like an awful lot of rights to hand out? The plugin has 18000 downloads according to their webpage. /Nicke Nicklas Norling wrote: > Hi. > > Just noted a user tried to add .forward by using the forwarding module > in squirrelmail. > > Jul 20 00:56:52 spock kernel: audit(1121813812.917:1844): avc: > denied { setgid } for pid=24466 comm="wfwd" capability=6 > scontext=root:system_r:httpd_sys_script_t > tcontext=root:system_r:httpd_sys_script_t tclass=capability > > httpd log: > /usr/local/sbin/wfwd: Operation not permitted > > [root at spock html]# audit2allow -d -l > allow httpd_sys_script_t self:capability setgid; > > The tool used is wfwd. > From dwalsh at redhat.com Fri Jul 29 10:17:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Jul 2005 06:17:42 -0400 Subject: Squirrelmail forward plugin In-Reply-To: <42E9FA84.4060609@exinor.net> References: <42DFAE18.6090307@exinor.net> <42E9FA84.4060609@exinor.net> Message-ID: <42EA0246.4050600@redhat.com> Nicklas Norling wrote: > Hi, > > I've compiled a local policy for the squirrel plugin mail_fwd found at > http://www.squirrelmail.org/plugin_view.php?id=16. > > The minimum required for creating and removing a users .forward file is: > > allow httpd_sys_script_t self:capability { setgid setuid }; > allow httpd_sys_script_t user_home_dir_t:dir { write add_name > remove_name }; > allow httpd_sys_script_t user_home_dir_t:file { write create getattr > unlink }; > Seems like we need policy for the plugin. IE a domain has to be written for it. Maybe a squirrel_helper_exec_t, squirrel_helper_t. > Are these appropriate for inclusion in the next targetted policy or > should I > send this info for inclusion in the plugins docs? Seems like an awful > lot of rights > to hand out? > > The plugin has 18000 downloads according to their webpage. > /Nicke > > Nicklas Norling wrote: > >> Hi. >> >> Just noted a user tried to add .forward by using the forwarding >> module in squirrelmail. >> >> Jul 20 00:56:52 spock kernel: audit(1121813812.917:1844): avc: >> denied { setgid } for pid=24466 comm="wfwd" capability=6 >> scontext=root:system_r:httpd_sys_script_t >> tcontext=root:system_r:httpd_sys_script_t tclass=capability >> >> httpd log: >> /usr/local/sbin/wfwd: Operation not permitted >> >> [root at spock html]# audit2allow -d -l >> allow httpd_sys_script_t self:capability setgid; >> >> The tool used is wfwd. >> > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From jorton at redhat.com Fri Jul 29 10:39:08 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 29 Jul 2005 11:39:08 +0100 Subject: Abnormal Apache behavior. In-Reply-To: <1120830210.19035.50.camel@moss-spartans.epoch.ncsc.mil> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> <1120618035.29103.5.camel@nexus.verbum.private> <20050708131558.GA22850@redhat.com> <1120830210.19035.50.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20050729103908.GA27354@redhat.com> On Fri, Jul 08, 2005 at 09:43:30AM -0400, Stephen Smalley wrote: > On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote: > > Eh? I thought the transition happens upon exec of httpd regardless of > > who performs the exec. Empirical evidence suggests that's the case > > anyway... > > > > [root at tango ~]# service httpd stop > > Stopping httpd: [ OK ] > > [root at tango ~]# apachectl start > > [root at tango ~]# ps axZ | grep httpd > > root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start > > On FC4, apachectl start leaves it running in unconfined_t. In FC3, > since the system starts in unconfined_t (so both rc scripts and user > shells are in the same domain), there is no distinction, so you wouldn't > see a difference there. OK - can that be changed? I'd really much rather that apachectl, the init script, and direct invocation of /usr/sbin/httpd all had the same behaviour, as has been (mostly) the case forever. joe From russell at coker.com.au Fri Jul 29 11:45:11 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 29 Jul 2005 21:45:11 +1000 Subject: audit update breaks hwclock In-Reply-To: <20050728122628.69259.qmail@web51505.mail.yahoo.com> References: <20050728122628.69259.qmail@web51505.mail.yahoo.com> Message-ID: <200507292145.15956.russell@coker.com.au> On Thursday 28 July 2005 22:26, Steve G wrote: > >After updating audit today I get an error after udev is started that > >says that it can't connot to the audit system. > > Are you sure that you didn't update util-linux, too? I did submit a patch > to util-linux to make hwclock log its actions as this is required by CAPP. > I guess that got pushed out. The hwclock in rawhide doesn't have that, so it seems that the update got in FC4 before Rawhide. :( I've attached a policy patch against the rawhide policy to get things going again. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 347 bytes Desc: not available URL: From russell at coker.com.au Fri Jul 29 12:02:42 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 29 Jul 2005 22:02:42 +1000 Subject: crond and auditing Message-ID: <200507292202.47042.russell@coker.com.au> In vixie-cron-4.1-36.FC4 crond wants capability audit_control, is this desired? It seems that the rawhide version vixie-cron-4.1-36.FC5 isn't doing this, is rawhide lagging behind FC4 updates? I've attached a patch against the FC4 policy for this... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 472 bytes Desc: not available URL: From dwalsh at redhat.com Fri Jul 29 13:15:18 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Jul 2005 09:15:18 -0400 Subject: Abnormal Apache behavior. In-Reply-To: <20050729103908.GA27354@redhat.com> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> <1120618035.29103.5.camel@nexus.verbum.private> <20050708131558.GA22850@redhat.com> <1120830210.19035.50.camel@moss-spartans.epoch.ncsc.mil> <20050729103908.GA27354@redhat.com> Message-ID: <42EA2BE6.2060705@redhat.com> Joe Orton wrote: >On Fri, Jul 08, 2005 at 09:43:30AM -0400, Stephen Smalley wrote: > > >>On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote: >> >> >>>Eh? I thought the transition happens upon exec of httpd regardless of >>>who performs the exec. Empirical evidence suggests that's the case >>>anyway... >>> >>>[root at tango ~]# service httpd stop >>>Stopping httpd: [ OK ] >>>[root at tango ~]# apachectl start >>>[root at tango ~]# ps axZ | grep httpd >>>root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start >>> >>> >>On FC4, apachectl start leaves it running in unconfined_t. In FC3, >>since the system starts in unconfined_t (so both rc scripts and user >>shells are in the same domain), there is no distinction, so you wouldn't >>see a difference there. >> >> > >OK - can that be changed? I'd really much rather that apachectl, the >init script, and direct invocation of /usr/sbin/httpd all had the same >behaviour, as has been (mostly) the case forever. > >joe > > > > > It already has been. apachectl is set to initrc_exec_t whith will start httpd in the correct context. Install the latest policy for FC4 and run restorecon on apachectl if it is not set to initrc_exec_t. Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From jorton at redhat.com Fri Jul 29 13:17:52 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 29 Jul 2005 14:17:52 +0100 Subject: Abnormal Apache behavior. In-Reply-To: <42EA2BE6.2060705@redhat.com> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> <1120618035.29103.5.camel@nexus.verbum.private> <20050708131558.GA22850@redhat.com> <1120830210.19035.50.camel@moss-spartans.epoch.ncsc.mil> <20050729103908.GA27354@redhat.com> <42EA2BE6.2060705@redhat.com> Message-ID: <20050729131752.GB8263@redhat.com> On Fri, Jul 29, 2005 at 09:15:18AM -0400, Daniel J Walsh wrote: > It already has been. apachectl is set to initrc_exec_t whith will > start httpd in the correct context. Install the latest policy for FC4 > and run restorecon on apachectl if it is not set to initrc_exec_t. Ah, great, yes, I see it on my current system. Thanks Dan. joe From sds at tycho.nsa.gov Fri Jul 29 13:24:06 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 29 Jul 2005 09:24:06 -0400 Subject: The HP PSC 1315 is recognized by FC4, print but not scan yet. In-Reply-To: <20050728160052.GI1950@redhat.com> References: <42D8ECE0.9020307@redhat.com> <42E8F6CF.7050307@redhat.com> <20050728155020.GG1950@redhat.com> <42E90040.8030604@redhat.com> <20050728160052.GI1950@redhat.com> Message-ID: <1122643446.6573.118.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-07-28 at 17:00 +0100, Tim Waugh wrote: > As I mentioned before, the previous behaviour had been to create a new > file and rename it over the old file, and the SELinux policy does not > seem to allow that. Can you clarify what the correct procedure is for > system tools that want to write configuration files for running > daemons? So, what precisely is the problem with allowing it to create a new file and rename it over the old file? While using a file type transition to put the new file into the correct type or modifying the program to use setfscreatecon() to explicitly label it with the correct type? -- Stephen Smalley National Security Agency From walters at redhat.com Fri Jul 29 13:32:16 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 29 Jul 2005 09:32:16 -0400 Subject: Abnormal Apache behavior. In-Reply-To: <20050729103908.GA27354@redhat.com> References: <1120610602.4019.13.camel@lt-sh.intern.pcservice.de> <1120618035.29103.5.camel@nexus.verbum.private> <20050708131558.GA22850@redhat.com> <1120830210.19035.50.camel@moss-spartans.epoch.ncsc.mil> <20050729103908.GA27354@redhat.com> Message-ID: <1122643936.15243.11.camel@nexus.verbum.private> On Fri, 2005-07-29 at 11:39 +0100, Joe Orton wrote: > On Fri, Jul 08, 2005 at 09:43:30AM -0400, Stephen Smalley wrote: > > On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote: > > > Eh? I thought the transition happens upon exec of httpd regardless of > > > who performs the exec. Empirical evidence suggests that's the case > > > anyway... > > > > > > [root at tango ~]# service httpd stop > > > Stopping httpd: [ OK ] > > > [root at tango ~]# apachectl start > > > [root at tango ~]# ps axZ | grep httpd > > > root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start > > > > On FC4, apachectl start leaves it running in unconfined_t. In FC3, > > since the system starts in unconfined_t (so both rc scripts and user > > shells are in the same domain), there is no distinction, so you wouldn't > > see a difference there. > > OK - can that be changed? I'd really much rather that apachectl, the > init script, and direct invocation of /usr/sbin/httpd all had the same > behaviour, as has been (mostly) the case forever. For direct invocation of /usr/sbin/httpd; we can't have it both ways. It has to either be confined or not confined. People seem to want it unconfined so e.g. httpd -t can still print to the terminal. From hhoffman at ip-solutions.net Fri Jul 29 14:50:53 2005 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 29 Jul 2005 10:50:53 -0400 (EDT) Subject: FC4, selinux, cyrus-imapd, saslauthd Message-ID: <20050729105013.J4547@surf.gcrc.upenn.edu> Hi All, Running FC4 with targeted policy and getting AVC messages when cyrus-imapd tries to connect to the saslauthd socket. Here are the pertinent msgs: type=AVC msg=audit(1122586257.404:286451): avc: denied { search } for pid=2727 comm="imapd" name="saslauthd" dev=dm-3 ino=157128 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir type=SYSCALL msg=audit(1122586257.404:286451): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bf8b13d0 a2=804228 a3=bf8b1437 items=1 pid=2727 auid=0 uid=76 gid=12 euid=76 suid=76 fsuid=76 egid=12 sgid=12 fsgid=12 comm="imapd" exe="/usr/lib/cyrus-imapd/imapd" type=SOCKADDR msg=audit(1122586257.404:286451): saddr=01002F7661722F72756E2F7361736C61757468642F6D75780000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Thanks, Harry From linux_4ever at yahoo.com Fri Jul 29 16:39:45 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 29 Jul 2005 09:39:45 -0700 (PDT) Subject: crond and auditing In-Reply-To: <200507292202.47042.russell@coker.com.au> Message-ID: <20050729163945.93977.qmail@web51501.mail.yahoo.com> >In vixie-cron-4.1-36.FC4 crond wants capability audit_control, is this >desired? Yes. It has to set the loginuid. >It seems that the rawhide version vixie-cron-4.1-36.FC5 isn't doing >this, is rawhide lagging behind FC4 updates? They are supposed to in sync. The change was to add pam_loginuid.so to the pam config. -Steve ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From linux_4ever at yahoo.com Fri Jul 29 16:44:36 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 29 Jul 2005 09:44:36 -0700 (PDT) Subject: FC4, selinux, cyrus-imapd, saslauthd In-Reply-To: <20050729105013.J4547@surf.gcrc.upenn.edu> Message-ID: <20050729164436.32091.qmail@web51508.mail.yahoo.com> Hi, I'm working on some documentation for the audit system, but I wanted to use this as an example to show people something until I get docs finshed. >type=AVC msg=audit(1122586257.404:286451): avc: denied { search } If you take the number after the ':' in the serial number and use ausearch, you can make this more understandable. Try: ausearch -i -a 286451 See if that makes it easier to understand. -Steve ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From al4in at jagua.cfg.sld.cu Sat Jul 30 03:32:01 2005 From: al4in at jagua.cfg.sld.cu (Alain Reguera Delgado) Date: Fri, 29 Jul 2005 23:32:01 -0400 Subject: Selinux Apache avc denied Message-ID: <1122694321.3536.11.camel@humus.cfg.sld.cu> Hi, this is my first message. I am completely new in SELinux. I can't make my web application able to send emails. Selinux blocks it and return to me an avc denied in /var/log/messages. --- ... Jul 27 15:41:38 hostname kernel: audit(1122493298.486:0): avc: denied { execute } for pid=4011 comm=httpd name=bash dev=hda5 ino=844138 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:shell_exec_t tclass=file ... --- Have you some comments about? I've been reading the faqs and redhat's manual, but it turns confuse to me. I continue reading and write to you, hoping you light my selinux's way, and help me to work in the first steps understanding the technology. I've been stopped the web development. I feel selinux is a brilliant technology I'd like to implement in my webserver. Thanks for your reading time...\:)> -- alain -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Valdis.Kletnieks at vt.edu Sat Jul 30 03:56:39 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 29 Jul 2005 23:56:39 -0400 Subject: Selinux Apache avc denied In-Reply-To: Your message of "Fri, 29 Jul 2005 23:32:01 EDT." <1122694321.3536.11.camel@humus.cfg.sld.cu> References: <1122694321.3536.11.camel@humus.cfg.sld.cu> Message-ID: <200507300356.j6U3uemr010001@turing-police.cc.vt.edu> On Fri, 29 Jul 2005 23:32:01 EDT, Alain Reguera Delgado said: > I've been stopped the web development. I feel selinux is a brilliant > technology I'd like to implement in my webserver. Actually, you have that almost totally backwards - SELinux is a brilliant technology that gets implemented in the kernel to make sure it doesn't matter *what* gets implemented in the webserver. Even if malicious code gets control of the webserver, it still can't access anything the webserver wasn't supposed to access... Now, about the actual problem: > Jul 27 15:41:38 hostname kernel: audit(1122493298.486:0): avc: denied > { execute } for pid=4011 comm=httpd name=bash dev=hda5 ino=844138 > scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:shell_exec_t > tclass=file Unfortunately, this is *much* too big a can of worms to solve directly - it would be technically possible to just add a rule that says 'httpd_t can exec shell_exec_t' - but that would be a *really* *bad* idea because then any exploit could get a shell (and exec_no_trans only partially minimizes the problem). Can you re-arrange the code so that /usr/sbin/sendmail gets invoked directly, rather than via a shell? If so, then maybe we can add a can_exec of sendmail_exec_t. Policy Gurus: How big a hole would adding a 'can_exec(sendmail_exec_t)' or 'domain_auto_trans(sendmail_t)' cause? And how many of these common "web interface wants to send mail" problems would it solve? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From roger at gwch.net Sun Jul 31 13:22:32 2005 From: roger at gwch.net (Roger Grosswiler) Date: Sun, 31 Jul 2005 15:22:32 +0200 Subject: update from fc3 -> fc4: cyrus/sasl-errors Message-ID: <42ECD098.7020406@gwch.net> hi, i recently updated from fc3 to fc4. i use this machine as a mailserver with cyrus. 1st problem was the database - fixed issue. now, on authentication, i get errors, will say, with selinux enforcing i cannot authenticate at all. from the fc-list i got some help, with a few commands, that should help better understanding. What can i do, to have this box with selinux enforcing enabled? ah, yes, in permissive mode it works fine. here a sniplet of my logs: > [root at link ~]# ausearch -i -a 9657218 > ---- > type=PATH msg=audit(07/30/05 16:21:20.281:9657218) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(07/30/05 16:21:20.281:9657218) : nargs=3 a0=b a1=bfd308fa a2=6e > type=SOCKADDR msg=audit(07/30/05 16:21:20.281:9657218) : saddr=local /var/run/saslauthd/mux > type=SYSCALL msg=audit(07/30/05 16:21:20.281:9657218) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd > type=AVC msg=audit(07/30/05 16:21:20.281:9657218) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir > >> ausearch -i -a 9659874 >> >> > [root at link ~]# ausearch -i -a 9659874 > ---- > type=PATH msg=audit(07/30/05 16:21:24.635:9659874) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(07/30/05 16:21:24.635:9659874) : nargs=3 a0=b a1=bfd308fa a2=6e > type=SOCKADDR msg=audit(07/30/05 16:21:24.635:9659874) : saddr=local /var/run/saslauthd/mux > type=SYSCALL msg=audit(07/30/05 16:21:24.635:9659874) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd > type=AVC msg=audit(07/30/05 16:21:24.635:9659874) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir i hope, you can help. Thanks a lot Roger From netdxr at gmail.com Sun Jul 31 22:18:39 2005 From: netdxr at gmail.com (Tom Lisjac) Date: Sun, 31 Jul 2005 16:18:39 -0600 Subject: Problem with saslauthd and winbind Message-ID: <863ff452050731151875e7cd9c@mail.gmail.com> Cyrus-imap authentication fails when using saslauthd with pam and winbind in active directory mode. I'm running FC4 with selinux-policy-targeted-1.25.3-6 . The following in local.te fixes it: allow saslauthd_t samba_var_t:dir search; allow saslauthd_t selinux_config_t:dir search; allow saslauthd_t selinux_config_t:file { getattr read }; allow saslauthd_t winbind_t:unix_stream_socket connectto; allow saslauthd_t winbind_var_run_t:sock_file { getattr write }; My question is: should this be reported as a bug? There are a large number of possible configurations with saslauthd, pam and winbind. Is the ultimate goal to support them all? -Tom