From dax at gurulabs.com Thu Apr 1 01:47:01 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 31 Mar 2004 18:47:01 -0700 (MST) Subject: FCT2 avc messages Message-ID: I did an "everything" install of FC2T2. On the first boot I saw a few avc messages, but now I just see these ones on boot: audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file audit(1080783274.604:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file On shutdown this command fails because of SELINUX with an avc message (which I don't have): Line 69 of /etc/init.d/halt : /bin/aumix-minimal -f /etc/.aumixrc -S The write to /etc/.aumixrc is denied. Other avc messages: Note that the ones at 4:03 AM are from the /etc/cron.daily/ being processed. Mar 31 00:21:27 mentor kernel: audit(1080717667.113:0): avc: denied { append } for pid=1182 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 00:21:27 mentor kernel: audit(1080717667.113:0): avc: denied { append } for pid=1182 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 00:21:27 mentor kernel: audit(1080717667.113:0): avc: denied { append } for pid=1182 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 00:21:52 mentor kernel: audit(1080717712.300:0): avc: denied { unix_read unix_write } for pid=50 exe=/usr/X11R6/bin/XFree86 key=0 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:system_r:initrc_t tclass=shm Mar 31 00:24:41 mentor kernel: audit(1080717881.247:0): avc: denied { unix_read unix_write } for pid=50 exe=/usr/X11R6/bin/XFree86 key=0 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:system_r:initrc_t tclass=shm Mar 31 00:26:41 mentor kernel: audit(1080718001.819:0): avc: denied { write } for pid=3405 exe=/bin/rm name=fd dev= ino=223150089 scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:initrc_t tclass=dir Mar 31 00:28:12 mentor kernel: audit(1080718084.130:0): avc: denied { append } for pid=1280 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 00:28:12 mentor kernel: audit(1080718084.131:0): avc: denied { append } for pid=1280 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 00:28:13 mentor kernel: audit(1080718084.131:0): avc: denied { append } for pid=1280 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 00:59:31 mentor kernel: audit(1080719971.236:0): avc: denied { write } for pid=3354 exe=/bin/aumix-minimal name=etc dev=hda8 ino=392449 scontext=root:system_r:sound_t tcontext=system_u:object_r:etc_t tclass=dir Mar 31 01:00:00 mentor kernel: audit(1080720000.160:0): avc: denied { search } for pid=3355 exe=/bin/aumix-minimal name=tmp dev=hda8 ino=98113 scontext=root:system_r:sound_t tcontext=system_u:object_r:tmp_t tclass=dir Mar 31 02:09:05 mentor kernel: audit(1080724145.771:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/dev/random dev=hda8 ino=133233 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 02:09:05 mentor kernel: audit(1080724145.772:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/dev/null dev=hda8 ino=133232 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 02:09:05 mentor kernel: audit(1080724145.824:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/random dev=hda8 ino=133249 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 02:09:05 mentor kernel: audit(1080724145.824:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/null dev=hda8 ino=133250 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 02:09:07 mentor kernel: audit(1080724147.313:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/ram dev=ram0 ino=17 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=blk_file Mar 31 02:09:07 mentor kernel: audit(1080724147.313:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty3 dev=ram0 ino=18 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 02:09:07 mentor kernel: audit(1080724147.313:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty1 dev=ram0 ino=19 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/null dev=ram0 ino=20 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty4 dev=ram0 ino=21 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty2 dev=ram0 ino=22 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/systty dev=ram0 ino=23 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 02:09:07 mentor kernel: audit(1080724147.315:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/console dev=ram0 ino=24 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 04:03:58 mentor kernel: audit(1080731038.214:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/dev/random dev=hda8 ino=133233 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 04:03:58 mentor kernel: audit(1080731038.215:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/dev/null dev=hda8 ino=133232 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 04:03:58 mentor kernel: audit(1080731038.230:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/random dev=hda8 ino=133249 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 04:03:58 mentor kernel: audit(1080731038.230:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/null dev=hda8 ino=133250 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file Mar 31 04:03:59 mentor kernel: audit(1080731039.591:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/ram dev=ram0 ino=17 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=blk_file Mar 31 04:03:59 mentor kernel: audit(1080731039.592:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty3 dev=ram0 ino=18 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 04:03:59 mentor kernel: audit(1080731039.592:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty1 dev=ram0 ino=19 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 04:03:59 mentor kernel: audit(1080731039.592:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/null dev=ram0 ino=20 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 04:03:59 mentor kernel: audit(1080731039.593:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty4 dev=ram0 ino=21 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 04:03:59 mentor kernel: audit(1080731039.593:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty2 dev=ram0 ino=22 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 04:03:59 mentor kernel: audit(1080731039.593:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/systty dev=ram0 ino=23 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 04:03:59 mentor kernel: audit(1080731039.594:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/console dev=ram0 ino=24 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file Mar 31 10:25:41 mentor kernel: audit(1080753941.211:0): avc: denied { write } for pid=18069 exe=/bin/rm name=fd dev= ino=1184169993 scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:initrc_t tclass=dir Mar 31 18:34:38 mentor kernel: audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 18:34:38 mentor kernel: audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file Mar 31 18:34:38 mentor kernel: audit(1080783274.604:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file From russell at coker.com.au Thu Apr 1 02:19:48 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 1 Apr 2004 12:19:48 +1000 Subject: install of kernel 2.6.4-1.298 does not work In-Reply-To: <200403311146.51488.gene@czarc.net> References: <406A41D2.4030001@mindspring.com> <1080748248.27486.8.camel@wintermute.sr.unh.edu> <200403311146.51488.gene@czarc.net> Message-ID: <200404011219.48685.russell@coker.com.au> On Thu, 1 Apr 2004 02:46, Gene Czarcinski wrote: > > I had similar problems. Clean install of test2 with selinux in enforcing > > mode followed by a yum update. Many of the postinstall scripts reported > > failures and after a reboot (to boot the new kernel that didn't get > > installed) lots of things were very broken. Permissions on directories > > in /var were all messed up (as root I couldn't cd to /var/log to try to > > figure out what was going). So I did a clean install of test2 again, > > setting selinux to warn only, and things are much happier. It seems like > > the default policy of selinux kept many files from being updated > > properly. > > > > Let me know if you file a bug report so I can add to it. > > This is an selinux - rpm problem ... see: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119538 That one is due to installing packages as staff_r. The general idea with SE Linux is that you use sysadm_r for such things. In Fedora su and sudo should change to sysadm_r. If you login at the console as root you will get sysadm_r. It should just work. -- 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 jneedle at redhat.com Thu Apr 1 02:33:35 2004 From: jneedle at redhat.com (Jeff Needle) Date: Wed, 31 Mar 2004 21:33:35 -0500 (EST) Subject: install of kernel 2.6.4-1.298 does not work In-Reply-To: <200404011219.48685.russell@coker.com.au> Message-ID: > That one is due to installing packages as staff_r. The general idea with SE > Linux is that you use sysadm_r for such things. In Fedora su and sudo should > change to sysadm_r. If you login at the console as root you will get > sysadm_r. It should just work. I think if you ssh in as root, you are left as staff_r and need to use newrole to switch. j. From rhally at mindspring.com Thu Apr 1 02:37:59 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 31 Mar 2004 21:37:59 -0500 Subject: install of kernel 2.6.4-1.298 does not work In-Reply-To: <200404011219.48685.russell@coker.com.au> References: <406A41D2.4030001@mindspring.com> <1080748248.27486.8.camel@wintermute.sr.unh.edu> <200403311146.51488.gene@czarc.net> <200404011219.48685.russell@coker.com.au> Message-ID: <406B8087.8060304@mindspring.com> Russell Coker wrote: >On Thu, 1 Apr 2004 02:46, Gene Czarcinski wrote: > > >>>I had similar problems. Clean install of test2 with selinux in enforcing >>>mode followed by a yum update. Many of the postinstall scripts reported >>>failures and after a reboot (to boot the new kernel that didn't get >>>installed) lots of things were very broken. Permissions on directories >>>in /var were all messed up (as root I couldn't cd to /var/log to try to >>>figure out what was going). So I did a clean install of test2 again, >>>setting selinux to warn only, and things are much happier. It seems like >>>the default policy of selinux kept many files from being updated >>>properly. >>> >>>Let me know if you file a bug report so I can add to it. >>> >>> >>This is an selinux - rpm problem ... see: >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119538 >> >> > >That one is due to installing packages as staff_r. The general idea with SE >Linux is that you use sysadm_r for such things. In Fedora su and sudo should >change to sysadm_r. If you login at the console as root you will get >sysadm_r. It should just work. > > > Russel, if you look at the original post of this thread you will see that I was root and was in sysadm_r and ran into this problem. thanks for your help, Richard Hally From russell at coker.com.au Thu Apr 1 02:41:52 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 1 Apr 2004 12:41:52 +1000 Subject: install of kernel 2.6.4-1.298 does not work In-Reply-To: References: Message-ID: <200404011241.52932.russell@coker.com.au> On Thu, 1 Apr 2004 12:33, Jeff Needle wrote: > > That one is due to installing packages as staff_r. The general idea with > > SE Linux is that you use sysadm_r for such things. In Fedora su and sudo > > should change to sysadm_r. If you login at the console as root you will > > get sysadm_r. It should just work. > > I think if you ssh in as root, you are left as staff_r and need to use > newrole to switch. That is the default. Giving ultimate access over ssh isn't desirable, but it can be changed via the ssh_sysadm_login option. -- 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 aleksey at nogin.org Thu Apr 1 02:42:24 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 31 Mar 2004 18:42:24 -0800 Subject: install of kernel 2.6.4-1.298 does not work In-Reply-To: <406B8087.8060304@mindspring.com> References: <406A41D2.4030001@mindspring.com> <1080748248.27486.8.camel@wintermute.sr.unh.edu> <200403311146.51488.gene@czarc.net> <200404011219.48685.russell@coker.com.au> <406B8087.8060304@mindspring.com> Message-ID: <406B8190.1080405@nogin.org> On 31.03.2004 18:37, Richard Hally wrote: > Russel, if you look at the original post of this thread you will see > that I was root and was in sysadm_r and ran into this problem. The problem is tha up2date is not marked as rpm_exec_t. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119208 A temporary workaround is to run /usr/bin/setfilecon system_u:object_r:rpm_exec_t /usr/sbin/up2date to temporarily fix the file context of the up2date program. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From dax at gurulabs.com Thu Apr 1 04:38:15 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 31 Mar 2004 21:38:15 -0700 (MST) Subject: kernel RPM install avc message Message-ID: I have a fresh FC2T2 install. I did the following to make up2date work: /usr/bin/setfilecon system_u:object_r:rpm_exec_t /usr/sbin/up2date Then I ran "up2date-nox kernel" The following appeared. It seems the kernel did install OK. audit(1080787992.351:0): avc: denied { search } for pid=20375 exe=/bin/bash name=root dev=hda8 ino=179873 scontext=root:sysadm_r:bootloader_t tcontext=root:object_r:staff_home_dir_t tclass=dir /bin/bash: /root/.bashrc: Permission denied audit(1080787998.806:0): avc: denied { search } for pid=20791 exe=/sbin/grubby name=root dev=hda8 ino=179873 scontext=root:sysadm_r:bootloader_t tcontext=root:object_r:staff_home_dir_t tclass=dir From russell at coker.com.au Thu Apr 1 05:48:47 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 1 Apr 2004 15:48:47 +1000 Subject: kernel RPM install avc message In-Reply-To: References: Message-ID: <200404011548.47129.russell@coker.com.au> On Thu, 1 Apr 2004 14:38, Dax Kelson wrote: > I have a fresh FC2T2 install. I did the following to make up2date work: > > /usr/bin/setfilecon system_u:object_r:rpm_exec_t /usr/sbin/up2date > > Then I ran "up2date-nox kernel" > > The following appeared. It seems the kernel did install OK. > > audit(1080787992.351:0): avc: denied { search } for pid=20375 > exe=/bin/bash name=root dev=hda8 ino=179873 > scontext=root:sysadm_r:bootloader_t > tcontext=root:object_r:staff_home_dir_t tclass=dir > /bin/bash: /root/.bashrc: Permission denied What was the working directory at the time you ran up2date? Was it /home/something? We don't want to grant such domains wide access, and we also don't want large dontaudit rules (they increase the size of the policy, increase kernel memory use, etc). Is it acceptable that sometimes if you run something from an unusual directory then it will cause an audit message? -- 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 list at inksystems.net Thu Apr 1 09:21:49 2004 From: list at inksystems.net (Igor N. Kolomiyets) Date: Thu, 01 Apr 2004 10:21:49 +0100 Subject: Cannot login with SELinux tuned on In-Reply-To: <1080652298.20950.17.camel@moss-spartans.epoch.ncsc.mil> References: <20040329234259.GD5236@server4.8080.it> <200403301855.24222.russell@coker.com.au> <1080652298.20950.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <406BDF2D.9010209@inksystems.net> Hi All! I have a problem trying to log on with SELinux enforced. Every time i'm typing a user name and password it prompts: 'Would you like to enter a security context? [y]' This does not seem to be a proper behavior as in such case i cannot login from the graphic login screen at all. It always returns an error saying something like: 'Cannot load a default context'. The system was upgraded from FC1 to FC2test. Then the following line was added to the /etc/security/selinux/src/policy/users file user testuser roles { user_r }; Policy was rebuilt and reloaded as well as all files in the system were relabeled. I also ran the following line /usr/sbin/setfiles /etc/security/selinux/file_contexts /home as suggested. Can anybody point me in the right direction? What am i doing wrong? Any help, comments would be greatly appreciated. Best regards, Igor. From dwalsh at redhat.com Thu Apr 1 16:59:34 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Apr 2004 11:59:34 -0500 Subject: FCT2 avc messages In-Reply-To: References: Message-ID: <406C4A76.3070109@redhat.com> Dax Kelson wrote: >I did an "everything" install of FC2T2. On the first boot I saw a few avc >messages, but now I just see these ones on boot: > >audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >audit(1080783274.604:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file > > Should be fixed in latest policy from rawhide. >On shutdown this command fails because of SELINUX with an avc message >(which I don't have): > >Line 69 of /etc/init.d/halt : > >/bin/aumix-minimal -f /etc/.aumixrc -S > >The write to /etc/.aumixrc is denied. > >Other avc messages: > >Note that the ones at 4:03 AM are from the /etc/cron.daily/ being >processed. > >Mar 31 00:21:27 mentor kernel: audit(1080717667.113:0): avc: denied { append } for pid=1182 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 00:21:27 mentor kernel: audit(1080717667.113:0): avc: denied { append } for pid=1182 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 00:21:27 mentor kernel: audit(1080717667.113:0): avc: denied { append } for pid=1182 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 00:21:52 mentor kernel: audit(1080717712.300:0): avc: denied { unix_read unix_write } for pid=50 exe=/usr/X11R6/bin/XFree86 key=0 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:system_r:initrc_t tclass=shm >Mar 31 00:24:41 mentor kernel: audit(1080717881.247:0): avc: denied { unix_read unix_write } for pid=50 exe=/usr/X11R6/bin/XFree86 key=0 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:system_r:initrc_t tclass=shm >Mar 31 00:26:41 mentor kernel: audit(1080718001.819:0): avc: denied { write } for pid=3405 exe=/bin/rm name=fd dev= ino=223150089 scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:initrc_t tclass=dir >Mar 31 00:28:12 mentor kernel: audit(1080718084.130:0): avc: denied { append } for pid=1280 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 00:28:12 mentor kernel: audit(1080718084.131:0): avc: denied { append } for pid=1280 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 00:28:13 mentor kernel: audit(1080718084.131:0): avc: denied { append } for pid=1280 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 00:59:31 mentor kernel: audit(1080719971.236:0): avc: denied { write } for pid=3354 exe=/bin/aumix-minimal name=etc dev=hda8 ino=392449 scontext=root:system_r:sound_t tcontext=system_u:object_r:etc_t tclass=dir >Mar 31 01:00:00 mentor kernel: audit(1080720000.160:0): avc: denied { search } for pid=3355 exe=/bin/aumix-minimal name=tmp dev=hda8 ino=98113 scontext=root:system_r:sound_t tcontext=system_u:object_r:tmp_t tclass=dir >Mar 31 02:09:05 mentor kernel: audit(1080724145.771:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/dev/random dev=hda8 ino=133233 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 02:09:05 mentor kernel: audit(1080724145.772:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/dev/null dev=hda8 ino=133232 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 02:09:05 mentor kernel: audit(1080724145.824:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/random dev=hda8 ino=133249 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 02:09:05 mentor kernel: audit(1080724145.824:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/null dev=hda8 ino=133250 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.313:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/ram dev=ram0 ino=17 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=blk_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.313:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty3 dev=ram0 ino=18 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.313:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty1 dev=ram0 ino=19 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/null dev=ram0 ino=20 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty4 dev=ram0 ino=21 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/tty2 dev=ram0 ino=22 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.314:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/systty dev=ram0 ino=23 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 02:09:07 mentor kernel: audit(1080724147.315:0): avc: denied { getattr } for pid=12497 exe=/usr/bin/slocate path=/initrd/dev/console dev=ram0 ino=24 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 04:03:58 mentor kernel: audit(1080731038.214:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/dev/random dev=hda8 ino=133233 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 04:03:58 mentor kernel: audit(1080731038.215:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/dev/null dev=hda8 ino=133232 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 04:03:58 mentor kernel: audit(1080731038.230:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/random dev=hda8 ino=133249 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 04:03:58 mentor kernel: audit(1080731038.230:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/var/named/chroot/var/named/chroot/dev/null dev=hda8 ino=133250 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:named_conf_t tclass=chr_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.591:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/ram dev=ram0 ino=17 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=blk_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.592:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty3 dev=ram0 ino=18 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.592:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty1 dev=ram0 ino=19 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.592:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/null dev=ram0 ino=20 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.593:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty4 dev=ram0 ino=21 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.593:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/tty2 dev=ram0 ino=22 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.593:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/systty dev=ram0 ino=23 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 04:03:59 mentor kernel: audit(1080731039.594:0): avc: denied { getattr } for pid=16683 exe=/usr/bin/slocate path=/initrd/dev/console dev=ram0 ino=24 scontext=system_u:system_r:locate_t tcontext=system_u:object_r:file_t tclass=chr_file >Mar 31 10:25:41 mentor kernel: audit(1080753941.211:0): avc: denied { write } for pid=18069 exe=/bin/rm name=fd dev= ino=1184169993 scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:initrc_t tclass=dir >Mar 31 18:34:38 mentor kernel: audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.crit dev=hda8 ino=135289 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 18:34:38 mentor kernel: audit(1080783274.603:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.err dev=hda8 ino=135290 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file >Mar 31 18:34:38 mentor kernel: audit(1080783274.604:0): avc: denied { append } for pid=1281 exe=/sbin/syslogd name=news.notice dev=hda8 ino=135288 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:innd_log_t tclass=file > > > /initrd is supposed to be umounted, that looks like a bug in the initscripts. When you reboot is the /initrd directory mounted? >-- >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 Thu Apr 1 17:05:24 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Apr 2004 12:05:24 -0500 Subject: kernel RPM install avc message In-Reply-To: References: Message-ID: <406C4BD4.9080008@redhat.com> Dax Kelson wrote: >I have a fresh FC2T2 install. I did the following to make up2date work: > >/usr/bin/setfilecon system_u:object_r:rpm_exec_t /usr/sbin/up2date > >Then I ran "up2date-nox kernel" > >The following appeared. It seems the kernel did install OK. > >audit(1080787992.351:0): avc: denied { search } for pid=20375 >exe=/bin/bash name=root dev=hda8 ino=179873 >scontext=root:sysadm_r:bootloader_t >tcontext=root:object_r:staff_home_dir_t tclass=dir >/bin/bash: /root/.bashrc: Permission denied >audit(1080787998.806:0): avc: denied { search } for pid=20791 >exe=/sbin/grubby name=root dev=hda8 ino=179873 >scontext=root:sysadm_r:bootloader_t >tcontext=root:object_r:staff_home_dir_t tclass=dir > > > > Messages will be gone in tomorrows build. >-- >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 Thu Apr 1 17:10:43 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Apr 2004 12:10:43 -0500 Subject: Cannot login with SELinux tuned on In-Reply-To: <406BDF2D.9010209@inksystems.net> References: <20040329234259.GD5236@server4.8080.it> <200403301855.24222.russell@coker.com.au> <1080652298.20950.17.camel@moss-spartans.epoch.ncsc.mil> <406BDF2D.9010209@inksystems.net> Message-ID: <406C4D13.9000506@redhat.com> You need to relabel the entire system if you are doing an upgrade. make -c /etc/security/selinux/src/policy relabel Igor N. Kolomiyets wrote: > Hi All! > > I have a problem trying to log on with SELinux enforced. > > Every time i'm typing a user name and password it prompts: > > 'Would you like to enter a security context? [y]' > > This does not seem to be a proper behavior as in such case i cannot > login from the graphic login screen at all. It always returns an error > saying something like: 'Cannot load a default context'. > > The system was upgraded from FC1 to FC2test. Then the following line > was added to the /etc/security/selinux/src/policy/users file > > user testuser roles { user_r }; > > Policy was rebuilt and reloaded as well as all files in the system > were relabeled. > > I also ran the following line > > /usr/sbin/setfiles /etc/security/selinux/file_contexts /home > > as suggested. > > Can anybody point me in the right direction? What am i doing wrong? > Any help, comments would be greatly appreciated. > > Best regards, > Igor. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From kwade at redhat.com Thu Apr 1 21:13:20 2004 From: kwade at redhat.com (Karsten Wade) Date: 01 Apr 2004 13:13:20 -0800 Subject: FC1 compatibility - was [Bug 119719] New: SELinux FAQ - SELinux FAQ - suggested questions on FC1 compatability Message-ID: <1080853999.26646.136.camel@erato.phig.org> -----Forwarded Message----- > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119719 > > > Here are two questions likely to be frequently asked, missing from the > FAQ. They belong right after "Q: I installed Fedora Core on a system > with an existing /home partition, and now I can't log in." Thanks, good questions. Just because I'm brave, I'm going to start answers to these questions, but am hoping others will soon chime in and help with the final answers for the FAQ. Please! > Q: If I relabel my existing /home partition after upgrading to FC2, > will I still be able to read it if I need to revert to FC1? (In other > words, am I burning my bridges when I run setfiles or fixfiles?) You (should?) be able to read the files from an FC1 system, but if the FC1 system does not have SELinux installed or enabled, any writes it does to that partition will be without file context. (Would this include changing timestamps? What about writing to existing files which do have file contexts?) > Q: Can an NFS-mountable /home partition be shared by FC1 and FC2 > installations? Yes. You can mount a non-SELinux partition with the context= option, e.g.: mount -t nfs -o context=system_u:object_r:tmp_t server:/some/path /mnt/wherever All of the files on the mount will appear to have the context system_u:object_r:tmp_t to SELinux. Any files written by a non-SELinux system will not have file contexts, and the contexts of existing files are affected how? thx - Karsten -- Karsten Wade, Sr. Tech Writer this is not the .signature you are looking for http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From dwalsh at redhat.com Thu Apr 1 21:28:02 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Apr 2004 16:28:02 -0500 Subject: FC1 compatibility - was [Bug 119719] New: SELinux FAQ - SELinux FAQ - suggested questions on FC1 compatability In-Reply-To: <1080853999.26646.136.camel@erato.phig.org> References: <1080853999.26646.136.camel@erato.phig.org> Message-ID: <406C8962.6000006@redhat.com> Karsten Wade wrote: >-----Forwarded Message----- > > > >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119719 >> >> >>Here are two questions likely to be frequently asked, missing from the >>FAQ. They belong right after "Q: I installed Fedora Core on a system >>with an existing /home partition, and now I can't log in." >> >> > >Thanks, good questions. > >Just because I'm brave, I'm going to start answers to these questions, >but am hoping others will soon chime in and help with the final answers >for the FAQ. Please! > > > >>Q: If I relabel my existing /home partition after upgrading to FC2, >>will I still be able to read it if I need to revert to FC1? (In other >>words, am I burning my bridges when I run setfiles or fixfiles?) >> >> Newly created files will not have a context and if you remove an recreate a file it will not have a context. > >You (should?) be able to read the files from an FC1 system, but if the >FC1 system does not have SELinux installed or enabled, any writes it >does to that partition will be without file context. (Would this >include changing timestamps? What about writing to existing files which >do have file contexts?) > > > You can read the files on the fc1 system. Just newly created files. >>Q: Can an NFS-mountable /home partition be shared by FC1 and FC2 >>installations? >> >> > >Yes. You can mount a non-SELinux partition with the context= option, >e.g.: > > You can nfs mount off of a SELinux file system onto a non SELinux file system. You can also nfs mount a non SELinux file system on a SELinux machine. By default all files are treated as nfs_t context. You can choose to override the default context by using the context option >mount -t nfs -o context=system_u:object_r:tmp_t server:/some/path /mnt/wherever > >All of the files on the mount will appear to have the context >system_u:object_r:tmp_t to SELinux. > >Any files written by a non-SELinux system will not have file contexts, >and the contexts of existing files are affected how? > > > Not true. When SELinux exports the file system the files will end up with the default context of the \ directory they were created in. The remote system has no effect on the file contexts. >thx - Karsten > > From gene at czarc.net Thu Apr 1 22:28:15 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 1 Apr 2004 17:28:15 -0500 Subject: Not good Message-ID: <200404011728.15051.gene@czarc.net> OK, I updated with todays round of updates ... at least with respect to selinux. This includes the kernel, policy, policy-sources, and policycoreutils. I then rebooted and ran "make reload" and "make relabel". They seemed to complete OK. However, I cannot login from gdm as root (!), a regular user, or a user with a sysadm role defined ... I get an indication that the home directory could not be found (including for root). BTW, what are the "right" circumstances for running "make relabel"? I have sometimes gotten an error saying it could not handle "/dev/tty1". Should I plan to do this from single-user-mode? Gene From pope_murphy at hotmail.com Thu Apr 1 22:15:35 2004 From: pope_murphy at hotmail.com (murphy pope) Date: Thu, 01 Apr 2004 17:15:35 -0500 Subject: Bugs, features, or misunderstandings? Message-ID: <1080857735.5403.16.camel@localhost.localdomain> How can I create a new Linux user account such that the home directory is assigned the proper context? I want to create a new user (fred). I want fred's home directory to he located in the default location (/home/fred). And I want the context for /home/fred to be: fred:user_r:user_home_dir_t. useradd doesn't work. It seems to have two problems: 1) If my context (when I run useradd fred) is root:staff_r:staff_t, useradd sets the home directory to root:object_r:home_root_t. 2) If my context is root:sysadm_r:sysadm_t, useradd sets the home directory to root:object_r:user_home_dir_t Item 1 seems like a bug - why would it choose :home_root_t instead of :user_home_dir_t? In either case, the identity is wrong. I think the problem here is that fred is a Linux user, but not an identity. So, I tried seuseradd instead. That doesn't work either - it seems to create the identity (how would I know???) but the identity assigned to the home directory is still 'root'. Here are my questions: 1) Why is this so bloody difficult? Can you really expect the average user/administrator to deal with problems like this? 2) How can I create a new user whose home directory is assigned the proper identity? 3) How can I get a list of valid identities? 4) Can I add identities with a simple command (i.e. without recompiling the policy)? I know about seuserx, but that takes forever to run and is about as friendly as Windows 3.1. Thanks in advance. -- Murphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From pope_murphy at hotmail.com Thu Apr 1 22:55:45 2004 From: pope_murphy at hotmail.com (murphy pope) Date: Thu, 01 Apr 2004 17:55:45 -0500 Subject: Naming convention flames Message-ID: <1080860144.5403.28.camel@localhost.localdomain> I've been struggling to understand some of this SELinux stuff so I can explain it to other users. But I have my stupid-hat on these days. Why does SELinux use a separate user database? Why doesn't SELinux read the /etc/passwd database instead of maintaining its own? Has anybody ever said "hey, we've already got one database, things will get a whole lot clearer if we invent another one instead"? There seems to be some difference between a domain and a type, although given the lack of documentation, I'm not convinced of that. If they are different, who's idea was it to use the same naming convention for both? Why not user_t and user_d? Use _t to indicate a type and _d to indicate a domain. Or do they have to be from the same namespace? Does a type named user_t always exactly correspond to a domain named user_t? If so, what's the difference between a domain and a type? Why do we need useradd and seuseradd? Shouldn't useradd give me the option to create an identity? Or better yet, shouldn't useradd create an identity by default and give me the option to create a generic user instead? Sorry to sound so negative, but this stuff is not ready for prime-time and without some documentation, it never will be. Without good documentation, you're gonna have to revert this whole project. When something goes wrong, I don't know if it's a bug, or if it's my error, or if it's working right and I just don't know what I'm doing. -- Murphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at redhat.com Fri Apr 2 00:06:49 2004 From: walters at redhat.com (Colin Walters) Date: Thu, 01 Apr 2004 19:06:49 -0500 Subject: Bugs, features, or misunderstandings? In-Reply-To: <1080857735.5403.16.camel@localhost.localdomain> References: <1080857735.5403.16.camel@localhost.localdomain> Message-ID: <1080864409.30319.17.camel@nexus.verbum.private> On Thu, 2004-04-01 at 17:15, murphy pope wrote: > How can I create a new Linux user account such that the home directory > is assigned the proper context? > > I want to create a new user (fred). > I want fred's home directory to he located in the default location > (/home/fred). > And I want the context for /home/fred to be: > fred:user_r:user_home_dir_t. > > useradd doesn't work. It seems to have two problems: > 1) If my context (when I run useradd fred) is > root:staff_r:staff_t, useradd sets the home directory to > root:object_r:home_root_t. Basically don't run useradd (or do anything that in typical Linux/Unix requires "root") as staff_r. It's the loseness of the FC2 policy that lets it even halfway work. > 2) If my context is root:sysadm_r:sysadm_t, useradd sets the > home directory to root:object_r:user_home_dir_t > > Item 1 seems like a bug - why would it choose :home_root_t instead of > :user_home_dir_t? > In either case, the identity is wrong. The identity isn't really wrong in 2. Sure, the SELinux user identity component of the security context is "root", but that won't matter in this case, since the user can't relabel their home directory anyways. > 1) Why is this so bloody difficult? Can you really expect the average > user/administrator to deal with problems like this? We're working on a solution. > 2) How can I create a new user whose home directory is assigned the > proper identity? Become root/sysadm_r, and run useradd. > 3) How can I get a list of valid identities? By identity I'm assuming you mean security context; you could egrep for '^type ' in policy.conf I guess... > 4) Can I add identities with a simple command (i.e. without > recompiling the policy)? No. -------------- 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 jmorris at redhat.com Fri Apr 2 04:22:25 2004 From: jmorris at redhat.com (James Morris) Date: Thu, 1 Apr 2004 23:22:25 -0500 (EST) Subject: Naming convention flames In-Reply-To: <1080860144.5403.28.camel@localhost.localdomain> Message-ID: On Thu, 1 Apr 2004, murphy pope wrote: > I've been struggling to understand some of this SELinux stuff so I can > explain it to other users. But I have my stupid-hat on these days. > > Why does SELinux use a separate user database? Why doesn't SELinux read > the /etc/passwd database instead of maintaining its own? Has anybody > ever said "hey, we've already got one database, things will get a whole > lot clearer if we invent another one instead"? SELinux has an independent user identity model, which provides for more rigorous identity based access control than standard Unix. e.g. you can change Unix user id, but not SELinux user id. The reason there are separate databases is that there is not a direct mapping between Unix users and SELinux users. Many users in /etc/passwd can be mapped to a single SELinux user for access control purposes (e.g. system_u). There also needs to be a way to map the user to a set of roles, so a separate database is needed anyway. > There seems to be some difference between a domain and a type, although > given the lack of documentation, I'm not convinced of that. This is unfortunately confusing. Under SELinux, domains are actually types: there is no difference. Use of the term domain, referring to the type associated with a process, stems from traditional TE models where domains and types are separate. > Why do we need useradd and seuseradd? Shouldn't useradd give me the > option to create an identity? Or better yet, shouldn't useradd create an > identity by default and give me the option to create a generic user > instead? An OS developer can probably answer this best. > Sorry to sound so negative, but this stuff is not ready for prime-time > and without some documentation, it never will be. Without good > documentation, you're gonna have to revert this whole project. When > something goes wrong, I don't know if it's a bug, or if it's my error, > or if it's working right and I just don't know what I'm doing. The documentation is improving, at least. Thanks for the feedback, we should probably add these questions to the FAQ. - James -- James Morris From russell at coker.com.au Fri Apr 2 04:44:52 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 2 Apr 2004 14:44:52 +1000 Subject: Naming convention flames In-Reply-To: <1080860144.5403.28.camel@localhost.localdomain> References: <1080860144.5403.28.camel@localhost.localdomain> Message-ID: <200404021444.52546.russell@coker.com.au> On Fri, 2 Apr 2004 08:55, murphy pope wrote: > Why does SELinux use a separate user database? Why doesn't SELinux read > the /etc/passwd database instead of maintaining its own? Has anybody > ever said "hey, we've already got one database, things will get a whole > lot clearer if we invent another one instead"? One thing that you have to consider is the use of NIS, LDAP, and other sources of account and password information. The SE Linux use of identities is compiled into the policy database which is loaded into the kernel and in normal system operation does not change. Having the SE Linux policy change according to a dynamic lookup of NIS or LDAP is not going to work well and may decrease security (NB in the standard policy /bin/login is not even permitted to read /etc/shadow). Having the SE Linux policy generation process involve sucking down all data about accounts is not necessarily possible. LDAP servers may be (and usually are) configured to limit the number of items returned in a single query for performance reasons (I once made a machine with 8G of RAM thrash until it was unusable with a single LDAP query because of not having such limits). If the LDAP result limit is less than the number of users then having SE Linux policy generation use the complete list of users would not be possible. The use of user_u identity is a good solution to these issues and the only solution for regular users. For users with higher access levels it should not be difficult to list them specially in the policy source files. > There seems to be some difference between a domain and a type, although > given the lack of documentation, I'm not convinced of that. If they are > different, who's idea was it to use the same naming convention for > both? Why not user_t and user_d? Use _t to indicate a type and _d to > indicate a domain. Or do they have to be from the same namespace? Does > a type named user_t always exactly correspond to a domain named user_t? > If so, what's the difference between a domain and a type? As James says, there is no difference, this is why they both end in _t. I agree that it can be confusing at the start, but it's not going to get changed at this time. > Why do we need useradd and seuseradd? Shouldn't useradd give me the > option to create an identity? Or better yet, shouldn't useradd create an > identity by default and give me the option to create a generic user > instead? useradd definitely should not create identities by default. If it did then we would have identities "ntp", "apache", "named", "xfs", etc. We don't want that. seuseradd is a good solution to this problem. It calls useradd (so /etc/default/useradd will be used in the regular manner), and it then does SE Linux stuff afterwards. I think that it is OK to have scripts that add system users continue to run as before, and have useradd work for adding user_u users, but require seuseradd for adding SE users. > Sorry to sound so negative, but this stuff is not ready for prime-time The version is Fedora Core 2 TEST 2. It's not expected to be fully ready for prime-time yet, we are working as fast as we can. One thing you may consider is joining #fedora-selinux on irc.freenode.net. I am usually on there and ready to answer questions. We want to build up the SE Linux skills of the community to help in solving such problems. -- 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 russell at coker.com.au Fri Apr 2 07:12:46 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 2 Apr 2004 17:12:46 +1000 Subject: Not good In-Reply-To: <200404011728.15051.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> Message-ID: <200404021712.46431.russell@coker.com.au> On Fri, 2 Apr 2004 08:28, Gene Czarcinski wrote: > OK, I updated with todays round of updates ... at least with respect to > selinux. This includes the kernel, policy, policy-sources, and > policycoreutils. > > I then rebooted and ran "make reload" and "make relabel". They seemed to > complete OK. However, I cannot login from gdm as root (!), a regular user, > or a user with a sysadm role defined ... I get an indication that the home > directory could not be found (including for root). What AVC messages do you get? > BTW, what are the "right" circumstances for running "make relabel"? I have > sometimes gotten an error saying it could not handle "/dev/tty1". Should I > plan to do this from single-user-mode? The error regarding /dev/tty1 is intentional. You don't want the terminal you are using to run setfiles to be relabeled, that would get in the way of other tasks you might want to perform before logging out. -- 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 gene at czarc.net Fri Apr 2 09:28:21 2004 From: gene at czarc.net (Gene Czarcinski) Date: Fri, 2 Apr 2004 04:28:21 -0500 Subject: Not good In-Reply-To: <200404021712.46431.russell@coker.com.au> References: <200404011728.15051.gene@czarc.net> <200404021712.46431.russell@coker.com.au> Message-ID: <200404020428.21961.gene@czarc.net> On Friday 02 April 2004 02:12, Russell Coker wrote: > On Fri, 2 Apr 2004 08:28, Gene Czarcinski wrote: > > OK, I updated with todays round of updates ... at least with respect to > > selinux. This includes the kernel, policy, policy-sources, and > > policycoreutils. > > > > I then rebooted and ran "make reload" and "make relabel". They seemed to > > complete OK. However, I cannot login from gdm as root (!), a regular > > user, or a user with a sysadm role defined ... I get an indication that > > the home directory could not be found (including for root). > > What AVC messages do you get? >From /var/log/messages: Apr 2 04:18:03 hummer gdm(pam_unix)[12970]: session opened for user czarcing by (uid=0) Apr 2 04:18:03 hummer kernel: audit(1080897483.768:0): avc: denied { getattr } for pid=12970 exe=/usr/bin/gdm-binary path=/home/czarcing dev=hda10 ino=1209338 scontext=system_u:system_r:xdm_t tcontext=czarcing:object_r:staff_home_dir_t tclass=dir Apr 2 04:18:03 hummer gdm[12970]: gdm_slave_session_start: Home directory for czarcing: '/home/czarcing' does not exist! Apr 2 04:18:09 hummer gdm(pam_unix)[12970]: session closed for user czarcing > > > BTW, what are the "right" circumstances for running "make relabel"? I > > have sometimes gotten an error saying it could not handle "/dev/tty1". > > Should I plan to do this from single-user-mode? > > The error regarding /dev/tty1 is intentional. You don't want the terminal > you are using to run setfiles to be relabeled, that would get in the way of > other tasks you might want to perform before logging out. Then this needs to be done better ... it looks like everything stops when this occurs and that things did not complete. Rather than saying it is an error, it needs to say what happened and what to do. Additionally, I don't seem to get this "error" for /dev/tty1 everytime I run "make relabel" ... only sometimes. This does not make sense to me. Gene From lists at ebourne.me.uk Fri Apr 2 11:33:20 2004 From: lists at ebourne.me.uk (Martin Ebourne) Date: Fri, 2 Apr 2004 12:33:20 +0100 Subject: Naming convention flames In-Reply-To: <200404021444.52546.russell@coker.com.au> References: <1080860144.5403.28.camel@localhost.localdomain> <200404021444.52546.russell@coker.com.au> Message-ID: <20040402123320.65v3ugw0k0ckgok4@ebourne.me.uk> Russell Coker wrote: > seuseradd is a good solution to this problem. It calls useradd > (so /etc/default/useradd will be used in the regular manner), and it then > does SE Linux stuff afterwards. I think that it is OK to have scripts that > add system users continue to run as before, and have useradd work for adding > user_u users, but require seuseradd for adding SE users. Personally I feel an option to useradd would be a better solution in this case. It's only natural for people to look in the man page when a command doesn't do what's expected and an option will be much more obvious, and more logical, than a reference to separate command. Cheers, Martin. From kdebisschop at alert.infoplease.com Fri Apr 2 14:15:49 2004 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Fri, 2 Apr 2004 09:15:49 -0500 Subject: httpd cannot read httpd-manual Message-ID: <20040402091549.4029ea0d.kdebisschop@alert.infoplease.com> Here's the audit from /var/log/messages: Apr 2 04:09:33 xxxxx kernel: audit(1080896972.999:0): avc: denied { getattr } for pid=1156 exe=/usr/sbin/httpd path=/var/www/manual/index.html dev=md0 ino=1473314 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:var_t tclass=file System is FC2 devel in enforcing mode, the only change I have made to policies is to add myself as an adminstrative user. -- Karl DeBisschop (kdebisschop at infoplease.com) Pearson Education/Infoplease (http://www.infoplease.com) From pope_murphy at hotmail.com Fri Apr 2 12:40:31 2004 From: pope_murphy at hotmail.com (murphy pope) Date: Fri, 02 Apr 2004 07:40:31 -0500 Subject: Naming convention flames Message-ID: <1080909556.5403.47.camel@localhost.localdomain> >SELinux has an independent user identity model, which provides for more rigorous identity based access control than standard Unix. e.g. you can change Unix user id, but not SELinux user id. And that's a feature is it? >The reason there are separate databases is that there is not a direct >mapping between Unix users and SELinux users. That's not a justification, it's a consequence of the fact that you are maintaining a separate database. In other words, that's a bad thing, not a good thing. >Many users in /etc/passwd can be mapped to a single SELinux user for access control purposes (e.g. system_u). Sounds like /etc/group to me. >There also needs to be a way to map the user to a set of roles, so a separate database is needed anyway. Yes, a separate database is required here to extend the data stored in /etc/passwd. But it should be analogous to /etc/shadow (which also extends the data stored in /etc/passwd). The important difference is that the "primary key" in /etc/shadow refers to the "primary key" in /etc/passwd. Of course, without an RDBMS, referential integrity is not enforced, but violations are meaningless - an orphan record in /etc/shadow is simply ignored. SELinux keeps two separate databases with no relationship between primary keys. And by the way, Russell mentioned that we have to consider NIS, LDAP, and other storage mechanisms. Those storage mechanisms are storage mechanisms, not separate databases, meaning that if you maintain a user database in NIS and duplicate the information in an LDAP directory, you're simply storing the same data in two places. The arrangement that SELinux uses is like keeping two different customer files and assigning two different customer ID numbers to the same customer - that's trouble. -- Murphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From pope_murphy at hotmail.com Fri Apr 2 12:54:21 2004 From: pope_murphy at hotmail.com (murphy pope) Date: Fri, 02 Apr 2004 07:54:21 -0500 Subject: Naming convention flames Message-ID: <1080910460.5403.56.camel@localhost.localdomain> > As James says, there is no difference, this is why they both end in _t. I agree that it can be confusing at the start, but it's not going to get changed at this time. Ok, but section 2.2.5 from Faye's document starts with: > There is a very important distinction which needs to be made here, between a domain and a type, as it tends to cause a little confusion later on if you don't understand it from the start. There is no difference, but we need to make a very important distinction? You're writing for programmers - write for users! How would you explain SELinux to your mother? -- Murphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gene at czarc.net Fri Apr 2 14:59:47 2004 From: gene at czarc.net (Gene Czarcinski) Date: Fri, 2 Apr 2004 09:59:47 -0500 Subject: login problem update Message-ID: <200404020959.47492.gene@czarc.net> For those interesting in the "login problem" which occurs after installing policy 1.9.2-1, check out https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119597 Dan Walsh has provided a fix and (after some fumbling by me) I found it works. Gene From pope_murphy at hotmail.com Fri Apr 2 14:56:45 2004 From: pope_murphy at hotmail.com (murphy pope) Date: Fri, 02 Apr 2004 09:56:45 -0500 Subject: Another dumb question... Message-ID: <1080917804.5403.70.camel@localhost.localdomain> Everything that I've read says that the 'su' command will change my Linux user ID but not my identity. Here's what I see: # id -Z root:staff_r:staff_t # su fred Your default context is fred:sysadm_r:sysadm_t. Do you want to choose a different one? [n]n $ id -Z fred:sysadm_r:sysadm_t My identity changed from 'root' to 'fred'. Bug? That seems a pretty fundamental flaw considering that every document that I've read uses 'su' to explain the difference between a user ID and an identity. By the way, I see the same result whether I use 'su' or 'su -'. I see the same result (a change in identity) whether I su from root to fred or from fred to root. So which one is right? The documentation or the code? -- Murphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at epoch.ncsc.mil Fri Apr 2 15:05:36 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 02 Apr 2004 10:05:36 -0500 Subject: Naming convention flames In-Reply-To: <1080860144.5403.28.camel@localhost.localdomain> References: <1080860144.5403.28.camel@localhost.localdomain> Message-ID: <1080918336.27706.85.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-01 at 17:55, murphy pope wrote: > I've been struggling to understand some of this SELinux stuff so I can > explain it to other users. But I have my stupid-hat on these days. yum install selinux-doc cd /usr/share/SELinux ggv policy.pdf In particular, see section 3. Note to Dan: Might it be a good idea to have selinux-doc also include the HTML version of the reports? The Makefile already supports building HTML from the DocBook sources. Of course, I assume you've already looked at the Fedora SELinux FAQ and the externally developed sourceforge selinux HOWTOs/FAQs. > Why does SELinux use a separate user database? Why doesn't SELinux > read the /etc/passwd database instead of maintaining its own? Has > anybody ever said "hey, we've already got one database, things will > get a whole lot clearer if we invent another one instead"? Section 3.3 of policy.pdf. > There seems to be some difference between a domain and a type, > although given the lack of documentation, I'm not convinced of that. > If they are different, who's idea was it to use the same naming > convention for both? Why not user_t and user_d? Use _t to indicate a > type and _d to indicate a domain. Or do they have to be from the same > namespace? Does a type named user_t always exactly correspond to a > domain named user_t? If so, what's the difference between a domain > and a type? Section 3.1 of policy.pdf. Likely also covered by the externall developed HOWTOs/FAQs. -- Stephen Smalley National Security Agency From icon at linux.duke.edu Fri Apr 2 15:08:15 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 02 Apr 2004 10:08:15 -0500 Subject: Another dumb question... In-Reply-To: <1080917804.5403.70.camel@localhost.localdomain> References: <1080917804.5403.70.camel@localhost.localdomain> Message-ID: <406D81DF.5070301@linux.duke.edu> murphy pope wrote: > Everything that I've read says that the 'su' command will change my > Linux user ID but not my identity. Here's what I see: > > # id -Z > root:staff_r:staff_t > # su fred > Your default context is fred:sysadm_r:sysadm_t. > > Do you want to choose a different one? [n]n > $ id -Z > fred:sysadm_r:sysadm_t > > My identity changed from 'root' to 'fred'. Bug? That seems a pretty > fundamental flaw considering that every document that I've read uses > 'su' to explain the difference between a user ID and an identity. > > By the way, I see the same result whether I use 'su' or 'su -'. I see > the same result (a change in identity) whether I su from root to fred or > from fred to root. > > So which one is right? The documentation or the code? I can't confirm this: icon at hagrid:[~]$ id -Z user_u:user_r:user_t icon at hagrid:[~]$ su Password: root at hagrid:[/home/einstein/staff/icon]# id -Z root:sysadm_r:sysadm_t root at hagrid:[/home/einstein/staff/icon]# su - Your default context is root:sysadm_r:sysadm_t. Do you want to choose a different one? [n] [root at hagrid root]# id -Z root:sysadm_r:sysadm_t [root at hagrid root]# su icon icon at hagrid:[/root]$ id -Z user_u:user_r:user_t icon at hagrid:[/root]$ exit [root at hagrid root]# su - icon icon at hagrid:[~]$ id -Z user_u:user_r:user_t icon at hagrid:[~]$ -icon From rms at 1407.org Fri Apr 2 15:09:34 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 02 Apr 2004 16:09:34 +0100 Subject: Naming convention flames In-Reply-To: <1080909556.5403.47.camel@localhost.localdomain> References: <1080909556.5403.47.camel@localhost.localdomain> Message-ID: <1080918574.12320.4.camel@roque> On Fri, 2004-04-02 at 07:40 -0500, murphy pope wrote: > >Many users in /etc/passwd can be mapped to a single SELinux user for > access control purposes (e.g. system_u). > > Sounds like /etc/group to me. Ok, let's say you have users john, jane, doe, and poe then you have groups like: staff:x:n:john,jane,doe and file xpto: -rw-rw-r-- 1 john staff 3399 Mar 9 00:40 xpto How do you forbid doe from writing on xpto? That's an example of what SELinux brings you, in terms of permissions. You can explictly say xpto can't be written by doe. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 sds at epoch.ncsc.mil Fri Apr 2 15:13:00 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 02 Apr 2004 10:13:00 -0500 Subject: Another dumb question... In-Reply-To: <1080917804.5403.70.camel@localhost.localdomain> References: <1080917804.5403.70.camel@localhost.localdomain> Message-ID: <1080918780.27706.93.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-02 at 09:56, murphy pope wrote: > Everything that I've read says that the 'su' command will change my > Linux user ID but not my identity. Here's what I see: > > # id -Z > root:staff_r:staff_t > # su fred > Your default context is fred:sysadm_r:sysadm_t. > > Do you want to choose a different one? [n]n > $ id -Z > fred:sysadm_r:sysadm_t > > My identity changed from 'root' to 'fred'. Bug? That seems a pretty > fundamental flaw considering that every document that I've read uses > 'su' to explain the difference between a user ID and an identity. > > By the way, I see the same result whether I use 'su' or 'su -'. I see > the same result (a change in identity) whether I su from root to fred > or from fred to root. > > So which one is right? The documentation or the code? RedHat chose to integrate security context transitions into su (via pam_selinux). The NSA documentation and externally developed sourceforge selinux HOWTOs/FAQs were written prior to that change. -- Stephen Smalley National Security Agency From rpjday at mindspring.com Fri Apr 2 15:21:35 2004 From: rpjday at mindspring.com (Robert P. J. Day) Date: Fri, 2 Apr 2004 10:21:35 -0500 (EST) Subject: Naming convention flames In-Reply-To: <1080918574.12320.4.camel@roque> References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> Message-ID: On Fri, 2 Apr 2004, Rui Miguel Seabra wrote: > On Fri, 2004-04-02 at 07:40 -0500, murphy pope wrote: > > >Many users in /etc/passwd can be mapped to a single SELinux user for > > access control purposes (e.g. system_u). > > > > Sounds like /etc/group to me. > > Ok, let's say you have users john, jane, doe, and poe > > then you have groups like: > staff:x:n:john,jane,doe > > and file xpto: > > -rw-rw-r-- 1 john staff 3399 Mar 9 00:40 xpto > > How do you forbid doe from writing on xpto? > > That's an example of what SELinux brings you, in terms of permissions. > You can explictly say xpto can't be written by doe. on the other hand, why should you be *allowed* to prevent doe from writing on xpto? you've explicitly made doe part of the staff group, and you've explicitly given the staff group write permission on that file. seems like these regular perms are doing exactly what they're *supposed* to be doing, no? as an aside, i *do* realize what point you're trying to make. but i've seen too many contrived examples of folks complaining about the effect of regular permission files when the example they use is perfectly reasonable and doesn't represent a limitation in the first place. unless i've totally misread what you were getting at. rday From rms at 1407.org Fri Apr 2 15:36:33 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 02 Apr 2004 16:36:33 +0100 Subject: Naming convention flames In-Reply-To: References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> Message-ID: <1080920193.12320.25.camel@roque> On Fri, 2004-04-02 at 10:21 -0500, Robert P. J. Day wrote: > On Fri, 2 Apr 2004, Rui Miguel Seabra wrote: > > > On Fri, 2004-04-02 at 07:40 -0500, murphy pope wrote: > > > >Many users in /etc/passwd can be mapped to a single SELinux user for > > > access control purposes (e.g. system_u). > > > > > > Sounds like /etc/group to me. > > > > Ok, let's say you have users john, jane, doe, and poe > > > > then you have groups like: > > staff:x:n:john,jane,doe > > > > and file xpto: > > > > -rw-rw-r-- 1 john staff 3399 Mar 9 00:40 xpto > > > > How do you forbid doe from writing on xpto? > > > > That's an example of what SELinux brings you, in terms of permissions. > > You can explictly say xpto can't be written by doe. > > on the other hand, why should you be *allowed* to prevent doe from > writing on xpto? you've explicitly made doe part of the staff group, > and you've explicitly given the staff group write permission on that > file. seems like these regular perms are doing exactly what they're > *supposed* to be doing, no? No. doe might be a junior staff member, for instance. Other instance I didn't say: How do you make poe be able to write to the file without making him a member of group staff or making the file world writable? Rui > unless i've totally misread what you were getting at. You must've missed the point of ACLs. This is very important in terms of security, and if I had this when I installed some systems a couple of years ago, I wouldn't need toying around with intermediate users to avoid direct +w permissions from some users to certain files that can't be +w for some others. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 sds at epoch.ncsc.mil Fri Apr 2 15:37:43 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 02 Apr 2004 10:37:43 -0500 Subject: Naming convention flames In-Reply-To: <1080909556.5403.47.camel@localhost.localdomain> References: <1080909556.5403.47.camel@localhost.localdomain> Message-ID: <1080920263.27706.107.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-02 at 07:40, murphy pope wrote: > >SELinux has an independent user identity model, which provides for > more rigorous identity based access control than standard Unix. e.g. > you can change Unix user id, but not SELinux user id. > > And that's a feature is it? Yes. Bounded privilege escalation. > > >The reason there are separate databases is that there is not a direct > >mapping between Unix users and SELinux users. > > That's not a justification, it's a consequence of the fact that you > are maintaining a separate database. In other words, that's a bad > thing, not a good thing. No, it is a consequence of different security models. And, as James noted, you need to have a mapping of users to roles regardless of whether you have an entry in policy/users for every entry in /etc/passwd or not. -- Stephen Smalley National Security Agency From rpjday at mindspring.com Fri Apr 2 15:51:27 2004 From: rpjday at mindspring.com (Robert P. J. Day) Date: Fri, 2 Apr 2004 10:51:27 -0500 (EST) Subject: Naming convention flames In-Reply-To: <1080920193.12320.25.camel@roque> References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <1080920193.12320.25.camel@roque> Message-ID: On Fri, 2 Apr 2004, Rui Miguel Seabra wrote: > On Fri, 2004-04-02 at 10:21 -0500, Robert P. J. Day wrote: > > On Fri, 2 Apr 2004, Rui Miguel Seabra wrote: > > > > > On Fri, 2004-04-02 at 07:40 -0500, murphy pope wrote: > > > > >Many users in /etc/passwd can be mapped to a single SELinux user for > > > > access control purposes (e.g. system_u). > > > > > > > > Sounds like /etc/group to me. > > > > > > Ok, let's say you have users john, jane, doe, and poe > > > > > > then you have groups like: > > > staff:x:n:john,jane,doe > > > > > > and file xpto: > > > > > > -rw-rw-r-- 1 john staff 3399 Mar 9 00:40 xpto > > > > > > How do you forbid doe from writing on xpto? > > > > > > That's an example of what SELinux brings you, in terms of permissions. > > > You can explictly say xpto can't be written by doe. > > > > on the other hand, why should you be *allowed* to prevent doe from > > writing on xpto? you've explicitly made doe part of the staff group, > > and you've explicitly given the staff group write permission on that > > file. seems like these regular perms are doing exactly what they're > > *supposed* to be doing, no? > > No. doe might be a junior staff member, for instance. then why would you make "doe" a member of "staff" in the first place? again, i *know* what you're getting at. what i'm arguing is that many of the examples i see promoting the use of extended permissions, including ACLs, are little more than a misuse of standard permissions. in the above, you create a group called "staff", assign user "doe" to such a group, then complain that user doe has, well, "staff" rights. what exactly were you expecting? > Other instance I didn't say: > > How do you make poe be able to write to the file without making him a > member of group staff or making the file world writable? ok, that's a better question, and represents a much better example. > Rui > > > unless i've totally misread what you were getting at. > > You must've missed the point of ACLs. au contraire, i understand ACLs pretty well. all i'm harping on is the sometimes lame examples people use to justify their existence. there's enough *good* justification for ACLs that one shouldn't need to dredge up *bad* justification. :-) rday From ron.arts at netland.nl Fri Apr 2 15:55:00 2004 From: ron.arts at netland.nl (Ron Arts) Date: Fri, 02 Apr 2004 17:55:00 +0200 Subject: yum update after fresh install of Core2 test2 In-Reply-To: References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> Message-ID: <406D8CD4.6020605@netland.nl> I just did a fresh install of Core 2 test2, and after that I logged in as root (by ssh) and issued `yum update`. During the update lots of errors happened like this one: setexeccon(root:staff_r:rpm_script_t) fails from context "root:staff_r:staff_t": Invalid argument %post(xorg-x11-Mesa-libGL-0.6.6-0.2004_03_30.1) scriptlet failed, exit status 255 And now even yum itself fails with: ImportError: /usr/lib/python2.3/site-packages/rpmmodule.so: undefined symbol: rpmdsBT Could not find this exact error in the archives, but I bet I did something stupid, but what? Thanks, Ron -- Netland Internet Services bedrijfsmatige internetoplossingen http://www.netland.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628282 servicedesk: 020-5628280 fax: 020-5628281 The best way to accelerate a Mac is at 9.8 m / sec^2. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3465 bytes Desc: S/MIME Cryptographic Signature URL: From pauln at truemesh.com Fri Apr 2 15:52:09 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 2 Apr 2004 15:52:09 +0000 Subject: yum update after fresh install of Core2 test2 In-Reply-To: <406D8CD4.6020605@netland.nl> References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <406D8CD4.6020605@netland.nl> Message-ID: <20040402155208.GD23468@lichen.truemesh.com> On Fri, Apr 02, 2004 at 05:55:00PM +0200, Ron Arts wrote: > I just did a fresh install of Core 2 test2, > and after that I logged in as root (by ssh) Logging in via ssh as root you will be staff_r, you need to run: newrole -r sysadm_r -t sysadm_t > and issued `yum update`. > During the update lots of errors happened like this one: > > setexeccon(root:staff_r:rpm_script_t) fails from context > "root:staff_r:staff_t": Invalid argument > %post(xorg-x11-Mesa-libGL-0.6.6-0.2004_03_30.1) scriptlet failed, exit > status 255 > > And now even yum itself fails with: > > ImportError: /usr/lib/python2.3/site-packages/rpmmodule.so: undefined > symbol: rpmdsBT > Could not find this exact error in the archives, but I bet It has been mentioned - your transaction broke and you probably have mismatching rpm and rpm-python. rpm -q rpm; rpm -q rpm-python Download rpm and rpm-python from your favourite mirror and rpm -Uvh them as sysadm_r id -Z will tell you what context you are in. Paul From carstengrohmann at gmx.de Fri Apr 2 16:05:02 2004 From: carstengrohmann at gmx.de (Carsten Grohmann) Date: Fri, 2 Apr 2004 18:05:02 +0200 Subject: httpd cannot read httpd-manual In-Reply-To: <20040402091549.4029ea0d.kdebisschop@alert.infoplease.com> References: <20040402091549.4029ea0d.kdebisschop@alert.infoplease.com> Message-ID: <200404021805.02609.carstengrohmann@gmx.de> On Freitag, 2. April 2004 16:15, Karl DeBisschop wrote: > Apr 2 04:09:33 xxxxx kernel: audit(1080896972.999:0): avc: > denied { getattr } for pid=1156 exe=/usr/sbin/httpd > path=/var/www/manual/index.html dev=md0 ino=1473314 > scontext=system_u:system_r:httpd_t > tcontext=system_u:object_r:var_t tclass=file Maybe you should relabel the webserver files with httpd_sys_context_t or look into /file_contexts/program/apache.fc change apaches path settings. From rms at 1407.org Fri Apr 2 16:06:42 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 02 Apr 2004 17:06:42 +0100 Subject: Naming convention flames In-Reply-To: References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <1080920193.12320.25.camel@roque> Message-ID: <1080922002.12320.42.camel@roque> On Fri, 2004-04-02 at 10:51 -0500, Robert P. J. Day wrote: > then why would you make "doe" a member of "staff" in the first place? > again, i *know* what you're getting at. what i'm arguing is that many of > the examples i see promoting the use of extended permissions, including > ACLs, are little more than a misuse of standard permissions. My specific case: 1 application server is run with user AS 2 application's files are own by user A 3 AS must be able to read application files (but not write) 4 application's files should not have any 'o' permissions. 5 production users must be able to change application files > > > unless i've totally misread what you were getting at. > > You must've missed the point of ACLs. > > au contraire, i understand ACLs pretty well. all i'm harping on is the > sometimes lame examples people use to justify their existence. there's > enough *good* justification for ACLs that one shouldn't need to dredge > up *bad* justification. :-) Ok, sorry for misunderstanding you! :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 ksnider at flarn.com Fri Apr 2 16:20:24 2004 From: ksnider at flarn.com (Ken Snider) Date: Fri, 02 Apr 2004 11:20:24 -0500 Subject: Naming convention flames In-Reply-To: References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <1080920193.12320.25.camel@roque> Message-ID: <406D92C8.5020704@flarn.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert P. J. Day wrote: | then why would you make "doe" a member of "staff" in the first place? Envision a "staff" only directory with ten files within. Nine of the ten should be writable by all members of staff, save one, which should be writable to everyone but user x. Should I make a new subgroup for "staff" now that includes everyone but x? Does that paradigm carry forward if another file needs to be writable by x but NOT by y (and creating yet another group)? Further, anytime you want a file to be written to by two different groups of people, you have to create a union group of the two and have the file written to by said new gid. I don't think the above is sustainable. expand that scenario out to N and you have good reasons for ACL's. - -- Ken Snider -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbZLHJz/2kL0fCRgRApxGAJ9DKLVUJf8iWVbxk7E6RPdgNSUCCwCfQ+Qb tswmkjxYcivBhp+MMPHFSds= =Nnjy -----END PGP SIGNATURE----- From kdebisschop at alert.infoplease.com Fri Apr 2 17:54:48 2004 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Fri, 2 Apr 2004 12:54:48 -0500 Subject: httpd cannot read httpd-manual In-Reply-To: <200404021805.02609.carstengrohmann@gmx.de> References: <20040402091549.4029ea0d.kdebisschop@alert.infoplease.com> <200404021805.02609.carstengrohmann@gmx.de> Message-ID: <20040402125448.64b9e8f4.kdebisschop@alert.infoplease.com> On Fri, 2 Apr 2004 18:05:02 +0200 Carsten Grohmann wrote: > On Freitag, 2. April 2004 16:15, Karl DeBisschop wrote: > > > Apr 2 04:09:33 xxxxx kernel: audit(1080896972.999:0): avc: > > denied { getattr } for pid=1156 exe=/usr/sbin/httpd > > path=/var/www/manual/index.html dev=md0 ino=1473314 > > scontext=system_u:system_r:httpd_t > > tcontext=system_u:object_r:var_t tclass=file > > Maybe you should relabel the webserver files with > httpd_sys_context_t or look into policy>/file_contexts/program/apache.fc change apaches path > settings. I'm trying to leave the system as unchanged as possible from the default distribution so I can find and report errors as they occur. Yes, I could make those changes on my local system, but it does not do much to further development for FC2. -- Karl DeBisschop (kdebisschop at infoplease.com) Pearson Education/Infoplease (http://www.infoplease.com) From kdebisschop at alert.infoplease.com Fri Apr 2 18:12:28 2004 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Fri, 2 Apr 2004 13:12:28 -0500 Subject: httpd cannot read httpd-manual In-Reply-To: <200404021805.02609.carstengrohmann@gmx.de> References: <20040402091549.4029ea0d.kdebisschop@alert.infoplease.com> <200404021805.02609.carstengrohmann@gmx.de> Message-ID: <20040402131228.1eec0c55.kdebisschop@alert.infoplease.com> On Fri, 2 Apr 2004 18:05:02 +0200 Carsten Grohmann wrote: > On Freitag, 2. April 2004 16:15, Karl DeBisschop wrote: > > > Apr 2 04:09:33 xxxxx kernel: audit(1080896972.999:0): avc: > > denied { getattr } for pid=1156 exe=/usr/sbin/httpd > > path=/var/www/manual/index.html dev=md0 ino=1473314 > > scontext=system_u:system_r:httpd_t > > tcontext=system_u:object_r:var_t tclass=file > > Maybe you should relabel the webserver files with > httpd_sys_context_t or look into policy>/file_contexts/program/apache.fc change apaches path > settings. FWIW, it works if you add adding these lines to /etc/security/selinux/src/policy/file_contexts/program/apache.fc: /var/www/manual(/.*)? system_u:object_r:httpd_sys_content_t /var/www/error(/.*)? system_u:object_r:httpd_sys_content_t then: make -C /etc/security/selinux/src/policy /sbin/fixfiles relabel Presumably something like that sort of change can make it into the vext update of policy. -- Karl DeBisschop (kdebisschop at infoplease.com) Pearson Education/Infoplease (http://www.infoplease.com) From dax at gurulabs.com Fri Apr 2 18:52:14 2004 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 02 Apr 2004 11:52:14 -0700 Subject: Naming convention flames In-Reply-To: <1080920193.12320.25.camel@roque> References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <1080920193.12320.25.camel@roque> Message-ID: <1080931934.2766.8.camel@mentor.gurulabs.com> On Fri, 2004-04-02 at 08:36, Rui Miguel Seabra wrote: > How do you make poe be able to write to the file without making him a > member of group staff or making the file world writable? > > Rui That's easy with a 2.6 kernel or a 2.4 kernel with the posix facl patch (RHEL3, SUSE ENTERPRISE). setfacl -m u:poe:w file Dax Kelson Guru Labs From jkeating at j2solutions.net Fri Apr 2 18:49:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Apr 2004 10:49:04 -0800 Subject: Naming convention flames In-Reply-To: <1080931934.2766.8.camel@mentor.gurulabs.com> References: <1080909556.5403.47.camel@localhost.localdomain> <1080920193.12320.25.camel@roque> <1080931934.2766.8.camel@mentor.gurulabs.com> Message-ID: <200404021049.08394.jkeating@j2solutions.net> On Friday 02 April 2004 10:52, Dax Kelson wrote: > That's easy with a 2.6 kernel or a 2.4 kernel with the posix facl > patch (RHEL3, SUSE ENTERPRISE). > > setfacl -m u:poe:w file Great, now you've set the ACL. Now how do you prevent an application ran as user B from editing every file that user B has ownership on? (: SELinux is more than just file permissions. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Fri Apr 2 18:54:39 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Apr 2004 10:54:39 -0800 Subject: Naming convention flames In-Reply-To: <200404021049.08394.jkeating@j2solutions.net> References: <1080909556.5403.47.camel@localhost.localdomain> <1080931934.2766.8.camel@mentor.gurulabs.com> <200404021049.08394.jkeating@j2solutions.net> Message-ID: <200404021054.39545.jkeating@j2solutions.net> On Friday 02 April 2004 10:49, Jesse Keating wrote: > Great, now you've set the ACL. Now how do you prevent an application > ran as user B from editing every file that user B has ownership on? > (: > > SELinux is more than just file permissions. NOte, this isn't directed at Dax, more at the general list. I'm quite confident that Dax knows that SELinux is more than just file permissions (: -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dax at gurulabs.com Fri Apr 2 19:06:17 2004 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 02 Apr 2004 12:06:17 -0700 Subject: Naming convention flames In-Reply-To: <406D92C8.5020704@flarn.com> References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <1080920193.12320.25.camel@roque> <406D92C8.5020704@flarn.com> Message-ID: <1080932777.2766.21.camel@mentor.gurulabs.com> On Fri, 2004-04-02 at 09:20, Ken Snider wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Robert P. J. Day wrote: > > | then why would you make "doe" a member of "staff" in the first place? > > Envision a "staff" only directory with ten files within. Nine of the ten > should be writable by all members of staff, save one, which should be writable > to everyone but user x. > > Should I make a new subgroup for "staff" now that includes everyone but x? > Does that paradigm carry forward if another file needs to be writable by x but > NOT by y (and creating yet another group)? > > Further, anytime you want a file to be written to by two different groups of > people, you have to create a union group of the two and have the file written > to by said new gid. What you just described is the "UNIX way" (tm) of doing things that has worked for 30 plus years. Ugly yes. Workable yes. A clean solution was devised many years ago called "POSIX file ACLs". Read the man page for setfacl and getfacl. Solaris adopted the feature in 1997, Linux (officially) with the 2.6 kernel. Obviously the features that POSIX file ACLs provides is a subset of what SELinux provides. I'm a fan of SELinux with it's way enforce the "correct behavior" of applications, but if you are just narrowly looking at the a solution for granular file permissions, then POSIX file ACLs are all you need. I suppose in a SELinux environment, POSIX file ACLs are redundant and uneeded (except for the "default permissions" (ala a custom umask) for a directory feature). Speaking of which, how does SELinux file permissions interact with a directory that has a default ACL applied? Dax Kelson Guru Labs From ron.arts at netland.nl Fri Apr 2 19:20:17 2004 From: ron.arts at netland.nl (Ron Arts) Date: Fri, 02 Apr 2004 21:20:17 +0200 Subject: adding selinux support to my own packages In-Reply-To: <406D8CD4.6020605@netland.nl> References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <406D8CD4.6020605@netland.nl> Message-ID: <406DBCF1.8070106@netland.nl> Hi, I want to add selinux support to one of our own network daemons. Are there new commands for specfiles? Which packages in the current tree are already properly selinux enabled and can I use as an example? Ron Arts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3465 bytes Desc: S/MIME Cryptographic Signature URL: From sds at epoch.ncsc.mil Fri Apr 2 19:24:31 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 02 Apr 2004 14:24:31 -0500 Subject: Naming convention flames In-Reply-To: <1080932777.2766.21.camel@mentor.gurulabs.com> References: <1080909556.5403.47.camel@localhost.localdomain> <1080918574.12320.4.camel@roque> <1080920193.12320.25.camel@roque> <406D92C8.5020704@flarn.com> <1080932777.2766.21.camel@mentor.gurulabs.com> Message-ID: <1080933870.28777.21.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-02 at 14:06, Dax Kelson wrote: > Obviously the features that POSIX file ACLs provides is a subset of what > SELinux provides. No. POSIX ACLs are a form of DAC, just slightly finer-grained. SELinux provides MAC. They are orthogonal. > I'm a fan of SELinux with it's way enforce the "correct behavior" of > applications, but if you are just narrowly looking at the a solution for > granular file permissions, then POSIX file ACLs are all you need. Not if you want to counter the classic limitations of DAC. > I suppose in a SELinux environment, POSIX file ACLs are redundant and > uneeded (except for the "default permissions" (ala a custom umask) for a > directory feature). > Speaking of which, how does SELinux file permissions interact with a > directory that has a default ACL applied? No, ACLS can still be useful for fine grained DAC. Both the DAC (ACLs or otherwise) and MAC must approve each operation. Why is DAC inadequate? - Decisions are only based on user identity and ownership. - There is no protection against flawed or malicious software. - Each user has complete discretion over his own objects. - There are typically only two major categories of users: administrators or others. - Many system services and privileged programs must run with coarse-grained privileges or even full administrator access. -- Stephen Smalley National Security Agency From jmorris at redhat.com Fri Apr 2 19:37:50 2004 From: jmorris at redhat.com (James Morris) Date: Fri, 2 Apr 2004 14:37:50 -0500 (EST) Subject: Naming convention flames In-Reply-To: <1080932777.2766.21.camel@mentor.gurulabs.com> Message-ID: On Fri, 2 Apr 2004, Dax Kelson wrote: > I'm a fan of SELinux with it's way enforce the "correct behavior" of > applications, but if you are just narrowly looking at the a solution for > granular file permissions, then POSIX file ACLs are all you need. Perhaps in a very limited way. You have no central policy for determining how the ACLs are applied, nor any mechanism for enforcing security policy. Management of security can become unwieldy from a user point of view as the access rights are stored with the objects, e.g. "which files can bilbo execute?" or "ensure that frodo can't read any files created by pippin" would involve expensive, non-atomic traversals of entire filesystems. > Speaking of which, how does SELinux file permissions interact with a > directory that has a default ACL applied? SELinux only provides additional restrictions to existing DAC logic, so if the ACL says "ok", SELinux can still override it. If the ACL says "no", access will be denied before SELinux is invoked. - James -- James Morris From dax at gurulabs.com Fri Apr 2 20:14:54 2004 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 02 Apr 2004 13:14:54 -0700 Subject: Naming convention flames In-Reply-To: References: Message-ID: <1080936894.2766.40.camel@mentor.gurulabs.com> On Fri, 2004-04-02 at 12:37, James Morris wrote: > On Fri, 2 Apr 2004, Dax Kelson wrote: > > > Speaking of which, how does SELinux file permissions interact with a > > directory that has a default ACL applied? > > SELinux only provides additional restrictions to existing DAC logic, so if > the ACL says "ok", SELinux can still override it. If the ACL says "no", > access will be denied before SELinux is invoked. Let me explain in more detail. I can set a default ACL on a directory so that any new files/directories created within that directory are writable by users joe, mike and sally and the groups hr and sales in addition to the standard uid and gid of the file (with permissions determined by the umask). It's more flexible than that even. The additional users and groups can each have unique permissions (rwx, r-x, rw-, etc). That's pretty darn cool and makes it so that the user-private-group scheme is no longer needed. So how do the SELinux file contexts interact? I guess I should go grok all this so I can answer my own questions. :) I have a couple projects to get done, then SELinux is next on the list. Dax Kelson Guru Labs From sds at epoch.ncsc.mil Fri Apr 2 20:44:19 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 02 Apr 2004 15:44:19 -0500 Subject: Naming convention flames In-Reply-To: <1080936894.2766.40.camel@mentor.gurulabs.com> References: <1080936894.2766.40.camel@mentor.gurulabs.com> Message-ID: <1080938659.28777.35.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-02 at 15:14, Dax Kelson wrote: > So how do the SELinux file contexts interact? The policy specifies rules for labeling new files based on: - the context of the creating process, - the context of the parent directory, - the kind of file (e.g. regular, directory, symlink, device,...). By default (in the absence of any matching rule in the policy), there is a standard manner in which the context is computed from the creating process context and parent directory context. The allowed accesses between a given process context and a given file context are explicitly defined via an access matrix, specified via the policy. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Sat Apr 3 05:46:03 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 03 Apr 2004 00:46:03 -0500 Subject: Not good In-Reply-To: <200404011728.15051.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> Message-ID: <406E4F9B.8080407@redhat.com> Gene Czarcinski wrote: >OK, I updated with todays round of updates ... at least with respect to >selinux. This includes the kernel, policy, policy-sources, and >policycoreutils. > >I then rebooted and ran "make reload" and "make relabel". They seemed to >complete OK. However, I cannot login from gdm as root (!), a regular user, >or a user with a sysadm role defined ... I get an indication that the home >directory could not be found (including for root). > >BTW, what are the "right" circumstances for running "make relabel"? I have >sometimes gotten an error saying it could not handle "/dev/tty1". Should I >plan to do this from single-user-mode? > > > First off you should never have to do a relabel, Or only under extreme circumstances. The problem here was the movement of the .Xauthority file out to /tmp. The new policy should fix your problem. Dan >Gene > >-- >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 Apr 3 06:14:00 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 03 Apr 2004 01:14:00 -0500 Subject: Naming convention flames In-Reply-To: <1080918336.27706.85.camel@moss-spartans.epoch.ncsc.mil> References: <1080860144.5403.28.camel@localhost.localdomain> <1080918336.27706.85.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <406E5628.8080502@redhat.com> Stephen Smalley wrote: >On Thu, 2004-04-01 at 17:55, murphy pope wrote: > > >>I've been struggling to understand some of this SELinux stuff so I can >>explain it to other users. But I have my stupid-hat on these days. >> >> > >yum install selinux-doc >cd /usr/share/SELinux >ggv policy.pdf > >In particular, see section 3. >Note to Dan: Might it be a good idea to have selinux-doc also include >the HTML version of the reports? The Makefile already supports building >HTML from the DocBook sources. > >Of course, I assume you've already looked at the Fedora SELinux FAQ and >the externally developed sourceforge selinux HOWTOs/FAQs. > > > >the HTML version of the reports? The Makefile already supports building >HTML from the DocBook sources. > > > HTML and PS files have been added. From dwalsh at redhat.com Sat Apr 3 06:45:06 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 03 Apr 2004 01:45:06 -0500 Subject: httpd cannot read httpd-manual In-Reply-To: <20040402091549.4029ea0d.kdebisschop@alert.infoplease.com> References: <20040402091549.4029ea0d.kdebisschop@alert.infoplease.com> Message-ID: <406E5D72.5090402@redhat.com> Karl DeBisschop wrote: >Here's the audit from /var/log/messages: > > > >Apr 2 04:09:33 xxxxx kernel: audit(1080896972.999:0): avc: denied { >getattr } for pid=1156 exe=/usr/sbin/httpd >path=/var/www/manual/index.html dev=md0 ino=1473314 >scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:var_t >tclass=file > > >System is FC2 devel in enforcing mode, the only change I have made to >policies is to add myself as an adminstrative user. > > File context problem. I have modified the context in policy-1.9.2-9 to label everything under /var/www as content unless it is specified later This is the patch, you will need to relabel after updating the policy files setfiles /etc/security/selinux/file_contexts /var/www --- apache.fc.20040403 2004-03-31 15:52:27.000000000 -0500 +++ apache.fc 2004-04-03 01:37:24.360416240 -0500 @@ -1,12 +1,9 @@ # apache HOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t -/var/www -d system_u:object_r:httpd_sys_content_t -/var/www/html(/.*)? system_u:object_r:httpd_sys_content_t -/var/www/mrtg(/.*)? system_u:object_r:httpd_sys_content_t +/var/www(/.*)? system_u:object_r:httpd_sys_content_t /var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t /usr/lib(64)?/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t /var/www/perl(/.*)? system_u:object_r:httpd_sys_script_exec_t -/var/www/icons(/.*)? system_u:object_r:httpd_sys_content_t /var/cache/httpd(/.*)? system_u:object_r:httpd_cache_t /etc/httpd -d system_u:object_r:httpd_config_t /etc/httpd/conf.* system_u:object_r:httpd_config_t From gene at czarc.net Sat Apr 3 09:49:52 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 04:49:52 -0500 Subject: Not good In-Reply-To: <406E4F9B.8080407@redhat.com> References: <200404011728.15051.gene@czarc.net> <406E4F9B.8080407@redhat.com> Message-ID: <200404030449.52614.gene@czarc.net> On Saturday 03 April 2004 00:46, Daniel J Walsh wrote: > First off you should never have to do a relabel, Or only under extreme > circumstances. > The problem here was the movement of the .Xauthority file out to /tmp. > The new policy should fix your problem. When we get to the end point (FC2 gold) this system is going to be very stable and secure. However, the transition with its large number of daily updates sure make things "interesting" ... I have managed to screw things up on one system so that I am on my third install. Unfortunately, discovering all of the different nuances necessary in a security policy supporting real people, real systems, and real situations is a lot more difficult than having a policy in a controlled experiment. Well, we are all here trying to pound this into something that works and I believe it will work pretty well when FC2 gold comes out but a wole lot better in FC2 gold. This is going to take time. One big gripe I do have is up2date: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119538 When rpm fails to (properly) install a package because of some selinux policy thing, this is not handled well by up2date. In fact, up2date reports that the package was installed properly when it was not installed. My latest experience with that is when I tried updating gdm ... old package removed but new package not installed. I only found this because I am manually querying rpm after every update. When I tried to manually install the package, I saw the errors. I then did "setenforce 0", manually installed the old package, manually installed the new package, and "setenforce 1". Update now complete. This rpm/up2date problem needs to be addressed. Unfortuantely, it is not clear that my bugzilla report is being addressed. Gene From axel at gapfilms.de Sat Apr 3 10:00:28 2004 From: axel at gapfilms.de (Axel Jerabek) Date: Sat, 3 Apr 2004 12:00:28 +0200 Subject: Is there a way to uninstall the SElinux? Message-ID: I installed the fedora core 2 and i am not really happy with the SElinux behaviour. since i ported our video software to the 2.6 kernel i used the fedora core 2 release. but unhappily i installed it with the SElinux option. Is there a way to get rid of the SElinux without having to reinstall the buddy again? thnx for help, axel. From linux at mellow.net Sat Apr 3 10:15:06 2004 From: linux at mellow.net (David Kvarnberg) Date: Sat, 03 Apr 2004 12:15:06 +0200 Subject: Is there a way to uninstall the SElinux? In-Reply-To: References: Message-ID: <1080987305.3561.3.camel@klavid> On Sat, 2004-04-03 at 12:00 +0200, Axel Jerabek wrote: > I installed the fedora core 2 and i am not really happy with the SElinux > behaviour. > since i ported our video software to the 2.6 kernel i used the fedora core 2 > release. > but unhappily i installed it with the SElinux option. Is there a way to get > rid of the SElinux > without having to reinstall the buddy again? > You can turn off SELinux by adding a kernel param to /etc/grub.conf Like this: kernel /vmlinuz-2.6.4-1.300 root=/dev/hda2 ro selinux=0 ^^^^^^^^^ After rebooting, SELinux will be turned off. Regards, David From felipe_alfaro at linuxmail.org Sat Apr 3 11:25:17 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 03 Apr 2004 13:25:17 +0200 Subject: Is there a way to uninstall the SElinux? In-Reply-To: <1080987305.3561.3.camel@klavid> References: <1080987305.3561.3.camel@klavid> Message-ID: <1080991516.2720.1.camel@teapot.felipe-alfaro.com> On Sat, 2004-04-03 at 12:15, David Kvarnberg wrote: > On Sat, 2004-04-03 at 12:00 +0200, Axel Jerabek wrote: > > > I installed the fedora core 2 and i am not really happy with the SElinux > > behaviour. > > since i ported our video software to the 2.6 kernel i used the fedora core 2 > > release. > > but unhappily i installed it with the SElinux option. Is there a way to get > > rid of the SElinux > > without having to reinstall the buddy again? > > > > You can turn off SELinux by adding a kernel param to /etc/grub.conf > Like this: > > kernel /vmlinuz-2.6.4-1.300 root=/dev/hda2 ro selinux=0 > ^^^^^^^^^ > > After rebooting, SELinux will be turned off. This won't for me. Instead, after booting, kernel panics trying to kill init as no policy has it seems SELinux is still enable but no policy been loaded into the kernel. Instead, I changed SELINUX=enforcing to SELINUX=0 in /etc/sysconfig/selinux. From red_alert at the-psychiatry.ch Sat Apr 3 11:34:40 2004 From: red_alert at the-psychiatry.ch (red_alert) Date: Sat, 03 Apr 2004 13:34:40 +0200 Subject: Is there a way to uninstall the SElinux? In-Reply-To: <1080991516.2720.1.camel@teapot.felipe-alfaro.com> References: <1080987305.3561.3.camel@klavid> <1080991516.2720.1.camel@teapot.felipe-alfaro.com> Message-ID: <406EA150.8020607@the-psychiatry.ch> yea, that seems to be still a problem/bug. if you have set SELINUX=enforcing in /etc/sysconfig/selinux, the kernel-param selinux=0 won't work (won't even boot...as you said). but you may rm /etc/sysconfig/selinux, then selinux=0 should work pretty fine. regards red_alert Felipe Alfaro Solana schrieb: > On Sat, 2004-04-03 at 12:15, David Kvarnberg wrote: > >>On Sat, 2004-04-03 at 12:00 +0200, Axel Jerabek wrote: >> >> >>>I installed the fedora core 2 and i am not really happy with the SElinux >>>behaviour. >>>since i ported our video software to the 2.6 kernel i used the fedora core 2 >>>release. >>>but unhappily i installed it with the SElinux option. Is there a way to get >>>rid of the SElinux >>>without having to reinstall the buddy again? >>> >> >>You can turn off SELinux by adding a kernel param to /etc/grub.conf >>Like this: >> >>kernel /vmlinuz-2.6.4-1.300 root=/dev/hda2 ro selinux=0 >> ^^^^^^^^^ >> >>After rebooting, SELinux will be turned off. > > > This won't for me. Instead, after booting, kernel panics trying to kill > init as no policy has it seems SELinux is still enable but no policy > been loaded into the kernel. > > Instead, I changed SELINUX=enforcing to SELINUX=0 in > /etc/sysconfig/selinux. > > -- > 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 Apr 3 13:29:58 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 03 Apr 2004 08:29:58 -0500 Subject: Not good In-Reply-To: <200404030449.52614.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <406E4F9B.8080407@redhat.com> <200404030449.52614.gene@czarc.net> Message-ID: <406EBC56.3030304@redhat.com> Gene Czarcinski wrote: >On Saturday 03 April 2004 00:46, Daniel J Walsh wrote: > > >>First off you should never have to do a relabel, Or only under extreme >>circumstances. >>The problem here was the movement of the .Xauthority file out to /tmp. >>The new policy should fix your problem. >> >> > >When we get to the end point (FC2 gold) this system is going to be very stable >and secure. However, the transition with its large number of daily updates >sure make things "interesting" ... I have managed to screw things up on one >system so that I am on my third install. > >Unfortunately, discovering all of the different nuances necessary in a >security policy supporting real people, real systems, and real situations is >a lot more difficult than having a policy in a controlled experiment. Well, >we are all here trying to pound this into something that works and I believe >it will work pretty well when FC2 gold comes out but a wole lot better in FC2 >gold. This is going to take time. > >One big gripe I do have is up2date: >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119538 > >When rpm fails to (properly) install a package because of some selinux policy >thing, this is not handled well by up2date. In fact, up2date reports that >the package was installed properly when it was not installed. My latest >experience with that is when I tried updating gdm ... old package removed but >new package not installed. I only found this because I am manually querying >rpm after every update. When I tried to manually install the package, I saw >the errors. I then did "setenforce 0", manually installed the old package, >manually installed the new package, and "setenforce 1". Update now complete. > >This rpm/up2date problem needs to be addressed. Unfortuantely, it is not >clear that my bugzilla report is being addressed. > > I have written the steps in the bug report on how to get up2date fixed. The final fix for the up2date package has not been released yet. Fixing up2date is a multi step process. One update to latest policy. restorecon /usr/sbin/up2date update to latest usermode Add ROLE=sysadm_r TYPE=rpm_t to /etc/security/console.apps/up2date. >Gene > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From gene at czarc.net Sat Apr 3 14:43:04 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 09:43:04 -0500 Subject: Not good In-Reply-To: <406EBC56.3030304@redhat.com> References: <200404011728.15051.gene@czarc.net> <200404030449.52614.gene@czarc.net> <406EBC56.3030304@redhat.com> Message-ID: <200404030943.04666.gene@czarc.net> On Saturday 03 April 2004 08:29, Daniel J Walsh wrote: > I have written the steps in the bug report on how to get up2date fixed. > The final fix for the up2date package has not been released yet. > > Fixing up2date is a multi step process. > > One update to latest policy. > restorecon /usr/sbin/up2date > > update to latest usermode > > Add > ROLE=sysadm_r > TYPE=rpm_t > to > > /etc/security/console.apps/up2date. Thanks for the update Dan. I am still a bit concerned that up2date did not report that the package up2date failed and that it removed the old version of the package as well. If I had been manually updating (as I did with the kernel), I saw that there was a problem. Up2date should have caught that also but did not. I do not know if yum has this problem or not and will probably explore using it as an alternative to up2date. However, I will probably wait for Seth's big rewrite that he is working on. Gene From n3npq at nc.rr.com Sat Apr 3 15:04:15 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 03 Apr 2004 10:04:15 -0500 Subject: Not good In-Reply-To: <200404030943.04666.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <200404030449.52614.gene@czarc.net> <406EBC56.3030304@redhat.com> <200404030943.04666.gene@czarc.net> Message-ID: <406ED26F.3070501@nc.rr.com> Gene Czarcinski wrote: >On Saturday 03 April 2004 08:29, Daniel J Walsh wrote: > > >>I have written the steps in the bug report on how to get up2date fixed. >>The final fix for the up2date package has not been released yet. >> >>Fixing up2date is a multi step process. >> >>One update to latest policy. >>restorecon /usr/sbin/up2date >> >>update to latest usermode >> >>Add >>ROLE=sysadm_r >>TYPE=rpm_t >>to >> >>/etc/security/console.apps/up2date. >> >> > >Thanks for the update Dan. > >I am still a bit concerned that up2date did not report that the package >up2date failed and that it removed the old version of the package as well. >If I had been manually updating (as I did with the kernel), I saw that there >was a problem. Up2date should have caught that also but did not. I do not >know if yum has this problem or not and will probably explore using it as an >alternative to up2date. However, I will probably wait for Seth's big rewrite >that he is working on. > > All rpm tools have this problem, as one of the two big lies in rpm is All-or-nothing behavior when installing packages. That lie is true iff packages are perfect. That is very much not the case during a development cycle with an importatnt paradigm shift like selinux. Fwiw, the other big lie is Virgin sources, applying patches, with *.spec procedure == reproducible builds. That lie is true iff one knows how to set up a build system, and the tools "work". 73 de Jeff >Gene > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > From imperator at gapfilms.de Sat Apr 3 09:54:19 2004 From: imperator at gapfilms.de (Imperator) Date: Sat, 3 Apr 2004 11:54:19 +0200 Subject: Is there a way to uninstall the SE-extensions? Message-ID: I installed the fedora core 2 and i am not really happy with the SElinux behaviour. since i ported our video software to the 2.6 kernel i used the fedora core 2 release. but unhappily i installed it with the SElinux option. Is there a way to get rid of the SElinux without having to reinstall the buddy again? thnx for help, axel. From gene at czarc.net Sat Apr 3 18:04:02 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 13:04:02 -0500 Subject: FC2T2, Selinux, and VMware Message-ID: <200404031304.02214.gene@czarc.net> I noticed that there are lots of "vmware" references in the SELinux policy files. Anyone have some tips or other perls of wisdon to say about running FC2T2 as a vmware guest or running vmware on a FC2T2 host? Gene From jsfarrow at comcast.net Sat Apr 3 18:18:49 2004 From: jsfarrow at comcast.net (jsfarrow at comcast.net) Date: Sat, 03 Apr 2004 18:18:49 +0000 Subject: kernel panic after policy update failure Message-ID: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> I just updated (via yum) to policy-1.9.2-9 on kernel 2.6.4.1-300 and get the following on reboot: Enforcing mode requested but no policy loaded. Halting now. Kernel panic: Attempted to kill init! I tried adding "selinux=0" to the kernel args, and also tried booting single user, but get the same result. I had to boot rescue mode off the iso disc and turn off selinux in /etc/sysconfig/selinux. Now I can boot again. It turns out that the policy rpm upgrade failed. No biggie, but I am wondering whether it is expected behaviour that you get a kernel panic if you attempt to boot with selinux enabled, but without a policy file (or a damaged file)? As a sysadmin, that concerns me. Perhaps a gentler behaviour would be to dump you in single user mode? - J. Scott Farrow From dwalsh at redhat.com Sat Apr 3 20:48:40 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 03 Apr 2004 15:48:40 -0500 Subject: Not good In-Reply-To: <200404030943.04666.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <200404030449.52614.gene@czarc.net> <406EBC56.3030304@redhat.com> <200404030943.04666.gene@czarc.net> Message-ID: <406F2328.9000202@redhat.com> Gene Czarcinski wrote: >On Saturday 03 April 2004 08:29, Daniel J Walsh wrote: > > >>I have written the steps in the bug report on how to get up2date fixed. >>The final fix for the up2date package has not been released yet. >> >>Fixing up2date is a multi step process. >> >>One update to latest policy. >>restorecon /usr/sbin/up2date >> >>update to latest usermode >> >>Add >>ROLE=sysadm_r >>TYPE=rpm_t >>to >> >>/etc/security/console.apps/up2date. >> >> > >Thanks for the update Dan. > >I am still a bit concerned that up2date did not report that the package >up2date failed and that it removed the old version of the package as well. >If I had been manually updating (as I did with the kernel), I saw that there >was a problem. Up2date should have caught that also but did not. I do not >know if yum has this problem or not and will probably explore using it as an >alternative to up2date. However, I will probably wait for Seth's big rewrite >that he is working on. > > > Submit a bug report on the problem with Up2date. It should not have blown away the old package. Dan >Gene > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From gene at czarc.net Sat Apr 3 21:16:24 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 16:16:24 -0500 Subject: Not good In-Reply-To: <406F2328.9000202@redhat.com> References: <200404011728.15051.gene@czarc.net> <200404030943.04666.gene@czarc.net> <406F2328.9000202@redhat.com> Message-ID: <200404031616.24153.gene@czarc.net> On Saturday 03 April 2004 15:48, Daniel J Walsh wrote: > Submit a bug report on the problem with Up2date. It should not have > blown away the old package. I have in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119538 but the deleting problem may be buried in the report. My initial problem was with the kernel and it did not actually delete the package since kernels are install only. However, when it happened with gdm, yes it deleted the package. Should I submit a new report? One of the problems is that I have moved on (added more updates and will be doing more in a couple of minutes) and, although I have all of the intermediate packages, it will be difficult to actually recreate the problem. I do not like creating bug reports that I cannot reproduce. Gene From gene at czarc.net Sat Apr 3 21:47:20 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 16:47:20 -0500 Subject: Not good In-Reply-To: <200404031616.24153.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <406F2328.9000202@redhat.com> <200404031616.24153.gene@czarc.net> Message-ID: <200404031647.20182.gene@czarc.net> On Saturday 03 April 2004 16:16, Gene Czarcinski wrote: > On Saturday 03 April 2004 15:48, Daniel J Walsh wrote: > > Submit a bug report on the problem with Up2date. It should not have > > blown away the old package. > > I have in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119538 > but the deleting problem may be buried in the report. My initial problem > was with the kernel and it did not actually delete the package since > kernels are install only. However, when it happened with gdm, yes it > deleted the package. > > Should I submit a new report? One of the problems is that I have moved on > (added more updates and will be doing more in a couple of minutes) and, > although I have all of the intermediate packages, it will be difficult to > actually recreate the problem. I do not like creating bug reports that I > cannot reproduce. Well, that was interesting. I just ran up2date to update policy/policy-sources from 1.9.2-5 to 1.9.2-9 and policycoreutils from 1.9.1-1 to 1.9.2-1 and up2date said everything went OK. Trusting person that I am I did a "rpm -qa polic*" and what I got was: policy-1.9.2-9 policycoreutils-1.9.2-1 policy-sources-1.9.2-9 policy-sources-1.9.2-5 Well, it did not delete without installing ... but it did not delete after installing. Gene From gene at czarc.net Sat Apr 3 22:04:01 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 17:04:01 -0500 Subject: Not good In-Reply-To: <200404031647.20182.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <200404031616.24153.gene@czarc.net> <200404031647.20182.gene@czarc.net> Message-ID: <200404031704.01359.gene@czarc.net> On Saturday 03 April 2004 16:47, Gene Czarcinski wrote: > Well, that was interesting. I just ran up2date to update > policy/policy-sources from 1.9.2-5 to 1.9.2-9 and policycoreutils from > 1.9.1-1 to 1.9.2-1 and up2date said everything went OK. Trusting person > that I am I did a "rpm -qa polic*" and what I got was: > > policy-1.9.2-9 > policycoreutils-1.9.2-1 > policy-sources-1.9.2-9 > policy-sources-1.9.2-5 > > Well, it did not delete without installing ... but it did not delete after > installing. Success!! I just updated a second system ... this first was x86_64 and this is ix86 (P-III SMP). I got exactly the same thing. In both cases I was running with the latest up2date and the latest rpm. The update selection was arts-*, elfutils-*, policy-*, policycoreutils, and selinux-doc. I am going to put in a bug report. Can anyone suggest what info I can collect to help troubleshoot this? Gene From n3npq at nc.rr.com Sat Apr 3 22:12:19 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 03 Apr 2004 17:12:19 -0500 Subject: Not good In-Reply-To: <200404031647.20182.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <406F2328.9000202@redhat.com> <200404031616.24153.gene@czarc.net> <200404031647.20182.gene@czarc.net> Message-ID: <406F36C3.7090609@nc.rr.com> Gene Czarcinski wrote: >Well, that was interesting. I just ran up2date to update >policy/policy-sources from 1.9.2-5 to 1.9.2-9 and policycoreutils from >1.9.1-1 to 1.9.2-1 and up2date said everything went OK. Trusting person that >I am I did a "rpm -qa polic*" and what I got was: > >policy-1.9.2-9 >policycoreutils-1.9.2-1 >policy-sources-1.9.2-9 >policy-sources-1.9.2-5 > >Well, it did not delete without installing ... but it did not delete after >installing. > > Try rpm -qa --last to see when/where this happened. 73 de Jeff From gene at czarc.net Sat Apr 3 22:24:10 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 17:24:10 -0500 Subject: Not good In-Reply-To: <406F36C3.7090609@nc.rr.com> References: <200404011728.15051.gene@czarc.net> <200404031647.20182.gene@czarc.net> <406F36C3.7090609@nc.rr.com> Message-ID: <200404031724.10312.gene@czarc.net> On Saturday 03 April 2004 17:12, Jeff Johnson wrote: > Gene Czarcinski wrote: > >Well, that was interesting. I just ran up2date to update > >policy/policy-sources from 1.9.2-5 to 1.9.2-9 and policycoreutils from > >1.9.1-1 to 1.9.2-1 and up2date said everything went OK. Trusting person > > that I am I did a "rpm -qa polic*" and what I got was: > > > >policy-1.9.2-9 > >policycoreutils-1.9.2-1 > >policy-sources-1.9.2-9 > >policy-sources-1.9.2-5 > > > >Well, it did not delete without installing ... but it did not delete after > >installing. > > > > Try > rpm -qa --last > to see when/where this happened. OK, here are the selected entries for "policy*" (unless you really want the whole listing in which case I will direct email it to you): selinux-doc-1.8-3 Sat 03 Apr 2004 04:32:42 PM EST policy-sources-1.9.2-9 Sat 03 Apr 2004 04:32:37 PM EST elfutils-devel-0.95-2 Sat 03 Apr 2004 04:32:34 PM EST elfutils-libelf-devel-0.95-2 Sat 03 Apr 2004 04:32:33 PM EST arts-devel-1.2.1-2 Sat 03 Apr 2004 04:32:33 PM EST policycoreutils-1.9.2-1 Sat 03 Apr 2004 04:32:32 PM EST policy-1.9.2-9 Sat 03 Apr 2004 04:32:32 PM EST elfutils-0.95-2 Sat 03 Apr 2004 04:32:30 PM EST arts-1.2.1-2 Sat 03 Apr 2004 04:32:29 PM EST elfutils-libelf-0.95-2 Sat 03 Apr 2004 04:32:09 PM EST rp-pppoe-3.5-14 Fri 02 Apr 2004 05:01:04 PM EST ... rpmdb-fedora-1.91-0.20040402 Fri 02 Apr 2004 03:52:58 PM EST policy-sources-1.9.2-5 Fri 02 Apr 2004 03:52:47 PM EST libselinux-devel-1.9-1 Fri 02 Apr 2004 03:52:45 PM EST Gene From gene at czarc.net Sat Apr 3 23:42:36 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 3 Apr 2004 18:42:36 -0500 Subject: Not good In-Reply-To: <200404031724.10312.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <406F36C3.7090609@nc.rr.com> <200404031724.10312.gene@czarc.net> Message-ID: <200404031842.36358.gene@czarc.net> On Saturday 03 April 2004 17:24, Gene Czarcinski wrote: > On Saturday 03 April 2004 17:12, Jeff Johnson wrote: > > Gene Czarcinski wrote: > > >Well, that was interesting. I just ran up2date to update > > >policy/policy-sources from 1.9.2-5 to 1.9.2-9 and policycoreutils from > > >1.9.1-1 to 1.9.2-1 and up2date said everything went OK. Trusting person > > > that I am I did a "rpm -qa polic*" and what I got was: > > > > > >policy-1.9.2-9 > > >policycoreutils-1.9.2-1 > > >policy-sources-1.9.2-9 > > >policy-sources-1.9.2-5 > > > > > >Well, it did not delete without installing ... but it did not delete > > > after installing. > > > > Try > > rpm -qa --last > > to see when/where this happened. > > OK, here are the selected entries for "policy*" (unless you really want the > whole listing in which case I will direct email it to you): > selinux-doc-1.8-3 Sat 03 Apr 2004 04:32:42 PM > EST policy-sources-1.9.2-9 Sat 03 Apr 2004 04:32:37 > PM EST elfutils-devel-0.95-2 Sat 03 Apr 2004 > 04:32:34 PM EST elfutils-libelf-devel-0.95-2 Sat 03 Apr > 2004 04:32:33 PM EST arts-devel-1.2.1-2 Sat 03 > Apr 2004 04:32:33 PM EST policycoreutils-1.9.2-1 Sat > 03 Apr 2004 04:32:32 PM EST policy-1.9.2-9 > Sat 03 Apr 2004 04:32:32 PM EST elfutils-0.95-2 > Sat 03 Apr 2004 04:32:30 PM EST arts-1.2.1-2 > Sat 03 Apr 2004 04:32:29 PM EST elfutils-libelf-0.95-2 > Sat 03 Apr 2004 04:32:09 PM EST rp-pppoe-3.5-14 > Fri 02 Apr 2004 05:01:04 PM EST ... > rpmdb-fedora-1.91-0.20040402 Fri 02 Apr 2004 03:52:58 PM > EST policy-sources-1.9.2-5 Fri 02 Apr 2004 03:52:47 > PM EST libselinux-devel-1.9-1 Fri 02 Apr 2004 > 03:52:45 PM EST I found another package with a duplicate entry on one of my systems (gpm). I decided to see what files are actually install by running rpm --verify against policy-sources-1.9.2-9 (only one file different because I changed in (users)) and policy-sources-1.9.2-5 (a whole bunch). So, as far as the delete goes, it looks like it is just the rpm DB that is screwed up. Gene From n3npq at nc.rr.com Sat Apr 3 23:43:11 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 03 Apr 2004 18:43:11 -0500 Subject: Not good In-Reply-To: <200404031724.10312.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <200404031647.20182.gene@czarc.net> <406F36C3.7090609@nc.rr.com> <200404031724.10312.gene@czarc.net> Message-ID: <406F4C0F.5090001@nc.rr.com> Gene Czarcinski wrote: >OK, here are the selected entries for "policy*" (unless you really want the >whole listing in which case I will direct email it to you): >selinux-doc-1.8-3 Sat 03 Apr 2004 04:32:42 PM EST >policy-sources-1.9.2-9 Sat 03 Apr 2004 04:32:37 PM EST >elfutils-devel-0.95-2 Sat 03 Apr 2004 04:32:34 PM EST >elfutils-libelf-devel-0.95-2 Sat 03 Apr 2004 04:32:33 PM EST >arts-devel-1.2.1-2 Sat 03 Apr 2004 04:32:33 PM EST >policycoreutils-1.9.2-1 Sat 03 Apr 2004 04:32:32 PM EST >policy-1.9.2-9 Sat 03 Apr 2004 04:32:32 PM EST >elfutils-0.95-2 Sat 03 Apr 2004 04:32:30 PM EST >arts-1.2.1-2 Sat 03 Apr 2004 04:32:29 PM EST >elfutils-libelf-0.95-2 Sat 03 Apr 2004 04:32:09 PM EST >rp-pppoe-3.5-14 Fri 02 Apr 2004 05:01:04 PM EST >... >rpmdb-fedora-1.91-0.20040402 Fri 02 Apr 2004 03:52:58 PM EST >policy-sources-1.9.2-5 Fri 02 Apr 2004 03:52:47 PM EST >libselinux-devel-1.9-1 Fri 02 Apr 2004 03:52:45 PM EST > > What's needed is context, not details. There's a chance that something other than up2date is/was at fault. Only you know what was happening at the dates/times above. Bugzilla accordingly ;-) 73 de Jeff From adrier at acm.org Sun Apr 4 02:17:53 2004 From: adrier at acm.org (Abe Drier) Date: Sat, 03 Apr 2004 21:17:53 -0500 Subject: Can't get off the ground In-Reply-To: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> References: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> Message-ID: <406F7051.906@acm.org> I have FC1 and FC2T1 with SELinux active on separate disks. I want to install FC2T2 as a new install on in place of FC2T1. Now here is the problem. I can't FC2T2 to install. Not only will it won't install, and can't even get it to boot. I have tried burning CD #1 in a number of different ways. Sometimes the boot process bypasses the CD and goes straight to the hard drive. I got into a situation where it would boot ask a couple questions such as language and then ask for a driver. I tried all the drivers in the list and that failed. I have two CD rooms running on the IDE. The CDs were burned on a Redhat 8 system using x-cd-roast. This must be a simple and straight forward process, what's worse is I have done it twice earlier with FC1 and FC2T1. Would someone be so kind as to give me a blow-by-blow discription of how to get this critter installed. Many thanks. From russell at coker.com.au Sun Apr 4 08:19:11 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 4 Apr 2004 18:19:11 +1000 Subject: Can't get off the ground In-Reply-To: <406F7051.906@acm.org> References: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> <406F7051.906@acm.org> Message-ID: <200404041819.11822.russell@coker.com.au> On Sun, 4 Apr 2004 12:17, Abe Drier wrote: > I have FC1 and FC2T1 with SELinux active on separate disks. I want to > install FC2T2 as a new install on in place of FC2T1. Now here is the > problem. I can't FC2T2 to install. Not only will it won't install, and > can't even get it to boot. I have tried burning CD #1 in a number of There is a known problem with getting it to boot, see bug 119386. It has been reported that booting a FC1 CD and then switching to a FC2T2 CD before it loads the kernel can work, I've never tried it. http://btmgr.sourceforge.net I used the smart boot manager (above URL) to make a kick-start floppy that would jump to the CD. -- 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 aoliva at redhat.com Sun Apr 4 10:23:13 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 04 Apr 2004 07:23:13 -0300 Subject: Advice for installing test2 if you are going to be saving files In-Reply-To: <200404041622.56467.russell@coker.com.au> References: <20040403185248.74575.qmail@web60705.mail.yahoo.com> <200404041622.56467.russell@coker.com.au> Message-ID: [Adding SELinux list] On Apr 4, 2004, Russell Coker wrote: > using the context= mount option to label them as > nfs_t might be an easy hack to solve this). I've tried adding context=system_u:object_r:nfs_t to the mounts containing the maze of soft links that my home dir is, but no luck. First off, booting in enforcing mode, it wouldn't mount it, probably because they're all in logical volumes (I think I heard that SELinux is not compatible with LVM ATM :-( Oddly, if I'm in enforcing mode and attempt to mount them as root_u:sysadm_r:sysadm_t, they fail to mount with the context= setting in /etc/fstab, but mount succeeds without it. Is this a bug? If so, same as above, or a different one? (it says the device is read only) I tried labeling everything in these filesystems as system_u:object_r:nfs_t, but I still couldn't ssh into the box in enforcing mode. SSH key authentication failed to stat() the authorized_keys file, so id demanded a password. Then, it failed to chdir to my homedir, and finally xauth took a few seconds trying to lock ~/.Xauthority before it timed out and gave up, and I was given a prompt with $PWD=/. I could then cd to my home dir and use it normally AFAICT, but this is quite inconvenient. I guess I'll have to stay a bit longer without enforcing mode :-( -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From russell at coker.com.au Sun Apr 4 12:15:38 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 4 Apr 2004 22:15:38 +1000 Subject: FC2T2, Selinux, and VMware In-Reply-To: <200404031304.02214.gene@czarc.net> References: <200404031304.02214.gene@czarc.net> Message-ID: <200404042215.38724.russell@coker.com.au> On Sun, 4 Apr 2004 04:04, Gene Czarcinski wrote: > I noticed that there are lots of "vmware" references in the SELinux policy > files. Anyone have some tips or other perls of wisdon to say about running > FC2T2 as a vmware guest or running vmware on a FC2T2 host? SE Linux has no relevance when running as a guest inside VMware. Whether SE Linux is running or not won't even be known by VMware, and SE Linux isn't at the level that is concerned about hardware. For running VMware on a SE Linux host there is policy for doing so, but it has all users running VMware sessions in the same context. I will probably re-write the VMware policy to give different domains for running VMware from different roles, so we'll have a staff_vmware_t, a user_vmware_t, etc. -- 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 jr36 at leicester.ac.uk Sun Apr 4 12:25:13 2004 From: jr36 at leicester.ac.uk (Jonathan Rawle) Date: Sun, 4 Apr 2004 13:25:13 +0100 Subject: Another dumb question... Message-ID: On Fri, 02 Apr 2004 Stephen Smalley wrote: >> Everything that I've read says that the 'su' command will change my >> Linux user ID but not my identity. Here's what I see: >> >> # id -Z >> root:staff_r:staff_t >> # su fred >> Your default context is fred:sysadm_r:sysadm_t. >> >> Do you want to choose a different one? [n]n >> $ id -Z >> fred:sysadm_r:sysadm_t >> >> My identity changed from 'root' to 'fred'. Bug? That seems a pretty >> fundamental flaw considering that every document that I've read uses >> 'su' to explain the difference between a user ID and an identity. >> >> By the way, I see the same result whether I use 'su' or 'su -'. I see >> the same result (a change in identity) whether I su from root to fred >> or from fred to root. >> >> So which one is right? The documentation or the code? > > RedHat chose to integrate security context transitions into su (via > pam_selinux). The NSA documentation and externally developed > sourceforge selinux HOWTOs/FAQs were written prior to that change. Unlike some posters here, I think SELinux is great, and I don't mean this to be a flame. But reading the existing documentation, I thought the idea of a SELinux identity being separate from the Unix user ID was that it couldn't change, so that it was possible to track people's activity, hold administrators to account, and to ensure users couldn't obtain escalating privileges. If RedHat have made the SELinux identity change with su, then it is identical to the Unix ID. Surely this weakens some of the security provided by SELinux? Hopefully someone can explain why I'm wrong! P.S. please can we add this list to Gmane? I read other Fedora lists there, but I've avoided subscribing to this one as I prefer to use a newsgroup interface. Jonathan From dwalsh at redhat.com Sun Apr 4 12:47:52 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sun, 04 Apr 2004 08:47:52 -0400 Subject: Another dumb question... In-Reply-To: References: Message-ID: <407003F8.8030401@redhat.com> Jonathan Rawle wrote: >On Fri, 02 Apr 2004 Stephen Smalley wrote: > > > >>>Everything that I've read says that the 'su' command will change my >>>Linux user ID but not my identity. Here's what I see: >>> >>># id -Z >>>root:staff_r:staff_t >>># su fred >>>Your default context is fred:sysadm_r:sysadm_t. >>> >>>Do you want to choose a different one? [n]n >>>$ id -Z >>>fred:sysadm_r:sysadm_t >>> >>>My identity changed from 'root' to 'fred'. Bug? That seems a pretty >>>fundamental flaw considering that every document that I've read uses >>>'su' to explain the difference between a user ID and an identity. >>> >>>By the way, I see the same result whether I use 'su' or 'su -'. I see >>>the same result (a change in identity) whether I su from root to fred >>>or from fred to root. >>> >>>So which one is right? The documentation or the code? >>> >>> >>RedHat chose to integrate security context transitions into su (via >>pam_selinux). The NSA documentation and externally developed >>sourceforge selinux HOWTOs/FAQs were written prior to that change. >> >> > >Unlike some posters here, I think SELinux is great, and I don't mean this >to be a flame. > >But reading the existing documentation, I thought the idea of a SELinux >identity being separate from the Unix user ID was that it couldn't change, >so that it was possible to track people's activity, hold administrators to >account, and to ensure users couldn't obtain escalating privileges. > >If RedHat have made the SELinux identity change with su, then it is >identical to the Unix ID. Surely this weakens some of the security >provided by SELinux? Hopefully someone can explain why I'm wrong! > > You are right. We are designing SELinux to be used by the masses and we felt that if we changed the way UNIX/Linux worked to radically people would just turn it off. Or even worse go to a competitor :^(. So we have the concept of tunables which should be come more prevalent in future test versions. This will allow admins to select the amount of protection they want including turning off user_canbe_admin which will separate users, from staff by policy. Our goal in the first release is to introduce MAC and protect the external facing (networked daemons). So these will be protected by MAC. So if you had a machine that only served web pages, you could turn off all the tunables, and end up with the pretty much the policy the NSA intended. >P.S. please can we add this list to Gmane? I read other Fedora lists >there, but I've avoided subscribing to this one as I prefer to use a >newsgroup interface. > > >Jonathan > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From aoliva at redhat.com Sun Apr 4 07:05:45 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 04 Apr 2004 04:05:45 -0300 Subject: ssh -l root getting context staff_t is pointless Message-ID: I read previous discussions about it here. The argument IIRC is that making the default context staff_t adds a little bit of security. IMHO, it adds no security whatsoever, since `ssh -l root hostname -t su -' gets you to sysadm_r without asking for a password. So how about changing the default policy such that ssh selects sysadm_r by default, which should minimize the inconvenience without really losing anything in terms of security? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From digitalcontrol at myrealbox.com Sun Apr 4 22:08:23 2004 From: digitalcontrol at myrealbox.com (Ric Letson) Date: Sun, 04 Apr 2004 18:08:23 -0400 Subject: missing policies? Message-ID: <1081116503.3668.7.camel@syr-24-59-227-58.twcny.rr.com> Where are the user policies located? Am I missing /etc/security/selinux/src/policy/users or has the user list moved to another location? It may be somewhere else and I'm just not finding it, my only experience with selinux was on gentoo. Also, does anyone know of any good documentation on the Fedora Core 2 SELinux implementation? The Fedora website is pretty sparse as far as any documentation goes, probably due to it not being written yet. OS: Fedora Core 2 Test 2 (installed by ftp from redhat mirror) Policy: policy-1.9-15 Coreutils: policycoreutils-1.9-12 -- Ric Letson, NB2E digitalcontrol at myrealbox.com ============================ GPG Signed for Authenticity -------------- 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 kwade at redhat.com Sun Apr 4 22:27:27 2004 From: kwade at redhat.com (Karsten Wade) Date: 04 Apr 2004 15:27:27 -0700 Subject: missing policies? In-Reply-To: <1081116503.3668.7.camel@syr-24-59-227-58.twcny.rr.com> References: <1081116503.3668.7.camel@syr-24-59-227-58.twcny.rr.com> Message-ID: <1081117646.3359.5.camel@erato.phig.org> On Sun, 2004-04-04 at 15:08, Ric Letson wrote: > Where are the user policies located? > > Am I missing /etc/security/selinux/src/policy/users or has the user list > moved to another location? It may be somewhere else and I'm just not > finding it, my only experience with selinux was on gentoo. > > Also, does anyone know of any good documentation on the Fedora Core 2 > SELinux implementation? The Fedora website is pretty sparse as far as > any documentation goes, probably due to it not being written yet. So far, the only Fedora project produced doxen is the SELinux FAQ: http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ We'll move that to the Fedora docs pages on fedora.redhat.com, in a few weeks after the changes to the FAQ slow down. There is one Fedora Core specific installation doc, which may help you with some of your questions: http://www.crypt.gen.nz/selinux/install_fedora.html hth - Karsten -- Karsten Wade, Sr. Tech Writer this is not the .signature you are looking for http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From gene at czarc.net Sun Apr 4 16:48:13 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sun, 4 Apr 2004 11:48:13 -0500 Subject: Not good In-Reply-To: <406F4C0F.5090001@nc.rr.com> References: <200404011728.15051.gene@czarc.net> <200404031724.10312.gene@czarc.net> <406F4C0F.5090001@nc.rr.com> Message-ID: <200404041248.13356.gene@czarc.net> On Saturday 03 April 2004 18:43, Jeff Johnson wrote: > What's needed is context, not details. There's a chance that something > other than up2date is/was at fault. OK, I am not sure what you mean by "context". I started noticing problems with up2date not handling a situation when a package install/update was not completed (as far as I can determine because of selinux policy failures) -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119538 I then attempted to update to the latest version of policy (1.9.2-9) and hit a problem where up2date/rpm was not removing an rpmdb entry for a package that was installed (but perhaps not correctly ... see below) -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119946 I made sure that I had the same general levels of updates on a second system (especially that rpm was the same). Everything looks good. OK, lets reboot ... oops kernel panic rebooting -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119981 ... cannot load/find policy reboot with enforcing=0 ... read the rest in the bugzilla report. So, "context" ... please be a bit more specific in what information you are looking for. I will be happy to gather anything I can but I cannot tell what that is from your "context" comment. Gene From rhallyx at mindspring.com Mon Apr 5 05:13:45 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Mon, 05 Apr 2004 01:13:45 -0400 Subject: errors installing policy Message-ID: <4070EB09.8020207@mindspring.com> Below is a copy of the output from attempting to install the SELinux packages. Should I bugzilla this or are the right people already aware of this? thanks for you help, Richard Hally [root at localhost security]# yum install checkpolicy libselinux policycoreutils policy policy-sources selinux-doc setools Gathering header information file(s) from server(s) Server: Fedora Core 1.91 - i386 - Rawhide Finding updated packages Downloading needed headers perl-suidperl-3-5.8.3-17. 100% |=========================| 5.3 kB 00:00 yum-0-2.0.7-0.20040403.no 100% |=========================| 3.8 kB 00:00 rpmdb-fedora-1-1.91-0.200 100% |=========================| 2.0 kB 00:00 perl-3-5.8.3-17.i386.hdr 100% |=========================| 73 kB 00:00 setools-gui-0-1.2.1-4.i38 100% |=========================| 7.3 kB 00:00 setools-devel-0-1.2.1-4.i 100% |=========================| 2.1 kB 00:00 setools-0-1.2.1-4.i386.hd 100% |=========================| 3.2 kB 00:00 libselinux is installed and is the latest version. selinux-doc is installed and is the latest version. Resolving dependencies Dependencies resolved I will do the following: [install: policy 1.9.2-9.noarch] [install: policycoreutils 1.9.2-1.i386] [install: policy-sources 1.9.2-9.noarch] [install: checkpolicy 1.8-1.i386] [install: setools 1.2.1-4.i386] Is this ok [y/N]: y Downloading Packages Getting policy-1.9.2-9.noarch.rpm policy-1.9.2-9.noarch.rpm 100% |=========================| 954 kB 00:08 Getting policycoreutils-1.9.2-1.i386.rpm policycoreutils-1.9.2-1.i 100% |=========================| 35 kB 00:00 Getting policy-sources-1.9.2-9.noarch.rpm policy-sources-1.9.2-9.no 100% |=========================| 1.8 MB 00:22 Getting checkpolicy-1.8-1.i386.rpm checkpolicy-1.8-1.i386.rp 100% |=========================| 53 kB 00:00 Getting setools-1.2.1-4.i386.rpm setools-1.2.1-4.i386.rpm 100% |=========================| 292 kB 00:02 Running test transaction: /etc/security/selinux/file_contexts: No such file or directory Test transaction complete, Success! /etc/security/selinux/file_contexts: No such file or directory checkpolicy 100 % done 1/5 policycoreutils 100 % done 2/5 policy 100 % done 3/5 Can't open '/etc/security/selinux/policy.16': No such file or directory error: %post(policy-1.9.2-9) scriptlet failed, exit status 2 policy-sources 100 % done 4/5 cat: /selinux/policyvers: No such file or directory cat: /selinux/policyvers: No such file or directory make: Entering directory `/etc/security/selinux/src/policy' /usr/sbin/load_policy /etc/security/selinux/policy. /usr/sbin/load_policy: security_load_policy failed make: *** [tmp/load] Error 3 make: Leaving directory `/etc/security/selinux/src/policy' error: %post(policy-sources-1.9.2-9) scriptlet failed, exit status 2 setools 100 % done 5/5 Installed: policy 1.9.2-9.noarch policycoreutils 1.9.2-1.i386 policy-sources 1.9.2-9.noarch checkpolicy 1.8-1.i386 setools 1.2.1-4.i386 Transaction(s) Complete [root at localhost security]# From sds at epoch.ncsc.mil Mon Apr 5 11:47:25 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 05 Apr 2004 07:47:25 -0400 Subject: ssh -l root getting context staff_t is pointless In-Reply-To: References: Message-ID: <1081165645.5343.3.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-04-04 at 03:05, Alexandre Oliva wrote: > I read previous discussions about it here. The argument IIRC is that > making the default context staff_t adds a little bit of security. > > IMHO, it adds no security whatsoever, since > `ssh -l root hostname -t su -' gets you to sysadm_r without asking for > a password. Do you have unlimitedUsers enabled in policy/tunable.te? That might explain it. Otherwise, the su should require re-authentication, as staff_t isn't normally authorized to skip authentication for pam_rootok. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Apr 5 12:51:35 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 05 Apr 2004 08:51:35 -0400 Subject: Another dumb question... In-Reply-To: References: Message-ID: <1081169495.5343.42.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-04-04 at 08:25, Jonathan Rawle wrote: > But reading the existing documentation, I thought the idea of a SELinux > identity being separate from the Unix user ID was that it couldn't change, > so that it was possible to track people's activity, hold administrators to > account, and to ensure users couldn't obtain escalating privileges. 1) Tracking people's activity and holding administrators to account (i.e. user accountability) is principally a job for an audit framework. As RedHat has introduced such an audit framework via a separate patch, it should be possible to preserve logging of the original login user identity using that audit framework rather than SELinux. Also, the existing SELinux auditing of permission checks could be configured to audit all transitions to and from the su domains, such that the SELinux user identity transitions would be logged as they occur, e.g. adding something like 'auditallow $1_t $1_su_t:process transition; auditallow $1_su_t userdomain:process transition;' to policy/macros/program/su_macros.te (caveat: untested). 2) Privilege escalation can still be bounded based on domain transitions. If you disable the unlimitedUsers and user_canbe_sysadm tunables that RedHat introduced, then user_t cannot use su and cannot transition to sysadm_t; only a staff_t user can use su to transition to sysadm_t. > If RedHat have made the SELinux identity change with su, then it is > identical to the Unix ID. Not identical, e.g. a setuid program still doesn't change the SELinux user identity, and a call to set*uid() by a program doesn't change the SELinux user identity. Only programs that have been specifically modified (typically via pam_selinux) will perform transitions in the SELinux user identity. -- Stephen Smalley National Security Agency From nate at mountaintimes.com Mon Apr 5 00:34:58 2004 From: nate at mountaintimes.com (nate at mountaintimes.com) Date: Sun, 4 Apr 2004 20:34:58 -0400 Subject: SELinux and ReiserFS Message-ID: <1081125298.4070a9b221416@webmail.mountaintimes.com> I just had the idea to install FC2 Test 2 with the Reiser file system. Boot off CD, run "linux reiserfs", format, install everything looks good, but on boot there's nothing but AVC errors about /sbin/init. I am suspecting that the Reiser FS problems with SELinux aren't fixed, and this is an impossible combination. Am I wrong? Is there a way to install FC2 without issues on a Reiser file system, if not the option to should be removed and some documentation should be referenced. Thanks for a great distro guys. Nate Solberg Information Systems Admin High Country Media Group, LLC Boone, NC ------------------------------------------------- This webmail service provided by Appalachian Technologies DSL, Dial-up, Networking and Expert Hosting services for the High-Country and Western NC http://www.apptechnc.net From walters at redhat.com Mon Apr 5 13:59:01 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 05 Apr 2004 09:59:01 -0400 Subject: Advice for installing test2 if you are going to be saving files In-Reply-To: References: <20040403185248.74575.qmail@web60705.mail.yahoo.com> <200404041622.56467.russell@coker.com.au> Message-ID: <1081173541.19613.1.camel@nexus.verbum.private> On Sun, 2004-04-04 at 06:23, Alexandre Oliva wrote: > Oddly, if I'm in enforcing mode and attempt to mount them as > root_u:sysadm_r:sysadm_t, they fail to mount with the context= setting > in /etc/fstab, but mount succeeds without it. Are there any AVC denials in dmesg? > I tried labeling everything in these filesystems as > system_u:object_r:nfs_t, but I still couldn't ssh into the box in > enforcing mode. SSH key authentication failed to stat() the > authorized_keys file, so id demanded a password. What is the type of your ~/.ssh? It should be staff_home_ssh_t most likely. > Then, it failed to > chdir to my homedir, What's the type of your homedir? -------------- 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 jmorris at redhat.com Mon Apr 5 14:03:58 2004 From: jmorris at redhat.com (James Morris) Date: Mon, 5 Apr 2004 10:03:58 -0400 (EDT) Subject: SELinux and ReiserFS In-Reply-To: <1081125298.4070a9b221416@webmail.mountaintimes.com> Message-ID: On Sun, 4 Apr 2004 nate at mountaintimes.com wrote: > > > I just had the idea to install FC2 Test 2 with the Reiser file system. > > Boot off CD, run "linux reiserfs", format, install everything looks good, but on > boot there's nothing but AVC errors about /sbin/init. > > I am suspecting that the Reiser FS problems with SELinux aren't fixed, and this > is an impossible combination. > > Am I wrong? Is there a way to install FC2 without issues on a Reiser file > system, if not the option to should be removed and some documentation should be > referenced. Reiserfs does not support file labeling, although there is a patch in the suse kernel for it (we would only want to apply something that is upstreamable though). - James -- James Morris From kaboom at gatech.edu Mon Apr 5 14:40:48 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Mon, 5 Apr 2004 10:40:48 -0400 (EDT) Subject: Not good In-Reply-To: <406ED26F.3070501@nc.rr.com> References: <200404011728.15051.gene@czarc.net> <200404030449.52614.gene@czarc.net> <406EBC56.3030304@redhat.com> <200404030943.04666.gene@czarc.net> <406ED26F.3070501@nc.rr.com> Message-ID: On Sat, 3 Apr 2004, Jeff Johnson wrote: > All rpm tools have this problem, as one of the two big lies in rpm is > All-or-nothing behavior when installing packages. > That lie is true iff packages are perfect. That is very much not the > case during > a development cycle with an importatnt paradigm shift like selinux. I don't see the selinux policy issues as being any different than, say, # mount -o remount,ro /usr # yum update # People have lived with that for years, they'll learn to live with similar situations due to selinux configs.... later, chris From gene at czarc.net Mon Apr 5 15:27:27 2004 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 5 Apr 2004 10:27:27 -0500 Subject: Not good In-Reply-To: References: <200404011728.15051.gene@czarc.net> <406ED26F.3070501@nc.rr.com> Message-ID: <200404051127.27126.gene@czarc.net> On Monday 05 April 2004 10:40, Chris Ricker wrote: > On Sat, 3 Apr 2004, Jeff Johnson wrote: > > All rpm tools have this problem, as one of the two big lies in rpm is > > All-or-nothing behavior when installing packages. > > That lie is true iff packages are perfect. That is very much not the > > case during > > a development cycle with an importatnt paradigm shift like selinux. > > I don't see the selinux policy issues as being any different than, say, > > # mount -o remount,ro /usr > # yum update > > # > > People have lived with that for years, they'll learn to live with similar > situations due to selinux configs.... I agree but ... we need to understand what the "rules" are with respect to selinux related packages. When things get screwed up, how do we unscrew them. I did not know that the active policy had to be named policy. so when the file was named "policy." I thought it was OK. If I had known, it was a quick fix to rename it to "policy.16". I do believe that the policy packages needs some work: 1. Cannot be built in a private build tree (this possibly caused the "policy." problem which is fixed in 1.9.2-11 ... we will see if it builds in the private tree by a regular user). 2. When policy is installed, it loads the policy it just installed ... OK, sounds reasonable. But, if you then install/update policy-sources, it causes the policy to be rebuilt from source and reloaded again! Why? 3. From what I see, there is no reason to have the policy package at all since policy-sources will build the needed files (except for /etc/security/{default_contexts,default_type,failsafe_context} and they could be in policy-sources too. Gene From sds at epoch.ncsc.mil Mon Apr 5 15:34:06 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 05 Apr 2004 11:34:06 -0400 Subject: Not good In-Reply-To: <200404051127.27126.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <406ED26F.3070501@nc.rr.com> <200404051127.27126.gene@czarc.net> Message-ID: <1081179246.5343.108.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-04-05 at 11:27, Gene Czarcinski wrote: > 3. From what I see, there is no reason to have the policy package at all since > policy-sources will build the needed files (except for > /etc/security/{default_contexts,default_type,failsafe_context} and they could > be in policy-sources too. As I understand it, the intent of policy is to support minimal installs, where the policy-sources and associated dependencies are not desirable. However, note that policy updates can't preserve local customizations, e.g. tunables or users, whereas policy-sources updates do. If you have never customized your policy at all, then you should just be able to update policy. If you have customized your policy and rebuilt it, then the %config(noreplace) should protect the binary policy against direct policy updates, and should protect tunables and users against policy-sources updates. -- Stephen Smalley National Security Agency From gene at czarc.net Mon Apr 5 16:21:00 2004 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 5 Apr 2004 11:21:00 -0500 Subject: Not good In-Reply-To: <1081179246.5343.108.camel@moss-spartans.epoch.ncsc.mil> References: <200404011728.15051.gene@czarc.net> <200404051127.27126.gene@czarc.net> <1081179246.5343.108.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200404051221.00859.gene@czarc.net> On Monday 05 April 2004 11:34, Stephen Smalley wrote: > On Mon, 2004-04-05 at 11:27, Gene Czarcinski wrote: > > 3. From what I see, there is no reason to have the policy package at all > > since policy-sources will build the needed files (except for > > /etc/security/{default_contexts,default_type,failsafe_context} and they > > could be in policy-sources too. > > As I understand it, the intent of policy is to support minimal installs, > where the policy-sources and associated dependencies are not desirable. > However, note that policy updates can't preserve local customizations, > e.g. tunables or users, whereas policy-sources updates do. If you have > never customized your policy at all, then you should just be able to > update policy. If you have customized your policy and rebuilt it, then > the %config(noreplace) should protect the binary policy against direct > policy updates, and should protect tunables and users against > policy-sources updates. That is what I figured ... However, I am not sure that policy-sources should automatically build the policy and file_contexts from source and then load it. Gene From sds at epoch.ncsc.mil Mon Apr 5 16:35:17 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 05 Apr 2004 12:35:17 -0400 Subject: Not good In-Reply-To: <200404051221.00859.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <200404051127.27126.gene@czarc.net> <1081179246.5343.108.camel@moss-spartans.epoch.ncsc.mil> <200404051221.00859.gene@czarc.net> Message-ID: <1081182917.5343.127.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-04-05 at 12:21, Gene Czarcinski wrote: > That is what I figured ... > > However, I am not sure that policy-sources should automatically build the > policy and file_contexts from source and then load it. Tradeoffs either way; you'd typically like for policy updates to take effect immediately. policy and policy-sources could possibly run some helper from the %post scriptlet that checks some local config to see whether the policy should be immediately rebuilt and loaded or whether it should just notify the admin of a pending policy update. -- Stephen Smalley National Security Agency From aoliva at redhat.com Mon Apr 5 17:59:36 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Apr 2004 14:59:36 -0300 Subject: ssh -l root getting context staff_t is pointless In-Reply-To: <1081165645.5343.3.camel@moss-spartans.epoch.ncsc.mil> References: <1081165645.5343.3.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Apr 5, 2004, Stephen Smalley wrote: > On Sun, 2004-04-04 at 03:05, Alexandre Oliva wrote: >> I read previous discussions about it here. The argument IIRC is that >> making the default context staff_t adds a little bit of security. >> >> IMHO, it adds no security whatsoever, since >> `ssh -l root hostname -t su -' gets you to sysadm_r without asking for >> a password. > Do you have unlimitedUsers enabled in policy/tunable.te? That might > explain it. Otherwise, the su should require re-authentication, as > staff_t isn't normally authorized to skip authentication for pam_rootok. Nope, I just happened to have setenforce 0, in which case su - doesn't require a password. I was hoping the message wouldn't make it through moderation, since I had this `doh!' moment right after posting it :-/ -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From notting at redhat.com Mon Apr 5 18:50:22 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Apr 2004 14:50:22 -0400 Subject: kernel panic after policy update failure In-Reply-To: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> References: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> Message-ID: <20040405185021.GA19792@devserv.devel.redhat.com> jsfarrow at comcast.net (jsfarrow at comcast.net) said: > Enforcing mode requested but no policy loaded. Halting now. > Kernel panic: Attempted to kill init! > > I tried adding "selinux=0" to the kernel args, and also tried booting > single user, but get the same result. I had to boot rescue mode off > the iso disc and turn off selinux in /etc/sysconfig/selinux. Now > I can boot again. enforcing=0 should also let you boot. Not booting with selinux=0 is fixed in SysVinit-2.85-23. Bill From gene at czarc.net Mon Apr 5 19:05:52 2004 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 5 Apr 2004 14:05:52 -0500 Subject: kernel panic after policy update failure In-Reply-To: <20040405185021.GA19792@devserv.devel.redhat.com> References: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> <20040405185021.GA19792@devserv.devel.redhat.com> Message-ID: <200404051505.52099.gene@czarc.net> On Monday 05 April 2004 14:50, Bill Nottingham wrote: > jsfarrow at comcast.net (jsfarrow at comcast.net) said: > > Enforcing mode requested but no policy loaded. Halting now. > > Kernel panic: Attempted to kill init! > > > > I tried adding "selinux=0" to the kernel args, and also tried booting > > single user, but get the same result. I had to boot rescue mode off > > the iso disc and turn off selinux in /etc/sysconfig/selinux. Now > > I can boot again. > > enforcing=0 should also let you boot. Not booting with selinux=0 > is fixed in SysVinit-2.85-23. Experience: It is a bit "cleaner" to boot enforcing=0 rather than selinux=0 (even in single user mode) when you are doing this to fix policy/policy-sources. Installing/reinstalling these rpms will get a bit confused if selinux is not running. Gene From 1 at 234.cx Mon Apr 5 19:10:35 2004 From: 1 at 234.cx (Pete Chown) Date: Mon, 05 Apr 2004 20:10:35 +0100 Subject: SELinux and ReiserFS In-Reply-To: References: Message-ID: <4071AF2B.4030503@234.cx> James Morris wrote: > Reiserfs does not support file labeling, although there is a patch in the > suse kernel for it (we would only want to apply something that is > upstreamable though). I hope this patch will make it into FC2. I have a lot of machines that are running on reiserfs, and can't easily be switched. This is for the obvious reason that reorganising the filesystems is time consuming. More importantly, though, there is an application which was developed specifically with reiserfs in mind, and creates huge numbers of small files. It would be difficult to run this under ext3. Pete From jmorris at redhat.com Mon Apr 5 19:22:24 2004 From: jmorris at redhat.com (James Morris) Date: Mon, 5 Apr 2004 15:22:24 -0400 (EDT) Subject: SELinux and ReiserFS In-Reply-To: <4071AF2B.4030503@234.cx> Message-ID: On Mon, 5 Apr 2004, Pete Chown wrote: > James Morris wrote: > > > Reiserfs does not support file labeling, although there is a patch in the > > suse kernel for it (we would only want to apply something that is > > upstreamable though). > > I hope this patch will make it into FC2. It won't unless Hans accepts the patch upstream. > I have a lot of machines that are running on reiserfs, and can't easily > be switched. This is for the obvious reason that reorganising the > filesystems is time consuming. More importantly, though, there is an > application which was developed specifically with reiserfs in mind, and > creates huge numbers of small files. It would be difficult to run this > under ext3. You can probably solve this with a context mount, as you won't need reiserfs for the entire box. - James -- James Morris From 1 at 234.cx Mon Apr 5 20:07:05 2004 From: 1 at 234.cx (Pete Chown) Date: Mon, 05 Apr 2004 21:07:05 +0100 Subject: SELinux and ReiserFS In-Reply-To: References: Message-ID: <4071BC69.1000009@234.cx> James Morris wrote: > > I hope this patch will make it into FC2. > It won't unless Hans accepts the patch upstream. Would you accept a patch against the kernel spec file and SRPM contents? In other words, if I make it easy for you, will it go in? Or is it more problematic than this, for example that the patch won't apply cleanly to the RedHat kernel? > You can probably solve this with a context mount, as you won't need > reiserfs for the entire box. I don't know that I'd be too keen on having part of the filesystem unlabelled. Presumably anyone who gets root has full control over any unlabelled files regardless of their SELinux credentials? Most likely I'll be solving this problem with a customised kernel, if I go for SELinux at all. Pete From jmorris at redhat.com Mon Apr 5 20:17:53 2004 From: jmorris at redhat.com (James Morris) Date: Mon, 5 Apr 2004 16:17:53 -0400 (EDT) Subject: SELinux and ReiserFS In-Reply-To: <4071BC69.1000009@234.cx> Message-ID: On Mon, 5 Apr 2004, Pete Chown wrote: > James Morris wrote: > > > > I hope this patch will make it into FC2. > > > It won't unless Hans accepts the patch upstream. > > Would you accept a patch against the kernel spec file and SRPM contents? > In other words, if I make it easy for you, will it go in? Or is it > more problematic than this, for example that the patch won't apply > cleanly to the RedHat kernel? No. The patch must be acceptable upstream, in the mainline kernel. > > > You can probably solve this with a context mount, as you won't need > > reiserfs for the entire box. > > I don't know that I'd be too keen on having part of the filesystem > unlabelled. Presumably anyone who gets root has full control over any > unlabelled files regardless of their SELinux credentials? It is labeled at the kernel level (like genfs mounts), SELinux controls work normally, and root cannot do anything special that could not be done with an xattr filesystem. - James -- James Morris From kwade at redhat.com Mon Apr 5 20:20:02 2004 From: kwade at redhat.com (Karsten Wade) Date: 05 Apr 2004 13:20:02 -0700 Subject: SELinux and ReiserFS In-Reply-To: References: Message-ID: <1081196402.3359.49.camel@erato.phig.org> On Mon, 2004-04-05 at 07:03, James Morris wrote: > Reiserfs does not support file labeling, although there is a patch in the > suse kernel for it (we would only want to apply something that is > upstreamable though). Are any other file systems besides ext2/3 usable for SELinux? thx - Karsten -- Karsten Wade, Sr. Tech Writer this is not the .signature you are looking for http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From notting at redhat.com Mon Apr 5 20:26:09 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Apr 2004 16:26:09 -0400 Subject: SELinux and ReiserFS In-Reply-To: <1081196402.3359.49.camel@erato.phig.org> References: <1081196402.3359.49.camel@erato.phig.org> Message-ID: <20040405202609.GE1502@devserv.devel.redhat.com> Karsten Wade (kwade at redhat.com) said: > On Mon, 2004-04-05 at 07:03, James Morris wrote: > > Reiserfs does not support file labeling, although there is a patch in the > > suse kernel for it (we would only want to apply something that is > > upstreamable though). > > Are any other file systems besides ext2/3 usable for SELinux? XFS supports labels, as I recall. Bill From dwalsh at redhat.com Mon Apr 5 21:04:24 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 05 Apr 2004 17:04:24 -0400 Subject: missing policies? In-Reply-To: <1081116503.3668.7.camel@syr-24-59-227-58.twcny.rr.com> References: <1081116503.3668.7.camel@syr-24-59-227-58.twcny.rr.com> Message-ID: <4071C9D8.6030200@redhat.com> Ric Letson wrote: >Where are the user policies located? > >Am I missing /etc/security/selinux/src/policy/users or has the user list >moved to another location? It may be somewhere else and I'm just not >finding it, my only experience with selinux was on gentoo. > > > No the users file should be there. >Also, does anyone know of any good documentation on the Fedora Core 2 >SELinux implementation? The Fedora website is pretty sparse as far as >any documentation goes, probably due to it not being written yet. > >OS: Fedora Core 2 Test 2 (installed by ftp from redhat mirror) >Policy: policy-1.9-15 >Coreutils: policycoreutils-1.9-12 > > > >------------------------------------------------------------------------ > >-- >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 Apr 5 21:11:05 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 05 Apr 2004 17:11:05 -0400 Subject: Not good In-Reply-To: <200404051127.27126.gene@czarc.net> References: <200404011728.15051.gene@czarc.net> <406ED26F.3070501@nc.rr.com> <200404051127.27126.gene@czarc.net> Message-ID: <4071CB69.1050203@redhat.com> Gene Czarcinski wrote: >On Monday 05 April 2004 10:40, Chris Ricker wrote: > > >>On Sat, 3 Apr 2004, Jeff Johnson wrote: >> >> >>>All rpm tools have this problem, as one of the two big lies in rpm is >>> All-or-nothing behavior when installing packages. >>>That lie is true iff packages are perfect. That is very much not the >>>case during >>>a development cycle with an importatnt paradigm shift like selinux. >>> >>> >>I don't see the selinux policy issues as being any different than, say, >> >># mount -o remount,ro /usr >># yum update >> >># >> >>People have lived with that for years, they'll learn to live with similar >>situations due to selinux configs.... >> >> > >I agree but ... we need to understand what the "rules" are with respect to >selinux related packages. When things get screwed up, how do we unscrew >them. I did not know that the active policy had to be named policy. >so when the file was named "policy." I thought it was OK. If I had known, it >was a quick fix to rename it to "policy.16". > >I do believe that the policy packages needs some work: > >1. Cannot be built in a private build tree (this possibly caused the "policy." >problem which is fixed in 1.9.2-11 ... we will see if it builds in the >private tree by a regular user). > > This is a bug caused by the user being unable to read policy_config_t files (file_context) >2. When policy is installed, it loads the policy it just installed ... OK, >sounds reasonable. But, if you then install/update policy-sources, it causes >the policy to be rebuilt from source and reloaded again! Why? > > We are going to rework the make file to build all supported policy versions. The problem is that the kernels are supporting newer versions of policy, but you can select older kernels which will cause crashes. So if we need to build policy.15 and 16 now and soon 17 ... >3. From what I see, there is no reason to have the policy package at all since >policy-sources will build the needed files (except for >/etc/security/{default_contexts,default_type,failsafe_context} and they could >be in policy-sources too. > > The problem is that policy-sources requires additional packages, checkpolicy, m4, make ... and it is considered that minimal installs don't need all that stuff. We have just made a change to link up policy-sources to policy, So you can install policy alone, but once you install policy-sources you will be required to install an updated policy file, so they should work in lockstep, Also if you have updated policy files users, tunables. Then policy will not override them. The last problem is when the policy version changes (not the rpm version). The fix above to build all supported policy versions should fix that. >Gene > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From don.patterson at tresys.com Mon Apr 5 21:16:11 2004 From: don.patterson at tresys.com (Don Patterson) Date: Mon, 5 Apr 2004 17:16:11 -0400 Subject: missing policies? In-Reply-To: <4071C9D8.6030200@redhat.com> Message-ID: You may need to install the policy-sources package. Try 'yum install policy-sources'. -Don -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Daniel J Walsh Sent: Monday, April 05, 2004 4:04 PM To: Fedora SELinux support list for users & developers. Subject: Re: missing policies? Ric Letson wrote: >Where are the user policies located? > >Am I missing /etc/security/selinux/src/policy/users or has the user list >moved to another location? It may be somewhere else and I'm just not >finding it, my only experience with selinux was on gentoo. > > > No the users file should be there. >Also, does anyone know of any good documentation on the Fedora Core 2 >SELinux implementation? The Fedora website is pretty sparse as far as >any documentation goes, probably due to it not being written yet. > >OS: Fedora Core 2 Test 2 (installed by ftp from redhat mirror) >Policy: policy-1.9-15 >Coreutils: policycoreutils-1.9-12 > > > >------------------------------------------------------------------------ > >-- >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 jmorris at redhat.com Mon Apr 5 21:21:57 2004 From: jmorris at redhat.com (James Morris) Date: Mon, 5 Apr 2004 17:21:57 -0400 (EDT) Subject: SELinux and ReiserFS In-Reply-To: <20040405202609.GE1502@devserv.devel.redhat.com> Message-ID: On Mon, 5 Apr 2004, Bill Nottingham wrote: > Karsten Wade (kwade at redhat.com) said: > > On Mon, 2004-04-05 at 07:03, James Morris wrote: > > > Reiserfs does not support file labeling, although there is a patch in the > > > suse kernel for it (we would only want to apply something that is > > > upstreamable though). > > > > Are any other file systems besides ext2/3 usable for SELinux? > > XFS supports labels, as I recall. devpts can also be labeled with xattrs. - James -- James Morris From gene at czarc.net Mon Apr 5 21:30:55 2004 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 5 Apr 2004 16:30:55 -0500 Subject: Not good In-Reply-To: <4071CB69.1050203@redhat.com> References: <200404011728.15051.gene@czarc.net> <200404051127.27126.gene@czarc.net> <4071CB69.1050203@redhat.com> Message-ID: <200404051730.55046.gene@czarc.net> On Monday 05 April 2004 17:11, Daniel J Walsh wrote: > The problem is that policy-sources requires additional packages, > checkpolicy, m4, make ... > and it is considered that minimal installs don't need all that stuff. After my initial griping I cam to realize that policy is needed. However, how about the suggestion made in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118604 The policy package would be for minimal and installation that only need the canned policies whereas policy-sources would be everthing. You would have one or the other installed but not both. ( installation option ). Gene From digitalcontrol at myrealbox.com Mon Apr 5 22:07:17 2004 From: digitalcontrol at myrealbox.com (Ric Letson) Date: Mon, 05 Apr 2004 18:07:17 -0400 Subject: missing policies? In-Reply-To: References: Message-ID: <1081202837.23968.28.camel@syr-24-59-227-58.twcny.rr.com> On Mon, 2004-04-05 at 17:16, Don Patterson wrote: > You may need to install the policy-sources package. Try 'yum install > policy-sources'. > > -Don > > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com > [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Daniel J Walsh > Sent: Monday, April 05, 2004 4:04 PM > To: Fedora SELinux support list for users & developers. > Subject: Re: missing policies? > > Ric Letson wrote: > > >Where are the user policies located? > > > >Am I missing /etc/security/selinux/src/policy/users or has the user list > >moved to another location? It may be somewhere else and I'm just not Yeah, I realized that I hadn't installed the policy-sources last night and installed them, this fixed the problem. Thank You though. -- Ric Letson, NB2E digitalcontrol at myrealbox.com ============================ GPG Signed for Authenticity -------------- 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 Mon Apr 5 22:23:37 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 05 Apr 2004 18:23:37 -0400 Subject: Updated policy files are available on ftp://people.redhat.com/dwalsh/SELinux In-Reply-To: <1081202837.23968.28.camel@syr-24-59-227-58.twcny.rr.com> References: <1081202837.23968.28.camel@syr-24-59-227-58.twcny.rr.com> Message-ID: <4071DC69.7090109@redhat.com> This is a yum repository, so if anyone wants to looked at the latest policy files, I will throw them out there. Dan From bmccarty at pt-net.net Mon Apr 5 22:48:37 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Mon, 05 Apr 2004 15:48:37 -0700 Subject: SELinux for RHEL3 Message-ID: <320328467.1081180117@[192.168.0.3]> Hi all, My question is somewhat off topic, but I hope that it can nevertheless be indulged. Some time ago, SELinux packages for RHEL 3 had been available on people.redhat.com. I successfully installed SELinux on several RHEL 3 systems using these packages. However, the packages that currently reside there don't work under RHEL 3. I've tried various cheats, such as using FC 2 packages, compiling source RPMs, etc. But, so far, everything I've tried is no-go for at least some of the necessary packages. Do RHEL 3 packages for SELinux currently exist? If so, where can they be obtained? If not, must we wait for RHEL 4 to obtain compatible SELinux packages? Or, is there a chance of another experimental release for RHEL 3? I myself don't mind hacking the SRPMs or whatever a bit. But, the available packages seem to be bound to a variety of versions of automake and autoconf. Hence, it's very troublesome to coax all of them into compiling on the same host . The coreutils package is especially troublesome; if SELinux packages aren't available I suspect that I'll have to patch the RHEL 3 coreutils sources. But I can't see when I'll have time to do so . So, any pointers are most welcome! Cheers, --------------------------------------------------- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From sct at redhat.com Tue Apr 6 00:12:08 2004 From: sct at redhat.com (Stephen C. Tweedie) Date: 06 Apr 2004 01:12:08 +0100 Subject: SELinux and ReiserFS In-Reply-To: <20040405202609.GE1502@devserv.devel.redhat.com> References: <1081196402.3359.49.camel@erato.phig.org> <20040405202609.GE1502@devserv.devel.redhat.com> Message-ID: <1081210328.3067.1181.camel@sisko.scot.redhat.com> Hi, On Mon, 2004-04-05 at 21:26, Bill Nottingham wrote: > XFS supports labels, as I recall. Yes, the XFS xattr support got the security.* namespace added on Jan 30 this year, so it should work fine. --Stephen From dwalsh at redhat.com Tue Apr 6 02:16:18 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 05 Apr 2004 22:16:18 -0400 Subject: SELinux for RHEL3 In-Reply-To: <320328467.1081180117@[192.168.0.3]> References: <320328467.1081180117@[192.168.0.3]> Message-ID: <407212F2.7080404@redhat.com> Bill McCarty wrote: > Hi all, > > My question is somewhat off topic, but I hope that it can nevertheless > be indulged. Some time ago, SELinux packages for RHEL 3 had been > available on people.redhat.com. I successfully installed SELinux on > several RHEL 3 systems using these packages. However, the packages > that currently reside there don't work under RHEL 3. I've tried > various cheats, such as using FC 2 packages, compiling source RPMs, > etc. But, so far, everything I've tried is no-go for at least some of > the necessary packages. > > Do RHEL 3 packages for SELinux currently exist? If so, where can they > be obtained? If not, must we wait for RHEL 4 to obtain compatible > SELinux packages? Or, is there a chance of another experimental > release for RHEL 3? > > I myself don't mind hacking the SRPMs or whatever a bit. But, the > available packages seem to be bound to a variety of versions of > automake and autoconf. Hence, it's very troublesome to coax all of > them into compiling on the same host . The coreutils package is > especially troublesome; if SELinux packages aren't available I suspect > that I'll have to patch the RHEL 3 coreutils sources. But I can't see > when I'll have time to do so . So, any pointers are most welcome! No I was attempting to keep them current, but eventually the FC versions changed to much to keep doing. There will be RHEL 4 Alpha and Betas available soon, but most of those are based off of FC2. Also installing new kernels and SELinux on RHEL 3 is not supported. Dan > > Cheers, > > --------------------------------------------------- > Bill McCarty, Ph.D. > Professor of Information Technology > Azusa Pacific University > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bmccarty at pt-net.net Tue Apr 6 02:44:06 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Mon, 05 Apr 2004 19:44:06 -0700 Subject: SELinux for RHEL3 In-Reply-To: <407212F2.7080404@redhat.com> References: <320328467.1081180117@[192.168.0.3]> <407212F2.7080404@redhat.com> Message-ID: <11511001.1081194246@[192.168.0.3]> Hi Dan, --On Monday, April 05, 2004 10:16 PM -0400 Daniel J Walsh wrote: > No I was attempting to keep them current, but eventually the FC versions > changed to much to keep doing. There will be RHEL 4 Alpha and Betas > available soon, but most of those are based off of FC2. I understand . Thanks just the same for the earlier RHEL 3 packages and your helpful reply. > Also installing > new kernels and SELinux on RHEL 3 is not supported. Understandable, and understood . Cheers, --------------------------------------------------- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From jsfarrow at comcast.net Tue Apr 6 02:47:31 2004 From: jsfarrow at comcast.net (J. Scott Farrow) Date: Mon, 05 Apr 2004 20:47:31 -0600 Subject: kernel panic after policy update failure In-Reply-To: <200404051505.52099.gene@czarc.net> References: <040320041818.22830.406F00090004726B0000592E2200745672FF88908D8D9E998C@comcast.net> <20040405185021.GA19792@devserv.devel.redhat.com> <200404051505.52099.gene@czarc.net> Message-ID: <1081219651.2315.12.camel@pontifex> On Mon, 2004-04-05 at 13:05, Gene Czarcinski wrote: [...] snip > > Experience: It is a bit "cleaner" to boot enforcing=0 rather than selinux=0 > (even in single user mode) when you are doing this to fix > policy/policy-sources. Installing/reinstalling these rpms will get a bit > confused if selinux is not running. > I'm going to agree with Gene here. In the process of my testing both the enforce=0 and selinux=0 kernel args (with no policy file), I managed to get myself into a state whereby I couldn't boot. It looked like a corrupt filesystem, but after fscking, I still couldn't boot until I did enforce=0 on the kernel args again. Syslog revealed the following: Apr 5 20:20:57 pontifex kernel: audit(1081196423.162:0): avc: denied { read } for pid=1 exe=/sbin/init name=utmp dev=hde2 ino=81925 scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t tclass=file Apr 5 20:20:57 pontifex kernel: audit(1081196423.162:0): avc: denied { lock } for pid=1 exe=/sbin/init path=/var/run/utmp dev=hde2 ino=81925 scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t tclass=file Apr 5 20:20:57 pontifex kernel: audit(1081196426.505:0): avc: denied { read } for pid=51 exe=/usr/bin/rhgb name=mtab dev=hde2 ino=561287 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:file_t tclass=file Apr 5 20:20:57 pontifex kernel: audit(1081196426.505:0): avc: denied { getattr } for pid=51 exe=/usr/bin/rhgb path=/etc/mtab dev=hde2 ino=561287 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:file_t tclass=file I poked at this a bit, then ran a fixfiles. I'm assuming I created or updated files without labels on them when I booted 'selinux=0'? Boots fine with enforcing on afterwards. :) At any rate, both enforcing=0 and selinux=0 do indeed now permit you to boot and fix things when your policy file is missing. Having to resort to a rescue disk was not a good option. Nice work! - J. Scott Farrow jsfarrow at comcast.net From rhallyx at mindspring.com Tue Apr 6 02:56:54 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Mon, 05 Apr 2004 22:56:54 -0400 Subject: avc denied messages from boot Message-ID: <40721C76.2080609@mindspring.com> when booting to runlevel 5 in enforcing mode with the latest policy there were only a few AVC denied messages. they are copied below. [root at localhost root]# rpm -q policy policy-sources policy-1.9.2-10 policy-sources-1.9.2-10 [root at localhost root]# Hope this helps, Richard Hally --------------------messages----------------------------- Apr 5 22:37:25 localhost crond: crond startup succeeded Apr 5 22:37:25 localhost kernel: audit(1081219045.889:0): avc: denied { read } for pid=1647 exe=/usr/sbin/crond name=mailman dev=hdc3 ino=539689 scontext=system_u:system_r:crond_t tcontext=system_u:object_r:file_t tclass=file Apr 5 22:37:27 localhost xfs: xfs startup succeeded Apr 5 22:38:04 localhost gdm(pam_unix)[1814]: session opened for user richard by (uid=0) Apr 5 22:38:19 localhost kernel: audit(1081219099.459:0): avc: denied { setattr } for pid=1886 exe=/usr/libexec/gnome-settings-daemon name=registry.xml dev=hdc3 ino=3009195 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:var_t tclass=file Apr 5 22:38:20 localhost kernel: audit(1081219100.136:0): avc: denied { getattr } for pid=1901 exe=/usr/X11R6/bin/xscreensaver path=/home/richard/.xscreensaver dev=hdc3 ino=2469233 scontext=richard:staff_r:staff_screensaver_t tcontext=richard:object_r:staff_home_t tclass=file Apr 5 22:38:29 localhost kernel: audit(1081219109.860:0): avc: denied { getattr } for pid=1955 exe=/usr/libexec/gnome-vfs-daemon path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Apr 5 22:38:30 localhost kernel: audit(1081219110.466:0): avc: denied { getattr } for pid=1966 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Apr 5 22:38:30 localhost kernel: audit(1081219110.653:0): avc: denied { getattr } for pid=1967 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Apr 5 22:38:37 localhost kernel: audit(1081219117.803:0): avc: denied { setattr } for pid=1976 exe=/usr/libexec/mixer_applet2 name=registry.xml dev=hdc3 ino=3009195 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:var_t tclas: From wtogami at redhat.com Tue Apr 6 07:42:03 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Apr 2004 21:42:03 -1000 Subject: List of selinux issues Message-ID: <40725F4B.6050909@redhat.com> This is my first time running with selinux enforcement enabled and this system has been apt upgraded from FC2test1 to latest rawhide, so please forgive me that some of these will be duplicates and others may be errors. Please let me know which are not duplicates, and if you want me to bugzilla them. To be clear, I did the following in order to ensure that my labels are correct during runtime. I hope this was correct. setenforce off fixfiles relabel setenforce 1 1) Infinite Loop of these messages when using "/sbin/ifup eth0" as non-root user. This is allowed when enforcement is disabled. CTRL-C is abled to stop the looping. Apr 5 21:07:28 ibmlaptop kernel: audit(1081235248.571:0): avc: denied { setuid } for pid=2463 exe=/bin/bash capability=7 scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=capability Apr 5 21:07:28 ibmlaptop kernel: audit(1081235248.589:0): avc: denied { setuid } for pid=2463 exe=/usr/sbin/usernetctl capability=7 scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=capability 2) "su -" from my non-root user caused this error. I was however allowed to work as root. Apr 5 21:07:42 ibmlaptop su(pam_unix)[12399]: session opened for user root by warren(uid=500) Apr 5 21:07:42 ibmlaptop su[12399]: pam_xauth: error creating temporary file `/root/.xauthsDAz4e': Permission denied Apr 5 21:07:42 ibmlaptop kernel: audit(1081235262.772:0): avc: denied { write } for pid=12399 exe=/bin/su name=root dev=hda2 ino=1291809 scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t tclass=dir 3) Then as root, I used "ifup eth0" which succeeded, but with the following in /var/log/messages. Apr 5 21:07:45 ibmlaptop kernel: audit(1081235265.089:0): avc: denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 ino=1389922 scontext=root:system_r:dhcpc_t tcontext=system_u:object_r:home_root_t tclass=dir Apr 5 21:07:45 ibmlaptop kernel: audit(1081235265.089:0): avc: denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 ino=1389922 scontext=root:system_r:dhcpc_t tcontext=system_u:object_r:home_root_t tclass=dir Apr 5 21:07:45 ibmlaptop dhclient: can't create /var/lib/dhcp/dhclient-eth0.leases: Permission denied Apr 5 21:07:46 ibmlaptop dhclient: sit0: unknown hardware address type 776 Apr 5 21:07:48 ibmlaptop dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 Apr 5 21:07:48 ibmlaptop dhclient: DHCPOFFER from 172.31.16.1 Apr 5 21:07:48 ibmlaptop dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Apr 5 21:07:48 ibmlaptop dhclient: DHCPACK from 172.31.16.1 Apr 5 21:07:48 ibmlaptop dhclient: can't create /var/lib/dhcp/dhclient-eth0.leases: Permission denied Apr 5 21:07:48 ibmlaptop dhclient: bound to 172.31.16.101 -- renewal in 356918 seconds. Apr 5 21:07:48 ibmlaptop kernel: audit(1081235268.039:0): avc: denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 ino=1389922 scontext=root:system_r:dhcpc_t tcontext=system_u:object_r:home_root_t tclass=dir 4) GNOME mixer_applet2 is unable to reach the device. Strangely this began failing in permissive mode too, but it works when selinux is totally disabled and not loaded. Apr 5 21:07:10 ibmlaptop kernel: audit(1081235230.797:0): avc: denied { setattr } for pid=2435 exe=/usr/libexec/mixer_applet2 name=registry.xml dev=hda2 ino=1425367 scontext=user_u:user_r:user_t tcontext=system_u:object_r:var_t tclass=file 5) This is vmware from the VMWare WS 4.5.1 service startup. The issues are ... complicated, numerous, and scary looking. Apr 5 21:06:08 ibmlaptop kernel: vmmon: module license 'unspecified' taints kernel. Apr 5 21:06:08 ibmlaptop kernel: vmnet: module license 'unspecified' taints kernel. Apr 5 21:06:08 ibmlaptop kernel: audit(1081235168.858:0): avc: denied { search } for pid=1909 exe=/usr/bin/vmnet-netifup name=net dev= ino=344 scontext=system_u:system_r:vmware_t tcontext=system_u:object_r:sysfs_t tclass=dir Apr 5 21:06:08 ibmlaptop kernel: audit(1081235168.867:0): avc: denied { search } for pid=1910 exe=/usr/bin/vmnet-netifup name=net dev= ino=344 scontext=system_u:system_r:vmware_t tcontext=system_u:object_r:sysfs_t tclass=dir Apr 5 21:06:09 ibmlaptop kernel: audit(1081235169.047:0): avc: denied { node_bind } for pid=1931 exe=/usr/bin/vmnet-natd scontext=system_u:system_r:vmware_t tcontext=system_u:object_r:node_inaddr_any_t tclass=rawip_socket Apr 5 21:06:09 ibmlaptop kernel: audit(1081235169.048:0): avc: denied { create } for pid=1931 exe=/usr/bin/vmnet-natd name=vmnat.1931 scontext=system_u:system_r:vmware_t tcontext=system_u:object_r:var_run_t tclass=sock_file Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Internet Software Consortium DHCP Server 2.0 Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: All rights reserved. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Please contribute if you find this software useful. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: For info, please visit http://www.isc.org/dhcp-contrib.html Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Internet Software Consortium DHCP Server 2.0 Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: All rights reserved. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Internet Software Consortium DHCP Server 2.0 Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: All rights reserved. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Configured subnet: 173.31.18.0 Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Please contribute if you find this software useful. Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Setting vmnet-dhcp IP address: 173.31.18.254 Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: For info, please visit http://www.isc.org/dhcp-contrib.html Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Recving on VNet/vmnet1/173.31.18.0 Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Apr 5 21:06:10 ibmlaptop vmnet-dhcpd: Sending on VNet/vmnet1/173.31.18.0 Apr 5 21:06:11 ibmlaptop vmnet-dhcpd: Configured subnet: 173.31.17.0 Apr 5 21:06:12 ibmlaptop vmnet-dhcpd: Setting vmnet-dhcp IP address: 173.31.17.254 Apr 5 21:06:12 ibmlaptop vmnet-dhcpd: Recving on VNet/vmnet8/173.31.17.0 Apr 5 21:06:12 ibmlaptop vmnet-dhcpd: Sending on VNet/vmnet8/173.31.17.0 Apr 5 21:06:15 ibmlaptop kernel: audit(1081235175.873:0): avc: denied { create } for pid=2253 exe=/usr/bin/vmware-nmbd scontext=system_u:system_r:vmware_t tcontext=system_u:system_r:vmware_t tclass=udp_socket Apr 5 21:06:15 ibmlaptop kernel: audit(1081235175.873:0): avc: denied { create } for pid=2253 exe=/usr/bin/vmware-nmbd scontext=system_u:system_r:vmware_t tcontext=system_u:system_r:vmware_t tclass=udp_socket Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.460:0): avc: denied { read } for pid=2254 exe=/usr/bin/vmware-smbd name=urandom dev=hda2 ino=1270748 scontext=system_u:system_r:vmware_t tcontext=system_u:object_r:urandom_device_t tclass=chr_fileApr 5 21:06:16 ibmlaptop kernel: audit(1081235176.461:0): avc: denied { read } for pid=2254 exe=/usr/bin/vmware-smbd name=shadow dev=hda2 ino=1963867 scontext=system_u:system_r:vmware_t tcontext=system_u:object_r:shadow_t tclass=file Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.804:0): avc: denied { setgid } for pid=2254 exe=/usr/bin/vmware-smbd capability=6 scontext=system_u:system_r:vmware_t tcontext=system_u:system_r:vmware_t tclass=capability Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.804:0): avc: denied { setgid } for pid=2254 exe=/usr/bin/vmware-smbd capability=6 scontext=system_u:system_r:vmware_t tcontext=system_u:system_r:vmware_t tclass=capability Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.805:0): avc: denied { setgid } for pid=2254 exe=/usr/bin/vmware-smbd capability=6 scontext=system_u:system_r:vmware_t tcontext=system_u:system_r:vmware_t tclass=capability Apr 5 21:06:16 ibmlaptop last message repeated 2 times Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.899:0): avc: denied { read } for pid=2254 exe=/usr/bin/vmware-smbd name=printcap dev=hda2 ino=1962265 scontext=system_u:system_r:vmware_t tcontext=system_u:object_r:cupsd_rw_etc_t tclass=file Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.899:0): avc: denied { create } for pid=2254 exe=/usr/bin/vmware-smbd scontext=system_u:system_r:vmware_t tcontext=system_u:system_r:vmware_t tclass=udp_socket Apr 5 21:06:17 ibmlaptop kernel: audit(1081235177.041:0): avc: denied { sys_resource } for pid=2254 exe=/usr/bin/vmware-smbd capability=24 scontext=system_u:system_r:vmware_t tcontext=system_u:system_r:vmware_t tclass=capability From dwalsh at redhat.com Tue Apr 6 11:10:04 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 07:10:04 -0400 Subject: avc denied messages from boot In-Reply-To: <40721C76.2080609@mindspring.com> References: <40721C76.2080609@mindspring.com> Message-ID: <4072900C.5030207@redhat.com> Richard Hally wrote: > when booting to runlevel 5 in enforcing mode with the latest policy > there were only a few AVC denied messages. they are copied below. > [root at localhost root]# rpm -q policy policy-sources > policy-1.9.2-10 > policy-sources-1.9.2-10 > [root at localhost root]# > > Hope this helps, > Richard Hally There is a bug in the init scripts that leaves /initrd mounted. If you umount this directory most of these messages will disappear. The screensaver ones should be fixed by -12 policy Not sure why gnome is trying to manipulate the registry.xml file. > > --------------------messages----------------------------- > Apr 5 22:37:25 localhost crond: crond startup succeeded > Apr 5 22:37:25 localhost kernel: audit(1081219045.889:0): avc: > denied { read > } for pid=1647 exe=/usr/sbin/crond name=mailman dev=hdc3 ino=539689 > scontext=system_u:system_r:crond_t tcontext=system_u:object_r:file_t > tclass=file > Apr 5 22:37:27 localhost xfs: xfs startup succeeded > > > Apr 5 22:38:04 localhost gdm(pam_unix)[1814]: session opened for user > richard by (uid=0) > Apr 5 22:38:19 localhost kernel: audit(1081219099.459:0): avc: > denied { setattr } for pid=1886 > exe=/usr/libexec/gnome-settings-daemon name=registry.xml dev=hdc3 > ino=3009195 scontext=richard:staff_r:staff_t > tcontext=system_u:object_r:var_t tclass=file > Apr 5 22:38:20 localhost kernel: audit(1081219100.136:0): avc: > denied { getattr } for pid=1901 exe=/usr/X11R6/bin/xscreensaver > path=/home/richard/.xscreensaver dev=hdc3 ino=2469233 > scontext=richard:staff_r:staff_screensaver_t > tcontext=richard:object_r:staff_home_t tclass=file > Apr 5 22:38:29 localhost kernel: audit(1081219109.860:0): avc: > denied { getattr } for pid=1955 exe=/usr/libexec/gnome-vfs-daemon > path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t > tcontext=system_u:object_r:file_t tclass=dir > Apr 5 22:38:30 localhost kernel: audit(1081219110.466:0): avc: > denied { getattr } for pid=1966 exe=/usr/bin/nautilus path=/initrd > dev=ram0 ino=2 scontext=richard:staff_r:staff_t > tcontext=system_u:object_r:file_t tclass=dir > Apr 5 22:38:30 localhost kernel: audit(1081219110.653:0): avc: > denied { getattr } for pid=1967 exe=/usr/bin/nautilus path=/initrd > dev=ram0 ino=2 scontext=richard:staff_r:staff_t > tcontext=system_u:object_r:file_t tclass=dir > Apr 5 22:38:37 localhost kernel: audit(1081219117.803:0): avc: > denied { setattr } for pid=1976 exe=/usr/libexec/mixer_applet2 > name=registry.xml dev=hdc3 ino=3009195 > scontext=richard:staff_r:staff_t tcontext=system_u:object_r:var_t tclas: > > -- > 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 Tue Apr 6 11:19:50 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 07:19:50 -0400 Subject: List of selinux issues In-Reply-To: <40725F4B.6050909@redhat.com> References: <40725F4B.6050909@redhat.com> Message-ID: <40729256.6080309@redhat.com> Warren Togami wrote: > This is my first time running with selinux enforcement enabled and > this system has been apt upgraded from FC2test1 to latest rawhide, so > please forgive me that some of these will be duplicates and others may > be errors. Please let me know which are not duplicates, and if you > want me to bugzilla them. > > To be clear, I did the following in order to ensure that my labels are > correct during runtime. I hope this was correct. > > setenforce off > fixfiles relabel > setenforce 1 > > > > 1) Infinite Loop of these messages when using "/sbin/ifup eth0" as > non-root user. This is allowed when enforcement is disabled. CTRL-C > is abled to stop the looping. > > Apr 5 21:07:28 ibmlaptop kernel: audit(1081235248.571:0): avc: > denied { setuid } for pid=2463 exe=/bin/bash capability=7 > scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t > tclass=capability > Apr 5 21:07:28 ibmlaptop kernel: audit(1081235248.589:0): avc: > denied { setuid } for pid=2463 exe=/usr/sbin/usernetctl capability=7 > scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t > tclass=capability > > I am not sure how you set this up to work. I execute /sbin/ifup eth0 and I get Users cannot control this device. If we want to allow this we will need policy to allow it. Any want to take a try at it? > 2) "su -" from my non-root user caused this error. I was however > allowed to work as root. > > Apr 5 21:07:42 ibmlaptop su(pam_unix)[12399]: session opened for user > root by warren(uid=500) > Apr 5 21:07:42 ibmlaptop su[12399]: pam_xauth: error creating > temporary file `/root/.xauthsDAz4e': Permission denied > Apr 5 21:07:42 ibmlaptop kernel: audit(1081235262.772:0): avc: > denied { write } for pid=12399 exe=/bin/su name=root dev=hda2 > ino=1291809 scontext=user_u:user_r:user_su_t > tcontext=root:object_r:staff_home_dir_t tclass=dir > > This should be fixed in latest policy 1.9.2-12 > 3) Then as root, I used "ifup eth0" which succeeded, but with the > following in /var/log/messages. > > Apr 5 21:07:45 ibmlaptop kernel: audit(1081235265.089:0): avc: > denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 > ino=1389922 scontext=root:system_r:dhcpc_t > tcontext=system_u:object_r:home_root_t tclass=dir > Apr 5 21:07:45 ibmlaptop kernel: audit(1081235265.089:0): avc: > denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 > ino=1389922 scontext=root:system_r:dhcpc_t > tcontext=system_u:object_r:home_root_t tclass=dir > Apr 5 21:07:45 ibmlaptop dhclient: can't create > /var/lib/dhcp/dhclient-eth0.leases: Permission denied > Apr 5 21:07:46 ibmlaptop dhclient: sit0: unknown hardware address > type 776 > Apr 5 21:07:48 ibmlaptop dhclient: DHCPDISCOVER on eth0 to > 255.255.255.255 port 67 interval 4 > Apr 5 21:07:48 ibmlaptop dhclient: DHCPOFFER from 172.31.16.1 > Apr 5 21:07:48 ibmlaptop dhclient: DHCPREQUEST on eth0 to > 255.255.255.255 port 67 > Apr 5 21:07:48 ibmlaptop dhclient: DHCPACK from 172.31.16.1 > Apr 5 21:07:48 ibmlaptop dhclient: can't create > /var/lib/dhcp/dhclient-eth0.leases: Permission denied > Apr 5 21:07:48 ibmlaptop dhclient: bound to 172.31.16.101 -- renewal > in 356918 seconds. > Apr 5 21:07:48 ibmlaptop kernel: audit(1081235268.039:0): avc: > denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 > ino=1389922 scontext=root:system_r:dhcpc_t > tcontext=system_u:object_r:home_root_t tclass=dir > Added policy to allow this , but not sure what it is trying todo. Could you try it in non-enforcing mode and grab the avc messages. > > 4) GNOME mixer_applet2 is unable to reach the device. Strangely this > began failing in permissive mode too, but it works when selinux is > totally disabled and not loaded. > > Apr 5 21:07:10 ibmlaptop kernel: audit(1081235230.797:0): avc: > denied { setattr } for pid=2435 exe=/usr/libexec/mixer_applet2 > name=registry.xml dev=hda2 ino=1425367 scontext=user_u:user_r:user_t > tcontext=system_u:object_r:var_t tclass=file > > This needs more investigation if it fails in permissive mode. > 5) This is vmware from the VMWare WS 4.5.1 service startup. The > issues are ... complicated, numerous, and scary looking. > > Apr 5 21:06:08 ibmlaptop kernel: vmmon: module license 'unspecified' > taints kernel. > Apr 5 21:06:08 ibmlaptop kernel: vmnet: module license 'unspecified' > taints kernel. > Apr 5 21:06:08 ibmlaptop kernel: audit(1081235168.858:0): avc: > denied { search } for pid=1909 exe=/usr/bin/vmnet-netifup name=net > dev= ino=344 scontext=system_u:system_r:vmware_t > tcontext=system_u:object_r:sysfs_t tclass=dir > Apr 5 21:06:08 ibmlaptop kernel: audit(1081235168.867:0): avc: > denied { search } for pid=1910 exe=/usr/bin/vmnet-netifup name=net > dev= ino=344 scontext=system_u:system_r:vmware_t > tcontext=system_u:object_r:sysfs_t tclass=dir > Apr 5 21:06:09 ibmlaptop kernel: audit(1081235169.047:0): avc: > denied { node_bind } for pid=1931 exe=/usr/bin/vmnet-natd > scontext=system_u:system_r:vmware_t > tcontext=system_u:object_r:node_inaddr_any_t tclass=rawip_socket > Apr 5 21:06:09 ibmlaptop kernel: audit(1081235169.048:0): avc: > denied { create } for pid=1931 exe=/usr/bin/vmnet-natd > name=vmnat.1931 scontext=system_u:system_r:vmware_t > tcontext=system_u:object_r:var_run_t tclass=sock_file > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Internet Software Consortium > DHCP Server 2.0 > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Copyright 1995, 1996, 1997, > 1998, 1999 The Internet Software Consortium. > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: All rights reserved. > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Please contribute if you find > this software useful. > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: For info, please visit > http://www.isc.org/dhcp-contrib.html > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Internet Software Consortium > DHCP Server 2.0 > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Copyright 1995, 1996, 1997, > 1998, 1999 The Internet Software Consortium. > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: All rights reserved. > > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Internet Software Consortium > DHCP Server 2.0 > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Copyright 1995, 1996, 1997, > 1998, 1999 The Internet Software Consortium. > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: All rights reserved. > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Configured subnet: 173.31.18.0 > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Please contribute if you find > this software useful. > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Setting vmnet-dhcp IP address: > 173.31.18.254 > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: For info, please visit > http://www.isc.org/dhcp-contrib.html > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: Recving on VNet/vmnet1/173.31.18.0 > Apr 5 21:06:09 ibmlaptop vmnet-dhcpd: > Apr 5 21:06:10 ibmlaptop vmnet-dhcpd: Sending on VNet/vmnet1/173.31.18.0 > Apr 5 21:06:11 ibmlaptop vmnet-dhcpd: Configured subnet: 173.31.17.0 > Apr 5 21:06:12 ibmlaptop vmnet-dhcpd: Setting vmnet-dhcp IP address: > 173.31.17.254 > Apr 5 21:06:12 ibmlaptop vmnet-dhcpd: Recving on VNet/vmnet8/173.31.17.0 > Apr 5 21:06:12 ibmlaptop vmnet-dhcpd: Sending on VNet/vmnet8/173.31.17.0 > Apr 5 21:06:15 ibmlaptop kernel: audit(1081235175.873:0): avc: > denied { create } for pid=2253 exe=/usr/bin/vmware-nmbd > scontext=system_u:system_r:vmware_t > tcontext=system_u:system_r:vmware_t tclass=udp_socket > Apr 5 21:06:15 ibmlaptop kernel: audit(1081235175.873:0): avc: > denied { create } for pid=2253 exe=/usr/bin/vmware-nmbd > scontext=system_u:system_r:vmware_t > tcontext=system_u:system_r:vmware_t tclass=udp_socket > Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.460:0): avc: > denied { read } for pid=2254 exe=/usr/bin/vmware-smbd name=urandom > dev=hda2 ino=1270748 scontext=system_u:system_r:vmware_t > tcontext=system_u:object_r:urandom_device_t tclass=chr_fileApr 5 > 21:06:16 ibmlaptop kernel: audit(1081235176.461:0): avc: denied { > read } for pid=2254 exe=/usr/bin/vmware-smbd name=shadow dev=hda2 > ino=1963867 scontext=system_u:system_r:vmware_t > tcontext=system_u:object_r:shadow_t tclass=file > Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.804:0): avc: > denied { setgid } for pid=2254 exe=/usr/bin/vmware-smbd capability=6 > scontext=system_u:system_r:vmware_t > tcontext=system_u:system_r:vmware_t tclass=capability > Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.804:0): avc: > denied { setgid } for pid=2254 exe=/usr/bin/vmware-smbd capability=6 > scontext=system_u:system_r:vmware_t > tcontext=system_u:system_r:vmware_t tclass=capability > Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.805:0): avc: > denied { setgid } for pid=2254 exe=/usr/bin/vmware-smbd capability=6 > scontext=system_u:system_r:vmware_t > tcontext=system_u:system_r:vmware_t tclass=capability > Apr 5 21:06:16 ibmlaptop last message repeated 2 times > Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.899:0): avc: > denied { read } for pid=2254 exe=/usr/bin/vmware-smbd name=printcap > dev=hda2 ino=1962265 scontext=system_u:system_r:vmware_t > tcontext=system_u:object_r:cupsd_rw_etc_t tclass=file > Apr 5 21:06:16 ibmlaptop kernel: audit(1081235176.899:0): avc: > denied { create } for pid=2254 exe=/usr/bin/vmware-smbd > scontext=system_u:system_r:vmware_t > tcontext=system_u:system_r:vmware_t tclass=udp_socket Apr 5 21:06:17 > ibmlaptop kernel: audit(1081235177.041:0): avc: denied { > sys_resource } for pid=2254 exe=/usr/bin/vmware-smbd capability=24 > scontext=system_u:system_r:vmware_t > tcontext=system_u:system_r:vmware_t tclass=capability > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From 13640887 at sun.ac.za Tue Apr 6 13:02:12 2004 From: 13640887 at sun.ac.za (Albert Strasheim) Date: Tue, 6 Apr 2004 15:02:12 +0200 Subject: Success with Gaussian03 Message-ID: <20040406130212.GB7452@dogbert.sdsl.sun.ac.za> Hello all, Not sure if this should go to fedora-test-list instead, but here goes... I have successfully managed to get Gaussian03 (commercial software for computation chemistry) going on FC2 test2. Here's a quick HOWTO: 1. Extract the LI2-800N.taz file provided by Gaussian, Inc. to /opt/g03. This is the x86 binary distribution of Gaussian03. 2. Gaussian03 won't run if its files are world readable, so create a seperate group for Gaussian03 users: /usr/sbin/groupadd -r g03 /usr/bin/gpasswd -a myuser g03 3. Set up the permissions on the Gaussian03 files: chown -R root.g03 /opt/g03 chmod -R a+rX /opt/g03 chmod -R o-rwx /opt/g03 4. Set the SELinux security context for the Gaussian03 files: chcon -t bin_t `find /opt/g03 -perm +111 -type f` (Modified command from the comment in bug 120140. Is this right?) Now Gaussian03 can be run by any user in the g03 group (provided he/she sets the g03root environment variable and sources the necessary file from /opt/g03/bsd). Cheers, Albert Strasheim From dac at tresys.com Tue Apr 6 13:15:23 2004 From: dac at tresys.com (David Caplan) Date: Tue, 06 Apr 2004 09:15:23 -0400 Subject: Not good In-Reply-To: <4071CB69.1050203@redhat.com> References: <200404011728.15051.gene@czarc.net> <406ED26F.3070501@nc.rr.com> <200404051127.27126.gene@czarc.net> <4071CB69.1050203@redhat.com> Message-ID: <4072AD6B.1090207@tresys.com> Daniel J Walsh wrote: > Gene Czarcinski wrote: > >> >> I do believe that the policy packages needs some work: >> >> 1. Cannot be built in a private build tree (this possibly caused the >> "policy." problem which is fixed in 1.9.2-11 ... we will see if it >> builds in the private tree by a regular user). >> >> > This is a bug caused by the user being unable to read policy_config_t > files (file_context) > I'm not sure I see what the "bug" is here. A "regular user" should not be building the policy for a system. A user should be able to build a private copy of the policy (eg, for testing, analysis, etc), but these files should have regular user file labels (i.e., *not* policy_config_t or policy_src_t). Any user/domain should be able to run checkpolicy, but much thought and consideration needs to be given as to which domains may run checkpolicy in the checkpolicy_t domain. Maybe I'm reading too much into this? David -- __________________________________ David Caplan 410 290 1411 x105 dac at tresys.com Tresys Technology, LLC 8840 Stanford Blvd., Suite 2100 Columbia, MD 21045 From 1 at 234.cx Tue Apr 6 13:38:53 2004 From: 1 at 234.cx (Pete Chown) Date: Tue, 06 Apr 2004 14:38:53 +0100 Subject: SELinux and ReiserFS In-Reply-To: References: Message-ID: <4072B2ED.8030809@234.cx> James Morris wrote: > The patch must be acceptable upstream, in the mainline kernel. As I understand it, Hans Reiser has indicated that he will only accept bugfixes for reiser3. It is therefore very unlikely that anyone could come up with a patch which would be merged upstream. Reiser4 will support file metadata from the beginning, but of course it's not available yet. I realised, though, that I don't really need to build a custom kernel. All I need to make is one module ("sereiserfs") which I then load into the normal kernel. I should be able to build that using the normal RedHat kernel source plus the SuSE patch. Assuming it works as expected, I'll announce it here for the benefit of anyone else who wants to use reiserfs. I'm unlikely to build it until FC2 is actually released though. > It is labeled at the kernel level (like genfs mounts), SELinux controls > work normally, and root cannot do anything special that could not be done > with an xattr filesystem. So is the idea that the whole filesystem gets the same label? That sounds useful in some circumstances, but building a new reiserfs module is more *fun*. :-) Pete From nico33b at yahoo.fr Tue Apr 6 13:43:26 2004 From: nico33b at yahoo.fr (=?iso-8859-1?q?Nic=A4?=) Date: Tue, 6 Apr 2004 09:43:26 -0400 (EDT) Subject: Creating new users and roles Message-ID: <20040406134326.75206.qmail@web40912.mail.yahoo.com> Hello, is there a different way to add new users and roles that creating them in the /etc/security/selinux/src/policy/users file and recompiling the policy ? thanks Nico. __________________________________________________________ L?che-vitrine ou l?che-?cran ? magasinage.yahoo.ca From jmorris at redhat.com Tue Apr 6 13:45:24 2004 From: jmorris at redhat.com (James Morris) Date: Tue, 6 Apr 2004 09:45:24 -0400 (EDT) Subject: SELinux and ReiserFS In-Reply-To: <4072B2ED.8030809@234.cx> Message-ID: On Tue, 6 Apr 2004, Pete Chown wrote: > > It is labeled at the kernel level (like genfs mounts), SELinux controls > > work normally, and root cannot do anything special that could not be done > > with an xattr filesystem. > > So is the idea that the whole filesystem gets the same label? Yes. - James -- James Morris From pauln at truemesh.com Tue Apr 6 13:38:58 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 6 Apr 2004 13:38:58 +0000 Subject: SELinux and ReiserFS In-Reply-To: References: <4072B2ED.8030809@234.cx> Message-ID: <20040406133857.GT23468@lichen.truemesh.com> On Tue, Apr 06, 2004 at 09:45:24AM -0400, James Morris wrote: > On Tue, 6 Apr 2004, Pete Chown wrote: > > > > It is labeled at the kernel level (like genfs mounts), SELinux controls > > > work normally, and root cannot do anything special that could not be done > > > with an xattr filesystem. > > > > So is the idea that the whole filesystem gets the same label? > > Yes. Out of curiosity how does this work with bind mounts, can you use context with a bind mount? Paul From cra at WPI.EDU Tue Apr 6 13:57:28 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 6 Apr 2004 09:57:28 -0400 Subject: List of selinux issues In-Reply-To: <40729256.6080309@redhat.com> References: <40725F4B.6050909@redhat.com> <40729256.6080309@redhat.com> Message-ID: <20040406135728.GD12722@angus.ind.WPI.EDU> On Tue, Apr 06, 2004 at 07:19:50AM -0400, Daniel J Walsh wrote: > >Apr 5 21:07:45 ibmlaptop dhclient: can't create > >/var/lib/dhcp/dhclient-eth0.leases: Permission denied > Added policy to allow this , but not sure what it is trying todo. Could > you try it in non-enforcing mode and grab the avc messages. dhclient needs to search/read/write /var/lib/dhcp/dhclient* so it can store the client leases there. From twaugh at redhat.com Tue Apr 6 14:02:46 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 6 Apr 2004 15:02:46 +0100 Subject: List of selinux issues In-Reply-To: <20040406135728.GD12722@angus.ind.WPI.EDU> References: <40725F4B.6050909@redhat.com> <40729256.6080309@redhat.com> <20040406135728.GD12722@angus.ind.WPI.EDU> Message-ID: <20040406140245.GO22468@redhat.com> On Tue, Apr 06, 2004 at 09:57:28AM -0400, Charles R. Anderson wrote: > On Tue, Apr 06, 2004 at 07:19:50AM -0400, Daniel J Walsh wrote: > > >Apr 5 21:07:45 ibmlaptop dhclient: can't create > > >/var/lib/dhcp/dhclient-eth0.leases: Permission denied > > > Added policy to allow this , but not sure what it is trying todo. Could > > you try it in non-enforcing mode and grab the avc messages. > > dhclient needs to search/read/write /var/lib/dhcp/dhclient* so it can > store the client leases there. The reason this failed in the first place is that the dhcp{c,d}.te file_context files were messing with m4 macros and getting unexpected results. You can fix it with: chcon system_u:object_r:dhcpd_state_t /var/lib/dhcp/dhcp.leases* 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 Tue Apr 6 14:42:19 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 10:42:19 -0400 Subject: Creating new users and roles In-Reply-To: <20040406134326.75206.qmail@web40912.mail.yahoo.com> References: <20040406134326.75206.qmail@web40912.mail.yahoo.com> Message-ID: <4072C1CB.7000706@redhat.com> Nic? wrote: >Hello, > >is there a different way to add new users and roles >that creating them in the >/etc/security/selinux/src/policy/users file and >recompiling the policy ? > >thanks > >Nico. > > No > > > > >__________________________________________________________ >L?che-vitrine ou l?che-?cran ? >magasinage.yahoo.ca >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From jmorris at redhat.com Tue Apr 6 14:49:52 2004 From: jmorris at redhat.com (James Morris) Date: Tue, 6 Apr 2004 10:49:52 -0400 (EDT) Subject: SELinux and ReiserFS In-Reply-To: <20040406133857.GT23468@lichen.truemesh.com> Message-ID: On Tue, 6 Apr 2004, Paul Nasrat wrote: > > > > work normally, and root cannot do anything special that could not be done > > > > with an xattr filesystem. > > > > > > So is the idea that the whole filesystem gets the same label? > > > > Yes. > > Out of curiosity how does this work with bind mounts, can you use context with a bind mount? Bind mounts ignore context options. - James -- James Morris From walters at redhat.com Tue Apr 6 13:53:47 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 06 Apr 2004 09:53:47 -0400 Subject: List of selinux issues In-Reply-To: <40725F4B.6050909@redhat.com> References: <40725F4B.6050909@redhat.com> Message-ID: <1081259626.7293.1.camel@nexus.verbum.private> On Tue, 2004-04-06 at 03:42, Warren Togami wrote: > 4) GNOME mixer_applet2 is unable to reach the device. Strangely this > began failing in permissive mode too, but it works when selinux is > totally disabled and not loaded. > > Apr 5 21:07:10 ibmlaptop kernel: audit(1081235230.797:0): avc: denied > { setattr } for pid=2435 exe=/usr/libexec/mixer_applet2 > name=registry.xml dev=hda2 ino=1425367 scontext=user_u:user_r:user_t > tcontext=system_u:object_r:var_t tclass=file Fixed in gstreamer-0.8.0-4. -------------- 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 Apr 6 15:01:44 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 11:01:44 -0400 Subject: Not good In-Reply-To: <4072AD6B.1090207@tresys.com> References: <200404011728.15051.gene@czarc.net> <406ED26F.3070501@nc.rr.com> <200404051127.27126.gene@czarc.net> <4071CB69.1050203@redhat.com> <4072AD6B.1090207@tresys.com> Message-ID: <4072C658.2090803@redhat.com> David Caplan wrote: > Daniel J Walsh wrote: > >> Gene Czarcinski wrote: >> >>> >>> I do believe that the policy packages needs some work: >>> >>> 1. Cannot be built in a private build tree (this possibly caused the >>> "policy." problem which is fixed in 1.9.2-11 ... we will see if it >>> builds in the private tree by a regular user). >>> >>> >> This is a bug caused by the user being unable to read policy_config_t >> files (file_context) >> > > I'm not sure I see what the "bug" is here. A "regular user" should > not be building the policy for a system. A user should be able to > build a private copy of the policy (eg, for testing, analysis, etc), > but these files should have regular user file labels (i.e., *not* > policy_config_t or policy_src_t). Any user/domain should be able to > run checkpolicy, but much thought and consideration needs to be given > as to which domains may run checkpolicy in the checkpolicy_t domain. > Maybe I'm reading too much into this? > > David > I don't believe that is what the user was complaining about. The problem is that when you build any rpm, it tries to read /etc/security/selinux/file_contexts which is marked policy_config_t. Rpm is storing the file_contexts of files in its headers. The current policy-1.9.2-12 allows users to read this, problem is that rpm needs to then check if the security contexts are valid. So they need can_getsecurity defined. This has been updated for policy-1.9.2-13 (Available on people). This is being governed by the user_canbe_sysadm tunable. If you turn this off only staff_u would be able to do it. Normal users running checkpolicy would still require the can_setenforce and maybe some other privs. Dan From n3npq at nc.rr.com Tue Apr 6 15:23:00 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 06 Apr 2004 11:23:00 -0400 Subject: Not good In-Reply-To: <4072C658.2090803@redhat.com> References: <200404011728.15051.gene@czarc.net> <406ED26F.3070501@nc.rr.com> <200404051127.27126.gene@czarc.net> <4071CB69.1050203@redhat.com> <4072AD6B.1090207@tresys.com> <4072C658.2090803@redhat.com> Message-ID: <4072CB54.2010101@nc.rr.com> Daniel J Walsh wrote: > I don't believe that is what the user was complaining about. The > problem is that when you build any rpm, it tries to read > /etc/security/selinux/file_contexts which is marked policy_config_t. > Rpm is storing the file_contexts of files in its headers. The current > policy-1.9.2-12 allows users to read this, problem is that rpm needs > to then check if the security contexts are valid. So they need > can_getsecurity defined. This has been updated for policy-1.9.2-13 > (Available on people). This is being governed by the > user_canbe_sysadm tunable. If you turn this off only staff_u would be > able to do it. > > Normal users running checkpolicy would still require the > can_setenforce and maybe some other privs. The path to the file context RE's is configurable for rpmbuild as well, there is no reason whatsoever that the path cannot be changed to something else if/when the time comes. In fact, policy for package builds is likely to be different than policy for the build system in almost every case. 73 de Jeff From gene at czarc.net Tue Apr 6 16:49:18 2004 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 6 Apr 2004 12:49:18 -0400 Subject: /sbin/service and /usr/sbin/run_init Message-ID: <200404061249.18321.gene@czarc.net> The various selinux documentation states that /usr/sbin/run_init should be used to start the various scripts in /etc/init.d/ to ensure that that have the correct selinux charactertics. I notice that service does not use run_init. Is this a problem? Gene From rhally at mindspring.com Tue Apr 6 16:53:04 2004 From: rhally at mindspring.com (Richard Hally) Date: Tue, 06 Apr 2004 12:53:04 -0400 Subject: avc denied messages from boot In-Reply-To: <4072900C.5030207@redhat.com> References: <40721C76.2080609@mindspring.com> <4072900C.5030207@redhat.com> Message-ID: <4072E070.7010808@mindspring.com> Daniel J Walsh wrote: > Richard Hally wrote: > >> when booting to runlevel 5 in enforcing mode with the latest policy >> there were only a few AVC denied messages. they are copied below. >> [root at localhost root]# rpm -q policy policy-sources >> policy-1.9.2-10 >> policy-sources-1.9.2-10 >> [root at localhost root]# >> >> Hope this helps, >> Richard Hally > > > There is a bug in the init scripts that leaves /initrd mounted. If > you umount this directory most of these messages will disappear. > > The screensaver ones should be fixed by -12 policy > > Not sure why gnome is trying to manipulate the registry.xml file. > > >> >> --------------------messages----------------------------- >> Apr 5 22:37:25 localhost crond: crond startup succeeded >> Apr 5 22:37:25 localhost kernel: audit(1081219045.889:0): avc: >> denied { read >> } for pid=1647 exe=/usr/sbin/crond name=mailman dev=hdc3 ino=539689 >> scontext=system_u:system_r:crond_t tcontext=system_u:object_r:file_t >> tclass=file >> Apr 5 22:37:27 localhost xfs: xfs startup succeeded >> >> >> Apr 5 22:38:04 localhost gdm(pam_unix)[1814]: session opened for >> user richard by (uid=0) >> Apr 5 22:38:19 localhost kernel: audit(1081219099.459:0): avc: >> denied { setattr } for pid=1886 >> exe=/usr/libexec/gnome-settings-daemon name=registry.xml dev=hdc3 >> ino=3009195 scontext=richard:staff_r:staff_t >> tcontext=system_u:object_r:var_t tclass=file >> Apr 5 22:38:20 localhost kernel: audit(1081219100.136:0): avc: >> denied { getattr } for pid=1901 exe=/usr/X11R6/bin/xscreensaver >> path=/home/richard/.xscreensaver dev=hdc3 ino=2469233 >> scontext=richard:staff_r:staff_screensaver_t >> tcontext=richard:object_r:staff_home_t tclass=file >> Apr 5 22:38:29 localhost kernel: audit(1081219109.860:0): avc: >> denied { getattr } for pid=1955 exe=/usr/libexec/gnome-vfs-daemon >> path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t >> tcontext=system_u:object_r:file_t tclass=dir >> Apr 5 22:38:30 localhost kernel: audit(1081219110.466:0): avc: >> denied { getattr } for pid=1966 exe=/usr/bin/nautilus path=/initrd >> dev=ram0 ino=2 scontext=richard:staff_r:staff_t >> tcontext=system_u:object_r:file_t tclass=dir >> Apr 5 22:38:30 localhost kernel: audit(1081219110.653:0): avc: >> denied { getattr } for pid=1967 exe=/usr/bin/nautilus path=/initrd >> dev=ram0 ino=2 scontext=richard:staff_r:staff_t >> tcontext=system_u:object_r:file_t tclass=dir >> Apr 5 22:38:37 localhost kernel: audit(1081219117.803:0): avc: >> denied { setattr } for pid=1976 exe=/usr/libexec/mixer_applet2 >> name=registry.xml dev=hdc3 ino=3009195 >> scontext=richard:staff_r:staff_t tcontext=system_u:object_r:var_t tclas: >> >> -- >> 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 > Thanks Dan! you and the other people working on SELinux are making great progress. It looks like really will happen :) Richard Hally From dwalsh at redhat.com Tue Apr 6 17:56:14 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 13:56:14 -0400 Subject: [Fwd: Re: Not good] Message-ID: <4072EF3E.5050404@redhat.com> -------------- next part -------------- An embedded message was scrubbed... From: Daniel J Walsh Subject: Re: Not good Date: Tue, 06 Apr 2004 13:55:31 -0400 Size: 2201 URL: From dwalsh at redhat.com Tue Apr 6 18:06:14 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 14:06:14 -0400 Subject: nsupdate and netlink_socket AVCs In-Reply-To: <40512DDC.9090503@nogin.org> References: <4050958B.50201@nogin.org> <4050D7B3.9050205@redhat.com> <40512DDC.9090503@nogin.org> Message-ID: <4072F196.10101@redhat.com> Aleksey Nogin wrote: > On 11.03.2004 13:18, Daniel J Walsh wrote: > >> Is nsupdate a program to be run by an ordinary user? > > > Yes. But if I understand correctly, it only needs to communicate over > UDP or TCP to a DNS server from an unprivileged port. I do not know > why it wants netlink_sockets. > >> If yes we need to define a security context for nsupdate to allow it >> to access the netlink_sockets. > > > Are you sure? _Why_ does nsupdate need it? Is it not an nsupdate > deficiency? Probably. From dwalsh at redhat.com Tue Apr 6 18:07:56 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 14:07:56 -0400 Subject: /sbin/service and /usr/sbin/run_init In-Reply-To: <200404061249.18321.gene@czarc.net> References: <200404061249.18321.gene@czarc.net> Message-ID: <4072F1FC.1060600@redhat.com> Gene Czarcinski wrote: >The various selinux documentation states that /usr/sbin/run_init should be >used to start the various scripts in /etc/init.d/ to ensure that that have >the correct selinux charactertics. > >I notice that service does not use run_init. Is this a problem? > >Gene > > No we found that using run_init was far too confusing, so we added auto transition rules so sysadm, or rpm are allowed to transition initrc programs to their proper state. There is a tunable to turn this off if you want to go back to using run_init, I believe. >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From gene at czarc.net Tue Apr 6 18:17:12 2004 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 6 Apr 2004 14:17:12 -0400 Subject: /sbin/service and /usr/sbin/run_init In-Reply-To: <4072F1FC.1060600@redhat.com> References: <200404061249.18321.gene@czarc.net> <4072F1FC.1060600@redhat.com> Message-ID: <200404061417.12145.gene@czarc.net> On Tuesday 06 April 2004 14:07, Daniel J Walsh wrote: > No we found that using run_init was far too confusing, so we added auto > transition rules > so sysadm, or rpm are allowed to transition initrc programs to their > proper state. > > There is a tunable to turn this off if you want to go back to using > run_init, I believe. No, no! In fact, do you need run_init at all? Gene From sds at epoch.ncsc.mil Tue Apr 6 18:25:31 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 06 Apr 2004 14:25:31 -0400 Subject: /sbin/service and /usr/sbin/run_init In-Reply-To: <200404061249.18321.gene@czarc.net> References: <200404061249.18321.gene@czarc.net> Message-ID: <1081275931.30082.6.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-04-06 at 12:49, Gene Czarcinski wrote: > The various selinux documentation states that /usr/sbin/run_init should be > used to start the various scripts in /etc/init.d/ to ensure that that have > the correct selinux charactertics. > > I notice that service does not use run_init. Is this a problem? The direct_sysadm_daemon tunable in tunable.te allows direct transitions upon executing /etc/init.d scripts or daemons from an admin shell, so that you don't have to use run_init if that tunable is set. There is a tradeoff in security vs. useability. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Apr 6 19:07:21 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 15:07:21 -0400 Subject: nsupdate and netlink_socket AVCs In-Reply-To: <4072F196.10101@redhat.com> References: <4050958B.50201@nogin.org> <4050D7B3.9050205@redhat.com> <40512DDC.9090503@nogin.org> <4072F196.10101@redhat.com> Message-ID: <4072FFE9.6040904@redhat.com> Daniel J Walsh wrote: > Aleksey Nogin wrote: > >> On 11.03.2004 13:18, Daniel J Walsh wrote: >> >>> Is nsupdate a program to be run by an ordinary user? >> >> >> >> Yes. But if I understand correctly, it only needs to communicate over >> UDP or TCP to a DNS server from an unprivileged port. I do not know >> why it wants netlink_sockets. >> >>> If yes we need to define a security context for nsupdate to allow it >>> to access the netlink_sockets. >> >> >> >> Are you sure? _Why_ does nsupdate need it? Is it not an nsupdate >> deficiency? > nsupdate does the following which looks suspicious. result = isc_net_probeipv4(); if (result == ISC_R_SUCCESS) have_ipv4 = ISC_TRUE; How does one use nsupdate? I just ran it and it came back with a > prompt. Dan > > Probably. > -- > 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 Tue Apr 6 19:08:04 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 15:08:04 -0400 Subject: /sbin/service and /usr/sbin/run_init In-Reply-To: <200404061417.12145.gene@czarc.net> References: <200404061249.18321.gene@czarc.net> <4072F1FC.1060600@redhat.com> <200404061417.12145.gene@czarc.net> Message-ID: <40730014.4040001@redhat.com> Gene Czarcinski wrote: >On Tuesday 06 April 2004 14:07, Daniel J Walsh wrote: > > >>No we found that using run_init was far too confusing, so we added auto >>transition rules >>so sysadm, or rpm are allowed to transition initrc programs to their >>proper state. >> >>There is a tunable to turn this off if you want to go back to using >>run_init, I believe. >> >> > >No, no! In fact, do you need run_init at all? > > No not with this policy. >Gene > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From m.schmiderer at web.de Tue Apr 6 19:13:00 2004 From: m.schmiderer at web.de (Martin Schmiderer) Date: Tue, 6 Apr 2004 21:13:00 +0200 Subject: /etc/sysconfig/selinux Message-ID: <200404062113.00183.m.schmiderer@web.de> Hello *, i start the installation of fc2t2 with selinux in permissive mode. Later on after i get the newest updates i try to set selinux to enforcing in /etc/sysconfig/selinux. After reboot dmesg |grep -i selinux tells me that selinx runs in permissive mode. Ok, whats happen... i append enforcing=1 on the grub cmd. That works fine. So why does it nothing do if i try to set enforcing in /etc/sysconfig/selinux??? Thanks for this good job in fc2t2 ;-) (and excuse me for my bad english). greetz, Martin From dwalsh at redhat.com Tue Apr 6 19:21:34 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 15:21:34 -0400 Subject: /etc/sysconfig/selinux In-Reply-To: <200404062113.00183.m.schmiderer@web.de> References: <200404062113.00183.m.schmiderer@web.de> Message-ID: <4073033E.2070406@redhat.com> Martin Schmiderer wrote: >Hello *, > >i start the installation of fc2t2 with selinux in permissive mode. Later on >after i get the newest updates i try to set selinux to enforcing >in /etc/sysconfig/selinux. >After reboot dmesg |grep -i selinux tells me that selinx runs in permissive >mode. Ok, whats happen... i append enforcing=1 on the grub cmd. That works >fine. >So why does it nothing do if i try to set enforcing >in /etc/sysconfig/selinux??? > >Thanks for this good job in fc2t2 ;-) (and excuse me for my bad english). > >greetz, > > > What does your /etc/sysconfig/selinux file look like? Dan > Martin >-- >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 Tue Apr 6 19:22:17 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Apr 2004 15:22:17 -0400 Subject: /etc/sysconfig/selinux In-Reply-To: <200404062113.00183.m.schmiderer@web.de> References: <200404062113.00183.m.schmiderer@web.de> Message-ID: <40730369.6080209@redhat.com> Martin Schmiderer wrote: >Hello *, > >i start the installation of fc2t2 with selinux in permissive mode. Later on >after i get the newest updates i try to set selinux to enforcing >in /etc/sysconfig/selinux. >After reboot dmesg |grep -i selinux tells me that selinx runs in permissive >mode. Ok, whats happen... i append enforcing=1 on the grub cmd. That works >fine. >So why does it nothing do if i try to set enforcing >in /etc/sysconfig/selinux??? > >Thanks for this good job in fc2t2 ;-) (and excuse me for my bad english). > >greetz, > > Also getenforce returns this info. > Martin >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From cra at WPI.EDU Tue Apr 6 19:27:52 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 6 Apr 2004 15:27:52 -0400 Subject: nsupdate and netlink_socket AVCs In-Reply-To: <4072FFE9.6040904@redhat.com> References: <4050958B.50201@nogin.org> <4050D7B3.9050205@redhat.com> <40512DDC.9090503@nogin.org> <4072F196.10101@redhat.com> <4072FFE9.6040904@redhat.com> Message-ID: <20040406192752.GN6142@angus.ind.WPI.EDU> On Tue, Apr 06, 2004 at 03:07:21PM -0400, Daniel J Walsh wrote: > nsupdate does the following which looks suspicious. > > result = isc_net_probeipv4(); > if (result == ISC_R_SUCCESS) > have_ipv4 = ISC_TRUE; That looks like it is trying to see if IPv4 is available. > How does one use nsupdate? > > I just ran it and it came back with a > > > prompt. You give it commands to remotely update the BIND nameserver zone, such as: > update add myhost.mydomain.com 86400 A a.b.c.d > <--- blank line, very important!!! > ^D From warren at togami.com Tue Apr 6 22:51:45 2004 From: warren at togami.com (Warren Togami) Date: Tue, 06 Apr 2004 12:51:45 -1000 Subject: List of selinux issues In-Reply-To: <40729256.6080309@redhat.com> References: <40725F4B.6050909@redhat.com> <40729256.6080309@redhat.com> Message-ID: <40733481.1020303@togami.com> Daniel J Walsh wrote: >> 1) Infinite Loop of these messages when using "/sbin/ifup eth0" as >> non-root user. This is allowed when enforcement is disabled. CTRL-C >> is abled to stop the looping. >> >> Apr 5 21:07:28 ibmlaptop kernel: audit(1081235248.571:0): avc: >> denied { setuid } for pid=2463 exe=/bin/bash capability=7 >> scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t >> tclass=capability >> Apr 5 21:07:28 ibmlaptop kernel: audit(1081235248.589:0): avc: >> denied { setuid } for pid=2463 exe=/usr/sbin/usernetctl capability=7 >> scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t >> tclass=capability >> >> > I am not sure how you set this up to work. I execute /sbin/ifup eth0 > and I get > Users cannot control this device. > /etc/sysconfig/network-scripts/ifcfg-eth0 must contain USERCTL=yes >> 2) "su -" from my non-root user caused this error. I was however >> allowed to work as root. >> >> Apr 5 21:07:42 ibmlaptop su(pam_unix)[12399]: session opened for user >> root by warren(uid=500) >> Apr 5 21:07:42 ibmlaptop su[12399]: pam_xauth: error creating >> temporary file `/root/.xauthsDAz4e': Permission denied >> Apr 5 21:07:42 ibmlaptop kernel: audit(1081235262.772:0): avc: >> denied { write } for pid=12399 exe=/bin/su name=root dev=hda2 >> ino=1291809 scontext=user_u:user_r:user_su_t >> tcontext=root:object_r:staff_home_dir_t tclass=dir >> >> > This should be fixed in latest policy 1.9.2-12 policy-1.9.2-12 I relabeled after upgrading to this version immediately before the above denied errors happened. > >> 3) Then as root, I used "ifup eth0" which succeeded, but with the >> following in /var/log/messages. >> >> Apr 5 21:07:45 ibmlaptop kernel: audit(1081235265.089:0): avc: >> denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 >> ino=1389922 scontext=root:system_r:dhcpc_t >> tcontext=system_u:object_r:home_root_t tclass=dir >> Apr 5 21:07:45 ibmlaptop kernel: audit(1081235265.089:0): avc: >> denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 >> ino=1389922 scontext=root:system_r:dhcpc_t >> tcontext=system_u:object_r:home_root_t tclass=dir >> Apr 5 21:07:45 ibmlaptop dhclient: can't create >> /var/lib/dhcp/dhclient-eth0.leases: Permission denied >> Apr 5 21:07:46 ibmlaptop dhclient: sit0: unknown hardware address >> type 776 >> Apr 5 21:07:48 ibmlaptop dhclient: DHCPDISCOVER on eth0 to >> 255.255.255.255 port 67 interval 4 >> Apr 5 21:07:48 ibmlaptop dhclient: DHCPOFFER from 172.31.16.1 >> Apr 5 21:07:48 ibmlaptop dhclient: DHCPREQUEST on eth0 to >> 255.255.255.255 port 67 >> Apr 5 21:07:48 ibmlaptop dhclient: DHCPACK from 172.31.16.1 >> Apr 5 21:07:48 ibmlaptop dhclient: can't create >> /var/lib/dhcp/dhclient-eth0.leases: Permission denied >> Apr 5 21:07:48 ibmlaptop dhclient: bound to 172.31.16.101 -- renewal >> in 356918 seconds. >> Apr 5 21:07:48 ibmlaptop kernel: audit(1081235268.039:0): avc: >> denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 >> ino=1389922 scontext=root:system_r:dhcpc_t >> tcontext=system_u:object_r:home_root_t tclass=dir >> > Added policy to allow this , but not sure what it is trying todo. Could > you try it in non-enforcing mode and grab the avc messages. > Apr 6 12:49:06 ibmlaptop kernel: audit(1081291746.752:0): avc: denied { search } for pid=14826 exe=/sbin/dhclient name=lib dev=hda2 ino=1389922 scontext=root:system_r:dhcpc_t tcontext=system_u:object_r:home_root_t tclass=dir Apr 6 12:49:06 ibmlaptop kernel: audit(1081291746.919:0): avc: denied { getattr } for pid=14837 exe=/bin/gawk path=/dev/pts/6 dev= ino=8 scontext=root:system_r:dhcpc_t tcontext=root:object_r:sysadm_devpts_t tclass=chr_file Apr 6 12:49:10 ibmlaptop dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Apr 6 12:49:10 ibmlaptop dhclient: DHCPACK from 172.31.16.1 Apr 6 12:49:10 ibmlaptop dhclient: bound to 172.31.16.101 -- renewal in 379377 seconds. From wtogami at redhat.com Tue Apr 6 23:15:07 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Apr 2004 13:15:07 -1000 Subject: cups package upgrade Message-ID: <407339FB.2020704@redhat.com> Apr 6 13:11:20 ibmlaptop cups: cupsd shutdown succeeded Apr 6 13:11:20 ibmlaptop kernel: audit(1081293080.182:0): avc: denied { read } for pid=15075 exe=/usr/sbin/cupsd path=pipe:[20082] dev= ino=20082 scontext=root:system_r:cupsd_t tcontext=root:sysadm_r:rpm_t tclass=fifo_file Apr 6 13:11:21 ibmlaptop cups: cupsd startup succeeded During cups package upgrade with enforcement enabled. Warren From twaugh at redhat.com Wed Apr 7 08:39:16 2004 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 7 Apr 2004 09:39:16 +0100 Subject: cups package upgrade In-Reply-To: <407339FB.2020704@redhat.com> References: <407339FB.2020704@redhat.com> Message-ID: <20040407083916.GT22468@redhat.com> On Tue, Apr 06, 2004 at 01:15:07PM -1000, Warren Togami wrote: > Apr 6 13:11:20 ibmlaptop cups: cupsd shutdown succeeded > Apr 6 13:11:20 ibmlaptop kernel: audit(1081293080.182:0): avc: denied > { read } for pid=15075 exe=/usr/sbin/cupsd path=pipe:[20082] dev= > ino=20082 scontext=root:system_r:cupsd_t tcontext=root:sysadm_r:rpm_t > tclass=fifo_file > Apr 6 13:11:21 ibmlaptop cups: cupsd startup succeeded > > During cups package upgrade with enforcement enabled. Not really sure what's causing that. Could it be that printconf-backend (/usr/share/printconf/util/backend.py) parses the output of /usr/sbin/alternatives --display print? 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 Wed Apr 7 11:21:09 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 07 Apr 2004 07:21:09 -0400 Subject: cups package upgrade In-Reply-To: <20040407083916.GT22468@redhat.com> References: <407339FB.2020704@redhat.com> <20040407083916.GT22468@redhat.com> Message-ID: <4073E425.7010606@redhat.com> Tim Waugh wrote: >On Tue, Apr 06, 2004 at 01:15:07PM -1000, Warren Togami wrote: > > > >>Apr 6 13:11:20 ibmlaptop cups: cupsd shutdown succeeded >>Apr 6 13:11:20 ibmlaptop kernel: audit(1081293080.182:0): avc: denied >> { read } for pid=15075 exe=/usr/sbin/cupsd path=pipe:[20082] dev= >>ino=20082 scontext=root:system_r:cupsd_t tcontext=root:sysadm_r:rpm_t >>tclass=fifo_file >>Apr 6 13:11:21 ibmlaptop cups: cupsd startup succeeded >> >>During cups package upgrade with enforcement enabled. >> >> > >Not really sure what's causing that. Could it be that >printconf-backend (/usr/share/printconf/util/backend.py) parses the >output of /usr/sbin/alternatives --display print? > >Tim. >*/ > > I put a fix in today's policy for this. rpm is execing cups during the install, and I think that is causeing this problem. Dan >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From russell at coker.com.au Sat Apr 10 05:02:05 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 10 Apr 2004 15:02:05 +1000 Subject: /sbin/service and /usr/sbin/run_init In-Reply-To: <200404061417.12145.gene@czarc.net> References: <200404061249.18321.gene@czarc.net> <4072F1FC.1060600@redhat.com> <200404061417.12145.gene@czarc.net> Message-ID: <200404101502.05028.russell@coker.com.au> On Wed, 7 Apr 2004 04:17, Gene Czarcinski wrote: > On Tuesday 06 April 2004 14:07, Daniel J Walsh wrote: > > No we found that using run_init was far too confusing, so we added auto > > transition rules > > so sysadm, or rpm are allowed to transition initrc programs to their > > proper state. > > > > There is a tunable to turn this off if you want to go back to using > > run_init, I believe. > > No, no! In fact, do you need run_init at all? That depends on what your aims are. Some daemons require write access to a terminal to allow them to start correctly, other daemons will start without terminal access but display useful error messages to stdout if it's available. It's generally not desirable to permit all daemons to access the administrator tty all the time (if a daemon has { read write ioctl } access to an admin tty then it shouldn't be difficult for an attacker who takes over the daemon to then take over the entire system). In Debian I made run_init open a new pty for the daemon start process so that the daemon could be permitted to write startup messages and afterwards the master end of the pty would be closed denying the daemon any access to do bad things. I have concluded that this isn't the ideal way of doing it as there are some problems with signals in the case where the parent exits before the child (the actual daemon process) closes it's tty. I think that the best way of doing this for strong security is to have run_init relabel it's controlling tty before spawning the daemon, and then label it back after the child exits. Something like this will probably end up in RHEL, although it will be optional. -- 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 russell at coker.com.au Sat Apr 10 06:18:40 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 10 Apr 2004 16:18:40 +1000 Subject: Another dumb question... In-Reply-To: <1081169495.5343.42.camel@moss-spartans.epoch.ncsc.mil> References: <1081169495.5343.42.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200404101618.40238.russell@coker.com.au> On Mon, 5 Apr 2004 22:51, Stephen Smalley wrote: > identity using that audit framework rather than SELinux. Also, the > existing SELinux auditing of permission checks could be configured to > audit all transitions to and from the su domains, such that the SELinux > user identity transitions would be logged as they occur, e.g. adding > something like 'auditallow $1_t $1_su_t:process transition; auditallow > $1_su_t userdomain:process transition;' to > policy/macros/program/su_macros.te (caveat: untested). The problem with this is that you need to analyse a lot of log data to get the result. Someone could run su days or weeks before performing an action that is undesirable. The audit framework can be used instead, it's just another thing that we have to learn and support in our log file analysis programs. -- 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 russell at coker.com.au Sat Apr 10 10:24:50 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 10 Apr 2004 20:24:50 +1000 Subject: List of selinux issues In-Reply-To: <40729256.6080309@redhat.com> References: <40725F4B.6050909@redhat.com> <40729256.6080309@redhat.com> Message-ID: <200404102024.50643.russell@coker.com.au> On Tue, 6 Apr 2004 21:19, Daniel J Walsh wrote: > > Apr 5 21:07:45 ibmlaptop kernel: audit(1081235265.089:0): avc: > > denied { search } for pid=12493 exe=/sbin/dhclient name=lib dev=hda2 > > ino=1389922 scontext=root:system_r:dhcpc_t > > tcontext=system_u:object_r:home_root_t tclass=dir > > Added policy to allow this , but not sure what it is trying todo. Could > you try it in non-enforcing mode and grab the avc messages. Looks like /var/lib is mis-labeled as home_root_t. Relabeling the file system is probably the best thing to do. > > 5) This is vmware from the VMWare WS 4.5.1 service startup. The > > issues are ... complicated, numerous, and scary looking. > > > > Apr 5 21:06:08 ibmlaptop kernel: audit(1081235168.858:0): avc: > > denied { search } for pid=1909 exe=/usr/bin/vmnet-netifup name=net > > dev= ino=344 scontext=system_u:system_r:vmware_t > > tcontext=system_u:object_r:sysfs_t tclass=dir > > Apr 5 21:06:08 ibmlaptop kernel: audit(1081235168.867:0): avc: > > denied { search } for pid=1910 exe=/usr/bin/vmnet-netifup name=net > > dev= ino=344 scontext=system_u:system_r:vmware_t > > tcontext=system_u:object_r:sysfs_t tclass=dir > > Apr 5 21:06:09 ibmlaptop kernel: audit(1081235169.047:0): avc: > > denied { node_bind } for pid=1931 exe=/usr/bin/vmnet-natd > > scontext=system_u:system_r:vmware_t > > tcontext=system_u:object_r:node_inaddr_any_t tclass=rawip_socket > > Apr 5 21:06:09 ibmlaptop kernel: audit(1081235169.048:0): avc: > > denied { create } for pid=1931 exe=/usr/bin/vmnet-natd > > name=vmnat.1931 scontext=system_u:system_r:vmware_t > > tcontext=system_u:object_r:var_run_t tclass=sock_file The problem here is that we don't have any distinction between vmware processes started by the user and the vmware daemons. Probably the best thing to do is to entirely re-write the vmware policy to fix this and the other problems. -- 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 gene at czarc.net Sun Apr 11 20:12:46 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sun, 11 Apr 2004 16:12:46 -0400 Subject: kernel install and policy Message-ID: <200404111612.46499.gene@czarc.net> I am not sure which bugzilla report this applies to but ... 1. With the latest policy installed (1.10.2-5) and 2. after running setfiles /etc/security/selinux/file... /dev because the /dev/loop devices are a variety of selinux attributes 3. I successfully was able to install a kernel with enforcing=1 Progress! Of course I found another bug but ... that is expected. Gene From herald at breggen.xs4all.nl Mon Apr 12 10:36:41 2004 From: herald at breggen.xs4all.nl (Herald van der Breggen) Date: Mon, 12 Apr 2004 12:36:41 +0200 Subject: policy rules for use as Xterminal Message-ID: <1081766201.7232.36.camel@lion.landweg.nl> Hello, I just installed FC2 on my laptop and changed /etc/inittab for use as Xterminal: removed the line #x:5:respawn:/etc/X11/prefdm -nodaemon added the line x:5:respawn:/usr/X11R6/bin/X -query 192.168.1.12 The current policy files don't allow init to start X (which is a symlink to XFree in the same direcory). avc: denied { execute } for pid=3058 exe=/sbin/init name=XFree86 dev=hda5 ino=395703 scontext=system_u:system_r:init_t tcontext=system_u:object_r:policy_config_t tclass=file Question one: should the default set of policy rules not allow this? Question two: what is the best way to allow to start the X server by init? I am new to selinux and have trouble to find my way. I struggled with the newrules.pl script (which not seemed to right way to solve this problem) and tried rules like can_exec(init_t, xserver_exec_t); can_exec(init_t, xserver_log_t); which are not enough (still: avc: denied { search } for pid=5116 exe=/usr/X11R6/bin/XFree86 name=tmp dev=hda5 ino=273633 scontext=system_u:system_r:init_t tcontext=system_u:object_r:tmp_t tclass=dir). Any help is appreciated! Herald -- Herald van der Breggen From russell at coker.com.au Mon Apr 12 13:17:26 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 12 Apr 2004 23:17:26 +1000 Subject: SELinux and ReiserFS In-Reply-To: <4072B2ED.8030809@234.cx> References: <4072B2ED.8030809@234.cx> Message-ID: <200404122317.26482.russell@coker.com.au> On Tue, 6 Apr 2004 23:38, Pete Chown <1 at 234.cx> wrote: > As I understand it, Hans Reiser has indicated that he will only accept > bugfixes for reiser3. ?It is therefore very unlikely that anyone could > come up with a patch which would be merged upstream. ?Reiser4 will > support file metadata from the beginning, but of course it's not > available yet. Hans and I get along well. I have used ReiserFS since the early days, benchmarked it and tested it in various other ways, make detailed bug reports, and generally helped it get accepted. Hans told me that there would never be official support for XATTR on ReiserFS 3, which led to me removing ReiserFS from all my systems. I think that it's quite safe to consider support for XATTR on Reiser3 to be impossible for Red Hat. That said, the "-o context=" mount option should do well for any situation where you REALLY need ReiserFS. ReiserFS performs really well for Maildir format mail spools on large mail servers, the original INN news spool, squid, and for other applications that manage large numbers of small files. In all those situations -o context will do really well. In fact for such situations where you have a file system dedicated to one type of file even when using other file systems using the -o context mount option may be advisable. For Ext2/3 the space overhead of an xattr on each file is not significant (based on my recollection of a conversation with sct it's one xattr block per 1024 files). However labelling a file system with >1M files will take quite a bit of time as will re-labelling such a file system after a serious disk error. For large file systems of Ext2/3 using -o context will save some significant amount of labelling time which is a definite benefit. Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see below bugzilla URL for the details). This means that existing XFS file systems will not be good candidates for being labelled with SE Linux contexts. I believe that we have never provided a method for install to an XFS root fs, so most use of XFS in Fedora should be for /mail, /var/spool/news, /var/cache/squid, etc. Using -o context for such file systems should provide significant benefits for disk space use and performance. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622 -- 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 russell at coker.com.au Mon Apr 12 13:29:26 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 12 Apr 2004 23:29:26 +1000 Subject: policy rules for use as Xterminal In-Reply-To: <1081766201.7232.36.camel@lion.landweg.nl> References: <1081766201.7232.36.camel@lion.landweg.nl> Message-ID: <200404122329.26227.russell@coker.com.au> On Mon, 12 Apr 2004 20:36, Herald van der Breggen wrote: > removed the line > #x:5:respawn:/etc/X11/prefdm -nodaemon > > added the line > x:5:respawn:/usr/X11R6/bin/X -query 192.168.1.12 > > The current policy files don't allow init to start X (which is a symlink > to XFree in the same direcory). > > avc: denied { execute } for pid=3058 exe=/sbin/init name=XFree86 > dev=hda5 ino=395703 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:policy_config_t tclass=file Firstly there is something very wrong in having the file labeled as policy_config_t. Please use setfiles to relabel /usr/X11R6 before trying it again. > Question one: should the default set of policy rules not allow this? Yes, I think it should. > Question two: what is the best way to allow to start the X server by > init? I am new to selinux and have trouble to find my way. I struggled > with the newrules.pl script (which not seemed to right way to solve this > problem) and tried rules like > > can_exec(init_t, xserver_exec_t); > can_exec(init_t, xserver_log_t); I don't know why a log file is being executed, I guess that there is a mislabeled file. Maybe relabelling your system would be a good idea. As for solving the problem, what you want is for init_t to transition to xdm_xserver_t (the domain for system X server processes). The following policy should work: domain_auto_trans(init_t, xserver_exec_t, xdm_xserver_t) Please try it and let me know how it works (very important). I don't have a network setup for testing X terms so I need positive feedback from you if I am to include this policy in my tree. If you want to have this work on a default Fedora SE Linux install then let me know how it works, if it doesn't work then tell me the AVC messages you get. -- 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 russell at coker.com.au Mon Apr 12 13:46:19 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 12 Apr 2004 23:46:19 +1000 Subject: SELinux for RHEL3 In-Reply-To: <320328467.1081180117@[192.168.0.3]> References: <320328467.1081180117@[192.168.0.3]> Message-ID: <200404122346.19653.russell@coker.com.au> On Tue, 6 Apr 2004 08:48, Bill McCarty wrote: > Do RHEL 3 packages for SELinux currently exist? If so, where can they be > obtained? If not, must we wait for RHEL 4 to obtain compatible SELinux > packages? Or, is there a chance of another experimental release for RHEL 3? Fedora Core is going to be the base for future RHEL releases. Fedora Core 2 Test 2 is currently the best available distribution for SE Linux, it has an option in the GUI installer for installing SE Linux (default is "on" for this release, maybe something different for the next test release), and the policy supports all the most common tasks you will want to perform. To achieve your goals of generally learning about Red Hat and SE Linux your best option is to just download some ISOs of FC2T2. There are no plans of integrating SE Linux into RHEL 3 as well as it is integrated into Fedora, and RHEL 4 will be longer than you want to wait. -- 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 dennis at ausil.us Mon Apr 12 14:14:10 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 13 Apr 2004 00:14:10 +1000 Subject: SELinux and ReiserFS In-Reply-To: <200404122317.26482.russell@coker.com.au> References: <4072B2ED.8030809@234.cx> <200404122317.26482.russell@coker.com.au> Message-ID: <200404130014.17671.dennis@ausil.us> Once upon a time Monday 12 April 2004 11:17 pm, Russell Coker wrote: > On Tue, 6 Apr 2004 23:38, Pete Chown <1 at 234.cx> wrote: > Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see below > bugzilla URL for the details). This means that existing XFS file systems > will not be good candidates for being labelled with SE Linux contexts. I > believe that we have never provided a method for install to an XFS root fs, > so most use of XFS in Fedora should be for /mail, /var/spool/news, > /var/cache/squid, etc. Using -o context for such file systems should > provide significant benefits for disk space use and performance. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622 at the install boot screen append xfs as an option i.e linux xfs and you will be able to install xfs from the get go. I currently have two test 2 systems running xfs as the root file system one system has a 80 gig drive and the other is 60 gig. im willing to help test things Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From herald at breggen.xs4all.nl Mon Apr 12 14:35:31 2004 From: herald at breggen.xs4all.nl (Herald van der Breggen) Date: Mon, 12 Apr 2004 16:35:31 +0200 Subject: policy rules for use as Xterminal In-Reply-To: <200404122329.26227.russell@coker.com.au> References: <1081766201.7232.36.camel@lion.landweg.nl> <200404122329.26227.russell@coker.com.au> Message-ID: <1081780530.7232.65.camel@lion.landweg.nl> Op ma 12-04-2004, om 15:29 schreef Russell Coker: > On Mon, 12 Apr 2004 20:36, Herald van der Breggen > wrote: > > removed the line > > #x:5:respawn:/etc/X11/prefdm -nodaemon > > > > added the line > > x:5:respawn:/usr/X11R6/bin/X -query 192.168.1.12 > > > > The current policy files don't allow init to start X (which is a symlink > > to XFree in the same direcory). > > > > avc: denied { execute } for pid=3058 exe=/sbin/init name=XFree86 > > dev=hda5 ino=395703 scontext=system_u:system_r:init_t > > tcontext=system_u:object_r:policy_config_t tclass=file > > Firstly there is something very wrong in having the file labeled as > policy_config_t. Please use setfiles to relabel /usr/X11R6 before trying it > again. Yes, you are right, in my attempts to fix the problem, I made a mistake. I did a relabel and now a "better" avc message appears when init tries to start X: avc: denied { execute } for pid=1908 exe=/sbin/init name=XFree86 dev=hda5 ino=395703 scontext=system_u:system_r:init_t tcontext=system_u:object_r:xserver_exec_t tclass=file > > > Question one: should the default set of policy rules not allow this? > > Yes, I think it should. > > > Question two: what is the best way to allow to start the X server by > > init? I am new to selinux and have trouble to find my way. I struggled > > with the newrules.pl script (which not seemed to right way to solve this > > problem) and tried rules like > > > > can_exec(init_t, xserver_exec_t); > > can_exec(init_t, xserver_log_t); > > I don't know why a log file is being executed, I guess that there is a > mislabeled file. Maybe relabelling your system would be a good idea. > > As for solving the problem, what you want is for init_t to transition to > xdm_xserver_t (the domain for system X server processes). The following > policy should work: > > domain_auto_trans(init_t, xserver_exec_t, xdm_xserver_t) I have put the line in domains/program/init.te, did a "make load" and there were no more avc messages anymore. Nice! The only thing was that the screen stayed black. I decided to reboot. And after that... It worked! So, the domain_auto_trans line really works! Thanks a lot! Herald From gene at czarc.net Mon Apr 12 14:44:51 2004 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 12 Apr 2004 10:44:51 -0400 Subject: Some questions relating to selinux Message-ID: <200404121044.51034.gene@czarc.net> The following is a mixed bag of comments/questions related to SElinux... 1. I noticed that when I login as root from a VT I get the choice of 3 different roles (staff_r, sysadm_r, and system_r) but when I login as a sysadm_r user and then "su -" to root, I only get two roles (staff_r and sysadm_r). Whe the difference? Better still, is this intentional? 2. If I login a VT or su to a user who has multiple roles defined, I get the option to select which role (when su - is working). On the other hand, if I login via gdm I do not get such a choice. Question: should gdm be enhanced to offer to option to select a role for users with multiple roles defined? 3. In the /etc/security/selinux/src/policy/users file there are two examples of defining a user having sysadm_r: # sample for administrative user #user jadmin roles { staff_r sysadm_r ifdef(`direct_sysadm_daemon', \ `system_r') }; # sample for regular user #user jdoe roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r system_r') }; Which one is the "right" one to use? 4. In the above, I notice that if I login from gdm I get sysadm_r in the first case and user_r in the second case. However, if I login from a VT, the default role is sysadm_r in both cases. Is this operating correctly? Why the difference? It seems to me that the correct operation should be the same in both cases. 5. Why is the system_r role only available from the VT? 6. Is there some command that will list the roles available for a user? 7. The packages libselinux has a lot of /usr/bin/ files which have no documentation (e.g., setfilecon). Is there some reason for this (other than we have not got around to that yet)? 8. Is there someplace that describes the differences between the various policy versions (15, 16, 17, etc.)? 9. Is there some additional documentation concerning the /etc/security/selinux/src/policy/tunable.te file (besides the comments in the file itself)? 10. Is there any documentation planned (but maybe not in FC2) which will make recommendations on how to lock a system down using the tunable.te file? 11. For the record, my "vote" is for FC2 final to default to selinux=1, enforcing=1 but with a policy that is very "loose" by default (it would more or less work as if selinux was not really installed for most users). I would also like to see an option for a more restrictive policy which could then be worked with for those inclined to do so. 12. I noticed that if I login as a user defined in users as above case 2 and then "su -" to root, I am given no role options. However, if I login as a sysadm_r user (case 1 above) and then "su -" to root, I am given a choice of role. Why the difference? If this operating correctly? ------------------------------------------------------------------------------------ I am sure that more questions will occur to me but that is enough for now. Gene From russell at coker.com.au Mon Apr 12 14:52:59 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 13 Apr 2004 00:52:59 +1000 Subject: policy rules for use as Xterminal In-Reply-To: <1081780530.7232.65.camel@lion.landweg.nl> References: <1081766201.7232.36.camel@lion.landweg.nl> <200404122329.26227.russell@coker.com.au> <1081780530.7232.65.camel@lion.landweg.nl> Message-ID: <200404130052.59120.russell@coker.com.au> On Tue, 13 Apr 2004 00:35, Herald van der Breggen wrote: > > domain_auto_trans(init_t, xserver_exec_t, xdm_xserver_t) > > I have put the line in domains/program/init.te, did a "make load" and > there were no more avc messages anymore. Nice! > > The only thing was that the screen stayed black. I decided to reboot. > And after that... It worked! > > So, the domain_auto_trans line really works! Thanks a lot! It's strange that you needed so many reboots. But it's good that it's now working. I've added that domain_auto_trans() line to my tree, it'll be in a future version of the Fedora policy package (keep it in domains/misc/custom.te for the moment). -- 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 russell at coker.com.au Mon Apr 12 14:57:50 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 13 Apr 2004 00:57:50 +1000 Subject: SELinux and ReiserFS In-Reply-To: <200404130014.17671.dennis@ausil.us> References: <200404122317.26482.russell@coker.com.au> <200404130014.17671.dennis@ausil.us> Message-ID: <200404130057.50561.russell@coker.com.au> On Tue, 13 Apr 2004 00:14, Dennis Gilmore wrote: > > Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see below > > bugzilla URL for the details). This means that existing XFS file systems > > will not be good candidates for being labelled with SE Linux contexts. I > > believe that we have never provided a method for install to an XFS root > > fs, so most use of XFS in Fedora should be for /mail, /var/spool/news, > > /var/cache/squid, etc. Using -o context for such file systems should > > provide significant benefits for disk space use and performance. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622 > > at the install boot screen append xfs as an option i.e linux xfs and you > will be able to install xfs from the get go. Even on the root fs? I wasn't aware of this. Is it possible to pass "-i size=512" to mkfs.xfs through the GUI or do you have to run mkfs.xfs from the command line to do so? > I currently have two test 2 > systems running xfs as the root file system one system has a 80 gig drive > and the other is 60 gig. im willing to help test things Well if you have 256 byte Inodes then your test results may make you unhappy. Lots of disk space used and no good way of reclaiming it. But I would be interested to hear about your test results apart from issues of performance and wasted disk space... -- 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 dennis at ausil.us Mon Apr 12 15:10:53 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 13 Apr 2004 01:10:53 +1000 Subject: SELinux and ReiserFS In-Reply-To: <200404130057.50561.russell@coker.com.au> References: <200404130014.17671.dennis@ausil.us> <200404130057.50561.russell@coker.com.au> Message-ID: <200404130110.54684.dennis@ausil.us> Once upon a time Tuesday 13 April 2004 12:57 am, Russell Coker wrote: > On Tue, 13 Apr 2004 00:14, Dennis Gilmore wrote: > > > Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see below > > > bugzilla URL for the details). This means that existing XFS file > > > systems will not be good candidates for being labelled with SE Linux > > > contexts. I believe that we have never provided a method for install > > > to an XFS root fs, so most use of XFS in Fedora should be for /mail, > > > /var/spool/news, /var/cache/squid, etc. Using -o context for such file > > > systems should provide significant benefits for disk space use and > > > performance. > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622 > > > > at the install boot screen append xfs as an option i.e linux xfs and you > > will be able to install xfs from the get go. > > Even on the root fs? I wasn't aware of this. yes both systems only have xfs as the filesystem > Is it possible to pass "-i size=512" to mkfs.xfs through the GUI or do you > have to run mkfs.xfs from the command line to do so? i will do some testing to see if it can be either passed as a boot option or specifed in the gui think it would probably only be available as a boot time option same as enabling xfs support. > > I currently have two test 2 > > systems running xfs as the root file system one system has a 80 gig > > drive and the other is 60 gig. im willing to help test things > > Well if you have 256 byte Inodes then your test results may make you > unhappy. Lots of disk space used and no good way of reclaiming it. But I > would be interested to hear about your test results apart from issues of > performance and wasted disk space... Ill let you know how it goes ill re-enable selinux Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From russell at coker.com.au Mon Apr 12 15:22:12 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 13 Apr 2004 01:22:12 +1000 Subject: SELinux and ReiserFS In-Reply-To: <200404130110.54684.dennis@ausil.us> References: <200404130057.50561.russell@coker.com.au> <200404130110.54684.dennis@ausil.us> Message-ID: <200404130122.12919.russell@coker.com.au> On Tue, 13 Apr 2004 01:10, Dennis Gilmore wrote: > > Is it possible to pass "-i size=512" to mkfs.xfs through the GUI or do > > you have to run mkfs.xfs from the command line to do so? > > i will do some testing to see if it can be either passed as a boot option > or specifed in the gui think it would probably only be available as a boot > time option same as enabling xfs support. I would be shocked if there was a boot option to pass such options to mkfs.xfs. XFS has lots of tunable options, using them all in boot options would not make sense to me, even if it wasn't for the fact that different file systems may want different mkfs options. There are XFS options -d for data section, -l for log, and -b for block size. Having boot options for all of these would be confusing at best. -- 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 dwalsh at redhat.com Mon Apr 12 15:36:39 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Apr 2004 11:36:39 -0400 Subject: Boolean support in latest SELinux policy. Message-ID: <407AB787.3020907@redhat.com> There is a new feature in SELinux that allows you to modify a running policy. Basically you can define booleans in policy that an admin can then decide to turn on or off. To allow users to ping you can execute the following command. > ping 4.2.2.2 ping: icmp open socket: Permission denied > show_bools user_ping --> active: 0 pending: 0 As root # change_bool user_ping 1 > show_bools user_ping --> active: 1 pending: 1 >ping 4.2.2.2 PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. 64 bytes from 4.2.2.2: icmp_seq=0 ttl=248 time=10.0 ms 64 bytes from 4.2.2.2: icmp_seq=1 ttl=248 time=10.6 ms To show the available booleans you can use show_bools. show_bools user_ping --> active: 0 pending: 0 From russell at coker.com.au Mon Apr 12 17:06:20 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 13 Apr 2004 03:06:20 +1000 Subject: Some questions relating to selinux In-Reply-To: <200404121044.51034.gene@czarc.net> References: <200404121044.51034.gene@czarc.net> Message-ID: <200404130306.20066.russell@coker.com.au> On Tue, 13 Apr 2004 00:44, Gene Czarcinski wrote: > The following is a mixed bag of comments/questions related to SElinux... > > 1. I noticed that when I login as root from a VT I get the choice of 3 > different roles (staff_r, sysadm_r, and system_r) but when I login as a > sysadm_r user and then "su -" to root, I only get two roles (staff_r and > sysadm_r). Whe the difference? Better still, is this intentional? The fact that you are offered system_r is a bug. Being offered the other two is OK, but you can turn this off by removing the "multiple" option from pam_selinux.so in the pam.d file. > 2. If I login a VT or su to a user who has multiple roles defined, I get > the option to select which role (when su - is working). On the other hand, > if I login via gdm I do not get such a choice. Question: should gdm be > enhanced to offer to option to select a role for users with multiple roles > defined? We discussed this at length and came to the conclusion that running a GNOME or KDE environment in a privileged role is a bad idea. Also GNOME and KDE create lots of /tmp entries such as /tmp/mcop-user and /tmp/.gconf-user. If you login to GNOME or KDE as one role and then login as the same UID with another role then one of two things will happen: 1) role A is not permitted to write to role B's /tmp files and the login will fail in ways that might be surprising and difficult to debug. 2) role A is permitted to write to role B's /tmp files, things will work BUT role A can probably use this to take over role B processes. If we permit this bi-directionally so that no combination of X login order will result in failure then we give role A and role B such access to each other that we should just merge them. The conclusion is that there is no benefit in giving the user two roles and allowing them both to be accessed through a GUI login. > 3. In the /etc/security/selinux/src/policy/users file there are two > examples of defining a user having sysadm_r: > > # sample for administrative user > #user jadmin roles { staff_r sysadm_r ifdef(`direct_sysadm_daemon', \ > `system_r') }; > > # sample for regular user > #user jdoe roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r system_r') > }; > > Which one is the "right" one to use? jdoe is a regular user, jadmin is an administrative user. Which one you use for an account depends on whether they are a regular user or an admin. > 4. In the above, I notice that if I login from gdm I get sysadm_r in the > first case and user_r in the second case. However, if I login from a VT, > the default role is sysadm_r in both cases. Is this operating correctly? > Why the difference? It seems to me that the correct operation should be > the same in both cases. See /etc/security/default_contexts . > 5. Why is the system_r role only available from the VT? The bug is limited in scope. > 6. Is there some command that will list the roles available for a user? The users file will contain the list, it should be possible to get the list from the kernel as well. > 7. The packages libselinux has a lot of /usr/bin/ files which have no > documentation (e.g., setfilecon). Is there some reason for this (other > than we have not got around to that yet)? We haven't got around to it yet. Contributions of man pages are welcome... > 9. Is there some additional documentation concerning the > /etc/security/selinux/src/policy/tunable.te file (besides the comments in > the file itself)? Not yet. > 10. Is there any documentation planned (but maybe not in FC2) which will > make recommendations on how to lock a system down using the tunable.te > file? Yes, we will have to do that. -- 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 walters at redhat.com Mon Apr 12 17:24:39 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 12 Apr 2004 13:24:39 -0400 Subject: Some questions relating to selinux In-Reply-To: <200404130306.20066.russell@coker.com.au> References: <200404121044.51034.gene@czarc.net> <200404130306.20066.russell@coker.com.au> Message-ID: <1081790679.24726.45.camel@nexus.verbum.private> On Mon, 2004-04-12 at 13:06, Russell Coker wrote: > We discussed this at length and came to the conclusion that running a GNOME or > KDE environment in a privileged role is a bad idea. The problem is that it's going to happen. E.g. if you log in as a staff_r, then inside a terminal use 'su' to become root/sysadm_r, and run a program that uses X. > Also GNOME and KDE > create lots of /tmp entries such as /tmp/mcop-user and /tmp/.gconf-user. If > you login to GNOME or KDE as one role and then login as the same UID with > another role then one of two things will happen: > > 1) role A is not permitted to write to role B's /tmp files and the login will > fail in ways that might be surprising and difficult to debug. > > 2) role A is permitted to write to role B's /tmp files, things will work BUT > role A can probably use this to take over role B processes. If we permit > this bi-directionally so that no combination of X login order will result in > failure then we give role A and role B such access to each other that we > should just merge them. There's a third option - write policy such that only for those shared files, each role can access the other's files. That's what I'm working on right now with GConf. > The conclusion is that there is no benefit in giving the user two roles and > allowing them both to be accessed through a GUI login. Although we don't have SE-X yet, making most of this moot, I think it's still a worthwhile goal. -------------- 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 gene at czarc.net Mon Apr 12 18:00:34 2004 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 12 Apr 2004 14:00:34 -0400 Subject: Some questions relating to selinux In-Reply-To: <200404130306.20066.russell@coker.com.au> References: <200404121044.51034.gene@czarc.net> <200404130306.20066.russell@coker.com.au> Message-ID: <200404121400.34904.gene@czarc.net> On Monday 12 April 2004 13:06, Russell Coker wrote: > On Tue, 13 Apr 2004 00:44, Gene Czarcinski wrote: > > The following is a mixed bag of comments/questions related to SElinux... > > > > 1. I noticed that when I login as root from a VT I get the choice of 3 > > different roles (staff_r, sysadm_r, and system_r) but when I login as a > > sysadm_r user and then "su -" to root, I only get two roles (staff_r and > > sysadm_r). Whe the difference? Better still, is this intentional? > > The fact that you are offered system_r is a bug. Being offered the other > two is OK, but you can turn this off by removing the "multiple" option from > pam_selinux.so in the pam.d file. OK, I will file a bugzilla report against policy (unless you suggest something else). [snip] > > 3. In the /etc/security/selinux/src/policy/users file there are two > > examples of defining a user having sysadm_r: > > > > # sample for administrative user > > #user jadmin roles { staff_r sysadm_r ifdef(`direct_sysadm_daemon', \ > > `system_r') }; > > > > # sample for regular user > > #user jdoe roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r system_r') > > }; > > > > Which one is the "right" one to use? > > jdoe is a regular user, jadmin is an administrative user. Which one you > use for an account depends on whether they are a regular user or an admin. I saw little difference in the capabilities. When I login from gdm, the administrative user's role is sysadm_4. When I login from gdm, the "regular user's" role is user_r but I can change to sysadm_r with the newrole command. The "role" I am seeing is the result of running "id -Z" in a terminal window. As a regular user (e.g., jdoe), I can run things like system-config-users by entering jdoe's password ... the same thing I have to do when I login as the administrative user (e.g., jadmin). I am also wonder what role is being used for most programs if I login as the adminstrative user. Aren't these running with sysadm_r. If so, it appears to me that the "safer" way is to use the"jdoe style" since it seems to provide the same capabilities but defaults to user_r. This leads to another question: just what capabilities does sysadm_r have if I am running it as the default? Also, if I ssh in (as admin user for example), I get exactly the same role that I get when I login from gdm. > > > 4. In the above, I notice that if I login from gdm I get sysadm_r in the > > first case and user_r in the second case. However, if I login from a VT, > > the default role is sysadm_r in both cases. Is this operating correctly? > > Why the difference? It seems to me that the correct operation should be > > the same in both cases. > > See /etc/security/default_contexts . I am not sure I see what this means (the contents of the file that is). The implication I see is that I should not be able to ssh in with sysadm_r but I do (see above). [snip] > > 6. Is there some command that will list the roles available for a user? > > The users file will contain the list, it should be possible to get the list > from the kernel as well. And the command to display the roles is ...? [snip] > > 10. Is there any documentation planned (but maybe not in FC2) which will > > make recommendations on how to lock a system down using the tunable.te > > file? > > Yes, we will have to do that. This is going to be a must for a lot of individuals. They will need to see hoiw to lock things down (and a bit of why) in order to see why seliniux is a good thing. I also believe this needs to be rather cookbookish so that folks do not have to work too hard to get some benefit. Otherwise a log of folks will be inclined to run selinux (witness the discussion on this list and others about what the default will be for FC2 final). Gene From bmccarty at pt-net.net Mon Apr 12 21:01:49 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Mon, 12 Apr 2004 14:01:49 -0700 Subject: SELinux for RHEL3 In-Reply-To: <200404122346.19653.russell@coker.com.au> References: <320328467.1081180117@[192.168.0.3]> <200404122346.19653.russell@coker.com.au> Message-ID: <185722124.1081778508@[192.168.0.3]> Hi Russell, --On Monday, April 12, 2004 11:46 PM +1000 Russell Coker wrote: > Fedora Core is going to be the base for future RHEL releases. Fedora > Core 2 Test 2 is currently the best available distribution for SE Linux, > it has an option in the GUI installer for installing SE Linux (default > is "on" for this release, maybe something different for the next test > release), and the policy supports all the most common tasks you will > want to perform. So far I've worked with SELinux under Debian Sid, Debian Woody, Gentoo, RHEL 3, and now FC2T2. Not being content with one toe in the water , I'm already running two FC2T2 hosts and expect soon to have more--including several honeypots, as I'm a honeynet researcher. Commenting as a disinterested party, I affirm that you're absolutely right in your high estimation of FC2T2's SELinux implementation. FC2T2 SELinux rocks, especially for those new to SELinux! > To achieve your goals of generally learning about Red Hat and SE Linux > your best option is to just download some ISOs of FC2T2. There are no > plans of integrating SE Linux into RHEL 3 as well as it is integrated > into Fedora, and RHEL 4 will be longer than you want to wait. Actually, in the case of RHEL 3, I was hoping to deploy, more than to learn. I obviously understand that the RHEL 3 packages that were once available are unsupported beta (alpha?) software. But, that's good enough for some of my purposes . Thanks for your recommendations! Cheers, --------------------------------------------------- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From mike at flyn.org Mon Apr 12 23:13:29 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 12 Apr 2004 18:13:29 -0500 Subject: Pam_mount and SELinux Message-ID: <20040412231329.GA8336@imp.flyn.org> As an exercise to help me learn the fundamentals of SELinux policies I am trying to get pam_mount to work one an enforcing SELinux system. Pam_mount is a module that allows password-protected volumes to be mounted when a user logs in using the users normal system password. Pam_mount requires several special capabilities and I have modified my su_macros.te to give them to the su command (its a start). 1. Pam_mount needs be able to work in /var/run/pam_mount: allow $1_su_t var_run_t:dir { getattr add_name remove_name write }; allow $1_su_t var_run_t:file { create getattr setattr read write lock unlink }; 2. Pam_mount needs to be able to read its configuration file: allow $1_su_t etc_runtime_t:file { getattr read }; allow $1_su_t user_home_t:dir { getattr read }; 3. Pam_mount needs to be able to execute some commands in /sbin: allow $1_su_t sbin_t:file { read execute }; 4. Pam_mount needs to be able to execute mount: allow $1_su_t mount_exec_t:file { read execute }; allow $1_su_t $1_su_t:capability { fsetid }; domain_auto_trans($1_su_t, mount_exec_t, mount_t) One problem I am having right now is that when pam_mount tries to execute mount it fails with a "permission denied" error. But I get no related AVC log from SELinux. If I disable SELinux's enforcing then I get no error and everything works fine. Other than that, I would like to hear any comments about the additional requirements pam_mount has. I am giving more capabilities to su and therefore increasing risk. Am I doing so in the right way? Does anyone have a better model to propose to accomplish this? -- Mike :wq From mitch48 at sbcglobal.net Tue Apr 13 01:03:46 2004 From: mitch48 at sbcglobal.net (Tom Mitchell) Date: Mon, 12 Apr 2004 18:03:46 -0700 Subject: sshd -- cannot relabel with system_u:object_r:sshd_devpts_t Message-ID: <20040413010346.GC26151@xtl1.xtl.tenegg.com> I just killed a remote terminal window and noted this message triple in the log/messages: sshd(pam_unix)[30912]: session opened for user root by (uid=0) sshd[30912]: Warning! Could not relabel with system_u:object_r:sshd_devpts_t, not relabeling. sshd(pam_unix)[30912]: session closed for user root policy-sources-1.10.2-5 policy-1.10.2-5 If this is what I think it is sshd will slowly run out of available ptys. -- T o m M i t c h e l l /dev/null the ultimate in secure storage. From dwalsh at redhat.com Tue Apr 13 02:22:04 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Apr 2004 22:22:04 -0400 Subject: Pam_mount and SELinux In-Reply-To: <20040412231329.GA8336@imp.flyn.org> References: <20040412231329.GA8336@imp.flyn.org> Message-ID: <407B4ECC.3080002@redhat.com> W. Michael Petullo wrote: >As an exercise to help me learn the fundamentals of SELinux policies I >am trying to get pam_mount to work one an enforcing SELinux system. >Pam_mount is a module that allows password-protected volumes to be >mounted when a user logs in using the users normal system password. > >Pam_mount requires several special capabilities and I have modified my >su_macros.te to give them to the su command (its a start). > >1. Pam_mount needs be able to work in /var/run/pam_mount: >allow $1_su_t var_run_t:dir { getattr add_name remove_name write }; >allow $1_su_t var_run_t:file { create getattr setattr read write lock unlink }; > > Look at the macros, You really want to create a transition rule that tells the kernel to create files under a specific context in the /var/run directory. So a rule like var_run_domain($1_su) will create a $1_su_var_run_t context. >2. Pam_mount needs to be able to read its configuration file: >allow $1_su_t etc_runtime_t:file { getattr read }; >allow $1_su_t user_home_t:dir { getattr read }; > >3. Pam_mount needs to be able to execute some commands in /sbin: >allow $1_su_t sbin_t:file { read execute }; > > > What files is it execing. A better macro for execute privs is can_exec($1_su_t, sbin_t) >4. Pam_mount needs to be able to execute mount: >allow $1_su_t mount_exec_t:file { read execute }; >allow $1_su_t $1_su_t:capability { fsetid }; >domain_auto_trans($1_su_t, mount_exec_t, mount_t) > > > domain_auto_trans will provide the first rule. >One problem I am having right now is that when pam_mount tries to execute >mount it fails with a "permission denied" error. But I get no related >AVC log from SELinux. If I disable SELinux's enforcing then I get no >error and everything works fine. > > > What is the mount point? Is there a mounton rule for it? >Other than that, I would like to hear any comments about the additional >requirements pam_mount has. I am giving more capabilities to su and >therefore increasing risk. Am I doing so in the right way? Does anyone >have a better model to propose to accomplish this? > > > From adrier at acm.org Tue Apr 13 02:42:48 2004 From: adrier at acm.org (Abe Drier) Date: Mon, 12 Apr 2004 22:42:48 -0400 Subject: Error recorded in Cron log file after completion of boot In-Reply-To: <20040412231329.GA8336@imp.flyn.org> References: <20040412231329.GA8336@imp.flyn.org> Message-ID: <407B53A8.10803@acm.org> An HTML attachment was scrubbed... URL: From w at puschitz.com Tue Apr 13 03:49:10 2004 From: w at puschitz.com (Werner Puschitz) Date: Mon, 12 Apr 2004 23:49:10 -0400 (EDT) Subject: SELinux and Oracle Database 10g Message-ID: Is anyone working on a policy for Oracle 10g yet? I'm thinking about writing an article that will cover the whole process of securing an Oracle database 10g using MAC. And I'm also thinking about writing a policy for Oracle Database 10g and for Oracle's Real Application Cluster (RAC). If anyone is already working on it, please let me know. Werner http://www.puschitz.com/ http://www.puschitz.com/OracleOnLinux.shtml From bmccarty at pt-net.net Tue Apr 13 04:15:42 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Mon, 12 Apr 2004 21:15:42 -0700 Subject: SELinux and Oracle Database 10g In-Reply-To: References: Message-ID: <211755828.1081804542@[192.168.0.3]> Hi Werner, --On Monday, April 12, 2004 11:49 PM -0400 Werner Puschitz wrote: > I'm thinking about writing an article that will cover the whole process > of securing an Oracle database 10g using MAC. Have you seen DShield's data on port 1521 probes? It suggests that Oracle security is pretty important right now: . I interpret the peaks as suggestive of one or more Oracle (TCP/1521) exploits in actual use, at an accelerating rate. So, your work would be most welcome, I suspect . Cheers, --------------------------------------------------- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From mike at netlyncs.com Tue Apr 13 10:36:40 2004 From: mike at netlyncs.com (Mike Chambers) Date: Tue, 13 Apr 2004 05:36:40 -0500 Subject: Kernel audit messages Message-ID: <1081852600.2582.6.camel@bart.netlyncs.com> I have found these this morning in my logs after the latest kernel from rawhide on a FC2T2 system... [root at homer cron.monthly]# rpm -q policy kernel policy-1.10.2-5 kernel-2.6.5-1.315 Apr 12 18:51:53 homer kernel: audit(1081813913.544:0): avc: denied { search } for pid=973 exe=/usr/bin/procmail name=mail dev=hda2 ino=246478 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=dir Apr 12 18:51:53 homer kernel: audit(1081813913.558:0): avc: denied { getattr } for pid=973 exe=/usr/bin/procmail path=/etc/mail/spamassassin/spamassassin-default.rc dev=hda2 ino=246760 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=file Apr 12 18:51:53 homer kernel: audit(1081813913.559:0): avc: denied { read } for pid=973 exe=/usr/bin/procmail name=spamassassin-default.rc dev=hda2 ino=246760 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=file Apr 12 18:51:53 homer kernel: audit(1081813913.662:0): avc: denied { read } for pid=975 exe=/usr/bin/perl name=urandom dev=hda2 ino=798062 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 12 18:51:53 homer kernel: audit(1081813913.664:0): avc: denied { read } for pid=975 exe=/usr/bin/perl name=self dev= ino=2 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:proc_t tclass=lnk_file Apr 12 18:51:53 homer kernel: audit(1081813913.665:0): avc: denied { search } for pid=975 exe=/usr/bin/perl name=975 dev= ino=63897602 scontext=system_u:system_r:procmail_t tcontext=system_u:system_r:procmail_t tclass=dir Apr 12 18:51:53 homer kernel: audit(1081813913.665:0): avc: denied { read } for pid=975 exe=/usr/bin/perl name=exe dev= ino=63897608 scontext=system_u:system_r:procmail_t tcontext=system_u:system_r:procmail_t tclass=lnk_file Apr 12 18:51:53 homer kernel: audit(1081813913.666:0): avc: denied { getattr } for pid=975 exe=/usr/bin/perl path=/bin dev=hda2 ino=851969 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:bin_t tclass=dir Apr 12 18:51:56 homer kernel: audit(1081813916.231:0): avc: denied { search } for pid=975 exe=/usr/bin/perl name=mqueue dev=hda2 ino=1065066 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:mqueue_spool_t tclass=dir Apr 12 18:51:58 homer kernel: audit(1081813918.828:0): avc: denied { read } for pid=975 exe=/usr/bin/perl name=shadow dev=hda2 ino=246191 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 18:51:58 homer kernel: audit(1081813918.829:0): avc: denied { getattr } for pid=975 exe=/usr/bin/perl path=/etc/shadow dev=hda2 ino=246191 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 18:51:59 homer kernel: audit(1081813919.130:0): avc: denied { getattr } for pid=975 exe=/usr/bin/perl path=/usr/share/spamassassin/20_anti_ratware.cf dev=hda2 ino=2327150 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 18:51:59 homer kernel: audit(1081813919.268:0): avc: denied { read } for pid=975 exe=/usr/bin/perl name=10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 18:51:59 homer kernel: audit(1081813919.268:0): avc: denied { ioctl } for pid=975 exe=/usr/bin/perl path=/usr/share/spamassassin/10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 18:52:01 homer kernel: audit(1081813921.154:0): avc: denied { getattr } for pid=975 exe=/usr/bin/perl path=/etc/mail/spamassassin dev=hda2 ino=246658 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=dir Apr 12 18:52:01 homer kernel: audit(1081813921.155:0): avc: denied { read } for pid=975 exe=/usr/bin/perl name=spamassassin dev=hda2 ino=246658 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=dir Apr 12 18:52:01 homer kernel: audit(1081813921.156:0): avc: denied { ioctl } for pid=975 exe=/usr/bin/perl path=/etc/mail/spamassassin/local.cf dev=hda2 ino=246831 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=file Apr 12 18:52:03 homer kernel: audit(1081813923.705:0): avc: denied { net_admin } for pid=986 exe=/usr/sbin/httpd capability=12 scontext=system_u:system_r:httpd_t tcontext=system_u:system_r:httpd_t tclass=capability Apr 12 18:52:05 homer kernel: audit(1081813925.336:0): avc: denied { getattr } for pid=975 exe=/usr/bin/perl path=/var/tmp dev=hda2 ino=1064964 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:tmp_t tclass=dir Apr 12 18:52:09 homer kernel: audit(1081813929.624:0): avc: denied { setrlimit } for pid=1007 exe=/usr/sbin/smbd scontext=system_u:system_r:smbd_t tcontext=system_u:system_r:smbd_t tclass=process Apr 12 18:54:57 homer kernel: audit(1081814097.936:0): avc: denied { search } for pid=1073 exe=/usr/bin/procmail name=mail dev=hda2 ino=246478 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=dir Apr 12 18:54:57 homer kernel: audit(1081814097.937:0): avc: denied { getattr } for pid=1073 exe=/usr/bin/procmail path=/etc/mail/spamassassin/spamassassin-default.rc dev=hda2 ino=246760 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=file Apr 12 18:54:57 homer kernel: audit(1081814097.948:0): avc: denied { read } for pid=1075 exe=/usr/bin/perl name=urandom dev=hda2 ino=798062 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 12 18:54:57 homer kernel: audit(1081814097.951:0): avc: denied { read } for pid=1075 exe=/usr/bin/perl name=self dev= ino=2 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:proc_t tclass=lnk_file Apr 12 18:54:57 homer kernel: audit(1081814097.952:0): avc: denied { search } for pid=1075 exe=/usr/bin/perl name=1075 dev= ino=70451202 scontext=system_u:system_r:procmail_t tcontext=system_u:system_r:procmail_t tclass=dir Apr 12 18:54:57 homer kernel: audit(1081814097.952:0): avc: denied { read } for pid=1075 exe=/usr/bin/perl name=exe dev= ino=70451208 scontext=system_u:system_r:procmail_t tcontext=system_u:system_r:procmail_t tclass=lnk_file Apr 12 18:54:57 homer kernel: audit(1081814097.953:0): avc: denied { getattr } for pid=1075 exe=/usr/bin/perl path=/bin dev=hda2 ino=851969 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:bin_t tclass=dir Apr 12 18:54:59 homer kernel: audit(1081814099.890:0): avc: denied { read } for pid=1075 exe=/usr/bin/perl name=shadow dev=hda2 ino=246191 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 18:54:59 homer kernel: audit(1081814099.891:0): avc: denied { getattr } for pid=1075 exe=/usr/bin/perl path=/etc/shadow dev=hda2 ino=246191 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 18:54:59 homer kernel: audit(1081814099.893:0): avc: denied { getattr } for pid=1075 exe=/usr/bin/perl path=/usr/share/spamassassin/20_anti_ratware.cf dev=hda2 ino=2327150 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 18:54:59 homer kernel: audit(1081814099.896:0): avc: denied { read } for pid=1075 exe=/usr/bin/perl name=10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 18:54:59 homer kernel: audit(1081814099.897:0): avc: denied { ioctl } for pid=1075 exe=/usr/bin/perl path=/usr/share/spamassassin/10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 18:55:00 homer kernel: audit(1081814100.023:0): avc: denied { getattr } for pid=1075 exe=/usr/bin/perl path=/etc/mail/spamassassin dev=hda2 ino=246658 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=dir Apr 12 18:55:00 homer kernel: audit(1081814100.025:0): avc: denied { read } for pid=1075 exe=/usr/bin/perl name=spamassassin dev=hda2 ino=246658 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=dir Apr 12 18:55:00 homer kernel: audit(1081814100.026:0): avc: denied { ioctl } for pid=1075 exe=/usr/bin/perl path=/etc/mail/spamassassin/local.cf dev=hda2 ino=246831 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:etc_mail_t tclass=file Apr 12 19:12:59 homer kernel: audit(1081815179.382:0): avc: denied { read } for pid=1089 exe=/usr/sbin/smbd name=mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 12 19:12:59 homer kernel: audit(1081815179.383:0): avc: denied { getattr } for pid=1089 exe=/usr/sbin/smbd path=/etc/mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 12 20:01:11 homer kernel: audit(1081818071.753:0): avc: denied { setattr } for pid=1182 exe=/usr/bin/rsync name=rawhide dev=hdd1 ino=473284 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:user_home_t tclass=dir Apr 12 20:01:11 homer kernel: audit(1081818071.754:0): avc: denied { setattr } for pid=1182 exe=/usr/bin/rsync name=Archive-Update-in-Progress-carroll.aset.psu.edu dev=hdd1 ino=473288 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:user_home_t tclass=file Apr 12 20:01:12 homer kernel: audit(1081818072.235:0): avc: denied { setattr } for pid=1182 exe=/usr/bin/rsync name=Canna-libs-3.7p1-6.i386.rpm dev=hdd1 ino=522486 scontext=system_u:system_r:system_crond_t tcontext=root:object_r:user_home_t tclass=file Apr 12 20:01:16 homer kernel: audit(1081818076.850:0): avc: denied { read } for pid=1192 exe=/usr/bin/perl name=shadow dev=hda2 ino=246191 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 20:01:16 homer kernel: audit(1081818076.851:0): avc: denied { getattr } for pid=1192 exe=/usr/bin/perl path=/etc/shadow dev=hda2 ino=246191 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 20:01:16 homer kernel: audit(1081818076.854:0): avc: denied { getattr } for pid=1192 exe=/usr/bin/perl path=/usr/share/spamassassin/20_anti_ratware.cf dev=hda2 ino=2327150 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 20:01:16 homer kernel: audit(1081818076.857:0): avc: denied { read } for pid=1192 exe=/usr/bin/perl name=10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 20:01:16 homer kernel: audit(1081818076.857:0): avc: denied { ioctl } for pid=1192 exe=/usr/bin/perl path=/usr/share/spamassassin/10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 20:16:59 homer kernel: audit(1081819019.856:0): avc: denied { read } for pid=1253 exe=/usr/sbin/smbd name=mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 12 20:16:59 homer kernel: audit(1081819019.857:0): avc: denied { getattr } for pid=1253 exe=/usr/sbin/smbd path=/etc/mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 12 21:26:27 homer kernel: audit(1081823187.677:0): avc: denied { getattr } for pid=1360 exe=/usr/sbin/ipop3d path=/etc/krb5.conf dev=hda2 ino=247355 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 12 21:26:27 homer kernel: audit(1081823187.679:0): avc: denied { read } for pid=1360 exe=/usr/sbin/ipop3d name=krb5.conf dev=hda2 ino=247355 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 12 21:26:27 homer kernel: audit(1081823187.679:0): avc: denied { write } for pid=1360 exe=/usr/sbin/ipop3d name=krb5.conf dev=hda2 ino=247355 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 12 21:26:27 homer kernel: audit(1081823187.716:0): avc: denied { read } for pid=1360 exe=/usr/sbin/ipop3d name=urandom dev=hda2 ino=798062 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 12 21:26:27 homer kernel: audit(1081823187.719:0): avc: denied { getattr } for pid=1360 exe=/usr/sbin/ipop3d path=/dev/urandom dev=hda2 ino=798062 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 12 21:26:28 homer kernel: audit(1081823188.064:0): avc: denied { read } for pid=1360 exe=/usr/sbin/ipop3d name=mounts dev= ino=4105 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:proc_t tclass=lnk_file Apr 12 21:26:28 homer kernel: audit(1081823188.065:0): avc: denied { search } for pid=1360 exe=/usr/sbin/ipop3d name=1360 dev= ino=89128962 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.065:0): avc: denied { read } for pid=1360 exe=/usr/sbin/ipop3d name=mounts dev= ino=89128976 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.066:0): avc: denied { getattr } for pid=1360 exe=/usr/sbin/ipop3d path=/proc/1360/mounts dev= ino=89128976 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.116:0): avc: denied { read } for pid=1360 exe=/usr/sbin/ipop3d name=shadow dev=hda2 ino=246191 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.117:0): avc: denied { getattr } for pid=1360 exe=/usr/sbin/ipop3d path=/etc/shadow dev=hda2 ino=246191 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:shadow_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.160:0): avc: denied { search } for pid=1360 exe=/usr/sbin/ipop3d name=sys dev= ino=4120 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:sysctl_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.162:0): avc: denied { search } for pid=1360 exe=/usr/sbin/ipop3d dev=hdd1 ino=2 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:home_root_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.162:0): avc: denied { search } for pid=1360 exe=/usr/sbin/ipop3d name=mike dev=hdd1 ino=1648321 scontext=system_u:system_r:inetd_child_t tcontext=mike:object_r:user_home_dir_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.209:0): avc: denied { search } for pid=1360 exe=/usr/sbin/ipop3d name=spool dev=hda2 ino=1064995 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:var_spool_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.209:0): avc: denied { search } for pid=1360 exe=/usr/sbin/ipop3d name=mail dev=hda2 ino=1064997 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.209:0): avc: denied { getattr } for pid=1360 exe=/usr/sbin/ipop3d path=/var/spool/mail/mike dev=hda2 ino=1065833 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.210:0): avc: denied { read } for pid=1360 exe=/usr/sbin/ipop3d name=mike dev=hda2 ino=1065833 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.263:0): avc: denied { setattr } for pid=1360 exe=/usr/sbin/ipop3d name=mike dev=hda2 ino=1065833 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.269:0): avc: denied { write } for pid=1360 exe=/usr/sbin/ipop3d name=mike dev=hda2 ino=1065833 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.270:0): avc: denied { write } for pid=1360 exe=/usr/sbin/ipop3d name=mail dev=hda2 ino=1064997 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.270:0): avc: denied { add_name } for pid=1360 exe=/usr/sbin/ipop3d name=mike.lock.1081823188.1360.homer.netlyncs.com scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.270:0): avc: denied { create } for pid=1360 exe=/usr/sbin/ipop3d name=mike.lock.1081823188.1360.homer.netlyncs.com scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.272:0): avc: denied { link } for pid=1360 exe=/usr/sbin/ipop3d name=mike.lock.1081823188.1360.homer.netlyncs.com dev=hda2 ino=1065132 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.272:0): avc: denied { remove_name } for pid=1360 exe=/usr/sbin/ipop3d name=mike.lock.1081823188.1360.homer.netlyncs.com dev=hda2 ino=1065132 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 12 21:26:28 homer kernel: audit(1081823188.272:0): avc: denied { unlink } for pid=1360 exe=/usr/sbin/ipop3d name=mike.lock.1081823188.1360.homer.netlyncs.com dev=hda2 ino=1065132 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:26:28 homer kernel: audit(1081823188.273:0): avc: denied { lock } for pid=1360 exe=/usr/sbin/ipop3d path=/var/spool/mail/mike dev=hda2 ino=1065833 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 12 21:31:24 homer kernel: audit(1081823484.510:0): avc: denied { read } for pid=1361 exe=/usr/sbin/ipop3d name=mounts dev= ino=4105 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:proc_t tclass=lnk_file Apr 12 21:40:42 homer kernel: audit(1081824042.049:0): avc: denied { read } for pid=1373 exe=/usr/bin/perl name=self dev= ino=2 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:proc_t tclass=lnk_file Apr 12 21:43:58 homer kernel: audit(1081824238.654:0): avc: denied { read } for pid=829 comm=nfsd laddr=192.168.1.4 lport=2049 faddr=192.168.1.3 fport=800 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 12 21:43:58 homer kernel: audit(1081824238.717:0): avc: denied { rawip_recv } for saddr=192.168.1.3 src=800 daddr=192.168.1.4 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 12 21:43:58 homer kernel: audit(1081824238.717:0): avc: denied { rawip_recv } for saddr=192.168.1.3 src=800 daddr=192.168.1.4 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:node_t tclass=node Apr 12 21:43:58 homer kernel: audit(1081824238.717:0): avc: denied { rawip_send } for saddr=192.168.1.4 src=2049 daddr=192.168.1.3 dest=800 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 12 21:43:58 homer kernel: audit(1081824238.717:0): avc: denied { rawip_send } for saddr=192.168.1.4 src=2049 daddr=192.168.1.3 dest=800 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:node_t tclass=node Apr 12 21:43:58 homer kernel: audit(1081824238.717:0): avc: denied { write } for pid=828 comm=nfsd laddr=192.168.1.4 lport=2049 faddr=192.168.1.3 fport=800 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 12 21:50:17 homer kernel: audit(1081824617.611:0): avc: denied { read } for pid=1452 exe=/usr/bin/perl name=exe dev= ino=95158280 scontext=system_u:system_r:procmail_t tcontext=system_u:system_r:procmail_t tclass=lnk_file Apr 12 21:50:17 homer kernel: audit(1081824617.613:0): avc: denied { getattr } for pid=1452 exe=/usr/bin/perl path=/bin dev=hda2 ino=851969 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:bin_t tclass=dir Apr 12 21:50:21 homer kernel: audit(1081824621.537:0): avc: denied { getattr } for pid=1452 exe=/usr/bin/perl path=/usr/share/spamassassin/20_anti_ratware.cf dev=hda2 ino=2327150 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 21:50:21 homer kernel: audit(1081824621.540:0): avc: denied { read } for pid=1452 exe=/usr/bin/perl name=10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 21:50:21 homer kernel: audit(1081824621.540:0): avc: denied { ioctl } for pid=1452 exe=/usr/bin/perl path=/usr/share/spamassassin/10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 12 21:50:22 homer sshd[1413]: Warning! Could not relabel with system_u:object_r:sshd_devpts_t, not relabeling. Apr 12 21:51:24 homer kernel: audit(1081824684.506:0): avc: denied { search } for pid=1458 exe=/usr/sbin/ipop3d name=1458 dev= ino=95551490 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=dir Apr 12 21:51:24 homer kernel: audit(1081824684.506:0): avc: denied { read } for pid=1458 exe=/usr/sbin/ipop3d name=mounts dev= ino=95551504 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=file Apr 12 21:51:24 homer kernel: audit(1081824684.507:0): avc: denied { getattr } for pid=1458 exe=/usr/sbin/ipop3d path=/proc/1458/mounts dev= ino=95551504 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=file Apr 12 21:53:00 homer kernel: audit(1081824780.234:0): avc: denied { read } for pid=1461 exe=/usr/sbin/smbd name=mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 12 21:53:00 homer kernel: audit(1081824780.235:0): avc: denied { getattr } for pid=1461 exe=/usr/sbin/smbd path=/etc/mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 12 21:55:48 homer kernel: audit(1081824948.537:0): avc: denied { read } for pid=826 comm=nfsd laddr=192.168.1.4 lport=2049 faddr=192.168.1.3 fport=800 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 12 21:55:48 homer kernel: audit(1081824948.537:0): avc: denied { write } for pid=826 comm=nfsd laddr=192.168.1.4 lport=2049 faddr=192.168.1.3 fport=800 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 12 21:55:48 homer kernel: audit(1081824948.537:0): avc: denied { rawip_send } for pid=826 comm=nfsd saddr=192.168.1.4 src=2049 daddr=192.168.1.3 dest=800 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 12 21:55:48 homer kernel: audit(1081824948.538:0): avc: denied { rawip_send } for pid=826 comm=nfsd saddr=192.168.1.4 src=2049 daddr=192.168.1.3 dest=800 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:node_t tclass=node Apr 12 21:55:48 homer kernel: audit(1081824948.538:0): avc: denied { rawip_recv } for pid=725 exe=/sbin/klogd saddr=192.168.1.3 src=800 daddr=192.168.1.4 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 12 21:55:48 homer kernel: audit(1081824948.538:0): avc: denied { rawip_recv } for pid=725 exe=/sbin/klogd saddr=192.168.1.3 src=800 daddr=192.168.1.4 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:node_t tclass=node Apr 12 22:38:14 homer kernel: audit(1081827494.725:0): avc: denied { search } for pid=1069 exe=/usr/sbin/httpd name=mysql dev=hda2 ino=1081669 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:mysqld_db_t tclass=dir Apr 12 22:38:14 homer kernel: audit(1081827494.725:0): avc: denied { write } for pid=1069 exe=/usr/sbin/httpd name=mysql.sock dev=hda2 ino=1802291 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:mysqld_db_t tclass=sock_file Apr 12 22:38:14 homer kernel: audit(1081827494.726:0): avc: denied { connectto } for pid=1069 exe=/usr/sbin/httpd path=/var/lib/mysql/mysql.sock scontext=system_u:system_r:httpd_t tcontext=system_u:system_r:initrc_t tclass=unix_stream_socket Apr 12 22:40:26 homer kernel: audit(1081827626.397:0): avc: denied { getattr } for pid=838 exe=/usr/sbin/rpc.mountd path=/proc/fs/nfsd/filehandle dev= ino=10 scontext=system_u:system_r:nfsd_t tcontext=system_u:object_r:nfsd_fs_t tclass=file Apr 12 23:55:20 homer kernel: audit(1081832120.161:0): avc: denied { search } for pid=1068 exe=/usr/sbin/httpd name=mysql dev=hda2 ino=1081669 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:mysqld_db_t tclass=dir Apr 13 00:00:00 homer kernel: audit(1081832400.471:0): avc: denied { read } for pid=1670 exe=/usr/bin/perl name=exe dev= ino=109445128 scontext=system_u:system_r:procmail_t tcontext=system_u:system_r:procmail_t tclass=lnk_file Apr 13 00:00:00 homer kernel: audit(1081832400.472:0): avc: denied { getattr } for pid=1670 exe=/usr/bin/perl path=/bin dev=hda2 ino=851969 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:bin_t tclass=dir Apr 13 00:00:04 homer kernel: audit(1081832404.255:0): avc: denied { getattr } for pid=1670 exe=/usr/bin/perl path=/usr/share/spamassassin/20_anti_ratware.cf dev=hda2 ino=2327150 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 13 00:00:04 homer kernel: audit(1081832404.258:0): avc: denied { read } for pid=1670 exe=/usr/bin/perl name=10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 13 00:00:04 homer kernel: audit(1081832404.259:0): avc: denied { ioctl } for pid=1670 exe=/usr/bin/perl path=/usr/share/spamassassin/10_misc.cf dev=hda2 ino=2326781 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:usr_t tclass=file Apr 13 00:01:00 homer kernel: audit(1081832460.817:0): avc: denied { read } for pid=1678 exe=/usr/sbin/smbd name=mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 13 00:01:00 homer kernel: audit(1081832460.818:0): avc: denied { getattr } for pid=1678 exe=/usr/sbin/smbd path=/etc/mtab dev=hda2 ino=247415 scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 13 00:01:05 homer kernel: audit(1081832465.152:0): avc: denied { setattr } for pid=1676 exe=/usr/bin/rsync name=rawhide dev=hdd1 ino=473284 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:user_home_t tclass=dir Apr 13 00:01:05 homer kernel: audit(1081832465.153:0): avc: denied { setattr } for pid=1676 exe=/usr/bin/rsync name=Archive-Update-in-Progress-carroll.aset.psu.edu dev=hdd1 ino=473288 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:user_home_t tclass=file Apr 13 00:01:05 homer kernel: audit(1081832465.634:0): avc: denied { setattr } for pid=1676 exe=/usr/bin/rsync name=Canna-libs-3.7p1-6.i386.rpm dev=hdd1 ino=522486 scontext=system_u:system_r:system_crond_t tcontext=root:object_r:user_home_t tclass=file Apr 13 02:33:18 homer kernel: audit(1081841598.434:0): avc: denied { getattr } for pid=1894 exe=/usr/sbin/ipop3d path=/etc/krb5.conf dev=hda2 ino=247355 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 13 02:33:18 homer kernel: audit(1081841598.435:0): avc: denied { read } for pid=1894 exe=/usr/sbin/ipop3d name=krb5.conf dev=hda2 ino=247355 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 13 02:33:18 homer kernel: audit(1081841598.436:0): avc: denied { write } for pid=1894 exe=/usr/sbin/ipop3d name=krb5.conf dev=hda2 ino=247355 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 13 02:33:18 homer kernel: audit(1081841598.438:0): avc: denied { read } for pid=1894 exe=/usr/sbin/ipop3d name=urandom dev=hda2 ino=798062 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 13 02:33:18 homer kernel: audit(1081841598.439:0): avc: denied { getattr } for pid=1894 exe=/usr/sbin/ipop3d path=/dev/urandom dev=hda2 ino=798062 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 13 02:33:19 homer kernel: audit(1081841599.251:0): avc: denied { read } for pid=1894 exe=/usr/sbin/ipop3d name=mounts dev= ino=4105 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:proc_t tclass=lnk_file Apr 13 02:33:19 homer kernel: audit(1081841599.251:0): avc: denied { search } for pid=1894 exe=/usr/sbin/ipop3d name=1894 dev= ino=124125186 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.251:0): avc: denied { read } for pid=1894 exe=/usr/sbin/ipop3d name=mounts dev= ino=124125200 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.251:0): avc: denied { getattr } for pid=1894 exe=/usr/sbin/ipop3d path=/proc/1894/mounts dev= ino=124125200 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_child_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.255:0): avc: denied { read } for pid=1894 exe=/usr/sbin/ipop3d name=shadow dev=hda2 ino=246191 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:shadow_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.256:0): avc: denied { getattr } for pid=1894 exe=/usr/sbin/ipop3d path=/etc/shadow dev=hda2 ino=246191 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:shadow_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.261:0): avc: denied { search } for pid=1894 exe=/usr/sbin/ipop3d name=sys dev= ino=4120 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:sysctl_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.267:0): avc: denied { search } for pid=1894 exe=/usr/sbin/ipop3d dev=hdd1 ino=2 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:home_root_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.267:0): avc: denied { search } for pid=1894 exe=/usr/sbin/ipop3d name=brad dev=hdd1 ino=734401 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:user_home_dir_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.287:0): avc: denied { search } for pid=1894 exe=/usr/sbin/ipop3d name=spool dev=hda2 ino=1064995 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:var_spool_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.288:0): avc: denied { search } for pid=1894 exe=/usr/sbin/ipop3d name=mail dev=hda2 ino=1064997 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.288:0): avc: denied { getattr } for pid=1894 exe=/usr/sbin/ipop3d path=/var/spool/mail/brad dev=hda2 ino=1065835 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.289:0): avc: denied { read } for pid=1894 exe=/usr/sbin/ipop3d name=brad dev=hda2 ino=1065835 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.339:0): avc: denied { setattr } for pid=1894 exe=/usr/sbin/ipop3d name=brad dev=hda2 ino=1065835 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.401:0): avc: denied { write } for pid=1894 exe=/usr/sbin/ipop3d name=brad dev=hda2 ino=1065835 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.401:0): avc: denied { write } for pid=1894 exe=/usr/sbin/ipop3d name=mail dev=hda2 ino=1064997 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.402:0): avc: denied { add_name } for pid=1894 exe=/usr/sbin/ipop3d name=brad.lock.1081841599.1894.homer.netlyncs.com scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.402:0): avc: denied { create } for pid=1894 exe=/usr/sbin/ipop3d name=brad.lock.1081841599.1894.homer.netlyncs.com scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.403:0): avc: denied { link } for pid=1894 exe=/usr/sbin/ipop3d name=brad.lock.1081841599.1894.homer.netlyncs.com dev=hda2 ino=1065132 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.404:0): avc: denied { remove_name } for pid=1894 exe=/usr/sbin/ipop3d name=brad.lock.1081841599.1894.homer.netlyncs.com dev=hda2 ino=1065132 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=dir Apr 13 02:33:19 homer kernel: audit(1081841599.404:0): avc: denied { unlink } for pid=1894 exe=/usr/sbin/ipop3d name=brad.lock.1081841599.1894.homer.netlyncs.com dev=hda2 ino=1065132 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:33:19 homer kernel: audit(1081841599.404:0): avc: denied { lock } for pid=1894 exe=/usr/sbin/ipop3d path=/var/spool/mail/brad dev=hda2 ino=1065835 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:mail_spool_t tclass=file Apr 13 02:42:31 homer kernel: audit(1081842151.034:0): avc: denied { read } for pid=827 comm=nfsd laddr=192.168.1.4 lport=2049 faddr=192.168.1.3 fport=800 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 13 02:42:31 homer kernel: audit(1081842151.098:0): avc: denied { rawip_recv } for pid=1446 exe=/home/mike/Seti/setiathome saddr=192.168.1.3 src=800 daddr=192.168.1.4 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 13 02:42:31 homer kernel: audit(1081842151.099:0): avc: denied { rawip_recv } for pid=1446 exe=/home/mike/Seti/setiathome saddr=192.168.1.3 src=800 daddr=192.168.1.4 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:node_t tclass=node Apr 13 02:42:31 homer kernel: audit(1081842151.099:0): avc: denied { rawip_send } for pid=1446 exe=/home/mike/Seti/setiathome saddr=192.168.1.4 src=2049 daddr=192.168.1.3 dest=800 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 13 02:42:31 homer kernel: audit(1081842151.099:0): avc: denied { rawip_send } for pid=1446 exe=/home/mike/Seti/setiathome saddr=192.168.1.4 src=2049 daddr=192.168.1.3 dest=800 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:node_t tclass=node Apr 13 02:42:31 homer kernel: audit(1081842151.108:0): avc: denied { write } for pid=828 comm=nfsd laddr=192.168.1.4 lport=2049 faddr=192.168.1.3 fport=800 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 13 03:02:02 homer kernel: audit(1081843322.045:0): avc: denied { write } for pid=1944 exe=/usr/bin/python name=run dev=hda2 ino=1064994 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:var_run_t tclass=dir Apr 13 03:02:02 homer kernel: audit(1081843322.045:0): avc: denied { add_name } for pid=1944 exe=/usr/bin/python name=epylog.pid scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:var_run_t tclass=dir Apr 13 03:02:02 homer kernel: audit(1081843322.045:0): avc: denied { create } for pid=1944 exe=/usr/bin/python name=epylog.pid scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:var_run_t tclass=file I do see some things in the log that might be 3rd party, such as setiathome and epylog which is how I get my logs but wasn't sure if this only involved those or others, such as POP3. Sorry to flood the list, but wasn't sure how to show these. -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt...Then it's hilarious!" From russell at coker.com.au Tue Apr 13 13:36:53 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 13 Apr 2004 23:36:53 +1000 Subject: Kernel audit messages In-Reply-To: <1081852600.2582.6.camel@bart.netlyncs.com> References: <1081852600.2582.6.camel@bart.netlyncs.com> Message-ID: <200404132336.53693.russell@coker.com.au> On Tue, 13 Apr 2004 20:36, Mike Chambers wrote: > I have found these this morning in my logs after the latest kernel from > rawhide on a FC2T2 system... I've attached a new procmail policy, please check it out. I would like to know what procmail is doing with Perl, is it just for spamassasin? If so then we probably need a domain transition. In any case we don't want to grant procmail_t access to shadow_t. Either the access is not needed and we can use a dontaudit, or we need to change procmail to use unix_chkpwd or some other method of doing whatever it may want to do. It's bad enough that we have to grant RADIUS servers access to it! -- 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 -------------- #DESC Procmail - Mail delivery agent for mail servers # # Author: Russell Coker # X-Debian-Packages: procmail # ################################# # # Rules for the procmail_t domain. # # procmail_exec_t is the type of the procmail executable. # # privhome only works until we define a different type for maildir type procmail_t, domain, privlog, privhome; type procmail_exec_t, file_type, sysadmfile, exec_type; role system_r types procmail_t; uses_shlib(procmail_t) allow procmail_t device_t:dir search; can_network(procmail_t) can_ypbind(procmail_t) allow procmail_t self:capability { sys_nice chown setuid setgid dac_override }; allow procmail_t etc_t:dir r_dir_perms; allow procmail_t { etc_t etc_runtime_t }:file { getattr read }; allow procmail_t etc_t:lnk_file read; read_locale(procmail_t) read_sysctl(procmail_t) allow procmail_t sysctl_t:dir search; allow procmail_t self:process { setsched fork sigchld signal }; can_exec(procmail_t, { bin_t shell_exec_t }) allow procmail_t bin_t:dir { getattr search }; allow procmail_t bin_t:lnk_file read; allow procmail_t self:fifo_file rw_file_perms; allow procmail_t self:unix_stream_socket create_socket_perms; allow procmail_t self:unix_dgram_socket create_socket_perms; # for /var/mail rw_dir_create_file(procmail_t, mail_spool_t) allow procmail_t var_t:dir { getattr search }; allow procmail_t var_spool_t:dir r_dir_perms; allow procmail_t fs_t:filesystem getattr; allow procmail_t { self proc_t }:dir search; allow procmail_t proc_t:file { getattr read }; allow procmail_t { self proc_t }:lnk_file read; # for if /var/mail is a symlink to /var/spool/mail #allow procmail_t mail_spool_t:lnk_file r_file_perms; # for spamassasin allow procmail_t usr_t:file { getattr ioctl read }; # Search /var/run. allow procmail_t var_run_t:dir { getattr search }; # Do not audit attempts to access /root. dontaudit procmail_t sysadm_home_dir_t:dir { getattr search }; allow procmail_t devtty_t:chr_file { read write }; allow procmail_t urandom_device_t:chr_file { getattr read }; ifdef(`sendmail.te', ` r_dir_file(procmail_t, etc_mail_t) ') From russell at coker.com.au Tue Apr 13 13:48:42 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 13 Apr 2004 23:48:42 +1000 Subject: SELinux and Oracle Database 10g In-Reply-To: References: Message-ID: <200404132348.42171.russell@coker.com.au> On Tue, 13 Apr 2004 13:49, Werner Puschitz wrote: > Is anyone working on a policy for Oracle 10g yet? > > I'm thinking about writing an article that will cover the whole process of > securing an Oracle database 10g using MAC. And I'm also thinking about > writing a policy for Oracle Database 10g and for Oracle's Real Application > Cluster (RAC). > > If anyone is already working on it, please let me know. It's on my todo list. I've downloaded the necesary Oracle files, but haven't got around to doing anything with them yet. As I lack any significant Oracle experience I figure that I need to dedicate at least a day of non-stop work to it, and I've got lots of other things happening at the moment. But I'll get on to it soon! -- 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 jmorris at redhat.com Tue Apr 13 14:04:06 2004 From: jmorris at redhat.com (James Morris) Date: Tue, 13 Apr 2004 10:04:06 -0400 (EDT) Subject: Some questions relating to selinux In-Reply-To: <200404121044.51034.gene@czarc.net> Message-ID: On Mon, 12 Apr 2004, Gene Czarcinski wrote: > 8. Is there someplace that describes the differences between the various > policy versions (15, 16, 17, etc.)? Version 16 added boolean policy support, and version 17 adds ipv6 support. - James -- James Morris From russell at coker.com.au Tue Apr 13 14:08:46 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 14 Apr 2004 00:08:46 +1000 Subject: SELinux for RHEL3 In-Reply-To: <185722124.1081778508@[192.168.0.3]> References: <320328467.1081180117@[192.168.0.3]> <200404122346.19653.russell@coker.com.au> <185722124.1081778508@[192.168.0.3]> Message-ID: <200404140008.46590.russell@coker.com.au> On Tue, 13 Apr 2004 07:01, Bill McCarty wrote: > Actually, in the case of RHEL 3, I was hoping to deploy, more than to > learn. I obviously understand that the RHEL 3 packages that were once > available are unsupported beta (alpha?) software. But, that's good enough > for some of my purposes . The problem with RHEL 3 is that some changes to significant parts of it are needed, coreutils, PAM, sysvinit, and a few others. The advantage for using RHEL 3 in production is that it's not changing much, so as long as those few packages aren't updated you don't need to re-compile anything. If those packages are updated then someone will have to recompile the SE Linux versions. Also there are some programs such as userhelper which have had SE Linux support added for which you probably wouldn't want to do a RHEL 3 port. This means that your RHEL 3 machine will lack some of the SE Linux functionality that Fedora has (you will need RHEL 4 for full functionality). -- 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 russell at coker.com.au Tue Apr 13 14:26:36 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 14 Apr 2004 00:26:36 +1000 Subject: sshd -- cannot relabel with system_u:object_r:sshd_devpts_t In-Reply-To: <20040413010346.GC26151@xtl1.xtl.tenegg.com> References: <20040413010346.GC26151@xtl1.xtl.tenegg.com> Message-ID: <200404140026.36245.russell@coker.com.au> On Tue, 13 Apr 2004 11:03, Tom Mitchell wrote: > I just killed a remote terminal window and noted this message triple in the > log/messages: > > sshd(pam_unix)[30912]: session opened for user root by (uid=0) > > sshd[30912]: Warning! Could not relabel with > system_u:object_r:sshd_devpts_t, not relabeling. What version of pam do you have installed? It should not even be trying to relabel a pty back to it's original type. The idea is that if someone exploits a copy of sshd we want to make it as difficult as possible to trick it into granting access to another user's session. Allowing sshd to label terminals back from userpty_type makes things easier for an attacker. > If this is what I think it is sshd will slowly run out of available ptys. I've noticed that 2.6 kernels don't seem to reuse pty numbers until they reach some large number. I don't think that there's any problem of running out of available ptys, it seems to handle things the same way in permissive and enforcing modes. -- 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 bmccarty at pt-net.net Tue Apr 13 14:42:21 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Tue, 13 Apr 2004 07:42:21 -0700 Subject: SELinux for RHEL3 In-Reply-To: <200404140008.46590.russell@coker.com.au> References: <320328467.1081180117@[192.168.0.3]> <200404122346.19653.russell@coker.com.au> <185722124.1081778508@[192.168.0.3]> <200404140008.46590.russell@coker.com.au> Message-ID: <249354663.1081842141@[192.168.0.3]> Hi Russell, --On Wednesday, April 14, 2004 12:08 AM +1000 Russell Coker wrote: > The problem with RHEL 3 is that some changes to significant parts of it > are needed, coreutils, PAM, sysvinit, and a few others. The advantage > for using RHEL 3 in production is that it's not changing much, so as > long as those few packages aren't updated you don't need to re-compile > anything. If those packages are updated then someone will have to > recompile the SE Linux versions. Yes, we're in close agreement: there's a significant burden involved in running SELinux under RHEL. Only those who're comfortable tweaking source code should even consider doing so. I'm a bit crazy : I've actually backported SELinux to RHL 7.x for use in an appliance based on that release. But, I've only gotten as far as coaxing the code to compile; I haven't yet done any testing. When I do, I may find that I have a lot more work to do . > Also there are some programs such as userhelper which have had SE Linux > support added for which you probably wouldn't want to do a RHEL 3 port. > This means that your RHEL 3 machine will lack some of the SE Linux > functionality that Fedora has (you will need RHEL 4 for full > functionality). Yes, these added features are a real convenience. But, I don't find them an absolute necessity. The long maintenance horizon of RHEL 3 helps offset their absence. With respect to RHEL 4, I'm hoping for an SELinux Christmas . Cheers, --------------------------------------------------- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From mike at flyn.org Tue Apr 13 13:12:09 2004 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 13 Apr 2004 08:12:09 -0500 Subject: X and SELinux on PowerPC Message-ID: <20040413131209.GA2128@imp.flyn.org> Has anyone had any luck with Fedora/SELinux on the PowerPC platform? On my PowerPC-based system, x.org's server wishes to access /proc/sys/dev (probably for mac_hid/mouse emulation) and /proc/bus/pci. When I set SELinux to enforce, these operations are blocked and X does not start. Here are the relavent logs: avc: denied { search } for pid=1504 exe=/usr/X11R6/bin/XFree86 name=dev +dev= ino=5303 scontext=system_u:system_r:xdm_xserver_t +tcontext=system_u:object_r:sysctl_dev_t tclass=dir avc: denied { getattr } for pid=1504 exe=/usr/X11R6/bin/XFree86 +path=/proc/bus/pci dev= ino=5458 scontext=system_u:system_r:xdm_xserver_t +tcontext=system_u:object_r:proc_t tclass=dir Perhaps x86's X server not touch these directories? I assume this policy works on x86 because I haven't seen any mention of this on fedora-dev or -test. Adding the following to xserver_macros.te gets X to load on PowerPC: # Access /proc/bus/pci allow $1_xserver_t proc_t:dir { getattr read }; However, I don't know if this is the correct way to do this. I'm not even sure exactly why X is trying to read from /proc/bus/pci. -- Mike :wq From mitch48 at sbcglobal.net Tue Apr 13 18:07:04 2004 From: mitch48 at sbcglobal.net (Tom Mitchell) Date: Tue, 13 Apr 2004 11:07:04 -0700 Subject: sshd -- cannot relabel with system_u:object_r:sshd_devpts_t In-Reply-To: <200404140026.36245.russell@coker.com.au> References: <20040413010346.GC26151@xtl1.xtl.tenegg.com> <200404140026.36245.russell@coker.com.au> Message-ID: <20040413180704.GB713@xtl1.xtl.tenegg.com> On Wed, Apr 14, 2004 at 12:26:36AM +1000, Russell Coker wrote: > On Tue, 13 Apr 2004 11:03, Tom Mitchell wrote: > > I just killed a remote terminal window and noted this message triple in the > > log/messages: > > > > sshd(pam_unix)[30912]: session opened for user root by (uid=0) > > > > sshd[30912]: Warning! Could not relabel with > > system_u:object_r:sshd_devpts_t, not relabeling. > > What version of pam do you have installed? It should not even be trying to # rpm -qa | grep pam pam-0.77-38 # rpm -q --whatprovides /usr/sbin/sshd openssh-server-3.6.1p2-34 > relabel a pty back to it's original type. The idea is that if someone > exploits a copy of sshd we want to make it as difficult as possible to trick > it into granting access to another user's session. Allowing sshd to label > terminals back from userpty_type makes things easier for an attacker. > > > If this is what I think it is sshd will slowly run out of available ptys. > > I've noticed that 2.6 kernels don't seem to reuse pty numbers until they reach > some large number. I don't think that there's any problem of running out of > available ptys, it seems to handle things the same way in permissive and > enforcing modes. Thanks I am less concerned now. Running out of pty's can take a while so that end point might have been lightly tested. -- T o m M i t c h e l l /dev/null the ultimate in secure storage. From anurupmishra1 at yahoo.com Tue Apr 13 21:09:00 2004 From: anurupmishra1 at yahoo.com (Anurup Mishra) Date: Tue, 13 Apr 2004 14:09:00 -0700 (PDT) Subject: How to determine the role of a user Message-ID: <20040413210900.81712.qmail@web80808.mail.yahoo.com> Hi, I am new to SELinux and recently I am able to install Fedora Core 2 test 2 on on machine. I want to implement a role based access control in one of my Java Stand Alone application. During experimentation, when I tried to find the context of an another user as root, I got following message: [root at v60x-1 root]# id --context n1gsps id: cannot display context when selinux not enabled or when displaying the id of a different user Now my first question is how do I figure out the role of another user. Do I need to tweak the policy to achieve this?? Could someone please navigate me on this. Second, how do I figure out the role of a user from a Java Application. As of now I am trying id command from java exec. Please suggest if you know any better alternative. warm regards, Anurup Mishra __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From dwalsh at redhat.com Tue Apr 13 23:23:39 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 Apr 2004 19:23:39 -0400 Subject: How to determine the role of a user In-Reply-To: <20040413210900.81712.qmail@web80808.mail.yahoo.com> References: <20040413210900.81712.qmail@web80808.mail.yahoo.com> Message-ID: <407C767B.8030405@redhat.com> Anurup Mishra wrote: >Hi, > >I am new to SELinux and recently I am able to install >Fedora Core 2 test 2 on on machine. > >I want to implement a role based access control in one >of my Java Stand Alone application. > >During experimentation, when I tried to find the >context of an another user as root, I got following >message: >[root at v60x-1 root]# id --context n1gsps >id: cannot display context when selinux not enabled or >when displaying the id of a different user > >Now my first question is how do I figure out the role >of another user. Do I need to tweak the policy to >achieve this?? Could someone please navigate me on >this. > >Second, how do I figure out the role of a user from a >Java Application. As of now I am trying id command >from java exec. Please suggest if you know any better >alternative. > >warm regards, > >Anurup Mishra > > > ps Z | grep username would give you all the processes run by the user, and the context they are running in. Since a user can be in multiple roles in different process id -Z username does not make sense. > > >__________________________________ >Do you Yahoo!? >Yahoo! Tax Center - File online by April 15th >http://taxes.yahoo.com/filing.html >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From mike at netlyncs.com Wed Apr 14 00:09:47 2004 From: mike at netlyncs.com (Mike Chambers) Date: Tue, 13 Apr 2004 19:09:47 -0500 Subject: Kernel audit messages In-Reply-To: <200404132336.53693.russell@coker.com.au> References: <1081852600.2582.6.camel@bart.netlyncs.com> <200404132336.53693.russell@coker.com.au> Message-ID: <1081901387.2909.10.camel@bart.netlyncs.com> On Tue, 2004-04-13 at 08:36, Russell Coker wrote: > On Tue, 13 Apr 2004 20:36, Mike Chambers wrote: > > I have found these this morning in my logs after the latest kernel from > > rawhide on a FC2T2 system... > > I've attached a new procmail policy, please check it out. > > I would like to know what procmail is doing with Perl, is it just for > spamassasin? If so then we probably need a domain transition. > > In any case we don't want to grant procmail_t access to shadow_t. Either the > access is not needed and we can use a dontaudit, or we need to change > procmail to use unix_chkpwd or some other method of doing whatever it may > want to do. It's bad enough that we have to grant RADIUS servers access to > it! I've copied your procmail.te file to replace the other one. Do I have to relabel or do anything else for it to take effect? I am planning on doing an upgrade here in the next few minutes which I believe updates my policy rpm to policy-1.11.2. Would that do it auto or even overwrite the .te file? -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt...Then it's hilarious!" From pmatilai at welho.com Wed Apr 14 05:41:02 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 14 Apr 2004 08:41:02 +0300 (EEST) Subject: A typo/thinko in current policy wrt synaptic + an ldconfig issue Message-ID: Hi, There's a small typo/thinko in current policy (1.11.1-2) wrt synaptic: it says "apt-synaptic" when it should be just "synaptic". Other than that apt seems to mostly work ok with enforcing mode on but it gets denied when running ldconfig (as the interpreter, if that's of relevance) in package %post: denied { read } for pid=1332 exe=/sbin/ldconfig name=liblcms.so.1.0.12 dev=hda2 ino=1170323 scontext=root:sysamd_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file (and then the same with { getattr }) Well, in fact I get the same error if I try to run /sbin/ldconfig as root:sysadm_r:sysadm_t which feels kinda curious :) but what baffles me is that when installing that package with rpm itself it doesn't complain. I would've thought having apt-get marked as system_u:object_r:rpm_exec_t meant that it's got exactly the same priviledges as rpm does but apparently not so... - Panu - From russell at coker.com.au Wed Apr 14 08:07:07 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 14 Apr 2004 18:07:07 +1000 Subject: Kernel audit messages In-Reply-To: <1081901387.2909.10.camel@bart.netlyncs.com> References: <1081852600.2582.6.camel@bart.netlyncs.com> <200404132336.53693.russell@coker.com.au> <1081901387.2909.10.camel@bart.netlyncs.com> Message-ID: <200404141807.07588.russell@coker.com.au> On Wed, 14 Apr 2004 10:09, Mike Chambers wrote: > I've copied your procmail.te file to replace the other one. ?Do I have > to relabel or do anything else for it to take effect? ?I am planning on Just copy it over and run "make load" to apply the change. > doing an upgrade here in the next few minutes which I believe updates my > policy rpm to policy-1.11.2. ?Would that do it auto or even overwrite > the .te file? It should not over-write it. -- 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 russell at coker.com.au Wed Apr 14 08:23:03 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 14 Apr 2004 18:23:03 +1000 Subject: X and SELinux on PowerPC In-Reply-To: <20040413131209.GA2128@imp.flyn.org> References: <20040413131209.GA2128@imp.flyn.org> Message-ID: <200404141823.03789.russell@coker.com.au> On Tue, 13 Apr 2004 23:12, "W. Michael Petullo" wrote: > Has anyone had any luck with Fedora/SELinux on the PowerPC platform? I guess you're the first to try it! ;) I've attached a new xserver_macros.te file, please try it out. -- 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 -------------- # # Macros for X server domains. # # # Authors: Stephen Smalley and Timothy Fraser # ################################# # # xserver_domain(domain_prefix) # # Define a derived domain for the X server when executed # by a user domain (e.g. via startx). See the xdm_t domain # in domains/program/xdm.te if using an X Display Manager. # # The type declarations for the executable type for this program # and the log type are provided separately in domains/program/xserver.te. # # FIXME! The X server requires far too many privileges. # undefine(`xserver_domain') ifdef(`xserver.te', ` define(`xserver_domain',` # Derived domain based on the calling user domain and the program. ifdef(`rpm.te', ` type $1_xserver_t, domain, privlog, privmem, privmodule; allow $1_xserver_t sysctl_modprobe_t:file { getattr read }; ', ` type $1_xserver_t, domain, privlog, privmem; ') # for SSP allow $1_xserver_t urandom_device_t:chr_file { getattr read ioctl }; # Transition from the user domain to this domain. ifelse($1, xdm, ` ifdef(`xdm.te', ` domain_auto_trans(xdm_t, xserver_exec_t, xdm_xserver_t) ') domain_auto_trans(initrc_t, xserver_exec_t, xdm_xserver_t) ', ` domain_auto_trans($1_t, xserver_exec_t, $1_xserver_t) ')dnl end ifelse xdm uses_shlib($1_xserver_t) can_network($1_xserver_t) allow $1_xserver_t xserver_port_t:tcp_socket name_bind; # for access within the domain general_domain_access($1_xserver_t) allow $1_xserver_t etc_runtime_t:file { getattr read }; ifelse($1, xdm, ` # The system role is authorised for the xdm and initrc domains role system_r types xdm_xserver_t; allow xdm_xserver_t init_t:fd use; dontaudit xdm_xserver_t sysadm_home_dir_t:dir { read search }; ', ` # The user role is authorized for this domain. role $1_r types $1_xserver_t; allow $1_xserver_t getty_t:fd use; allow $1_xserver_t local_login_t:fd use; allow $1_xserver_t $1_tty_device_t:chr_file { setattr rw_file_perms }; can_unix_connect($1_t, $1_xserver_t) # Access the home directory. allow $1_xserver_t home_root_t:dir search; allow $1_xserver_t $1_home_dir_t:dir { getattr search }; ifdef(`allow_xserver_home_fonts', ` r_dir_file($1_xserver_t, $1_home_t) ') ifdef(`xauth.te', ` allow $1_xserver_t $1_home_xauth_t:file { getattr read }; ', ` allow $1_xserver_t $1_home_t:file { getattr read }; ')dnl end ifdef xauth ifdef(`userhelper.te', ` allow $1_xserver_t userhelper_conf_t:dir search; ')dnl end ifdef userhelper ')dnl end ifelse xdm allow $1_xserver_t fs_t:filesystem getattr; allow $1_xserver_t proc_t:dir { getattr search }; # XFree86-4 wants to check if kernel is tainted allow $1_xserver_t { sysctl_t sysctl_kernel_t }:dir search; allow $1_xserver_t sysctl_kernel_t:file { getattr read }; # Use capabilities. # allow setuid/setgid for the wrapper program to change UID # sys_rawio is for iopl access - should not be needed for frame-buffer # sys_admin, locking shared mem? chowning IPC message queues or semaphores? # admin of APM bios? # sys_nice is so that the X server can set a negative nice value allow $1_xserver_t self:capability { dac_override setuid setgid sys_rawio sys_admin sys_nice sys_tty_config }; allow $1_xserver_t self:capability ipc_owner; # memory_device_t access is needed if not using the frame buffer #dontaudit $1_xserver_t memory_device_t:chr_file read; allow $1_xserver_t memory_device_t:chr_file { rw_file_perms execute }; # net_bind_service is needed if you want your X server to allow TCP connections # from other hosts, EG an XDM serving a network of X terms # if you want good security you do not want this # not sure why some people want chown, fsetid, and sys_tty_config. #allow $1_xserver_t self:capability { net_bind_service chown fsetid sys_tty_config }; dontaudit $1_xserver_t self:capability chown; # for nscd dontaudit $1_xserver_t var_run_t:dir search; allow $1_xserver_t mtrr_device_t:file rw_file_perms; allow $1_xserver_t apm_bios_t:chr_file rw_file_perms; allow $1_xserver_t framebuf_device_t:chr_file rw_file_perms; allow $1_xserver_t devtty_t:chr_file rw_file_perms; allow $1_xserver_t devtty_t:lnk_file read; # Type for temporary files. tmp_domain($1_xserver) file_type_auto_trans($1_xserver_t, xdm_xserver_tmp_t, $1_xserver_tmp_t, sock_file) ifelse($1, xdm, `', ` allow $1_t xdm_xserver_tmp_t:dir r_dir_perms; allow $1_t $1_xserver_t:process signal; # Allow the user domain to connect to the X server. allow $1_t $1_xserver_tmp_t:sock_file rw_file_perms; allow $1_t $1_xserver_tmp_t:dir r_dir_perms; ifdef(`xdm.te', ` allow $1_t xdm_tmp_t:sock_file { unlink }; ') # Signal the user domain. allow $1_xserver_t $1_t:process signal; # for /tmp/.ICE-unix file_type_auto_trans($1_t, xdm_xserver_tmp_t, $1_tmp_t, sock_file) ')dnl end ifelse xdm # Create files in /var/log with the xserver_log_t type. allow $1_xserver_t var_t:dir search; file_type_auto_trans($1_xserver_t, var_log_t, xserver_log_t, file) allow $1_xserver_t xserver_log_t:dir r_dir_perms; # Access AGP device. allow $1_xserver_t agp_device_t:chr_file rw_file_perms; # for other device nodes such as the NVidia binary-only driver allow $1_xserver_t xserver_misc_device_t:chr_file rw_file_perms; # Access /proc/mtrr allow $1_xserver_t proc_t:file rw_file_perms; # Access /proc/sys/dev allow $1_xserver_t sysctl_dev_t:dir search; allow $1_xserver_t sysctl_dev_t:file { getattr read }; # Create and access /dev/dri devices. allow $1_xserver_t dri_device_t:dir { setattr rw_dir_perms }; allow $1_xserver_t dri_device_t:chr_file create_file_perms; allow $1_xserver_t tty_device_t:chr_file { setattr rw_file_perms }; # Run helper programs in $1_xserver_t. can_exec_any($1_xserver_t) # Connect to xfs. ifdef(`xfs.te', ` can_unix_connect($1_xserver_t, xfs_t) allow $1_xserver_t xfs_tmp_t:dir r_dir_perms; allow $1_xserver_t xfs_tmp_t:sock_file rw_file_perms; # Bind to the X server socket in /tmp. allow $1_xserver_t $1_xserver_tmp_t:unix_stream_socket name_bind; ') read_locale($1_xserver_t) # Type for tmpfs/shm files. tmpfs_domain($1_xserver) ifelse($1, xdm, `', ` allow $1_xserver_t $1_t:shm rw_shm_perms; allow $1_xserver_t $1_tmpfs_t:file rw_file_perms; ')dnl end ifelse xdm ifdef(`xdm.te', ` allow xdm_xserver_t xdm_t:shm rw_shm_perms; allow xdm_xserver_t xdm_tmpfs_t:file rw_file_perms; ') # Use the mouse. allow $1_xserver_t mouse_device_t:chr_file rw_file_perms; allow $1_xserver_t var_lib_t:dir search; rw_dir_create_file($1_xserver_t, var_lib_xkb_t) # for fonts r_dir_file($1_xserver_t, fonts_t) ')dnl end macro definition ', ` define(`xserver_domain',`') ') From dwalsh at redhat.com Wed Apr 14 12:29:00 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Apr 2004 08:29:00 -0400 Subject: A typo/thinko in current policy wrt synaptic + an ldconfig issue In-Reply-To: References: Message-ID: <407D2E8C.6090801@redhat.com> Panu Matilainen wrote: >Hi, > >There's a small typo/thinko in current policy (1.11.1-2) wrt synaptic: it >says "apt-synaptic" when it should be just "synaptic". > >Other than that apt seems to mostly work ok with enforcing mode on but it >gets denied when running ldconfig (as the interpreter, if that's of >relevance) in package %post: >denied { read } for pid=1332 exe=/sbin/ldconfig name=liblcms.so.1.0.12 >dev=hda2 ino=1170323 scontext=root:sysamd_r:ldconfig_t >tcontext=root:object_r:lib_t tclass=file >(and then the same with { getattr }) > > liblcms has the wrong security context on it. It should be shlib_t. >Well, in fact I get the same error if I try to run /sbin/ldconfig as >root:sysadm_r:sysadm_t which feels kinda curious :) but what baffles me is >that when installing that package with rpm itself it doesn't complain. I >would've thought having apt-get marked as system_u:object_r:rpm_exec_t >meant that it's got exactly the same priviledges as rpm does but >apparently not so... > > - Panu - >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From dfiguero at openmex.com Wed Apr 14 19:41:08 2004 From: dfiguero at openmex.com (dfiguero) Date: Wed, 14 Apr 2004 19:41:08 +0000 Subject: Enforcing mode requested but no policy loaded. Halting now. Message-ID: <20040414194108.6080.qmail@server283.com> Hi, I recently installed FC2 and I updated the kernel, using up2date, on my machine but whenever I try to log to the new kernel I get the error on the subject: Enforcing mode requested but no policy loaded. Halting now. Kernel panic: attempted to kill init! I read the FAQ but I couldn't find an answer. I tried relabeling the filesystem but that didn't work. Any suggestions? Diego. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Wed Apr 14 19:50:38 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Apr 2004 15:50:38 -0400 Subject: Enforcing mode requested but no policy loaded. Halting now. In-Reply-To: <20040414194108.6080.qmail@server283.com> References: <20040414194108.6080.qmail@server283.com> Message-ID: <20040414195038.GB8749@nostromo.devel.redhat.com> dfiguero (dfiguero at openmex.com) said: > Any suggestions? Make sure you have the latest SysVinit. If you're using SELinux, check the value of /etc/sysconfig/selinux. Bill From aleksey at nogin.org Wed Apr 14 20:43:22 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 14 Apr 2004 13:43:22 -0700 Subject: A lot of AVC messages running "make install" from the kernel source dir. Message-ID: <407DA26A.6080302@nogin.org> If I install the kernel-source package and build a custom kernel, then at "make install" I see: rm: ??????? ??????? ??????????: Permission denied rm: ??????? ??????? ??????????: Permission denied rm: remove.c:378: AD_pop_and_chdir: Assertion `AD_stack_height (ds)' failed. /sbin/mkinitrd: line 678: 11649 Aborted rm -rf $MNTIMAGE $MNTPOINT $IMAGE grubby: error moving /boot/grub/grub.conf- to /boot/grub/grub.conf: Permission denied And I see a huge number of AVC messages. Some of them are obviously a bug (the grub.conf- should be created as bootloader_t, not as etc_t), and for others I am not sure what would be the right thing to do. audit(1081938574.814:0): avc: denied { search } for pid=11483 exe=/bin/bash name=src dev=hda2 ino=4627617 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938574.816:0): avc: denied { search } for pid=11484 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938575.176:0): avc: denied { search } for pid=11487 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938575.397:0): avc: denied { search } for pid=11491 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938575.398:0): avc: denied { search } for pid=11492 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.040:0): avc: denied { search } for pid=11492 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938576.040:0): avc: denied { search } for pid=11492 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938576.400:0): avc: denied { search } for pid=11495 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.402:0): avc: denied { search } for pid=11496 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.403:0): avc: denied { search } for pid=11497 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.405:0): avc: denied { search } for pid=11497 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938576.406:0): avc: denied { search } for pid=11497 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938576.406:0): avc: denied { search } for pid=11494 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.779:0): avc: denied { search } for pid=11500 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.782:0): avc: denied { search } for pid=11503 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.786:0): avc: denied { search } for pid=11505 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.844:0): avc: denied { search } for pid=11506 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938576.847:0): avc: denied { search } for pid=11506 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938576.847:0): avc: denied { search } for pid=11506 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938576.966:0): avc: denied { search } for pid=11511 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938576.966:0): avc: denied { search } for pid=11511 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.352:0): avc: denied { search } for pid=11516 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.352:0): avc: denied { search } for pid=11516 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.375:0): avc: denied { search } for pid=11521 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.375:0): avc: denied { search } for pid=11521 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.540:0): avc: denied { search } for pid=11523 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.543:0): avc: denied { search } for pid=11523 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.543:0): avc: denied { search } for pid=11523 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.544:0): avc: denied { search } for pid=11524 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.549:0): avc: denied { search } for pid=11525 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.551:0): avc: denied { search } for pid=11525 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.551:0): avc: denied { search } for pid=11525 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.643:0): avc: denied { search } for pid=11527 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.646:0): avc: denied { search } for pid=11528 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.652:0): avc: denied { search } for pid=11530 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.654:0): avc: denied { search } for pid=11531 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.658:0): avc: denied { search } for pid=11532 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.660:0): avc: denied { search } for pid=11532 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.660:0): avc: denied { search } for pid=11532 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.663:0): avc: denied { search } for pid=11533 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.665:0): avc: denied { search } for pid=11533 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.665:0): avc: denied { search } for pid=11533 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.669:0): avc: denied { search } for pid=11536 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.674:0): avc: denied { search } for pid=11539 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.679:0): avc: denied { search } for pid=11541 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.683:0): avc: denied { search } for pid=11542 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.686:0): avc: denied { search } for pid=11542 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.687:0): avc: denied { search } for pid=11542 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.733:0): avc: denied { search } for pid=11545 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.737:0): avc: denied { search } for pid=11547 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.741:0): avc: denied { search } for pid=11548 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.743:0): avc: denied { search } for pid=11548 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.744:0): avc: denied { search } for pid=11548 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.792:0): avc: denied { search } for pid=11553 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.793:0): avc: denied { search } for pid=11553 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.828:0): avc: denied { search } for pid=11557 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.828:0): avc: denied { search } for pid=11557 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.850:0): avc: denied { search } for pid=11561 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.850:0): avc: denied { search } for pid=11561 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.853:0): avc: denied { search } for pid=11565 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.868:0): avc: denied { search } for pid=11570 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.868:0): avc: denied { search } for pid=11570 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.888:0): avc: denied { search } for pid=11575 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.888:0): avc: denied { search } for pid=11575 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.910:0): avc: denied { search } for pid=11580 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.910:0): avc: denied { search } for pid=11580 exe=/bin/gawk name=sys dev= ino=4120 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:sysctl_t tclass=dir audit(1081938579.924:0): avc: denied { search } for pid=11582 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938579.930:0): avc: denied { search } for pid=11583 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938580.116:0): avc: denied { search } for pid=11584 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938580.142:0): avc: denied { search } for pid=11585 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938580.144:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938580.458:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938581.734:0): avc: denied { search } for pid=11593 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.096:0): avc: denied { search } for pid=11593 exe=/sbin/mke2fs name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir sage repeated 3 times audit(1081938582.184:0): avc: denied { search } for pid=11593 exe=/sbin/mke2fs name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.184:0): avc: denied { search } for pid=11593 exe=/sbin/mke2fs name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.185:0): avc: denied { search } for pid=11593 exe=/sbin/mke2fs name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir sage repeated 4 times audit(1081938582.189:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.364:0): avc: denied { search } for pid=11594 exe=/sbin/tune2fs name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir sage repeated 10 times audit(1081938582.366:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.487:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir SELinux: initialized (dev loop0, type ext2), uses xattr audit(1081938582.685:0): avc: denied { search } for pid=11598 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.687:0): avc: denied { search } for pid=11599 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.690:0): avc: denied { search } for pid=11600 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.693:0): avc: denied { search } for pid=11601 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.695:0): avc: denied { search } for pid=11602 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.698:0): avc: denied { search } for pid=11603 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.700:0): avc: denied { search } for pid=11604 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.703:0): avc: denied { search } for pid=11605 exe=/bin/mkdir name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.703:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.847:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.864:0): avc: denied { search } for pid=11607 exe=/bin/rm name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938582.969:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938584.003:0): avc: denied { search } for pid=11611 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.075:0): avc: denied { search } for pid=11613 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.372:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.591:0): avc: denied { search } for pid=11625 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.591:0): avc: denied { search } for pid=11626 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.687:0): avc: denied { search } for pid=11629 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.691:0): avc: denied { search } for pid=11630 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.699:0): avc: denied { search } for pid=11634 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.701:0): avc: denied { search } for pid=11635 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.706:0): avc: denied { search } for pid=11638 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.711:0): avc: denied { search } for pid=11639 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.716:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938585.788:0): avc: denied { search } for pid=11641 exe=/bin/chmod name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938586.514:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938586.766:0): avc: denied { search } for pid=11483 exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938587.469:0): avc: denied { search } for pid=11649 exe=/bin/rm name=linux-2.6.5-1.319 dev=hda2 ino=4627658 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t tclass=dir audit(1081938587.987:0): avc: denied { unlink } for pid=11664 exe=/sbin/grubby name=grub.conf dev=hda1 ino=4031 scontext=root:sysadm_r:bootloader_t tcontext=aleksey:object_r:etc_t tclass=file audit(1081938587.988:0): avc: denied { unlink } for pid=11664 exe=/sbin/grubby name=grub.conf dev=hda1 ino=4031 scontext=root:sysadm_r:bootloader_t tcontext=aleksey:object_r:etc_t tclass=file -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From mike at flyn.org Wed Apr 14 21:01:20 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 14 Apr 2004 16:01:20 -0500 Subject: X and SELinux on PowerPC In-Reply-To: <200404141823.03789.russell@coker.com.au> References: <20040413131209.GA2128@imp.flyn.org> <200404141823.03789.russell@coker.com.au> Message-ID: <20040414210120.GA3378@imp.flyn.org> >> Has anyone had any luck with Fedora/SELinux on the PowerPC platform? > > I guess you're the first to try it! ;) > > I've attached a new xserver_macros.te file, please try it out. This xserver_macros.te works fine. Thank you! I filed this as a bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120886 -- Mike :wq From mike at flyn.org Wed Apr 14 21:50:36 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 14 Apr 2004 16:50:36 -0500 Subject: Pam_mount and SELinux In-Reply-To: <407B4ECC.3080002@redhat.com> References: <20040412231329.GA8336@imp.flyn.org> <407B4ECC.3080002@redhat.com> Message-ID: <20040414215036.GA3959@imp.flyn.org> >> One problem I am having right now is that when pam_mount tries to execute >> mount it fails with a "permission denied" error. But I get no related >> AVC log from SELinux. If I disable SELinux's enforcing then I get no >> error and everything works fine. > What is the mount point? Is there a mounton rule for it? The permission denied error is because pam_mount does not seem to have permission to execute mount. I added a mounton rule, but this did not solve my problem. I am especially confused by the fact that SELinux is not logging any failures. I would expect an "avc: denied" error. This feels like a traditional Unix permissions issue but does not occur when SELinux is not enforcing its policies. -- Mike :wq From walters at redhat.com Wed Apr 14 23:21:38 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 14 Apr 2004 19:21:38 -0400 Subject: Pam_mount and SELinux In-Reply-To: <20040414215036.GA3959@imp.flyn.org> References: <20040412231329.GA8336@imp.flyn.org> <407B4ECC.3080002@redhat.com> <20040414215036.GA3959@imp.flyn.org> Message-ID: <1081984898.23204.13.camel@optimus-prime.boston.redhat.com> On Wed, 2004-04-14 at 17:50, W. Michael Petullo wrote: > I added a mounton rule, but this did not solve my problem. I am > especially confused by the fact that SELinux is not logging any failures. > I would expect an "avc: denied" error. This feels like a traditional > Unix permissions issue but does not occur when SELinux is not enforcing > its policies. There are a few things that SELinux will deny but not generate a log message for. is the big one. That's bitten me in the past. In your particular case, if pam_mount is being run before su transitions to the sysadm_r role, then you'll probably get denials from user_r not being authorized for the mount_t domain. Solution: role $1_r types mount_t; From walters at redhat.com Wed Apr 14 23:22:54 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 14 Apr 2004 19:22:54 -0400 Subject: Pam_mount and SELinux In-Reply-To: <1081984898.23204.13.camel@optimus-prime.boston.redhat.com> References: <20040412231329.GA8336@imp.flyn.org> <407B4ECC.3080002@redhat.com> <20040414215036.GA3959@imp.flyn.org> <1081984898.23204.13.camel@optimus-prime.boston.redhat.com> Message-ID: <1081984973.23204.15.camel@optimus-prime.boston.redhat.com> On Wed, 2004-04-14 at 19:21, Colin Walters wrote: > On Wed, 2004-04-14 at 17:50, W. Michael Petullo wrote: > > > I added a mounton rule, but this did not solve my problem. I am > > especially confused by the fact that SELinux is not logging any failures. > > I would expect an "avc: denied" error. This feels like a traditional > > Unix permissions issue but does not occur when SELinux is not enforcing > > its policies. > > There are a few things that SELinux will deny but not generate a log > message for. is the big one. That's bitten me in the past. ^ Disallowed domain transitions /me kicks Evolution's easy-to-accidentally-press Ctrl-RET keybinding... From mike at flyn.org Thu Apr 15 00:35:46 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 14 Apr 2004 19:35:46 -0500 Subject: Pam_mount and SELinux In-Reply-To: <1081984898.23204.13.camel@optimus-prime.boston.redhat.com> References: <20040412231329.GA8336@imp.flyn.org> <407B4ECC.3080002@redhat.com> <20040414215036.GA3959@imp.flyn.org> <1081984898.23204.13.camel@optimus-prime.boston.redhat.com> Message-ID: <20040415003546.GA12138@imp.flyn.org> >> I added a mounton rule, but this did not solve my problem. I am >> especially confused by the fact that SELinux is not logging any failures. >> I would expect an "avc: denied" error. This feels like a traditional >> Unix permissions issue but does not occur when SELinux is not enforcing >> its policies. > There are a few things that SELinux will deny but not generate a log > message for. is the big one. That's bitten me in the past. > > In your particular case, if pam_mount is being run before su transitions > to the sysadm_r role, then you'll probably get denials from user_r not > being authorized for the mount_t domain. > > Solution: > > role $1_r types mount_t; Great! The pam_mount module is now working for me in enforcing mode. Once I go through and clean things up I'll share my work. Why would SELinux not log some denials? -- Mike :wq From dwalsh at redhat.com Thu Apr 15 01:16:23 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Apr 2004 21:16:23 -0400 Subject: A lot of AVC messages running "make install" from the kernel source dir. In-Reply-To: <407DA26A.6080302@nogin.org> References: <407DA26A.6080302@nogin.org> Message-ID: <407DE267.7020203@redhat.com> Aleksey Nogin wrote: > If I install the kernel-source package and build a custom kernel, then > at "make install" I see: > > rm: ??????? ??????? ??????????: Permission denied > rm: ??????? ??????? ??????????: Permission denied > rm: remove.c:378: AD_pop_and_chdir: Assertion `AD_stack_height (ds)' > failed. > /sbin/mkinitrd: line 678: 11649 Aborted rm -rf $MNTIMAGE > $MNTPOINT $IMAGE > grubby: error moving /boot/grub/grub.conf- to /boot/grub/grub.conf: > Permission denied > > And I see a huge number of AVC messages. Some of them are obviously a > bug (the grub.conf- should be created as bootloader_t, not as etc_t), > and for others I am not sure what would be the right thing to do. > > audit(1081938574.814:0): avc: denied { search } for pid=11483 > exe=/bin/bash name=src dev=hda2 ino=4627617 > scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t > tclass=dir > audit(1081938574.816:0): avc: denied { search } for pid=11484 > exe=/bin/bash name=linux-2.6.5-1.319 dev=hda2 ino=4627658 > scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:src_t > tclass=dir In certain cases it is helpful to just run these avc messages through audit2allow All these messages basically came down to a couple of rules that have been added to the laste policy. A couple of tricks you might want to try audit2allow -l -i /var/log/messages Will output all rules for messages since the last time you ran a make load. You can then take the output from this command and output it do the misc subdirectory under policy audit2allow -l -i /var/log/messages > /etc/security/selinux/src/policy/domain/misc/later.te Then do a make load to see if the policy compiles. If it does see if this fixes you problem. You have written your first policy. In alot of cases the rules that are generated by audit2allow will be disallowed do to the assert.te and constraints.te. For example you will not be allowed to write files in the /etc/ directory. You should look at how other programs handle this, usually though file_type_domain_trans. Dan From dwalsh at redhat.com Thu Apr 15 01:19:13 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Apr 2004 21:19:13 -0400 Subject: Pam_mount and SELinux In-Reply-To: <20040415003546.GA12138@imp.flyn.org> References: <20040412231329.GA8336@imp.flyn.org> <407B4ECC.3080002@redhat.com> <20040414215036.GA3959@imp.flyn.org> <1081984898.23204.13.camel@optimus-prime.boston.redhat.com> <20040415003546.GA12138@imp.flyn.org> Message-ID: <407DE311.2070104@redhat.com> W. Michael Petullo wrote: >>>I added a mounton rule, but this did not solve my problem. I am >>>especially confused by the fact that SELinux is not logging any failures. >>>I would expect an "avc: denied" error. This feels like a traditional >>>Unix permissions issue but does not occur when SELinux is not enforcing >>>its policies. >>> >>> > > > >>There are a few things that SELinux will deny but not generate a log >>message for. is the big one. That's bitten me in the past. >> >>In your particular case, if pam_mount is being run before su transitions >>to the sysadm_r role, then you'll probably get denials from user_r not >>being authorized for the mount_t domain. >> >>Solution: >> >>role $1_r types mount_t; >> >> > >Great! The pam_mount module is now working for me in enforcing mode. >Once I go through and clean things up I'll share my work. > >Why would SELinux not log some denials? > > This is a bug in the kernel that has not been upstreamed yet. Hopefully it will fixed soon. This type of think has burnt me several times also. Dan From aleksey at nogin.org Thu Apr 15 02:17:14 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 14 Apr 2004 19:17:14 -0700 Subject: A lot of AVC messages running "make install" from the kernel source dir. In-Reply-To: <407DE267.7020203@redhat.com> References: <407DA26A.6080302@nogin.org> <407DE267.7020203@redhat.com> Message-ID: <407DF0AA.5000207@nogin.org> On 14.04.2004 18:16, Daniel J Walsh wrote: > In certain cases it is helpful to just run these avc messages through > audit2allow I guess so, although for many of these things, the right solution is not to allow the access, but change something else (e.g. grub- should be marked correctly). > All these messages basically came down to a couple of rules that have > been added to the laste policy. Thanks! > A couple of tricks you might want to try > > audit2allow -l -i /var/log/messages > Will output all rules for messages since the last time you ran a make load. Ah, that's very useful, thanks, I did not know about these audit2allow options. > You have written your first policy. Far from the first one ;-) BTW, do you think any of the following is worth adding to the default policy (or is already there)? --- My local te --- # Allow hotplug (including /sbin/ifup-local) to start/stop services and # run sendmail -q domain_auto_trans(hotplug_t, initrc_exec_t, initrc_t) domain_auto_trans(hotplug_t, sendmail_exec_t, system_mail_t) # Same for apm/acpid scripts domain_auto_trans(apmd_t, initrc_exec_t, initrc_t) domain_auto_trans(apmd_t, sendmail_exec_t, system_mail_t) # Allow syslog to a terminal allow syslogd_t tty_device_t:chr_file { getattr write ioctl append }; # Allow staff to mess with removable devices allow staff_t removable_device_t:blk_file { getattr read ioctl lock }; # Allow utemper to write to /tmp/.xses-* allow utempter_t staff_tmp_t:file { getattr write }; # VNC v4 module in X server type vnc_port_t, port_type; allow xdm_xserver_t vnc_port_t:tcp_socket name_bind; # For some reason, putting portcon here is a syntax error and it has to # go into net_contexts :-( # portcon tcp 5900 system_u:object_r:vnc_port_t # Allow strace debugging for staff allow staff_t {staff_mozilla_t staff_xauth_t}:process { ptrace }; --- My local fc --- # Workaround for bug 117685 /home/nogin -l aleksey:object_r:staff_home_t # /dev/cdrom is a removable device. Is there a better way to say this? /dev/hdc -b system_u:object_r:removable_device_t /home/aleksey/\.gnupg/idea aleksey:object_r:shlib_t # The hibernation script (downloaded from # http://prdownloads.sourceforge.net/swsusp/suspend.sh?download ) /usr/local/sbin/hibernate system_u:object_r:initrc_exec_t # This is where my Java installation lives /usr/local/j2re.*/bin(/.*)? system_u:object_r:bin_t /usr/local/j2re.*/lib(64)?/i386(/.*)? system_u:object_r:lib_t # Is there a better way to say that random users should be able # to dump files here? /opt/downloads system_u:object_r:tmp_t -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From dwalsh at redhat.com Thu Apr 15 03:00:12 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Apr 2004 23:00:12 -0400 Subject: A lot of AVC messages running "make install" from the kernel source dir. In-Reply-To: <407DF0AA.5000207@nogin.org> References: <407DA26A.6080302@nogin.org> <407DE267.7020203@redhat.com> <407DF0AA.5000207@nogin.org> Message-ID: <407DFABC.1050004@redhat.com> Aleksey Nogin wrote: > On 14.04.2004 18:16, Daniel J Walsh wrote: > >> In certain cases it is helpful to just run these avc messages through >> audit2allow > > > I guess so, although for many of these things, the right solution is > not to allow the access, but change something else (e.g. grub- should > be marked correctly). > >> All these messages basically came down to a couple of rules that have >> been added to the laste policy. > > > Thanks! > >> A couple of tricks you might want to try >> >> audit2allow -l -i /var/log/messages >> Will output all rules for messages since the last time you ran a make >> load. > > > Ah, that's very useful, thanks, I did not know about these audit2allow > options. > >> You have written your first policy. > > > Far from the first one ;-) > Not really meant at you, It was more meant at anyone else that wants to try their hand at writing policy. > BTW, do you think any of the following is worth adding to the default > policy (or is already there)? > > --- My local te --- > > # Allow hotplug (including /sbin/ifup-local) to start/stop services > and # run sendmail -q > domain_auto_trans(hotplug_t, initrc_exec_t, initrc_t) > domain_auto_trans(hotplug_t, sendmail_exec_t, system_mail_t) > Added > # Same for apm/acpid scripts > domain_auto_trans(apmd_t, initrc_exec_t, initrc_t) > domain_auto_trans(apmd_t, sendmail_exec_t, system_mail_t) > Added > # Allow syslog to a terminal > allow syslogd_t tty_device_t:chr_file { getattr write ioctl append }; > I will add this and see what security people say. > # Allow staff to mess with removable devices > allow staff_t removable_device_t:blk_file { getattr read ioctl lock }; > This is already in there for handling floppies. > # Allow utemper to write to /tmp/.xses-* > allow utempter_t staff_tmp_t:file { getattr write }; > Added > # VNC v4 module in X server > type vnc_port_t, port_type; > allow xdm_xserver_t vnc_port_t:tcp_socket name_bind; > # For some reason, putting portcon here is a syntax error and it has to > # go into net_contexts :-( > # portcon tcp 5900 system_u:object_r:vnc_port_t > Added > # Allow strace debugging for staff > allow staff_t {staff_mozilla_t staff_xauth_t}:process { ptrace }; > > --- My local fc --- > > # Workaround for bug 117685 > /home/nogin -l aleksey:object_r:staff_home_t > > # /dev/cdrom is a removable device. Is there a better way to say this? > /dev/hdc -b system_u:object_r:removable_device_t > I don't know. We have though about this, but what happens when you have more then one cdrom? > /home/aleksey/\.gnupg/idea aleksey:object_r:shlib_t > > # The hibernation script (downloaded from > # http://prdownloads.sourceforge.net/swsusp/suspend.sh?download ) > /usr/local/sbin/hibernate system_u:object_r:initrc_exec_t > > # This is where my Java installation lives > /usr/local/j2re.*/bin(/.*)? system_u:object_r:bin_t > /usr/local/j2re.*/lib(64)?/i386(/.*)? system_u:object_r:lib_t > > # Is there a better way to say that random users should be able > # to dump files here? > /opt/downloads system_u:object_r:tmp_t > That is the way I do it. From aleksey at nogin.org Thu Apr 15 06:58:37 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 14 Apr 2004 23:58:37 -0700 Subject: A lot of AVC messages running "make install" from the kernel source dir. In-Reply-To: <407DFABC.1050004@redhat.com> References: <407DA26A.6080302@nogin.org> <407DE267.7020203@redhat.com> <407DF0AA.5000207@nogin.org> <407DFABC.1050004@redhat.com> Message-ID: <407E329D.6070002@nogin.org> On 14.04.2004 20:00, Daniel J Walsh wrote: >> # /dev/cdrom is a removable device. Is there a better way to say this? >> /dev/hdc -b system_u:object_r:removable_device_t >> > I don't know. We have though about this, but what happens when you have > more then one cdrom? Well, kudzu already creates /dev/cdrom, /dev/cdrom1, etc symlinks, may be it should be augmented to also relabel the targets of those links as removable_device_t? Alternatively, is there a way to talk about a target of a symlink in file_contexts? -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From dennis at ausil.us Thu Apr 15 08:33:49 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Apr 2004 18:33:49 +1000 Subject: Long XFS filesystem avc errors on boot Message-ID: <200404151833.56251.dennis@ausil.us> Ok ill try again. first post was denied for being to big so ill cut it back. on a fully updated system that has XFS as the filesystem i reenabled selinux booted into single user mode and relabeled my filesystem. then rebooted. Postfix failed to start as did X. i am using kdm as my login manager seems its being denied access to some resources it needs. sorry is so long but i thought id show it in its context that is what was logged in /var/log/messages for the boot secqunce up until the point of x failing to start Dennis some of the messages for boot up are as follows Apr 15 11:26:06 asgard kernel: audit(1081992347.449:0): avc: denied { getattr } for pid=774 exe=/sbin/pam_console_apply path=/dev/input/js2 dev=hde2 ino=234962788 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Apr 15 11:26:06 asgard kernel: audit(1081992347.464:0): avc: denied { dac_override } for pid=774 exe=/sbin/pam_console_apply capability=1 scontext=system_u:system_r:pam_console_t tcontext=system_u:system_r:pam_console_t tclass=capability Apr 15 11:26:06 asgard kernel: audit(1081992347.464:0): avc: denied { dac_read_search } for pid=774 exe=/sbin/pam_console_apply capability=2 scontext=system_u:system_r:pam_console_t tcontext=system_u:system_r:pam_console_t tclass=capability Apr 15 11:26:06 asgard kernel: inode_doinit_with_dentry: getxattr returned 13 for dev=hde2 ino=234962799 Apr 15 11:26:06 asgard kernel: audit(1081992347.464:0): avc: denied { getattr } for pid=774 exe=/sbin/pam_console_apply path=/dev/input/js3 dev=hde2 ino=234962799 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Apr 15 11:26:06 asgard kernel: audit(1081992347.546:0): avc: denied { dac_override } for pid=774 exe=/sbin/pam_console_apply capability=1 scontext=system_u:system_r:pam_console_t tcontext=system_u:system_r:pam_console_t tclass=capability Apr 15 11:27:19 asgard /sbin/mingetty[1796]: tty1: Operation not permitted Apr 15 11:27:19 asgard /sbin/mingetty[1797]: tty2: Operation not permitted Apr 15 11:27:19 asgard /sbin/mingetty[1798]: tty3: Operation not permitted Apr 15 11:27:19 asgard kernel: audit(1081992439.217:0): avc: denied { fowner } for pid=1796 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:19 asgard kernel: audit(1081992439.221:0): avc: denied { fowner } for pid=1797 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:19 asgard kernel: audit(1081992439.225:0): avc: denied { fowner } for pid=1798 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:19 asgard kdm_config[1817]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:19 asgard kdm_config[1817]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:19 asgard kernel: audit(1081992439.880:0): avc: denied { read } for pid=1802 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:19 asgard kdm[1802]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:19 asgard kernel: audit(1081992439.921:0): avc: denied { getattr } for pid=1818 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:19 asgard kernel: audit(1081992439.921:0): avc: denied { write } for pid=1818 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:21 asgard kdm[1802]: X server died during startup Apr 15 11:27:21 asgard kdm[1802]: X server for display :0 can't be started, session disabled Apr 15 11:27:22 asgard kdm_config[1834]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:22 asgard kdm_config[1834]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:22 asgard kernel: audit(1081992442.419:0): avc: denied { read } for pid=1819 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:22 asgard kdm[1819]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:22 asgard kernel: audit(1081992442.427:0): avc: denied { getattr } for pid=1835 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:22 asgard kernel: audit(1081992442.427:0): avc: denied { write } for pid=1835 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:23 asgard kdm[1819]: X server died during startup Apr 15 11:27:23 asgard kdm[1819]: X server for display :0 can't be started, session disabled Apr 15 11:27:23 asgard kdm_config[1851]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:23 asgard kdm_config[1851]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:23 asgard kernel: AVC: 1 messages suppressed. Apr 15 11:27:23 asgard kernel: audit(1081992443.946:0): avc: denied { read } for pid=1836 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:23 asgard kdm[1836]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:23 asgard kernel: audit(1081992443.956:0): avc: denied { getattr } for pid=1852 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:23 asgard kernel: audit(1081992443.957:0): avc: denied { write } for pid=1852 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:24 asgard /sbin/mingetty[1853]: tty1: Operation not permitted Apr 15 11:27:24 asgard kernel: audit(1081992444.224:0): avc: denied { fowner } for pid=1853 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:24 asgard kernel: audit(1081992444.230:0): avc: denied { fowner } for pid=1854 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:24 asgard /sbin/mingetty[1854]: tty2: Operation not permitted Apr 15 11:27:24 asgard kernel: audit(1081992444.237:0): avc: denied { fowner } for pid=1855 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:24 asgard /sbin/mingetty[1855]: tty3: Operation not permitted Apr 15 11:27:24 asgard kdm[1836]: X server died during startup Apr 15 11:27:24 asgard kdm[1836]: X server for display :0 can't be started, session disabled Apr 15 11:27:25 asgard kdm_config[1871]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:25 asgard kdm_config[1871]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:25 asgard kernel: audit(1081992445.088:0): avc: denied { read } for pid=1856 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:25 asgard kdm[1856]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:25 asgard kernel: audit(1081992445.098:0): avc: denied { getattr } for pid=1872 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:25 asgard kernel: audit(1081992445.098:0): avc: denied { write } for pid=1872 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:26 asgard kdm[1856]: X server died during startup Apr 15 11:27:26 asgard kdm[1856]: X server for display :0 can't be started, session disabled Apr 15 11:27:26 asgard kdm_config[1888]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:26 asgard kdm_config[1888]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:26 asgard kernel: audit(1081992446.224:0): avc: denied { read } for pid=1873 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:26 asgard kdm[1873]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:26 asgard kernel: audit(1081992446.234:0): avc: denied { getattr } for pid=1889 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:26 asgard kernel: audit(1081992446.234:0): avc: denied { write } for pid=1889 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:27 asgard kdm[1873]: X server died during startup Apr 15 11:27:27 asgard kdm[1873]: X server for display :0 can't be started, session disabled Apr 15 11:27:27 asgard kdm_config[1905]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:27 asgard kdm_config[1905]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:27 asgard kernel: audit(1081992447.358:0): avc: denied { read } for pid=1890 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:27 asgard kdm[1890]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:27 asgard kernel: audit(1081992447.368:0): avc: denied { getattr } for pid=1906 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:27 asgard kernel: audit(1081992447.368:0): avc: denied { write } for pid=1906 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:28 asgard kdm[1890]: X server died during startup Apr 15 11:27:28 asgard kdm[1890]: X server for display :0 can't be started, session disabled Apr 15 11:27:28 asgard kdm_config[1922]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:28 asgard kdm_config[1922]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:28 asgard kernel: audit(1081992448.495:0): avc: denied { read } for pid=1907 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:28 asgard kdm[1907]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:28 asgard kernel: audit(1081992448.503:0): avc: denied { getattr } for pid=1923 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:28 asgard kernel: audit(1081992448.504:0): avc: denied { write } for pid=1923 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:29 asgard /sbin/mingetty[1924]: tty1: Operation not permitted Apr 15 11:27:29 asgard kernel: AVC: 17 messages suppressed. Apr 15 11:27:29 asgard kernel: audit(1081992449.230:0): avc: denied { fowner } for pid=1924 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:29 asgard kernel: audit(1081992449.238:0): avc: denied { fowner } for pid=1925 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:29 asgard /sbin/mingetty[1925]: tty2: Operation not permitted Apr 15 11:27:29 asgard kernel: audit(1081992449.244:0): avc: denied { fowner } for pid=1926 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:29 asgard /sbin/mingetty[1926]: tty3: Operation not permitted Apr 15 11:27:29 asgard kdm[1907]: X server died during startup Apr 15 11:27:29 asgard kdm[1907]: X server for display :0 can't be started, session disabled Apr 15 11:27:29 asgard kdm_config[1942]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:29 asgard kdm_config[1942]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:29 asgard kernel: audit(1081992449.635:0): avc: denied { read } for pid=1927 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:29 asgard kdm[1927]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:29 asgard kernel: audit(1081992449.644:0): avc: denied { getattr } for pid=1943 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:29 asgard kernel: audit(1081992449.646:0): avc: denied { write } for pid=1943 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:30 asgard kdm[1927]: X server died during startup Apr 15 11:27:30 asgard kdm[1927]: X server for display :0 can't be started, session disabled Apr 15 11:27:30 asgard kdm_config[1959]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:30 asgard kdm_config[1959]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:30 asgard kernel: audit(1081992450.771:0): avc: denied { read } for pid=1944 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:30 asgard kdm[1944]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:30 asgard kernel: audit(1081992450.781:0): avc: denied { getattr } for pid=1960 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:30 asgard kernel: audit(1081992450.782:0): avc: denied { write } for pid=1960 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:31 asgard kdm[1944]: X server died during startup Apr 15 11:27:31 asgard kdm[1944]: X server for display :0 can't be started, session disabled Apr 15 11:27:31 asgard kdm_config[1976]: Unrecognized section name [Desktop0] at /usr/share/config/kdm/kdmrc:42 Apr 15 11:27:31 asgard kdm_config[1976]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:266 Apr 15 11:27:31 asgard kernel: audit(1081992451.907:0): avc: denied { read } for pid=1961 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Apr 15 11:27:31 asgard kdm[1961]: Cannot read randomFile "/dev/mem"; X cookies may be easily guessable Apr 15 11:27:31 asgard kernel: audit(1081992451.917:0): avc: denied { getattr } for pid=1977 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:31 asgard kernel: audit(1081992451.918:0): avc: denied { write } for pid=1977 exe=/usr/X11R6/bin/Xorg name=Xorg.0.log dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 11:27:32 asgard kdm[1961]: X server died during startup Apr 15 11:27:32 asgard kdm[1961]: X server for display :0 can't be started, session disabled Apr 15 11:27:32 asgard init: Id "x" respawning too fast: disabled for 5 minutes Apr 15 11:27:34 asgard /sbin/mingetty[1978]: tty1: Operation not permitted Apr 15 11:27:34 asgard kernel: AVC: 11 messages suppressed. Apr 15 11:27:34 asgard kernel: audit(1081992454.236:0): avc: denied { fowner } for pid=1978 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:34 asgard /sbin/mingetty[1979]: tty2: Operation not permitted Apr 15 11:27:34 asgard kernel: audit(1081992454.245:0): avc: denied { fowner } for pid=1979 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:34 asgard /sbin/mingetty[1980]: tty3: Operation not permitted Apr 15 11:27:34 asgard kernel: audit(1081992454.252:0): avc: denied { fowner } for pid=1980 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:39 asgard /sbin/mingetty[1981]: tty1: Operation not permitted Apr 15 11:27:39 asgard kernel: AVC: 2 messages suppressed. Apr 15 11:27:39 asgard kernel: audit(1081992459.242:0): avc: denied { fowner } for pid=1981 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:39 asgard /sbin/mingetty[1982]: tty2: Operation not permitted Apr 15 11:27:39 asgard kernel: audit(1081992459.251:0): avc: denied { fowner } for pid=1982 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:39 asgard /sbin/mingetty[1983]: tty3: Operation not permitted Apr 15 11:27:39 asgard kernel: audit(1081992459.258:0): avc: denied { fowner } for pid=1983 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:44 asgard /sbin/mingetty[1984]: tty1: Operation not permitted Apr 15 11:27:44 asgard kernel: AVC: 2 messages suppressed. Apr 15 11:27:44 asgard kernel: audit(1081992464.248:0): avc: denied { fowner } for pid=1984 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:44 asgard /sbin/mingetty[1985]: tty2: Operation not permitted Apr 15 11:27:44 asgard kernel: audit(1081992464.258:0): avc: denied { fowner } for pid=1985 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:44 asgard /sbin/mingetty[1986]: tty3: Operation not permitted Apr 15 11:27:44 asgard kernel: audit(1081992464.265:0): avc: denied { fowner } for pid=1986 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:49 asgard /sbin/mingetty[1987]: tty1: Operation not permitted Apr 15 11:27:49 asgard kernel: AVC: 2 messages suppressed. Apr 15 11:27:49 asgard kernel: audit(1081992469.255:0): avc: denied { fowner } for pid=1987 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:49 asgard /sbin/mingetty[1988]: tty2: Operation not permitted Apr 15 11:27:49 asgard kernel: audit(1081992469.265:0): avc: denied { fowner } for pid=1988 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:49 asgard /sbin/mingetty[1989]: tty3: Operation not permitted Apr 15 11:27:49 asgard kernel: audit(1081992469.272:0): avc: denied { fowner } for pid=1989 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:54 asgard /sbin/mingetty[1990]: tty1: Operation not permitted Apr 15 11:27:54 asgard kernel: AVC: 2 messages suppressed. Apr 15 11:27:54 asgard kernel: audit(1081992474.262:0): avc: denied { fowner } for pid=1990 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:54 asgard /sbin/mingetty[1991]: tty2: Operation not permitted Apr 15 11:27:54 asgard kernel: audit(1081992474.272:0): avc: denied { fowner } for pid=1991 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:54 asgard /sbin/mingetty[1992]: tty3: Operation not permitted Apr 15 11:27:54 asgard kernel: audit(1081992474.279:0): avc: denied { fowner } for pid=1992 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:59 asgard /sbin/mingetty[1993]: tty1: Operation not permitted Apr 15 11:27:59 asgard kernel: AVC: 2 messages suppressed. Apr 15 11:27:59 asgard kernel: audit(1081992479.269:0): avc: denied { fowner } for pid=1993 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:59 asgard /sbin/mingetty[1994]: tty2: Operation not permitted Apr 15 11:27:59 asgard kernel: audit(1081992479.279:0): avc: denied { fowner } for pid=1994 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:59 asgard kernel: audit(1081992479.287:0): avc: denied { fowner } for pid=1995 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:27:59 asgard /sbin/mingetty[1995]: tty3: Operation not permitted Apr 15 11:28:04 asgard kernel: AVC: 2 messages suppressed. Apr 15 11:28:04 asgard kernel: audit(1081992484.277:0): avc: denied { fowner } for pid=1996 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:28:04 asgard /sbin/mingetty[1996]: tty1: Operation not permitted Apr 15 11:28:04 asgard kernel: audit(1081992484.286:0): avc: denied { fowner } for pid=1997 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:28:04 asgard /sbin/mingetty[1997]: tty2: Operation not permitted Apr 15 11:28:04 asgard /sbin/mingetty[1998]: tty3: Operation not permitted Apr 15 11:28:04 asgard kernel: audit(1081992484.295:0): avc: denied { fowner } for pid=1998 exe=/sbin/mingetty capability=3 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t tclass=capability Apr 15 11:28:09 asgard init: Id "1" respawning too fast: disabled for 5 minutes Apr 15 11:28:09 asgard init: Id "2" respawning too fast: disabled for 5 minutes Apr 15 11:28:09 asgard init: Id "3" respawning too fast: disabled for 5 minutes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From gene at czarc.net Thu Apr 15 08:47:56 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 04:47:56 -0400 Subject: Long XFS filesystem avc errors on boot In-Reply-To: <200404151833.56251.dennis@ausil.us> References: <200404151833.56251.dennis@ausil.us> Message-ID: <200404150447.56519.gene@czarc.net> On Thursday 15 April 2004 04:33, Dennis Gilmore wrote: > Ok ill try again. first post was denied for being to big so ill cut it > back. Long messages to the mailing list are likely to get more people annoyed than getting their help. I suggest that you should put this information into a bugzilla report (along with your avc messages as an attachment). You will then get a report in that the developers will be able to track. If you want to discuss the problem on the mailing list, you can put in a url pointing to the bugzilla report. Gene From russell at coker.com.au Thu Apr 15 09:16:25 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 15 Apr 2004 19:16:25 +1000 Subject: Long XFS filesystem avc errors on boot In-Reply-To: <200404151833.56251.dennis@ausil.us> References: <200404151833.56251.dennis@ausil.us> Message-ID: <200404151916.25386.russell@coker.com.au> On Thu, 15 Apr 2004 18:33, Dennis Gilmore wrote: > Apr 15 11:26:06 asgard kernel: audit(1081992347.449:0): avc: denied > { getattr } for pid=774 exe=/sbin/pam_console_apply path=/dev/input/js2 > dev=hde2 ino=234962788 scontext=system_u:system_r:pam_console_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file /dev/input/js* should have the type mouse_device_t. Please do a "ls -Z" on them and tell me what it says. NB It is not going to say unlabeled_t, it will say whatever is on disk, the kernel uses unlabeled_t if what's on disk makes no sense with the currently loaded policy. > Apr 15 11:26:06 asgard kernel: audit(1081992347.464:0): avc: denied > { dac_override } for pid=774 exe=/sbin/pam_console_apply capability=1 > scontext=system_u:system_r:pam_console_t > tcontext=system_u:system_r:pam_console_t tclass=capability What is it trying to do here? > Apr 15 11:26:06 asgard kernel: audit(1081992347.464:0): avc: denied > { dac_read_search } for pid=774 exe=/sbin/pam_console_apply capability=2 > scontext=system_u:system_r:pam_console_t > tcontext=system_u:system_r:pam_console_t tclass=capability The fact that it tries both in quick succession means that all it really wanted is read. > Apr 15 11:26:06 asgard kernel: inode_doinit_with_dentry: getxattr returned > 13 for dev=hde2 ino=234962799 13 == EACCES? That can't be right. Steve, what do you think about this? > Apr 15 11:27:19 asgard /sbin/mingetty[1796]: tty1: Operation not permitted > Apr 15 11:27:19 asgard /sbin/mingetty[1797]: tty2: Operation not permitted > Apr 15 11:27:19 asgard /sbin/mingetty[1798]: tty3: Operation not permitted > Apr 15 11:27:19 asgard kernel: audit(1081992439.217:0): avc: denied > { fowner } for pid=1796 exe=/sbin/mingetty capability=3 > scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t > tclass=capability Interesting. Who owns your tty devices? Granting this capability should not cause a problem so please test allowing this and see if it does some good. We don't want to grant capabilities wildly, but this will be OK if there are cases that need it. > Apr 15 11:27:19 asgard kernel: audit(1081992439.880:0): avc: denied { > read } for pid=1802 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 > scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t > tclass=chr_file > Apr 15 11:27:19 asgard kdm[1802]: Cannot read randomFile "/dev/mem"; X > cookies may be easily guessable This one is already in bugzilla. You could put an allow rule in custom.te if you want to reduce the noise. But we deliberately don't want to allow this in the default policy. kdm needs to be fixed (it was always broken). > Apr 15 11:27:19 asgard kernel: audit(1081992439.921:0): avc: denied > { getattr } for pid=1818 exe=/usr/X11R6/bin/Xorg path=/var/log/Xorg.0.log > dev=hde2 ino=302135865 scontext=system_u:system_r:xdm_t > tcontext=system_u:object_r:var_log_t tclass=file Put the following in file_contexts/program/xserver.fc /var/log/XOrg.* -- system_u:object_r:xserver_log_t I have attached a suitable xserver.fc file. Then you have to relabel /var/log after rebuilding the file_contexts file. Regarding the long message, all the messages after 11:27:19 appeared to be repeats. The X server and getty will continue restarting forever so will produce an unlimited amount of messages if they can't startup correctly. -- 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 -------------- # X server /dev/agpgart -c system_u:object_r:agp_device_t /dev/dri(/.*)? system_u:object_r:dri_device_t /usr/X11R6/bin/Xwrapper -- system_u:object_r:xserver_exec_t /usr/X11R6/bin/X -- system_u:object_r:xserver_exec_t /usr/X11R6/bin/XFree86 -- system_u:object_r:xserver_exec_t /usr/X11R6/bin/Xipaq -- system_u:object_r:xserver_exec_t /var/lib/xkb(/.*)? system_u:object_r:var_lib_xkb_t /usr/X11R6/lib(64)?/X11/xkb -d system_u:object_r:var_lib_xkb_t /usr/X11R6/lib(64)?/X11/xkb/.* -- system_u:object_r:var_lib_xkb_t /usr/X11R6/lib(64)?/X11/xkb/xkbcomp -- system_u:object_r:bin_t /var/log/XFree86.* -- system_u:object_r:xserver_log_t /var/log/XOrg.* -- system_u:object_r:xserver_log_t /etc/init\.d/xfree86-common -- system_u:object_r:xserver_exec_t /tmp/\.X11-unix -d system_u:object_r:xdm_xserver_tmp_t /tmp/\.X11-unix/.* -s <> /tmp/\.ICE-unix -d system_u:object_r:xdm_xserver_tmp_t /tmp/\.ICE-unix/.* -s <> From sds at epoch.ncsc.mil Thu Apr 15 11:49:02 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Apr 2004 07:49:02 -0400 Subject: Pam_mount and SELinux In-Reply-To: <20040414215036.GA3959@imp.flyn.org> References: <20040412231329.GA8336@imp.flyn.org> <407B4ECC.3080002@redhat.com> <20040414215036.GA3959@imp.flyn.org> Message-ID: <1082029742.25880.3.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-14 at 17:50, W. Michael Petullo wrote: > I added a mounton rule, but this did not solve my problem. I am > especially confused by the fact that SELinux is not logging any failures. > I would expect an "avc: denied" error. This feels like a traditional > Unix permissions issue but does not occur when SELinux is not enforcing > its policies. If you are trying to do this from user_r, then it will fail because the user_r role is not presently authorized for the mount_t domain. The preferred approach would be to use the mount_domain() macro to define a separate user_mount_t domain that is less privileged than the full mount_t domain, and then authorize user_r for it. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Apr 15 11:55:12 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Apr 2004 07:55:12 -0400 Subject: A lot of AVC messages running "make install" from the kernel source dir. In-Reply-To: <407E329D.6070002@nogin.org> References: <407DA26A.6080302@nogin.org> <407DE267.7020203@redhat.com> <407DF0AA.5000207@nogin.org> <407DFABC.1050004@redhat.com> <407E329D.6070002@nogin.org> Message-ID: <1082030112.25880.10.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-15 at 02:58, Aleksey Nogin wrote: > Alternatively, is there a way to talk about a target > of a symlink in file_contexts? Not presently. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Apr 15 12:01:03 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Apr 2004 08:01:03 -0400 Subject: Long XFS filesystem avc errors on boot In-Reply-To: <200404151916.25386.russell@coker.com.au> References: <200404151833.56251.dennis@ausil.us> <200404151916.25386.russell@coker.com.au> Message-ID: <1082030463.25880.15.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-15 at 05:16, Russell Coker wrote: > > Apr 15 11:26:06 asgard kernel: inode_doinit_with_dentry: getxattr returned > > 13 for dev=hde2 ino=234962799 > > 13 == EACCES? That can't be right. Steve, what do you think about this? Is XFS internally performing its own permission check on getxattr for the security namespace? If so, then that is a bug in XFS, as access checking needs to be handled by the security module so that it can internally call the handlers without restriction. -- Stephen Smalley National Security Agency From gene at czarc.net Thu Apr 15 12:18:20 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 08:18:20 -0400 Subject: setting files attributes Message-ID: <200404150818.20004.gene@czarc.net> I had an experience yesterday which has given me pause for thought. I was working with Dan Walsh to get the policy correct to run the X after the xorg-x11-* update which renamed a lot of things including /usr/X11R6/bin/XFree86 -> /usr/X11R6/bin/Xorg. After installing the updated packages (which should be in development/rawhide later today), he informed me I needed to run the following: restorecon /usr/bin/X11/Xorg restorecon /var/log/Xorg* and I dutifully did that. Then I tried to do "telinit 5" with enforcing=1 again and, again, the X server startup failed. After some looking around I came to realize the following: The path specified makes a difference. The full path specified in policy is /usr/X11R6/bin/Xorg where I was using /usr/bin/X11/Xorg. The result of restorecon /usr/bin/X11/Xorg is -rws--x--x+ root root system_u:object_r:bin_t \ /usr/bin/X11/Xorg whereas the result of running restorecon /usr/X11R6/Xorg is -rws--x--x+ root root system_u:object_r:xserver_exec_t /usr/bin/X11/Xorg OK, besides sending this message to give folks some warning when they install the new xor-x11-* and the new policy (1.11.2-3 or later) is that I do not complete understand what is done when I do a system wide relabel. What make -C /etc/security/selinux/src/policy/ relabel appears to do is to go through the all mounted filesystems and set the attributes depending on the rules it has. The question is, does it follow symbolic links or not. If it does not, then there should not be a problem as long as all of the policy rules always use the actual (non-symbolic-link) path AND make sure we do also if we do something manually. However, I can see a problem occurring if it does follow symbolic links because the process likely occurs in sorted order. Now /tmp is clears (or so it says and, I hope, that means /var/tmp/ also), so I should not be able to rename /usr/X11R6/bin/Xorg. However, what if I had a symbolic link from my home directory to something in /etc. Would that get mislabeled? Gene From sds at epoch.ncsc.mil Thu Apr 15 12:26:49 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Apr 2004 08:26:49 -0400 Subject: setting files attributes In-Reply-To: <200404150818.20004.gene@czarc.net> References: <200404150818.20004.gene@czarc.net> Message-ID: <1082032009.25880.36.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-15 at 08:18, Gene Czarcinski wrote: > What make -C /etc/security/selinux/src/policy/ relabel appears to do is to go > through the all mounted filesystems and set the attributes depending on the > rules it has. The question is, does it follow symbolic links or not. If it > does not, then there should not be a problem as long as all of the policy > rules always use the actual (non-symbolic-link) path AND make sure we do also > if we do something manually. setfiles does not follow symlinks during the traversal (FTW_PHYS). It also attempts to detect multiple hard links to the same file and issue warnings if they would yield different security contexts. > However, I can see a problem occurring if it does follow symbolic links > because the process likely occurs in sorted order. Now /tmp is clears (or so > it says and, I hope, that means /var/tmp/ also), so I should not be able to > rename /usr/X11R6/bin/Xorg. However, what if I had a symbolic link from my > home directory to something in /etc. Would that get mislabeled? setfiles doesn't follow symlinks during the traversal, but there is a legitimate concern about malicious symlinks created during the traversal after descent. At present, this is mitigated by policy - setfiles is not allowed to follow untrustworthy symlinks. -- Stephen Smalley National Security Agency From aleksey at nogin.org Thu Apr 15 12:33:16 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Thu, 15 Apr 2004 05:33:16 -0700 Subject: Long XFS filesystem avc errors on boot In-Reply-To: <200404151916.25386.russell@coker.com.au> References: <200404151833.56251.dennis@ausil.us> <200404151916.25386.russell@coker.com.au> Message-ID: <20040415123303.GA4724@dell.nogin.org> On Thu, Apr 15, 2004 at 07:16:25PM +1000, Russell Coker wrote: > > Apr 15 11:27:19 asgard kernel: audit(1081992439.880:0): avc: denied { > > read } for pid=1802 exe=/usr/bin/kdm name=mem dev=hde2 ino=33580795 > > scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:memory_device_t > > tclass=chr_file > > Apr 15 11:27:19 asgard kdm[1802]: Cannot read randomFile "/dev/mem"; X > > cookies may be easily guessable > > This one is already in bugzilla. Yes, bug #118051. > You could put an allow rule in custom.te if you want to reduce the noise. A better workaround is to add a line "RandomDevice=/dev/urandom" to the "General" section of your /etc/X11/xdm/kdmrc file. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From gene at czarc.net Thu Apr 15 12:42:41 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 08:42:41 -0400 Subject: setting files attributes In-Reply-To: <1082032009.25880.36.camel@moss-spartans.epoch.ncsc.mil> References: <200404150818.20004.gene@czarc.net> <1082032009.25880.36.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200404150842.41793.gene@czarc.net> On Thursday 15 April 2004 08:26, Stephen Smalley wrote: > On Thu, 2004-04-15 at 08:18, Gene Czarcinski wrote: > > What make -C /etc/security/selinux/src/policy/ relabel appears to do is > > to go through the all mounted filesystems and set the attributes > > depending on the rules it has. The question is, does it follow symbolic > > links or not. If it does not, then there should not be a problem as long > > as all of the policy rules always use the actual (non-symbolic-link) path > > AND make sure we do also if we do something manually. > > setfiles does not follow symlinks during the traversal (FTW_PHYS). It > also attempts to detect multiple hard links to the same file and issue > warnings if they would yield different security contexts. > > > However, I can see a problem occurring if it does follow symbolic links > > because the process likely occurs in sorted order. Now /tmp is clears > > (or so it says and, I hope, that means /var/tmp/ also), so I should not > > be able to rename /usr/X11R6/bin/Xorg. However, what if I had a symbolic > > link from my home directory to something in /etc. Would that get > > mislabeled? > > setfiles doesn't follow symlinks during the traversal, but there is a > legitimate concern about malicious symlinks created during the traversal > after descent. At present, this is mitigated by policy - setfiles is > not allowed to follow untrustworthy symlinks. That is a relief. Now folks just need to understand not to do anything manually with a symlink in the path. Gene From nico33b at yahoo.fr Thu Apr 15 15:29:51 2004 From: nico33b at yahoo.fr (=?iso-8859-1?q?Nic=A4?=) Date: Thu, 15 Apr 2004 11:29:51 -0400 (EDT) Subject: Su from an unprivileged account Message-ID: <20040415152951.84928.qmail@web40904.mail.yahoo.com> Hi all. Is there a way to easily configure the policy to allow an unprivileged user to execute the su command. By default, this is not allowed ! Nico. __________________________________________________________ L?che-vitrine ou l?che-?cran ? magasinage.yahoo.ca From gene at czarc.net Thu Apr 15 17:41:40 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 13:41:40 -0400 Subject: some hits from latest set of updates Message-ID: <200404151341.40141.gene@czarc.net> The latest version of udev (024-3) may fix something but it breaks others -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120956 My reason for this message is really another matter. When I say the large number of denied messages involving udev, I immediately reinstalled udev-023-2 and, sure enough, they went away ... well mostly. My sound was broken again ... not for root (I could run s-c-soundcard) but for the user. OK, I knew how to fix that ... "telinit 1", "setfiles /etc/security... /dev", "telinit 5" ... sound works again for the user. Now, my question is how will this be handled in the future? With the large number of updates during the release development cycle, the number of updates (and sometimes reinstall oldpackage) has created situtations where the attributes on a file have gotten screwed up. Through experience (I have done it enough times), I have come to know that occasionally I will need to do a relabel (or if I am lucky and know the general area, a setfiles). But how will this be handled once FC2 is release? Will a general user be willing to run selinux=1, enforcing=1 if things get screwed up when they update packages and suddenly things stop working (because some file is mis-labeled)? I want to run selinux and plan to run enforcing=1 regardless of what FC2 ships by default. But, will that be true of most users? Gene From dwalsh at redhat.com Thu Apr 15 18:09:54 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 15 Apr 2004 14:09:54 -0400 Subject: Su from an unprivileged account In-Reply-To: <20040415152951.84928.qmail@web40904.mail.yahoo.com> References: <20040415152951.84928.qmail@web40904.mail.yahoo.com> Message-ID: <407ECFF2.7060607@redhat.com> Nic? wrote: >Hi all. > >Is there a way to easily configure the policy to allow >an unprivileged user to execute the su command. > >By default, this is not allowed ! > > > By default it is allowed, there is a tunable to turn this off, but a normal user should be able to su. >Nico. > > > >__________________________________________________________ >L?che-vitrine ou l?che-?cran ? >magasinage.yahoo.ca >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From gene at czarc.net Thu Apr 15 18:15:59 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 14:15:59 -0400 Subject: Su from an unprivileged account In-Reply-To: <407ECFF2.7060607@redhat.com> References: <20040415152951.84928.qmail@web40904.mail.yahoo.com> <407ECFF2.7060607@redhat.com> Message-ID: <200404151415.59271.gene@czarc.net> On Thursday 15 April 2004 14:09, Daniel J Walsh wrote: > Nic? wrote: > >Hi all. > > > >Is there a way to easily configure the policy to allow > >an unprivileged user to execute the su command. > > > >By default, this is not allowed ! > > By default it is allowed, there is a tunable to turn this off, but a > normal user should be able to su. Mmmm .. I wonder if it can be fine tuned enough so that a user could su to another regular user but not root or any user with sysadm_r capability? At the same time, a user with a sysadm_r capability could su to anyone. That might be an interesting capability to have. Gene From dax at gurulabs.com Thu Apr 15 19:21:05 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 15 Apr 2004 13:21:05 -0600 Subject: rawhide install aborts on setools-1.2.1-7 install Message-ID: <1082056865.2973.27.camel@mentor.gurulabs.com> I tried to install the 04/14/04 rawhide twice. I did an "Everything" install and everything was good until right near the end I got a fatal message that the setools RPM couldn't be installed. Plenty of diskspace (12GB) was available. Out on a text terminal (F4??) there was a cpio error message. Dax Kelson Guru Labs From notting at redhat.com Thu Apr 15 19:39:09 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Apr 2004 15:39:09 -0400 Subject: rawhide install aborts on setools-1.2.1-7 install In-Reply-To: <1082056865.2973.27.camel@mentor.gurulabs.com> References: <1082056865.2973.27.camel@mentor.gurulabs.com> Message-ID: <20040415193909.GA12504@nostromo.devel.redhat.com> Dax Kelson (dax at gurulabs.com) said: > I tried to install the 04/14/04 rawhide twice. I did an "Everything" > install and everything was good until right near the end I got a fatal > message that the setools RPM couldn't be installed. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120552 Bill From dwalsh at redhat.com Thu Apr 15 19:45:33 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 15 Apr 2004 15:45:33 -0400 Subject: Su from an unprivileged account In-Reply-To: <200404151415.59271.gene@czarc.net> References: <20040415152951.84928.qmail@web40904.mail.yahoo.com> <407ECFF2.7060607@redhat.com> <200404151415.59271.gene@czarc.net> Message-ID: <407EE65D.5090700@redhat.com> Gene Czarcinski wrote: >On Thursday 15 April 2004 14:09, Daniel J Walsh wrote: > > >>Nic? wrote: >> >> >>>Hi all. >>> >>>Is there a way to easily configure the policy to allow >>>an unprivileged user to execute the su command. >>> >>>By default, this is not allowed ! >>> >>> >>By default it is allowed, there is a tunable to turn this off, but a >>normal user should be able to su. >> >> > >Mmmm .. I wonder if it can be fine tuned enough so that a user could su to >another regular user but not root or any user with sysadm_r capability? At >the same time, a user with a sysadm_r capability could su to anyone. > >That might be an interesting capability to have. > > That is what staff_r is defined as. If you turn off user_canbe_sysadm, you will end up with regular users who can't su and staff users who can. >Gene > >-- >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 Thu Apr 15 19:51:06 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 15 Apr 2004 15:51:06 -0400 Subject: some hits from latest set of updates In-Reply-To: <200404151341.40141.gene@czarc.net> References: <200404151341.40141.gene@czarc.net> Message-ID: <407EE7AA.8070708@redhat.com> Gene Czarcinski wrote: >The latest version of udev (024-3) may fix something but it breaks others -- >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120956 > >My reason for this message is really another matter. When I say the large >number of denied messages involving udev, I immediately reinstalled >udev-023-2 and, sure enough, they went away ... well mostly. My sound was >broken again ... not for root (I could run s-c-soundcard) but for the user. > >OK, I knew how to fix that ... "telinit 1", "setfiles /etc/security... /dev", >"telinit 5" ... sound works again for the user. > >Now, my question is how will this be handled in the future? With the large >number of updates during the release development cycle, the number of updates >(and sometimes reinstall oldpackage) has created situtations where the >attributes on a file have gotten screwed up. > >Through experience (I have done it enough times), I have come to know that >occasionally I will need to do a relabel (or if I am lucky and know the >general area, a setfiles). But how will this be handled once FC2 is release? >Will a general user be willing to run selinux=1, enforcing=1 if things get >screwed up when they update packages and suddenly things stop working >(because some file is mis-labeled)? > >I want to run selinux and plan to run enforcing=1 regardless of what FC2 ships >by default. But, will that be true of most users? > > First off the volume of changes will hopefully slowdown. Maybe not till FC3. :^( File contexts should not be getting changed so often, and major changes like xorg and stuff will not be happening as often. Basically we have got to get better. One problem is that we are sharing rawhide with the user community, so if someone submits a package in rawhide, you and I see it at the same time. If it breaks policy it takes time for us to fix it. (Xorg being an example.) As others start to run SELinux, and everyone becomes more aware of SELinux these problems should happen less often. >Gene > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From notting at redhat.com Thu Apr 15 20:23:11 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Apr 2004 16:23:11 -0400 Subject: bugs of the day Message-ID: <20040415202311.GA13523@nostromo.devel.redhat.com> I can bugzilla if it's preferred. policy-1.11.2-6 1) contexts aren't set correctly on install. Jeremy is looking at this. 2) lvm_t can't read sysfs_t. It needs to 3) udev spews all sorts of stuff a) it can't run things in /etc/dev.d (etc_t, shell_exec_t ATM) b) can't look in /bin c) read symlinks in /bin d) various other things because of this 4) init can't write to wtmp (var_log_t) 5) other bits bootup log and audit2allow attached. Bill -------------- next part -------------- Apr 15 15:50:40 apone kernel: audit(1082058571.990:0): avc: denied { search } for pid=34 exe=/bin/hostname dev=hda3 ino=2 scontext=system_u:system_r:hostname_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058572.266:0): avc: denied { search } for pid=46 exe=/sbin/consoletype dev=hda3 ino=2 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058572.825:0): avc: denied { search } for pid=57 exe=/sbin/minilogd dev=hda3 ino=2 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058572.860:0): avc: denied { search } for pid=60 exe=/bin/dmesg dev=hda3 ino=2 scontext=system_u:system_r:dmesg_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058572.926:0): avc: denied { search } for pid=63 exe=/usr/bin/rhgb dev=hda3 ino=2 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058574.244:0): avc: denied { search } for pid=74 exe=/sbin/hwclock dev=hda3 ino=2 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058575.407:0): avc: denied { read } for pid=105 exe=/sbin/fsck name=fstab dev=hda3 ino=374631 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:file_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058575.407:0): avc: denied { getattr } for pid=105 exe=/sbin/fsck path=/etc/fstab dev=hda3 ino=374631 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:file_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058576.129:0): avc: denied { search } for pid=131 exe=/sbin/udevsend dev=hda3 ino=2 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058583.177:0): avc: denied { search } for pid=560 exe=/sbin/pam_console_apply dev=hda3 ino=2 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058583.254:0): avc: denied { read } for pid=560 exe=/sbin/pam_console_apply name=fstab dev=hda3 ino=374631 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:file_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058583.255:0): avc: denied { getattr } for pid=560 exe=/sbin/pam_console_apply path=/etc/fstab dev=hda3 ino=374631 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:file_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058583.596:0): avc: denied { search } for pid=577 exe=/bin/dmesg dev=hda3 ino=2 scontext=system_u:system_r:dmesg_t tcontext=system_u:object_r:file_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058583.636:0): avc: denied { append } for pid=1 exe=/sbin/init name=wtmp dev=hda3 ino=16339 scontext=system_u:system_r:init_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058583.636:0): avc: denied { write } for pid=1 exe=/sbin/init name=wtmp dev=hda3 ino=16339 scontext=system_u:system_r:init_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058583.636:0): avc: denied { lock } for pid=1 exe=/sbin/init path=/var/log/wtmp dev=hda3 ino=16339 scontext=system_u:system_r:init_t tcontext=system_u:object_r:var_log_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.429:0): avc: denied { execute } for pid=585 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.429:0): avc: denied { execute_no_trans } for pid=585 exe=/sbin/udev path=/etc/dev.d/default/dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.429:0): avc: denied { search } for pid=585 exe=/sbin/udev name=bin dev=hda3 ino=1237889 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:bin_t tclass=dir Apr 15 15:50:40 apone kernel: audit(1082058586.429:0): avc: denied { read } for pid=585 exe=/sbin/udev name=sh dev=hda3 ino=1237899 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:bin_t tclass=lnk_file Apr 15 15:50:40 apone kernel: audit(1082058586.429:0): avc: denied { execute } for pid=585 exe=/sbin/udev name=bash dev=hda3 ino=1237897 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:shell_exec_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.429:0): avc: denied { read } for pid=585 exe=/sbin/udev path=/bin/bash dev=hda3 ino=1237897 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:shell_exec_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.430:0): avc: denied { read } for pid=585 exe=/bin/bash name=mtab dev=hda3 ino=377480 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.430:0): avc: denied { getattr } for pid=585 exe=/bin/bash path=/etc/mtab dev=hda3 ino=377480 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_runtime_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.430:0): avc: denied { getattr } for pid=585 exe=/bin/bash path=/proc/meminfo dev= ino=4098 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:proc_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.431:0): avc: denied { ioctl } for pid=585 exe=/bin/bash path=/etc/dev.d/default/dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 15:50:40 apone kernel: audit(1082058586.435:0): avc: denied { getattr } for pid=586 exe=/bin/bash path=/usr/bin/logger dev=hda3 ino=640141 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:bin_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059345.849:0): avc: denied { getattr } for pid=135 exe=/sbin/lvm.static path=/var/run/ptal-printd dev=hda3 ino=35011 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:var_run_t tclass=dir Apr 15 16:04:14 apone kernel: audit(1082059345.859:0): avc: denied { read } for pid=135 exe=/sbin/lvm.static dev= ino=1 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:devpts_t tclass=dir Apr 15 16:04:14 apone kernel: audit(1082059346.398:0): avc: denied { read } for pid=135 exe=/sbin/lvm.static name=block dev= ino=385 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:sysfs_t tclass=dir Apr 15 16:04:14 apone kernel: audit(1082059355.383:0): avc: denied { execute } for pid=159 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.383:0): avc: denied { execute } for pid=161 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.383:0): avc: denied { execute } for pid=160 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.383:0): avc: denied { execute } for pid=158 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=163 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=164 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=162 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=165 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=166 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=168 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=169 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059355.384:0): avc: denied { execute } for pid=167 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059356.815:0): avc: denied { execute } for pid=177 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059356.816:0): avc: denied { execute } for pid=178 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059356.816:0): avc: denied { execute } for pid=179 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059359.389:0): avc: denied { execute } for pid=187 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059359.389:0): avc: denied { execute } for pid=188 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059359.389:0): avc: denied { execute } for pid=189 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059361.992:0): avc: denied { execute } for pid=197 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059361.993:0): avc: denied { execute } for pid=198 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059361.993:0): avc: denied { execute } for pid=199 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059364.556:0): avc: denied { execute } for pid=207 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059364.557:0): avc: denied { execute } for pid=208 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059364.557:0): avc: denied { execute } for pid=209 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059367.117:0): avc: denied { execute } for pid=217 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059367.118:0): avc: denied { execute } for pid=218 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059367.118:0): avc: denied { execute } for pid=219 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059369.697:0): avc: denied { execute } for pid=227 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059369.697:0): avc: denied { execute } for pid=228 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059369.698:0): avc: denied { execute } for pid=229 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059372.280:0): avc: denied { execute } for pid=237 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059372.280:0): avc: denied { execute } for pid=238 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:14 apone kernel: audit(1082059372.281:0): avc: denied { execute } for pid=239 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059374.839:0): avc: denied { execute } for pid=247 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059374.840:0): avc: denied { execute } for pid=248 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059374.840:0): avc: denied { execute } for pid=249 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059377.400:0): avc: denied { execute } for pid=257 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059377.401:0): avc: denied { execute } for pid=258 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059377.401:0): avc: denied { execute } for pid=259 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059379.961:0): avc: denied { execute } for pid=267 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059379.962:0): avc: denied { execute } for pid=268 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059379.962:0): avc: denied { execute } for pid=269 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059382.541:0): avc: denied { execute } for pid=277 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059382.541:0): avc: denied { execute } for pid=278 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059382.542:0): avc: denied { execute } for pid=279 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059385.102:0): avc: denied { execute } for pid=287 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059385.102:0): avc: denied { execute } for pid=288 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059385.103:0): avc: denied { execute } for pid=289 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059387.662:0): avc: denied { execute } for pid=297 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059387.662:0): avc: denied { execute } for pid=298 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059387.663:0): avc: denied { execute } for pid=299 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059390.237:0): avc: denied { execute } for pid=307 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059390.237:0): avc: denied { execute } for pid=308 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059390.237:0): avc: denied { execute } for pid=309 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059392.765:0): avc: denied { execute } for pid=317 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059392.766:0): avc: denied { execute } for pid=318 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059392.766:0): avc: denied { execute } for pid=319 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059395.346:0): avc: denied { execute } for pid=327 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059395.347:0): avc: denied { execute } for pid=328 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059395.347:0): avc: denied { execute } for pid=329 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059397.926:0): avc: denied { execute } for pid=337 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059397.926:0): avc: denied { execute } for pid=338 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059397.927:0): avc: denied { execute } for pid=339 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059400.486:0): avc: denied { execute } for pid=347 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059400.486:0): avc: denied { execute } for pid=348 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059400.487:0): avc: denied { execute } for pid=349 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059403.067:0): avc: denied { execute } for pid=357 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059403.067:0): avc: denied { execute } for pid=358 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059403.067:0): avc: denied { execute } for pid=359 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059405.648:0): avc: denied { execute } for pid=367 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059405.648:0): avc: denied { execute } for pid=368 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059405.648:0): avc: denied { execute } for pid=369 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:15 apone kernel: audit(1082059408.210:0): avc: denied { execute } for pid=377 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059408.211:0): avc: denied { execute } for pid=378 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059408.211:0): avc: denied { execute } for pid=379 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059410.790:0): avc: denied { execute } for pid=387 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059410.791:0): avc: denied { execute } for pid=388 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059410.791:0): avc: denied { execute } for pid=389 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059413.370:0): avc: denied { execute } for pid=397 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059413.370:0): avc: denied { execute } for pid=398 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059413.371:0): avc: denied { execute } for pid=399 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059415.931:0): avc: denied { execute } for pid=407 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059415.931:0): avc: denied { execute } for pid=408 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059415.932:0): avc: denied { execute } for pid=409 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059418.492:0): avc: denied { execute } for pid=417 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059418.492:0): avc: denied { execute } for pid=418 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059418.492:0): avc: denied { execute } for pid=419 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059421.072:0): avc: denied { execute } for pid=427 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059421.072:0): avc: denied { execute } for pid=428 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059421.072:0): avc: denied { execute } for pid=429 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059423.634:0): avc: denied { execute } for pid=437 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059423.635:0): avc: denied { execute } for pid=438 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059423.635:0): avc: denied { execute } for pid=439 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059426.196:0): avc: denied { execute } for pid=447 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059426.197:0): avc: denied { execute } for pid=448 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:16 apone kernel: audit(1082059426.197:0): avc: denied { execute } for pid=449 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:17 apone kernel: audit(1082059447.285:0): avc: denied { execute } for pid=1185 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:17 apone kernel: audit(1082059447.286:0): avc: denied { execute } for pid=1186 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:17 apone kernel: audit(1082059447.286:0): avc: denied { execute } for pid=1187 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:17 apone kernel: audit(1082059456.313:0): avc: denied { getattr } for pid=1652 exe=/usr/sbin/automount path=/mnt dev=hda3 ino=1531073 scontext=system_u:system_r:automount_t tcontext=system_u:object_r:mnt_t tclass=dir Apr 15 16:04:17 apone kernel: audit(1082059456.362:0): avc: denied { getattr } for pid=1708 exe=/usr/sbin/automount path=/home dev=hda3 ino=325761 scontext=system_u:system_r:automount_t tcontext=system_u:object_r:home_root_t tclass=dir Apr 15 16:04:22 apone kernel: audit(1082059462.513:0): avc: denied { getattr } for pid=2021 exe=/bin/su path=/etc/krb5.conf dev=hda3 ino=374773 scontext=system_u:system_r:initrc_su_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 15 16:04:22 apone kernel: audit(1082059462.513:0): avc: denied { getattr } for pid=2021 exe=/bin/su path=/etc/krb5.conf dev=hda3 ino=374773 scontext=system_u:system_r:initrc_su_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 15 16:04:22 apone kernel: audit(1082059462.513:0): avc: denied { getattr } for pid=2021 exe=/bin/su path=/dev/urandom dev=hda3 ino=174526 scontext=system_u:system_r:initrc_su_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 15 16:04:26 apone kernel: audit(1082059466.070:0): avc: denied { getattr } for pid=2087 exe=/bin/su path=/etc/krb5.conf dev=hda3 ino=374773 scontext=system_u:system_r:initrc_su_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 15 16:04:26 apone kernel: audit(1082059466.070:0): avc: denied { getattr } for pid=2087 exe=/bin/su path=/etc/krb5.conf dev=hda3 ino=374773 scontext=system_u:system_r:initrc_su_t tcontext=system_u:object_r:krb5_conf_t tclass=file Apr 15 16:04:26 apone kernel: audit(1082059466.071:0): avc: denied { getattr } for pid=2087 exe=/bin/su path=/dev/urandom dev=hda3 ino=174526 scontext=system_u:system_r:initrc_su_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 15 16:04:26 apone kernel: audit(1082059466.180:0): avc: denied { read } for pid=2099 exe=/usr/sbin/cannaserver name=resolv.conf dev=hda3 ino=378631 scontext=system_u:system_r:canna_t tcontext=system_u:object_r:net_conf_t tclass=file Apr 15 16:04:26 apone kernel: audit(1082059466.180:0): avc: denied { create } for pid=2099 exe=/usr/sbin/cannaserver scontext=system_u:system_r:canna_t tcontext=system_u:system_r:canna_t tclass=udp_socket Apr 15 16:04:26 apone kernel: audit(1082059466.181:0): avc: denied { create } for pid=2099 exe=/usr/sbin/cannaserver scontext=system_u:system_r:canna_t tcontext=system_u:system_r:canna_t tclass=udp_socket Apr 15 16:04:29 apone kernel: audit(1082059469.659:0): avc: denied { execute } for pid=2232 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:29 apone kernel: audit(1082059469.659:0): avc: denied { execute } for pid=2233 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:29 apone kernel: audit(1082059469.660:0): avc: denied { execute } for pid=2234 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:29 apone kernel: audit(1082059469.669:0): avc: denied { execute } for pid=2235 exe=/sbin/udev name=hotplug.dev dev=hda3 ino=380314 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:29 apone kernel: audit(1082059469.670:0): avc: denied { execute } for pid=2236 exe=/sbin/udev name=dbus.dev dev=hda3 ino=380311 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:29 apone kernel: audit(1082059469.670:0): avc: denied { execute } for pid=2237 exe=/sbin/udev name=pam_console.dev dev=hda3 ino=380312 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Apr 15 16:04:29 apone kernel: audit(1082059469.671:0): avc: denied { execute } for pid=2238 exe=/sbin/udev name=selinux.dev dev=hda3 ino=380313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file -------------- next part -------------- allow automount_t home_root_t:dir { getattr }; allow automount_t mnt_t:dir { getattr }; allow canna_t canna_t:udp_socket { create }; allow canna_t net_conf_t:file { read }; allow consoletype_t file_t:dir { search }; allow dmesg_t file_t:dir { search }; allow fsadm_t file_t:file { getattr read }; allow hostname_t file_t:dir { search }; allow hwclock_t file_t:dir { search }; allow init_t var_log_t:file { append lock write }; allow initrc_su_t krb5_conf_t:file { getattr }; allow initrc_su_t urandom_device_t:chr_file { getattr }; allow lvm_t devpts_t:dir { read }; allow lvm_t sysfs_t:dir { read }; allow lvm_t var_run_t:dir { getattr }; allow pam_console_t file_t:dir { search }; allow pam_console_t file_t:file { getattr read }; allow rhgb_t file_t:dir { search }; allow syslogd_t file_t:dir { search }; allow udev_t bin_t:dir { search }; allow udev_t bin_t:file { getattr }; allow udev_t bin_t:lnk_file { read }; allow udev_t etc_runtime_t:file { getattr read }; allow udev_t etc_t:file { execute execute_no_trans ioctl }; allow udev_t file_t:dir { search }; allow udev_t proc_t:file { getattr }; allow udev_t shell_exec_t:file { execute read }; From gene at czarc.net Thu Apr 15 20:40:07 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 16:40:07 -0400 Subject: Su from an unprivileged account In-Reply-To: <407EE65D.5090700@redhat.com> References: <20040415152951.84928.qmail@web40904.mail.yahoo.com> <200404151415.59271.gene@czarc.net> <407EE65D.5090700@redhat.com> Message-ID: <200404151640.07090.gene@czarc.net> On Thursday 15 April 2004 15:45, Daniel J Walsh wrote: > >Mmmm .. I wonder if it can be fine tuned enough so that a user could su to > >another regular user but not root or any user with sysadm_r capability? > > At the same time, a user with a sysadm_r capability could su to anyone. > > > >That might be an interesting capability to have. > > > > That is what staff_r is defined as. If you turn off user_canbe_sysadm, > you will end up with regular users who can't su and > staff users who can. Great! Well, that puts this message into my selinux "Goodinfo" folder. Gene From gene at czarc.net Thu Apr 15 20:41:38 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 16:41:38 -0400 Subject: bugs of the day In-Reply-To: <20040415202311.GA13523@nostromo.devel.redhat.com> References: <20040415202311.GA13523@nostromo.devel.redhat.com> Message-ID: <200404151641.38187.gene@czarc.net> On Thursday 15 April 2004 16:23, Bill Nottingham wrote: > I can bugzilla if it's preferred. > > policy-1.11.2-6 > > 1) contexts aren't set correctly on install. Jeremy is looking at this. > 2) lvm_t can't read sysfs_t. It needs to > 3) udev spews all sorts of stuff > a) it can't run things in /etc/dev.d (etc_t, shell_exec_t ATM) > b) can't look in /bin > c) read symlinks in /bin > d) various other things because of this > 4) init can't write to wtmp (var_log_t) > 5) other bits At least some of this is already in bugzilla (lvm and udev). Gene From elanthis at awesomeplay.com Thu Apr 15 20:46:41 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 15 Apr 2004 16:46:41 -0400 Subject: adding /etc/roles Message-ID: <1082062001.25991.18.camel@support02.civic.twp.ypsilanti.mi.us> As was recommended to me, I'm sending this to the list. I was recommended to go to -devel, but this list seems a heck of a lot more appropriate, so here it is. Note that although I'm now subscribed I have delivery turned off, so CC me if you want a response. I check the web mail archives too, but I can't respond to messages posted there. (I'd love to add that ability, tho; a form to respond to any list mail using your subscribed mail address and account password... would be sweet.) Red Hat Bugzilla #120571 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120571) I wrote a script and patch for adding /etc/roles support to SELinux. So, instead of needing to hack in m4 macros and botch the ability to upgrade sources with RPM, you can just edit /etc/roles and rebuild the policy nice and clean like. Still need to figure out how to tell the policy (or system utilities) what the default login role should be. A user with user_r and sysadm_r roles, for example, should not have sysadm_r as the default. The default_contexts files does this, but I'm not comfortable modifying that file with a script. Also, some tools like addrole and delrole would be nice, for modifying the /etc/roles file and automatically rebuilding/reloading the policy. useradd/userdel should also support this functionality. The silly seadduser command should also be fixed/removed; just make it so a flag to useradd gives a default role, and if the default role is omitted, don't add an /etc/roles entry. (Users not in /etc/roles wouldn't have an SELinux user ID, unless manually added to the policy sources.) Makes a heck of a lot more sense than a separate seuseradd command. I think there was a bugzilla entry regarding that, not sure what bug# though. Additionally, a command like "policy" or "selinux" for modifying various SELinux attributes would be great (for example, pull in the selinuxenabled command, and add something like "rebuild" or "load" as well for rebuilding and reloading the policy). Would make administration a lot easier and saner, which SELinux needs a lot of... -- Sean Middleditch AwesomePlay Productions, Inc. From gene at czarc.net Thu Apr 15 21:21:05 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 17:21:05 -0400 Subject: login default ... changed? Message-ID: <200404151721.05876.gene@czarc.net> Now things related to selinux, policy, etc. have been changing so radidly that my memory may be incorrect. IIRC, it used to be that if I logged in from gdm as a sysadm_r user (staff_r and sysadm_r) as defined in users, I would be logged in with sysadm_r. This appears to have changed (or my memory is faulty). The default for a sysadm_r user is to get staff_r and must use newrole -r sysadm_r to get that. Good! That is the way I think it should work. The same is true for root. As far as selinux is concerned, root is just another sysadm_r user and the default role logging in from gdm is staff_r. Is this what should be done. This will certainly be a change for most users. When I login as root from gdm, I do not expect that I will be prompted for root's password when I invoke system-config-users from the menu. I also notice that doing an "su -" to root or another sysadm_r user will default to sysadm_r role for that user. if it is from another sysadm_r user, then I get a choice of sysadm_r (default) or staff_r. If it is from a user_r user, then no choice, I just get sysadm_r. Comments?? Is this how things should work?? This is not criticism, just wondering. Gene From sds at epoch.ncsc.mil Thu Apr 15 21:29:22 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Apr 2004 17:29:22 -0400 Subject: login default ... changed? In-Reply-To: <200404151721.05876.gene@czarc.net> References: <200404151721.05876.gene@czarc.net> Message-ID: <1082064561.25880.149.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-15 at 17:21, Gene Czarcinski wrote: > IIRC, it used to be that if I logged in from gdm as a sysadm_r user (staff_r > and sysadm_r) as defined in users, I would be logged in with sysadm_r. This > appears to have changed (or my memory is faulty). The default for a sysadm_r > user is to get staff_r and must use newrole -r sysadm_r to get that. Good! > That is the way I think it should work. Yes, I think that this was wrong earlier in default_contexts and subsequently changed. console login might still default to sysadm_r. > The same is true for root. As far as selinux is concerned, root is just > another sysadm_r user and the default role logging in from gdm is staff_r. > Is this what should be done. This will certainly be a change for most users. > When I login as root from gdm, I do not expect that I will be prompted for > root's password when I invoke system-config-users from the menu. You can create a /root/.default_contexts file that will take precedence over /etc/security/default_contexts for root logins. So you can still have 'root' default to sysadm_r if desired. > I also notice that doing an "su -" to root or another sysadm_r user will > default to sysadm_r role for that user. if it is from another sysadm_r user, > then I get a choice of sysadm_r (default) or staff_r. If it is from a user_r > user, then no choice, I just get sysadm_r. This has to do with the allowed role transitions in the policy. The standard policy didn't allow user_r -> sysadm_r at all; the user_canbe_sysadm tunable introduced a user_r -> sysadm_r transition, but did not include a user_r -> staff_r transition. No real reason to omit it in that case. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Apr 15 21:34:51 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Apr 2004 17:34:51 -0400 Subject: login default ... changed? In-Reply-To: <1082064561.25880.149.camel@moss-spartans.epoch.ncsc.mil> References: <200404151721.05876.gene@czarc.net> <1082064561.25880.149.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1082064891.25880.153.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-15 at 17:29, Stephen Smalley wrote: > Yes, I think that this was wrong earlier in default_contexts and > subsequently changed. console login might still default to sysadm_r. No, looks like the latest default_contexts also puts staff_r before sysadm_r for console logins, so those should also go to staff_r by default for non-root users authorized for both roles. Note that you may need to restorecon /root/.default_contexts to get it into the right type; otherwise, login/sshd/gdm can't read it. -- Stephen Smalley National Security Agency From kmacmillan at tresys.com Thu Apr 15 21:44:22 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 15 Apr 2004 17:44:22 -0400 Subject: ANN: Tresys Setools 1.3 Message-ID: <200404152143.i3FLhvJx021847@gotham.columbia.tresys.com> Setools version 1.3 has been released. It is available from http://www.tresys.com/selinux/ and the selinux cvs repository on SourceForge. This is a major new feature release that includes: - Two new commandline tools for finding and replacing file contexts. The tools findcon and replcon can recursively search for files with contexts that match search strings. The search strings can specify complete contexts, partial contexts, and shell globbing style wildcards. Replcon will then replace the context or part of the context. These tools fill an important gap for the administration of SElinux systems and for the analysis of SELinux policies. These tools are different from restorecon and chcon because they can recursively search directories and different from setfiles because they can set arbitrary contexts. - Seaudit now supports the creation of multiple views of the same audit log. This allows the user to view the results from multiple audit log queries at the same time. In addition, these queries can now be saved so that views can be recreated later. - Seaudit also has support for the new audit infrastructure included in the current NSA release, Fedora Core 2 test 2, and recent Linux kernels. Also, boolean change messages are supported. - Apol has complete support for conditional policies, including the viewing of conditional expressions, policy query and analysis results based on the current boolean values, and changing the boolean values. - The information flow analysis in Apol now supports assigning weights to object class permissions. These weights are used to specify the importance, or bandwidth, of object permissions so that the information flow analysis can return flows that contain important permissions first. This will make it easier for an analyst to find information flows in which they are interested quickly. - Seuser will now label newly created home directories. - Support for version 17 policies is included in all of the tools. Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 From gene at czarc.net Thu Apr 15 22:43:09 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 18:43:09 -0400 Subject: Locally defined file contexts Message-ID: <200404151843.09953.gene@czarc.net> Before I go and submit an RFE, I thought I would put this message out to see if what I am asking for is reasonable and/or I am missing something and it is already available. I have a need/want to be able to define some file contexts for directories and possibly separately mounted partitions which will have different attributes from what is currently defined. For example, I may want to mount one or more partitions under /home/ or /usr/local/ or even / which are to be shared read-only to anyone but writable only by root and one user. An example in my current situation on a FC1 system is where I have a very large partition for vmware in /home/vmware/ and I want this r/w by one user running as staff_r or user_r. As I currently understand things, only the tunable.te and users files are intended for modification by the user or local installation. The rest or the files are for policy-sources and will be updated when the package is updated. I want some place to put rules similar to those in file_contexts or types.fc which will be used to build the master files_contexts but not be replaced when policy-sources is updated. I am hoping that this capability already exists and I just do not understand that it is there. Gene From aleksey at nogin.org Thu Apr 15 22:48:59 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Thu, 15 Apr 2004 15:48:59 -0700 Subject: Locally defined file contexts In-Reply-To: <200404151843.09953.gene@czarc.net> References: <200404151843.09953.gene@czarc.net> Message-ID: <407F115B.6020309@nogin.org> On 15.04.2004 15:43, Gene Czarcinski wrote: > As I currently understand things, only the tunable.te and users files are > intended for modification by the user or local installation. The rest or the > files are for policy-sources and will be updated when the package is updated. > I want some place to put rules similar to those in file_contexts or types.fc > which will be used to build the master files_contexts but not be replaced > when policy-sources is updated. If you put an _additional_ file into the appropriate directory, it should be picked up by the make scripts and will not be overwritten by upgrades. For example, I have /etc/security/selinux/src/policy/domains/misc/local.te for local policy add-ons and /etc/security/selinux/src/policy/file_contexts/misc/local.fc for local file_contexts add-ons. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From gene at czarc.net Thu Apr 15 23:02:31 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 15 Apr 2004 19:02:31 -0400 Subject: Locally defined file contexts In-Reply-To: <407F115B.6020309@nogin.org> References: <200404151843.09953.gene@czarc.net> <407F115B.6020309@nogin.org> Message-ID: <200404151902.31622.gene@czarc.net> On Thursday 15 April 2004 18:48, Aleksey Nogin wrote: > On 15.04.2004 15:43, Gene Czarcinski wrote: > > As I currently understand things, only the tunable.te and users files are > > intended for modification by the user or local installation. The rest or > > the files are for policy-sources and will be updated when the package is > > updated. I want some place to put rules similar to those in file_contexts > > or types.fc which will be used to build the master files_contexts but not > > be replaced when policy-sources is updated. > > If you put an _additional_ file into the appropriate directory, it > should be picked up by the make scripts and will not be overwritten by > upgrades. For example, I have > /etc/security/selinux/src/policy/domains/misc/local.te for local policy > add-ons and /etc/security/selinux/src/policy/file_contexts/misc/local.fc > for local file_contexts add-ons. Yes, just what I am looking for. Perhaps it should be named "local" rather than "misc" but for now it exists. Thanks. Gene From aoliva at redhat.com Fri Apr 16 03:55:00 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 16 Apr 2004 00:55:00 -0300 Subject: bugs of the day In-Reply-To: <20040415202311.GA13523@nostromo.devel.redhat.com> References: <20040415202311.GA13523@nostromo.devel.redhat.com> Message-ID: On Apr 15, 2004, Bill Nottingham wrote: > 1) contexts aren't set correctly on install. Jeremy is looking at this. BTW... I noticed that my kickstart post-install scripts are not run with a sysadm context, so they can't quite set things up the way I'd like. Has this been changed? If not, is there any point in filing a bug report, or is the restriction on what post-install can do by design? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aleksey at nogin.org Fri Apr 16 08:03:29 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Fri, 16 Apr 2004 01:03:29 -0700 Subject: udev tries to execute files in /etc/dev.d Message-ID: <407F9351.6050303@cs.caltech.edu> I see a lot of messages of the form audit(1082098131.912:0): avc: denied { execute } for pid=3700 exe=/sbin/udev name=dbus.dev dev=hda2 ino=229313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file audit(1082098131.920:0): avc: denied { execute } for pid=3701 exe=/sbin/udev name=dbus.dev dev=hda2 ino=229313 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file audit(1082098131.921:0): avc: denied { execute } for pid=3702 exe=/sbin/udev name=pam_console.dev dev=hda2 ino=229315 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file audit(1082098131.921:0): avc: denied { execute } for pid=3703 exe=/sbin/udev name=selinux.dev dev=hda2 ino=229329 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file audit(1082098131.922:0): avc: denied { execute } for pid=3704 exe=/sbin/udev name=pam_console.dev dev=hda2 ino=229315 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file audit(1082098131.922:0): avc: denied { execute } for pid=3705 exe=/sbin/udev name=selinux.dev dev=hda2 ino=229329 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Should the files in /etc/dev.d be labeled differently? -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From nico33b at yahoo.fr Fri Apr 16 09:08:27 2004 From: nico33b at yahoo.fr (=?iso-8859-1?q?Nic=A4?=) Date: Fri, 16 Apr 2004 05:08:27 -0400 (EDT) Subject: Su from an unprivileged account In-Reply-To: <200404151640.07090.gene@czarc.net> Message-ID: <20040416090827.84060.qmail@web40906.mail.yahoo.com> Hmm... I turned off user_canbe_sysadm, I gave the user user_test the role staff_r, and when I try from the user_test shell with the context user_test:user_r:user_t to transit to the user_test:staff_r:staff_t : [user_test at localhost user_test]$ newrole -t staff_t -r staff_r Authenticating user_test. Password: failed to exec shell : Permission non accord??e Does anyone know why ? Nico --- Gene Czarcinski a ?crit : > On Thursday 15 April 2004 15:45, Daniel J Walsh > wrote: > > >Mmmm .. I wonder if it can be fine tuned enough > so that a user could su to > > >another regular user but not root or any user > with sysadm_r capability? > > > At the same time, a user with a sysadm_r > capability could su to anyone. > > > > > >That might be an interesting capability to have. > > > > > > > That is what staff_r is defined as. If you turn > off user_canbe_sysadm, > > you will end up with regular users who can't su > and > > staff users who can. > > Great! Well, that puts this message into my selinux > "Goodinfo" folder. > > Gene > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list __________________________________________________________ L?che-vitrine ou l?che-?cran ? magasinage.yahoo.ca From dwalsh at redhat.com Fri Apr 16 16:11:11 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 Apr 2004 12:11:11 -0400 Subject: bugs of the day In-Reply-To: References: <20040415202311.GA13523@nostromo.devel.redhat.com> Message-ID: <4080059F.3000902@redhat.com> Alexandre Oliva wrote: >On Apr 15, 2004, Bill Nottingham wrote: > > > >>1) contexts aren't set correctly on install. Jeremy is looking at this. >> >> > >BTW... I noticed that my kickstart post-install scripts are not run >with a sysadm context, so they can't quite set things up the way I'd >like. Has this been changed? If not, is there any point in filing a >bug report, or is the restriction on what post-install can do by >design? > > Post a bug. Post-install should be running in rpm_script_t I think. Which currently is unrestriced. Dan From dwalsh at redhat.com Fri Apr 16 16:18:17 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 Apr 2004 12:18:17 -0400 Subject: login default ... changed? In-Reply-To: <1082064891.25880.153.camel@moss-spartans.epoch.ncsc.mil> References: <200404151721.05876.gene@czarc.net> <1082064561.25880.149.camel@moss-spartans.epoch.ncsc.mil> <1082064891.25880.153.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <40800749.5060006@redhat.com> Stephen Smalley wrote: >On Thu, 2004-04-15 at 17:29, Stephen Smalley wrote: > > >>Yes, I think that this was wrong earlier in default_contexts and >>subsequently changed. console login might still default to sysadm_r. >> >> > >No, looks like the latest default_contexts also puts staff_r before >sysadm_r for console logins, so those should also go to staff_r by >default for non-root users authorized for both roles. > >Note that you may need to restorecon /root/.default_contexts to get it >into the right type; otherwise, login/sshd/gdm can't read it. > > I have added a /root/.default_contexts in policy*rpm. This allows users logging into root to default to sysadm_r and everywhere else as staff_r/or user_r. There is a comment in the /root/.default_contexts that you could change to allow sshd to automatically pick sysadm_r when logging in via ssh. (This is a potential security whole). Please check out these contexts to verify they make sence. Todays policy has the changes. Dan From dwalsh at redhat.com Fri Apr 16 16:22:44 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 Apr 2004 12:22:44 -0400 Subject: udev tries to execute files in /etc/dev.d In-Reply-To: <407F9351.6050303@cs.caltech.edu> References: <407F9351.6050303@cs.caltech.edu> Message-ID: <40800854.1040701@redhat.com> Aleksey Nogin wrote: > I see a lot of messages of the form > > audit(1082098131.912:0): avc: denied { execute } for pid=3700 > exe=/sbin/udev name=dbus.dev dev=hda2 ino=229313 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t > tclass=file > audit(1082098131.920:0): avc: denied { execute } for pid=3701 > exe=/sbin/udev name=dbus.dev dev=hda2 ino=229313 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t > tclass=file > audit(1082098131.921:0): avc: denied { execute } for pid=3702 > exe=/sbin/udev name=pam_console.dev dev=hda2 ino=229315 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t > tclass=file > audit(1082098131.921:0): avc: denied { execute } for pid=3703 > exe=/sbin/udev name=selinux.dev dev=hda2 ino=229329 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t > tclass=file > audit(1082098131.922:0): avc: denied { execute } for pid=3704 > exe=/sbin/udev name=pam_console.dev dev=hda2 ino=229315 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t > tclass=file > audit(1082098131.922:0): avc: denied { execute } for pid=3705 > exe=/sbin/udev name=selinux.dev dev=hda2 ino=229329 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t > tclass=file > > Should the files in /etc/dev.d be labeled differently? Yes I am writing policy for the new version of udev now. It should be inplace today. From gene at czarc.net Fri Apr 16 16:35:44 2004 From: gene at czarc.net (Gene Czarcinski) Date: Fri, 16 Apr 2004 12:35:44 -0400 Subject: udev tries to execute files in /etc/dev.d In-Reply-To: <40800854.1040701@redhat.com> References: <407F9351.6050303@cs.caltech.edu> <40800854.1040701@redhat.com> Message-ID: <200404161235.44120.gene@czarc.net> On Friday 16 April 2004 12:22, Daniel J Walsh wrote: > Yes I am writing policy for the new version of udev now. It should be > inplace today. When you get done, could you post the updates packages on ftp://people.redhat.com? Gene From dwalsh at redhat.com Fri Apr 16 17:42:30 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 Apr 2004 13:42:30 -0400 Subject: udev tries to execute files in /etc/dev.d In-Reply-To: <200404161235.44120.gene@czarc.net> References: <407F9351.6050303@cs.caltech.edu> <40800854.1040701@redhat.com> <200404161235.44120.gene@czarc.net> Message-ID: <40801B06.50105@redhat.com> Gene Czarcinski wrote: >On Friday 16 April 2004 12:22, Daniel J Walsh wrote: > > >>Yes I am writing policy for the new version of udev now. It should be >>inplace today. >> >> > >When you get done, could you post the updates packages on >ftp://people.redhat.com? > >Gene > > policy-1.11.2-9 is on people. You will need to relable the udev stuff to get it too work restorecon `rpm -q -l udev` Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From gene at czarc.net Fri Apr 16 21:41:38 2004 From: gene at czarc.net (Gene Czarcinski) Date: Fri, 16 Apr 2004 17:41:38 -0400 Subject: udev tries to execute files in /etc/dev.d In-Reply-To: <40801B06.50105@redhat.com> References: <407F9351.6050303@cs.caltech.edu> <200404161235.44120.gene@czarc.net> <40801B06.50105@redhat.com> Message-ID: <200404161741.38151.gene@czarc.net> On Friday 16 April 2004 13:42, Daniel J Walsh wrote: > Gene Czarcinski wrote: > >On Friday 16 April 2004 12:22, Daniel J Walsh wrote: > >>Yes I am writing policy for the new version of udev now. It should be > >>inplace today. > > > >When you get done, could you post the updates packages on > >ftp://people.redhat.com? > > > >Gene > > policy-1.11.2-9 is on people. > > You will need to relable the udev stuff to get it too work > > restorecon `rpm -q -l udev` OK, this seems to work (updated udev-024-4 and policy-1.11.2-3). I closed the bugzilla report. Thelvm problem is still there ... see bugzilla. I gave up on my VIA8233 sound adapter on the ASUS SK8V and install an Ensoniq card. This works .. even for regular users after I setfiles /dev and setfiles /udev I sure hope I can get a "clean" snapshot of development soon so I can try a fresh install and see how things will work without all of the packages changing. Gene From mike at flyn.org Fri Apr 16 22:27:45 2004 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 16 Apr 2004 17:27:45 -0500 Subject: Pam_mount and SELinux In-Reply-To: <1081984973.23204.15.camel@optimus-prime.boston.redhat.com> References: <20040412231329.GA8336@imp.flyn.org> <407B4ECC.3080002@redhat.com> <20040414215036.GA3959@imp.flyn.org> <1081984898.23204.13.camel@optimus-prime.boston.redhat.com> <1081984973.23204.15.camel@optimus-prime.boston.redhat.com> Message-ID: <20040416222745.GA3226@imp.flyn.org> [...] >>1. Pam_mount needs be able to work in /var/run/pam_mount: >>allow $1_su_t var_run_t:dir { getattr add_name remove_name write }; >>allow $1_su_t var_run_t:file { create getattr setattr read write lock >>unlink }; > Look at the macros, You really want to create a transition rule that > tells the kernel to create > files under a specific context in the /var/run directory. So a rule like > var_run_domain($1_su) will create a $1_su_var_run_t context. I think I want to make a pam_mount context of some type. This is because login, gdm, su, etc. will all share the same /var/run/pam_mount. But when I try to do something like "var_run_domain(pam_mount)" I get the following errors on make load: [...] /usr/bin/checkpolicy -o /etc/security/selinux/policy.17 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf domains/user.te:47:ERROR 'name conflict for type pam_mount_var_run_t' at token ';' on line 39900: type pam_mount_var_run_t, file_type, sysadmfile, pidfile; #line 47 /usr/bin/checkpolicy: error(s) encountered while parsing configuration [...] Obviously, var_run_domain(pam_mount) is a reach. Could someone explain a little more about how that var_run_domain works? [...] >> I added a mounton rule, but this did not solve my problem. I am >> especially confused by the fact that SELinux is not logging any failures. >> I would expect an "avc: denied" error. This feels like a traditional >> Unix permissions issue but does not occur when SELinux is not enforcing >> its policies. [...] [...] > Solution: > > role $1_r types mount_t; [...] The following does what I need: domain_auto_trans($1_su_t, mount_exec_t, mount_t) role $1_r types mount_t; But out of curiosity, why does the domain_auto_trans statement not imply the role statement? Would you ever have a domain_auto_trans without a role? -- Mike :wq From rhallyx at mindspring.com Sat Apr 17 00:37:44 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Fri, 16 Apr 2004 20:37:44 -0400 Subject: acv denied messages, misceleneous Message-ID: <40807C58.7030200@mindspring.com> Attached is a log/messages file from running in enforcing mode. Some of the messages are from running "yum update" to get todays updates and some are from running Mozilla mail to send a message. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: messages.20040416 URL: From mike at flyn.org Sat Apr 17 15:01:53 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 17 Apr 2004 10:01:53 -0500 Subject: SELinux and gtkam Message-ID: <20040417150153.GA3596@imp.flyn.org> The digital camera application gtkam does not seem to want to play nicely with SELinux. Gtkam needs to access /proc/bus/usb because it uses libusb. When I try to run gtkam as a user (user_u:user_r:user_t) I get: Apr 17 09:57:47 imp kernel: avc: denied { read } for pid=3620 exe=/usr/bin/gtkam dev= ino=724 scontext=user_u:user_r:user_t tcontext=system_u:object_r:usbfs_t tclass=dir Apr 17 09:57:47 imp kernel: Apr 17 09:57:47 imp kernel: avc: denied { search } for pid=3620 exe=/usr/bin/gtkam dev= ino=1 scontext=user_u:user_r:user_t tcontext=system_u:object_r:sysfs_t tclass=dir Do we need a new domain like gtkam_t, gphoto_t or libusb_t? -- Mike :wq From gene at czarc.net Sat Apr 17 15:06:57 2004 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 17 Apr 2004 11:06:57 -0400 Subject: SELinux and gtkam In-Reply-To: <20040417150153.GA3596@imp.flyn.org> References: <20040417150153.GA3596@imp.flyn.org> Message-ID: <200404171106.57522.gene@czarc.net> On Saturday 17 April 2004 11:01, W. Michael Petullo wrote: > The digital camera application gtkam does not seem to want to play nicely > with SELinux. Gtkam needs to access /proc/bus/usb because it uses libusb. > When I try to run gtkam as a user (user_u:user_r:user_t) I get: > > Apr 17 09:57:47 imp kernel: avc: denied { read } for pid=3620 > exe=/usr/bin/gtkam dev= ino=724 scontext=user_u:user_r:user_t > tcontext=system_u:object_r:usbfs_t tclass=dir Apr 17 09:57:47 imp kernel: > Apr 17 09:57:47 imp kernel: avc: denied { search } for pid=3620 > exe=/usr/bin/gtkam dev= ino=1 scontext=user_u:user_r:user_t > tcontext=system_u:object_r:sysfs_t tclass=dir > > Do we need a new domain like gtkam_t, gphoto_t or libusb_t? bugzilla please so it does not fall through the cracks. From nutello at sweetness.com Sun Apr 18 16:52:56 2004 From: nutello at sweetness.com (Rudi Chiarito) Date: Sun, 18 Apr 2004 18:52:56 +0200 Subject: gnome-cpufreq-applet problem Message-ID: <20040418165256.GC5220@server4.8080.it> Any attempts to start the 3rd party GNOME cpufreq applet (which can be found at http://linups.org/~kal/gnome-cpufreq-applet/) will result in two identical error messages like this: avc: denied { search } for pid=9558 exe=/usr/libexec/gnome-cpufreq-applet dev= ino=1 scontext=user_u:user_r:user_t tcontext=system_u:object_r:sysfs_t tclass=dir The program is trying to read in /sys/devices/system/cpu/cpu*/cpufreq/. Rudi From fedora at andrewfarris.com Sun Apr 18 23:35:59 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Sun, 18 Apr 2004 16:35:59 -0700 Subject: Failed CD mount as normal user (enforcing), works in permissive Message-ID: <1082331358.6137.48.camel@CirithUngol> Mounting FC1 cd1 as normal user fails when in enforcing mode, but is allowed (with audit) when in permissive mode. Note: I relinked files in a modified way, it is straightforward, but I apologize if it confuses (/mnt/cdrom1 is not used, but links to /mnt/cdrw). /mnt/cdrw: directory /dev/hdd: block special (22/64) 426829 8 drwxr-xr-x 2 system_u:object_r:mnt_t 0 0 4 Mar 29 17:33 cdrw/ 66236 4 brw------- 1 system_u:object_r:fixed_disk_device_t 502 6 22, 64 Feb 23 13:02 hdd $-> getenforce enforcing $-> mount /mnt/cdrw mount: only root can mount /dev/hdd on /mnt/cdrw (root runs setenforce 0) (normal user) $-> mount /mnt/cdrw (success mounting) -- audit generated Apr 18 18:17:07 CirithUngol kernel: audit(1082326627.383:0): avc: denied { getattr } for pid=20162 exe=/bin/mount path=/dev/hdd dev=hdb8 ino=66236 scontext=user_u:user_r:user_mount_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file /etc/fstab entry: /dev/hdd /mnt/cdrw iso9660 noauto,owner,ro 0 0 policy version: policy-1.11.2-9 (a full relabel was not performed since this policy was updated) -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From mike at flyn.org Mon Apr 19 00:33:26 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sun, 18 Apr 2004 19:33:26 -0500 Subject: SELinux and gtkam In-Reply-To: <200404171106.57522.gene@czarc.net> References: <20040417150153.GA3596@imp.flyn.org> <200404171106.57522.gene@czarc.net> Message-ID: <20040419003326.GA9225@imp.flyn.org> >> The digital camera application gtkam does not seem to want to play nicely >> with SELinux. Gtkam needs to access /proc/bus/usb because it uses libusb. >> When I try to run gtkam as a user (user_u:user_r:user_t) I get: >> >> Apr 17 09:57:47 imp kernel: avc: denied { read } for pid=3620 >> exe=/usr/bin/gtkam dev= ino=724 scontext=user_u:user_r:user_t >> tcontext=system_u:object_r:usbfs_t tclass=dir Apr 17 09:57:47 imp kernel: >> Apr 17 09:57:47 imp kernel: avc: denied { search } for pid=3620 >> exe=/usr/bin/gtkam dev= ino=1 scontext=user_u:user_r:user_t >> tcontext=system_u:object_r:sysfs_t tclass=dir >> >> Do we need a new domain like gtkam_t, gphoto_t or libusb_t? > bugzilla please so it does not fall through the cracks. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121207. -- Mike :wq From dax at gurulabs.com Mon Apr 19 00:59:25 2004 From: dax at gurulabs.com (Dax Kelson) Date: Sun, 18 Apr 2004 18:59:25 -0600 Subject: disabled selinux??? Message-ID: <1082336365.17961.1.camel@mentor.gurulabs.com> > fam-2.6.10-8 > ------------ > * Fri Apr 16 2004 Alex Larsson 2.6.10-8 > > - re-enable fam since we disabled selinux What's the story? Hve the SELinux plans changed with FC2? From efthym at gmx.net Mon Apr 19 01:19:24 2004 From: efthym at gmx.net (Efthym) Date: Sun, 18 Apr 2004 21:19:24 -0400 Subject: VMware + SELinux Message-ID: Hi all I've recently installed VMware 4.5.1 on Fedora 2 Test 2 with SELinux in enforcing mode. The configuration process only works while enforce=0 and after every reboot I get a message that VMware has not been configured yet and I have to rerun the configuration and recreate the vmmon and vmnet modules. During this I get a hell of a lot avc denied messages. I'm quite new to SELinux but i'm guessing this is because there is no default permission for VMware in the policy. Has anyone else tried this, or perhaps get some help how to configure VMware to work alongside SELinux ? VMware-workstation-4.5.1-7568 policy-1.11.2-8 kernel-2.6.5-1.326 Thanx From russell at coker.com.au Mon Apr 19 13:13:04 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 19 Apr 2004 23:13:04 +1000 Subject: Locally defined file contexts In-Reply-To: <200404151902.31622.gene@czarc.net> References: <200404151843.09953.gene@czarc.net> <407F115B.6020309@nogin.org> <200404151902.31622.gene@czarc.net> Message-ID: <200404192313.04885.russell@coker.com.au> On Fri, 16 Apr 2004 09:02, Gene Czarcinski wrote: > > If you put an _additional_ file into the appropriate directory, it > > should be picked up by the make scripts and will not be overwritten by > > upgrades. For example, I have > > /etc/security/selinux/src/policy/domains/misc/local.te for local policy > > add-ons and /etc/security/selinux/src/policy/file_contexts/misc/local.fc > > for local file_contexts add-ons. > > Yes, just what I am looking for. > > Perhaps it should be named "local" rather than "misc" but for now it > exists. domains/misc and file_contexts/misc are not necessarily for local customisations, they are for files without a match. For every .te file in domains/program there must be a matching .fc file in file_contexts/program (or you can't build the file_contexts file). Any .fc file in file_contexts/program that does not have a matching .te file will not be used. So if you have a .fc file with no matching .te file or a .te with no matching .fc then you have to put it in a misc directory. For a file you create yourself use a name like local.te or custom.te that is not likely to be used in any distributed policy. -- 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 jacob at e303.vildanden.afb.lu.se Mon Apr 19 18:21:14 2004 From: jacob at e303.vildanden.afb.lu.se (jacob) Date: Mon, 19 Apr 2004 20:21:14 +0200 (CEST) Subject: SELinux issues Message-ID: Some SELinux issues I've been experiencing when running in enforcing mode: * Only my own user processes show up in top/gnome-system-monitor/ps aux, no root or other users processes are visible. * /lib/modules is marked with '?--------- ? ? ? ? modules' for me as normal user, I can't even cd into it. Looks ok as root though. * Normal user can't mount cdrom, only root can. * fam & nautilus are the ones spewing out the most avc messages in dmesg. Running latest rawhide as of 2004/04/19 policy : 1.11.2-9 libselinux : 1.11.1-1 /Jacob From walters at redhat.com Mon Apr 19 19:25:57 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 19 Apr 2004 15:25:57 -0400 Subject: SELinux issues In-Reply-To: References: Message-ID: <1082402757.12261.22.camel@nexus.verbum.private> On Mon, 2004-04-19 at 14:21, jacob wrote: > Some SELinux issues I've been experiencing when running in enforcing mode: > > * Only my own user processes show up in top/gnome-system-monitor/ps aux, > no root or other users processes are visible. That's expected. > * /lib/modules is marked with '?--------- ? ? ? ? modules' for me as > normal user, I can't even cd into it. Looks ok as root though. That's also expected. The ??? is because user_t is denied getattr for modules_object_t. > * Normal user can't mount cdrom, only root can. Do you have the "user" option in /etc/fstab and the user_can_mount tunable enabled? > * fam & nautilus are the ones spewing out the most avc messages in > dmesg. fam is known to be incompatible with SELinux. I'm working on a patch to disable it if SELinux is enabled. What nautilus AVC messages are you seeing? the /initrd one is a known issue, also on my queue of stuff to fix. -------------- 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 mike at flyn.org Mon Apr 19 20:40:01 2004 From: mike at flyn.org (mike at flyn.org) Date: Mon, 19 Apr 2004 15:40:01 -0500 Subject: SELinux issues Message-ID: <20040419194001.D1C4231546@neuromancer.voxel.net> >> * fam & nautilus are the ones spewing out the most avc messages in >> dmesg. > fam is known to be incompatible with SELinux. I'm working on a patch to > disable it if SELinux is enabled. What nautilus AVC messages are you > seeing? the /initrd one is a known issue, also on my queue of stuff to > fix. Is there a plan to replace fam's functionality? If I do a "touch /home/mike/foo" and have a nautilus window displaying /home/mike/foo then this file immediately appears in the nautilus window (without manually telling nautilus to reload the directory's contents). Will this be impossible with SELinux running in enforcing mode? Or is there something coming down the pipe to handle this? I think fam is required by the nautilus package. Will this requirement be relaxed? -- Mike From walters at redhat.com Mon Apr 19 20:42:29 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 19 Apr 2004 16:42:29 -0400 Subject: SELinux issues In-Reply-To: <20040419194001.D1C4231546@neuromancer.voxel.net> References: <20040419194001.D1C4231546@neuromancer.voxel.net> Message-ID: <1082407349.16025.3.camel@nexus.verbum.private> On Mon, 2004-04-19 at 16:40, mike at flyn.org wrote: > Is there a plan to replace fam's functionality? I believe someone is working on it. > If I do a "touch > /home/mike/foo" and have a nautilus window displaying /home/mike/foo then > this file immediately appears in the nautilus window (without manually > telling nautilus to reload the directory's contents). Will this be > impossible with SELinux running in enforcing mode? Once we have a replacement, it will be possible. > I think fam is required by the nautilus package. Will this requirement be > relaxed? The fam package is required by the nautilus package, yes. However my patch will just make libfam client calls return an error. Nautilus should treat this the same as if famd isn't running, and just not monitor files. -------------- 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 Tue Apr 20 02:50:30 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 19 Apr 2004 22:50:30 -0400 Subject: mkinitrd problems - 2 slightly different ones... Message-ID: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> Running the fedora-devel code as of 0419.. hitting some issues with installing a new kernel due to mkinitrd failing. System has 1 disk, using LVM for the root filesystem - the bigger error seems to be LVM-specific (looks like bootloader_t needs to be able to do stuff with lvm_exec_t and lvm_etc_t). First, a quick example of shooting yourself in the foot: # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10 (wheel) context=root:sysadm_r:sysadm_t # /sbin/mkinitrd -v /boot/initrd-2.6.5-1.327.img 2.6.5-1.327 Looking for deps of module ide-disk /sbin/mkinitrd: line 1: /bin/ls: Permission denied Looking for deps of module ext3 jbd Looking for deps of module jbd Looking for deps of module dm-mod Using modules: ./kernel/fs/jbd/jbd.ko ./kernel/fs/ext3/ext3.ko ./kernel/drivers/md/dm-mod.ko Using loopback device /dev/loop0 rm: cannot get current directory: Permission denied /sbin/nash -> /tmp/initrd.Y15570/bin/nash /sbin/insmod.static -> /tmp/initrd.Y15570/bin/insmod copy from /lib/modules/2.6.5-1.327/./kernel/fs/jbd/jbd.ko(elf32-i386) to /tmp/initrd.Y15570/lib/jbd.ko(elf32-i386) copy from /lib/modules/2.6.5-1.327/./kernel/fs/ext3/ext3.ko(elf32-i386) to /tmp/initrd.Y15570/lib/ext3.ko(elf32-i386) copy from /lib/modules/2.6.5-1.327/./kernel/drivers/md/dm-mod.ko(elf32-i386) to /tmp/initrd.Y15570/lib/dm-mod.ko(elf32-i386) /sbin/lvm.static -> /tmp/initrd.Y15570/bin/lvm cp: cannot open `/sbin/lvm.static' for reading: Permission denied /etc/lvm -> /tmp/initrd.Y15570/etc/lvm `/etc/lvm/lvm.conf' -> `/tmp/initrd.Y15570/etc/lvm/lvm.conf' cp: cannot open `/etc/lvm/lvm.conf' for reading: Permission denied Loading module jbd Loading module ext3 Loading module dm-mod rm: cannot get current directory: Permission denied rm: remove.c:378: AD_pop_and_chdir: Assertion `AD_stack_height (ds)' failed. /sbin/mkinitrd: line 678: 15649 Aborted rm -rf $MNTIMAGE $MNTPOINT $IMAGE # Ouch. Gotta love that final 'rm' error. :) How did I cause that? I was stupidly still cd'ed into /etc/security/selinux/src/policy at the time. ;) Got *tons* of these: Apr 19 22:31:27 orange kernel: audit(1082428287.917:0): avc: denied { search } for pid=15434 exe=/bin/bash name=policy dev=dm-0 ino=85034 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:policy_src_t tclass=dir and here's the one that killed the rm command, I think: Apr 19 22:31:28 orange kernel: audit(1082428288.257:0): avc: denied { search } for pid=15649 exe=/bin/rm name=policy dev=dm-0 ino=85034 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:policy_src_t tclass=dir (total of 88 failed 'search' - odd part is that I did NOT have '.' in my $PATH). OK, so take 2 - this gets rid of the 88 failed search requests: # cd / # /sbin/mkinitrd -v /boot/initrd-2.6.5-1.327.img 2.6.5-1.327 Looking for deps of module ide-disk /sbin/mkinitrd: line 1: /bin/ls: Permission denied Looking for deps of module ext3 jbd Looking for deps of module jbd Looking for deps of module dm-mod Using modules: ./kernel/fs/jbd/jbd.ko ./kernel/fs/ext3/ext3.ko ./kernel/drivers/md/dm-mod.ko Using loopback device /dev/loop0 /sbin/nash -> /tmp/initrd.f15792/bin/nash /sbin/insmod.static -> /tmp/initrd.f15792/bin/insmod copy from /lib/modules/2.6.5-1.327/./kernel/fs/jbd/jbd.ko(elf32-i386) to /tmp/initrd.f15792/lib/jbd.ko(elf32-i386) copy from /lib/modules/2.6.5-1.327/./kernel/fs/ext3/ext3.ko(elf32-i386) to /tmp/initrd.f15792/lib/ext3.ko(elf32-i386) copy from /lib/modules/2.6.5-1.327/./kernel/drivers/md/dm-mod.ko(elf32-i386) to /tmp/initrd.f15792/lib/dm-mod.ko(elf32-i386) /sbin/lvm.static -> /tmp/initrd.f15792/bin/lvm cp: cannot open `/sbin/lvm.static' for reading: Permission denied /etc/lvm -> /tmp/initrd.f15792/etc/lvm `/etc/lvm/lvm.conf' -> `/tmp/initrd.f15792/etc/lvm/lvm.conf' cp: cannot open `/etc/lvm/lvm.conf' for reading: Permission denied Loading module jbd Loading module ext3 Loading module dm-mod A bit better - here's the remaining avc messages: Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc: denied { execute } for pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc: denied { read } for pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc: denied { execute } for pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:ls_exec_t tclass=file Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc: denied { read } for pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:ls_exec_t tclass=file Apr 19 22:36:46 orange kernel: SELinux: initialized (dev loop0, type ext2), uses xattr Apr 19 22:36:47 orange kernel: audit(1082428607.002:0): avc: denied { read } for pid=15834 exe=/bin/cp name=lvm.static dev=dm-0 ino=72206 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file Apr 19 22:36:47 orange kernel: audit(1082428607.007:0): avc: denied { read } for pid=15835 exe=/bin/cp name=lvm.conf dev=dm-0 ino=82396 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_etc_t tclass=file -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From walters at redhat.com Tue Apr 20 03:12:29 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 19 Apr 2004 23:12:29 -0400 Subject: mkinitrd problems - 2 slightly different ones... In-Reply-To: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> References: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> Message-ID: <1082430749.1713.6.camel@nexus.verbum.private> On Mon, 2004-04-19 at 22:50, Valdis.Kletnieks at vt.edu wrote: > Running the fedora-devel code as of 0419.. hitting some issues > with installing a new kernel due to mkinitrd failing. > > System has 1 disk, using LVM for the root filesystem - the bigger error seems > to be LVM-specific (looks like bootloader_t needs to be able to do stuff > with lvm_exec_t and lvm_etc_t). I don't think anyone here has really messed seriously with SELinux and LVM yet. Looks like you are the lucky winner :) > rm: remove.c:378: AD_pop_and_chdir: Assertion `AD_stack_height (ds)' failed. Nice. I think many applications were written with the idea that they would always have permissions to the current working directory. > How did I cause that? I was stupidly still cd'ed into /etc/security/selinux/src/policy at the time. ;) Yeah. > Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc: denied { execute } for pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file > Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc: denied { read } for pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file > Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc: denied { execute } for pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:ls_exec_t tclass=file > Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc: denied { read } for pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:ls_exec_t tclass=file > Apr 19 22:36:46 orange kernel: SELinux: initialized (dev loop0, type ext2), uses xattr > Apr 19 22:36:47 orange kernel: audit(1082428607.002:0): avc: denied { read } for pid=15834 exe=/bin/cp name=lvm.static dev=dm-0 ino=72206 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file > Apr 19 22:36:47 orange kernel: audit(1082428607.007:0): avc: denied { read } for pid=15835 exe=/bin/cp name=lvm.conf dev=dm-0 ino=82396 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_etc_t tclass=file I added stuff to try to fix this into policy, will be in the next upload. Patch attached, let me know if it works for you... -------------- next part -------------- A non-text attachment was scrubbed... Name: lvm.patch Type: text/x-patch Size: 872 bytes Desc: not available URL: -------------- 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 Tue Apr 20 03:25:52 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 19 Apr 2004 23:25:52 -0400 Subject: mkinitrd problems - 2 slightly different ones... In-Reply-To: Your message of "Mon, 19 Apr 2004 23:12:29 EDT." <1082430749.1713.6.camel@nexus.verbum.private> References: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> <1082430749.1713.6.camel@nexus.verbum.private> Message-ID: <200404200325.i3K3Pqel005144@turing-police.cc.vt.edu> On Mon, 19 Apr 2004 23:12:29 EDT, Colin Walters said: > I added stuff to try to fix this into policy, will be in the next > upload. Patch attached, let me know if it works for you... Almost right, it needs lvm_etc_t as well - fixed patch attached, thanks for the fast feedback... -------------- next part -------------- A non-text attachment was scrubbed... Name: lvm.patch Type: application/x-patch Size: 1329 bytes Desc: lvm.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From walters at redhat.com Tue Apr 20 03:32:55 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 19 Apr 2004 23:32:55 -0400 Subject: mkinitrd problems - 2 slightly different ones... In-Reply-To: <200404200325.i3K3Pqel005144@turing-police.cc.vt.edu> References: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> <1082430749.1713.6.camel@nexus.verbum.private> <200404200325.i3K3Pqel005144@turing-police.cc.vt.edu> Message-ID: <1082431975.1713.11.camel@nexus.verbum.private> On Mon, 2004-04-19 at 23:25, Valdis.Kletnieks at vt.edu wrote: > On Mon, 19 Apr 2004 23:12:29 EDT, Colin Walters said: > > > I added stuff to try to fix this into policy, will be in the next > > upload. Patch attached, let me know if it works for you... > > Almost right, it needs lvm_etc_t as well - fixed patch attached, > thanks for the fast feedback... Ah, that was actually a typo in my original patch. If you change the r_dir_file(bootloader_t, lvm_t) to r_dir_file(bootloader_t, lvm_etc_t) does it work? -------------- 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 Tue Apr 20 03:43:36 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 19 Apr 2004 23:43:36 -0400 Subject: mkinitrd problems - 2 slightly different ones... In-Reply-To: Your message of "Mon, 19 Apr 2004 23:32:55 EDT." <1082431975.1713.11.camel@nexus.verbum.private> References: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> <1082430749.1713.6.camel@nexus.verbum.private> <200404200325.i3K3Pqel005144@turing-police.cc.vt.edu> <1082431975.1713.11.camel@nexus.verbum.private> Message-ID: <200404200343.i3K3haYI005652@turing-police.cc.vt.edu> On Mon, 19 Apr 2004 23:32:55 EDT, Colin Walters said: > Ah, that was actually a typo in my original patch. If you change the > r_dir_file(bootloader_t, lvm_t) > to > r_dir_file(bootloader_t, lvm_etc_t) > does it work? Yes, that works too... Tomorrow's job: Figure out why /bin/ls and /bin/rm died just because I was cd'ed to the wrong place when I did the initrd, even though they weren't being asked to do anything with $PWD.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dax at gurulabs.com Tue Apr 20 07:40:08 2004 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 20 Apr 2004 01:40:08 -0600 Subject: SELinux and Palm devices (with avc messages) Message-ID: <1082446808.3652.10.camel@mentor.gurulabs.com> This has been on my ToDo list for awhile, here goes. I have a Treo 600 (finally, a converged device done right) Palm OS 5.2 pda, cell phone, OGG/MP3/WMA player, mobile email, and mobile ssh client. When I plug it in, it shows up at /dev/usb/ttyUSB1 Many of the binaries from the pilot-link package want to read and write to that character device file. For sure the pilot-xfer utility. For example, audit(1082445673.351:0): avc: denied { read write } for pid=3647 exe=/usr/bin/pilot-xfer name=ttyUSB1 dev=hda8 ino=1210304 scontext=user_u:user_r:user_t tcontext=system_u:object_r:tty_device_t tclass=chr_file Additionally, I need to sync Evolution's calendar and address book with my Treo. Evolution uses gnome-pilot and it's gpilotd daemon to communicate with Palm devices. Currently this results in failure with the following avc message: audit(1082445978.961:0): avc: denied { read write } for pid=3735 exe=/usr/libexec/gpilotd name=ttyUSB1 dev=hda8 ino=1210304 scontext=user_u:user_r:user_t tcontext=system_u:object_r:tty_device_t tclass=chr_file Dax Kelson Guru Labs From russell at coker.com.au Tue Apr 20 14:25:28 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Apr 2004 00:25:28 +1000 Subject: mkinitrd problems - 2 slightly different ones... In-Reply-To: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> References: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> Message-ID: <200404210025.28060.russell@coker.com.au> On Tue, 20 Apr 2004 12:50, Valdis.Kletnieks at vt.edu wrote: > Running the fedora-devel code as of 0419.. hitting some issues > with installing a new kernel due to mkinitrd failing. > > System has 1 disk, using LVM for the root filesystem - the bigger error > seems to be LVM-specific (looks like bootloader_t needs to be able to do > stuff with lvm_exec_t and lvm_etc_t). Regarding the issue of search access to the current directory. One work-around is that if you are writing a program that launches such a fussy program then you can have it do "cd /" before the exec. I have attached a patch for lvm that cleans up a few things (and also has some non-LVM changes that won't cause any harm), and a patch for bootloader.te which will hopefully fix this issue. Please apply both patches, relabel /etc/lvm, and let me know how it goes. -- 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 -------------- #DESC LVM - Linux Volume Manager # # Author: Michael Kaufman # X-Debian-Packages: lvm10 lvm2 lvm-common # ################################# # # Rules for the lvm_t domain. # # lvm_t is the domain for LVM administration. # lvm_exec_t is the type of the corresponding programs. # lvm_etc_t is for read-only LVM configuration files. # lvm_metadata_t is the type of LVM metadata files in /etc that are # modified at runtime. # type lvm_vg_t, file_type, sysadmfile; type lvm_metadata_t, file_type, sysadmfile; type lvm_control_t, file_type, device_type; etcdir_domain(lvm) typealias lvm_etc_t alias etc_lvm_t; lock_domain(lvm) daemon_base_domain(lvm, `, fs_domain') role sysadm_r types lvm_t; # LVM will complain a lot if it cannot set its priority. allow lvm_t self:process { setsched }; allow lvm_t self:fifo_file rw_file_perms; r_dir_file(lvm_t, proc_t) allow lvm_t self:file r_file_perms; # Read system variables in /proc/sys allow lvm_t sysctl_kernel_t:file r_file_perms; allow lvm_t sysctl_kernel_t:dir r_dir_perms; # Read /sys/block. Device mapper metadata is kept there. r_dir_file(lvm_t, sysfs_t) # Read configuration files in /etc. allow lvm_t { etc_t etc_runtime_t }:file { getattr read }; # LVM creates block devices in /dev/mapper or /dev/ # depending on its version file_type_auto_trans(lvm_t, device_t, fixed_disk_device_t, blk_file) # LVM(2) needs to create directores (/dev/mapper, /dev/) # and links from /dev/ to /dev/mapper/- allow lvm_t device_t:dir create_dir_perms; allow lvm_t device_t:lnk_file create_file_perms; # /lib/lvm- holds the actual LVM binaries (and symlinks) allow lvm_t lvm_exec_t:dir search; allow lvm_t lvm_exec_t:{ file lnk_file } r_file_perms; tmp_domain(lvm) # DAC overrides and mknod for modifying /dev entries (vgmknodes) allow lvm_t self:capability { dac_override mknod sys_admin }; # Write to /etc/lvm, /etc/lvmtab, /etc/lvmtab.d file_type_auto_trans(lvm_t, etc_t, lvm_etc_t, dir) file_type_auto_trans(lvm_t, { etc_t lvm_etc_t }, lvm_metadata_t, file) # Inherit and use descriptors from init. allow lvm_t init_t:fd use; # LVM is split into many individual binaries can_exec(lvm_t, lvm_exec_t) # Access disk devices. allow lvm_t fixed_disk_device_t:chr_file create_file_perms; # Access terminals. allow lvm_t { initrc_devpts_t admin_tty_type }:chr_file rw_file_perms; ifdef(`gnome-pty-helper.te', `allow lvm_t sysadm_gph_t:fd use;') allow lvm_t privfd:fd use; allow lvm_t devpts_t:dir getattr; read_locale(lvm_t) # LVM (vgscan) scans for devices by stating every file in /dev and applying a regex... dontaudit lvm_t device_type:{ chr_file blk_file } getattr; -------------- next part -------------- A non-text attachment was scrubbed... Name: boot.diff Type: text/x-diff Size: 1338 bytes Desc: not available URL: From mike at flyn.org Tue Apr 20 16:20:12 2004 From: mike at flyn.org (mike at flyn.org) Date: Tue, 20 Apr 2004 11:20:12 -0500 Subject: .te file in RPMs Message-ID: <20040420152012.9F93931530@neuromancer.voxel.net> The Fedora SELinux roadmap states: > rpm should handle packages which contain their own .te files > jbj owns this > Right now this will mean installing doing a 'make reload' or whatever. dwalsh > can work with jbj to make that happen inside rpm. > A big problem is having to use make+m4 I would like to learn the proper way for a package to install an associated te file, rebuild the SELinux policy and load the new policy. Could someone point me in the proper direction? Is there something better than "make reload" in the post-install script? -- Mike From russell at coker.com.au Tue Apr 20 15:45:10 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Apr 2004 01:45:10 +1000 Subject: mkinitrd problems - 2 slightly different ones... In-Reply-To: <200404210025.28060.russell@coker.com.au> References: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> <200404210025.28060.russell@coker.com.au> Message-ID: <200404210145.10921.russell@coker.com.au> On Wed, 21 Apr 2004 00:25, Russell Coker wrote: > On Tue, 20 Apr 2004 12:50, Valdis.Kletnieks at vt.edu wrote: > > Running the fedora-devel code as of 0419.. hitting some issues > > with installing a new kernel due to mkinitrd failing. > > > > System has 1 disk, using LVM for the root filesystem - the bigger error > > seems to be LVM-specific (looks like bootloader_t needs to be able to do > > stuff with lvm_exec_t and lvm_etc_t). > > Regarding the issue of search access to the current directory. One > work-around is that if you are writing a program that launches such a fussy > program then you can have it do "cd /" before the exec. > > I have attached a patch for lvm that cleans up a few things (and also has > some non-LVM changes that won't cause any harm), and a patch for > bootloader.te which will hopefully fix this issue. > > Please apply both patches, relabel /etc/lvm, and let me know how it goes. It seems that my lvm patch was messed up, I didn't have the latest version. I've attached a new lvm.te that is correct. -- 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 -------------- #DESC LVM - Linux Volume Manager # # Author: Michael Kaufman # X-Debian-Packages: lvm10 lvm2 lvm-common # ################################# # # Rules for the lvm_t domain. # # lvm_t is the domain for LVM administration. # lvm_exec_t is the type of the corresponding programs. # lvm_etc_t is for read-only LVM configuration files. # lvm_metadata_t is the type of LVM metadata files in /etc that are # modified at runtime. # type lvm_vg_t, file_type, sysadmfile; type lvm_metadata_t, file_type, sysadmfile; type lvm_control_t, file_type, device_type; etcdir_domain(lvm) typealias lvm_etc_t alias etc_lvm_t; lock_domain(lvm) daemon_base_domain(lvm, `, fs_domain') role sysadm_r types lvm_t; # LVM will complain a lot if it cannot set its priority. allow lvm_t self:process { setsched }; allow lvm_t self:fifo_file rw_file_perms; r_dir_file(lvm_t, proc_t) allow lvm_t self:file r_file_perms; # Read system variables in /proc/sys allow lvm_t sysctl_kernel_t:file r_file_perms; allow lvm_t sysctl_kernel_t:dir r_dir_perms; # Read /sys/block. Device mapper metadata is kept there. r_dir_file(lvm_t, sysfs_t) # Read configuration files in /etc. allow lvm_t { etc_t etc_runtime_t }:file { getattr read }; # LVM creates block devices in /dev/mapper or /dev/ # depending on its version file_type_auto_trans(lvm_t, device_t, fixed_disk_device_t, blk_file) # LVM(2) needs to create directores (/dev/mapper, /dev/) # and links from /dev/ to /dev/mapper/- allow lvm_t device_t:dir create_dir_perms; allow lvm_t device_t:lnk_file create_file_perms; # /lib/lvm- holds the actual LVM binaries (and symlinks) allow lvm_t lvm_exec_t:dir search; allow lvm_t lvm_exec_t:{ file lnk_file } r_file_perms; tmp_domain(lvm) # DAC overrides and mknod for modifying /dev entries (vgmknodes) allow lvm_t self:capability { dac_override mknod sys_admin }; # Write to /etc/lvm, /etc/lvmtab, /etc/lvmtab.d file_type_auto_trans(lvm_t, { etc_t lvm_etc_t }, lvm_metadata_t, file) allow lvm_t lvm_metadata_t:dir r_dir_perms; # Inherit and use descriptors from init. allow lvm_t init_t:fd use; # LVM is split into many individual binaries can_exec(lvm_t, lvm_exec_t) # Access disk devices. allow lvm_t fixed_disk_device_t:chr_file create_file_perms; # Access terminals. allow lvm_t { initrc_devpts_t admin_tty_type }:chr_file rw_file_perms; ifdef(`gnome-pty-helper.te', `allow lvm_t sysadm_gph_t:fd use;') allow lvm_t privfd:fd use; allow lvm_t devpts_t:dir { getattr read }; read_locale(lvm_t) # LVM (vgscan) scans for devices by stating every file in /dev and applying a regex... dontaudit lvm_t device_type:{ chr_file blk_file } getattr; dontaudit lvm_t device_t:{ fifo_file dir chr_file blk_file } getattr; dontaudit lvm_t devpts_t:dir getattr; ifdef(`gpm.te', ` dontaudit lvm_t gpmctl_t:sock_file getattr; ') dontaudit lvm_t initctl_t:fifo_file getattr; dontaudit lvm_t sbin_t:file getattr; allow lvm_t lvm_control_t:chr_file rw_file_perms; dontaudit lvm_t var_run_t:dir getattr; From russell at coker.com.au Tue Apr 20 15:56:18 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Apr 2004 01:56:18 +1000 Subject: .te file in RPMs In-Reply-To: <20040420152012.9F93931530@neuromancer.voxel.net> References: <20040420152012.9F93931530@neuromancer.voxel.net> Message-ID: <200404210156.18183.russell@coker.com.au> On Wed, 21 Apr 2004 02:20, "mike at flyn.org" wrote: > I would like to learn the proper way for a package to install an associated > te file, rebuild the SELinux policy and load the new policy. Could someone > point me in the proper direction? Is there something better than "make > reload" in the post-install script? Currently there is no proper method. Loading the policy in the post-install alone won't do it. Any policy that is significant will add new file types, and the package which contains the policy (*) will have files that need to be labeled with those types. This means that you would have to not only load the policy but label the files in the post-install script. This is ugly. (*) I am assuming that you often want to have the .te files in the same package as the programs which need them. For some programs there may be several programs that need the same policy (examples are xdm type programs, FTP servers, etc) and so it makes sense to have policy separate from the packages. For the case of packages such as Postfix or Apache there is only one program that can possibly work with the policy so having two packages (one for policy and another for the actual package) seems at best wasteful, and at worst increases the chance of bugs relating to mis-matches between versions with no good cause. I think that doing this in any convenient way will require a change to rpm. The policy will have to be loaded before any files are installed. -- 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 mike at flyn.org Tue Apr 20 17:03:11 2004 From: mike at flyn.org (mike at flyn.org) Date: Tue, 20 Apr 2004 12:03:11 -0500 Subject: .te file in RPMs Message-ID: <20040420160311.9FCB531530@neuromancer.voxel.net> >> I would like to learn the proper way for a package to install an associated >> te file, rebuild the SELinux policy and load the new policy. Could someone >> point me in the proper direction? Is there something better than "make >> reload" in the post-install script? > Currently there is no proper method. > > Loading the policy in the post-install alone won't do it. Any policy that > is significant will add new file types, and the package which contains the > policy (*) will have files that need to be labeled with those types. This > means that you would have to not only load the policy but label the files > in the post-install script. This is ugly. Does this mean that this is not a blocker for Fedora Core 2, as the entry in the SELinux roadmap at http://fedora.redhat.com/projects/selinux/ seems to imply ("Fedora Core 2 release may happen after item 9 or 10...")? -- Mike From n3npq at nc.rr.com Tue Apr 20 16:54:50 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 20 Apr 2004 12:54:50 -0400 Subject: .te file in RPMs In-Reply-To: <20040420160311.9FCB531530@neuromancer.voxel.net> References: <20040420160311.9FCB531530@neuromancer.voxel.net> Message-ID: <408555DA.7030702@nc.rr.com> mike at flyn.org wrote: >>>I would like to learn the proper way for a package to install an >>> >>> >associated > > >>>te file, rebuild the SELinux policy and load the new policy. Could >>> >>> >someone > > >>>point me in the proper direction? Is there something better than "make >>>reload" in the post-install script? >>> >>> > > > >>Currently there is no proper method. >> >>Loading the policy in the post-install alone won't do it. Any policy that >>is significant will add new file types, and the package which contains the >>policy (*) will have files that need to be labeled with those types. This >>means that you would have to not only load the policy but label the files >>in the post-install script. This is ugly. >> >> > >Does this mean that this is not a blocker for Fedora Core 2, as the entry in >the SELinux roadmap at http://fedora.redhat.com/projects/selinux/ seems to >imply ("Fedora Core 2 release may happen after item 9 or 10...")? > > The means to save *.te files exists in rpm-4.3 and later. In %files, adding %policy before a path will load the contents of the file into metadata. If the path is relative, then it's relative to the build directory, and the contents goes only into the header. If the path is absolute, then it's relative to $RPM_BUILD_ROOT, and the contents goes into both the header and the payload. Now, all that being said, the entire mechanism is gonna be scrapped and redone, for several reasons: 1) policy is now composed of both macros and *.te files (and *.fc, handled already), and has policy versions and booleans and probably other "stuff" in the works that needs to be accomodated. 2) policy is still changing too rapidly for it to make sense to burn into package headers that are about to be released as Fedora Core 2, which will persist long beyond the development cycle. So it's time to back up and redesign how policy should be packaged into rpm. So, "Not a blocker" afaik. 73 de Jeff From Valdis.Kletnieks at vt.edu Tue Apr 20 20:27:02 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Apr 2004 16:27:02 -0400 Subject: mkinitrd problems - 2 slightly different ones... In-Reply-To: Your message of "Wed, 21 Apr 2004 01:45:10 +1000." <200404210145.10921.russell@coker.com.au> References: <200404200250.i3K2oUt4004122@turing-police.cc.vt.edu> <200404210025.28060.russell@coker.com.au> <200404210145.10921.russell@coker.com.au> Message-ID: <200404202027.i3KKR2Np018422@turing-police.cc.vt.edu> On Wed, 21 Apr 2004 01:45:10 +1000, Russell Coker said: > It seems that my lvm patch was messed up, I didn't have the latest version. > I've attached a new lvm.te that is correct. Still needs some work: # cd / # /sbin/lvm lvcreate -n LogVol06 -L 2048M Volume00 /var/lock/lvm/V_Volume00: open failed: Permission denied Can't get lock for Volume00 # And these avc message: Apr 20 16:23:51 orange kernel: audit(1082492631.510:0): avc: denied { getattr } for pid=3575 exe=/sbin/lvm.static path=/var/lock/lvm dev=dm-5 ino=12289 scontext=root:system_r:lvm_t tcontext=system_u:object_r:lvm_lock_t tclass=dir Apr 20 16:23:51 orange kernel: audit(1082492631.511:0): avc: denied { read write search } for pid=3575 exe=/sbin/lvm.static name=lvm dev=dm-5 ino=12289 scontext=root:system_r:lvm_t tcontext=system_u:object_r:lvm_lock_t tclass=dir Apr 20 16:23:51 orange kernel: audit(1082492631.511:0): avc: denied { search } for pid=3575 exe=/sbin/lvm.static name=lvm dev=dm-5 ino=12289 scontext=root:system_r:lvm_t tcontext=system_u:object_r:lvm_lock_t tclass=dir Apr 20 16:23:51 orange kernel: audit(1082492631.513:0): avc: denied { getattr } for pid=3575 exe=/sbin/lvm.static name=/ dev=dm-5 ino=2 scontext=root:system_r:lvm_t tcontext=system_u:object_r:fs_t tclass=filesystem (Yes, breaking stuff like this is part of my job :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From kmacmillan at tresys.com Tue Apr 20 20:37:22 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Tue, 20 Apr 2004 16:37:22 -0400 Subject: .te file in RPMs In-Reply-To: <408555DA.7030702@nc.rr.com> Message-ID: <200404202036.i3KKasJx011796@gotham.columbia.tresys.com> First, I want to give a little background before I make some specific comments on this discussion. We (Tresys) are working on support for binary policy modules. We hope to create an infrastructure for the management of the system policy in a modular fashion. We envision this infrastructure could be used by other tools (like RPM) and will provide a consistent and safe mechanism to facilitate and control modification to the system policy. These modules will be a binary package that has a piece of the policy, information of the requirements of the module (i.e. which object class, types, roles, etc it references but doesn't declare), an optional labeling policy, and an optional copy of the policy source. The existing tools like checkpolicy and loadmodule will be modified to support this work. This discussion of how rpm will interact with policies is, I think, a good opportunity for us to discuss our current plans and get some feedback so that hopefully our work can be used by rpm. Also, this work is what #10 on the selinux todo for Fedora refers to. > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Jeff Johnson > > Now, all that being said, the entire mechanism is gonna be scrapped and > redone, for > several reasons: > 1) policy is now composed of both macros and *.te files (and *.fc, > handled already), and has policy versions > and booleans and probably other "stuff" in the works that needs > to be accomodated. I know that rpm can handle labeling of files that it installs, but I'm not certain that is complete support for labeling (maybe *.fc being handled means more this and I'm not aware of the additional support). It seems that providing a database of labeling decisions (e.g. a global file_contexts file) is necessary and helpful. So, for example, when an rpm is installed into /opt instead /usr the file_contexts file has entries for the files that rpm installed with the correct location. This is necessary, at least, for support a full 'make relabel' style relabeling of the filesystem. As for the other "stuff", this seems to boil down to rpm supporting the installation of multiple policies based on different criteria. This is useful for both versioning (for handling backward compatibility for booleans, etc) and for supporting policies with different goals in 1 rpm. For example, a single rpm might provide a very permissive policy for general use and a tightly locked down policy for more security sensitive installs. A global security setting might then control which type of policy gets installed. > 2) policy is still changing too rapidly for it to make sense to > burn into package headers that are about to be > released as Fedora Core 2, which will persist long beyond the > development cycle. > This problem seems more general to me. In some circumstances, policy may be orthogonal to what rpm provides and it seems like a good idea to think about some ways to support this. For example, I can envision the need to support policies that are distributed separately from rpms. A company might have a very strict security policy for its servers, including an SELinux policy, that they want to install on all of their servers. In this case, an rpm upgrade might modify the policy in an undesirable way. I don't have any good answers for this, but think it is important to think about the relationship between rpms (applications) and policy and how closely they should be coupled. Karl > So it's time to back up and redesign how policy should be packaged into > rpm. > > So, "Not a blocker" afaik. > > 73 de Jeff > Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From walters at redhat.com Tue Apr 20 21:42:52 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 20 Apr 2004 17:42:52 -0400 Subject: relabeling needed Message-ID: <1082497372.26211.3.camel@nexus.verbum.private> Hi, If you are running into AVC denials, remember to try relabeling first. There have been several renames and new types recently. For example: New file /root/.default_contexts needs to be labeled default_context_t /usr/X11R6/bin/XFree86 is now Xorg /var/spool/at now has type crond_spool_t And there's more. /home/$USER/.gconf may have a separate type shortly too. The other thing is to be sure you're grabbing the latest policy-sources RPM from rawhide. -------------- 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 efthym at gmx.net Tue Apr 20 21:50:56 2004 From: efthym at gmx.net (Efthym) Date: Tue, 20 Apr 2004 17:50:56 -0400 Subject: VMware + SELinux In-Reply-To: References: Message-ID: I saw the additions to file_contexts in policy 1.11.2-9 and thought I give it another try ;) With enforce=1, vmware-config.pl produces [root at Purgatory log]# vmware-config.pl Can't open perl script "/usr/bin/vmware-config.pl": Permission denied Apr 20 17:36:08 Purgatory kernel: audit(1082496968.198:0): avc: denied { read } for pid=4273 exe=/usr/bin/perl name=urandom dev=hda2 ino=596039 scontext=root:system_r:vmware_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Apr 20 17:36:08 Purgatory kernel: audit(1082496968.199:0): avc: denied { search } for pid=4273 exe=/usr/bin/perl name=bin dev=hda2 ino=1126081 scontext=root:system_r:vmware_t tcontext=system_u:object_r:bin_t tclass=dir With enforce=0, it vmware-config.pl works ok and also starts the VMservices alright. So this works ! (see attached file of /var/log/messages) (But ..) the problem again occurs if there is a change in the enforcing mode (either with a restart or setenforce=1). [root at Purgatory log]# service vmware stop Apr 20 17:44:15 Purgatory kernel: audit(1082497454.955:0): avc: denied { search } for pid=5411 comm=vmnet-netifup name=vmnet1 dev= ino=25998 scontext=root:system_r:vmware_t tcontext=system_u:object_r:sysfs_t tclass=dir Apr 20 17:44:16 Purgatory kernel: audit(1082497456.081:0): avc: denied { unlink } for pid=5136 exe=/usr/bin/vmnet-natd name=vmnat.5136 dev=hda2 ino=2105474 scontext=root:system_r:vmware_t tcontext=root:object_r:var_run_t tclass=sock_file [root at Purgatory log]# setenforce 1 [root at Purgatory log]# service vmware start Starting VMware services: Virtual machine monitor [ OK ] Virtual ethernet [ OK ] Bridged networking on /dev/vmnet0 [FAILED] Host-only networking on /dev/vmnet1 (background) [ OK ] Host-only networking on /dev/vmnet8 (background) [ OK ] NAT networking on /dev/vmnet8 [FAILED] Apr 20 17:45:46 Purgatory kernel: audit(1082497546.084:0): avc: granted { setenforce } for pid=5869 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security Apr 20 17:46:00 Purgatory kernel: vmmon: module license 'unspecified' taints kernel. Apr 20 17:46:01 Purgatory kernel: parport0: PC-style at 0x3bc (0x7bc) [PCSPP,TRISTATE] Apr 20 17:46:01 Purgatory kernel: parport0: irq 7 detected Apr 20 17:46:01 Purgatory kernel: vmnet: module license 'unspecified' taints kernel. Apr 20 17:46:01 Purgatory kernel: audit(1082497561.203:0): avc: denied { read write } for pid=5911 exe=/usr/bin/vmnet-bridge name=vmnet0 dev=hda2 ino=588039 scontext=root:system_r:vmware_t tcontext=root:object_r:device_t tclass=chr_file Apr 20 17:46:01 Purgatory kernel: audit(1082497561.454:0): avc: denied { read write } for pid=5933 exe=/usr/bin/vmnet-natd name=vmnet8 dev=hda2 ino=587693 scontext=root:system_r:vmware_t tcontext=root:object_r:device_t tclass=chr_file Apr 20 17:46:11 Purgatory kernel: audit(1082497571.268:0): avc: denied { read write } for pid=6190 exe=/usr/bin/vmnet-netifup name=vmnet1 dev=hda2 ino=587685 scontext=root:system_r:vmware_t tcontext=root:object_r:device_t tclass=chr_fileApr 20 17:46:11 Purgatory VMware[init]: /dev/vmnet1: Permission denied Apr 20 17:46:11 Purgatory kernel: audit(1082497571.354:0): avc: denied { read write } for pid=6191 exe=/usr/bin/vmnet-netifup name=vmnet8 dev=hda2 ino=587693 scontext=root:system_r:vmware_t tcontext=root:object_r:device_t tclass=chr_fileApr 20 17:46:11 Purgatory VMware[init]: /dev/vmnet8: Permission denied If I restart (with kernel parameter enforcing=1) [root at Purgatory log]# service vmware start VMware Workstation is installed, but it has not been (correctly) configured for the running kernel. To (re-)configure it, invoke the following command: /usr/bin/vmware-config.pl. And were back to square 1 ! Hope all this helps,it took a while to get all the messages off ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: vmware.log Type: application/octet-stream Size: 36963 bytes Desc: not available URL: From notting at redhat.com Tue Apr 20 22:12:37 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Apr 2004 18:12:37 -0400 Subject: Fedora Core 2 and SELinux Message-ID: <20040420221237.GD4090@nostromo.devel.redhat.com> Just clarifying what's been posted in a couple of other threads. SELinux *will* be included in Fedora Core 2 test 3 and the final Fedora Core 2 release. However, SELinux will be disabled by default. To install with SELinux support, pass 'selinux' to the installer on the command line. (Or, configure it appropriately in kickstart). This was done based on both internal and external testing and feedback of the current Fedora Core SELinux implementation and policy. At this point, we feel that it would be potentially damaging to the aims of both SELinux and Fedora to ship Fedora Core 2 with SELinux enabled by default. We're still committed to the integration of SELinux technology, and we're still working to fix all the bugs we find. Evaluation of when the right time isto switch it on by default will continue. What does this mean for those testing with SELinux? Please, continue! We're still looking to shake out all the issues and make it work. Thanks, The Fedora team From goddard at audiolab.com.br Tue Apr 20 17:02:32 2004 From: goddard at audiolab.com.br (=?iso-8859-1?q?Andr=E9=20Goddard=20Rosa?=) Date: Tue, 20 Apr 2004 14:02:32 -0300 Subject: SELinux impact on performance Message-ID: <200404201402.32416.goddard@audiolab.com.br> Even with SELinux turned off it still has losing of performance? Thanks, Andre From CRidgeway at maximsys.com Tue Apr 20 21:51:30 2004 From: CRidgeway at maximsys.com (Christine Ridgeway) Date: Tue, 20 Apr 2004 14:51:30 -0700 Subject: NSA accreditation Message-ID: <3712661E4EEC004FACDC660D64B9D40BEBAC67@mail.maximsys.com> Hi: I was wondering if there are any C&A documents that we could review in regards to SELinux and Fedora. If so, could you please point me in the right direction or forward them to me at this address? Thank you very much in advance! V/R, Christine Ridgeway Maxim Systems, Inc. Tel: 619-574-2275 Fax: 619-692-3597 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorris at redhat.com Tue Apr 20 22:58:15 2004 From: jmorris at redhat.com (James Morris) Date: Tue, 20 Apr 2004 18:58:15 -0400 (EDT) Subject: SELinux impact on performance In-Reply-To: <200404201402.32416.goddard@audiolab.com.br> Message-ID: On Tue, 20 Apr 2004, Andr? Goddard Rosa wrote: > Even with SELinux turned off it still has losing of performance? Using selinux=0, performance will not be affected. - James -- James Morris From mattdm at mattdm.org Tue Apr 20 23:42:36 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Apr 2004 19:42:36 -0400 Subject: Fedora Core 2 and SELinux In-Reply-To: <20040420221237.GD4090@nostromo.devel.redhat.com> References: <20040420221237.GD4090@nostromo.devel.redhat.com> Message-ID: <20040420234236.GA26191@jadzia.bu.edu> On Tue, Apr 20, 2004 at 06:12:37PM -0400, Bill Nottingham wrote: > SELinux *will* be included in Fedora Core 2 test 3 and the final > Fedora Core 2 release. However, SELinux will be disabled by default. > To install with SELinux support, pass 'selinux' to the installer > on the command line. (Or, configure it appropriately in kickstart). Disabled, like the current "disabled" in anaconda, or disabled like "selinux=0"? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwboyer at charter.net Wed Apr 21 02:02:27 2004 From: jwboyer at charter.net (Josh Boyer) Date: Tue, 20 Apr 2004 21:02:27 -0500 Subject: gpg avc Message-ID: <1082512947.2332.2.camel@localhost.localdomain> Trying to generate a new gpg key fails with the latest policy updates. Below is the avc: audit(1082512578.827:0): avc: denied { read } for pid=2543 exe=/usr/bin/gpg name=random dev=hda5 ino=267501 scontext=user_u:user_r:user_gpg_t tcontext=system_u:object_r:random_device_t tclass=chr_file [jwboyer at localhost jwboyer]$ rpm -q policy policy-1.11.2-9 Any tips? thx, josh From walters at redhat.com Wed Apr 21 02:36:41 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 20 Apr 2004 22:36:41 -0400 Subject: gpg avc In-Reply-To: <1082512947.2332.2.camel@localhost.localdomain> References: <1082512947.2332.2.camel@localhost.localdomain> Message-ID: <1082515001.3180.0.camel@nexus.verbum.private> On Tue, 2004-04-20 at 22:02, Josh Boyer wrote: > Trying to generate a new gpg key fails with the latest policy updates. > Below is the avc: > > audit(1082512578.827:0): avc: denied { read } for pid=2543 > exe=/usr/bin/gpg name=random dev=hda5 ino=267501 > scontext=user_u:user_r:user_gpg_t > tcontext=system_u:object_r:random_device_t tclass=chr_file > > [jwboyer at localhost jwboyer]$ rpm -q policy > policy-1.11.2-9 Try this patch, will be in the next policy. -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg.patch Type: text/x-patch Size: 456 bytes Desc: not available URL: -------------- 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 Apr 21 02:49:14 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 20 Apr 2004 22:49:14 -0400 Subject: gpg avc In-Reply-To: <1082515001.3180.0.camel@nexus.verbum.private> References: <1082512947.2332.2.camel@localhost.localdomain> <1082515001.3180.0.camel@nexus.verbum.private> Message-ID: <1082515753.3180.6.camel@nexus.verbum.private> On Tue, 2004-04-20 at 22:36, Colin Walters wrote: > On Tue, 2004-04-20 at 22:02, Josh Boyer wrote: > > Trying to generate a new gpg key fails with the latest policy updates. > > Below is the avc: > > > > audit(1082512578.827:0): avc: denied { read } for pid=2543 > > exe=/usr/bin/gpg name=random dev=hda5 ino=267501 > > scontext=user_u:user_r:user_gpg_t > > tcontext=system_u:object_r:random_device_t tclass=chr_file > > > > [jwboyer at localhost jwboyer]$ rpm -q policy > > policy-1.11.2-9 > > Try this patch, will be in the next policy. I presume by the way there's a reason access to random_device_t is was originally denied - it prevents users from draining your good entropy by generating a ton of keys. On the other hand, if you have GPG installed on a system, I think most system administrators are going to expect users to be able to generate keys securely. Maybe the right way is a resource constraint framework. Anyways, do people think this is worth being made into a tunable or something? -------------- 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 katzj at redhat.com Wed Apr 21 02:25:04 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Apr 2004 22:25:04 -0400 Subject: Fedora Core 2 and SELinux In-Reply-To: <20040420234236.GA26191@jadzia.bu.edu> References: <20040420221237.GD4090@nostromo.devel.redhat.com> <20040420234236.GA26191@jadzia.bu.edu> Message-ID: <1082514303.22892.765.camel@rivendell.local.net> On Tue, 2004-04-20 at 19:42, Matthew Miller wrote: > On Tue, Apr 20, 2004 at 06:12:37PM -0400, Bill Nottingham wrote: > > SELinux *will* be included in Fedora Core 2 test 3 and the final > > Fedora Core 2 release. However, SELinux will be disabled by default. > > To install with SELinux support, pass 'selinux' to the installer > > on the command line. (Or, configure it appropriately in kickstart). > > Disabled, like the current "disabled" in anaconda, or disabled like > "selinux=0"? Disabled like the current "disabled" in anaconda right now. Hopefully Stephen Smalley's patch to allow completely deregistering SELinux hooks from before policy gets loaded won't get torn apart too badly on lkml; then we'll do that as well. Jeremy From udo.christ at tw-systems.com Wed Apr 21 07:28:14 2004 From: udo.christ at tw-systems.com (Udo Christ) Date: Wed, 21 Apr 2004 09:28:14 +0200 Subject: SELinux denies setrlimit during user login Message-ID: <1082532494.6920.2.camel@empire.hq.tw-systems.com> Hello, the current policies still seem to deny the setting of limits during user login (local and remote, but not during gdm-login). The settings get established using the pam module and its configuration. (Raising file limits and such) Right now i have to run in permissive mode in order to be able to log in as root and users. Could someone change the policies accordingly or tell me what to try to be able to log on in enforcing mode ? Regards, Udo -------------- 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 gene at czarc.net Wed Apr 21 08:40:04 2004 From: gene at czarc.net (Gene Czarcinski) Date: Wed, 21 Apr 2004 04:40:04 -0400 Subject: Fedora Core 2 and SELinux In-Reply-To: <1082514303.22892.765.camel@rivendell.local.net> References: <20040420221237.GD4090@nostromo.devel.redhat.com> <20040420234236.GA26191@jadzia.bu.edu> <1082514303.22892.765.camel@rivendell.local.net> Message-ID: <200404210440.04073.gene@czarc.net> On Tuesday 20 April 2004 22:25, Jeremy Katz wrote: > On Tue, 2004-04-20 at 19:42, Matthew Miller wrote: > > On Tue, Apr 20, 2004 at 06:12:37PM -0400, Bill Nottingham wrote: > > > SELinux *will* be included in Fedora Core 2 test 3 and the final > > > Fedora Core 2 release. However, SELinux will be disabled by default. > > > To install with SELinux support, pass 'selinux' to the installer > > > on the command line. (Or, configure it appropriately in kickstart). > > > > Disabled, like the current "disabled" in anaconda, or disabled like > > "selinux=0"? > > Disabled like the current "disabled" in anaconda right now. Hopefully > Stephen Smalley's patch to allow completely deregistering SELinux hooks > from before policy gets loaded won't get torn apart too badly on lkml; > then we'll do that as well. I am unclear on this (anaconda disabled versus selinux=0). Can someone explain? Gene From russell at coker.com.au Wed Apr 21 08:40:24 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Apr 2004 18:40:24 +1000 Subject: gpg avc In-Reply-To: <1082515753.3180.6.camel@nexus.verbum.private> References: <1082512947.2332.2.camel@localhost.localdomain> <1082515001.3180.0.camel@nexus.verbum.private> <1082515753.3180.6.camel@nexus.verbum.private> Message-ID: <200404211840.24508.russell@coker.com.au> On Wed, 21 Apr 2004 12:49, Colin Walters wrote: > I presume by the way there's a reason access to random_device_t is was > originally denied - it prevents users from draining your good entropy by > generating a ton of keys. On the other hand, if you have GPG installed Actually when I gave different types to /dev/random and /dev/urandom we just sorted out which access each program seemed to need. At the time GPG didn't seem to want /dev/random access. If it wants it then it should get it. > Maybe the right way is a resource constraint framework. Anyways, do > people think this is worth being made into a tunable or something? I think that a resource constraint framework for entropy would be useful. However there are other ways of attacking the problem. It seems that every desktop, laptop, and PDA shipped in the last few years has sound hardware. The microphone that's built in to many machines can be used as a source of entropy, and even an unconnected line-in if sampled at 16bit will do reasonably well. There is already policy for /usr/sbin/audio-entropyd to use this, if we get this packaged then maybe it would be the best solution to the problem? -- 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 dennis at ausil.us Wed Apr 21 10:59:44 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 21 Apr 2004 20:59:44 +1000 Subject: Long XFS filesystem avc errors on boot In-Reply-To: <200404151916.25386.russell@coker.com.au> References: <200404151833.56251.dennis@ausil.us> <200404151916.25386.russell@coker.com.au> Message-ID: <200404212059.50106.dennis@ausil.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Once upon a time Thursday 15 April 2004 7:16 pm, Russell Coker wrote: > On Thu, 15 Apr 2004 18:33, Dennis Gilmore wrote: > > Apr 15 11:26:06 asgard kernel: audit(1081992347.449:0): avc: denied > > { getattr } for pid=774 exe=/sbin/pam_console_apply path=/dev/input/js2 > > dev=hde2 ino=234962788 scontext=system_u:system_r:pam_console_t > > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > > /dev/input/js* should have the type mouse_device_t. Please do a "ls -Z" on > them and tell me what it says. NB It is not going to say unlabeled_t, it > will say whatever is on disk, the kernel uses unlabeled_t if what's on disk > makes no sense with the currently loaded policy. > system_u:object_r:mouse_device_t > > Apr 15 11:26:06 asgard kernel: audit(1081992347.464:0): avc: denied > > { dac_override } for pid=774 exe=/sbin/pam_console_apply capability=1 > > scontext=system_u:system_r:pam_console_t > > tcontext=system_u:system_r:pam_console_t tclass=capability > > What is it trying to do here? that im not sure of there is lots of them logged but they dont seem to be affecting things too much just thought i would bring it up > > Apr 15 11:26:06 asgard kernel: inode_doinit_with_dentry: getxattr > > returned 13 for dev=hde2 ino=234962799 > > 13 == EACCES? That can't be right. Steve, what do you think about this? > > > Apr 15 11:27:19 asgard /sbin/mingetty[1796]: tty1: Operation not > > permitted Apr 15 11:27:19 asgard /sbin/mingetty[1797]: tty2: Operation > > not permitted Apr 15 11:27:19 asgard /sbin/mingetty[1798]: tty3: > > Operation not permitted Apr 15 11:27:19 asgard kernel: > > audit(1081992439.217:0): avc: denied { fowner } for pid=1796 > > exe=/sbin/mingetty capability=3 > > scontext=system_u:system_r:getty_t tcontext=system_u:system_r:getty_t > > tclass=capability > > Interesting. Who owns your tty devices? root:root > Granting this capability should not cause a problem so please test allowing > this and see if it does some good. We don't want to grant capabilities > wildly, but this will be OK if there are cases that need it. > > > Apr 15 11:27:19 asgard kernel: audit(1081992439.921:0): avc: denied > > { getattr } for pid=1818 exe=/usr/X11R6/bin/Xorg > > path=/var/log/Xorg.0.log dev=hde2 ino=302135865 > > scontext=system_u:system_r:xdm_t > > tcontext=system_u:object_r:var_log_t tclass=file > > Put the following in file_contexts/program/xserver.fc > /var/log/XOrg.* -- system_u:object_r:xserver_log_t > > I have attached a suitable xserver.fc file. > > Then you have to relabel /var/log after rebuilding the file_contexts file. > > Regarding the long message, all the messages after 11:27:19 appeared to be > repeats. The X server and getty will continue restarting forever so will > produce an unlimited amount of messages if they can't startup correctly. Sorry i should have picked up the repeats and sorry it took me so long to get back i had a hdd failure in my server. With latest updates all seems ok except when i log in x dies and restarts so i efectivly cant log in i treid starting at run level 3 and x would start but hang Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAhlQmkSxm47BaWfcRAtXNAJ4kPPoegHGsxryF/3M93JkHXrmphQCgi1gI dJUnl1YZW4FCntUzkyfFBIs= =kDiD -----END PGP SIGNATURE----- From sds at epoch.ncsc.mil Wed Apr 21 12:33:30 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 21 Apr 2004 08:33:30 -0400 Subject: Fedora Core 2 and SELinux In-Reply-To: <200404210440.04073.gene@czarc.net> References: <20040420221237.GD4090@nostromo.devel.redhat.com> <20040420234236.GA26191@jadzia.bu.edu> <1082514303.22892.765.camel@rivendell.local.net> <200404210440.04073.gene@czarc.net> Message-ID: <1082550810.9213.19.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-21 at 04:40, Gene Czarcinski wrote: > On Tuesday 20 April 2004 22:25, Jeremy Katz wrote: > > Disabled like the current "disabled" in anaconda right now. Hopefully > > Stephen Smalley's patch to allow completely deregistering SELinux hooks > > from before policy gets loaded won't get torn apart too badly on lkml; > > then we'll do that as well. > > I am unclear on this (anaconda disabled versus selinux=0). Can someone > explain? The selinux=0 boot parameter is handled by the kernel and causes SELinux to immediately abort initialization, so that it never registers as a security module with the kernel, never registers its NetFilter hooks, and never registers the selinuxfs pseudo filesystem (no-selinux for short). The boot parameter was introduced by RH to support shipping a single kernel with SELinux included while still allowing for disabling of SELinux. But Jeremy later informed us that kernel boot parameters are difficult to employ on certain platforms, so RH looked for another approach that would be more portable across all platforms. The /etc/sysconfig/selinux disabled setting is handled by /sbin/init and occurs after SELinux has already performed basic initialization (but before policy load), and merely causes SELinux to proceed under permissive mode with no policy loaded (permissive/no-policy for short). permissive/no-policy looks very similar to no-selinux in behavior, but isn't quite identical and still imposes processing overhead on kernel operations. To address this problem, we have developed and submitted a kernel patch for the SELinux module that adds a runtime disable that can be invoked prior to the initial policy load, so that /sbin/init will be able to truly disable SELinux, unregistering its security hooks, NetFilter hooks, and the selinuxfs filesystem. The patches were posted to lkml and the NSA selinux mailing list, and are now in 2.6.6-rc2-mm1 and have been submitted to Linus (but are not yet in bk). Once a kernel is released with this support, /sbin/init can be updated to use it. -- Stephen Smalley National Security Agency From walters at redhat.com Wed Apr 21 13:29:47 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 21 Apr 2004 09:29:47 -0400 Subject: gpg avc In-Reply-To: <200404211840.24508.russell@coker.com.au> References: <1082512947.2332.2.camel@localhost.localdomain> <1082515001.3180.0.camel@nexus.verbum.private> <1082515753.3180.6.camel@nexus.verbum.private> <200404211840.24508.russell@coker.com.au> Message-ID: <1082554186.20679.7.camel@nexus.verbum.private> On Wed, 2004-04-21 at 04:40, Russell Coker wrote: > On Wed, 21 Apr 2004 12:49, Colin Walters wrote: > > I presume by the way there's a reason access to random_device_t is was > > originally denied - it prevents users from draining your good entropy by > > generating a ton of keys. On the other hand, if you have GPG installed > > Actually when I gave different types to /dev/random and /dev/urandom we just > sorted out which access each program seemed to need. At the time GPG didn't > seem to want /dev/random access. If it wants it then it should get it. I think it only uses /dev/random when generating keys. > It seems that every desktop, laptop, and PDA shipped in the last few years has > sound hardware. The microphone that's built in to many machines can be used > as a source of entropy, and even an unconnected line-in if sampled at 16bit > will do reasonably well. There is already policy > for /usr/sbin/audio-entropyd to use this, if we get this packaged then maybe > it would be the best solution to the problem? That does sound like a cool idea. You can really get data even if there's no microphone connected? -------------- 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 Wed Apr 21 14:40:21 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 21 Apr 2004 10:40:21 -0400 Subject: gpg avc In-Reply-To: Your message of "Wed, 21 Apr 2004 09:29:47 EDT." <1082554186.20679.7.camel@nexus.verbum.private> References: <1082512947.2332.2.camel@localhost.localdomain> <1082515001.3180.0.camel@nexus.verbum.private> <1082515753.3180.6.camel@nexus.verbum.private> <200404211840.24508.russell@coker.com.au> <1082554186.20679.7.camel@nexus.verbum.private> Message-ID: <200404211440.i3LEeLkn016813@turing-police.cc.vt.edu> On Wed, 21 Apr 2004 09:29:47 EDT, Colin Walters said: > That does sound like a cool idea. You can really get data even if > there's no microphone connected? I think the basic concept there is that even without a microphone, as you sample, most cards won't return a steady stream of exact zeros - you'll get back the tiniest bit of background hiss, and the low-order bits have entropy. Of course, doing this without filtering is a Bad Idea - the amount of entropy coming off the always-on cheap sound card in my laptop that has maybe 70db S/N is probably a lot higher than somebody who has a high-end card that has 85db S/N - and if their card supports auto-muting for unused inputs, you're basically screwed... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From shahms at shahms.com Wed Apr 21 18:00:02 2004 From: shahms at shahms.com (Shahms King) Date: Wed, 21 Apr 2004 11:00:02 -0700 Subject: .te files in packages Message-ID: <1082570402.12920.73.camel@shahms.mesd.k12.or.us> (I just subscribed, so I'm replying from the list archive...) Given that FC2 is no longer shipping with SELinux enabled by default, it makes sense to have a separate policy package for individual packages, IMHO. The policy package would depend on policy-sources and the parent package and could easily do: %post cd /etc/security/selinux/src/polixy make load PACKAGELIST="parent-package parent-package-devel" for PACKAGE in $PACKAGELIST; do if /bin/rpm -q $PACKAGE > /dev/null 2>&1; then /bin/rpm -ql $PACKAGE | /usr/sbin/setfiles -s \ /etc/security/selinux/file_contexts fi done ================================================================ Of course all of this would be greatly enhanced by an rpm macro that handled adding all other packages built from the same spec file as the policy package. Heck, the macro could have options to exclude packages or include separately compiled packages in the list. -- Shahms King From walters at redhat.com Wed Apr 21 19:02:28 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 21 Apr 2004 15:02:28 -0400 Subject: newrole using SELinux user identity for password lookups Message-ID: <1082574148.2438.68.camel@nexus.verbum.private> So on a default Fedora installation, as a regular user trying to run newrole -r sysadm_r, I get this: testuser at optimus-prime:~$ newrole -r sysadm_r cannot find your entry in the passwd file. Now, in newrole.c:364, there is the code: if( !(pw=getpwnam(context_user_get(context))) ) { fprintf(stderr,_("cannot find your entry in the passwd file.\n")); exit(-1); } context_user_get just returns the user identity portion of the security context of current process. Since I have no special user identity defined, it defaults to user_u, which is obviously not in the passwd file. This conflicts with our current default Fedora policy, we have in the SELinux users file: user user_u roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r system_r') }; The user_canbe_sysadm tunable is on by default, but the user can't use newrole to get to that role - only su. So how to fix this bug? I understand the reason we're using the SELinux user identity - SELinux doesn't want to trust the Linux uid. But perhaps it would be good if we had a way to say that for particular SELinux user identities like user_u, newrole could just use the Linux uid for authentication. -------------- 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 sds at epoch.ncsc.mil Wed Apr 21 19:21:26 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 21 Apr 2004 15:21:26 -0400 Subject: newrole using SELinux user identity for password lookups In-Reply-To: <1082574148.2438.68.camel@nexus.verbum.private> References: <1082574148.2438.68.camel@nexus.verbum.private> Message-ID: <1082575285.9213.89.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-21 at 15:02, Colin Walters wrote: > The user_canbe_sysadm tunable is on by default, but the user can't use > newrole to get to that role - only su. > > So how to fix this bug? I understand the reason we're using the SELinux > user identity - SELinux doesn't want to trust the Linux uid. But > perhaps it would be good if we had a way to say that for particular > SELinux user identities like user_u, newrole could just use the Linux > uid for authentication. The only purpose of the newrole re-authentication is to force a user interaction to verify user intent prior to a role change, as opposed to some malicious code that happens to be run by the user being able to change roles without the user's awareness. The policy governs who can enter the role, not the newrole program. Anything could be substituted for the re-authentication, as long as it provides some confidence of user confirmation and is not easily spoofed by malicious code. Long term, the right solution is to use a trusted path mechanism once one becomes available in Linux. -- Stephen Smalley National Security Agency From walters at redhat.com Wed Apr 21 19:33:12 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 21 Apr 2004 15:33:12 -0400 Subject: newrole using SELinux user identity for password lookups In-Reply-To: <1082575285.9213.89.camel@moss-spartans.epoch.ncsc.mil> References: <1082574148.2438.68.camel@nexus.verbum.private> <1082575285.9213.89.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1082575992.4826.9.camel@nexus.verbum.private> On Wed, 2004-04-21 at 15:21, Stephen Smalley wrote: > The only purpose of the newrole re-authentication is to force a user > interaction to verify user intent prior to a role change, as opposed to > some malicious code that happens to be run by the user being able to > change roles without the user's awareness. The policy governs who can > enter the role, not the newrole program. Anything could be substituted > for the re-authentication, as long as it provides some confidence of > user confirmation and is not easily spoofed by malicious code. Ok, that all makes sense. Why not then just use getpwuid(getuid()) instead of getpwnam? Hm, although I see one reason - on a SELinux system where "su" is not modified, and a normal user with their own SELinux user identity uses "su" to become uid 0, then uses newrole, they'd be prompted for the root password instead of their password. However for Fedora where we've modified "su", this is not an issue. > Long term, the right solution is to use a trusted path mechanism once one > becomes available in Linux. Yeah. It seems there is some work in this area going on: http://shellcode.org/Kernel/tpe/ -------------- 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 sds at epoch.ncsc.mil Wed Apr 21 19:40:37 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 21 Apr 2004 15:40:37 -0400 Subject: newrole using SELinux user identity for password lookups In-Reply-To: <1082575992.4826.9.camel@nexus.verbum.private> References: <1082574148.2438.68.camel@nexus.verbum.private> <1082575285.9213.89.camel@moss-spartans.epoch.ncsc.mil> <1082575992.4826.9.camel@nexus.verbum.private> Message-ID: <1082576437.9213.97.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-21 at 15:33, Colin Walters wrote: > Ok, that all makes sense. Why not then just use getpwuid(getuid()) > instead of getpwnam? > > Hm, although I see one reason - on a SELinux system where "su" is not > modified, and a normal user with their own SELinux user identity uses > "su" to become uid 0, then uses newrole, they'd be prompted for the root > password instead of their password. > > However for Fedora where we've modified "su", this is not an issue. I'd rather move away from asking for a password at all in newrole, and substitute some other user confirmation mechanism (one that doesn't risk exposure of a secret). > Yeah. It seems there is some work in this area going on: > http://shellcode.org/Kernel/tpe/ TPE is _not_ related to the classical notion of trusted path at all. Type Enforcement is a better mechanism for providing the equivalent functionality of TPE. Trusted path is described in the latter part of http://www.nsa.gov/selinux/papers/inevitability/#2 , among other places. -- Stephen Smalley National Security Agency From walters at redhat.com Wed Apr 21 19:48:16 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 21 Apr 2004 15:48:16 -0400 Subject: newrole using SELinux user identity for password lookups In-Reply-To: <1082576437.9213.97.camel@moss-spartans.epoch.ncsc.mil> References: <1082574148.2438.68.camel@nexus.verbum.private> <1082575285.9213.89.camel@moss-spartans.epoch.ncsc.mil> <1082575992.4826.9.camel@nexus.verbum.private> <1082576437.9213.97.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1082576896.4826.34.camel@nexus.verbum.private> On Wed, 2004-04-21 at 15:40, Stephen Smalley wrote: > I'd rather move away from asking for a password at all in newrole, and > substitute some other user confirmation mechanism (one that doesn't risk > exposure of a secret). Ok. Well do you (or anyone else, Dan?) have any suggestions for the short term? For FC2 we could just tell users to always use 'su'. The unfortunate thing here is that Fedora users who are reading upstream docs will get exactly the opposite information :/ > > Yeah. It seems there is some work in this area going on: > > http://shellcode.org/Kernel/tpe/ > > TPE is _not_ related to the classical notion of trusted path at all. > Type Enforcement is a better mechanism for providing the equivalent > functionality of TPE. Trusted path is described in the latter part of > http://www.nsa.gov/selinux/papers/inevitability/#2 , among other places. I'd just briefly glanced at the TPE page. Looking at it more carefully I think you're right. -------------- 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 sds at epoch.ncsc.mil Wed Apr 21 19:56:52 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 21 Apr 2004 15:56:52 -0400 Subject: newrole using SELinux user identity for password lookups In-Reply-To: <1082576896.4826.34.camel@nexus.verbum.private> References: <1082574148.2438.68.camel@nexus.verbum.private> <1082575285.9213.89.camel@moss-spartans.epoch.ncsc.mil> <1082575992.4826.9.camel@nexus.verbum.private> <1082576437.9213.97.camel@moss-spartans.epoch.ncsc.mil> <1082576896.4826.34.camel@nexus.verbum.private> Message-ID: <1082577412.9213.111.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-21 at 15:48, Colin Walters wrote: > Ok. Well do you (or anyone else, Dan?) have any suggestions for the > short term? For FC2 we could just tell users to always use 'su'. The > unfortunate thing here is that Fedora users who are reading upstream > docs will get exactly the opposite information :/ In the short term, if you want to have it fall back to the Linux uid for authentication purposes if the SELinux user identity is SELINUX_DEFAULTUSER (defined in include/selinux/get_context_list.h), then that is fine. Just don't use the Linux uid as the user identity for the new context. -- Stephen Smalley National Security Agency From walters at redhat.com Wed Apr 21 20:15:04 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 21 Apr 2004 16:15:04 -0400 Subject: newrole using SELinux user identity for password lookups In-Reply-To: <1082577412.9213.111.camel@moss-spartans.epoch.ncsc.mil> References: <1082574148.2438.68.camel@nexus.verbum.private> <1082575285.9213.89.camel@moss-spartans.epoch.ncsc.mil> <1082575992.4826.9.camel@nexus.verbum.private> <1082576437.9213.97.camel@moss-spartans.epoch.ncsc.mil> <1082576896.4826.34.camel@nexus.verbum.private> <1082577412.9213.111.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1082578504.4826.76.camel@nexus.verbum.private> On Wed, 2004-04-21 at 15:56, Stephen Smalley wrote: > In the short term, if you want to have it fall back to the Linux uid for > authentication purposes if the SELinux user identity is > SELINUX_DEFAULTUSER (defined in include/selinux/get_context_list.h), > then that is fine. Just don't use the Linux uid as the user identity > for the new context. Ah, I didn't know about SELINUX_DEFAULTUSER. Cool. Patch attached then. Tested in both the explicit user identity and default cases. -------------- next part -------------- A non-text attachment was scrubbed... Name: policycoreutils-1.10-getuid-fallback.patch Type: text/x-patch Size: 1598 bytes Desc: not available URL: -------------- 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 thomas.bleher at jmh.mhn.de Wed Apr 21 22:57:42 2004 From: thomas.bleher at jmh.mhn.de (Thomas Bleher) Date: Thu, 22 Apr 2004 00:57:42 +0200 Subject: SELinux issues In-Reply-To: <1082402757.12261.22.camel@nexus.verbum.private> References: <1082402757.12261.22.camel@nexus.verbum.private> Message-ID: <20040421225742.GB2255@jmh.mhn.de> * Colin Walters [2004-04-19 21:26]: > On Mon, 2004-04-19 at 14:21, jacob wrote: > > * fam & nautilus are the ones spewing out the most avc messages in > > dmesg. > > fam is known to be incompatible with SELinux. I'm working on a patch to > disable it if SELinux is enabled. What nautilus AVC messages are you > seeing? the /initrd one is a known issue, also on my queue of stuff to > fix. Not sure what you mean by "incompatible". Writing policy for fam is not difficult, in fact I have written some policy for fam some time ago (diff against CVS attached). It is however impossible to prevent some information leakage when using fam. The attached policy is very liberal regarding this, allowing any userdomain to monitor any file. For a more secure setup fam should only be able to monitor user_home_t and user_tmp_t. A full solution requires modifications to fam: it should check the security context of the caller (like it does already with uid and gid) and only monitor the files if they can be accessed by the caller. Thomas -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7 Disclaimer: The quote was selected randomly. Really. -------------- next part -------------- --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ policy/domains/program/unused/famd.te 2004-04-21 23:43:24.000000000 +0200 @@ -0,0 +1,27 @@ +# DESC famd - File Alteration Monitor (FAM) daemon +# +# Author: Thomas Bleher + +rpc_domain(famd) +allow famd_t self:unix_stream_socket create_stream_socket_perms; +allow famd_t self:unix_dgram_socket { connect create write }; +allow famd_t self:fifo_file { read write }; +allow famd_t port_t:{ tcp_socket udp_socket } name_bind; + +# why does it need this? +allow famd_t self:capability { chown setgid setuid }; + +tmp_domain(famd) +# read /etc/mtab +allow famd_t etc_runtime_t:file read; + +# monitor all files +allow famd_t { file_type - shadow_t }:dir { search getattr read }; +allow famd_t { file_type - shadow_t }:{ lnk_file file } getattr; +allow famd_t { file_type - shadow_t }:lnk_file read; +dontaudit famd_t { sysfs_t security_t domain proc_t }:dir { search getattr read }; +dontaudit famd_t { self proc_t }:{ file lnk_file } getattr; + +allow userdomain famd_tmp_t:sock_file write; +allow userdomain famd_t:unix_stream_socket connectto; + --- policy/domains/program/unused/rpcd.te 2004-04-21 23:43:13.000000000 +0200 +++ policy/domains/program/unused/rpcd.te 2004-04-21 23:43:24.000000000 +0200 @@ -12,15 +12,2 @@ # -define(`rpc_domain', ` -daemon_base_domain($1) -can_network($1_t) -allow $1_t etc_t:file { getattr read }; -read_locale($1_t) -allow $1_t self:capability net_bind_service; - -allow $1_t var_t:dir { getattr search }; -allow $1_t var_lib_t:dir { search }; -allow $1_t var_lib_nfs_t:dir create_dir_perms; -allow $1_t var_lib_nfs_t:file create_file_perms; -') - # rpcd_t is the domain of rpc daemons. --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ policy/file_contexts/program/famd.fc 2004-04-21 23:43:24.000000000 +0200 @@ -0,0 +1,2 @@ +# famd +/usr/sbin/famd -- system_u:object_r:famd_exec_t --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ policy/macros/program/rpcd_macros.te 2004-04-21 23:43:24.000000000 +0200 @@ -0,0 +1,19 @@ +# Macros for RPCD-domains +# +# Authors: Stephen Smalley and Timothy Fraser +# Russell Coker +# + +define(`rpc_domain', ` +daemon_base_domain($1) +can_network($1_t) +allow $1_t etc_t:file { getattr read }; +read_locale($1_t) +allow $1_t self:capability net_bind_service; + +allow $1_t var_t:dir { getattr search }; +allow $1_t var_lib_t:dir { search }; +allow $1_t var_lib_nfs_t:dir create_dir_perms; +allow $1_t var_lib_nfs_t:file create_file_perms; +') + -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dax at gurulabs.com Wed Apr 21 23:31:36 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 21 Apr 2004 17:31:36 -0600 Subject: Fedora Core 2 and SELinux In-Reply-To: <1082550810.9213.19.camel@moss-spartans.epoch.ncsc.mil> References: <20040420221237.GD4090@nostromo.devel.redhat.com> <20040420234236.GA26191@jadzia.bu.edu> <1082514303.22892.765.camel@rivendell.local.net> <200404210440.04073.gene@czarc.net> <1082550810.9213.19.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1082590296.2839.126.camel@mentor.gurulabs.com> On Wed, 2004-04-21 at 06:33, Stephen Smalley wrote: > To address this problem, we have developed and submitted a kernel patch > for the SELinux module that adds a runtime disable that can be invoked > prior to the initial policy load, so that /sbin/init will be able to > truly disable SELinux, unregistering its security hooks, NetFilter > hooks, and the selinuxfs filesystem. The patches were posted to lkml > and the NSA selinux mailing list, and are now in 2.6.6-rc2-mm1 and have > been submitted to Linus (but are not yet in bk). Once a kernel is > released with this support, /sbin/init can be updated to use it. Nine hours ago Linus accepted that patch into his tree. From walters at redhat.com Wed Apr 21 23:34:52 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 21 Apr 2004 19:34:52 -0400 Subject: SELinux issues In-Reply-To: <20040421225742.GB2255@jmh.mhn.de> References: <1082402757.12261.22.camel@nexus.verbum.private> <20040421225742.GB2255@jmh.mhn.de> Message-ID: <1082590492.6554.16.camel@nexus.verbum.private> On Wed, 2004-04-21 at 18:57, Thomas Bleher wrote: > Not sure what you mean by "incompatible". Writing policy for fam is not > difficult, in fact I have written some policy for fam some time ago > (diff against CVS attached). It is however impossible to prevent some > information leakage when using fam. The attached policy is very liberal > regarding this, allowing any userdomain to monitor any file. For a more > secure setup fam should only be able to monitor user_home_t and > user_tmp_t. Well, that's not the only thing that it's desirable to monitor. For example, the GNOME theme manager monitors the theme installation directory, so if you install a new theme, it automatically shows up in the theme list. Similarly with the menu system. > A full solution requires modifications to fam: it should check the > security context of the caller (like it does already with uid and gid) > and only monitor the files if they can be accessed by the caller. Right - I think someone here looked at doing that and just gave up. We have someone working on writing a new file monitoring system, hopefully something will happen there soon. Anyways, I think it makes some sense to include your FAM policy as a temporary solution for people who run SELinux and also want the file monitoring. But I will leave that decision up to Dan Walsh, the main policy maintainer. Hopefully he'll comment here. > http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages I see you're using Arch to maintain the policy, very cool. I really wish we could do that here. Editing patches in Emacs' diff-mode and committing to CVS just isn't quite the same... -------------- 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 jwboyer at charter.net Thu Apr 22 01:05:44 2004 From: jwboyer at charter.net (Josh Boyer) Date: Wed, 21 Apr 2004 20:05:44 -0500 Subject: gpg avc In-Reply-To: <1082515001.3180.0.camel@nexus.verbum.private> References: <1082512947.2332.2.camel@localhost.localdomain> <1082515001.3180.0.camel@nexus.verbum.private> Message-ID: <1082595944.2332.5.camel@localhost.localdomain> On Tue, 2004-04-20 at 21:36, Colin Walters wrote: > Try this patch, will be in the next policy. Yep, that worked fine. Thanks. josh > > ______________________________________________________________________ From russell at coker.com.au Thu Apr 22 05:37:58 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 22 Apr 2004 15:37:58 +1000 Subject: gpg avc In-Reply-To: <200404211440.i3LEeLkn016813@turing-police.cc.vt.edu> References: <1082512947.2332.2.camel@localhost.localdomain> <1082554186.20679.7.camel@nexus.verbum.private> <200404211440.i3LEeLkn016813@turing-police.cc.vt.edu> Message-ID: <200404221537.58987.russell@coker.com.au> On Thu, 22 Apr 2004 00:40, Valdis.Kletnieks at vt.edu wrote: > I think the basic concept there is that even without a microphone, as you > sample, most cards won't return a steady stream of exact zeros - you'll get > back the tiniest bit of background hiss, and the low-order bits have > entropy. > > Of course, doing this without filtering is a Bad Idea - the amount of > entropy coming off the always-on cheap sound card in my laptop that has > maybe 70db S/N is probably a lot higher than somebody who has a high-end > card that has 85db S/N - and if their card supports auto-muting for unused > inputs, you're basically screwed... Detecting an auto-mute input should be quite easy, just read for a second or two and see if there is any change in the signal. Also writing non-random data to /dev/random is supposed to not cause any problems. -- 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 sds at epoch.ncsc.mil Thu Apr 22 11:37:50 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 22 Apr 2004 07:37:50 -0400 Subject: Fedora Core 2 and SELinux In-Reply-To: <1082590296.2839.126.camel@mentor.gurulabs.com> References: <20040420221237.GD4090@nostromo.devel.redhat.com> <20040420234236.GA26191@jadzia.bu.edu> <1082514303.22892.765.camel@rivendell.local.net> <200404210440.04073.gene@czarc.net> <1082550810.9213.19.camel@moss-spartans.epoch.ncsc.mil> <1082590296.2839.126.camel@mentor.gurulabs.com> Message-ID: <1082633870.10587.12.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-21 at 19:31, Dax Kelson wrote: > Nine hours ago Linus accepted that patch into his tree. Thanks for the heads up. I've sent a patch to libselinux to Dan to add a function exporting the runtime disable interface to applications, and he should then be able to modify init to try using it (and then fall back to the existing logic if it fails due to an older kernel). -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Apr 22 12:09:51 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 22 Apr 2004 08:09:51 -0400 Subject: SELinux issues In-Reply-To: <1082590492.6554.16.camel@nexus.verbum.private> References: <1082402757.12261.22.camel@nexus.verbum.private> <20040421225742.GB2255@jmh.mhn.de> <1082590492.6554.16.camel@nexus.verbum.private> Message-ID: <1082635791.10587.27.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-21 at 19:34, Colin Walters wrote: > On Wed, 2004-04-21 at 18:57, Thomas Bleher wrote: > > A full solution requires modifications to fam: it should check the > > security context of the caller (like it does already with uid and gid) > > and only monitor the files if they can be accessed by the caller. > > Right - I think someone here looked at doing that and just gave up. We > have someone working on writing a new file monitoring system, hopefully > something will happen there soon. I don't know that it would be technically difficult to modify famd to perform such checks (and SELinux does export an API for performing such checks that is already used by other programs), but you would still have a situation where famd would have to be highly trusted and a potential conduit through which domains could communicate in violation of the policy. It would be preferable to instantiate separarate famd's per client context. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Apr 22 14:43:37 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 22 Apr 2004 10:43:37 -0400 Subject: disabled selinux??? In-Reply-To: <1082336365.17961.1.camel@mentor.gurulabs.com> References: <1082336365.17961.1.camel@mentor.gurulabs.com> Message-ID: <4087DA19.80905@redhat.com> Dax Kelson wrote: >>fam-2.6.10-8 >>------------ >>* Fri Apr 16 2004 Alex Larsson 2.6.10-8 >> >>- re-enable fam since we disabled selinux >> >> > >What's the story? Hve the SELinux plans changed with FC2? > > SELinux will be disabled by default in FC2. You will have the ability to enable it during the install or by installing Policy and relabeling the file system. It was felt that the Policy was not in a state where we could support Policy being on by default. We are continuing our development and hope that people interested in SELinux will continue to test it and work with us to improve the quality of it. Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From shahms at shahms.com Thu Apr 22 15:15:47 2004 From: shahms at shahms.com (Shahms King) Date: Thu, 22 Apr 2004 08:15:47 -0700 Subject: SELinux issues In-Reply-To: <1082590492.6554.16.camel@nexus.verbum.private> References: <1082402757.12261.22.camel@nexus.verbum.private> <20040421225742.GB2255@jmh.mhn.de> <1082590492.6554.16.camel@nexus.verbum.private> Message-ID: <1082646946.12920.77.camel@shahms.mesd.k12.or.us> On Wed, 2004-04-21 at 16:34, Colin Walters wrote: > Right - I think someone here looked at doing that and just gave up. We > have someone working on writing a new file monitoring system, hopefully > something will happen there soon. "file monitoring system" on what level? A fam replacement or a dnotify replacement? I know he's employed by Novell these days, but RML seems pretty close to replacing both of these (of course, I haven't been able to find any code for his mysterious "kernel events layer"...) -- Shahms King From dwalsh at redhat.com Thu Apr 22 15:46:02 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 22 Apr 2004 11:46:02 -0400 Subject: gnome-cpufreq-applet problem In-Reply-To: <20040418165256.GC5220@server4.8080.it> References: <20040418165256.GC5220@server4.8080.it> Message-ID: <4087E8BA.6000507@redhat.com> Rudi Chiarito wrote: >Any attempts to start the 3rd party GNOME cpufreq applet (which can be >found at http://linups.org/~kal/gnome-cpufreq-applet/) will result in >two identical error messages like this: > >avc: denied { search } for pid=9558 >exe=/usr/libexec/gnome-cpufreq-applet dev= ino=1 >scontext=user_u:user_r:user_t tcontext=system_u:object_r:sysfs_t >tclass=dir > >The program is trying to read in /sys/devices/system/cpu/cpu*/cpufreq/. > >Rudi >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > The latest policy should allow this. Dan From dwalsh at redhat.com Thu Apr 22 16:04:25 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 22 Apr 2004 12:04:25 -0400 Subject: SELinux and Palm devices (with avc messages) In-Reply-To: <1082446808.3652.10.camel@mentor.gurulabs.com> References: <1082446808.3652.10.camel@mentor.gurulabs.com> Message-ID: <4087ED09.9070008@redhat.com> Dax Kelson wrote: >This has been on my ToDo list for awhile, here goes. > >I have a Treo 600 (finally, a converged device done right) Palm OS 5.2 >pda, cell phone, OGG/MP3/WMA player, mobile email, and mobile ssh >client. > >When I plug it in, it shows up at /dev/usb/ttyUSB1 > >Many of the binaries from the pilot-link package want to read and write >to that character device file. For sure the pilot-xfer utility. > >For example, > >audit(1082445673.351:0): avc: denied { read write } for pid=3647 exe=/usr/bin/pilot-xfer name=ttyUSB1 dev=hda8 ino=1210304 scontext=user_u:user_r:user_t tcontext=system_u:object_r:tty_device_t tclass=chr_file > >Additionally, I need to sync Evolution's calendar and address book with >my Treo. Evolution uses gnome-pilot and it's gpilotd daemon to >communicate with Palm devices. > >Currently this results in failure with the following avc message: > >audit(1082445978.961:0): avc: denied { read write } for pid=3735 exe=/usr/libexec/gpilotd name=ttyUSB1 dev=hda8 ino=1210304 scontext=user_u:user_r:user_t tcontext=system_u:object_r:tty_device_t tclass=chr_file > >Dax Kelson >Guru Labs > > > Bugzilla please. >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From dax at gurulabs.com Thu Apr 22 17:42:17 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 22 Apr 2004 11:42:17 -0600 Subject: SELinux and Palm devices (with avc messages) In-Reply-To: <4087ED09.9070008@redhat.com> References: <1082446808.3652.10.camel@mentor.gurulabs.com> <4087ED09.9070008@redhat.com> Message-ID: <1082655736.2845.30.camel@mentor.gurulabs.com> On Thu, 2004-04-22 at 10:04, Daniel J Walsh wrote: > Bugzilla please. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121545 From kmazurczyk at wskiz.poznan.pl Thu Apr 22 20:23:46 2004 From: kmazurczyk at wskiz.poznan.pl (Krzysztof Mazurczyk) Date: Thu, 22 Apr 2004 22:23:46 +0200 Subject: SE Linux policy Message-ID: <20040422202346.GC14558@Winux.wskiz.poznan.pl> Hi all, I have started playing with new SE Linux. I have it already running. BTW minor question: There are messages in log that /sbin/unix_verify is denied to do something. System is seemed to work well. Because /sbin/unix_verify is from libpam-modules I'm not sure what to do - ignore or add some rules to policy for /sbin/unix_verify. I can run user-mode-linux from my shell but I need to run UML when main system boots. UML should generaly run via nohup program in background mode. My main question is how to that. I'm generally looking for good solution from security point of view and relatively easy to do. I have thought about: 1) Leave UML running in initrc_t domain - now I have but it is bad. Isn't it? 2) Create special domain - is impossible for me yet. 3) Extend rights for existing domains. 4) Run UML via runcon program in init.d script in the same context like when run from shell. 3) and 4) are similar somehow but 4) seems to be easier to do. I can modify policy adding 'allow' rules but I'm not sure if it is right way in this case. I haven't found a document like, let's say, 'general advices' containing advices like: 'what can be do safely', 'what should be avoided', 'if you do ... remember about ...', 'be careful if you want ...', 'if you allow ... you week policy seriously'. I have feeling that SE Linux policy has its own deep philosophy so I'm afraid to make deeper changes in policy and not to break policy seriously. Any advices, helps or comments are welcome. Best regards, Chris From bleher at informatik.uni-muenchen.de Thu Apr 22 21:37:54 2004 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Thu, 22 Apr 2004 23:37:54 +0200 Subject: SELinux issues In-Reply-To: <1082590492.6554.16.camel@nexus.verbum.private> References: <1082402757.12261.22.camel@nexus.verbum.private> <20040421225742.GB2255@jmh.mhn.de> <1082590492.6554.16.camel@nexus.verbum.private> Message-ID: <20040422213753.GA5683@jmh.mhn.de> * Colin Walters [2004-04-22 01:35]: > On Wed, 2004-04-21 at 18:57, Thomas Bleher wrote: > > http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages > > I see you're using Arch to maintain the policy, very cool. I really > wish we could do that here. Editing patches in Emacs' diff-mode and > committing to CVS just isn't quite the same... Yeah, arch is just So Cool! I really hope it gets adopted more widely. Right now I have some patches and cleanups in my local trees; I haven't sent them yet because preparing patches, splitting and cleaning them requires extra work. With arch this process would be much easier. So I hope someone soon makes an official arch archive where merge request can be sent to. That would really rock :-) For the time being I will maintain my arch repository. I have attached the small script I use to replay changes from CVS into arch. I didn't use cscvs because I wanted to use taglines (really useful with all the file moving). Syncing the other way round (arch->cvs) is not done yet, but shouldn't be too difficult; only the taglines need to be filtered out. Thomas -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7 Write a wise saying, and your name will live forever. -- Anonymous -------------- next part -------------- #!/bin/bash # (C) 2004 Thomas Bleher under the GNU GPL v2 # clean up a patch between a cvs tree and an arch tree with taglines # just pipe your patch through this... # # this small script can be used to synchronize an arch-archive with a # cvs repository. assuming the codebase is identical except taglines # Usage: diff -urN arch/ cvs/ | cleanup-patch | patch -d arch/ -p1 # the above line merges all changes from cvs into arch # first filter out all control files filterdiff -x '*/CVS/*' -x '*/.arch-i*' -x '*/{arch}/*' -x '*/,,*' -x '*/++log*' | filterdiff | \ perl -0 -w -ne '# slurp the whole patch in and mangle it for my $file (split(/(?=\n--- )/)) { # split into files for (split(/\n(?=@@ )/m, $file)) { # split into chunks (starting with @@) if (not /^@/) { # the header, just pass it through $data = $_; } else { # the cvs version doesnt have arch-tags; filter them from the diff if (s/\n-\n-(# arch-tag: [-a-z0-9]+)(.*)/$2\n \n $1/s # arch-tag with preceding blank line || s/\n-(# arch-tag: [-a-z0-9]+)(.*)/$2\n+\n $1/s) { # single line arch-tag s/^(@@ -\d+,\d+ \+\d+,)(\d+)( @@\n)/$1.($2 + 2).$3/me; # adjust line count in patch } s/^@@.*?@@(\n[ \\].*)+$//g; # delete hunks that are now empty if (not /^$/) { $data .= "\n".$_; } } } print $data unless ($data =~ /^\n---.*\n\+\+\+.*$/); } ' | \ filterdiff | interdiff -U 3 /dev/null /proc/self/fd/0 | filterdiff # some final cleanup -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From russell at coker.com.au Sat Apr 24 12:23:10 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 24 Apr 2004 22:23:10 +1000 Subject: SE Linux policy In-Reply-To: <20040422202346.GC14558@Winux.wskiz.poznan.pl> References: <20040422202346.GC14558@Winux.wskiz.poznan.pl> Message-ID: <200404242223.10817.russell@coker.com.au> On Fri, 23 Apr 2004 06:23, Krzysztof Mazurczyk wrote: > I have started playing with new SE Linux. I have it already running. > BTW minor question: There are messages in log that /sbin/unix_verify > is denied to do something. System is seemed to work well. Because > /sbin/unix_verify is from libpam-modules I'm not sure what to do - > ignore or add some rules to policy for /sbin/unix_verify. What access is denied? > I can run user-mode-linux from my shell but I need to run UML when main > system boots. UML should generaly run via nohup program in background > mode. My main question is how to that. The following is the start of what is needed for a first cut at it. Try it and let me know how it goes. domain_auto_trans(initrc_t, uml_exec_t, sysadm_uml_t) -- 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 fedora at andrewfarris.com Mon Apr 26 07:55:07 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Mon, 26 Apr 2004 00:55:07 -0700 Subject: .te files in packages In-Reply-To: <1082570402.12920.73.camel@shahms.mesd.k12.or.us> References: <1082570402.12920.73.camel@shahms.mesd.k12.or.us> Message-ID: <1082966107.3422.10.camel@CirithUngol> On Wed, 2004-04-21 at 11:00 -0700, Shahms King wrote: > (I just subscribed, so I'm replying from the list archive...) > > Given that FC2 is no longer shipping with SELinux enabled by default, it > makes sense to have a separate policy package for individual packages, > IMHO. While this sounds like a neat idea.. I can see problems with it being used effectively. What if a user has selinux disabled when they install a number of packages, and then decide to turn it on--the packages would have to be retrieved and installed before they could be used. That could be frustrating, especially for network isolated machines. Might it be better to include the policy with the main package, to install the policy files into the policy source, but not to rebuild or reload the policy unless selinux was running. As I understood.. shipping with selinux off by default would not mean the packages were not installed at all. If the policy will not be installed at all, and each 'extra' package installed that contained policy abstained from installing the policy, then some mechanism would be required to extract all the policy from 'extra' installed packages at the time selinux was installed or enabled (in the future). That would be difficult as well, so including the policy files may not be a perfect solution either. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From kmazurczyk at wskiz.poznan.pl Mon Apr 26 10:05:41 2004 From: kmazurczyk at wskiz.poznan.pl (Krzysztof Mazurczyk) Date: Mon, 26 Apr 2004 12:05:41 +0200 Subject: SE Linux policy In-Reply-To: <200404242223.10817.russell@coker.com.au> References: <20040422202346.GC14558@Winux.wskiz.poznan.pl> <200404242223.10817.russell@coker.com.au> Message-ID: <20040426100541.GA18699@Winux.wskiz.poznan.pl> On Sat, 24/Apr/04 22:23:10, Russell Coker wrote: > On Fri, 23 Apr 2004 06:23, Krzysztof Mazurczyk > wrote: > > I have started playing with new SE Linux. I have it already running. > > BTW minor question: There are messages in log that /sbin/unix_verify > > is denied to do something. System is seemed to work well. Because > > /sbin/unix_verify is from libpam-modules I'm not sure what to do - > > ignore or add some rules to policy for /sbin/unix_verify. > > What access is denied? > avc: denied { getattr } for pid=1768 exe=/sbin/unix_verify path=/proc/1768/mounts dev= ino=115867664 scontext=system_u:system_r: system_chkpwd_t tcontext=system_u:system_r:system_chkpwd_t tclass=file avc: denied { use } for pid=3608 exe=/sbin/unix_verify path=/dev/null dev=sda2 ino=2021 scontext=system_u:system_r:system_chkpwd_t tcontext= system_u:system_r:system_crond_t tclass=fd avc: denied { read write } for pid=1795 exe=/sbin/unix_verify path=/dev/tty1 dev=sda2 ino=2845 scontext=system_u:system_r: system_chkpwd_t tcontext=root:object_r:sysadm_tty_device_t tclass= chr_file avc: denied { search } for pid=1795 exe=/sbin/unix_verify name=run dev=sda5 ino=31172 scontext=system_u:system_r:system_chkpwd_t tcontext=system_u:object_r:var_run_t tclass=dir > > I can run user-mode-linux from my shell but I need to run UML when main > > system boots. UML should generaly run via nohup program in background > > mode. My main question is how to that. > > The following is the start of what is needed for a first cut at it. Try it > and let me know how it goes. > domain_auto_trans(initrc_t, uml_exec_t, sysadm_uml_t) > Yes, I have found it. But then I've got 'security-compute-sid: invalid context system_u:system_r:sysadm_uml_t for scontext=system_u:system_r: initrc_t tcontext=system_u:object_r:uml_exec_t tclass=process'. Googling hasn't told me what to do. Regards, Chris From dax at gurulabs.com Mon Apr 26 19:14:02 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 26 Apr 2004 13:14:02 -0600 Subject: Current rawhide (test3??) Firstboot AVC messages Message-ID: <1083006841.3080.21.camel@mentor.gurulabs.com> I did an install from rawhide last night. It claims to be test3. I started my install with "linux selinux" and run in enforcing mode. After going through the FirstBoot app, I logged in as root at the text terminal and ran "dmesg | grep avc". Here is the output: audit(1082992916.819:0): avc: denied { create } for pid=211 exe=/sbin/lvm.static name=archive scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:lvm_etc_t tclass=dir audit(1082992944.637:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB0 dev=hda6 ino=700638 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB1 dev=hda6 ino=700639 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB2 dev=hda6 ino=700646 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB3 dev=hda6 ino=700647 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB4 dev=hda6 ino=700648 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB5 dev=hda6 ino=700649 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB6 dev=hda6 ino=700650 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB7 dev=hda6 ino=700651 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB8 dev=hda6 ino=700652 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.638:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB9 dev=hda6 ino=700653 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.639:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB10 dev=hda6 ino=700640 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.639:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB11 dev=hda6 ino=700641 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.639:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB12 dev=hda6 ino=700642 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.639:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB13 dev=hda6 ino=700643 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.639:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB14 dev=hda6 ino=700644 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992944.639:0): avc: denied { write } for pid=1495 exe=/usr/lib/cups/backend/serial name=ttyUSB15 dev=hda6 ino=700645 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usbtty_device_t tclass=chr_file audit(1082992952.663:0): avc: denied { transition } for pid=1663 exe=/bin/su path=/bin/bash dev=hda6 ino=977288 scontext=system_u:system_r:initrc_su_t tcontext=user_u:sysadm_r:sysadm_t tclass=process audit(1082992965.952:0): avc: denied { unix_read unix_write } for pid=51 exe=/usr/X11R6/bin/Xorg key=0 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:system_r:firstboot_t tclass=shm audit(1082992972.074:0): avc: denied { read } for pid=1916 exe=/sbin/consoletype path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:consoletype_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992972.074:0): avc: denied { write } for pid=1916 exe=/sbin/consoletype path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:consoletype_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992972.161:0): avc: denied { read } for pid=1917 exe=/sbin/iptables path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:iptables_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992972.161:0): avc: denied { write } for pid=1917 exe=/sbin/iptables path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:iptables_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992987.095:0): avc: denied { read } for pid=1931 exe=/sbin/consoletype path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:consoletype_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992987.095:0): avc: denied { write } for pid=1931 exe=/sbin/consoletype path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:consoletype_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992987.106:0): avc: denied { read } for pid=1932 exe=/sbin/iptables path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:iptables_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992987.107:0): avc: denied { write } for pid=1932 exe=/sbin/iptables path=pipe:[3710] dev= ino=3710 scontext=system_u:system_r:iptables_t tcontext=system_u:system_r:firstboot_t tclass=fifo_file audit(1082992996.944:0): avc: denied { unix_read unix_write } for pid=51 exe=/usr/X11R6/bin/Xorg key=0 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:system_r:firstboot_t tclass=shm From dax at gurulabs.com Mon Apr 26 19:17:46 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 26 Apr 2004 13:17:46 -0600 Subject: Current rawhide RHGB avc message Message-ID: <1083007066.3080.25.camel@mentor.gurulabs.com> The Red Hat graphical boot program "rhgb" generates this avc message at bootup. It seems to run ok. audit(1082997673.875:0): avc: denied { read } for pid=49 exe=/usr/bin/rhgb name=XF86Config dev=hda6 ino=408408 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:firstboot_rw_t tclass=file A oddity (non SELinux related) thing I noticed is that the the files /etc/X11/XF86Config and /etc/X11/xorg.conf both exist and have different contents. From dax at gurulabs.com Mon Apr 26 19:25:08 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 26 Apr 2004 13:25:08 -0600 Subject: Current rawhide "cardctl ident" problem Message-ID: <1083007507.3080.33.camel@mentor.gurulabs.com> In enforcing mode I can't run the cardctl program. Specifically, I tried "cardctl ident" to get a list of PCMCIA/Cardbus devices. It comes back with an error message, and this avc message: audit(1082997955.593:0): avc: denied { ioctl } for pid=2076 exe=/sbin/cardctl path=/dev/tty1 dev=hda6 ino=678551 scontext=root:sysadm_r:cardmgr_t tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file From russell at coker.com.au Mon Apr 26 21:58:57 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 27 Apr 2004 07:58:57 +1000 Subject: .te files in packages In-Reply-To: <1082966107.3422.10.camel@CirithUngol> References: <1082570402.12920.73.camel@shahms.mesd.k12.or.us> <1082966107.3422.10.camel@CirithUngol> Message-ID: <200404270758.57036.russell@coker.com.au> On Mon, 26 Apr 2004 17:55, Andrew Farris wrote: > On Wed, 2004-04-21 at 11:00 -0700, Shahms King wrote: > > (I just subscribed, so I'm replying from the list archive...) > > > > Given that FC2 is no longer shipping with SELinux enabled by default, it > > makes sense to have a separate policy package for individual packages, > > IMHO. > > While this sounds like a neat idea.. I can see problems with it being > used effectively. What if a user has selinux disabled when they install > a number of packages, and then decide to turn it on--the packages would > have to be retrieved and installed before they could be used. That > could be frustrating, especially for network isolated machines. The obvious solution to this is that policy files would be kept on the system regardless of whether SE Linux was active at installation time or not. Policy files are quite small... > Might it be better to include the policy with the main package, to > install the policy files into the policy source, but not to rebuild or > reload the policy unless selinux was running. As I understood.. Having the policy files for as many applications as possible in the policy-source package is good. However we expect that our customers will want to build their own rpms of in-house software and that some vendors will want to produce rpms of proprietary software with SE Linux support. -- 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 russell at coker.com.au Mon Apr 26 22:26:08 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 27 Apr 2004 08:26:08 +1000 Subject: SE Linux policy In-Reply-To: <20040426100541.GA18699@Winux.wskiz.poznan.pl> References: <20040422202346.GC14558@Winux.wskiz.poznan.pl> <200404242223.10817.russell@coker.com.au> <20040426100541.GA18699@Winux.wskiz.poznan.pl> Message-ID: <200404270826.08187.russell@coker.com.au> On Mon, 26 Apr 2004 20:05, Krzysztof Mazurczyk wrote: > > > I have started playing with new SE Linux. I have it already running. > > > BTW minor question: There are messages in log that /sbin/unix_verify > > > is denied to do something. System is seemed to work well. Because > > > /sbin/unix_verify is from libpam-modules I'm not sure what to do - > > > ignore or add some rules to policy for /sbin/unix_verify. > > > > What access is denied? > > avc: denied { getattr } for pid=1768 exe=/sbin/unix_verify > path=/proc/1768/mounts dev= ino=115867664 scontext=system_u:system_r: > system_chkpwd_t tcontext=system_u:system_r:system_chkpwd_t tclass=file Allow this. The main policy will be changed to allow this. > avc: denied { use } for pid=3608 exe=/sbin/unix_verify path=/dev/null > dev=sda2 ino=2021 scontext=system_u:system_r:system_chkpwd_t tcontext= > system_u:system_r:system_crond_t tclass=fd This looks like a bug in the policy, it should have been allowed. Please file a bug on bugzilla. > avc: denied { read write } for pid=1795 exe=/sbin/unix_verify > path=/dev/tty1 dev=sda2 ino=2845 scontext=system_u:system_r: > system_chkpwd_t tcontext=root:object_r:sysadm_tty_device_t tclass= > chr_file This looks like a bug in pam, that file handle should have been closed before the execution of unix_verify. > avc: denied { search } for pid=1795 exe=/sbin/unix_verify name=run > dev=sda5 ino=31172 scontext=system_u:system_r:system_chkpwd_t > tcontext=system_u:object_r:var_run_t tclass=dir We should have a dontaudit for that. > > The following is the start of what is needed for a first cut at it. Try > > it and let me know how it goes. > > domain_auto_trans(initrc_t, uml_exec_t, sysadm_uml_t) > > Yes, I have found it. But then I've got 'security-compute-sid: invalid > context system_u:system_r:sysadm_uml_t for scontext=system_u:system_r: > initrc_t tcontext=system_u:object_r:uml_exec_t tclass=process'. Googling > hasn't told me what to do. In this case: role system_r types sysadm_uml_t; But long-term I think that the right thing to do is to make some changes to the UML policy to cover this and related issues. -- 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 fedora at andrewfarris.com Tue Apr 27 01:00:29 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Mon, 26 Apr 2004 18:00:29 -0700 Subject: Current rawhide RHGB avc message In-Reply-To: <1083007066.3080.25.camel@mentor.gurulabs.com> References: <1083007066.3080.25.camel@mentor.gurulabs.com> Message-ID: <1083021976.13412.2.camel@CirithUngol> On Mon, 2004-04-26 at 13:17 -0600, Dax Kelson wrote: > A oddity (non SELinux related) thing I noticed is that the the files > /etc/X11/XF86Config and /etc/X11/xorg.conf both exist and have different > contents. /etc/X11/xorg.conf should now be used, /etc/X11/XF86config should be removed for clarity... it is still referenced in the event that xorg.conf does not exist. The log (/var/log/Xorg.0.log) should explicitly claim which config file is in use. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From fedora at andrewfarris.com Tue Apr 27 01:39:44 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Mon, 26 Apr 2004 18:39:44 -0700 Subject: nVIDIA binary driver audits generated by OpenGL apps Message-ID: <1083029984.18163.9.camel@CirithUngol> I am working toward getting Enforcing mode to work with the nvidia binary drivers, and having some difficulties. I see that there is some policy with this intention , but it is not quite adequate yet, as below. Some hints how to proceed, or solutions to this would be appreciated. Running enforcing with /dev/nvidia* labeled as xserver_misc_device_t: Apr 26 17:13:59 CirithUngol kernel: audit(1083024839.937:0): avc: denied { read write } for pid=15200 exe=/usr/X11R6/bin/glxinfo name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file Apr 26 17:14:04 CirithUngol kernel: audit(1083024844.641:0): avc: denied { read write } for pid=15209 exe=/usr/X11R6/bin/glxgears name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file The X server can start up as normal user without any audit of X itself startinghen X is started in permissive mode only these audits appear, but glxgears and glxinfo work as expected. These programs, and all my other openGL apps, need access to /dev/nvidiactl. The error message generated at command prompt in enforcing mode is: Error: Could not open /dev/nvidiactl because the permissions are too resticitive. Please see the FREQUENTLY ASKED QUESTIONS section of /usr/share/doc/NVIDIA_GLX-1.0/README for steps to correct. Although the unix perms of the device nodes are all identical as below: crw-rw-rw- 0 0 system_u:object_r:xserver_misc_device_t /dev/nvidiactl crw-rw-rw- 1 0 0 195, 255 Apr 17 16:28 /dev/nvidiactl To relabel the devices I uncommented the definition of xserver_misc_device_t from ./types/device.te, and added the following line to ./file_contexts/program/xserver.fc (then make reload, followed by setfiles on these devices). /dev/nvidia.* system_u:object_r:xserver_misc_device_t And I rely on these (there are 4) lines in policy.conf after the make (I do not understand how these are generated yet). allow user_xserver_t xserver_misc_device_t:chr_file { ioctl read getattr lock write append }; When running enforcing with the /dev/nvidia* devices labeled as dri_device_t (had to try), the same behavior exists, X runs.. but glxgears/glxinfo (and GL games) cannot access the nvidiactl device. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From fedora at andrewfarris.com Tue Apr 27 01:52:54 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Mon, 26 Apr 2004 18:52:54 -0700 Subject: Access to cd device denied for cdp Message-ID: <1083030774.18163.22.camel@CirithUngol> Playing a cd from the terminal using cdp, or cdplay (non-interactive), results in the following avc in permissive mode (but the cd is allowed to play): Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 ino=66203 scontext=user_u:user_r:user_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file This is not audited in enforcing mode.. but does not work either (program exits with "please chmod 666 /dev/cdrom as root"). /dev/cdrom is symlinked directly to /dev/hdc. 4.0K lrwxrwxrwx 1 0 0 8 Mar 29 17:26 /dev/cdrom -> /dev/hdc 4.0K brw-rw-rw- 1 0 6 22, 0 Feb 23 13:02 /dev/hdc Is this expected, or desired behavior? Shouldn't a locally logged in user be allowed access to audio cds? (perhaps should be -or is- tunable) I'm working with policy-sources-1.11.2-13. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From dax at gurulabs.com Tue Apr 27 16:59:57 2004 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 27 Apr 2004 10:59:57 -0600 Subject: x.org DRI/Hardware accel (a SELinux problem) In-Reply-To: References: <1082497553.2842.88.camel@mentor.gurulabs.com> Message-ID: <1083085196.2825.13.camel@mentor.gurulabs.com> On Tue, 2004-04-20 at 15:50, Mike A. Harris wrote: > On Tue, 20 Apr 2004, Dax Kelson wrote: > > >Should I bugzilla this, or is it a known issue? > > > >A did a install from Rawhide yesterday (also noted with test2), and on > >my laptop with an Radeon Mobility M7 LW [Radeon Mobility 7500]. I have > >no direct rendering. > > > >$ glxinfo | grep rendering: > >direct rendering: No > > > >It did work with RHL8, RHL9, and FC1. FYI, I have an 80GB hard disk in my laptop and I did two concurrent Everything installs of FC2T3. One in SELinux enforcing mode and the other with SELinux disabled (the default). Without SELinux = Direct Rending works With Enforcing SELinux = Direct Rending doesn't work Curiously, I didn't see any avc messages that seem to be related. Dax Kelson Guru Labs From Valdis.Kletnieks at vt.edu Tue Apr 27 17:52:12 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Apr 2004 13:52:12 -0400 Subject: Policy file for 'aide' and/or 'tripwire'? Message-ID: <200404271752.i3RHqC8E015562@turing-police.cc.vt.edu> Has anybody already done a policy file for Tripwire or its open-sourced replacement 'aide'? Trying to run 'tripwire --check' from a cron job gets this: Apr 27 04:03:37 orange kernel: audit(1083053017.355:0): avc: denied { write } for pid=14045 exe=/usr/sbin/tripwire name=tripwire dev=dm-5 ino=22529 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:var_t tclass=dir when trying to open the TEMPDIRECTORY directory: # ls -ld --context /var/tripwire/ drwx------+ root root system_u:object_r:var_t /var/tripwire/ (The actual database files are here: # ls --context /var/lib/tripwire -rw-------+ root root system_u:object_r:var_lib_t orange.cirt.vt.edu.twd -rw------- root root system_u:object_r:var_lib_t orange.cirt.vt.edu.twd.bak drwxr-xr-x+ root root system_u:object_r:var_lib_t report It occurs to me that it would be simple but incorrect to just use setfilecon to coerce the contexts into something that works, and that a separate set of tripwire_t and/or aide_t contexts is probably desired. Having no wish to reinvent the wheel, has anybody done this already? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From nagray at austin.rr.com Tue Apr 27 15:11:37 2004 From: nagray at austin.rr.com (Nick Gray) Date: Tue, 27 Apr 2004 10:11:37 -0500 Subject: Core 2 Test 3 Message-ID: <1083078696.29534.168.camel@hawaii.efficax.net> OK Dan, I am on the right list now! I joined this morning and was reviewing the archives. First question is about the way that we are the installation/selection of SELinux in Core 2 from the message titled 'Fedora Core 2 and SELinux' > SELinux *will* be included in Fedora Core 2 test 3 and the final > Fedora Core 2 release. However, SELinux will be disabled by default. > To install with SELinux support, pass 'selinux' to the installer > on the command line. (Or, configure it appropriately in kickstart). Can Someone justify using a command line option to the installation process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1. I will add the same below. From tdiehl at rogueind.com Wed Apr 28 02:03:07 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 27 Apr 2004 22:03:07 -0400 (EDT) Subject: Core 2 Test 3 In-Reply-To: <1083078696.29534.168.camel@hawaii.efficax.net> References: <1083078696.29534.168.camel@hawaii.efficax.net> Message-ID: On Tue, 27 Apr 2004, Nick Gray wrote: > OK Dan, I am on the right list now! > > I joined this morning and was reviewing the archives. First question is > about the way that we are the installation/selection of SELinux in Core > 2 from the message titled 'Fedora Core 2 and SELinux' > > > SELinux *will* be included in Fedora Core 2 test 3 and the final > > Fedora Core 2 release. However, SELinux will be disabled by default. > > To install with SELinux support, pass 'selinux' to the installer > > on the command line. (Or, configure it appropriately in kickstart). > > Can Someone justify using a command line option to the installation > process. I provided to the SEL list, a comp.xml skeleton that I used to > add SEL to Core 1. I will add the same below. Because selinux is not ready for prime time. Devel is continuing and if you want to test it feel free to add the switch, otherwise ignore the selinux part. Tom From aleksey at nogin.org Wed Apr 28 06:05:16 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Tue, 27 Apr 2004 23:05:16 -0700 Subject: AVC attaching gdb to Mozilla process. Message-ID: <408F499C.9020100@nogin.org> Under policy-sources-1.11.2-18: audit(1083131647.146:0): avc: denied { signal } for pid=28661 exe=/usr/bin/gdb scontext=aleksey:staff_r:staff_mozilla_t tcontext=aleksey:staff_r:staff_t tclass=process -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From aleksey at nogin.org Wed Apr 28 06:07:32 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Tue, 27 Apr 2004 23:07:32 -0700 Subject: Weird avc messages from udev Message-ID: <408F4A24.4000809@nogin.org> I am getting a lot of messages of the form: audit(1083104429.259:0): avc: denied { sendto } for pid=23780 exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1083104431.054:0): avc: denied { sendto } for pid=23803 exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1083104431.406:0): avc: denied { sendto } for pid=23815 exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1083104432.080:0): avc: denied { sendto } for pid=23821 exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From aleksey at nogin.org Wed Apr 28 06:58:31 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Tue, 27 Apr 2004 23:58:31 -0700 Subject: Numerous problems with postfix's newaliases. Message-ID: <408F5617.10809@nogin.org> When MTA is set to postfix, if I try to use newaliases in enforcing mode, I get: audit(1083135148.926:0): security_compute_sid: invalid context root:system_r:sysadm_mail_t for scontext=root:sysadm_r:sysadm_mail_t tcontext=system_u:object_r:postfix_master_exec_t tclass=process and execution fails. In permissive mode, I see: audit(1083135243.731:0): security_compute_sid: invalid context root:system_r:sysadm_mail_t for scontext=root:sysadm_r:sysadm_mail_t tcontext=system_u:object_r:postfix_master_exec_t tclass=process audit(1083135243.732:0): avc: denied { transition } for pid=29608 exe=/usr/sbin/sendmail.postfix path=/usr/sbin/postalias dev=hda2 ino=392740 scontext=root:sysadm_r:sysadm_mail_t tcontext=root:system_r:sysadm_mail_t tclass=process audit(1083135243.732:0): avc: denied { entrypoint } for pid=29608 exe=/usr/sbin/sendmail.postfix path=/usr/sbin/postalias dev=hda2 ino=392740 scontext=root:system_r:sysadm_mail_t tcontext=system_u:object_r:postfix_master_exec_t tclass=file audit(1083135243.733:0): avc: denied { use } for pid=29608 exe=/usr/sbin/postalias path=/proc/net/if_inet6 dev= ino=-268434827 scontext=root:system_r:sysadm_mail_t tcontext=root:sysadm_r:sysadm_mail_t tclass=fd audit(1083135243.733:0): avc: denied { siginh } for pid=29608 exe=/usr/sbin/postalias scontext=root:sysadm_r:sysadm_mail_t tcontext=root:system_r:sysadm_mail_t tclass=process audit(1083135243.733:0): avc: denied { rlimitinh } for pid=29608 exe=/usr/sbin/postalias scontext=root:sysadm_r:sysadm_mail_t tcontext=root:system_r:sysadm_mail_t tclass=process audit(1083135243.733:0): avc: denied { noatsecure } for pid=29608 exe=/usr/sbin/postalias scontext=root:sysadm_r:sysadm_mail_t tcontext=root:system_r:sysadm_mail_t tclass=process audit(1083135243.757:0): avc: denied { write } for pid=29608 exe=/usr/sbin/postalias name=postfix dev=hda2 ino=4055697 scontext=root:system_r:sysadm_mail_t tcontext=system_u:object_r:postfix_etc_t tclass=dir audit(1083135243.757:0): avc: denied { add_name } for pid=29608 exe=/usr/sbin/postalias name=__db.aliases.db scontext=root:system_r:sysadm_mail_t tcontext=system_u:object_r:postfix_etc_t tclass=dir audit(1083135243.757:0): avc: denied { create } for pid=29608 exe=/usr/sbin/postalias name=__db.aliases.db scontext=root:system_r:sysadm_mail_t tcontext=root:object_r:postfix_etc_t tclass=file audit(1083135243.758:0): avc: denied { write } for pid=29608 exe=/usr/sbin/postalias path=/etc/postfix/__db.aliases.db dev=hda2 ino=4055330 scontext=root:system_r:sysadm_mail_t tcontext=root:object_r:postfix_etc_t tclass=file audit(1083135243.764:0): avc: denied { remove_name } for pid=29608 exe=/usr/sbin/postalias name=__db.aliases.db dev=hda2 ino=4055330 scontext=root:system_r:sysadm_mail_t tcontext=system_u:object_r:postfix_etc_t tclass=dir audit(1083135243.764:0): avc: denied { rename } for pid=29608 exe=/usr/sbin/postalias name=__db.aliases.db dev=hda2 ino=4055330 scontext=root:system_r:sysadm_mail_t tcontext=root:object_r:postfix_etc_t tclass=file -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From sds at epoch.ncsc.mil Wed Apr 28 12:11:40 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 28 Apr 2004 08:11:40 -0400 Subject: AVC attaching gdb to Mozilla process. In-Reply-To: <408F499C.9020100@nogin.org> References: <408F499C.9020100@nogin.org> Message-ID: <1083154300.25987.44.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-28 at 02:05, Aleksey Nogin wrote: > Under policy-sources-1.11.2-18: > > audit(1083131647.146:0): avc: denied { signal } for pid=28661 > exe=/usr/bin/gdb scontext=aleksey:staff_r:staff_mozilla_t > tcontext=aleksey:staff_r:staff_t tclass=process In general, you'd like to confine mozilla so that if it is subverted by malicious code, then it can't do much harm. So allowing it to send signals back to the user domain isn't desirable. For development environments, you might want a policy tunable or boolean to allow such permissions, but not for operational use. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed Apr 28 15:40:59 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 Apr 2004 11:40:59 -0400 Subject: nVIDIA binary driver audits generated by OpenGL apps In-Reply-To: <1083029984.18163.9.camel@CirithUngol> References: <1083029984.18163.9.camel@CirithUngol> Message-ID: <408FD08B.9030000@redhat.com> Andrew Farris wrote: >I am working toward getting Enforcing mode to work with the nvidia >binary drivers, and having some difficulties. I see that there is some >policy with this intention , but it is not quite adequate yet, as below. >Some hints how to proceed, or solutions to this would be appreciated. >Running enforcing with /dev/nvidia* labeled as xserver_misc_device_t: > >Apr 26 17:13:59 CirithUngol kernel: audit(1083024839.937:0): avc: >denied { read write } for pid=15200 exe=/usr/X11R6/bin/glxinfo >name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t >tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file > >Apr 26 17:14:04 CirithUngol kernel: audit(1083024844.641:0): avc: >denied { read write } for pid=15209 exe=/usr/X11R6/bin/glxgears >name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t >tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file > >The X server can start up as normal user without any audit of X itself >startinghen X is started in permissive mode only these audits appear, >but glxgears and glxinfo work as expected. These programs, and all my >other openGL apps, need access to /dev/nvidiactl. > >The error message generated at command prompt in enforcing mode is: >Error: Could not open /dev/nvidiactl because the permissions >are too resticitive. Please see the FREQUENTLY ASKED QUESTIONS >section of /usr/share/doc/NVIDIA_GLX-1.0/README for steps >to correct. > >Although the unix perms of the device nodes are all identical as below: >crw-rw-rw- 0 0 system_u:object_r:xserver_misc_device_t /dev/nvidiactl >crw-rw-rw- 1 0 0 195, 255 Apr 17 16:28 /dev/nvidiactl > >To relabel the devices I uncommented the definition of >xserver_misc_device_t from ./types/device.te, and added the following >line to ./file_contexts/program/xserver.fc (then make reload, followed >by setfiles on these devices). >/dev/nvidia.* system_u:object_r:xserver_misc_device_t > >And I rely on these (there are 4) lines in policy.conf after the make (I >do not understand how these are generated yet). >allow user_xserver_t xserver_misc_device_t:chr_file { ioctl read getattr >lock write append }; > >When running enforcing with the /dev/nvidia* devices labeled as >dri_device_t (had to try), the same behavior exists, X runs.. but >glxgears/glxinfo (and GL games) cannot access the nvidiactl device. > > > Did setting the context to xserver_misc_device_t get it to work? Dan From dwalsh at redhat.com Wed Apr 28 15:52:31 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 Apr 2004 11:52:31 -0400 Subject: Weird avc messages from udev In-Reply-To: <408F4A24.4000809@nogin.org> References: <408F4A24.4000809@nogin.org> Message-ID: <408FD33F.3000205@redhat.com> Aleksey Nogin wrote: > I am getting a lot of messages of the form: > > audit(1083104429.259:0): avc: denied { sendto } for pid=23780 > exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t > tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket > audit(1083104431.054:0): avc: denied { sendto } for pid=23803 > exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t > tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket > audit(1083104431.406:0): avc: denied { sendto } for pid=23815 > exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t > tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket > audit(1083104432.080:0): avc: denied { sendto } for pid=23821 > exe=/sbin/udevsendpath=@udevd scontext=system_u:system_r:udev_t > tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket > Does adding allow udev_t kernel_t:unix_dgram_socket { sendto }; solv the problem? Dan From dwalsh at redhat.com Wed Apr 28 15:53:55 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 Apr 2004 11:53:55 -0400 Subject: x.org DRI/Hardware accel (a SELinux problem) In-Reply-To: <1083085196.2825.13.camel@mentor.gurulabs.com> References: <1082497553.2842.88.camel@mentor.gurulabs.com> <1083085196.2825.13.camel@mentor.gurulabs.com> Message-ID: <408FD393.80905@redhat.com> Dax Kelson wrote: >On Tue, 2004-04-20 at 15:50, Mike A. Harris wrote: > > >>On Tue, 20 Apr 2004, Dax Kelson wrote: >> >> >> >>>Should I bugzilla this, or is it a known issue? >>> >>>A did a install from Rawhide yesterday (also noted with test2), and on >>>my laptop with an Radeon Mobility M7 LW [Radeon Mobility 7500]. I have >>>no direct rendering. >>> >>>$ glxinfo | grep rendering: >>>direct rendering: No >>> >>>It did work with RHL8, RHL9, and FC1. >>> >>> > >FYI, I have an 80GB hard disk in my laptop and I did two concurrent >Everything installs of FC2T3. One in SELinux enforcing mode and the >other with SELinux disabled (the default). > >Without SELinux = Direct Rending works >With Enforcing SELinux = Direct Rending doesn't work > >Curiously, I didn't see any avc messages that seem to be related. > >Dax Kelson >Guru Labs > > > Go to the policy directory and execute make enableaudit make load. Now try. This disables the dontaudit policy. Dan >-- >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 Wed Apr 28 15:57:29 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 Apr 2004 11:57:29 -0400 Subject: Access to cd device denied for cdp In-Reply-To: <1083030774.18163.22.camel@CirithUngol> References: <1083030774.18163.22.camel@CirithUngol> Message-ID: <408FD469.9040605@redhat.com> Andrew Farris wrote: >Playing a cd from the terminal using cdp, or cdplay (non-interactive), >results in the following avc in permissive mode (but the cd is allowed >to play): > >Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: >denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 >ino=66203 scontext=user_u:user_r:user_t >tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file > > Please put in a bugzilla. The problem is that /dev/hdc is labeled wrong. It should have a label of removable_disk_device_t. The problem is there is currently no good way of determining what cdrom disk is from a fixed disk, from a policy point of view. We are investigating ideas around using kudzu to relabel the devices. If you do a chcon -t removable_disk_device_t /dev/hdc does the problem go away? Dan >This is not audited in enforcing mode.. but does not work either >(program exits with "please chmod 666 /dev/cdrom as root"). >/dev/cdrom is symlinked directly to /dev/hdc. > >4.0K lrwxrwxrwx 1 0 0 8 Mar 29 17:26 /dev/cdrom -> /dev/hdc >4.0K brw-rw-rw- 1 0 6 22, 0 Feb 23 13:02 /dev/hdc > >Is this expected, or desired behavior? Shouldn't a locally logged in >user be allowed access to audio cds? (perhaps should be -or is- tunable) > >I'm working with policy-sources-1.11.2-13. > > From sopwith at redhat.com Wed Apr 28 16:09:53 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 28 Apr 2004 12:09:53 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: <200404281609.i3SG9rdS017524@ostrich-deluxe.devel.redhat.com> This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events fedora-list - For users of releases fedora-test-list - For testers of test releases fedora-devel-list - For developers, developers, developers fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From gene at czarc.net Wed Apr 28 16:49:09 2004 From: gene at czarc.net (Gene Czarcinski) Date: Wed, 28 Apr 2004 12:49:09 -0400 Subject: FC2-T3 selinux warning Message-ID: <200404281249.09244.gene@czarc.net> Install (fresh, everything) FC2-T3 seems to have some policy related problems: 1. /root/.default_contexts has wrong attribute (restorecon fixes it). 2. I seems to need to boot enforcing=0 for the firstboot (otherwise the display does not initialize properly). After updating to latest updates from development (including policy, policycoreutils, and libselinux): 1. trying to login a syadm_r user cannot find the home directory 2. creating new users definitiely assigns wrong attributes to /home/user/* Gene From gene at czarc.net Wed Apr 28 17:24:31 2004 From: gene at czarc.net (Gene Czarcinski) Date: Wed, 28 Apr 2004 13:24:31 -0400 Subject: FC2-T2 and selinux Message-ID: <200404281324.31866.gene@czarc.net> Let me empahsize -- please be sure to specify enforcing=0 for the first boot after install if you have installed with selinux "active". If you do not, the X configuration and firstboot get screwed up. I may be easier to just reinstall than trying to fix things. Gene From sds at epoch.ncsc.mil Wed Apr 28 17:35:27 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 28 Apr 2004 13:35:27 -0400 Subject: FC2-T2 and selinux In-Reply-To: <200404281324.31866.gene@czarc.net> References: <200404281324.31866.gene@czarc.net> Message-ID: <1083173726.25987.178.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-28 at 13:24, Gene Czarcinski wrote: > Let me empahsize -- please be sure to specify enforcing=0 for the first boot > after install if you have installed with selinux "active". > > If you do not, the X configuration and firstboot get screwed up. I may be > easier to just reinstall than trying to fix things. I was able to recover via fixfiles restore (and also purged /tmp to be sure). I also had problems with the X server starting due to erroneous file labels, but was able to login and run fixfiles, then rebooted and everything worked ok. I sent the output from fixfiles restore to Dan and Russell. -- Stephen Smalley National Security Agency From gene at czarc.net Wed Apr 28 19:30:10 2004 From: gene at czarc.net (Gene Czarcinski) Date: Wed, 28 Apr 2004 15:30:10 -0400 Subject: FC2-T2 and selinux In-Reply-To: <1083173726.25987.178.camel@moss-spartans.epoch.ncsc.mil> References: <200404281324.31866.gene@czarc.net> <1083173726.25987.178.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200404281530.10984.gene@czarc.net> On Wednesday 28 April 2004 13:35, Stephen Smalley wrote: > On Wed, 2004-04-28 at 13:24, Gene Czarcinski wrote: > > Let me empahsize -- please be sure to specify enforcing=0 for the first > > boot after install if you have installed with selinux "active". > > > > If you do not, the X configuration and firstboot get screwed up. I may > > be easier to just reinstall than trying to fix things. > > I was able to recover via fixfiles restore (and also purged /tmp to be > sure). I also had problems with the X server starting due to erroneous > file labels, but was able to login and run fixfiles, then rebooted and > everything worked ok. I sent the output from fixfiles restore to Dan > and Russell. >From the looks of things when I ran fixfiles, maybe firstboot needs to run it. Gene From aleksey at nogin.org Wed Apr 28 20:29:14 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 28 Apr 2004 13:29:14 -0700 Subject: AVC attaching gdb to Mozilla process. In-Reply-To: <1083154300.25987.44.camel@moss-spartans.epoch.ncsc.mil> References: <408F499C.9020100@nogin.org> <1083154300.25987.44.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4090141A.5060003@nogin.org> On 28.04.2004 05:11, Stephen Smalley wrote: > On Wed, 2004-04-28 at 02:05, Aleksey Nogin wrote: > >>Under policy-sources-1.11.2-18: >> >>audit(1083131647.146:0): avc: denied { signal } for pid=28661 >>exe=/usr/bin/gdb scontext=aleksey:staff_r:staff_mozilla_t >>tcontext=aleksey:staff_r:staff_t tclass=process > > > In general, you'd like to confine mozilla so that if it is subverted by > malicious code, then it can't do much harm. So allowing it to send > signals back to the user domain isn't desirable. For development > environments, you might want a policy tunable or boolean to allow such > permissions, but not for operational use. Note that exe is gdb, not mozilla. How did gdb end up in mozilla_t? -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From sds at epoch.ncsc.mil Wed Apr 28 21:21:34 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 28 Apr 2004 17:21:34 -0400 Subject: AVC attaching gdb to Mozilla process. In-Reply-To: <4090141A.5060003@nogin.org> References: <408F499C.9020100@nogin.org> <1083154300.25987.44.camel@moss-spartans.epoch.ncsc.mil> <4090141A.5060003@nogin.org> Message-ID: <1083187294.25987.226.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-28 at 16:29, Aleksey Nogin wrote: > Note that exe is gdb, not mozilla. How did gdb end up in mozilla_t? The pid and exe information doesn't necessarily correlate with the source context; it is just derived from the "current" process. For example, if gdb waits on mozilla, there is a mozilla-to-gdb signal check (typically sigchld when SIGCHLD is the exit signal but other signals are possible). -- Stephen Smalley National Security Agency From fedora at andrewfarris.com Wed Apr 28 22:05:19 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Wed, 28 Apr 2004 15:05:19 -0700 Subject: nVIDIA binary driver audits generated by OpenGL apps In-Reply-To: <408FD08B.9030000@redhat.com> References: <1083029984.18163.9.camel@CirithUngol> <408FD08B.9030000@redhat.com> Message-ID: <1083189918.30567.14.camel@CirithUngol> On Wed, 2004-04-28 at 11:40 -0400, Daniel J Walsh wrote: > Andrew Farris wrote: > > >I am working toward getting Enforcing mode to work with the nvidia > >binary drivers, and having some difficulties. I see that there is some > >policy with this intention , but it is not quite adequate yet, as below. > >Some hints how to proceed, or solutions to this would be appreciated. > >Running enforcing with /dev/nvidia* labeled as xserver_misc_device_t: > > > >Apr 26 17:13:59 CirithUngol kernel: audit(1083024839.937:0): avc: > >denied { read write } for pid=15200 exe=/usr/X11R6/bin/glxinfo > >name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t > >tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file > > > >Apr 26 17:14:04 CirithUngol kernel: audit(1083024844.641:0): avc: > >denied { read write } for pid=15209 exe=/usr/X11R6/bin/glxgears > >name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t > >tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file > >To relabel the devices I uncommented the definition of > >xserver_misc_device_t from ./types/device.te, and added the following > >line to ./file_contexts/program/xserver.fc (then make reload, followed > >by setfiles on these devices). > >/dev/nvidia.* system_u:object_r:xserver_misc_device_t > >And I rely on these (there are 4) lines in policy.conf after the make (I > >do not understand how these are generated yet). > >allow user_xserver_t xserver_misc_device_t:chr_file { ioctl read getattr > >lock write append }; > Did setting the context to > > xserver_misc_device_t > get it to work? > > Dan Sorry about the extra size email, it is confusing. Yes, running with the /dev/nvidia* devices labeled as xserver_misc_device_t will allow the X server to run and login.. etc. However it does NOT allow glxinfo or glxgears to run (they complain about access permissions to /dev/nvidiactl). I need policy that will allow user programs access { read write } to /dev/nvidiactl before any OpenGL apps will run with these drivers (the same issue happens for Quake3, AAOps.. not just these GL test tools). Perhaps the solution involves including each game in games.fc? The same problem may exist for running with the new nvidia dri software for OpenGL, I did not check yet, but will. If the problem does not exist for that then a similar setup for nvidiactl may work, I'm not sure. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From tmolina at cablespeed.com Wed Apr 28 22:42:46 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Wed, 28 Apr 2004 18:42:46 -0400 (EDT) Subject: Access to cd device denied for cdp In-Reply-To: <408FD469.9040605@redhat.com> References: <1083030774.18163.22.camel@CirithUngol> <408FD469.9040605@redhat.com> Message-ID: On Wed, 28 Apr 2004, Daniel J Walsh wrote: > Please put in a bugzilla. The problem is that /dev/hdc is labeled > wrong. It should have a label of removable_disk_device_t. > The problem is there is currently no good way of determining what cdrom > disk is from a fixed disk, from a policy point of > view. We are investigating ideas around using kudzu to relabel the devices. Please do not use that abomination called kudzu to determine policy. First off, userland tools have no place in determining policy in my opinion, especially not in the case of removable media. Secondly, I despise kudzu. It is an abomination which get removed forthwith from any system I maintain. From fedora at andrewfarris.com Thu Apr 29 00:53:16 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Wed, 28 Apr 2004 17:53:16 -0700 Subject: Access to cd device denied for cdp In-Reply-To: <408FD469.9040605@redhat.com> References: <1083030774.18163.22.camel@CirithUngol> <408FD469.9040605@redhat.com> Message-ID: <1083199996.25352.5.camel@CirithUngol> On Wed, 2004-04-28 at 11:57 -0400, Daniel J Walsh wrote: > Andrew Farris wrote: > > >Playing a cd from the terminal using cdp, or cdplay (non-interactive), > >results in the following avc in permissive mode (but the cd is allowed > >to play): > > > >Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: > >denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 > >ino=66203 scontext=user_u:user_r:user_t > >tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file > > > > > > Please put in a bugzilla. The problem is that /dev/hdc is labeled > wrong. It should have a label of removable_disk_device_t. > The problem is there is currently no good way of determining what cdrom > disk is from a fixed disk, from a policy point of > view. We are investigating ideas around using kudzu to relabel the devices. > > If you do a chcon -t removable_disk_device_t /dev/hdc > does the problem go away? > > Dan > >I'm working with policy-sources-1.11.2-13. Now working with policy-sources-1.11.2-18 and removable_disk_device_t is not a valid argument to chcon, however removable_device_t is, and when I relabel /dev/hdc such it does allow me to play the cd in enforcing mode, this is the solution. brw-rw-rw-+ root disk system_u:object_r:removable_device_t /dev/hdc I will add this to bugzilla if not there already today. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From nick-gray at austin.rr.com Thu Apr 29 02:16:54 2004 From: nick-gray at austin.rr.com (Nick) Date: Wed, 28 Apr 2004 21:16:54 -0500 Subject: Core 2 SELinux installation Message-ID: <1083205014.27417.49.camel@hawaii.efficax.net> >From the message titled 'Fedora Core 2 and SELinux' > SELinux *will* be included in Fedora Core 2 test 3 and the final > Fedora Core 2 release. However, SELinux will be disabled by default. > To install with SELinux support, pass 'selinux' to the installer > on the command line. (Or, configure it appropriately in kickstart). Why are we using the command line option to install SELinux process. I provided to the SEL list, a comp.xml skeleton that I used to add SEL to Core 1. In the original framework I just added dependencies that were not on the std Linux install (i.e. sharutils). A follow through to this could provide a separate selection within the group for policy tools and source to allow the installer to put the source in place as well (as shown in the category section below) selinux true true SELinux Installation Install this group of packages to configure the system for SELinux installation. sharutils linuxdoc-tools netpbm-progs tetex-latex autoconf213 elfutils-devel libcroco-devel SELinux selinux policy tools/source -- Nick Gray Senior Systems Engineer Bruzenak Inc. nagray at austin.rr.com (512) 331-7998 From nick-gray at austin.rr.com Thu Apr 29 02:27:52 2004 From: nick-gray at austin.rr.com (Nick) Date: Wed, 28 Apr 2004 21:27:52 -0500 Subject: Trying to get user modification tools and policy source Message-ID: <1083205671.27417.65.camel@hawaii.efficax.net> Conditions: Install from DVD Download of Tresys tools Installation of several RPMs that were needed to compile these tools yum update of system. Problem: I can't build the Tresys tools for user account modification. I had been doing this in the past: > #1. useradd -m developer > #2. passwd developer > #3. sed -i -e /user\ root/a\ user\ developer\ roles\ \{\ staff_r\ \ > sysadm_r\ \}\; /etc/security/selinux/src/policy/users > > #4. cd /etc/security/selinux/src/policy > #5. make policy > #6. make load I asked the SEL list about this and it was recommeded that I try Tresys setools? seuser, seuseradd?. Problem is, I can't build them I keep getting a message about TCL being in the wrong place? Anyone seen this? This is a new install, without deviations from what needs to be done initially. I would think this would be a pretty common problem I obviously can't do my old procedure since the policy source wasn't installed. Thanks Nix -- Nick Gray Senior Systems Engineer Bruzenak Inc. nagray at austin.rr.com (512) 331-7998 From katzj at redhat.com Thu Apr 29 02:43:48 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 Apr 2004 22:43:48 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083205014.27417.49.camel@hawaii.efficax.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> Message-ID: <1083206627.3949.13.camel@rivendell.local.net> On Wed, 2004-04-28 at 21:16 -0500, Nick wrote: > Why are we using the command line option to install SELinux process. I > provided to the SEL list, a comp.xml skeleton that I used to add SEL to > Core 1. The option has nothing to do with what packages get installed, it deals instead with if we set up such things as xattrs on the filesystem and whether policy will end up loading by default. Jeremy From fedora at andrewfarris.com Thu Apr 29 03:06:42 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Wed, 28 Apr 2004 20:06:42 -0700 Subject: Trying to get user modification tools and policy source In-Reply-To: <1083205671.27417.65.camel@hawaii.efficax.net> References: <1083205671.27417.65.camel@hawaii.efficax.net> Message-ID: <1083208001.25352.13.camel@CirithUngol> On Wed, 2004-04-28 at 21:27 -0500, Nick wrote: > I asked the SEL list about this and it was recommeded that I try Tresys > setools? seuser, seuseradd?. > > Problem is, I can't build them I keep getting a message about TCL being > in the wrong place? The setools and setools-gui packages are both available in Rawhide at the moment. Here are the latest packages from the www.kernel.org mirror. http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/setools-1.3-2.i386.rpm http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/setools-gui-1.3-2.i386.rpm -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From nagray at austin.rr.com Thu Apr 29 03:06:58 2004 From: nagray at austin.rr.com (Nick Gray) Date: Wed, 28 Apr 2004 22:06:58 -0500 Subject: Core 2 SELinux installation In-Reply-To: <1083206627.3949.13.camel@rivendell.local.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> Message-ID: <1083208018.27417.78.camel@hawaii.efficax.net> On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote: > On Wed, 2004-04-28 at 21:16 -0500, Nick wrote: > > Why are we using the command line option to install SELinux process. I > > provided to the SEL list, a comp.xml skeleton that I used to add SEL to > > Core 1. > > The option has nothing to do with what packages get installed, it deals > instead with if we set up such things as xattrs on the filesystem and > whether policy will end up loading by default Isn't all of that via packages? Isn't the kernel build during install from a source package? So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install? What about building a core 2 system without SELinux. Are we forcing users to use SEL if they are using Fedora in the future? > Jeremy > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From gene at czarc.net Thu Apr 29 05:30:38 2004 From: gene at czarc.net (Gene Czarcinski) Date: Thu, 29 Apr 2004 01:30:38 -0400 Subject: RFE: provide a command to display all roles available to a user Message-ID: <200404290130.38397.gene@czarc.net> OK, this got closed on bugzilla with the suggestion to bring it up for discussion on the mailing list. The problem: Currently, there is no way for a user to display what roles are available ... available for switching to via a newrole command. Solution: Provide a command to display the roles available to a user ... what roles could be specified for that user on a newroles command. Gene From nick-gray at austin.rr.com Thu Apr 29 10:23:26 2004 From: nick-gray at austin.rr.com (Nick) Date: Thu, 29 Apr 2004 05:23:26 -0500 Subject: Core 2 SELinux installation In-Reply-To: <1083206627.3949.13.camel@rivendell.local.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> Message-ID: <1083234205.27417.81.camel@hawaii.efficax.net> On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote: > On Wed, 2004-04-28 at 21:16 -0500, Nick wrote: > > Why are we using the command line option to install SELinux process. I > > provided to the SEL list, a comp.xml skeleton that I used to add SEL to > > Core 1. > > The option has nothing to do with what packages get installed, it deals > instead with if we set up such things as xattrs on the filesystem and > whether policy will end up loading by default Isn't all of that via packages? Isn't the kernel build during install from a source package? So your saying that the switch is just a way of setting the level that is currently set in the firewall screen of the install? What about building a core 2 system without SELinux. Are we forcing users to use SEL if they are using Fedora in the future? > Jeremy > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Nick Gray Senior Systems Engineer Bruzenak Inc. nagray at austin.rr.com (512) 331-7998 From mayerf at tresys.com Thu Apr 29 11:52:26 2004 From: mayerf at tresys.com (Frank Mayer) Date: Thu, 29 Apr 2004 07:52:26 -0400 Subject: provide a command to display all roles available to a user In-Reply-To: <200404290130.38397.gene@czarc.net> Message-ID: <003c01c42de0$70c83630$9e0c010a@columbia.tresys.com> > The problem: > > Currently, there is no way for a user to display what roles are > available ... available for switching to via a newrole command. > > Solution: > > Provide a command to display the roles available to a user ... what > roles could be specified for that user on a newroles command. If you have setools installed, then run 'seuser show roles' or 'seinfo -r'; seinfo is a more general purpose command. 'seuser users username' or 'seinfo -uusername -x' will show the authorized roles for username. Currently (as of v 1.3) these tools require policy sources to be installed to work (it uses the policy.conf file). Shortly (couple of weeks) we'll release v 1.4 which will allow our core library to work off binary policy files (which must always be present) breaking the requirement for policy sources (unless of course you plan to use seuser to add a user!). Frank From sds at epoch.ncsc.mil Thu Apr 29 11:56:16 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 29 Apr 2004 07:56:16 -0400 Subject: Trying to get user modification tools and policy source In-Reply-To: <1083205671.27417.65.camel@hawaii.efficax.net> References: <1083205671.27417.65.camel@hawaii.efficax.net> Message-ID: <1083239776.27820.5.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-28 at 22:27, Nick wrote: > I obviously can't do my old procedure since the policy source wasn't > installed. The Tresys setools depend on policy-sources, so you'll still need them anyway. yum install checkpolicy policy-sources. IMHO, they should be installed by default unless someone explicitly chooses minimal install. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Apr 29 13:20:24 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 29 Apr 2004 09:20:24 -0400 Subject: nVIDIA binary driver audits generated by OpenGL apps In-Reply-To: <1083189918.30567.14.camel@CirithUngol> References: <1083029984.18163.9.camel@CirithUngol> <408FD08B.9030000@redhat.com> <1083189918.30567.14.camel@CirithUngol> Message-ID: <40910118.8060900@redhat.com> Andrew Farris wrote: >On Wed, 2004-04-28 at 11:40 -0400, Daniel J Walsh wrote: > > >>Andrew Farris wrote: >> >> >> >>>I am working toward getting Enforcing mode to work with the nvidia >>>binary drivers, and having some difficulties. I see that there is some >>>policy with this intention , but it is not quite adequate yet, as below. >>>Some hints how to proceed, or solutions to this would be appreciated. >>>Running enforcing with /dev/nvidia* labeled as xserver_misc_device_t: >>> >>>Apr 26 17:13:59 CirithUngol kernel: audit(1083024839.937:0): avc: >>>denied { read write } for pid=15200 exe=/usr/X11R6/bin/glxinfo >>>name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t >>>tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file >>> >>>Apr 26 17:14:04 CirithUngol kernel: audit(1083024844.641:0): avc: >>>denied { read write } for pid=15209 exe=/usr/X11R6/bin/glxgears >>>name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t >>>tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file >>> >>> > > > >>>To relabel the devices I uncommented the definition of >>>xserver_misc_device_t from ./types/device.te, and added the following >>>line to ./file_contexts/program/xserver.fc (then make reload, followed >>>by setfiles on these devices). >>>/dev/nvidia.* system_u:object_r:xserver_misc_device_t >>> >>> > > > >>>And I rely on these (there are 4) lines in policy.conf after the make (I >>>do not understand how these are generated yet). >>>allow user_xserver_t xserver_misc_device_t:chr_file { ioctl read getattr >>>lock write append }; >>> >>> > > > >>Did setting the context to >> >>xserver_misc_device_t >>get it to work? >> >>Dan >> >> > >Sorry about the extra size email, it is confusing. Yes, running with >the /dev/nvidia* devices labeled as xserver_misc_device_t will allow the >X server to run and login.. etc. However it does NOT allow glxinfo or >glxgears to run (they complain about access permissions >to /dev/nvidiactl). I need policy that will allow user programs access >{ read write } to /dev/nvidiactl before any OpenGL apps will run with >these drivers (the same issue happens for Quake3, AAOps.. not just these >GL test tools). > >Perhaps the solution involves including each game in games.fc? > >The same problem may exist for running with the new nvidia dri software >for OpenGL, I did not check yet, but will. If the problem does not >exist for that then a similar setup for nvidiactl may work, I'm not >sure. > > Not sure of the security ramifications, but does adding the following fix your problem? This might need to be a tunable. diff -u base_user_macros.te~ base_user_macros.te --- base_user_macros.te~ 2004-04-29 09:18:03.882721648 -0400 +++ base_user_macros.te 2004-04-29 09:18:58.802372592 -0400 @@ -250,6 +250,9 @@ ')dnl end ifdef xdm.te +# Access the special XServer devices. +allow $1_t xserver_misc_device_t:chr_file rw_file_perms; + # Access the sound device. allow $1_t sound_device_t:chr_file { getattr read write ioctl }; From mayerf at tresys.com Thu Apr 29 13:28:16 2004 From: mayerf at tresys.com (Frank Mayer) Date: Thu, 29 Apr 2004 09:28:16 -0400 Subject: Trying to get user modification tools and policy source In-Reply-To: <1083239776.27820.5.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <004e01c42ded$d41d0ff0$9e0c010a@columbia.tresys.com> > > The Tresys setools depend on policy-sources, so you'll still need them > anyway. yum install checkpolicy policy-sources. IMHO, they should be > installed by default unless someone explicitly chooses minimal > install. As I just noted on another thread, in the next couple of weeks we will release v1.4 of setools that will enable our core library to work directly off the policy binary. For the tools that just look at the policy (seinfo, apol, sesearch,...), the dependency on policy sources will no longer be required. Of course to change the policy (e.g., seuseradd) policy sources will still be required but we're hoping that dependency will be eliminated (or mitigated) following release of the policy binary module infrastructure due out later this summer. Frank From katzj at redhat.com Thu Apr 29 15:05:05 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 Apr 2004 11:05:05 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083208018.27417.78.camel@hawaii.efficax.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> Message-ID: <1083251105.3949.32.camel@rivendell.local.net> On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote: > On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote: > > On Wed, 2004-04-28 at 21:16 -0500, Nick wrote: > > > Why are we using the command line option to install SELinux process. I > > > provided to the SEL list, a comp.xml skeleton that I used to add SEL to > > > Core 1. > > > > The option has nothing to do with what packages get installed, it deals > > instead with if we set up such things as xattrs on the filesystem and > > whether policy will end up loading by default > > Isn't all of that via packages? It's based on information in packages, but it's influenced also by _how_ the packages are installed. Not by which packages are actually being installed. ie, what %__file_context_path is set to for RPM and thus whether contexts are set on files as they're laid down on the filesystem. Also, what ends up in /etc/sysconfig/selinux which gets looked at by init to determine whether policy should be loaded or not. > Isn't the kernel build during install from a source package? Ummm, no. This would a) require the installation of a compiler and b) make the install time much longer, especially on older hardware. > So your saying that the switch is just a way of setting the level that > is currently set in the firewall screen of the install? Whether or not the control is even shown. SELinux is not at this point something that is going to be suitable for all users -- this will change over time, but right now avoiding having the users who don't know better from getting into trouble is a good idea just to cut down on the support burden. > What about building a core 2 system without SELinux. Are we forcing > users to use SEL if they are using Fedora in the future? No, there's nothing that forces you to use SELinux. There are things that depend on libselinux, but that doesn't mean that you're actually using SELinux. Jeremy From nick-gray at austin.rr.com Thu Apr 29 16:35:33 2004 From: nick-gray at austin.rr.com (Nick) Date: Thu, 29 Apr 2004 11:35:33 -0500 Subject: Core 2 SELinux installation In-Reply-To: <1083251105.3949.32.camel@rivendell.local.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> Message-ID: <1083256533.27417.156.camel@hawaii.efficax.net> On Thu, 2004-04-29 at 10:05, Jeremy Katz wrote: > On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote: > > On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote: > > > On Wed, 2004-04-28 at 21:16 -0500, Nick wrote: > > > > Why are we using the command line option to install SELinux process. I > > > > provided to the SEL list, a comp.xml skeleton that I used to add SEL to > > > > Core 1. > > > > > > The option has nothing to do with what packages get installed, it deals > > > instead with if we set up such things as xattrs on the filesystem and > > > whether policy will end up loading by default > > > > Isn't all of that via packages? > > It's based on information in packages, but it's influenced also by _how_ > the packages are installed. Not by which packages are actually being > installed. ie, what %__file_context_path is set to for RPM and thus > whether contexts are set on files as they're laid down on the > filesystem. Also, what ends up in /etc/sysconfig/selinux which gets > looked at by init to determine whether policy should be loaded or not. This seems like semantics, you won't need to set xattrs, setup a /selinux directory, or access any of the selinux packages if you are given the option not to install SEL. My original point addresses an issue with the switch setting. I believe that the switch is the wrong way to implement this > > Isn't the kernel build during install from a source package? > > Ummm, no. This would a) require the installation of a compiler and b) > make the install time much longer, especially on older hardware. I vaguely recall this. So the default kernels must be pretty large to contain all of the modules, etc, for each option (Bluetooth etc.. ). > > So your saying that the switch is just a way of setting the level that > > is currently set in the firewall screen of the install? > > Whether or not the control is even shown. SELinux is not at this point > something that is going to be suitable for all users -- this will change > over time, but right now avoiding having the users who don't know better > from getting into trouble is a good idea just to cut down on the support > burden. I still think you are missing my point. Is the SELinux kernel installed by default and directories such as '/etc/security' created even if the switch is off? Assuming for the moment that selecting the switch during the install, prevents any trace of SEL from showing on the system, why do it via switch? Why not use the installation menu and leave the SELinux portion disabled by default? Making the other assumption that all the binaries/directories are installed, and just not enabled. I think those of us who need to have this accredited are going to have a tough time with the distinction of installed but not used. The selection should let you go down one of two paths, installed or not installed. The distinction needs to be pristine if those of us who need this for secure implementations are going to present it > > What about building a core 2 system without SELinux. Are we forcing > > users to use SEL if they are using Fedora in the future? > > No, there's nothing that forces you to use SELinux. There are things > that depend on libselinux, but that doesn't mean that you're actually > using SELinux. See above > Jeremy > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Nick Gray Senior Systems Engineer Bruzenak Inc. nagray at austin.rr.com (512) 331-7998 From nagray at austin.rr.com Thu Apr 29 16:23:22 2004 From: nagray at austin.rr.com (Nick Gray) Date: Thu, 29 Apr 2004 11:23:22 -0500 Subject: Core 2 SELinux installation In-Reply-To: <1083251105.3949.32.camel@rivendell.local.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> Message-ID: <1083255798.27417.149.camel@hawaii.efficax.net> On Thu, 2004-04-29 at 10:05, Jeremy Katz wrote: > On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote: > > On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote: > > > On Wed, 2004-04-28 at 21:16 -0500, Nick wrote: > > > > Why are we using the command line option to install SELinux process. I > > > > provided to the SEL list, a comp.xml skeleton that I used to add SEL to > > > > Core 1. > > > > > > The option has nothing to do with what packages get installed, it deals > > > instead with if we set up such things as xattrs on the filesystem and > > > whether policy will end up loading by default > > > > Isn't all of that via packages? > > It's based on information in packages, but it's influenced also by _how_ > the packages are installed. Not by which packages are actually being > installed. ie, what %__file_context_path is set to for RPM and thus > whether contexts are set on files as they're laid down on the > filesystem. Also, what ends up in /etc/sysconfig/selinux which gets > looked at by init to determine whether policy should be loaded or not. This seems like semantics, you won't need to set xattrs, setup a /selinux directory, or access any of the selinux packages if you are given the option not to install SEL. My original point addresses an issue with the switch setting. I believe that the switch is the wrong way to implement this > > Isn't the kernel build during install from a source package? > > Ummm, no. This would a) require the installation of a compiler and b) > make the install time much longer, especially on older hardware. I vaguely recall this. So the default kernels must be pretty large to contain all of the modules, etc, for each option (Bluetooth etc.. ). > > So your saying that the switch is just a way of setting the level that > > is currently set in the firewall screen of the install? > > Whether or not the control is even shown. SELinux is not at this point > something that is going to be suitable for all users -- this will change > over time, but right now avoiding having the users who don't know better > from getting into trouble is a good idea just to cut down on the support > burden. I still think you are missing my point. Is the SELinux kernel installed by default and directories such as '/etc/security' created even if the switch is off? Assuming for the moment that selecting the switch during the install, prevents any trace of SEL from showing on the system, why do it via switch? Why not use the installation menu and leave the SELinux portion disabled by default? Making the other assumption that all the binaries/directories are installed, and just not enabled. I think those of us who need to have this accredited are going to have a tough time with the distinction of installed but not used. The selection should let you go down one of two paths, installed or not installed. The distinction needs to be pristine if those of us who need this for secure implementations are going to present it > > What about building a core 2 system without SELinux. Are we forcing > > users to use SEL if they are using Fedora in the future? > > No, there's nothing that forces you to use SELinux. There are things > that depend on libselinux, but that doesn't mean that you're actually > using SELinux. See above > Jeremy > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From nick-gray at austin.rr.com Thu Apr 29 18:10:22 2004 From: nick-gray at austin.rr.com (Nick) Date: Thu, 29 Apr 2004 13:10:22 -0500 Subject: Problem with Tresys tools on Core 2 Message-ID: <1083262222.27417.163.camel@hawaii.efficax.net> Conditions: ----------- Install from DVD ISO yum upgrade installation of RPMS checkpolicy-1.10-1.i386.rpm policy-sources-1.11.2-18.noarch.rpm setools-1.3-2.i386.rpm setools-gui-1.3-2.i386.rpm Results ------- [root at rocket policy]# seinfo -r Could not open policy! [root at rocket policy]# seuser -X Error in StartScript (/usr/share/setools/se_user.tcl): Thanks Nick -- Nick Gray Senior Systems Engineer Bruzenak Inc. nagray at austin.rr.com (512) 331-7998 From nick-gray at austin.rr.com Thu Apr 29 23:10:24 2004 From: nick-gray at austin.rr.com (Nick) Date: Thu, 29 Apr 2004 18:10:24 -0500 Subject: Problem with Tresys tools on Core 2 In-Reply-To: <1083262222.27417.163.camel@hawaii.efficax.net> References: <1083262222.27417.163.camel@hawaii.efficax.net> Message-ID: <1083280223.5793.4.camel@hawaii.efficax.net> On Thu, 2004-04-29 at 13:10, Nick wrote: > Conditions: > ----------- > > Install from DVD ISO > yum upgrade > installation of RPMS > checkpolicy-1.10-1.i386.rpm > policy-sources-1.11.2-18.noarch.rpm > setools-1.3-2.i386.rpm > setools-gui-1.3-2.i386.rpm > > > Results > ------- > > [root at rocket policy]# seinfo -r > Could not open policy! I rebuilt and now seinfo -r works. > [root at rocket policy]# seuser -X > Error in StartScript (/usr/share/setools/se_user.tcl): This still does not work > Thanks Nick -- Nick Gray Senior Systems Engineer Bruzenak Inc. nagray at austin.rr.com (512) 331-7998 From fedora at andrewfarris.com Fri Apr 30 00:21:13 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Thu, 29 Apr 2004 17:21:13 -0700 Subject: nVIDIA binary driver audits generated by OpenGL apps In-Reply-To: <40910118.8060900@redhat.com> References: <1083029984.18163.9.camel@CirithUngol> <408FD08B.9030000@redhat.com> <1083189918.30567.14.camel@CirithUngol> <40910118.8060900@redhat.com> Message-ID: <1083284472.22563.19.camel@CirithUngol> On Thu, 2004-04-29 at 09:20 -0400, Daniel J Walsh wrote: > Andrew Farris wrote: > >On Wed, 2004-04-28 at 11:40 -0400, Daniel J Walsh wrote: > >>Andrew Farris wrote: > >>>I am working toward getting Enforcing mode to work with the nvidia > >>>binary drivers, and having some difficulties. I see that there is some > >>>policy with this intention , but it is not quite adequate yet, as below. > >>>Some hints how to proceed, or solutions to this would be appreciated. > >>>Running enforcing with /dev/nvidia* labeled as xserver_misc_device_t: > >>> > >>>Apr 26 17:13:59 CirithUngol kernel: audit(1083024839.937:0): avc: > >>>denied { read write } for pid=15200 exe=/usr/X11R6/bin/glxinfo > >>>name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t > >>>tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file > >>> > >>>Apr 26 17:14:04 CirithUngol kernel: audit(1083024844.641:0): avc: > >>>denied { read write } for pid=15209 exe=/usr/X11R6/bin/glxgears > >>>name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t > >>>tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file > >Sorry about the extra size email, it is confusing. Yes, running with > >the /dev/nvidia* devices labeled as xserver_misc_device_t will allow the > >X server to run and login.. etc. However it does NOT allow glxinfo or > >glxgears to run (they complain about access permissions > >to /dev/nvidiactl). I need policy that will allow user programs access > >{ read write } to /dev/nvidiactl before any OpenGL apps will run with > >these drivers (the same issue happens for Quake3, AAOps.. not just these > >GL test tools). > > > Not sure of the security ramifications, but does adding the following > fix your problem? This might > need to be a tunable. > > > diff -u base_user_macros.te~ base_user_macros.te > --- base_user_macros.te~ 2004-04-29 09:18:03.882721648 -0400 > +++ base_user_macros.te 2004-04-29 09:18:58.802372592 -0400 > @@ -250,6 +250,9 @@ > > ')dnl end ifdef xdm.te > > +# Access the special XServer devices. > +allow $1_t xserver_misc_device_t:chr_file rw_file_perms; > + > # Access the sound device. > allow $1_t sound_device_t:chr_file { getattr read write ioctl }; Yes, this does fix the problem, although in my case this last change only really needed to apply to /dev/nvidiactl, and not the whole set of /dev/nvidia* device nodes. If it is worth the bloat, another type could be used for the single node. For a desktop or workstation system, which should be the ONLY systems running these closed source drivers, the security issues are probably minimal -- Although the system could be brought down by these drivers, having no source to the encrypted driver would probably make it difficult to exploit. Is this a minor issue? It would be very nice if this were tunable, so that the policy would enable the device type, label the devices, and allow this access. A similar problem may exist for the ATI closed source drivers as well. What I have done (including your latest) is summarized below: 1) create type xserver_misc_device_t in types/devices.te 2) add entry to label the devices in file_contexts/program/xserver.fc 3) uncomment access to the devices in macros/program/xserver_macros.te 4) add above patch to base_user_macros.te to allow user access If anyone is following along and would like to check if this works for their setup as well, the patch below can be applied with: cd /etc/security/selinux/src/policy patch -p1 < /path/to/saved/diff-file patch to test this first workaround available at: http://webpages.charter.net/cirithungol/fedora/policy-nvidia-dev.patch -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From lamont at gurulabs.com Fri Apr 30 00:36:41 2004 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 29 Apr 2004 18:36:41 -0600 Subject: Access to cd device denied for cdp In-Reply-To: References: <1083030774.18163.22.camel@CirithUngol> <408FD469.9040605@redhat.com> Message-ID: <1083285401.3190.22.camel@wraith.lrp.advansoft.us> On Wed, 2004-04-28 at 16:42, Thomas Molina wrote: > Please do not use that abomination called kudzu to determine policy. > > First off, userland tools have no place in determining policy in my > opinion, especially not in the case of removable media. > > Secondly, I despise kudzu. It is an abomination which get removed > forthwith from any system I maintain. Oh, come on now, Thomas, please, don't hold back; tell us how you really feel :-). Seriously, though, I am curious to know what is wrong, here. Aside from the fact that kudzu is for hardware detection and SELinux is not hardware, why is kudzu (in your opinion) is so "evil"? That question asked, I have to say that I am inclined to think that as long as kudzu is around in a system with SELinux, we are going to have to accept the need for it (kudzu) to work withing that (SELinux) environment. I do not yet agree that there is need for kudzu to alter policies, but I am going to reserve judgment until after further discussion. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. http://www.GuruLabs.com/ -------------- 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 katzj at redhat.com Fri Apr 30 02:51:52 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 Apr 2004 22:51:52 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083256533.27417.156.camel@hawaii.efficax.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> Message-ID: <1083293511.2791.6.camel@rivendell.local.net> On Thu, 2004-04-29 at 11:35 -0500, Nick wrote: > On Thu, 2004-04-29 at 10:05, Jeremy Katz wrote: > > On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote: > > > On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote: > > > > On Wed, 2004-04-28 at 21:16 -0500, Nick wrote: > > > > > Why are we using the command line option to install SELinux process. I > > > > > provided to the SEL list, a comp.xml skeleton that I used to add SEL to > > > > > Core 1. > > > > > > > > The option has nothing to do with what packages get installed, it deals > > > > instead with if we set up such things as xattrs on the filesystem and > > > > whether policy will end up loading by default > > > > > > Isn't all of that via packages? > > > > It's based on information in packages, but it's influenced also by _how_ > > the packages are installed. Not by which packages are actually being > > installed. ie, what %__file_context_path is set to for RPM and thus > > whether contexts are set on files as they're laid down on the > > filesystem. Also, what ends up in /etc/sysconfig/selinux which gets > > looked at by init to determine whether policy should be loaded or not. > > This seems like semantics, you won't need to set xattrs, setup a > /selinux directory, or access any of the selinux packages if you are > given the option not to install SEL. But you *have* to install some SELinux packages. eg, libselinux is always going to end up being installed due to dependencies of other packages. And doing an 'Everything' install (although I hate them) also shouldn't necessarily imply that you want SELinux enabled and setup. > > > Isn't the kernel build during install from a source package? > > > > Ummm, no. This would a) require the installation of a compiler and b) > > make the install time much longer, especially on older hardware. > > I vaguely recall this. So the default kernels must be pretty large to > contain all of the modules, etc, for each option (Bluetooth etc.. ). Yes, the kernel package is not small and contains many, many modules. > > > So your saying that the switch is just a way of setting the level that > > > is currently set in the firewall screen of the install? > > > > Whether or not the control is even shown. SELinux is not at this point > > something that is going to be suitable for all users -- this will change > > over time, but right now avoiding having the users who don't know better > > from getting into trouble is a good idea just to cut down on the support > > burden. > > I still think you are missing my point. Is the SELinux kernel installed > by default and directories such as '/etc/security' created even if the > switch is off? The kernel includes the support and the directories are created, but without policy being loaded, etc, there isn't an impact. Okay, that's not 100% true. There was a performance hit due to some additional hooks being added, but with recent kernel changes, you can unregister on the fly and so init will now do that if it's not loading a policy and thus mitigate that. > Assuming for the moment that selecting the switch during the install, > prevents any trace of SEL from showing on the system, why do it via > switch? Why not use the installation menu and leave the SELinux portion > disabled by default? Because there's not a way to give enough information on what all of the ramifications are. And with the current state of things, it's thus best to make it an option for people who know what they're doing. > Making the other assumption that all the binaries/directories are > installed, and just not enabled. I think those of us who need to have > this accredited are going to have a tough time with the distinction of > installed but not used. The selection should let you go down one of two > paths, installed or not installed. The distinction needs to be pristine > if those of us who need this for secure implementations are going to > present it It's not that hard. Take a look at is_selinux_enabled() in libselinux for the way to determine this. And even that's not even enough if you're wanting to make some sort of "guarantee" on the security of the system -- what your policy is directly defines this. SELinux itself is just a framework to provide the capability for having a secure implementation. Jeremy From 1 at 234.cx Fri Apr 30 09:40:05 2004 From: 1 at 234.cx (Pete Chown) Date: Fri, 30 Apr 2004 10:40:05 +0100 Subject: Core 2 SELinux installation In-Reply-To: <1083293511.2791.6.camel@rivendell.local.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> Message-ID: <40921EF5.7020207@234.cx> Jeremy Katz wrote: > But you *have* to install some SELinux packages. eg, libselinux is > always going to end up being installed due to dependencies of other > packages. Incidentally Fedora 1 has a similar situation. If you want Postgres, you have to install krb5-libs, even if you aren't using Kerberos. If you are going to ship binary packages, you have to turn on all the options that anyone could want. I guess taken to extremes it would increase bloat unacceptably, but krb5-libs and the user space SELinux libraries are not large. > Because there's not a way to give enough information on what all of > the ramifications are [of installing SELinux]. And with the current > state of things, it's thus best to make it an option for people who > know what they're doing. I think this is especially true for a new security technology. Most people's view of security is quite simplistic: they want the bad guys kept out, without their work being interfered with. If SELinux interferes with their work, they will turn it off, reasoning that normal Unix security has kept the bad guys out so far. They are then unlikely to try it again later however much people tell them that the policy has been improved. Pete From tmolina at cablespeed.com Fri Apr 30 10:23:44 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Fri, 30 Apr 2004 06:23:44 -0400 (EDT) Subject: Access to cd device denied for cdp In-Reply-To: <1083285401.3190.22.camel@wraith.lrp.advansoft.us> References: <1083030774.18163.22.camel@CirithUngol> <408FD469.9040605@redhat.com> <1083285401.3190.22.camel@wraith.lrp.advansoft.us> Message-ID: On Thu, 29 Apr 2004, Lamont R. Peterson wrote: > On Wed, 2004-04-28 at 16:42, Thomas Molina wrote: > > Please do not use that abomination called kudzu to determine policy. > > > > First off, userland tools have no place in determining policy in my > > opinion, especially not in the case of removable media. > > > > Secondly, I despise kudzu. It is an abomination which get removed > > forthwith from any system I maintain. > > Oh, come on now, Thomas, please, don't hold back; tell us how you really > feel :-). > > Seriously, though, I am curious to know what is wrong, here. Aside from > the fact that kudzu is for hardware detection and SELinux is not > hardware, why is kudzu (in your opinion) is so "evil"? All hyperbole aside, it is a userland tool which has the potential to affect policy with unintended consequences. I have seen it mess up hardware detection enough that I don't don't trust it. While there is a need for a hardware detection tool for setting up a system, I don't believe it is something which needs to be run as a background daemon as RedHat has it set up. We have hotplug and friends for USB and those parts of the system designed to have components dynamically added and removed. From sds at epoch.ncsc.mil Fri Apr 30 12:34:44 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 30 Apr 2004 08:34:44 -0400 Subject: Core 2 SELinux installation In-Reply-To: <40921EF5.7020207@234.cx> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> Message-ID: <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-30 at 05:40, Pete Chown wrote: > I think this is especially true for a new security technology. Most > people's view of security is quite simplistic: they want the bad guys > kept out, without their work being interfered with. If SELinux > interferes with their work, they will turn it off, reasoning that normal > Unix security has kept the bad guys out so far. They are then unlikely > to try it again later however much people tell them that the policy has > been improved. So how would people feel about a separate relaxed policy that allows everything in the system to run completely unconfined except for a small set of specific services, e.g. apache, bind, postfix, ... That would ensure that SELinux wouldn't get in the way of users, while providing some protection benefit for network-facing services. -- Stephen Smalley National Security Agency From katzj at redhat.com Fri Apr 30 13:24:31 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Apr 2004 09:24:31 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1083331471.4710.2.camel@rivendell.local.net> On Fri, 2004-04-30 at 08:34 -0400, Stephen Smalley wrote: > So how would people feel about a separate relaxed policy that allows > everything in the system to run completely unconfined except for a small > set of specific services, e.g. apache, bind, postfix, ... > That would ensure that SELinux wouldn't get in the way of users, while > providing some protection benefit for network-facing services. I think (consistent with my view a few months ago :-) that this is a very good idea. At the same time, it's something that's clearly not realistic to target for FC2 since the last test release just went out and so it'd be going out with very little testing. Jeremy From brugolsky at telemetry-investments.com Fri Apr 30 13:33:56 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 30 Apr 2004 09:33:56 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040430133356.GA29325@ti64.telemetry-investments.com> On Fri, Apr 30, 2004 at 08:34:44AM -0400, Stephen Smalley wrote: > So how would people feel about a separate relaxed policy that allows > everything in the system to run completely unconfined except for a small > set of specific services, e.g. apache, bind, postfix, ... > That would ensure that SELinux wouldn't get in the way of users, while > providing some protection benefit for network-facing services. While I think that a relaxed policy might be useful to server admins who would rather not fix their admin scripts, etc., the full policy ought not be terribly burdensome on a dedicated server. It is on the desktop that SELinux potentially offers the greatest benefit and the greatest burden. Client apps (and particularly GUI client apps) -- browser, e-mail, IM, media players, will be targeted. We laugh at poor MS Outlook users, but social engineering works. A measurable fraction of Linux users will inevitably read their e-mail and follow that link, look at that picture or video clip, play that game applet, etc. It is the client apps that need confinement. While exploiting a client app doesn't immediately give the attacker admin privileges, that's largely irrelevant if the purpose of the attack is to (1) harvest, destroy, or modify the user's data, or (2) use the client at a zombie for some purpose. Confining Postfix and not Mozilla is like double-locking the front door, but leaving the bathroom window open. Regards, Bill Rugolsky From kmacmillan at tresys.com Fri Apr 30 14:01:23 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Fri, 30 Apr 2004 10:01:23 -0400 Subject: Problem with Tresys tools on Core 2 In-Reply-To: <1083280223.5793.4.camel@hawaii.efficax.net> Message-ID: <200404301400.i3UE0mJx024222@gotham.columbia.tresys.com> Nick, Seuser looks for the policy.conf file in /etc/security/selinux/src by default, but it seems that some systems only have the policy.conf file in /etc/security/selinux/src/policy (note the extra policy directory at the end). If that is the case on your system, in the file /usr/share/setools/seuser.conf change the line: policy.conf /etc/security/selinux/src/policy.conf to policy.conf /etc/security/selinux/src/policy/policy.conf On my Fedora Core 2 test 2 system the policy.conf is in both locations - anyone know which is the location for default installs of Fedora Core 2? Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Nick > Sent: Thursday, April 29, 2004 7:10 PM > To: fedora-selinux-list at redhat.com > Subject: Re: Problem with Tresys tools on Core 2 > > On Thu, 2004-04-29 at 13:10, Nick wrote: > > Conditions: > > ----------- > > > > Install from DVD ISO > > yum upgrade > > installation of RPMS > > checkpolicy-1.10-1.i386.rpm > > policy-sources-1.11.2-18.noarch.rpm > > setools-1.3-2.i386.rpm > > setools-gui-1.3-2.i386.rpm > > > > > > Results > > ------- > > > > [root at rocket policy]# seinfo -r > > Could not open policy! > > I rebuilt and now seinfo -r works. > > > [root at rocket policy]# seuser -X > > Error in StartScript (/usr/share/setools/se_user.tcl): > > This still does not work > > > Thanks Nick > -- > Nick Gray > Senior Systems Engineer > Bruzenak Inc. > nagray at austin.rr.com > (512) 331-7998 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at epoch.ncsc.mil Fri Apr 30 14:02:32 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 30 Apr 2004 10:02:32 -0400 Subject: Core 2 SELinux installation In-Reply-To: <20040430133356.GA29325@ti64.telemetry-investments.com> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <20040430133356.GA29325@ti64.telemetry-investments.com> Message-ID: <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-30 at 09:33, Bill Rugolsky Jr. wrote: > While I think that a relaxed policy might be useful to server admins who > would rather not fix their admin scripts, etc., the full policy ought not > be terribly burdensome on a dedicated server. > > It is on the desktop that SELinux potentially offers the greatest benefit > and the greatest burden. Client apps (and particularly GUI client apps) -- > browser, e-mail, IM, media players, will be targeted. We laugh at poor > MS Outlook users, but social engineering works. A measurable fraction of > Linux users will inevitably read their e-mail and follow that link, > look at that picture or video clip, play that game applet, etc. It > is the client apps that need confinement. > > While exploiting a client app doesn't immediately give the attacker > admin privileges, that's largely irrelevant if the purpose of the > attack is to (1) harvest, destroy, or modify the user's data, or (2) > use the client at a zombie for some purpose. > > Confining Postfix and not Mozilla is like double-locking the front door, > but leaving the bathroom window open. And yet the default tunable settings in the Fedora policy effectively undo much of the benefit of the example mozilla policy (see 'readhome' and 'writehome'). Yes, you can change those tunable settings. But offering a separate relaxed policy doesn't mean that you can no longer choose a strict policy; it just means that the relaxed policy can be greatly simplified (as you can collapse many domains and types together), will be much easier to get right (thus avoiding users disabling SELinux entirely), and won't keep "leaking" weakness into the strict policy. It also makes the choice clear to users. SELinux provides flexible support for security policies in recognition of the fact that a single policy won't meet everyone's desires or needs. Forcing everyone to use a single security policy (even a single policy with small variations via tunables) runs counter to the point, and seems to be leading to SELinux disabled by default. That will ultimately lead to ever greater divergence and compatibility issues between the SELinux-enabled state and the SELinux-disabled state, effectively yielding two different systems like the old trusted vs. mainstream product separation of old. Better to have SELinux enabled all the time with two different policies that are appropriately tuned to the needs and desires of differing user communities. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Apr 30 14:03:51 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 30 Apr 2004 10:03:51 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083331471.4710.2.camel@rivendell.local.net> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <1083331471.4710.2.camel@rivendell.local.net> Message-ID: <1083333831.30875.74.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-30 at 09:24, Jeremy Katz wrote: > I think (consistent with my view a few months ago :-) that this is a > very good idea. At the same time, it's something that's clearly not > realistic to target for FC2 since the last test release just went out > and so it'd be going out with very little testing. That's fine; it can always be introduced post-FC2. It matters little for FC2 given that SELinux will be disabled by default for it anyway. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Apr 30 14:07:31 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 30 Apr 2004 10:07:31 -0400 Subject: Problem with Tresys tools on Core 2 In-Reply-To: <200404301400.i3UE0mJx024222@gotham.columbia.tresys.com> References: <200404301400.i3UE0mJx024222@gotham.columbia.tresys.com> Message-ID: <1083334050.30875.80.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-30 at 10:01, Karl MacMillan wrote: > On my Fedora Core 2 test 2 system the policy.conf is in both locations - > anyone know which is the location for default installs of Fedora Core 2? It is only under /etc/security/selinux/src/policy now, as noted in an earlier discussion. -- Stephen Smalley National Security Agency From 1 at 234.cx Fri Apr 30 14:12:22 2004 From: 1 at 234.cx (Pete Chown) Date: Fri, 30 Apr 2004 15:12:22 +0100 Subject: Core 2 SELinux installation In-Reply-To: <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <40925EC6.9020909@234.cx> Stephen Smalley wrote: > So how would people feel about a separate relaxed policy that allows > everything in the system to run completely unconfined except for a small > set of specific services, e.g. apache, bind, postfix, ... This sounds like a big change of direction, but I think it would be useful for servers. It would also be a good starting point for people developing their own policies. It might also be good to introduce SELinux gradually, taking the easy security gains first. It's comparatively easy to isolate things like Apache, so one approach would be to take that improvement while continuing to work on the rest. Has anyone attempted to add type enforcement to a commercial desktop operating system before? I haven't heard of it being done; as far as I know the various distros' SELinux projects are breaking new ground. That is probably one reason why it is turning up more problems than expected. Pete From lists at ebourne.me.uk Fri Apr 30 14:16:44 2004 From: lists at ebourne.me.uk (Martin Ebourne) Date: Fri, 30 Apr 2004 15:16:44 +0100 Subject: Core 2 SELinux installation In-Reply-To: <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1083334603.15201.3.camel@baade.ebourne.me.uk> On Fri, 2004-04-30 at 13:34, Stephen Smalley wrote: > So how would people feel about a separate relaxed policy that allows > everything in the system to run completely unconfined except for a small > set of specific services, e.g. apache, bind, postfix, ... > That would ensure that SELinux wouldn't get in the way of users, while > providing some protection benefit for network-facing services. I think that would be very worthwhile, and would probably speed uptake of SELinux on Fedora. I for one would happily switch that on asap and then gradually move to something more secure when it was much more polished. Cheers, Martin. From kmacmillan at tresys.com Fri Apr 30 14:23:19 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Fri, 30 Apr 2004 10:23:19 -0400 Subject: Problem with Tresys tools on Core 2 In-Reply-To: <200404301400.i3UE0mJx024222@gotham.columbia.tresys.com> Message-ID: <200404301422.i3UEMhJx024372@gotham.columbia.tresys.com> > > Nick, > > Seuser looks for the policy.conf file in /etc/security/selinux/src by > default, but it seems that some systems only have the policy.conf file in > /etc/security/selinux/src/policy (note the extra policy directory at the > end). If that is the case on your system, in the file > /usr/share/setools/seuser.conf change the line: > > policy.conf /etc/security/selinux/src/policy.conf > > to > > policy.conf /etc/security/selinux/src/policy/policy.conf > > > On my Fedora Core 2 test 2 system the policy.conf is in both locations - > anyone know which is the location for default installs of Fedora Core 2? > Steve Smalley reminded me that this change of location was discussed a while ago. We will change the default location for seuser for the next release, but until then this change will need to be made to the configuration file. Dan, any way to get this minor update made to the redhat packages? Karl Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 > Karl > > Karl MacMillan > Tresys Technology > http://www.tresys.com > (410)290-1411 ext 134 > > > -----Original Message----- > > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux- > list- > > bounces at redhat.com] On Behalf Of Nick > > Sent: Thursday, April 29, 2004 7:10 PM > > To: fedora-selinux-list at redhat.com > > Subject: Re: Problem with Tresys tools on Core 2 > > > > On Thu, 2004-04-29 at 13:10, Nick wrote: > > > Conditions: > > > ----------- > > > > > > Install from DVD ISO > > > yum upgrade > > > installation of RPMS > > > checkpolicy-1.10-1.i386.rpm > > > policy-sources-1.11.2-18.noarch.rpm > > > setools-1.3-2.i386.rpm > > > setools-gui-1.3-2.i386.rpm > > > > > > > > > Results > > > ------- > > > > > > [root at rocket policy]# seinfo -r > > > Could not open policy! > > > > I rebuilt and now seinfo -r works. > > > > > [root at rocket policy]# seuser -X > > > Error in StartScript (/usr/share/setools/se_user.tcl): > > > > This still does not work > > > > > Thanks Nick > > -- > > Nick Gray > > Senior Systems Engineer > > Bruzenak Inc. > > nagray at austin.rr.com > > (512) 331-7998 > > > > -- > > 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 nick-gray at austin.rr.com Fri Apr 30 14:31:51 2004 From: nick-gray at austin.rr.com (Nick) Date: Fri, 30 Apr 2004 09:31:51 -0500 Subject: Problem with Tresys tools on Core 2 In-Reply-To: <1083334050.30875.80.camel@moss-spartans.epoch.ncsc.mil> References: <200404301400.i3UE0mJx024222@gotham.columbia.tresys.com> <1083334050.30875.80.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1083335510.21037.1.camel@hawaii.efficax.net> Thanks, soft linking /etc/security/selinux/src/policy/policy.conf to /etc/security/selinux/src/policy.conf works for now On Fri, 2004-04-30 at 09:07, Stephen Smalley wrote: > On Fri, 2004-04-30 at 10:01, Karl MacMillan wrote: > > On my Fedora Core 2 test 2 system the policy.conf is in both locations - > > anyone know which is the location for default installs of Fedora Core 2? > > It is only under /etc/security/selinux/src/policy now, as noted in an > earlier discussion. -- Nick Gray Senior Systems Engineer Bruzenak Inc. nagray at austin.rr.com (512) 331-7998 From brugolsky at telemetry-investments.com Fri Apr 30 14:39:03 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 30 Apr 2004 10:39:03 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <20040430133356.GA29325@ti64.telemetry-investments.com> <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040430143903.GC29325@ti64.telemetry-investments.com> On Fri, Apr 30, 2004 at 10:02:32AM -0400, Stephen Smalley wrote: > Better to have SELinux enabled > all the time with two different policies that are appropriately tuned to > the needs and desires of differing user communities. I concur with that sentiment, and didn't mean to imply that a relaxed policy is not desirable. Not having to frantically rebuild a server app the moment an exploit is discovered is reason enough to have SELinux confining all network-facing servers. I only wanted to highlight that expectations need to be reset as both the default policy has been loosened, and the relaxed policy will loosen things further. I would hate for it to reflect negatively on SELinux when someone exploits an FC2 default SELinux install; the press will not make fine distinctions, and there will be gloating from other corners. Toward that end, I think it is important that users understand where along the "low-medium-high" spectrum they have set their security. Having SELinux on by default, even with a relatively permissive policy, will (1) ensure that the code is exercised, and (2) force developers, packagers, etc., to think about the required logic, and address any performance problems, so we can get to a more secure default install. Regards, Bill Rugolsky From katzj at redhat.com Fri Apr 30 15:36:35 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Apr 2004 11:36:35 -0400 Subject: Core 2 SELinux installation In-Reply-To: <20040430143903.GC29325@ti64.telemetry-investments.com> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <20040430133356.GA29325@ti64.telemetry-investments.com> <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> <20040430143903.GC29325@ti64.telemetry-investments.com> Message-ID: <1083339394.4710.28.camel@rivendell.local.net> On Fri, 2004-04-30 at 10:39 -0400, Bill Rugolsky Jr. wrote: > I concur with that sentiment, and didn't mean to imply that a relaxed > policy is not desirable. Not having to frantically rebuild a server > app the moment an exploit is discovered is reason enough to have SELinux > confining all network-facing servers. I only wanted to highlight that > expectations need to be reset as both the default policy has been loosened, > and the relaxed policy will loosen things further. I would hate for it > to reflect negatively on SELinux when someone exploits an FC2 default > SELinux install; the press will not make fine distinctions, and there > will be gloating from other corners. Toward that end, I think it is > important that users understand where along the "low-medium-high" > spectrum they have set their security. Definitely -- my plan is to provide the spectrum of choices and also have accompanying explanatory text so that users can make an informed decision about what they want to use SELinux-wise on their system > Having SELinux on by default, even with a relatively permissive policy, > will (1) ensure that the code is exercised, and (2) force developers, > packagers, etc., to think about the required logic, and address any > performance problems, so we can get to a more secure default install. Yep, and hopefully then in the longer term, we can move to more and more locked down setups as users become used to the concepts introduced by SELinux and applications become aware of it. Jeremy From jmorris at redhat.com Fri Apr 30 16:04:04 2004 From: jmorris at redhat.com (James Morris) Date: Fri, 30 Apr 2004 12:04:04 -0400 (EDT) Subject: Core 2 SELinux installation In-Reply-To: <20040430143903.GC29325@ti64.telemetry-investments.com> Message-ID: On Fri, 30 Apr 2004, Bill Rugolsky Jr. wrote: > and the relaxed policy will loosen things further. I would hate for it > to reflect negatively on SELinux when someone exploits an FC2 default > SELinux install; the press will not make fine distinctions, and there > will be gloating from other corners. I think we need to concentrate on what will actually increase overall security in the long term. - James -- James Morris From sds at epoch.ncsc.mil Fri Apr 30 16:14:08 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 30 Apr 2004 12:14:08 -0400 Subject: Core 2 SELinux installation In-Reply-To: <20040430143903.GC29325@ti64.telemetry-investments.com> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <20040430133356.GA29325@ti64.telemetry-investments.com> <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> <20040430143903.GC29325@ti64.telemetry-investments.com> Message-ID: <1083341648.30875.157.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-30 at 10:39, Bill Rugolsky Jr. wrote: > I concur with that sentiment, and didn't mean to imply that a relaxed > policy is not desirable. Not having to frantically rebuild a server > app the moment an exploit is discovered is reason enough to have SELinux > confining all network-facing servers. I only wanted to highlight that > expectations need to be reset as both the default policy has been loosened, > and the relaxed policy will loosen things further. I would hate for it > to reflect negatively on SELinux when someone exploits an FC2 default > SELinux install; the press will not make fine distinctions, and there > will be gloating from other corners. Toward that end, I think it is > important that users understand where along the "low-medium-high" > spectrum they have set their security. One thing to consider is that the "relaxed" policy may actually end up being more "secure" for the set of security goals it targets. Perhaps a better term than "relaxed" would be "specialized" or "targeted". Given a small focused set of security goals, you can more easily specify the policy and analyze it for exceptions. In contrast, when you try to put every process in its own sandbox while supporting existing functionality (particularly functionality that isn't used to living in sandboxes), it becomes very difficult to analyze the resulting large, complex policy to see whether it meets your higher level goals (e.g. don't let apache subvert a trusted process). -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Fri Apr 30 16:44:49 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Apr 2004 12:44:49 -0400 Subject: Access to cd device denied for cdp In-Reply-To: Your message of "Thu, 29 Apr 2004 18:36:41 MDT." <1083285401.3190.22.camel@wraith.lrp.advansoft.us> References: <1083030774.18163.22.camel@CirithUngol> <408FD469.9040605@redhat.com> <1083285401.3190.22.camel@wraith.lrp.advansoft.us> Message-ID: <200404301644.i3UGinN7016725@turing-police.cc.vt.edu> On Thu, 29 Apr 2004 18:36:41 MDT, "Lamont R. Peterson" said: > That question asked, I have to say that I am inclined to think that as > long as kudzu is around in a system with SELinux, we are going to have > to accept the need for it (kudzu) to work withing that (SELinux) > environment. I do not yet agree that there is need for kudzu to alter > policies, but I am going to reserve judgment until after further > discussion. I can't convince myself that kudzu must be able to alter policy. I can convince myself that if kudzu is running in an SELinux environment, and it creates a /dev entry, that it needs some way to make it end up labeled according to the policy in effect. On the other hand, kudzu under SELinux *does* have a rather heavy taste of "Doctor, it hurts when I do that" "Don't do that then". After all, there is hotplug and friends.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Apr 30 16:47:56 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Apr 2004 12:47:56 -0400 Subject: Core 2 SELinux installation In-Reply-To: Your message of "Fri, 30 Apr 2004 08:34:44 EDT." <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200404301647.i3UGluH9016869@turing-police.cc.vt.edu> On Fri, 30 Apr 2004 08:34:44 EDT, Stephen Smalley said: > So how would people feel about a separate relaxed policy that allows > everything in the system to run completely unconfined except for a small > set of specific services, e.g. apache, bind, postfix, ... > That would ensure that SELinux wouldn't get in the way of users, while > providing some protection benefit for network-facing services. Hmm.. that sounds like something that might be a good idea for some environments, but it's not something that I want on my machines. Personally, I *like* the idea that things like Mozilla and my MUA can be confined - my machines are already hardened enough that those two are positively the soft underbelly of the system.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Apr 30 16:54:55 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Apr 2004 12:54:55 -0400 Subject: Core 2 SELinux installation In-Reply-To: Your message of "Fri, 30 Apr 2004 10:02:32 EDT." <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <20040430133356.GA29325@ti64.telemetry-investments.com> <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200404301654.i3UGstvL017120@turing-police.cc.vt.edu> On Fri, 30 Apr 2004 10:02:32 EDT, Stephen Smalley said: > SELinux provides flexible support for security policies in recognition > of the fact that a single policy won't meet everyone's desires or > needs. Just in case my previous note was unclear - I actually agree with Stephen. If I'm reading his proposal correctly, it *is* something that will be of use in some environments - it's just that my needs are going in other directions. (Similarl to the fact there's a need for an Oracle-class database system, even though I don't run any of those either)... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mattdm at mattdm.org Fri Apr 30 17:37:48 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 30 Apr 2004 13:37:48 -0400 Subject: Core 2 SELinux installation In-Reply-To: <1083341648.30875.157.camel@moss-spartans.epoch.ncsc.mil> References: <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> <20040430133356.GA29325@ti64.telemetry-investments.com> <1083333752.30875.71.camel@moss-spartans.epoch.ncsc.mil> <20040430143903.GC29325@ti64.telemetry-investments.com> <1083341648.30875.157.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040430173748.GA29643@jadzia.bu.edu> On Fri, Apr 30, 2004 at 12:14:08PM -0400, Stephen Smalley wrote: > One thing to consider is that the "relaxed" policy may actually end up > being more "secure" for the set of security goals it targets. Perhaps a > better term than "relaxed" would be "specialized" or "targeted". Given > a small focused set of security goals, you can more easily specify the > policy and analyze it for exceptions. In contrast, when you try to put > every process in its own sandbox while supporting existing functionality > (particularly functionality that isn't used to living in sandboxes), it > becomes very difficult to analyze the resulting large, complex policy to > see whether it meets your higher level goals (e.g. don't let apache > subvert a trusted process). This sounds like a very good approach, and is much less threatening to a sysadmin with a large base of systems and users that are all basically working fine now. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tmolina at cablespeed.com Fri Apr 30 22:56:34 2004 From: tmolina at cablespeed.com (Thomas Molina) Date: Fri, 30 Apr 2004 18:56:34 -0400 (EDT) Subject: Core 2 SELinux installation In-Reply-To: <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> References: <1083205014.27417.49.camel@hawaii.efficax.net> <1083206627.3949.13.camel@rivendell.local.net> <1083208018.27417.78.camel@hawaii.efficax.net> <1083251105.3949.32.camel@rivendell.local.net> <1083256533.27417.156.camel@hawaii.efficax.net> <1083293511.2791.6.camel@rivendell.local.net> <40921EF5.7020207@234.cx> <1083328484.30875.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Fri, 30 Apr 2004, Stephen Smalley wrote: > On Fri, 2004-04-30 at 05:40, Pete Chown wrote: > > I think this is especially true for a new security technology. Most > > people's view of security is quite simplistic: they want the bad guys > > kept out, without their work being interfered with. If SELinux > > interferes with their work, they will turn it off, reasoning that normal > > Unix security has kept the bad guys out so far. They are then unlikely > > to try it again later however much people tell them that the policy has > > been improved. > > So how would people feel about a separate relaxed policy that allows > everything in the system to run completely unconfined except for a small > set of specific services, e.g. apache, bind, postfix, ... > That would ensure that SELinux wouldn't get in the way of users, while > providing some protection benefit for network-facing services. My initial reaction is that it sounds like quitting smoking by each month reducing by one the number of cigarettes smoked per day. You are certainly headed in the right direction, but taking a god awful amount of time getting there. Who knows what will happen in the meantime. Cold turkey sounds good. Nice, secure defaults, with the option to turn it off temporarily during testing would give us the chance to shake out the bugs the quickest. I would advocate having a range of security selections available. I will certainly avail myself of the opportunity to test the strictest of those choices, consistent with getting a little work done. I want good policy available, and awareness/pressure on developers to consider policy when creating applications.