From csellers at tresys.com Thu Dec 1 15:23:20 2005 From: csellers at tresys.com (Chad Sellers) Date: Thu, 1 Dec 2005 10:23:20 -0500 Subject: help with the SELinux FAQ In-Reply-To: <1133302866.19569.38.camel@erato.phig.org> References: <1133302866.19569.38.camel@erato.phig.org> Message-ID: <200512011023.20342.csellers@tresys.com> On Tuesday 29 November 2005 05:21 pm, Karsten Wade wrote: > If you would like to help write or update the Fedora SELinux FAQ[1], > please follow up to this thread on fedora-docs-list at redhat.com (reply-to > set). > > I've been unable to maintain the FAQ in a proper state for a while now, > and we need the content to be significantly updated for FC5. > > Changes made now can be included in the FC5 testing process. > > To fill this role, you need to know what is going on in the Fedora > SELinux project. We can take care of the rest with you, from access to > the content and tools to make the changes. > > Thanks - Karsten, lazy FAQ maintainer > > [1] http://fedora.redhat.com/docs/selinux-faq/ We definitely want to make sure that many of the changes (move to reference policy/policy v2, move to managed policy, move to policy modules, etc.) get into the FAQ. Let me know what I can do to help. Thanks, Chad Sellers -- ---------------------- Chad Sellers Tresys Technology, LLC csellers at tresys.com http://www.tresys.com From sds at tycho.nsa.gov Fri Dec 2 19:20:55 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 02 Dec 2005 14:20:55 -0500 Subject: 'install' command goes "oink!" after recent updates. In-Reply-To: <1133380367.26593.371.camel@moss-spartans.epoch.ncsc.mil> References: <200511301909.jAUJ9Gh6022351@turing-police.cc.vt.edu> <438DFC64.2090905@redhat.com> <1133380367.26593.371.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133551255.28437.143.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-11-30 at 14:52 -0500, Stephen Smalley wrote: > On Wed, 2005-11-30 at 14:24 -0500, Daniel J Walsh wrote: > > Sounds like that is probably the udev problem also. > > The issue is the complete processing of file_contexts by > matchpathcon_init() even when the caller is only going to do a single > matchpathcon(). That costs us both in regex compilation time and in > context validation/canonicalization time (the only change in the latter > is that we now read back the canonical context from the kernel; we were > already writing the context to the kernel to validate it). As the > original user of matchpathcon was setfiles/restorecon, that was > reasonable (we wanted the entire configuration). For udev and install, > it isn't. > > Solution is likely to provide a variant of matchpathcon_init() that > allows the caller to specify a prefix, and only process file_contexts > entries with that prefix. Much of the install slowdown should be addressed by libselinux 1.27.28. We can also potentially improve that further by modifying install to use the new matchpathcon_init_prefix() interface, but some improvement should be immediately evident from the new libselinux. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Dec 2 19:24:52 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 02 Dec 2005 14:24:52 -0500 Subject: selinux and udev ? In-Reply-To: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> Message-ID: <1133551492.28437.145.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote: > There are reports in fedora-test about the 2.X policy slowing down > udev. (Appears that folks are comparing booting with selinxux=1 with > selinux=0). > > I have to admit that udev is running slower (targeted/enforcing). > > Any validity to this? Known issue? How to track down? libselinux 1.27.28 should help with this slowdown, and further improvement can be had by modifying udev to call matchpathcon_init_prefix() to limit processing to /dev entries. -- Stephen Smalley National Security Agency From selinux at gmail.com Sat Dec 3 20:08:19 2005 From: selinux at gmail.com (Tom London) Date: Sat, 3 Dec 2005 12:08:19 -0800 Subject: AVCs when inserting USB hard drive, etc. Message-ID: <4c4ba1530512031208v33424184m15192fb62a42c23d@mail.gmail.com> Running Rawhide, targeted/enforcing. running selinux-policy-targeted-2.0.8-1, got the following in /var/log/messages when I inserted a USB hard drive: Dec 3 11:58:18 localhost kernel: sda: sda1 sda2 sda3 Dec 3 11:58:18 localhost kernel: sd 0:0:0:0: Attached scsi disk sda Dec 3 11:58:20 localhost dbus: Can't send to audit system: USER_AVC pid=2759 uid=81 loginuid=-1 message=avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.Hal.Device member=SetPropertyBoolean dest=org.freedesktop.Hal spid=25942 tpid=2799 scontext=system_u:system_r:hald_t tcontext=system_u:system_r:hald_t tclass=dbus Dec 3 11:58:20 localhost fstab-sync[25943]: added mount point /media/usbdisk for /dev/sda1 Dec 3 11:58:20 localhost dbus: Can't send to audit system: USER_AVC pid=2759 uid=81 loginuid=-1 message=avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.Hal.Device member=SetPropertyBoolean dest=org.freedesktop.Hal spid=25949 tpid=2799 scontext=system_u:system_r:hald_t tcontext=system_u:system_r:hald_t tclass=dbus Dec 3 11:58:20 localhost fstab-sync[25950]: added mount point /media/usbdisk1 for /dev/sda2 Many of the following in /var/log/audit/audit.log: time->Sat Dec 3 11:58:20 2005 type=PATH msg=audit(1133639900.242:1387): item=0 flags=1 inode=2142284 dev=fd:00 mode=0140666 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1133639900.242:1387): nargs=3 a0=4 a1=bfd17f6a a2=6e type=SOCKADDR msg=audit(1133639900.242:1387): saddr=01002F7661722F72756E2F61637069642E736F636B6574000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 type=SYSCALL msg=audit(1133639900.242:1387): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd17f20 a2=4 a3=8b31030 items=1 pid=2805 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-acpi" exe="/usr/libexec/hald-addon-acpi" type=AVC msg=audit(1133639900.242:1387): avc: denied { write } for pid=2805 comm="hald-addon-acpi" name="acpid.socket" dev=dm-0 ino=2142284 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file ---- time->Sat Dec 3 11:58:25 2005 type=PATH msg=audit(1133639905.246:1388): item=0 flags=1 inode=2142284 dev=fd:00 mode=0140666 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1133639905.246:1388): nargs=3 a0=4 a1=bfd17f6a a2=6e type=SOCKADDR msg=audit(1133639905.246:1388): saddr=01002F7661722F72756E2F61637069642E736F636B6574000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 type=SYSCALL msg=audit(1133639905.246:1388): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd17f20 a2=4 a3=8b31030 items=1 pid=2805 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-acpi" exe="/usr/libexec/hald-addon-acpi" type=AVC msg=audit(1133639905.246:1388): avc: denied { write } for pid=2805 comm="hald-addon-acpi" name="acpid.socket" dev=dm-0 ino=2142284 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file ---- time->Sat Dec 3 11:58:30 2005 type=PATH msg=audit(1133639910.250:1389): item=0 flags=1 inode=2142284 dev=fd:00 mode=0140666 ouid=0 ogid=0 rdev=00:00 type=SOCKETCALL msg=audit(1133639910.250:1389): nargs=3 a0=4 a1=bfd17f6a a2=6e type=SOCKADDR msg=audit(1133639910.250:1389): saddr=01002F7661722F72756E2F61637069642E736F636B6574000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 type=SYSCALL msg=audit(1133639910.250:1389): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd17f20 a2=4 a3=8b31030 items=1 pid=2805 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-acpi" exe="/usr/libexec/hald-addon-acpi" type=AVC msg=audit(1133639910.250:1389): avc: denied { write } for pid=2805 comm="hald-addon-acpi" name="acpid.socket" dev=dm-0 ino=2142284 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file ---- Did a manual 'restorecon -v -R /var/run' and got: [root at tlondon ~]# restorecon -v -R /var/run restorecon reset /var/run/vmnet-natd-8.mac context system_u:object_r:initrc_var_run_t->system_u:object_r:var_run_t restorecon reset /var/run/acpid.socket context system_u:object_r:var_run_t->system_u:object_r:apmd_var_run_t tom -- Tom London From nicolas.mailhot at laposte.net Mon Dec 5 22:50:45 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 05 Dec 2005 23:50:45 +0100 Subject: Spamassasin Problem In-Reply-To: <20051120155222.GA13990@scooby> References: <20051120155222.GA13990@scooby> Message-ID: <4394C445.30502@laposte.net> W. Scott Wilburn wrote: > Since the problem occurred with a spamassassin update, not selinux, I > assume something in the behavior of spamassassin has changed. There is a boatload of spamassassin+selinux problems in bugzilla, I'm not sure Dan will have the time to fix them before FC5, let alone look at FC4 problems. Spamassassin does so many things (resolves names, writes in user homes, launches pluggins like pyzor/razor, some client/server spamc/spamd stuff...) from so many contexts (procmail, user, mta...) it seems every single policy/spamassassin update breaks something. -- Nicolas Mailhot From dravet at hotmail.com Tue Dec 6 15:24:35 2005 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 06 Dec 2005 09:24:35 -0600 Subject: udev slowness and selinux Message-ID: Hello, I am running todays rawhide and udev is still slow, but it is better than it was. Here are some numbers: booting with selinux disabled: udev starts in 5 seconds booting with selinux enabled (libselinux-1.27.28-1): udev starts in 26 seconds. booting with selinux enabled (older than libselinux-1.27.28-1): udev started in 50-60 seconds. I am running udev-075-4, kernel-2.6.14-1-1740, libselinux-1.27.28-1, and selinux-policy-targeted-2.0.9-1. I am running selinux in targeted enforcing mode. Thanks, Jason From sds at tycho.nsa.gov Tue Dec 6 15:45:14 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 06 Dec 2005 10:45:14 -0500 Subject: udev slowness and selinux In-Reply-To: References: Message-ID: <1133883914.20862.183.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-06 at 09:24 -0600, Jason Dravet wrote: > Hello, > > I am running todays rawhide and udev is still slow, but it is better than it > was. Here are some numbers: > booting with selinux disabled: udev starts in 5 seconds > booting with selinux enabled (libselinux-1.27.28-1): udev starts in 26 > seconds. > booting with selinux enabled (older than libselinux-1.27.28-1): udev started > in 50-60 seconds. > I am running udev-075-4, kernel-2.6.14-1-1740, libselinux-1.27.28-1, and > selinux-policy-targeted-2.0.9-1. I am running selinux in targeted enforcing > mode. Hmmm...I'm still not sure I understand why there has been a recent slowdown, as I wouldn't have expected either reference policy or the matchpathcon canonicalization to have added that much overhead (particularly as we were already validating the contexts). From your numbers above, it seems that the canonicalization is adding significant overhead, since the canonicalization is performed lazily in libselinux 1.27.28, but we still have major overhead remaining. How exactly are you timing the startup time here, e.g. are you just inserting a time command prior to the /sbin/start_udev call in rc.sysinit or are you timing the entire sequence including the Initializing hardware setup? udev could/should be changed to call matchpathcon_init_prefix(NULL, "/dev") once at startup prior to any matchpathcon() calls to avoid the overhead of processing the entire file_contexts configuration. But I'd like to get more information on where that time is being spent currently as well, so I'd like to know exactly how you are measuring so I can reproduce it and then try to profile it. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Dec 6 17:23:06 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 06 Dec 2005 12:23:06 -0500 Subject: udev slowness and selinux In-Reply-To: <1133883914.20862.183.camel@moss-spartans.epoch.ncsc.mil> References: <1133883914.20862.183.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133889786.20862.202.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-06 at 10:45 -0500, Stephen Smalley wrote: > Hmmm...I'm still not sure I understand why there has been a recent > slowdown, as I wouldn't have expected either reference policy or the > matchpathcon canonicalization to have added that much overhead > (particularly as we were already validating the contexts). From your > numbers above, it seems that the canonicalization is adding significant > overhead, since the canonicalization is performed lazily in libselinux > 1.27.28, but we still have major overhead remaining. > > How exactly are you timing the startup time here, e.g. are you just > inserting a time command prior to the /sbin/start_udev call in > rc.sysinit or are you timing the entire sequence including the > Initializing hardware setup? > > udev could/should be changed to call matchpathcon_init_prefix(NULL, > "/dev") once at startup prior to any matchpathcon() calls to avoid the > overhead of processing the entire file_contexts configuration. But I'd > like to get more information on where that time is being spent currently > as well, so I'd like to know exactly how you are measuring so I can > reproduce it and then try to profile it. Part of the slowdown could also be from libsetrans (both on translating contexts prior to storing them in the spec array and for the translation that occurs upon the security_canonicalize_context calls). Possibly we should make the context translation lazy as well, as with the canonicalization. But the largest savings are likely to come from using matchpathcon_init_prefix() and avoiding processing of many file_contexts entries altogether. -- Stephen Smalley National Security Agency From dravet at hotmail.com Tue Dec 6 17:29:05 2005 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 06 Dec 2005 11:29:05 -0600 Subject: udev slowness and selinux In-Reply-To: <1133883914.20862.183.camel@moss-spartans.epoch.ncsc.mil> Message-ID: >From: Stephen Smalley >To: Jason Dravet >CC: Daniel J Walsh , SELinux-dev at tresys.com, >fedora-selinux-list at redhat.com >Subject: Re: udev slowness and selinux >Date: Tue, 06 Dec 2005 10:45:14 -0500 > >On Tue, 2005-12-06 at 09:24 -0600, Jason Dravet wrote: > > Hello, > > > > I am running todays rawhide and udev is still slow, but it is better >than it > > was. Here are some numbers: > > booting with selinux disabled: udev starts in 5 seconds > > booting with selinux enabled (libselinux-1.27.28-1): udev starts in 26 > > seconds. > > booting with selinux enabled (older than libselinux-1.27.28-1): udev >started > > in 50-60 seconds. > > I am running udev-075-4, kernel-2.6.14-1-1740, libselinux-1.27.28-1, and > > selinux-policy-targeted-2.0.9-1. I am running selinux in targeted >enforcing > > mode. > >Hmmm...I'm still not sure I understand why there has been a recent >slowdown, as I wouldn't have expected either reference policy or the >matchpathcon canonicalization to have added that much overhead >(particularly as we were already validating the contexts). From your >numbers above, it seems that the canonicalization is adding significant >overhead, since the canonicalization is performed lazily in libselinux >1.27.28, but we still have major overhead remaining. > >How exactly are you timing the startup time here, e.g. are you just >inserting a time command prior to the /sbin/start_udev call in >rc.sysinit or are you timing the entire sequence including the >Initializing hardware setup? > >udev could/should be changed to call matchpathcon_init_prefix(NULL, >"/dev") once at startup prior to any matchpathcon() calls to avoid the >overhead of processing the entire file_contexts configuration. But I'd >like to get more information on where that time is being spent currently >as well, so I'd like to know exactly how you are measuring so I can >reproduce it and then try to profile it. > >-- >Stephen Smalley >National Security Agency > I am using a stop watch to measure the time. I start the watch when I see starting udev and I stop it when I see loading default keymap. If you would like me to use a different method of timing please tell me how and I will be happy to use it. Thanks, Jason From dwalsh at redhat.com Tue Dec 6 18:23:03 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Dec 2005 13:23:03 -0500 Subject: udev slowness and selinux In-Reply-To: References: Message-ID: <4395D707.2070305@redhat.com> Jason Dravet wrote: >> From: Stephen Smalley >> To: Jason Dravet >> CC: Daniel J Walsh , >> SELinux-dev at tresys.com, fedora-selinux-list at redhat.com >> Subject: Re: udev slowness and selinux >> Date: Tue, 06 Dec 2005 10:45:14 -0500 >> >> On Tue, 2005-12-06 at 09:24 -0600, Jason Dravet wrote: >> > Hello, >> > >> > I am running todays rawhide and udev is still slow, but it is >> better than it >> > was. Here are some numbers: >> > booting with selinux disabled: udev starts in 5 seconds >> > booting with selinux enabled (libselinux-1.27.28-1): udev starts in 26 >> > seconds. >> > booting with selinux enabled (older than libselinux-1.27.28-1): >> udev started >> > in 50-60 seconds. >> > I am running udev-075-4, kernel-2.6.14-1-1740, >> libselinux-1.27.28-1, and >> > selinux-policy-targeted-2.0.9-1. I am running selinux in targeted >> enforcing >> > mode. >> >> Hmmm...I'm still not sure I understand why there has been a recent >> slowdown, as I wouldn't have expected either reference policy or the >> matchpathcon canonicalization to have added that much overhead >> (particularly as we were already validating the contexts). From your >> numbers above, it seems that the canonicalization is adding significant >> overhead, since the canonicalization is performed lazily in libselinux >> 1.27.28, but we still have major overhead remaining. >> >> How exactly are you timing the startup time here, e.g. are you just >> inserting a time command prior to the /sbin/start_udev call in >> rc.sysinit or are you timing the entire sequence including the >> Initializing hardware setup? >> >> udev could/should be changed to call matchpathcon_init_prefix(NULL, >> "/dev") once at startup prior to any matchpathcon() calls to avoid the >> overhead of processing the entire file_contexts configuration. But I'd >> like to get more information on where that time is being spent currently >> as well, so I'd like to know exactly how you are measuring so I can >> reproduce it and then try to profile it. >> >> -- >> Stephen Smalley >> National Security Agency >> > I am using a stop watch to measure the time. I start the watch when I > see starting udev and I stop it when I see loading default keymap. If > you would like me to use a different method of timing please tell me > how and I will be happy to use it. > > Thanks, > Jason > > matchpathcon_init_prefix(NULL, "/dev") has been added to udev, not sure when it will hit rawhide. -- From dwalsh at redhat.com Tue Dec 6 18:28:51 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Dec 2005 13:28:51 -0500 Subject: udev slowness and selinux In-Reply-To: <4395D707.2070305@redhat.com> References: <4395D707.2070305@redhat.com> Message-ID: <4395D863.5040709@redhat.com> Updated udev policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora/ udev-076-1.i386.rpm -- From sds at tycho.nsa.gov Tue Dec 6 21:04:12 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 06 Dec 2005 16:04:12 -0500 Subject: udev slowness and selinux In-Reply-To: <4395D707.2070305@redhat.com> References: <4395D707.2070305@redhat.com> Message-ID: <1133903052.20862.217.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-06 at 13:23 -0500, Daniel J Walsh wrote: > matchpathcon_init_prefix(NULL, "/dev") > has been added to udev, not sure when it will hit rawhide. Ok, just to clarify: - udev is only calling it once, right? - does udev ever create any nodes outside of /dev? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Dec 6 21:24:57 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 06 Dec 2005 16:24:57 -0500 Subject: udev slowness and selinux In-Reply-To: <4395D863.5040709@redhat.com> References: <4395D707.2070305@redhat.com> <4395D863.5040709@redhat.com> Message-ID: <1133904297.20862.223.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-06 at 13:28 -0500, Daniel J Walsh wrote: > Updated udev policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora/ > > udev-076-1.i386.rpm That yields a major improvement in startup time for me. So as long as it is valid to assume that udev only creates nodes in /dev, this should be ok... -- Stephen Smalley National Security Agency From dravet at hotmail.com Wed Dec 7 00:08:03 2005 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 06 Dec 2005 18:08:03 -0600 Subject: udev slowness and selinux In-Reply-To: <4395D863.5040709@redhat.com> Message-ID: >From: Daniel J Walsh >To: Daniel J Walsh >CC: Jason Dravet , SELinux-dev at tresys.com, >fedora-selinux-list at redhat.com >Subject: Re: udev slowness and selinux >Date: Tue, 06 Dec 2005 13:28:51 -0500 > >Updated udev policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora/ > >udev-076-1.i386.rpm I installed the above rpm and now udev starts in 9 seconds. Much better! The slowdown started when the targeted policy moved from version 1 to 2. Back in late November Harald Hoyer asked users in fedora-devel-list to do some "udev alpha testing" and he created a udev-076-1 package. I don't know if your udev rpm will cause people some problems/yum confusion or not. Thanks to everyone who is working on selinux. Keep up the good work. Jason From lamia.h at wanadoo.tn Wed Dec 7 09:15:17 2005 From: lamia.h at wanadoo.tn (lamia.h at wanadoo.tn) Date: Wed, 07 Dec 2005 10:15:17 +0100 Subject: selinux Message-ID: <200512070915.jB79FHjH022658@smtp1.planet.net.tn> An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Wed Dec 7 15:21:00 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 07 Dec 2005 10:21:00 -0500 Subject: selinux In-Reply-To: <200512070915.jB79FHjH022658@smtp1.planet.net.tn> References: <200512070915.jB79FHjH022658@smtp1.planet.net.tn> Message-ID: <1133968860.2366.12.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-12-07 at 10:15 +0100, lamia.h at wanadoo.tn wrote: > > Hello > > I'm very interested in SELinux. I'm a beginner of SELinux. > > I have installed Linux Fedora core 1. To test the installation and > configuration of selinux, I need to download the files : > > linux-2.4-2003120509.tgz > > selinux-usr-2003120509.tgz > > but I couldn't find them inNSA's web site > (http://www.nsa.gov/selinux). Two problems: 1) Fedora Core 1 is very old, only supported by Fedora Legacy at this point and had a 2.4-based kernel. 2) The files you list above were a very old release of SELinux (December 2003), and are no longer available (you could download the last snapshot from the historical versions of SELinux page, but it isn't supported and it is likely to take a lot of work to get it up and running properly). Much easier to just install a modern version of Fedora (3 or later) that comes with SELinux already integrated. At this point, Fedora Core 4 is your best bet, as FC3 is likely to get transferred to Fedora Legacy by the end of this year IIUC (when FC5 test2 comes out later this month). -- Stephen Smalley National Security Agency From exinor at exinor.net Wed Dec 7 15:18:42 2005 From: exinor at exinor.net (Nicklas Norling) Date: Wed, 07 Dec 2005 16:18:42 +0100 Subject: Selinux and RPM packaging (trac) Message-ID: <4396FD52.1030406@exinor.net> Hi, Been looking around for quite some time and have found very little about how one is supposed to create rpm packages with selinux content. Specifically I'm trying to create a rpm package of trac http://projects.edgewall.com/trac/. The Wiki there suggests .fc and .te files for it http://projects.edgewall.com/trac/wiki/TracWithSeLinux. How would you recommend I go about this project. Does selinux contain a system for plugging in .te and .fc files so contexts are recognized during the package install or should I submitt these files for inclusion in the normal policy packages and wait for it to hit the fans? Do anyone have any pointers to best practis in these situations? What can the .spec file do in order to keep track of selinux permissions etc. Thankful for any help, /Nicke -- JID nicke at im.exinor.net From sds at tycho.nsa.gov Wed Dec 7 15:35:48 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 07 Dec 2005 10:35:48 -0500 Subject: Selinux and RPM packaging (trac) In-Reply-To: <4396FD52.1030406@exinor.net> References: <4396FD52.1030406@exinor.net> Message-ID: <1133969748.2366.23.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-12-07 at 16:18 +0100, Nicklas Norling wrote: > Been looking around for quite some time and have found very little about > how one is > supposed to create rpm packages with selinux content. > > Specifically I'm trying to create a rpm package of trac > http://projects.edgewall.com/trac/. > The Wiki there suggests .fc and .te files for it > http://projects.edgewall.com/trac/wiki/TracWithSeLinux. > > How would you recommend I go about this project. Does selinux contain a > system > for plugging in .te and .fc files so contexts are recognized during the > package install or > should I submitt these files for inclusion in the normal policy packages > and wait for it > to hit the fans? > > Do anyone have any pointers to best practis in these situations? What > can the .spec file > do in order to keep track of selinux permissions etc. Current practice is just to submit patches to the single monolithic policy to add your .te and .fc files there rather than trying to package them with your software package. However, FC5 (development) has incorporated the new support for binary policy modules, which allows individual .te and .fc files to be precompiled and packaged together and shipped separate from the base policy package. So it depends on what you are targeting, e.g. if you are looking ahead to FC5 or just trying to get things working in FC4. -- Stephen Smalley National Security Agency From Bjorn.Victor at it.uu.se Wed Dec 7 17:21:19 2005 From: Bjorn.Victor at it.uu.se (Bjorn Victor) Date: Wed, 07 Dec 2005 18:21:19 +0100 Subject: Spamassasin Problem In-Reply-To: <4394C445.30502@laposte.net> (Nicolas Mailhot's message of "Mon, 05 Dec 2005 23:50:45 +0100") References: <4394C445.30502@laposte.net> Message-ID: <7ny82w2580.fsf@Nomen.it.uu.se> On Mon, 05 Dec 2005 23:50:45 +0100 Nicolas Mailhot wrote: > W. Scott Wilburn wrote: > >> Since the problem occurred with a spamassassin update, not selinux, I >> assume something in the behavior of spamassassin has changed. > > There is a boatload of spamassassin+selinux problems in bugzilla, I'm > not sure Dan will have the time to fix them before FC5, let alone look > at FC4 problems. > > Spamassassin does so many things (resolves names, writes in user homes, > launches pluggins like pyzor/razor, some client/server spamc/spamd > stuff...) from so many contexts (procmail, user, mta...) it seems every > single policy/spamassassin update breaks something. Any advise on how to make spamassassin/spamd work (without disabling SElinux entirely) would be very welcome. -- Bjorn From nicolas.mailhot at laposte.net Wed Dec 7 18:24:42 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 07 Dec 2005 19:24:42 +0100 Subject: Spamassasin Problem In-Reply-To: <7ny82w2580.fsf@Nomen.it.uu.se> References: <4394C445.30502@laposte.net> <7ny82w2580.fsf@Nomen.it.uu.se> Message-ID: <439728EA.5050907@laposte.net> Bjorn Victor wrote: > On Mon, 05 Dec 2005 23:50:45 +0100 Nicolas Mailhot wrote: > >> W. Scott Wilburn wrote: >> >>> Since the problem occurred with a spamassassin update, not selinux, I >>> assume something in the behavior of spamassassin has changed. >> There is a boatload of spamassassin+selinux problems in bugzilla, I'm >> not sure Dan will have the time to fix them before FC5, let alone look >> at FC4 problems. >> >> Spamassassin does so many things (resolves names, writes in user homes, >> launches pluggins like pyzor/razor, some client/server spamc/spamd >> stuff...) from so many contexts (procmail, user, mta...) it seems every >> single policy/spamassassin update breaks something. > > Any advise on how to make spamassassin/spamd work (without disabling > SElinux entirely) would be very welcome. Report AVCs in bugzilla, confirm existing bugs, etc -- Nicolas Mailhot From robin-lists at robinbowes.com Wed Dec 7 20:00:39 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 07 Dec 2005 20:00:39 +0000 Subject: Allow apache to send mail? Message-ID: Hi, Can anyone tell me how to allow apache (httpd) to send mail, i.e. to use the smtp port? I'm trying to enable notifications in Trac and am seeing this in the audit log: type=AVC msg=audit(1133985478.317:38): avc: denied { name_connect } for pid=2175 comm="httpd" dest=25 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:smtp_port_t tclass=tcp_socket type=SYSCALL msg=audit(1133985478.317:38): arch=c000003e syscall=42 success=no exit=-13 a0=11 a1=2aaab21569f0 a2=10 a3=0 items=0 pid=2175 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" type=SOCKADDR msg=audit(1133985478.317:38): saddr=020000195433A04E0000000000000000 How do I modify my policy to allow this? Thanks, R. From robin-lists at robinbowes.com Wed Dec 7 20:29:53 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 07 Dec 2005 20:29:53 +0000 Subject: Selinux and RPM packaging (trac) In-Reply-To: <4396FD52.1030406@exinor.net> References: <4396FD52.1030406@exinor.net> Message-ID: Nicklas Norling said the following on 07/12/2005 15:18: > Hi, > > Been looking around for quite some time and have found very little about > how one is > supposed to create rpm packages with selinux content. > > Specifically I'm trying to create a rpm package of trac > http://projects.edgewall.com/trac/. > The Wiki there suggests .fc and .te files for it > http://projects.edgewall.com/trac/wiki/TracWithSeLinux. > > How would you recommend I go about this project. Does selinux contain a > system > for plugging in .te and .fc files so contexts are recognized during the > package install or > should I submitt these files for inclusion in the normal policy packages > and wait for it > to hit the fans? > > Do anyone have any pointers to best practis in these situations? What > can the .spec file > do in order to keep track of selinux permissions etc. Nicklas, One suggestion would be to ensure that the trac repositories are in /var/www/trac/ so they inherit from the /var/www parent directory. I've done this on FC4 and it's working OK for me. One other thing that isn't listed on the trac wiki is that httpd is not allowed to send mail by default (I've just posted about this). I've since worked out how to fix it: # To find out what policy is required to allow httpd to connect to # the smtp port, pipe the error msg from the audit.log into audit2allow audit2allow -i /var/log/audit/audit.log -l # This produces the following output: # allow httpd_t smtp_port_t:tcp_socket name_connect; # Add this new policy rule as a local policy: vi /etc/selinux/targeted/src/policy/domains/misc/local.te # add "allow httpd_t smtp_port_t:tcp_socket name_connect;" # make and activate the policy cd /etc/selinux/targeted/src/policy/ make load Not sure if this should be part of the apache policy - it probably should be a boolean. R. From mayerf at tresys.com Wed Dec 7 20:57:34 2005 From: mayerf at tresys.com (Frank Mayer) Date: Wed, 7 Dec 2005 15:57:34 -0500 Subject: SELinux Symposium Agenda released Message-ID: <014901c5fb70$d95c9740$220d010a@columbia.tresys.com> All, FYI, the agenda for the 2nd SELinux Symposium has been released. Below is a copy of the press release. Frank Speakers Confirmed for the Second Security-Enhanced Linux Symposium and Developer Summit Baltimore, Md. - (December 7, 2005) - The Security-Enhanced Linux (SELinux) Symposium announces papers and speakers for its second annual symposium. Experts from business, government, and academia will share and discuss the latest SELinux research and development results, application experience, and product plans. The event explores the emerging SELinux technology and the power of flexible mandatory access control in Linux. Registration for the SELinux Symposium, scheduled for February 27-March 3, 2006 in Baltimore, Maryland, will open soon at www.selinux-symposium.org. The Second SELinux Symposium features two full days of SELinux-related tutorials followed by a two-day technical agenda that includes papers, presentations, and case studies by experts and practitioners with SELinux. Topics for the symposium include in-depth discussions of the core SELinux technology, emerging SELinux policy management and development tools, experiences using SELinux to build secure system solutions, and the status of SELinux within Linux. New this year is an invitation-only SELinux developer summit, where the core developers and contributors of SELinux discuss upcoming technology changes, requirements, and plans. Papers for the symposium were selected via a community review process, and include authors from several organizations including IBM, MITRE Corporation, Pennsylvania State University, Purdue University, Red Hat, Tresys Technology, Trusted Computer Solutions, University of Illinois, University of Tulsa, University of Wisconsin, and the U.S. National Security Agency. The full agenda for the symposium is available at www.selinux-symposium.org. About the SELinux Symposium The Security-Enhanced Linux (SELinux) Symposium is an annual exchange of ideas, technology, and research involving SELinux. SELinux is technology that adds flexible, strong mandatory access control security to Linux. The Second Symposium is scheduled for February 27-March 3, 2006 in Baltimore, Maryland and is sponsored by Hewlett-Packard, IBM, Red Hat, Tresys Technology, and Trusted Computer Solutions. The event brings together experts from business, government, and academia to share research, development, and application experiences using SELinux. For information on registration and sponsorship opportunities, see www.selinux-symposium.org or info at selinux-symposium.org. From dwalsh at redhat.com Wed Dec 7 21:24:11 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 07 Dec 2005 16:24:11 -0500 Subject: Allow apache to send mail? In-Reply-To: References: Message-ID: <439752FB.40404@redhat.com> Robin Bowes wrote: > Hi, > > Can anyone tell me how to allow apache (httpd) to send mail, i.e. to use > the smtp port? > > I'm trying to enable notifications in Trac and am seeing this in the > audit log: > > type=AVC msg=audit(1133985478.317:38): avc: denied { name_connect } > for pid=2175 comm="httpd" dest=25 scontext=system_u:system_r:httpd_t > tcontext=system_u:object_r:smtp_port_t tclass=tcp_socket > type=SYSCALL msg=audit(1133985478.317:38): arch=c000003e syscall=42 > success=no exit=-13 a0=11 a1=2aaab21569f0 a2=10 a3=0 items=0 pid=2175 > auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 > fsgid=48 comm="httpd" exe="/usr/sbin/httpd" > type=SOCKADDR msg=audit(1133985478.317:38): > saddr=020000195433A04E0000000000000000 > > How do I modify my policy to allow this? > > Thanks, > > R. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Easiest way is setsebool -P httpd_can_network_connect=1 -- From dwalsh at redhat.com Wed Dec 7 21:32:06 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 07 Dec 2005 16:32:06 -0500 Subject: Spamassasin Problem In-Reply-To: <7ny82w2580.fsf@Nomen.it.uu.se> References: <4394C445.30502@laposte.net> <7ny82w2580.fsf@Nomen.it.uu.se> Message-ID: <439754D6.90004@redhat.com> Bjorn Victor wrote: > On Mon, 05 Dec 2005 23:50:45 +0100 Nicolas Mailhot wrote: > > >> W. Scott Wilburn wrote: >> >> >>> Since the problem occurred with a spamassassin update, not selinux, I >>> assume something in the behavior of spamassassin has changed. >>> >> There is a boatload of spamassassin+selinux problems in bugzilla, I'm >> not sure Dan will have the time to fix them before FC5, let alone look >> at FC4 problems. >> >> Spamassassin does so many things (resolves names, writes in user homes, >> launches pluggins like pyzor/razor, some client/server spamc/spamd >> stuff...) from so many contexts (procmail, user, mta...) it seems every >> single policy/spamassassin update breaks something. >> > > Any advise on how to make spamassassin/spamd work (without disabling > SElinux entirely) would be very welcome. > > -- Bjorn > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Try selinux-policy-targeted-1.27.1-2.16 which was just released to Updates. -- From robin-lists at robinbowes.com Wed Dec 7 22:58:18 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 07 Dec 2005 22:58:18 +0000 Subject: Allow apache to send mail? In-Reply-To: <439752FB.40404@redhat.com> References: <439752FB.40404@redhat.com> Message-ID: Daniel J Walsh said the following on 07/12/2005 21:24: > Robin Bowes wrote: > >> Hi, >> >> Can anyone tell me how to allow apache (httpd) to send mail, i.e. to use >> the smtp port? >> >> I'm trying to enable notifications in Trac and am seeing this in the >> audit log: >> >> type=AVC msg=audit(1133985478.317:38): avc: denied { name_connect } >> for pid=2175 comm="httpd" dest=25 scontext=system_u:system_r:httpd_t >> tcontext=system_u:object_r:smtp_port_t tclass=tcp_socket >> type=SYSCALL msg=audit(1133985478.317:38): arch=c000003e syscall=42 >> success=no exit=-13 a0=11 a1=2aaab21569f0 a2=10 a3=0 items=0 pid=2175 >> auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 >> fsgid=48 comm="httpd" exe="/usr/sbin/httpd" >> type=SOCKADDR msg=audit(1133985478.317:38): >> saddr=020000195433A04E0000000000000000 >> >> How do I modify my policy to allow this? > > Easiest way is > > setsebool -P httpd_can_network_connect=1 Daniel, Thanks. I came up with the following: allow httpd_t smtp_port_t:tcp_socket name_connect; CAn this be added to the std policy? Or preferably added as a boolean, e.g.: setsebool -P httpd_can_send_mail R. From cra at WPI.EDU Thu Dec 8 19:31:59 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 8 Dec 2005 14:31:59 -0500 Subject: mysqld_disable_trans leaves mysqld running as initrc_t? Message-ID: <20051208193159.GP2168@angus.ind.WPI.EDU> I've disabled SELinux protection of mysqld since it was causing major performance problems. This broke CGI scripts since httpd_script_t couldn't connect to the mysql unix domain socket. audit2allow created these rules which I put into local.te: allow httpd_sys_script_t var_t:dir getattr; allow httpd_sys_script_t initrc_t:unix_stream_socket connectto; allow httpd_t initrc_t:unix_stream_socket connectto; This fixed the problem. However, is mysqld supposed to be running as initrc_t instead of unconfined_t when mysqld_disable_trans is set? From sds at tycho.nsa.gov Thu Dec 8 19:44:37 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 08 Dec 2005 14:44:37 -0500 Subject: mysqld_disable_trans leaves mysqld running as initrc_t? In-Reply-To: <20051208193159.GP2168@angus.ind.WPI.EDU> References: <20051208193159.GP2168@angus.ind.WPI.EDU> Message-ID: <1134071077.2366.309.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-12-08 at 14:31 -0500, Chuck Anderson wrote: > I've disabled SELinux protection of mysqld since it was causing major > performance problems. More information about those performance problems would be of interest. > This fixed the problem. However, is mysqld supposed to be running as > initrc_t instead of unconfined_t when mysqld_disable_trans is set? In FC4 and later, yes. FC4 re-introduced the use of separate initial domains for system initialization, transitioning later to unconfined_t, rather than starting the system in unconfined_t as in FC3, which allows some useful distinctions to be made. But in targeted policy, initrc.te contains unconfined_domain(initrc_t), so it still ends up with full permissions. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Dec 8 21:29:17 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 08 Dec 2005 16:29:17 -0500 Subject: Interesting reading on exec* access checks. Message-ID: <4398A5AD.2010701@redhat.com> http://people.redhat.com/drepper/selinux-mem.html We are planning on turning off allow_execmem, allow_execmod, allow_execheap for unconfined_t in targeted policy. We are working to clean up any problems this might cause. This will add additional security features to Userspace, but might cause headaches. If you have the latest policy installed on Rawhide selinux-policy-targeted-2.1.0-3 or later you can try it out by running setsebool -P allow_execmem=0 allow_execmod=0 allow_execheap=0 You might need to relabel /usr/lib and /lib. Any help would be appreciated. :^) -- From ben.youngdahl at gmail.com Thu Dec 8 22:15:54 2005 From: ben.youngdahl at gmail.com (Benjamin Youngdahl) Date: Thu, 8 Dec 2005 16:15:54 -0600 Subject: sandboxing rpms Message-ID: <291399270512081415m4ff9c59al70c3032fdb72a4c8@mail.gmail.com> Greetings. My understanding is that RPM packages will be able to install policy modules in FC5, an improvement over a monolithic policy. I have a couple of questions about the implementation: 1. Is it possible to provide a temporary policy (either external, or with an RPM) that constains what the specific RPM's installation can do? The motivation here is that when I install an RPM, it would be nice if I would be able to get a declarative list of what the RPM wants access to do. The RPM tool might summarize before installing the package what the package will be allowed to do, by parsing this "installation sandbox" policy. 2. Is it possible to limit (or discover easily in advance) what changes to the system policy are being made by the RPM's policy modules? The motivation being that I want to be sure that the policy modules installed by an RPM are well behaved concerning overall system constraints. Apologies in advance if these questions are way off-base, or belong somewhere else. Thanks for your thoughts, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jose.Remy at SECUR.NET Fri Dec 9 15:28:01 2005 From: Jose.Remy at SECUR.NET (Jose H. REMY) Date: Fri, 9 Dec 2005 16:28:01 +0100 Subject: Spamassassin Problem Message-ID: <941F634BDD486A44B80120541613D3D22CFF69@gc._msdcs.jr.secur.net> For inf. My Spamassassin install works fine (3.0.4-2.fc4) With spamass-milter-0.3.0-8.fc4 and also mimedefang-2.54-1.2.fc4 With policy version 2.0 and selinux-policy-targeted-1.27.1-2.11 Except Razor2 plugin and custom header rewritings Jose H. REMY From dwalsh at redhat.com Fri Dec 9 20:58:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 09 Dec 2005 15:58:14 -0500 Subject: Adding two new booleans to httpd to tighten it's security. Message-ID: <4399EFE6.5040206@redhat.com> Currently policy allows httpd to connect to relay ports and to mysql/postgres ports. Adding these booleans * httpd_can_network_relay * httpd_can_network_connect_db And turning this feature off by default. This is going into tonights reference policy and into FC4 test release. If we had these turned off we would have prevented the last apache worm virus. This could cause problems for people who run httpd relays or have their apache databases talking to mysql and postgres databases over the network. You can turn the features back on by executing: setsebool -P httpd_can_network_relay=1 or setsebool -P httpd_can_network_connect_db=1 Will consider adding this feature to RHEL in a future update. Comments? Dan -- From exinor at exinor.net Sat Dec 10 14:42:02 2005 From: exinor at exinor.net (Nicklas Norling) Date: Sat, 10 Dec 2005 15:42:02 +0100 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <4399EFE6.5040206@redhat.com> References: <4399EFE6.5040206@redhat.com> Message-ID: <439AE93A.3000302@exinor.net> Daniel J Walsh wrote: > > Currently policy allows httpd to connect to relay ports and to > mysql/postgres ports. > > Adding these booleans > * httpd_can_network_relay > * httpd_can_network_connect_db > > And turning this feature off by default. This is going into tonights > reference policy and into FC4 test release. > If we had these turned off we would have prevented the last apache > worm virus. > This could cause problems for people who run httpd relays or have > their apache databases talking to mysql and postgres databases over > the network. > I'm sorry but I don't understand most of what you write. What is relay ports? What worm are you refering to? I find nothing googling and the latest worms I could find was a defect in apache or openssl. I'm conserned that this is going in without any discussion, or have I missed somerhing? I'm guessing most FC4 users having apache setup are using different kind of applications in PHP, Python, Perl etc. that they run. Forums, portals, Wikis, blogs etc. Most, if not all, uses the network to connect to the local email server and to store/retreive data from a database. Installing a policy that breaks their services will be very determinental to the trust of selinux. I suppose those services will be left semi-functional after such an update and that manual intervention is required to restore service. That would be close to a DOS attack in my oppinion. > You can turn the features back on by executing: > setsebool -P httpd_can_network_relay=1 > or > setsebool -P httpd_can_network_connect_db=1 > > Will consider adding this feature to RHEL in a future update. > > Comments? Please elaborate, what problem is being solved here? What will the consequences be for end users? > > Dan > /Nicke -- JID nicke at im.exinor.net From nicolas.mailhot at laposte.net Sat Dec 10 16:47:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 17:47:07 +0100 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439AE93A.3000302@exinor.net> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> Message-ID: <439B068B.4070402@laposte.net> Nicklas Norling wrote: > Daniel J Walsh wrote: > >> >> Currently policy allows httpd to connect to relay ports and to >> mysql/postgres ports. >> >> Adding these booleans >> * httpd_can_network_relay >> * httpd_can_network_connect_db >> >> And turning this feature off by default. This is going into tonights >> reference policy and into FC4 test release. >> If we had these turned off we would have prevented the last apache >> worm virus. I'd really appreciate if more effort was expanded in fixing existing AVCs rather than adding new blocking rules. The current ruleset is already strong enough a lot of people just turn off selinux, perfect security isn't much use if no one enables it. I'd rather aim for imperfect security some users actually use. -- Nicolas Mailhot From dwalsh at redhat.com Sat Dec 10 17:54:09 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 10 Dec 2005 12:54:09 -0500 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439B068B.4070402@laposte.net> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> Message-ID: <439B1641.3010900@redhat.com> Nicolas Mailhot wrote: > Nicklas Norling wrote: > >> Daniel J Walsh wrote: >> >> >>> Currently policy allows httpd to connect to relay ports and to >>> mysql/postgres ports. >>> >>> Adding these booleans >>> * httpd_can_network_relay >>> * httpd_can_network_connect_db >>> >>> And turning this feature off by default. This is going into tonights >>> reference policy and into FC4 test release. >>> If we had these turned off we would have prevented the last apache >>> worm virus. >>> > > I'd really appreciate if more effort was expanded in fixing existing > AVCs rather than adding new blocking rules. > Which avc's are you talking about. We have been working hard to fix all avc's when we can. > The current ruleset is already strong enough a lot of people just turn > off selinux, perfect security isn't much use if no one enables it. > > Most people turned off firewall support in the beginning also. These rules should not effect 90 % of apache SELinux users and will further secure those same users. > I'd rather aim for imperfect security some users actually use. > We are trying to work to a happy medium of security with as little pain as possible. -- From dwalsh at redhat.com Sat Dec 10 18:03:28 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 10 Dec 2005 13:03:28 -0500 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439AE93A.3000302@exinor.net> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> Message-ID: <439B1870.50000@redhat.com> Nicklas Norling wrote: > Daniel J Walsh wrote: > >> >> Currently policy allows httpd to connect to relay ports and to >> mysql/postgres ports. >> >> Adding these booleans >> * httpd_can_network_relay >> * httpd_can_network_connect_db >> >> And turning this feature off by default. This is going into tonights >> reference policy and into FC4 test release. >> If we had these turned off we would have prevented the last apache >> worm virus. >> This could cause problems for people who run httpd relays or have >> their apache databases talking to mysql and postgres databases over >> the network. >> > I'm sorry but I don't understand most of what you write. What is relay > ports? What worm are you refering to? In the default targeted policy in FC4/RHEL4 apache is allowed to attach to the Apache ports 80. 8080 and a few others like ftp etc. This boolean would allow users who do not want their apache servers to be able to connect out. Most apache servers do not relay requests to other machines, and this would just enforce this policy. A worm that came out over the last couple of months attacked PHP and apache and once a machine was infected launched attacks on other web servers inside your private network. If the new policy was in place this worm/attack would have been thwarted. Apache currently is not allowed to connect to random ports including the mail port. You have to turn that on a boolean if you want apache to connect to these other ports. These new booleans would just close all remaining ports that apache could connect to. > I find nothing googling and the latest worms I could find was a defect > in apache or openssl. > I'm conserned that this is going in without any discussion, or have I > missed somerhing? This is the discussion. I have not put out a fc4 RELEASE YET. I am looking for peoples comments before we turn this on. > I'm guessing most FC4 users having apache setup are using different > kind of applications in PHP, Python, Perl > etc. that they run. Forums, portals, Wikis, blogs etc. Most, if not > all, uses the network to connect to the local > email server and to store/retreive data from a database. Connecting to the local database should not be a problem, since that would be over a unix domain socket. Mail is currently shut off and you need to turn on boolean to allow it. > Installing a policy that breaks their services will be > very determinental to the trust of selinux. I suppose those services > will be left semi-functional after such an update > and that manual intervention is required to restore service. That > would be close to a DOS attack in my oppinion. > We could leave the boolean turned on, but then most customers would not get the security increase. >> You can turn the features back on by executing: >> setsebool -P httpd_can_network_relay=1 >> or >> setsebool -P httpd_can_network_connect_db=1 >> >> Will consider adding this feature to RHEL in a future update. >> >> Comments? > > Please elaborate, what problem is being solved here? What will the > consequences be for end users? > It will prevent a hacked Apache/PHP server from being able to launch attacks on other servers. The consequences for most users would be nil. Some will break their service, until they set the boolean, if we default to off. >> >> Dan >> > /Nicke > -- From i.pilcher at comcast.net Sat Dec 10 19:05:26 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sat, 10 Dec 2005 13:05:26 -0600 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439B1870.50000@redhat.com> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B1870.50000@redhat.com> Message-ID: Daniel J Walsh wrote: > Connecting to the local database should not be a problem, since that > would be over a unix domain socket. Mail is currently shut off and you > need to turn on boolean to allow it. Please don't make this assumption. A lot of web application authors don't bother to enable this (assuming that the database, the web scripting language, and the connection software all support it), so it's necessary to use a network connection over the loopback adapter. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From nicolas.mailhot at laposte.net Sat Dec 10 19:08:20 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 20:08:20 +0100 (CET) Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439B1641.3010900@redhat.com> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> Message-ID: <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> On Sam 10 d?cembre 2005 18:54, Daniel J Walsh wrote: > Nicolas Mailhot wrote: >> I'd really appreciate if more effort was expanded in fixing existing >> AVCs rather than adding new blocking rules. >> > Which avc's are you talking about. We have been working hard to fix all > avc's when we can. How about having selinux play nice with spamassassin at last ? It's still not able to create resolver sockets "Error creating a DNS resolver socket" or writing in its own files cannot create tmp lockfile ~/.spamassassin/bayes.lock.xxx cannot write to ~/.spamassassin/user_pref (this has been reported many many times) Or else fix fstab-sync avc: denied { getattr } for pid=2572 comm="fstab-sync" name="/" dev=tmpfs ino=5287 scontext=system_u:system_r:updfstab_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir (again, reported many times) Or else not break basic stuff like thunderbird avc: denied { execmem } for pid=2950 comm="thunderbird-bin" scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process or gpm avc: denied { write } for pid=2420 comm="gpm" name="mice" dev=tmpfs ino=4118 scontext=system_u:system_r:gpm_t:s0 tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file these two are new, but since I spare you the stuff which has been fixed lately I figured it was only fair to add new breakage # audit2allow Well, after alot of trying i did a fixfiles relabel and right after that a touch /.autorelabel and rebooted the machine, and dovecot works again. I still don't know what went wrong, but it works again. Mark Evers ----- Original Message ----- From: Net-Care Beheer To: fedora-selinux-list at redhat.com Sent: Saturday, December 10, 2005 1:43 AM Subject: Possible bug.. First of all, i'm hoping i'm posting this the right way, but i've tried everything that i know I'm having problems with Dovecot, and i've asked for help in #fedore on freenode.net, without success and they adviced me to post it here. This is the error i get in /var/log/audit/audit.log when i start dovecot using webmin type=AVC msg=audit(1134174789.681:11): avc: denied { read } for pid=2908 comm="dovecot" name="dovecot" dev=dm-0 ino=67858 scontext=system_u:system_r:dovecot_t tcontext=system_u:object_r:bin_t tclass=dir type=SYSCALL msg=audit(1134174789.681:11): arch=40000003 syscall=5 success=no exit=-13 a0=8059310 a1=8000 a2=0 a3=8000 items=1 pid=2908 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="dovecot" exe="/usr/sbin/dovecot" type=CWD msg=audit(1134174789.681:11): cwd="/usr/libexec/webmin/dovecot" type=PATH msg=audit(1134174789.681:11): item=0 name="." flags=101 inode=67858 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 On my screen i get "Starting Dovecot Imap: Fatal: unlink_directory() failed for /var/run/dovecot-login: Permission denied" When i try to start dovecot using "service dovecot start" or /etc/rc.d/init.d/dovecot start i get "Starting Dovecot Imap: [FAILED]" I've allready tried a fixfiles and even a touch /.autorelabel without luck. The system is fully updated with yum, and removing/adding dovecot doesn't make a difference. I Hope someone can help. Thanks Mark Evers Netherlands. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drepper at redhat.com Sat Dec 10 20:37:57 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 10 Dec 2005 12:37:57 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> Message-ID: <439B3CA5.4080009@redhat.com> Nicolas Mailhot wrote: > avc: denied { execmem } for pid=2950 comm="thunderbird-bin" > scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 > tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process If this really happens then this is a terrible bug in tbird. It's nothing which should be patched with the policy. By not adding the support to catch these problems early the code won't be fixed. New rules are often added for a specific purpose: discover bugs in programs and stop existing threats. It would be wrong to not attack these as soon as possible. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From nicolas.mailhot at laposte.net Sat Dec 10 20:59:23 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 21:59:23 +0100 (CET) Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439B3CA5.4080009@redhat.com> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> Message-ID: <56950.81.64.157.3.1134248363.squirrel@rousalka.dyndns.org> On Sam 10 d?cembre 2005 21:37, Ulrich Drepper wrote: > Nicolas Mailhot wrote: >> avc: denied { execmem } for pid=2950 comm="thunderbird-bin" >> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 >> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process > > If this really happens then this is a terrible bug in tbird. It's > nothing which should be patched with the policy. By not adding the > support to catch these problems early the code won't be fixed. > > New rules are often added for a specific purpose: discover bugs in > programs and stop existing threats. It would be wrong to not attack > these as soon as possible. It really happens, at least there (and thunderbird hasn't been updated, only selinux was - so it was happening before). So there are lots of work to do with existing rules before even thinking of moving to new bits like httpd port policy. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sat Dec 10 21:10:16 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 22:10:16 +0100 (CET) Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> Message-ID: <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> On Sam 10 d?cembre 2005 21:59, Nicolas Mailhot wrote: > > On Sam 10 d?cembre 2005 21:37, Ulrich Drepper wrote: >> Nicolas Mailhot wrote: >>> avc: denied { execmem } for pid=2950 comm="thunderbird-bin" >>> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 >>> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process >> >> If this really happens then this is a terrible bug in tbird. It's >> nothing which should be patched with the policy. By not adding the >> support to catch these problems early the code won't be fixed. >> >> New rules are often added for a specific purpose: discover bugs in >> programs and stop existing threats. It would be wrong to not attack >> these as soon as possible. > > It really happens, at least there (and thunderbird hasn't been updated, > only selinux was - so it was happening before). > > So there are lots of work to do with existing rules before even thinking > of moving to new bits like httpd port policy. Vanilla x86_64 thunderbird (thunderbird-1.5-0.5.1.rc1) (installed a week ago when evo started dying on no ascii folders), only extension : enigmail 0.93.1 (not that it actually works) Rawhide killed evo a week ago (#174931) It killed thunderbird today I'm running out of imap clients. I still have squirrelmail, and it's not even the rawhide one, since that one started misbehaving at least a month before (#162852) Do you want a bug entry for this problem too ? Regards, -- Nicolas Mailhot From drepper at redhat.com Sat Dec 10 21:38:15 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 10 Dec 2005 13:38:15 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <56950.81.64.157.3.1134248363.squirrel@rousalka.dyndns.org> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248363.squirrel@rousalka.dyndns.org> Message-ID: <439B4AC7.6040302@redhat.com> Nicolas Mailhot wrote: > So there are lots of work to do with existing rules before even thinking > of moving to new bits like httpd port policy. You do not understand the situation and my comments at all: the changes which cause problems due to execmod and execmem errors must be fixed in the programs. "Adding" these errors in independent of fixing up the policy for currently failing but valid programs. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From drepper at redhat.com Sat Dec 10 21:44:27 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 10 Dec 2005 13:44:27 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> Message-ID: <439B4C3B.40601@redhat.com> Nicolas Mailhot wrote: > Rawhide killed evo a week ago (#174931) > It killed thunderbird today > I'm running out of imap clients. Just add appropriate security labels. for f in /usr/lib/thunderbird-1.5/*.so /usr/lib/thunderbird-1.5/*/*.so; do if readelf -d $f | fgrep -q TEXTREL; then chcon system_u:object_r:texrel_shlib_t $f; fi; done (One long line.) Repeat for other directories. This specific problem is a gcc bug. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From nicolas.mailhot at laposte.net Sat Dec 10 21:50:57 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 22:50:57 +0100 (CET) Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439B4C3B.40601@redhat.com> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> Message-ID: <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> On Sam 10 d?cembre 2005 22:44, Ulrich Drepper wrote: > Nicolas Mailhot wrote: >> Rawhide killed evo a week ago (#174931) >> It killed thunderbird today >> I'm running out of imap clients. > > Just add appropriate security labels. > > for f in /usr/lib/thunderbird-1.5/*.so /usr/lib/thunderbird-1.5/*/*.so; > do if readelf -d $f | fgrep -q TEXTREL; then chcon > system_u:object_r:texrel_shlib_t $f; fi; done > > > (One long line.) Repeat for other directories. > > This specific problem is a gcc bug. Ok, thanks. I won't do it because workarounding like this is a slippery slope ending with selinux=false. I try to keep my system in line with current rawhide so it stays a valid test system (even if sometimes it's a difficult position to keep) But thank you for the information. -- Nicolas Mailhot From selinux at gmail.com Sun Dec 11 21:35:39 2005 From: selinux at gmail.com (Tom London) Date: Sun, 11 Dec 2005 13:35:39 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> Message-ID: <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> Running latest rawhide stuff, targeted/enforcing. Two 'after market' packages appear to need some help: skype and vmware. Here's the avc from vmware ---- time->Sun Dec 11 13:05:51 2005 type=AVC_PATH msg=audit(1134335151.660:39): path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0" type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000 success=no exit=-13 a0=b7c99000 a1=7b000 a2=5 a3=bfc5a1e0 items=0 pid=4418 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="vmware" exe="/usr/lib/vmware/bin/vmware" type=AVC msg=audit(1134335151.660:39): avc: denied { execmod } for pid=4418 comm="vmware" name="libgdk-x11-2.0.so.0" dev=dm-0 ino=343461 scontext=root:system_r:unconfined_t:s0-s0:c0.c255 tcontext=system_u:object_r:lib_t:s0 tclass=file Looks like they have a 'local version' of libgdk-x11-2.s0.0 that needs TEXTREL (looks like the one in /usr/lib doesn't need TEXTREL). and for skype: ---- time->Sun Dec 11 12:00:29 2005 type=PATH msg=audit(1134331229.904:20): item=1 flags=101 inode=327136 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1134331229.904:20): item=0 name="/usr/bin/skype" flags=101 inode=145190 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=CWD msg=audit(1134331229.904:20): cwd="/home/tbl" type=SYSCALL msg=audit(1134331229.904:20): arch=40000003 syscall=11 success=yes exit=0 a0=86ec0d8 a1=86f0e98 a2=86eca28 a3=1 items=2 pid=3359 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="skype" type=AVC msg=audit(1134331229.904:20): avc: denied { execmem } for pid=3359 comm="skype" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process ---- I'm willing to pester the vmware folks to get them to examine/fix this. Not sure how to do that with the skype folks ..... Any suggestions with either? tom -- Tom London From nicolas.mailhot at laposte.net Sun Dec 11 21:52:37 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Dec 2005 22:52:37 +0100 (CET) Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> Message-ID: <60416.81.64.157.3.1134337957.squirrel@rousalka.dyndns.org> On Dim 11 d?cembre 2005 22:35, Tom London wrote: > Running latest rawhide stuff, targeted/enforcing. > > Two 'after market' packages appear to need some help: skype and vmware. Seems some python bits and mplayer are not safe either : type=AVC msg=audit(1134326070.107:1325): avc: denied { execmem } for pid=28368 comm="mplayer" scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1134326070.107:1325): arch=c000003e syscall=10 success=no exit=-13 a0=7fffff8a5000 a1=1000 a2=1000007 a3=1 items=0 pid=28368 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mplayer" exe="/usr/bin/mplayer" type=AVC msg=audit(1134326066.831:1324): avc: denied { execmem } for pid=28361 comm="python" scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1134326066.831:1324): arch=c000003e syscall=10 success=no exit=-13 a0=7fffff863000 a1=1000 a2=1000007 a3=1 items=0 pid=28361 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="python" exe="/usr/bin/python" Oh, well I didn't have a http://bugzilla.livna.org/ account yet Regards, -- Nicolas Mailhot From drepper at redhat.com Sun Dec 11 22:02:52 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 11 Dec 2005 14:02:52 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> Message-ID: <439CA20C.7000704@redhat.com> Tom London wrote: > path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0" > type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000 This is indeed a text relocation issue. Since the code is LGPLed they have to provide you with the sources. Just use compile and use eu-findtextrel to determine the sources of the text relocation. > type=PATH msg=audit(1134331229.904:20): item=0 name="/usr/bin/skype" > flags=101 inode=145190 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=CWD msg=audit(1134331229.904:20): cwd="/home/tbl" > type=SYSCALL msg=audit(1134331229.904:20): arch=40000003 syscall=11 That's a fault in the execve syscall. This most likely means the binary has a section which is executable and writable at the same time. This really should never happen, it's a security nightmare. Would you want an application which by its nature has to accept connections from all over the net to have such a flaw? Maybe you can post the output of eu-readelf -l /usr/bin/skype -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From selinux at gmail.com Sun Dec 11 22:13:19 2005 From: selinux at gmail.com (Tom London) Date: Sun, 11 Dec 2005 14:13:19 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439CA20C.7000704@redhat.com> References: <4399EFE6.5040206@redhat.com> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> <439CA20C.7000704@redhat.com> Message-ID: <4c4ba1530512111413h7b6ca145oc1531c00bc7c71bb@mail.gmail.com> On 12/11/05, Ulrich Drepper wrote: > Tom London wrote: > > path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0" > > type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000 > > This is indeed a text relocation issue. Since the code is LGPLed they > have to provide you with the sources. Just use compile and use > eu-findtextrel to determine the sources of the text relocation. > > > > type=PATH msg=audit(1134331229.904:20): item=0 name="/usr/bin/skype" > > flags=101 inode=145190 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > > type=CWD msg=audit(1134331229.904:20): cwd="/home/tbl" > > type=SYSCALL msg=audit(1134331229.904:20): arch=40000003 syscall=11 > > That's a fault in the execve syscall. This most likely means the binary > has a section which is executable and writable at the same time. This > really should never happen, it's a security nightmare. Would you want > an application which by its nature has to accept connections from all > over the net to have such a flaw? > > Maybe you can post the output of > > eu-readelf -l /usr/bin/skype > > -- > ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? > Agree that its a security 'accident' waiting to happen. Here is the output of 'eu-readelf -l /usr/bin/skype' Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x000120 0x000120 R E 0x4 INTERP 0x000154 0x08048154 0x08048154 0x000013 0x000013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x7970f9 0x7970f9 RWE 0x1000 LOAD 0x7970fc 0x087e00fc 0x087e00fc 0x00bc68 0x101e44 RWE 0x1000 LOAD 0x7a2d64 0x088e2d64 0x088e2d64 0x016768 0x016768 RW 0x1000 DYNAMIC 0x7972c4 0x087e02c4 0x087e02c4 0x000108 0x000108 RW 0x4 NOTE 0x000168 0x08048168 0x08048168 0x000020 0x000020 R 0x4 GNU_EH_FRAME 0x7008ec 0x087488ec 0x087488ec 0x0108fc 0x0108fc R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .hash .dynsym .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table 03 .ctors .dtors .jcr .dynamic .got .got.plt .data .dynbss .bss 04 .dynstr .gnu.liblist .gnu.conflict 05 .dynamic 06 .note.ABI-tag 07 .eh_frame_hdr 08 -- Tom London From drepper at redhat.com Sun Dec 11 22:24:48 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 11 Dec 2005 14:24:48 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <60416.81.64.157.3.1134337957.squirrel@rousalka.dyndns.org> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> <60416.81.64.157.3.1134337957.squirrel@rousalka.dyndns.org> Message-ID: <439CA730.1060603@redhat.com> Nicolas Mailhot wrote: > Seems some python bits and mplayer are not safe either : You have to specify which architecture. I assume the following are x64 since otherwise syscall=10 makes no sense. > type=AVC msg=audit(1134326070.107:1325): avc: denied { execmem } for > pid=28368 comm="mplayer" > scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 > tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process > type=SYSCALL msg=audit(1134326070.107:1325): arch=c000003e syscall=10 > success=no exit=-13 a0=7fffff8a5000 a1=1000 a2=1000007 a3=1 items=0 > pid=28368 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="mplayer" exe="/usr/bin/mplayer" > > type=AVC msg=audit(1134326066.831:1324): avc: denied { execmem } for > pid=28361 comm="python" > scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 > tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process > type=SYSCALL msg=audit(1134326066.831:1324): arch=c000003e syscall=10 > success=no exit=-13 a0=7fffff863000 a1=1000 a2=1000007 a3=1 items=0 > pid=28361 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="python" exe="/usr/bin/python" Both a mprotect calls but because x64 does not allow text relocations the reason must be in the program logic. Definitely wrong code but what remains to be seen. Try using strace to determine what the programs try to do. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From drepper at redhat.com Sun Dec 11 22:28:21 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 11 Dec 2005 14:28:21 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <4c4ba1530512111413h7b6ca145oc1531c00bc7c71bb@mail.gmail.com> References: <4399EFE6.5040206@redhat.com> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> <439CA20C.7000704@redhat.com> <4c4ba1530512111413h7b6ca145oc1531c00bc7c71bb@mail.gmail.com> Message-ID: <439CA805.90107@redhat.com> Tom London wrote: > LOAD 0x000000 0x08048000 0x08048000 0x7970f9 0x7970f9 RWE 0x1000 > LOAD 0x7970fc 0x087e00fc 0x087e00fc 0x00bc68 0x101e44 RWE 0x1000 Wow, that's truly horribly bad. I would refrain from using that code until it's fixed. Somebody who cares might want to contact that company. Their build technology is very screwed. There is no reason to have two segments. It seems they modified the linker scripts without having the slightest bit of clue. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From selinux at gmail.com Sun Dec 11 22:53:30 2005 From: selinux at gmail.com (Tom London) Date: Sun, 11 Dec 2005 14:53:30 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439CA805.90107@redhat.com> References: <4399EFE6.5040206@redhat.com> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> <439CA20C.7000704@redhat.com> <4c4ba1530512111413h7b6ca145oc1531c00bc7c71bb@mail.gmail.com> <439CA805.90107@redhat.com> Message-ID: <4c4ba1530512111453n7e3ae32ay2bfe6b50c8a1c4c4@mail.gmail.com> On 12/11/05, Ulrich Drepper wrote: > Tom London wrote: > > LOAD 0x000000 0x08048000 0x08048000 0x7970f9 0x7970f9 RWE 0x1000 > > LOAD 0x7970fc 0x087e00fc 0x087e00fc 0x00bc68 0x101e44 RWE 0x1000 > > > Wow, that's truly horribly bad. I would refrain from using that code > until it's fixed. Somebody who cares might want to contact that > company. Their build technology is very screwed. There is no reason to > have two segments. It seems they modified the linker scripts without > having the slightest bit of clue. > OK, I posted this to the 'skype support' area of their website. I'll provide whatever updates I get...... Thanks for the help. tom -- Tom London From selinux at gmail.com Sun Dec 11 23:00:21 2005 From: selinux at gmail.com (Tom London) Date: Sun, 11 Dec 2005 15:00:21 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439CA20C.7000704@redhat.com> References: <4399EFE6.5040206@redhat.com> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> <439CA20C.7000704@redhat.com> Message-ID: <4c4ba1530512111500i52ecf9bas761c14cd727b805@mail.gmail.com> On 12/11/05, Ulrich Drepper wrote: > Tom London wrote: > > path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0" > > type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000 > > This is indeed a text relocation issue. Since the code is LGPLed they > have to provide you with the sources. Just use compile and use > eu-findtextrel to determine the sources of the text relocation. > For completeness: I've posted this problem to the vmware support/discussion group as well. Petr (support ultra wizard) is usually pretty good at responding. I'll post what I get...... tom -- Tom London From jorton at redhat.com Mon Dec 12 11:02:47 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 12 Dec 2005 11:02:47 +0000 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <4399EFE6.5040206@redhat.com> References: <4399EFE6.5040206@redhat.com> Message-ID: <20051212110247.GA25100@redhat.com> On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote: > > Currently policy allows httpd to connect to relay ports and to > mysql/postgres ports. > > Adding these booleans > * httpd_can_network_relay > * httpd_can_network_connect_db > > And turning this feature off by default. This is going into tonights > reference policy and into FC4 test release. Do you mean FC4 or FC5? This should not go in an FC4 update off-by-default since it will break working setups. Make it on-by-default if you want to ship this to FC4 users and off-by-default with a big release note for FC5. What's the difference between httpd_can_network_relay and httpd_can_network_connect? Do we still have the problem that httpd cannot reap idle children properly when the latter is set? That really really does need to work by default. joe From craigwhite at azapple.com Mon Dec 12 12:55:32 2005 From: craigwhite at azapple.com (Craig White) Date: Mon, 12 Dec 2005 05:55:32 -0700 Subject: issue with named Message-ID: <1134392133.17649.23.camel@lin-workstation.azapple.com> from /var/log/messages Dec 12 05:11:48 srv1 named[18083]: /var/named/clsurvey.com.hosts.jnl: create: permission denied Dec 12 05:11:48 srv1 kernel: audit(1134389508.478:0): avc: denied { add_name } for pid=18084 comm=named name=clsurvey.com.hosts.jnl scontext=root:system_r:named_t tcontext=system_u:object_r:named_zone_t tclass=dir Dec 12 05:11:48 srv1 named[18083]: client 192.168.1.1#33259: updating zone 'clsurvey.com/IN': error: journal open failed: unexpected error I have added to /etc/selinux/targeted/src/policy/domains/local.te allow named_t named_zone_t:dir write; and then make reload but the problem doesn't go away. Suggestions? Thanks Craig From sds at tycho.nsa.gov Mon Dec 12 15:00:46 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 12 Dec 2005 10:00:46 -0500 Subject: sandboxing rpms In-Reply-To: <291399270512081415m4ff9c59al70c3032fdb72a4c8@mail.gmail.com> References: <291399270512081415m4ff9c59al70c3032fdb72a4c8@mail.gmail.com> Message-ID: <1134399646.7305.56.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-12-08 at 16:15 -0600, Benjamin Youngdahl wrote: > Greetings. > > My understanding is that RPM packages will be able to install policy > modules in FC5, an improvement over a monolithic policy. I have a > couple of questions about the implementation: > > 1. Is it possible to provide a temporary policy (either external, or > with an RPM) that constains what the specific RPM's installation can > do? > > The motivation here is that when I install an RPM, it would be nice if > I would be able to get a declarative list of what the RPM wants access > to do. The RPM tool might summarize before installing the package > what the package will be allowed to do, by parsing this "installation > sandbox" policy. Not yet. > 2. Is it possible to limit (or discover easily in advance) what > changes to the system policy are being made by the RPM's policy > modules? > > The motivation being that I want to be sure that the policy modules > installed by an RPM are well behaved concerning overall system > constraints. > > Apologies in advance if these questions are way off-base, or belong > somewhere else. When a module is installed, the base policy assertions (defined by neverallow statements in the base policy) are re-checked and the module is rejected if it invalidates one of those assertions. Further, libsemanage can be configured to execute verification programs at certain steps in the process of installing a new module to check properties on the resulting policy. Such verification programs remain to be written. The policy language also now supports a notion of hierarchical roles and types, where type a.b is strictly limited to a subset of the permissions granted to type a, to allow portions of the policy to be reasonably delegated. Ongoing work on a policy management server will provide a way to perform fine-grained access control over policy, but that won't be in FC5. -- Stephen Smalley National Security Agency From himainu-ynakam at miomio.jp Mon Dec 12 15:00:40 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 12 Dec 2005 10:00:40 -0500 Subject: Where is policy source? Message-ID: <200512121500.jBCF0hQT011242@mms-r00.iijmio.jp> Hi. I've begun to try Rawhide. I installed FC5-test1 and did yum update. Policy is now reference policy(selinux-policy-targeted-2.1.2-2). However, I can not find selinux-policy-targeted-source package for refpolicy. Where is policy source? How do I edit policy? --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) SELinux Policy Editor: http://seedit.sourceforge.net/ From sds at tycho.nsa.gov Mon Dec 12 15:22:15 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 12 Dec 2005 10:22:15 -0500 Subject: Interesting reading on exec* access checks. In-Reply-To: <4398A5AD.2010701@redhat.com> References: <4398A5AD.2010701@redhat.com> Message-ID: <1134400935.7305.64.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-12-08 at 16:29 -0500, Daniel J Walsh wrote: > http://people.redhat.com/drepper/selinux-mem.html The description of execmem says: "The solution for the anonymous case is to create the memory region without execution permission and then, when the wanted content is created, change the permission to include PROT_EXEC but not PROT_WRITE." But this will still trigger an execmem check, as the check is applied upon mmap or mprotect for anonymous mappings with PROT_EXEC, irrespective of PROT_WRITE, in order to control the ability to execute arbitrary memory (not just to control the ability to execute currently writable memory). In the case of private file mappings, it is handled differently, with execmem only applied upon mmap or mprotect with PROT_EXEC and PROT_WRITE simultaneously, and execmod applied upon PROT_EXEC by itself after a prior modification. > We are planning on turning off allow_execmem, allow_execmod, > allow_execheap for unconfined_t in targeted policy. We are working to > clean up any problems this might cause. This will add additional > security features to Userspace, but might cause headaches. > > If you have the latest policy installed on Rawhide > > selinux-policy-targeted-2.1.0-3 or later you can try it out by running > > setsebool -P allow_execmem=0 allow_execmod=0 allow_execheap=0 There is no allow_execheap, but there is an allow_execstack. Note that turning off allow_execmem should also disable execstack; execmem covers a superset of what execstack covers. If you need runtime code generation, you can enable execmem while disabling execstack to retain protection of the stack while permitting generation of code to other anonymous memory. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Dec 12 15:31:28 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 12 Dec 2005 10:31:28 -0500 Subject: Where is policy source? In-Reply-To: <200512121500.jBCF0hQT011242@mms-r00.iijmio.jp> References: <200512121500.jBCF0hQT011242@mms-r00.iijmio.jp> Message-ID: <1134401488.7305.69.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-12-12 at 10:00 -0500, Yuichi Nakamura wrote: > Hi. > > I've begun to try Rawhide. > I installed FC5-test1 and did yum update. > Policy is now reference policy(selinux-policy-targeted-2.1.2-2). > However, I can not find selinux-policy-targeted-source package for refpolicy. > Where is policy source? > How do I edit policy? Policy sources are now only available via the .src.rpm file; it is no longer necessary or desirable to have a separate selinux-policy-targeted-sources package. If you just want to add policy, you can generate local policy separately, build it as a module, and install the module without needing the base policy sources. See the EXAMPLE section of the updated audit2allow man page, along with the man pages for checkmodule, semodule_package, and semodule. We still need to have the reference policy install its interfaces files somewhere standard ala /usr/include so that we can write policy modules that use those interfaces without needing the .src.rpm for the base policy. -- Stephen Smalley National Security Agency From himainu-ynakam at miomio.jp Mon Dec 12 16:46:49 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 12 Dec 2005 11:46:49 -0500 Subject: Where is policy source? In-Reply-To: <1134401488.7305.69.camel@moss-spartans.epoch.ncsc.mil> References: <1134401488.7305.69.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200512121646.jBCGkq3B016826@mms-r00.iijmio.jp> Stephen Smalley wrote: > Policy sources are now only available via the .src.rpm file; it is no > longer necessary or desirable to have a separate > selinux-policy-targeted-sources package. > > If you just want to add policy, you can generate local policy > separately, build it as a module, and install the module without needing > the base policy sources. See the EXAMPLE section of the updated > audit2allow man page, along with the man pages for checkmodule, > semodule_package, and semodule. > > We still need to have the reference policy install its interfaces files > somewhere standard ala /usr/include so that we can write policy modules > that use those interfaces without needing the .src.rpm for the base > policy. Thank you for information. I am surprized at many changes, but I will study them and if find something interesting, I will post. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) SELinux Policy Editor: http://seedit.sourceforge.net/ From robin-lists at robinbowes.com Mon Dec 12 16:47:54 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Mon, 12 Dec 2005 16:47:54 +0000 Subject: Making httpd work with trac and svn Message-ID: Hi, I'm using httpd, trac, and svn on FC4 with svnmailer providing svn commit notifications. I've found I have to add the following local policies to allow this combination to work: # Needed to allow httpd to send ticket notifications via # direct connection to smtp port as httpd user allow httpd_t smtp_port_t:tcp_socket name_connect; # Needed to allow svnmailer to execute and send commit notifications # using sendmail as httpd user allow httpd_t trac_var_t:file execute; allow httpd_t trac_var_t:file execute_no_trans; allow restorecon_t devpts_t:chr_file getattr; allow httpd_t sbin_t:lnk_file read; Is there a better way to do this, i.e. without adding these missing TEs? R. From himainu-ynakam at miomio.jp Mon Dec 12 17:03:37 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 12 Dec 2005 12:03:37 -0500 Subject: Interesting reading on exec* access checks. In-Reply-To: <4398A5AD.2010701@redhat.com> References: <4398A5AD.2010701@redhat.com> Message-ID: <200512121703.jBCH3eEg017497@mms-r00.iijmio.jp> Daniel J Walsh wrote: > http://people.redhat.com/drepper/selinux-mem.html I have basic question about these permissions. Fedora Core already have "Exec Shield" to prevent execution of malicious code on memory. I can not understand relationship between exec shield and these permissions. What is good point of these permissions? In other words, I would like to know "Attack that can not be prevented by exec shield, but can be prevented by these permissions(exec* permissions)". Does anyone know ? Yuichi Nakamura From sds at tycho.nsa.gov Mon Dec 12 17:27:07 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 12 Dec 2005 12:27:07 -0500 Subject: Interesting reading on exec* access checks. In-Reply-To: <200512121703.jBCH3eEg017497@mms-r00.iijmio.jp> References: <4398A5AD.2010701@redhat.com> <200512121703.jBCH3eEg017497@mms-r00.iijmio.jp> Message-ID: <1134408427.7305.123.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-12-12 at 12:03 -0500, Yuichi Nakamura wrote: > Daniel J Walsh wrote: > > http://people.redhat.com/drepper/selinux-mem.html > I have basic question about these permissions. > Fedora Core already have "Exec Shield" to prevent execution of malicious code on memory. > I can not understand relationship between exec shield and these permissions. > What is good point of these permissions? > In other words, > I would like to know > "Attack that can not be prevented by exec shield, > but can be prevented by these permissions(exec* permissions)". > > Does anyone know ? exec-shield is a mechanism that approximates NX support, but does not define policy, so it cannot differentiate between a legitimate application request for executable memory from the same request induced by malicious code. The SELinux exec* checks provide a way to apply policy control over what processes can mmap/mprotect memory with PROT_EXEC. With just exec-shield, you lack protection against explicit PROT_EXEC mmap/mprotect requests induced by malicious code; with just SELinux exec* checking, you lack a mechanism to enforce NX (unless you have hardware NX support), so the SELinux checking by itself is not very useful. exec-shield by itself provides some useful protection; coupled with the SELinux checks, you get stronger protection. Example of the difference in paxtest output (with dummy function moved to outer scope) before and after turning of the SELinux booleans for exec*: Executable data : Killed Executable heap : Killed Executable stack : Killed -Executable anonymous mapping (mprotect) : Vulnerable -Executable bss (mprotect) : Vulnerable -Executable data (mprotect) : Vulnerable -Executable heap (mprotect) : Vulnerable -Executable shared library bss (mprotect) : Vulnerable -Executable shared library data (mprotect): Vulnerable -Executable stack (mprotect) : Vulnerable +Executable anonymous mapping (mprotect) : Killed +Executable bss (mprotect) : Killed +Executable data (mprotect) : Killed +Executable heap (mprotect) : Killed +Executable shared library bss (mprotect) : Killed +Executable shared library data (mprotect): Killed +Executable stack (mprotect) : Killed -Writable text segments : Vulnerable +Writable text segments : Killed -- Stephen Smalley National Security Agency From lamont at gurulabs.com Mon Dec 12 17:30:49 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Mon, 12 Dec 2005 10:30:49 -0700 Subject: issue with named In-Reply-To: <1134392133.17649.23.camel@lin-workstation.azapple.com> References: <1134392133.17649.23.camel@lin-workstation.azapple.com> Message-ID: <200512121030.53410.lamont@gurulabs.com> On Monday 12 December 2005 05:55am, Craig White wrote: > from /var/log/messages > > Dec 12 05:11:48 srv1 named[18083]: /var/named/clsurvey.com.hosts.jnl: > create: permission denied Have you flipped the named_write_master_zones boolean? > Dec 12 05:11:48 srv1 kernel: audit(1134389508.478:0): avc: denied > { add_name } for pid=18084 comm=named name=clsurvey.com.hosts.jnl > scontext=root:system_r:named_t tcontext=system_u:object_r:named_zone_t > tclass=dir > > Dec 12 05:11:48 srv1 named[18083]: client 192.168.1.1#33259: updating > zone 'clsurvey.com/IN': error: journal open failed: unexpected error > > I have added to /etc/selinux/targeted/src/policy/domains/local.te > allow named_t named_zone_t:dir write; > > and then make reload but the problem doesn't go away. > > Suggestions? > > Thanks HTH. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From craigwhite at azapple.com Mon Dec 12 17:45:05 2005 From: craigwhite at azapple.com (Craig White) Date: Mon, 12 Dec 2005 10:45:05 -0700 Subject: issue with named In-Reply-To: <200512121030.53410.lamont@gurulabs.com> References: <1134392133.17649.23.camel@lin-workstation.azapple.com> <200512121030.53410.lamont@gurulabs.com> Message-ID: <1134409505.17649.31.camel@lin-workstation.azapple.com> On Mon, 2005-12-12 at 10:30 -0700, Lamont R. Peterson wrote: > On Monday 12 December 2005 05:55am, Craig White wrote: > > from /var/log/messages > > > > Dec 12 05:11:48 srv1 named[18083]: /var/named/clsurvey.com.hosts.jnl: > > create: permission denied > > Have you flipped the named_write_master_zones boolean? ---- I haven't done anything other than create the entries that I listed in local.te and reload the policy. How do I 'flipp the named_write_master_zones boolean? ---- > > > Dec 12 05:11:48 srv1 kernel: audit(1134389508.478:0): avc: denied > > { add_name } for pid=18084 comm=named name=clsurvey.com.hosts.jnl > > scontext=root:system_r:named_t tcontext=system_u:object_r:named_zone_t > > tclass=dir > > > > Dec 12 05:11:48 srv1 named[18083]: client 192.168.1.1#33259: updating > > zone 'clsurvey.com/IN': error: journal open failed: unexpected error > > > > I have added to /etc/selinux/targeted/src/policy/domains/local.te > > allow named_t named_zone_t:dir write; > > > > and then make reload but the problem doesn't go away. > > > > Suggestions? > > > > Thanks > > HTH. ---- it just pointed out another of the infinite things I don't understand. Thanks Craig From lamont at gurulabs.com Mon Dec 12 18:29:28 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Mon, 12 Dec 2005 11:29:28 -0700 Subject: issue with named In-Reply-To: <1134409505.17649.31.camel@lin-workstation.azapple.com> References: <1134392133.17649.23.camel@lin-workstation.azapple.com> <200512121030.53410.lamont@gurulabs.com> <1134409505.17649.31.camel@lin-workstation.azapple.com> Message-ID: <200512121129.33408.lamont@gurulabs.com> On Monday 12 December 2005 10:45am, Craig White wrote: > On Mon, 2005-12-12 at 10:30 -0700, Lamont R. Peterson wrote: > > On Monday 12 December 2005 05:55am, Craig White wrote: > > > from /var/log/messages > > > > > > Dec 12 05:11:48 srv1 named[18083]: /var/named/clsurvey.com.hosts.jnl: > > > create: permission denied > > > > Have you flipped the named_write_master_zones boolean? > > ---- > I haven't done anything other than create the entries that I listed in > local.te and reload the policy. How do I 'flipp the > named_write_master_zones boolean? > ---- As root (of course), run: # getsebool named_write_master_zones named_write_master_zones --> inactive If it says "inactive" (------^^^^^^^^), then run: # setsebool named_write_master_zones 1 Use "getsebool -a" to see the available booleans. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cpebenito at tresys.com Mon Dec 12 19:27:57 2005 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Mon, 12 Dec 2005 14:27:57 -0500 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> Message-ID: <1134415677.16519.53.camel@sgc> On Sat, 2005-12-10 at 20:08 +0100, Nicolas Mailhot wrote: > How about having selinux play nice with spamassassin at last ? > > It's still not able to create resolver sockets > "Error creating a DNS resolver socket" This is fixed upstream. > or writing in its own files > > cannot create tmp lockfile ~/.spamassassin/bayes.lock.xxx > cannot write to ~/.spamassassin/user_pref You didn't say what the denial was. I went looking, and only found this on the mail list: On Sun, 2005-11-20 at 08:52 -0700, W. Scott Wilburn wrote: > Nov 20 04:05:44 scooby kernel: audit(1132484744.807:45387): avc: denied > { search } for pid=25548 comm="spamd" name=".spamassassin" dev=md0 > ino=2197675 scontext=root:system_r:spamd_t > tcontext=user_u:object_r:user_home_t tclass=dir Is this the denial that corresponds to the messages you have above? > Or else fix fstab-sync > > avc: denied { getattr } for pid=2572 comm="fstab-sync" name="/" > dev=tmpfs ino=5287 scontext=system_u:system_r:updfstab_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir Fixed upstream. > or gpm > > avc: denied { write } for pid=2420 comm="gpm" name="mice" dev=tmpfs > ino=4118 scontext=system_u:system_r:gpm_t:s0 > tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file Fixed upstream. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From nicolas.mailhot at laposte.net Mon Dec 12 20:00:26 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Dec 2005 21:00:26 +0100 (CET) Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439CA730.1060603@redhat.com> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <439B3CA5.4080009@redhat.com> <56950.81.64.157.3.1134248366.squirrel@rousalka.dyndns.org> <59103.81.64.157.3.1134249016.squirrel@rousalka.dyndns.org> <439B4C3B.40601@redhat.com> <56009.81.64.157.3.1134251457.squirrel@rousalka.dyndns.org> <4c4ba1530512111335w67b8429bo6312c523520e2bf7@mail.gmail.com> <60416.81.64.157.3.1134337957.squirrel@rousalka.dyndns.org> <439CA730.1060603@redhat.com> Message-ID: <48000.81.64.157.3.1134417626.squirrel@rousalka.dyndns.org> On Dim 11 d?cembre 2005 23:24, Ulrich Drepper wrote: > Nicolas Mailhot wrote: >> Seems some python bits and mplayer are not safe either : > > You have to specify which architecture. I assume the following are x64 > since otherwise syscall=10 makes no sense. x86_64 >> type=AVC msg=audit(1134326070.107:1325): avc: denied { execmem } for >> pid=28368 comm="mplayer" >> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 >> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process >> type=SYSCALL msg=audit(1134326070.107:1325): arch=c000003e syscall=10 >> success=no exit=-13 a0=7fffff8a5000 a1=1000 a2=1000007 a3=1 items=0 >> pid=28368 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="mplayer" exe="/usr/bin/mplayer" >> >> type=AVC msg=audit(1134326066.831:1324): avc: denied { execmem } for >> pid=28361 comm="python" >> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 >> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process >> type=SYSCALL msg=audit(1134326066.831:1324): arch=c000003e syscall=10 >> success=no exit=-13 a0=7fffff863000 a1=1000 a2=1000007 a3=1 items=0 >> pid=28361 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 >> egid=500 sgid=500 fsgid=500 comm="python" exe="/usr/bin/python" > > Both a mprotect calls but because x64 does not allow text relocations > the reason must be in the program logic. Definitely wrong code but what > remains to be seen. > > Try using strace to determine what the programs try to do. I will try to isolate the problem. This was just a quick scan of yesterday's audit.log. I installed a lot of new python packages at that time, so pinpointing the problem is going to take some time. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Dec 12 20:06:00 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Dec 2005 21:06:00 +0100 (CET) Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <1134415677.16519.53.camel@sgc> References: <4399EFE6.5040206@redhat.com> <439AE93A.3000302@exinor.net> <439B068B.4070402@laposte.net> <439B1641.3010900@redhat.com> <38552.81.64.157.3.1134241700.squirrel@rousalka.dyndns.org> <1134415677.16519.53.camel@sgc> Message-ID: <49102.81.64.157.3.1134417960.squirrel@rousalka.dyndns.org> On Lun 12 d?cembre 2005 20:27, Christopher J. PeBenito wrote: > On Sat, 2005-12-10 at 20:08 +0100, Nicolas Mailhot wrote: >> How about having selinux play nice with spamassassin at last ? >> >> It's still not able to create resolver sockets >> "Error creating a DNS resolver socket" > > This is fixed upstream. I think it is in spamd context but not in procmail context. >> or writing in its own files >> >> cannot create tmp lockfile ~/.spamassassin/bayes.lock.xxx >> cannot write to ~/.spamassassin/user_pref > > You didn't say what the denial was. A lot of traces where attached in redhat bugzilla entries. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172088 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172496 They no longuer appear in audit.log - I suspect /homes accesses are now filtered by default (when the problem was first reported a few weeks ago they did appear as AVCs) The tricky bit is most of them are executed for the home user, but in procmail context. Regards, -- Nicolas Mailhot From steve at atc-nycorp.com Mon Dec 12 21:03:30 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Mon, 12 Dec 2005 16:03:30 -0500 Subject: default deny for uncofined_t using targeted? Message-ID: <60D45469A1AAD311A04C009027B6BF680591445F@server20.inside.oracorp.com> Stephen Smalley wrote: > On Fri, 2005-11-18 at 15:17 +0000, Paul Howarth wrote: >> Won't that kill all network access, including via localhost, rather >> than just eth0 access? > > Well, yes, good point ;) > > Also looks like Dan reworked the old netifcon statements and netif > types as part of the network macro work. > > Ok, so one approach might be to: > - Add a netifcon statement to policy/net_contexts (between the > portcon entries and the nodecon entries) to distinguish eth0: > netifcon eth0 system_u:object_r:netif_eth0_t > system_u:object_r:unlabeled_t - Add the type to > policy/types/network.te (or anywhere in the policy): type > netif_eth0_t, netif_type; - Change the allow rule in > unconfined_domain from allow $1 netif_type:netif *; > to: > allow $1 netif_t:netif *; > so that unconfined_t no longer gets access to all netif types, just > the default one (which covers loopback). > > Looks like macros/network_macros.te already limits itself to > netif_t:netif, so it will also cease granting access to eth0 when you > make the above changes without needing to modify the macro itself. Well this seemed to be working, but then something strange happened. I wanted ssh to work over eth0, so I added this to domains/program/ssh.te: auditallow sshd_t netif_type:netif *; allow sshd_t netif_type:netif *; This single change allowed ssh to use eth0, but apparently it also allows anything in unconfined_t to access eth0 also! For example, when I run nmap 192.168.1.109 it is no longer blocked: type=AVC msg=audit(1134421016.167:1744): avc: granted { rawip_send } for pid=2854 comm="nmap" saddr=192.168.1.80 src=55724 daddr=192.168.1.209 dest=1502 netif=eth0 scontext=root:system_r:unconfined_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Am I missing something fundamental or is this a bug? It seems to me that giving sshd_t access to eth0 shouldn't also cause everyone in unconfined_t to have access to eth0. Thanks for your help so far, Stephen Brueckner, ATC-NY From cochranb at speakeasy.net Tue Dec 13 01:29:23 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Mon, 12 Dec 2005 20:29:23 -0500 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <20051212110247.GA25100@redhat.com> References: <4399EFE6.5040206@redhat.com> <20051212110247.GA25100@redhat.com> Message-ID: <439E23F3.7090709@speakeasy.net> Joe Orton wrote: >On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote: > > >>Currently policy allows httpd to connect to relay ports and to >>mysql/postgres ports. >> >>Adding these booleans >> * httpd_can_network_relay >> * httpd_can_network_connect_db >> >>And turning this feature off by default. This is going into tonights >>reference policy and into FC4 test release. >> >> > >Do you mean FC4 or FC5? This should not go in an FC4 update >off-by-default since it will break working setups. Make it >on-by-default if you want to ship this to FC4 users and off-by-default >with a big release note for FC5. > >What's the difference between httpd_can_network_relay and >httpd_can_network_connect? > >Do we still have the problem that httpd cannot reap idle children >properly when the latter is set? That really really does need to work >by default. > >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > I'd like to completely agree with Joe. I'm beginning to have quite a lot invested in httpd, PHP and related database code and I don't want SELinux breaking what is there without a lot of warning. For new installs of FC4, I've been forced to turn off SELinux support for these applications. They simply don't work otherwise. Bob Cochran Greenbelt. Maryland, USA From dwalsh at redhat.com Tue Dec 13 03:39:17 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Dec 2005 22:39:17 -0500 Subject: default deny for uncofined_t using targeted? In-Reply-To: <60D45469A1AAD311A04C009027B6BF680591445F@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF680591445F@server20.inside.oracorp.com> Message-ID: <439E4265.1040006@redhat.com> Steve Brueckner wrote: > Stephen Smalley wrote: > >> On Fri, 2005-11-18 at 15:17 +0000, Paul Howarth wrote: >> >>> Won't that kill all network access, including via localhost, rather >>> than just eth0 access? >>> >> Well, yes, good point ;) >> >> Also looks like Dan reworked the old netifcon statements and netif >> types as part of the network macro work. >> >> Ok, so one approach might be to: >> - Add a netifcon statement to policy/net_contexts (between the >> portcon entries and the nodecon entries) to distinguish eth0: >> netifcon eth0 system_u:object_r:netif_eth0_t >> system_u:object_r:unlabeled_t - Add the type to >> policy/types/network.te (or anywhere in the policy): type >> netif_eth0_t, netif_type; - Change the allow rule in >> unconfined_domain from allow $1 netif_type:netif *; >> to: >> allow $1 netif_t:netif *; >> so that unconfined_t no longer gets access to all netif types, just >> the default one (which covers loopback). >> >> Looks like macros/network_macros.te already limits itself to >> netif_t:netif, so it will also cease granting access to eth0 when you >> make the above changes without needing to modify the macro itself. >> > > Well this seemed to be working, but then something strange happened. I > wanted ssh to work over eth0, so I added this to domains/program/ssh.te: > auditallow sshd_t netif_type:netif *; > allow sshd_t netif_type:netif *; > > This single change allowed ssh to use eth0, but apparently it also allows > anything in unconfined_t to access eth0 also! For example, when I run nmap > 192.168.1.109 it is no longer blocked: > > type=AVC msg=audit(1134421016.167:1744): avc: granted { rawip_send } for > pid=2854 comm="nmap" saddr=192.168.1.80 src=55724 daddr=192.168.1.209 > dest=1502 netif=eth0 scontext=root:system_r:unconfined_t > tcontext=system_u:object_r:netif_eth0_t tclass=netif > > Am I missing something fundamental or is this a bug? It seems to me that > giving sshd_t access to eth0 shouldn't also cause everyone in unconfined_t > to have access to eth0. > > sshd_t is an alias for unconfined_t, in targeted policy. > Thanks for your help so far, > > Stephen Brueckner, ATC-NY > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From dwalsh at redhat.com Tue Dec 13 04:14:35 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Dec 2005 23:14:35 -0500 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <20051212110247.GA25100@redhat.com> References: <4399EFE6.5040206@redhat.com> <20051212110247.GA25100@redhat.com> Message-ID: <439E4AAB.2080406@redhat.com> Joe Orton wrote: > On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote: > >> Currently policy allows httpd to connect to relay ports and to >> mysql/postgres ports. >> >> Adding these booleans >> * httpd_can_network_relay >> * httpd_can_network_connect_db >> >> And turning this feature off by default. This is going into tonights >> reference policy and into FC4 test release. >> > > Do you mean FC4 or FC5? This should not go in an FC4 update > off-by-default since it will break working setups. Make it > on-by-default if you want to ship this to FC4 users and off-by-default > with a big release note for FC5. > Ok plan is to add this to FC4 With relay and database network connect turned on by default. > What's the difference between httpd_can_network_relay and > httpd_can_network_connect? > They are just more specific. They allow specific connections to relay ports (http, ftp, gopher etc) and database ports (mysql and postgres). > Do we still have the problem that httpd cannot reap idle children > properly when the latter is set? That really really does need to work > by default. > > Do you have a bugzilla for this? > joe > -- From dwalsh at redhat.com Tue Dec 13 04:15:50 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Dec 2005 23:15:50 -0500 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439E23F3.7090709@speakeasy.net> References: <4399EFE6.5040206@redhat.com> <20051212110247.GA25100@redhat.com> <439E23F3.7090709@speakeasy.net> Message-ID: <439E4AF6.40403@redhat.com> Robert L Cochran wrote: > Joe Orton wrote: > >> On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote: >> >> >>> Currently policy allows httpd to connect to relay ports and to >>> mysql/postgres ports. >>> >>> Adding these booleans >>> * httpd_can_network_relay >>> * httpd_can_network_connect_db >>> >>> And turning this feature off by default. This is going into >>> tonights reference policy and into FC4 test release. >>> >> >> Do you mean FC4 or FC5? This should not go in an FC4 update >> off-by-default since it will break working setups. Make it >> on-by-default if you want to ship this to FC4 users and >> off-by-default with a big release note for FC5. >> >> What's the difference between httpd_can_network_relay and >> httpd_can_network_connect? >> >> Do we still have the problem that httpd cannot reap idle children >> properly when the latter is set? That really really does need to >> work by default. >> >> joe >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >> > I'd like to completely agree with Joe. I'm beginning to have quite a > lot invested in httpd, PHP and related database code and I don't want > SELinux breaking what is there without a lot of warning. For new > installs of FC4, I've been forced to turn off SELinux support for > these applications. They simply don't work otherwise. > > Bob Cochran > Greenbelt. Maryland, USA > > Have your reported your problems here or in bugzilla? -- From dwalsh at redhat.com Tue Dec 13 04:39:12 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Dec 2005 23:39:12 -0500 Subject: issue with named In-Reply-To: <200512121129.33408.lamont@gurulabs.com> References: <1134392133.17649.23.camel@lin-workstation.azapple.com> <200512121030.53410.lamont@gurulabs.com> <1134409505.17649.31.camel@lin-workstation.azapple.com> <200512121129.33408.lamont@gurulabs.com> Message-ID: <439E5070.1090606@redhat.com> Lamont R. Peterson wrote: > On Monday 12 December 2005 10:45am, Craig White wrote: > >> On Mon, 2005-12-12 at 10:30 -0700, Lamont R. Peterson wrote: >> >>> On Monday 12 December 2005 05:55am, Craig White wrote: >>> >>>> from /var/log/messages >>>> >>>> Dec 12 05:11:48 srv1 named[18083]: /var/named/clsurvey.com.hosts.jnl: >>>> create: permission denied >>>> >>> Have you flipped the named_write_master_zones boolean? >>> >> ---- >> I haven't done anything other than create the entries that I listed in >> local.te and reload the policy. How do I 'flipp the >> named_write_master_zones boolean? >> ---- >> > > As root (of course), run: > # getsebool named_write_master_zones > named_write_master_zones --> inactive > > If it says "inactive" (------^^^^^^^^), then run: > # setsebool named_write_master_zones 1 > > Use "getsebool -a" to see the available booleans. > [snip] > > Use setseboop -P named_write_master_zones 1 To make it permanent. > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Tue Dec 13 04:44:01 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Dec 2005 23:44:01 -0500 Subject: Making httpd work with trac and svn In-Reply-To: References: Message-ID: <439E5191.8070302@redhat.com> Robin Bowes wrote: > Hi, > > I'm using httpd, trac, and svn on FC4 with svnmailer providing svn > commit notifications. > > I've found I have to add the following local policies to allow this > combination to work: > > # Needed to allow httpd to send ticket notifications via > # direct connection to smtp port as httpd user > allow httpd_t smtp_port_t:tcp_socket name_connect; > > # Needed to allow svnmailer to execute and send commit notifications > # using sendmail as httpd user > allow httpd_t trac_var_t:file execute; > allow httpd_t trac_var_t:file execute_no_trans; > What is trac_var_t? > allow restorecon_t devpts_t:chr_file getattr; > allow httpd_t sbin_t:lnk_file read; > > Is there a better way to do this, i.e. without adding these missing TEs? > > R. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From robin-lists at robinbowes.com Tue Dec 13 11:17:03 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Tue, 13 Dec 2005 11:17:03 +0000 Subject: Making httpd work with trac and svn In-Reply-To: <439E5191.8070302@redhat.com> References: <439E5191.8070302@redhat.com> Message-ID: Daniel J Walsh said the following on 13/12/2005 04:44: > Robin Bowes wrote: >> # Needed to allow svnmailer to execute and send commit notifications >> # using sendmail as httpd user >> allow httpd_t trac_var_t:file execute; >> allow httpd_t trac_var_t:file execute_no_trans; >> > > What is trac_var_t? > >> allow restorecon_t devpts_t:chr_file getattr; >> allow httpd_t sbin_t:lnk_file read; >> I followed the instructions here [1] to set up trac to work with SELinux. [1] http://projects.edgewall.com/trac/wiki/TracWithSeLinux trac_var_t is a file type creagted by the SELinux config listed on that site. R. From selinux at gmail.com Tue Dec 13 14:46:55 2005 From: selinux at gmail.com (Tom London) Date: Tue, 13 Dec 2005 06:46:55 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439E4AF6.40403@redhat.com> References: <4399EFE6.5040206@redhat.com> <20051212110247.GA25100@redhat.com> <439E23F3.7090709@speakeasy.net> <439E4AF6.40403@redhat.com> Message-ID: <4c4ba1530512130646i3a9b0dd7v5935599dbdd43111@mail.gmail.com> VMWare has problems with execmem as previously reported: type=AVC msg=audit(1134338328.000:56): avc: denied { execmem } for pid=5215 comm="ld-linux.so.2" scontext=root:system_r:unconfined_t:s0-s0:c0.c255 tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1134338328.000:56): arch=40000003 syscall=125 success=no exit=-13 a0=bfc78000 a1=1000 a2=1000007 a3=98b6e0 items=0 pid=5215 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ld-linux.so.2" exe="/lib/ld-2.3.90.so" and time->Sun Dec 11 13:05:51 2005 type=AVC_PATH msg=audit(1134335151.660:39): path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0" type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000 success=no exit=-13 a0=b7c99000 a1=7b000 a2=5 a3=bfc5a1e0 items=0 pid=4418 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="vmware" exe="/usr/lib/vmware/bin/vmware" type=AVC msg=audit(1134335151.660:39): avc: denied { execmod } for pid=4418 comm="vmware" name="libgdk-x11-2.0.so.0" dev=dm-0 ino=343461 scontext=root:system_r:unconfined_t:s0-s0:c0.c255 tcontext=system_u:object_r:lib_t:s0 tclass=file Reply from VMware on my complaint about execmem issues: As your system refuses to execute even /lib/ld-2.3.90.so (if I understand it correctly), you seems to have some problem... None of VMware parts (at least I believe) require executable stack or heap. Applications which need it explicitly call mmap with PROT_EXEC. Another question is whether libraries we ship are correctly tagged to signal this - but it should not be problem as you can install all libraries VMware needs from your distribution, VMware just ships libraries it was linked with as it is simpler for us to ship you libgdk-whatever than (finding and) explaining that you must to install some-strange-package-with-no-gdk-in-filename to get VMware to work. On "correct" system with all libraries you should be able to run vmware directly by /usr/lib/vmware/bin/vmware. Apparently your system is missing at least openssl097... -------------------------------------------- My understanding from this thread on how execmem works is that calling mmap with PROT_EXEC can (will?) still trigger execmem. Right? Here is the link to the discussion thread: Please hop on to help/clarify! http://www.vmware.com/community/thread.jspa?messageID=320149񎊕 thanks, tom -- Tom London From fredit at charter.net Tue Dec 13 16:00:16 2005 From: fredit at charter.net (Pigeon) Date: Tue, 13 Dec 2005 11:00:16 -0500 Subject: How to setup a single user with almost no rights... References: <438C84F1.2030706@redhat.com> Message-ID: <005e01c5fffe$50c8a530$020a0a0a@desktop> Hello, sorry for the newbie question.. but I have tried not to ask in here and google/read books/manuals before i asked... How can I have a user that (when they ssh in) only has access to 1 or 2 predefinied dirs? (outside his home dir). I know so far I have to: -create user seuseradd -create user role -create domain -change type of the dir I want user access to -give new domain rights to access to these new dir type(s) Does this sound right? Any help on the syntax :/ thanks! From mike at plan99.net Tue Dec 13 17:03:34 2005 From: mike at plan99.net (Mike Hearn) Date: Tue, 13 Dec 2005 17:03:34 +0000 Subject: Interesting reading on exec* access checks. References: <4398A5AD.2010701@redhat.com> <200512121703.jBCH3eEg017497@mms-r00.iijmio.jp> <1134408427.7305.123.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mon, 12 Dec 2005 12:27:07 -0500, Stephen Smalley wrote: > exec-shield is a mechanism that approximates NX support, but does not > define policy, so it cannot differentiate between a legitimate > application request for executable memory from the same request induced > by malicious code I thought that in order to get malicious code into a running program with any degree of reliability you need to know its VMA layout, and execshield prevents that. So how can you do attacks like this with execshield enabled? thanks -mike From linux_4ever at yahoo.com Tue Dec 13 18:37:16 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 13 Dec 2005 10:37:16 -0800 (PST) Subject: Interesting reading on exec* access checks. In-Reply-To: Message-ID: <20051213183716.28428.qmail@web51502.mail.yahoo.com> >So how can you do attacks like this with execshield enabled? I think the core idea is to have layers of protection so that if there ever was a hole discovered in exec-shield, you still have another layer of defense. There's at least 3 layers that I can see for people with local access: execshield, SE Linux, and the gcc/glibc FORTIFY_SOURCE & stack protector options. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dwalsh at redhat.com Tue Dec 13 18:49:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 Dec 2005 13:49:08 -0500 Subject: Making httpd work with trac and svn In-Reply-To: References: <439E5191.8070302@redhat.com> Message-ID: <439F17A4.6030909@redhat.com> Robin Bowes wrote: > Daniel J Walsh said the following on 13/12/2005 04:44: > >> Robin Bowes wrote: >> >>> # Needed to allow svnmailer to execute and send commit notifications >>> # using sendmail as httpd user >>> allow httpd_t trac_var_t:file execute; >>> allow httpd_t trac_var_t:file execute_no_trans; >>> >>> >> What is trac_var_t? >> >> >>> allow restorecon_t devpts_t:chr_file getattr; >>> allow httpd_t sbin_t:lnk_file read; >>> >>> > > I followed the instructions here [1] to set up trac to work with SELinux. > > [1] http://projects.edgewall.com/trac/wiki/TracWithSeLinux > > trac_var_t is a file type creagted by the SELinux config listed on that > site. > > R. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Ok from reading that policy, it looks like you would be able to write to those directories, but now you are trying to execute files in those directories? -- From sds at tycho.nsa.gov Tue Dec 13 18:37:22 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 Dec 2005 13:37:22 -0500 Subject: Interesting reading on exec* access checks. In-Reply-To: References: <4398A5AD.2010701@redhat.com> <200512121703.jBCH3eEg017497@mms-r00.iijmio.jp> <1134408427.7305.123.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1134499042.3421.74.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-13 at 17:03 +0000, Mike Hearn wrote: > On Mon, 12 Dec 2005 12:27:07 -0500, Stephen Smalley wrote: > > exec-shield is a mechanism that approximates NX support, but does not > > define policy, so it cannot differentiate between a legitimate > > application request for executable memory from the same request induced > > by malicious code > > I thought that in order to get malicious code into a running program with > any degree of reliability you need to know its VMA layout, and execshield > prevents that. So how can you do attacks like this with execshield enabled? http://www.stanford.edu/~blp/papers/asrandom.pdf -- Stephen Smalley National Security Agency From robin-lists at robinbowes.com Tue Dec 13 20:16:34 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Tue, 13 Dec 2005 20:16:34 +0000 Subject: Making httpd work with trac and svn In-Reply-To: <439F17A4.6030909@redhat.com> References: <439E5191.8070302@redhat.com> <439F17A4.6030909@redhat.com> Message-ID: Daniel J Walsh said the following on 13/12/2005 18:49: > Robin Bowes wrote: >>>> # Needed to allow svnmailer to execute and send commit notifications >>>> # using sendmail as httpd user >>>> allow httpd_t trac_var_t:file execute; >>>> allow httpd_t trac_var_t:file execute_no_trans; >>>> allow restorecon_t devpts_t:chr_file getattr; >>>> allow httpd_t sbin_t:lnk_file read; >> >> I followed the instructions here [1] to set up trac to work with SELinux. >> >> [1] http://projects.edgewall.com/trac/wiki/TracWithSeLinux >> >> trac_var_t is a file type creagted by the SELinux config listed on that >> site. > > Ok from reading that policy, it looks like you would be able to write to > those directories, but now you are trying to execute files in those > directories? Yes. I am running svn hooks. eg. post-commit. The post-commit script runs svn-mailer which, in turn, sends mail using /usr/sbin/sendmail and also (optionally) includes diffs in the mails (hence the need for temp file access). R. From mike at plan99.net Tue Dec 13 20:38:42 2005 From: mike at plan99.net (Mike Hearn) Date: Tue, 13 Dec 2005 20:38:42 +0000 Subject: Interesting reading on exec* access checks. References: <4398A5AD.2010701@redhat.com> <200512121703.jBCH3eEg017497@mms-r00.iijmio.jp> <1134408427.7305.123.camel@moss-spartans.epoch.ncsc.mil> <1134499042.3421.74.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Tue, 13 Dec 2005 13:37:22 -0500, Stephen Smalley wrote: >> I thought that in order to get malicious code into a running program with >> any degree of reliability you need to know its VMA layout, and execshield >> prevents that. So how can you do attacks like this with execshield enabled? > > http://www.stanford.edu/~blp/papers/asrandom.pdf Interesting paper, thanks. I guess that answers my question pretty well. It's nice to know it's still (mostly) effective on 64 bit systems though. thanks -mike From dwalsh at redhat.com Tue Dec 13 22:20:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 Dec 2005 17:20:14 -0500 Subject: Making httpd work with trac and svn In-Reply-To: References: <439E5191.8070302@redhat.com> <439F17A4.6030909@redhat.com> Message-ID: <439F491E.8070208@redhat.com> Robin Bowes wrote: > Daniel J Walsh said the following on 13/12/2005 18:49: > >> Robin Bowes wrote: >> >>>>> # Needed to allow svnmailer to execute and send commit notifications >>>>> # using sendmail as httpd user >>>>> allow httpd_t trac_var_t:file execute; >>>>> allow httpd_t trac_var_t:file execute_no_trans; >>>>> allow restorecon_t devpts_t:chr_file getattr; >>>>> allow httpd_t sbin_t:lnk_file read; >>>>> >>> I followed the instructions here [1] to set up trac to work with SELinux. >>> >>> [1] http://projects.edgewall.com/trac/wiki/TracWithSeLinux >>> >>> trac_var_t is a file type creagted by the SELinux config listed on that >>> site. >>> >> Ok from reading that policy, it looks like you would be able to write to >> those directories, but now you are trying to execute files in those >> directories? >> > > Yes. I am running svn hooks. eg. post-commit. > > The post-commit script runs svn-mailer which, in turn, sends mail using > /usr/sbin/sendmail and also (optionally) includes diffs in the mails > (hence the need for temp file access). > > R. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Not sure why you needed smpt since httpd should be allowed to transition to system_mail_t via sendmail You chould set the /var/trac directories to httpd_sys_content_t and I think you will get the execute for free. -- From cochranb at speakeasy.net Tue Dec 13 22:24:19 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Tue, 13 Dec 2005 17:24:19 -0500 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439E4AF6.40403@redhat.com> References: <4399EFE6.5040206@redhat.com> <20051212110247.GA25100@redhat.com> <439E23F3.7090709@speakeasy.net> <439E4AF6.40403@redhat.com> Message-ID: <439F4A13.3020701@speakeasy.net> Daniel J Walsh wrote: > Robert L Cochran wrote: > >> Joe Orton wrote: >> >>> On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote: >>> >>> >>>> Currently policy allows httpd to connect to relay ports and to >>>> mysql/postgres ports. >>>> >>>> Adding these booleans >>>> * httpd_can_network_relay >>>> * httpd_can_network_connect_db >>>> >>>> And turning this feature off by default. This is going into >>>> tonights reference policy and into FC4 test release. >>>> >>> >>> >>> Do you mean FC4 or FC5? This should not go in an FC4 update >>> off-by-default since it will break working setups. Make it >>> on-by-default if you want to ship this to FC4 users and >>> off-by-default with a big release note for FC5. >>> >>> What's the difference between httpd_can_network_relay and >>> httpd_can_network_connect? >>> >>> Do we still have the problem that httpd cannot reap idle children >>> properly when the latter is set? That really really does need to >>> work by default. >>> >>> joe >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >>> >>> >> I'd like to completely agree with Joe. I'm beginning to have quite a >> lot invested in httpd, PHP and related database code and I don't want >> SELinux breaking what is there without a lot of warning. For new >> installs of FC4, I've been forced to turn off SELinux support for >> these applications. They simply don't work otherwise. >> >> Bob Cochran >> Greenbelt. Maryland, USA >> >> > Have your reported your problems here or in bugzilla? > Yes I reported an error in fedora-selinux-list with this subject line: "MySQL 5.0.4 Beta AVC Denied Messages". That was back in May, there was no reply to the post. I don't think I've put anything in bugzilla. I fixed the error by removing SELinux protection for the MySQL application. I believe, but need to confirm, that I also turned it off for php (I compile a lot of snapshots from snaps.php.net) on that machine, too. I have since upgraded the machine to Fedora Core 4. I can't remember whether I set that machine up with SELinux in permissive or enforcing mode. But when I later installed MySQL 5 from rpm's downloaded from dev.mysql.com, SELinux broke the startup script by denying mysqld permission to start and thereby build the grant tables, etc. Until a better solution comes along, I don't want SELinux breaking my applications in this way. As a matter of fact, one enhancement I'd like to see is SELinux emitting a user-friendly message in the logs explaining how to turn on the functionality for an application it has just denied. Something like this: To turn this functionality on, go to Desktop --> System Settings ---> Security Level --> SELinux and....[more precise instructions presented here]. It would also be nice to have preconfigured "application access levels" an administrator can turn on or off rapidly. For example, if the machine is intended to be used as a firewall, have an application access level that would configure SELinux to let the right kind of firewall services (iptables, for example) run correctly. This access level would be set up to prevent gcc, perl, ruby or any other compiler from working if installed. The idea is to introduce ease of use and adminstration to SELinux. I'm not an SELinux expert; I'm just trying to administer my own machines on my own network and go about application development with a minimum of interference and pain from security type software. If I can't get SELinux to cooperate with me a little and provide a smooth solution for not breaking my applications, I'll simply turn it off. Bob Cochran From ejtr at layer3.co.uk Tue Dec 13 23:22:27 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Tue, 13 Dec 2005 23:22:27 +0000 Subject: localpolicy.fc settings not always honoured Message-ID: <1134516147.5132.25.camel@topaz.bugfinder.co.uk> For a personal requirement, I was trying to tweak SELinux strict sources policy so that the OpenOffice main binary had a non-default label, i.e. "soffice_exec_t". I found that despite setting the file_context override in localpolicy.fc, a restorecon kept flipping the file_context back to bin_t, implying that the loaded policy had ignored my localpolicy settings. I eventually found that the settings in distros.fc appeared to be overriding whatever I did, provided it had a regex match for the file in question. In other words, "restorecon" used the file_context as set by the last matching regex in /etc/selinux/strict/contexts/files/file_contexts The implication is that the Makefile for the policy doesn't guarantee to arrange things such that localpolicy.fc can always be used to apply local policy overrides. I had always assumed this to be the case. On most occasions, localpolicy.fc will override. My problem here was that distros.fc contains a "wilder" regex which happened to match the file_context I was trying to tweak. A grep of the relevant sections of localpolicy.fc and distros.fc are shown below. I was finding that an override for this file: /usr/lib/openoffice.org2.0/program/soffice was matching this in distros.fc /usr/lib/.*/program(/.*)? Could the Makefile be rearranged to ensure that local settings always override the default policy, please? Ted Policy in use is: selinux-policy-strict-sources-1.27.1-2.16 [root at workstation policy]# pwd /etc/selinux/strict/src/policy [root at workstation policy]# [root at workstation policy]# grep program file_contexts/distros.fc /usr/lib/.*/program(/.*)? system_u:object_r:bin_t /usr/lib/.*/program/.*\.so.* system_u:object_r:shlib_t /usr/lib/.*/program/libicudata\.so.* -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libsts645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libvclplug_gen645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libwrp645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libswd680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/librecentfile\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsvx680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libcomphelp4gcc3\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsoffice\.so -- system_u:object_r:texrel_shlib_t [root at workstation policy]# [root at workstation policy]# grep program file_contexts/program/localpolicy.fc #/usr/lib/openoffice.org2.0/program/libsoffice.so -- system_u:object_r:texrel_shlib_t /usr/lib/openoffice.org2.0/program/soffice -- system_u:object_r:soffice_exec_t /usr/lib/openoffice.org2.0/program/soffice.bin -- system_u:object_r:soffice_exec_t [root at workstation policy]# [root at workstation files]# pwd /etc/selinux/strict/contexts/files [root at workstation files]# grep program file_contexts # when the security policy is installed. The setfiles program # listed here anyway so that if the setfiles program is used on a running # cvs program #/usr/lib/openoffice.org2.0/program/libsoffice.so -- system_u:object_r:texrel_shlib_t /usr/lib/openoffice.org2.0/program/soffice -- system_u:object_r:soffice_exec_t /usr/lib/openoffice.org2.0/program/soffice.bin -- system_u:object_r:soffice_exec_t # rsync program # sysstat and other sar programs # Add programs here which should not be confined by SELinux # Add programs here which should not be confined by SELinux # uucico program /usr/lib/.*/program(/.*)? system_u:object_r:bin_t /usr/lib/.*/program/.*\.so.* system_u:object_r:shlib_t /usr/lib/.*/program/libicudata\.so.* -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libsts645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libvclplug_gen645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libwrp645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libswd680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/librecentfile\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsvx680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libcomphelp4gcc3\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsoffice\.so -- system_u:object_r:texrel_shlib_t [root at workstation files]# -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From selinux at gmail.com Wed Dec 14 03:31:49 2005 From: selinux at gmail.com (Tom London) Date: Tue, 13 Dec 2005 19:31:49 -0800 Subject: Adding two new booleans to httpd to tighten it's security. In-Reply-To: <439F4A13.3020701@speakeasy.net> References: <4399EFE6.5040206@redhat.com> <20051212110247.GA25100@redhat.com> <439E23F3.7090709@speakeasy.net> <439E4AF6.40403@redhat.com> <439F4A13.3020701@speakeasy.net> Message-ID: <4c4ba1530512131931o16728314s205ed41f906a573f@mail.gmail.com> Here is the response from vmware: VMware generates lots of code on the fly, so flipping PROT_EXEC with PROT_WRITE would not reasonably work. Especially not in the multithreaded environment where it would continuously cause IPIs to be send between processors, slowing down everything. If SELinux default policy authors decided that they cannot trust applications, then I'm afraid that you'll have to create special policy for VMware. libgdk-x11's library from vmware's directory will be used only if libraries on your host are found to be inadequate. Try 'VMWARE_USE_SHIPPED_GTK=no vmware' and it should tell you which libraries are missing on your box. After you'll install them then libgdk-x11 from /usr/lib should be used. ------------------------------------------------------------- I haven't gotten the library test working yet..... tom -- Tom London From robin-lists at robinbowes.com Wed Dec 14 08:17:59 2005 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 14 Dec 2005 08:17:59 +0000 Subject: Making httpd work with trac and svn In-Reply-To: <439F491E.8070208@redhat.com> References: <439E5191.8070302@redhat.com> <439F17A4.6030909@redhat.com> <439F491E.8070208@redhat.com> Message-ID: Daniel J Walsh said the following on 13/12/2005 22:20: > Robin Bowes wrote: >> Yes. I am running svn hooks. eg. post-commit. >> >> The post-commit script runs svn-mailer which, in turn, sends mail using >> /usr/sbin/sendmail and also (optionally) includes diffs in the mails >> (hence the need for temp file access). >> > > Not sure why you needed smpt since httpd should be allowed to transition > to system_mail_t via sendmail trac sends ticket notifications via smtp. > > You chould set the /var/trac directories to httpd_sys_content_t and I > think you will get the execute for free. OK, I'll give that a go. Thanks, R. From dwalsh at redhat.com Wed Dec 14 14:15:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Dec 2005 09:15:24 -0500 Subject: localpolicy.fc settings not always honoured In-Reply-To: <1134516147.5132.25.camel@topaz.bugfinder.co.uk> References: <1134516147.5132.25.camel@topaz.bugfinder.co.uk> Message-ID: <43A028FC.3050501@redhat.com> Ted Rule wrote: > For a personal requirement, I was trying to tweak SELinux strict sources > policy so that the OpenOffice main binary had a non-default label, i.e. > "soffice_exec_t". > > I found that despite setting the file_context override in > localpolicy.fc, a restorecon kept flipping the file_context > back to bin_t, implying that the loaded policy had ignored my > localpolicy settings. > > I eventually found that the settings in distros.fc appeared to be > overriding whatever I did, provided it had a regex match for the file in > question. In other words, "restorecon" used the file_context as set by > the last matching regex > in /etc/selinux/strict/contexts/files/file_contexts > > The implication is that the Makefile for the policy doesn't guarantee to > arrange things such that localpolicy.fc can always be > used to apply local policy overrides. I had always assumed this to be > the case. > > On most occasions, localpolicy.fc will override. My problem here was > that distros.fc contains a "wilder" regex which happened to match the > file_context I was trying to tweak. > > A grep of the relevant sections of localpolicy.fc and distros.fc are > shown below. I was finding that an override for this file: > > /usr/lib/openoffice.org2.0/program/soffice > > was matching this in distros.fc > > /usr/lib/.*/program(/.*)? > > > Could the Makefile be rearranged to ensure that local settings always > override the default policy, please? > > > Ted > > > Policy in use is: > > selinux-policy-strict-sources-1.27.1-2.16 > > > [root at workstation policy]# pwd > /etc/selinux/strict/src/policy > > [root at workstation policy]# > [root at workstation policy]# grep program file_contexts/distros.fc > /usr/lib/.*/program(/.*)? system_u:object_r:bin_t > /usr/lib/.*/program/.*\.so.* > system_u:object_r:shlib_t > /usr/lib/.*/program/libicudata\.so.* -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libsts645li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libvclplug_gen645li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libwrp645li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libswd680li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/librecentfile\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/libsvx680li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/libcomphelp4gcc3\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/libsoffice\.so -- > system_u:object_r:texrel_shlib_t > [root at workstation policy]# > > [root at workstation policy]# grep program > file_contexts/program/localpolicy.fc > #/usr/lib/openoffice.org2.0/program/libsoffice.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/openoffice.org2.0/program/soffice -- > system_u:object_r:soffice_exec_t > /usr/lib/openoffice.org2.0/program/soffice.bin -- > system_u:object_r:soffice_exec_t > [root at workstation policy]# > > > [root at workstation files]# pwd > /etc/selinux/strict/contexts/files > [root at workstation files]# grep program file_contexts > # when the security policy is installed. The setfiles program > # listed here anyway so that if the setfiles program is used on a > running > # cvs program > #/usr/lib/openoffice.org2.0/program/libsoffice.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/openoffice.org2.0/program/soffice -- > system_u:object_r:soffice_exec_t > /usr/lib/openoffice.org2.0/program/soffice.bin -- > system_u:object_r:soffice_exec_t > # rsync program > # sysstat and other sar programs > # Add programs here which should not be confined by SELinux > # Add programs here which should not be confined by SELinux > # uucico program > /usr/lib/.*/program(/.*)? system_u:object_r:bin_t > /usr/lib/.*/program/.*\.so.* > system_u:object_r:shlib_t > /usr/lib/.*/program/libicudata\.so.* -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libsts645li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libvclplug_gen645li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libwrp645li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib/.*/program/libswd680li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/librecentfile\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/libsvx680li\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/libcomphelp4gcc3\.so -- > system_u:object_r:texrel_shlib_t > /usr/lib(64)?/.*/program/libsoffice\.so -- > system_u:object_r:texrel_shlib_t > [root at workstation files]# > > > > > The makefile reassembles /etc/selinux/strict/contexts/files/file_context and should put your change after the distro one. -- From sds at tycho.nsa.gov Wed Dec 14 14:26:58 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 14 Dec 2005 09:26:58 -0500 Subject: localpolicy.fc settings not always honoured In-Reply-To: <1134516147.5132.25.camel@topaz.bugfinder.co.uk> References: <1134516147.5132.25.camel@topaz.bugfinder.co.uk> Message-ID: <1134570418.3421.197.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-13 at 23:22 +0000, Ted Rule wrote: > For a personal requirement, I was trying to tweak SELinux strict sources > policy so that the OpenOffice main binary had a non-default label, i.e. > "soffice_exec_t". > > I found that despite setting the file_context override in > localpolicy.fc, a restorecon kept flipping the file_context > back to bin_t, implying that the loaded policy had ignored my > localpolicy settings. A couple of points: - Conventionally, such local settings have been put into file_contexts/misc/local.fc or file_contexts/misc/custom.fc. The contents of the misc subdirectory are put after the distros.fc file and thus take precedence. - A better way of doing this is to create a /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts.local file with your local settings. That doesn't require policy sources to be kept around at all. restorecon and other users of matchpathcon give precedence to anything in that file if it exists. -- Stephen Smalley National Security Agency From selinux at gmail.com Wed Dec 14 18:12:53 2005 From: selinux at gmail.com (Tom London) Date: Wed, 14 Dec 2005 10:12:53 -0800 Subject: login shell running as rpm_script_t? Message-ID: <4c4ba1530512141012k17072c9fn454e7698358fb662@mail.gmail.com> Running latest rawhide (selinux-policy-targeted-2.1.5-1): My login shell appears to be running as rpm_script_t. Did I do something funny? tom [tbl at tlondon ~]$ ps Z LABEL PID TTY STAT TIME COMMAND user_u:system_r:rpm_script_t:s0 3193 pts/1 Ss 0:00 bash user_u:system_r:rpm_script_t:s0 3195 pts/2 Ss 0:00 bash user_u:system_r:rpm_script_t:s0 3922 pts/2 R+ 0:00 ps Z [tbl at tlondon ~]$ -- Tom London From beheer at net-care.nl Wed Dec 14 21:37:35 2005 From: beheer at net-care.nl (Mark Evers) Date: Wed, 14 Dec 2005 22:37:35 +0100 Subject: Still having problems with SELinux and Dovecot Message-ID: <001a01c600f6$993b1a20$3201a8c0@game01> Well, i still have problems with SELinux and Dovecot, when i do a reboot i get a error Starting Dovecot Imap: Fatal: Can't open configuration file /etc/dovecot.conf: Permission denied and in the audit.log i find this error type=AVC msg=audit(1134595859.843:208): avc: denied { read } for pid=26990 comm="dovecot" name="dovecot.conf" dev=dm-0 ino=197586 scontext=system_u:system_r:dovecot_t tcontext=system_u:object_r:etc_runtime_t tclass=file type=SYSCALL msg=audit(1134595859.843:208): arch=40000003 syscall=5 success=no exit=-13 a0=8058a3e a1=8000 a2=0 a3=8000 items=1 pid=26990 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="dovecot" exe="/usr/sbin/dovecot" type=CWD msg=audit(1134595859.843:208): cwd="/usr/libexec/webmin/dovecot" type=PATH msg=audit(1134595859.843:208): item=0 name="/etc/dovecot.conf" flags=101 inode=197586 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 I can only fix this by doing a "fixfiles relabel" and "touch ./autorelabel" and then it works again, till the next reboot.. Is there a way to fix this? or is there a way to exclude dovecot from SELinux?? Mark Evers -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Dec 14 21:49:18 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Dec 2005 16:49:18 -0500 Subject: login shell running as rpm_script_t? In-Reply-To: <4c4ba1530512141012k17072c9fn454e7698358fb662@mail.gmail.com> References: <4c4ba1530512141012k17072c9fn454e7698358fb662@mail.gmail.com> Message-ID: <43A0935E.50409@redhat.com> Tom London wrote: > Running latest rawhide (selinux-policy-targeted-2.1.5-1): > > My login shell appears to be running as rpm_script_t. > > Did I do something funny? > tom > > [tbl at tlondon ~]$ ps Z > LABEL PID TTY STAT TIME COMMAND > user_u:system_r:rpm_script_t:s0 3193 pts/1 Ss 0:00 bash > user_u:system_r:rpm_script_t:s0 3195 pts/2 Ss 0:00 bash > user_u:system_r:rpm_script_t:s0 3922 pts/2 R+ 0:00 ps Z > [tbl at tlondon ~]$ > > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > What did you login using? Looks like a bad default_context file. -- From dwalsh at redhat.com Wed Dec 14 21:51:22 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Dec 2005 16:51:22 -0500 Subject: Still having problems with SELinux and Dovecot In-Reply-To: <001a01c600f6$993b1a20$3201a8c0@game01> References: <001a01c600f6$993b1a20$3201a8c0@game01> Message-ID: <43A093DA.807@redhat.com> Mark Evers wrote: > Well, i still have problems with SELinux and Dovecot, when i do a > reboot i get a error > Starting Dovecot Imap: Fatal: Can't open configuration file > /etc/dovecot.conf: Permission denied > > and in the audit.log i find this error > > type=AVC msg=audit(1134595859.843:208): avc: denied { read } for > pid=26990 comm="dovecot" name="dovecot.conf" dev=dm-0 ino=197586 > scontext=system_u:system_r:dovecot_t > tcontext=system_u:object_r:etc_runtime_t tclass=file > type=SYSCALL msg=audit(1134595859.843:208): arch=40000003 syscall=5 > success=no exit=-13 a0=8058a3e a1=8000 a2=0 a3=8000 items=1 pid=26990 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 comm="dovecot" exe="/usr/sbin/dovecot" > type=CWD msg=audit(1134595859.843:208): cwd="/usr/libexec/webmin/dovecot" > type=PATH msg=audit(1134595859.843:208): item=0 > name="/etc/dovecot.conf" flags=101 inode=197586 dev=fd:00 > mode=0100644 ouid=0 ogid=0 rdev=00:00 > > I can only fix this by doing a "fixfiles relabel" and "touch > ./autorelabel" and then it works again, till the next reboot.. > > Is there a way to fix this? or is there a way to exclude dovecot from > SELinux?? > restorecon /etc/dovecot.conf How does that file get created? Is it being created by an init script? Basically its context is wrong, Should be dovecot_etc_t not etc_runtime_t. > Mark Evers > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From selinux at gmail.com Wed Dec 14 22:07:38 2005 From: selinux at gmail.com (Tom London) Date: Wed, 14 Dec 2005 14:07:38 -0800 Subject: login shell running as rpm_script_t? In-Reply-To: <43A0935E.50409@redhat.com> References: <4c4ba1530512141012k17072c9fn454e7698358fb662@mail.gmail.com> <43A0935E.50409@redhat.com> Message-ID: <4c4ba1530512141407r203a2d1p5cc82a7404b29f4@mail.gmail.com> On 12/14/05, Daniel J Walsh wrote: > Tom London wrote: > > Running latest rawhide (selinux-policy-targeted-2.1.5-1): > > > > My login shell appears to be running as rpm_script_t. > > > > Did I do something funny? > > tom > > > > [tbl at tlondon ~]$ ps Z > > LABEL PID TTY STAT TIME COMMAND > > user_u:system_r:rpm_script_t:s0 3193 pts/1 Ss 0:00 bash > > user_u:system_r:rpm_script_t:s0 3195 pts/2 Ss 0:00 bash > > user_u:system_r:rpm_script_t:s0 3922 pts/2 R+ 0:00 ps Z > > [tbl at tlondon ~]$ > > > > -- > > Tom London > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > What did you login using? Looks like a bad default_context file. > Standard graphical login. Ah. I seem to have a default_contexts.rpmnew. Here are the diffs: --- default_contexts 2005-12-13 14:14:45.000000000 -0800 +++ default_contexts.rpmnew 2005-12-08 13:58:07.000000000 -0800 @@ -1,9 +1,9 @@ -system_r:crond_t:s0 system_r:unconfined_t:s0 +system_r:xdm_t:s0 system_r:unconfined_t:s0 +system_r:unconfined_t:s0 system_r:unconfined_t:s0 system_r:initrc_t:s0 system_r:unconfined_t:s0 system_r:local_login_t:s0 system_r:unconfined_t:s0 system_r:remote_login_t:s0 system_r:unconfined_t:s0 system_r:rshd_t:s0 system_r:unconfined_t:s0 +system_r:crond_t:s0 system_r:unconfined_t:s0 system_r:sshd_t:s0 system_r:unconfined_t:s0 system_r:sysadm_su_t:s0 system_r:unconfined_t:s0 -system_r:unconfined_t:s0 system_r:unconfined_t:s0 -system_r:xdm_t:s0 system_r:unconfined_t:s0 Is order 'important'? tom -- Tom London From dwalsh at redhat.com Wed Dec 14 22:09:29 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 Dec 2005 17:09:29 -0500 Subject: login shell running as rpm_script_t? In-Reply-To: <4c4ba1530512141407r203a2d1p5cc82a7404b29f4@mail.gmail.com> References: <4c4ba1530512141012k17072c9fn454e7698358fb662@mail.gmail.com> <43A0935E.50409@redhat.com> <4c4ba1530512141407r203a2d1p5cc82a7404b29f4@mail.gmail.com> Message-ID: <43A09819.80705@redhat.com> Tom London wrote: > On 12/14/05, Daniel J Walsh wrote: > >> Tom London wrote: >> >>> Running latest rawhide (selinux-policy-targeted-2.1.5-1): >>> >>> My login shell appears to be running as rpm_script_t. >>> >>> Did I do something funny? >>> tom >>> >>> [tbl at tlondon ~]$ ps Z >>> LABEL PID TTY STAT TIME COMMAND >>> user_u:system_r:rpm_script_t:s0 3193 pts/1 Ss 0:00 bash >>> user_u:system_r:rpm_script_t:s0 3195 pts/2 Ss 0:00 bash >>> user_u:system_r:rpm_script_t:s0 3922 pts/2 R+ 0:00 ps Z >>> [tbl at tlondon ~]$ >>> >>> -- >>> Tom London >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >> What did you login using? Looks like a bad default_context file. >> >> > Standard graphical login. > > Ah. I seem to have a default_contexts.rpmnew. Here are the diffs: > > --- default_contexts 2005-12-13 14:14:45.000000000 -0800 > +++ default_contexts.rpmnew 2005-12-08 13:58:07.000000000 -0800 > @@ -1,9 +1,9 @@ > -system_r:crond_t:s0 system_r:unconfined_t:s0 > +system_r:xdm_t:s0 system_r:unconfined_t:s0 > +system_r:unconfined_t:s0 system_r:unconfined_t:s0 > system_r:initrc_t:s0 system_r:unconfined_t:s0 > system_r:local_login_t:s0 system_r:unconfined_t:s0 > system_r:remote_login_t:s0 system_r:unconfined_t:s0 > system_r:rshd_t:s0 system_r:unconfined_t:s0 > +system_r:crond_t:s0 system_r:unconfined_t:s0 > system_r:sshd_t:s0 system_r:unconfined_t:s0 > system_r:sysadm_su_t:s0 system_r:unconfined_t:s0 > -system_r:unconfined_t:s0 system_r:unconfined_t:s0 > -system_r:xdm_t:s0 system_r:unconfined_t:s0 > > Is order 'important'? > > tom > -- > Tom London > No. Is gdm running as xdm_t? -- From beheer at net-care.nl Wed Dec 14 22:16:30 2005 From: beheer at net-care.nl (Mark Evers) Date: Wed, 14 Dec 2005 23:16:30 +0100 Subject: Still having problems with SELinux and Dovecot References: <001a01c600f6$993b1a20$3201a8c0@game01> <43A093DA.807@redhat.com> <002801c600f9$79677d80$3201a8c0@game01> <43A0994F.90800@redhat.com> Message-ID: <003401c600fc$08a2bf80$3201a8c0@game01> ----- Original Message ----- From: "Daniel J Walsh" To: "Mark Evers" Sent: Wednesday, December 14, 2005 11:14 PM Subject: Re: Still having problems with SELinux and Dovecot > Mark Evers wrote: >> The file was created by a regular "yum install dovecot", and i altered it >> later using nano >> The weard thing is, when it runs it keeps running, sometimes when i >> reboot it isn't blocked by SELinux, but most times it is. >> >> I just did the "restorecon /etc/dovecot.conf" and rebooted and it started >> fine >> >>> Basically its context is wrong, Should be dovecot_etc_t not >>> etc_runtime_t. >> >> Errrr?? >> >> >> ----- Original Message ----- From: "Daniel J Walsh" >> To: "Mark Evers" >> Cc: >> Sent: Wednesday, December 14, 2005 10:51 PM >> Subject: Re: Still having problems with SELinux and Dovecot >> >> >>> Mark Evers wrote: >>>> Well, i still have problems with SELinux and Dovecot, when i do a >>>> reboot i get a error >>>> Starting Dovecot Imap: Fatal: Can't open configuration file >>>> /etc/dovecot.conf: Permission denied >>>> and in the audit.log i find this error >>>> type=AVC msg=audit(1134595859.843:208): avc: denied { read } for >>>> pid=26990 comm="dovecot" name="dovecot.conf" dev=dm-0 ino=197586 >>>> scontext=system_u:system_r:dovecot_t >>>> tcontext=system_u:object_r:etc_runtime_t tclass=file >>>> type=SYSCALL msg=audit(1134595859.843:208): arch=40000003 syscall=5 >>>> success=no exit=-13 a0=8058a3e a1=8000 a2=0 a3=8000 items=1 pid=26990 >>>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 >>>> comm="dovecot" exe="/usr/sbin/dovecot" >>>> type=CWD msg=audit(1134595859.843:208): >>>> cwd="/usr/libexec/webmin/dovecot" >>>> type=PATH msg=audit(1134595859.843:208): item=0 >>>> name="/etc/dovecot.conf" flags=101 inode=197586 dev=fd:00 mode=0100644 >>>> ouid=0 ogid=0 rdev=00:00 >>>> I can only fix this by doing a "fixfiles relabel" and "touch >>>> ./autorelabel" and then it works again, till the next reboot.. >>>> Is there a way to fix this? or is there a way to exclude dovecot from >>>> SELinux?? >>>> >>> restorecon /etc/dovecot.conf >>> >>> How does that file get created? Is it being created by an init script? >>> >>> Basically its context is wrong, Should be dovecot_etc_t not >>> etc_runtime_t. >>> > Well watch that file context and make sure no init script is replacing > that file. I'll keep an eye on it, thanks. >>>> Mark Evers >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >>> -- >>> >> > > > -- > From selinux at gmail.com Wed Dec 14 22:29:45 2005 From: selinux at gmail.com (Tom London) Date: Wed, 14 Dec 2005 14:29:45 -0800 Subject: login shell running as rpm_script_t? In-Reply-To: <43A09819.80705@redhat.com> References: <4c4ba1530512141012k17072c9fn454e7698358fb662@mail.gmail.com> <43A0935E.50409@redhat.com> <4c4ba1530512141407r203a2d1p5cc82a7404b29f4@mail.gmail.com> <43A09819.80705@redhat.com> Message-ID: <4c4ba1530512141429n4a015020ua65bc923a8f41db1@mail.gmail.com> On 12/14/05, Daniel J Walsh wrote: > Tom London wrote: > > On 12/14/05, Daniel J Walsh wrote: > > > >> Tom London wrote: > >> > >>> Running latest rawhide (selinux-policy-targeted-2.1.5-1): > >>> > >>> My login shell appears to be running as rpm_script_t. > >>> > >>> Did I do something funny? > >>> tom > >>> > >>> [tbl at tlondon ~]$ ps Z > >>> LABEL PID TTY STAT TIME COMMAND > >>> user_u:system_r:rpm_script_t:s0 3193 pts/1 Ss 0:00 bash > >>> user_u:system_r:rpm_script_t:s0 3195 pts/2 Ss 0:00 bash > >>> user_u:system_r:rpm_script_t:s0 3922 pts/2 R+ 0:00 ps Z > >>> [tbl at tlondon ~]$ > >>> > >>> -- > >>> Tom London > >>> > >>> -- > >>> fedora-selinux-list mailing list > >>> fedora-selinux-list at redhat.com > >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >>> > >>> > >> What did you login using? Looks like a bad default_context file. > >> > >> > > Standard graphical login. > > > > Ah. I seem to have a default_contexts.rpmnew. Here are the diffs: > > > > --- default_contexts 2005-12-13 14:14:45.000000000 -0800 > > +++ default_contexts.rpmnew 2005-12-08 13:58:07.000000000 -0800 > > @@ -1,9 +1,9 @@ > > -system_r:crond_t:s0 system_r:unconfined_t:s0 > > +system_r:xdm_t:s0 system_r:unconfined_t:s0 > > +system_r:unconfined_t:s0 system_r:unconfined_t:s0 > > system_r:initrc_t:s0 system_r:unconfined_t:s0 > > system_r:local_login_t:s0 system_r:unconfined_t:s0 > > system_r:remote_login_t:s0 system_r:unconfined_t:s0 > > system_r:rshd_t:s0 system_r:unconfined_t:s0 > > +system_r:crond_t:s0 system_r:unconfined_t:s0 > > system_r:sshd_t:s0 system_r:unconfined_t:s0 > > system_r:sysadm_su_t:s0 system_r:unconfined_t:s0 > > -system_r:unconfined_t:s0 system_r:unconfined_t:s0 > > -system_r:xdm_t:s0 system_r:unconfined_t:s0 > > > > Is order 'important'? > > > > tom > > -- > > Tom London > > > No. Is gdm running as xdm_t? > > -- [root at tlondon contexts]# ps agxZ | grep gdm system_u:system_r:xdm_t:s0-s0:c0.c255 2968 ? S 0:00 /usr/sbin/gdm-binary -nodaemon system_u:system_r:xdm_t:s0-s0:c0.c255 3000 ? S 0:00 /usr/sbin/gdm-binary -nodaemon system_u:system_r:xdm_t:s0-s0:c0.c255 3005 tty7 Ss+ 3:17 /usr/bin/Xorg :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 root:system_r:ldconfig_t:s0-s0:c0.c255 5270 pts/1 R+ 0:00 grep gdm ldconfig_t for 'grep'? (This is running as a 'su -' root). Something funny. I'll reboot. tom -- Tom London From selinux at gmail.com Fri Dec 16 15:34:43 2005 From: selinux at gmail.com (Tom London) Date: Fri, 16 Dec 2005 07:34:43 -0800 Subject: selinux-policy-targeted-2.1.6-4: needs netif Message-ID: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> running today's policy, have boot/network problems. Fixed boot problems by turning off hplip/cups. Appears more 'netif' work is needed: [root at tlondon ~]# ausearch -m avc,selinux_err -ts 12/16/2005 |audit2allow -l allow avahi_t null_device_t:netif udp_send; allow cupsd_t null_device_t:netif tcp_send; allow hplip_t null_device_t:netif tcp_send; allow kernel_t null_device_t:netif rawip_send; allow ntpd_t null_device_t:netif udp_send; allow ntpd_t policy_config_t:udp_socket node_bind; allow ping_t null_device_t:netif rawip_recv; allow ping_t policy_config_t:node rawip_recv; allow unconfined_t null_device_t:netif tcp_recv; allow unconfined_t policy_config_t:node udp_recv; allow unconfined_t sysctl_t:tcp_socket recv_msg; allow unconfined_t sysctl_t:udp_socket send_msg; [root at tlondon ~]# Here are a few AVCs: ---- time->Fri Dec 16 07:06:31 2005 type=AVC msg=audit(1134745591.755:5): avc: denied { tcp_send } for pid=2686 comm="python" saddr=127.0.0.1 src=37866 daddr=127.0.0.1 dest=50000 netif=lo scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:null_device_t:s0 tclass=netif ---- time->Fri Dec 16 07:06:34 2005 type=AVC msg=audit(1134745594.243:6): avc: denied { tcp_send } for pid=2713 comm="hp" saddr=127.0.0.1 src=37867 daddr=127.0.0.1 dest=50000 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:null_device_t:s0 tclass=netif ---- time->Fri Dec 16 07:06:34 2005 type=AVC msg=audit(1134745594.755:7): avc: denied { tcp_send } for saddr=127.0.0.1 src=37866 daddr=127.0.0.1 dest=50000 netif=lo scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:null_device_t:s0 tclass=netif ------- time->Fri Dec 16 07:16:44 2005 type=SOCKETCALL msg=audit(1134746204.111:5): nargs=4 a0=4 a1=bfbf3450 a2=20 a3=0type=SYSCALL msg=audit(1134746204.111:5): arch=40000003 syscall=102 success=no exit=-1 a0=9 a1=bfbf30e4 a2=771ff4 a3=20 items=0 pid=2731 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ntpdate" exe="/usr/sbin/ntpdate" type=AVC msg=audit(1134746204.111:5): avc: denied { udp_send } for pid=2731 comm="ntpdate" saddr=192.168.1.101 src=32768 daddr=68.87.76.178 dest=53 netif=eth0 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:null_device_t:s0 tclass=netif ---- time->Fri Dec 16 07:16:57 2005 type=SOCKETCALL msg=audit(1134746217.580:190): nargs=3 a0=d a1=bfae85ec a2=0 type=SOCKADDR msg=audit(1134746217.580:190): saddr=020014E9E00000FB0000000000000000 type=SYSCALL msg=audit(1134746217.580:190): arch=40000003 syscall=102 success=no exit=-1 a0=10 a1=bfae8590 a2=af5134 a3=d items=0 pid=2814 auid=4294967295 uid=70 gid=70 euid=70 suid=70 fsuid=70 egid=70 sgid=70 fsgid=70 comm="avahi-daemon" exe="/usr/sbin/avahi-daemon" type=AVC msg=audit(1134746217.580:190): avc: denied { udp_recv } for pid=2814 comm="avahi-daemon" saddr=192.168.1.101 src=5353 daddr=224.0.0.251 dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:null_device_t:s0 tclass=netif type=AVC msg=audit(1134746217.580:190): avc: denied { udp_send } for pid=2814 comm="avahi-daemon" saddr=192.168.1.101 src=5353 daddr=224.0.0.251 dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:null_device_t:s0 tclass=netif ---- <<<<>>>> tom - -- Tom London From sds at tycho.nsa.gov Fri Dec 16 15:50:03 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 Dec 2005 10:50:03 -0500 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> Message-ID: <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-12-16 at 07:34 -0800, Tom London wrote: > running today's policy, have boot/network problems. > > Fixed boot problems by turning off hplip/cups. > > Appears more 'netif' work is needed: Dan removed what he thought were obsolete initial SIDs from the policy, but you can't do that without rebuilding the kernel to match. Thus, rawhide policy is busted, revert and reboot and wait for an update. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Dec 16 15:58:43 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 Dec 2005 10:58:43 -0500 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43A2E433.8070708@redhat.com> Stephen Smalley wrote: > On Fri, 2005-12-16 at 07:34 -0800, Tom London wrote: > >> running today's policy, have boot/network problems. >> >> Fixed boot problems by turning off hplip/cups. >> >> Appears more 'netif' work is needed: >> > > Dan removed what he thought were obsolete initial SIDs from the policy, > but you can't do that without rebuilding the kernel to match. Thus, > rawhide policy is busted, revert and reboot and wait for an update. > > Fixed policy is on ftp://people.redhat.com/dwalsh/SELinux/Fedora -- From selinux at gmail.com Fri Dec 16 17:15:47 2005 From: selinux at gmail.com (Tom London) Date: Fri, 16 Dec 2005 09:15:47 -0800 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <43A2E433.8070708@redhat.com> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> <43A2E433.8070708@redhat.com> Message-ID: <4c4ba1530512160915j53a2f308q1949848acf10147@mail.gmail.com> On 12/16/05, Daniel J Walsh wrote: > Stephen Smalley wrote: > > On Fri, 2005-12-16 at 07:34 -0800, Tom London wrote: > > > >> running today's policy, have boot/network problems. > >> > >> Fixed boot problems by turning off hplip/cups. > >> > >> Appears more 'netif' work is needed: > >> > > > > Dan removed what he thought were obsolete initial SIDs from the policy, > > but you can't do that without rebuilding the kernel to match. Thus, > > rawhide policy is busted, revert and reboot and wait for an update. > > > > > Fixed policy is on ftp://people.redhat.com/dwalsh/SELinux/Fedora > > Uhh... get the following messages with 'yum --enablerepo=dwalsh update selinux-policy-targeted'. Do I need the updated libsepol, etc. too? tom (1/1): selinux-policy-tar 100% |=========================| 235 kB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : selinux-policy-targeted ######################### [1/2] libsepol.mls_from_string: invalid MLS context s0) libsepol.mls_from_string: could not construct mls context structure libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:var_run_t:s0) to sid /etc/selinux/targeted/contexts/files/file_contexts: line 808 has invalid context system_u:object_r:var_run_t:s0) libsemanage.semanage_install_active: setfiles returned error code 1. Failed! Cleanup : selinux-policy-targeted ######################### [2/2] Updated: selinux-policy-targeted.noarch 0:2.1.6-6 Complete! -- Tom London From linux_4ever at yahoo.com Fri Dec 16 17:40:17 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 16 Dec 2005 09:40:17 -0800 (PST) Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> Message-ID: <20051216174017.73596.qmail@web51502.mail.yahoo.com> >type=SOCKADDR msg=audit(1134746217.580:190): >saddr=020014E9E00000FB0000000000000000 If you add the -i parameter to ausearch, it will interpret this so we can see what it means. Dan already has a new policy, so its not needed this time. But its helpful to see this field next time. Thanks, -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dwalsh at redhat.com Fri Dec 16 17:56:35 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 Dec 2005 12:56:35 -0500 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <4c4ba1530512160915j53a2f308q1949848acf10147@mail.gmail.com> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> <43A2E433.8070708@redhat.com> <4c4ba1530512160915j53a2f308q1949848acf10147@mail.gmail.com> Message-ID: <43A2FFD3.9010908@redhat.com> Tom London wrote: > On 12/16/05, Daniel J Walsh wrote: > >> Stephen Smalley wrote: >> >>> On Fri, 2005-12-16 at 07:34 -0800, Tom London wrote: >>> >>> >>>> running today's policy, have boot/network problems. >>>> >>>> Fixed boot problems by turning off hplip/cups. >>>> >>>> Appears more 'netif' work is needed: >>>> >>>> >>> Dan removed what he thought were obsolete initial SIDs from the policy, >>> but you can't do that without rebuilding the kernel to match. Thus, >>> rawhide policy is busted, revert and reboot and wait for an update. >>> >>> >>> >> Fixed policy is on ftp://people.redhat.com/dwalsh/SELinux/Fedora >> >> >> > Uhh... get the following messages with 'yum --enablerepo=dwalsh update > selinux-policy-targeted'. Do I need the updated libsepol, etc. too? > > tom > > (1/1): selinux-policy-tar 100% |=========================| 235 kB 00:00 > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Updating : selinux-policy-targeted ######################### [1/2] > libsepol.mls_from_string: invalid MLS context s0) > libsepol.mls_from_string: could not construct mls context structure > libsepol.context_from_record: could not create context structure > libsepol.context_from_string: could not create context structure > libsepol.sepol_context_to_sid: could not convert > system_u:object_r:var_run_t:s0) to sid > /etc/selinux/targeted/contexts/files/file_contexts: line 808 has > invalid context system_u:object_r:var_run_t:s0) > libsemanage.semanage_install_active: setfiles returned error code 1. > Failed! > Cleanup : selinux-policy-targeted ######################### [2/2] > > Updated: selinux-policy-targeted.noarch 0:2.1.6-6 > Complete! > > > > -- > Tom London > Could you try semodule -b /usr/share/selinux/targeted/base.pp See if the previous error is just caused by the bad policy. Dan -- From linux_4ever at yahoo.com Fri Dec 16 18:01:56 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 16 Dec 2005 10:01:56 -0800 (PST) Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <43A2E433.8070708@redhat.com> Message-ID: <20051216180156.81370.qmail@web51502.mail.yahoo.com> >> Dan removed what he thought were obsolete initial SIDs from the policy, >> but you can't do that without rebuilding the kernel to match. Thus, >> rawhide policy is busted, revert and reboot and wait for an update. >> >Fixed policy is on ftp://people.redhat.com/dwalsh/SELinux/Fedora I get this when installing: [root at localhost ~]# rpm -Uvh ~sgrubb/selinux-policy-targeted-2.1.6-6.noarch.rpm Preparing... ########################################### [100%] 1:selinux-policy-targeted########################################### [100%] libsepol.mls_from_string: invalid MLS context s0) libsepol.mls_from_string: could not construct mls context structure libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:var_run_t:s0) to sid /etc/selinux/targeted/contexts/files/file_contexts: line 808 has invalid context system_u:object_r:var_run_t:s0) libsemanage.semanage_install_active: setfiles returned error code 1. Failed! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From linux_4ever at yahoo.com Fri Dec 16 18:03:59 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 16 Dec 2005 10:03:59 -0800 (PST) Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <43A2FFD3.9010908@redhat.com> Message-ID: <20051216180359.83342.qmail@web51502.mail.yahoo.com> >Could you try semodule -b /usr/share/selinux/targeted/base.pp > >See if the previous error is just caused by the bad policy. When I run that command, I get the same errors. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From selinux at gmail.com Fri Dec 16 18:05:47 2005 From: selinux at gmail.com (Tom London) Date: Fri, 16 Dec 2005 10:05:47 -0800 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <43A2FFD3.9010908@redhat.com> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> <43A2E433.8070708@redhat.com> <4c4ba1530512160915j53a2f308q1949848acf10147@mail.gmail.com> <43A2FFD3.9010908@redhat.com> Message-ID: <4c4ba1530512161005j72d6bdf2na411facea0765e48@mail.gmail.com> On 12/16/05, Daniel J Walsh wrote: > Tom London wrote: > > On 12/16/05, Daniel J Walsh wrote: > > > >> Stephen Smalley wrote: > >> > >>> On Fri, 2005-12-16 at 07:34 -0800, Tom London wrote: > >>> > >>> > >>>> running today's policy, have boot/network problems. > >>>> > >>>> Fixed boot problems by turning off hplip/cups. > >>>> > >>>> Appears more 'netif' work is needed: > >>>> > >>>> > >>> Dan removed what he thought were obsolete initial SIDs from the policy, > >>> but you can't do that without rebuilding the kernel to match. Thus, > >>> rawhide policy is busted, revert and reboot and wait for an update. > >>> > >>> > >>> > >> Fixed policy is on ftp://people.redhat.com/dwalsh/SELinux/Fedora > >> > >> > >> > > Uhh... get the following messages with 'yum --enablerepo=dwalsh update > > selinux-policy-targeted'. Do I need the updated libsepol, etc. too? > > > > tom > > > > (1/1): selinux-policy-tar 100% |=========================| 235 kB 00:00 > > Running Transaction Test > > Finished Transaction Test > > Transaction Test Succeeded > > Running Transaction > > Updating : selinux-policy-targeted ######################### [1/2] > > libsepol.mls_from_string: invalid MLS context s0) > > libsepol.mls_from_string: could not construct mls context structure > > libsepol.context_from_record: could not create context structure > > libsepol.context_from_string: could not create context structure > > libsepol.sepol_context_to_sid: could not convert > > system_u:object_r:var_run_t:s0) to sid > > /etc/selinux/targeted/contexts/files/file_contexts: line 808 has > > invalid context system_u:object_r:var_run_t:s0) > > libsemanage.semanage_install_active: setfiles returned error code 1. > > Failed! > > Cleanup : selinux-policy-targeted ######################### [2/2] > > > > Updated: selinux-policy-targeted.noarch 0:2.1.6-6 > > Complete! > > > > > > > > -- > > Tom London > > > Could you try semodule -b /usr/share/selinux/targeted/base.pp > > > See if the previous error is just caused by the bad policy. > > Dan > [root at tlondon packages]# semodule -b /usr/share/selinux/targeted/base.pp libsepol.mls_from_string: invalid MLS context s0) libsepol.mls_from_string: could not construct mls context structure libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:var_run_t:s0) to sid /etc/selinux/targeted/contexts/files/file_contexts: line 808 has invalid context system_u:object_r:var_run_t:s0) libsemanage.semanage_install_active: setfiles returned error code 1. Failed! [root at tlondon packages]# -- Tom London From sds at tycho.nsa.gov Fri Dec 16 18:30:36 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 Dec 2005 13:30:36 -0500 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <4c4ba1530512161005j72d6bdf2na411facea0765e48@mail.gmail.com> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> <43A2E433.8070708@redhat.com> <4c4ba1530512160915j53a2f308q1949848acf10147@mail.gmail.com> <43A2FFD3.9010908@redhat.com> <4c4ba1530512161005j72d6bdf2na411facea0765e48@mail.gmail.com> Message-ID: <1134757836.28677.41.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-12-16 at 10:05 -0800, Tom London wrote: > [root at tlondon packages]# semodule -b /usr/share/selinux/targeted/base.pp > libsepol.mls_from_string: invalid MLS context s0) Looks like macro-processing error at policy build time - you have a terminating parenthesis there after the s0. > libsepol.mls_from_string: could not construct mls context structure > libsepol.context_from_record: could not create context structure > libsepol.context_from_string: could not create context structure > libsepol.sepol_context_to_sid: could not convert > system_u:object_r:var_run_t:s0) to sid > /etc/selinux/targeted/contexts/files/file_contexts: line 808 has > invalid context system_u:object_r:var_run_t:s0) > libsemanage.semanage_install_active: setfiles returned error code 1. > Failed! > [root at tlondon packages]# -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Dec 16 18:43:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 Dec 2005 13:43:53 -0500 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <1134757836.28677.41.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> <43A2E433.8070708@redhat.com> <4c4ba1530512160915j53a2f308q1949848acf10147@mail.gmail.com> <43A2FFD3.9010908@redhat.com> <4c4ba1530512161005j72d6bdf2na411facea0765e48@mail.gmail.com> <1134757836.28677.41.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <43A30AE9.30802@redhat.com> Stephen Smalley wrote: > On Fri, 2005-12-16 at 10:05 -0800, Tom London wrote: > >> [root at tlondon packages]# semodule -b /usr/share/selinux/targeted/base.pp >> libsepol.mls_from_string: invalid MLS context s0) >> > > Looks like macro-processing error at policy build time - you have a > terminating parenthesis there after the s0. > > >> libsepol.mls_from_string: could not construct mls context structure >> libsepol.context_from_record: could not create context structure >> libsepol.context_from_string: could not create context structure >> libsepol.sepol_context_to_sid: could not convert >> system_u:object_r:var_run_t:s0) to sid >> /etc/selinux/targeted/contexts/files/file_contexts: line 808 has >> invalid context system_u:object_r:var_run_t:s0) >> libsemanage.semanage_install_active: setfiles returned error code 1. >> Failed! >> [root at tlondon packages]# >> > > New policy on people to fix this problem. Should have been caught during build. -- From selinux at gmail.com Fri Dec 16 20:02:10 2005 From: selinux at gmail.com (Tom London) Date: Fri, 16 Dec 2005 12:02:10 -0800 Subject: selinux-policy-targeted-2.1.6-4: needs netif In-Reply-To: <43A30AE9.30802@redhat.com> References: <4c4ba1530512160734j705e5ad8l230b5a9f8dd9abf9@mail.gmail.com> <1134748203.28677.0.camel@moss-spartans.epoch.ncsc.mil> <43A2E433.8070708@redhat.com> <4c4ba1530512160915j53a2f308q1949848acf10147@mail.gmail.com> <43A2FFD3.9010908@redhat.com> <4c4ba1530512161005j72d6bdf2na411facea0765e48@mail.gmail.com> <1134757836.28677.41.camel@moss-spartans.epoch.ncsc.mil> <43A30AE9.30802@redhat.com> Message-ID: <4c4ba1530512161202q3b1df329o1684d5a670c053b9@mail.gmail.com> On 12/16/05, Daniel J Walsh wrote: > Stephen Smalley wrote: > > On Fri, 2005-12-16 at 10:05 -0800, Tom London wrote: > > > >> [root at tlondon packages]# semodule -b /usr/share/selinux/targeted/base.pp > >> libsepol.mls_from_string: invalid MLS context s0) > >> > > > > Looks like macro-processing error at policy build time - you have a > > terminating parenthesis there after the s0. > > > > > >> libsepol.mls_from_string: could not construct mls context structure > >> libsepol.context_from_record: could not create context structure > >> libsepol.context_from_string: could not create context structure > >> libsepol.sepol_context_to_sid: could not convert > >> system_u:object_r:var_run_t:s0) to sid > >> /etc/selinux/targeted/contexts/files/file_contexts: line 808 has > >> invalid context system_u:object_r:var_run_t:s0) > >> libsemanage.semanage_install_active: setfiles returned error code 1. > >> Failed! > >> [root at tlondon packages]# > >> > > > > > New policy on people to fix this problem. Should have been caught > during build. > This works for me. Thanks! tom -- Tom London From dant at cdkkt.com Sat Dec 17 02:11:25 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 16 Dec 2005 18:11:25 -0800 Subject: Problem with VNC and SELinux: FC4 Message-ID: Folks, With the new SELinux updates, it appears that root, other than normal users can login to Fedora via VNC Server? My VNC Server is setup such that I am using xinitd for VNC Server requests. Another problem I noticed is that when I log into my Fedora system via VNC as root user, and open a xterm window and run a su - , I get back a SElinux message: ================================================ # su - dan Your default context is: user_u:system_r:kernel_t. Do you want to want to choose a different one? [n] ================================================ It is *possible* that this problem came up when I had to make a copy of my filesystem to another hard-disk for the purpose of creating a /boot partition (my bad) and copied/restored the filesystem back over to the main drive. I don't think I made any copy/restore mistakes as I know the fs permissions are correct but I cannot speak for filesystem journaling or whatever that keeps track of the SELinux attributes. In any case, what can I do to resolve my VNC and/or su issue knowing that SElinux has something to do with it? Thanks! Dan Thurman -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/204 - Release Date: 12/15/2005 From chanson at TrustedCS.com Sat Dec 17 05:40:57 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Sat, 17 Dec 2005 00:40:57 -0500 Subject: Problem with VNC and SELinux: FC4 Message-ID: <36282A1733C57546BE392885C0618592057341@chaos.tcs.tcs-sec.com> >Folks, > >With the new SELinux updates, it appears that root, >other than normal users can login to Fedora via VNC >Server? My VNC Server is setup such that I am using >xinitd for VNC Server requests. > A problem I noticed on FC4 with updates is that running VNC from initscripts will cause user sessions to have a system_u:system_r:initrc_t context. If you start a VNC server as the user from a shell, you get get the expected behavior of unconfined_t session. >Another problem I noticed is that when I log into my >Fedora system via VNC as root user, and open a xterm >window and run a su - , I get back a >SElinux message: > >================================================ ># su - dan >Your default context is: user_u:system_r:kernel_t. > >Do you want to want to choose a different one? [n] >================================================ From nicolas.mailhot at laposte.net Sat Dec 17 10:49:10 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Dec 2005 11:49:10 +0100 Subject: Using spamassassin with selinux Message-ID: <43A3ED26.6060406@laposte.net> Hi, I'm still trying to get spamassassin to work properly with procmail selinux (this is bug #172088, been open almost 50 days, still not closed). I'm getting a bit tired of watching my spam system fail and will probably revert to no selinux testing at all (selinux=0, like almost everyone else) if this continues. 50 days is more than enough to fix a reported problem. I have the following entry in my procmail : :0fw: .spamc.lock * < 256000 | spamc Now maildir logs show spamassassin is denied access to its own files when selinux is enabled : Dec 17 11:30:05 rousalka spamd[2681]: spamd: connection from localhost.localdomain [127.0.0.1] at port 50637 Dec 17 11:30:05 rousalka spamd[2681]: spamd: setuid to nim succeeded (yes spamd does setuids) Dec 17 11:30:05 rousalka spamd[2681]: spamd: creating default_prefs: /home/nim/.spamassassin/user_prefs (spamd didn't see the pref files already existed - probably because of selinux - so it tries to create it) Dec 17 11:30:05 rousalka spamd[2681]: mkdir /home/nim: Le fichier existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line 1467 (the system tells it to get lost, the file already exists) Dec 17 11:30:05 rousalka spamd[2681]: config: cannot write to /home/nim/.spamassassin/user_prefs: Permission non accord?e (and spamd is not allowed to write it) Dec 17 11:30:05 rousalka spamd[2681]: spamd: failed to create readable default_prefs: /home/nim/.spamassassin/user_prefs likewise pyzor is dead Dec 17 11:30:05 rousalka spamd[2681]: internal error Dec 17 11:30:05 rousalka spamd[2681]: pyzor: check failed: internal error and the autowhitelist can not be modified, because spamd can not create a lockfile Dec 17 11:30:05 rousalka spamd[2681]: locker: safe_lock: cannot create tmp lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2681 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e Dec 17 11:30:05 rousalka spamd[2681]: auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot create tmp lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2681 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e Dec 17 11:30:05 rousalka spamd[2681]: Can't call method "finish" on an undefined value at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/Plugin/AWL.pm line 397. This on a fully relabeled selinux-policy-targeted-2.1.6-8 rawhide system -- Nicolas Mailhot From dwalsh at redhat.com Sat Dec 17 13:04:28 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 17 Dec 2005 08:04:28 -0500 Subject: Using spamassassin with selinux In-Reply-To: <43A3ED26.6060406@laposte.net> References: <43A3ED26.6060406@laposte.net> Message-ID: <43A40CDC.6010302@redhat.com> Nicolas Mailhot wrote: > Hi, > > I'm still trying to get spamassassin to work properly with procmail > selinux (this is bug #172088, been open almost 50 days, still not > closed). I'm getting a bit tired of watching my spam system fail and > will probably revert to no selinux testing at all (selinux=0, like > almost everyone else) if this continues. 50 days is more than enough > to fix a reported problem. > > I have the following entry in my procmail : > > :0fw: .spamc.lock > * < 256000 > | spamc > > Now maildir logs show spamassassin is denied access to its own files > when selinux is enabled : > > Dec 17 11:30:05 rousalka spamd[2681]: spamd: connection from > localhost.localdomain [127.0.0.1] at port 50637 > Dec 17 11:30:05 rousalka spamd[2681]: spamd: setuid to nim succeeded > > (yes spamd does setuids) > > Dec 17 11:30:05 rousalka spamd[2681]: spamd: creating default_prefs: > /home/nim/.spamassassin/user_prefs > > (spamd didn't see the pref files already existed - probably because of > selinux - so it tries to create it) > > Dec 17 11:30:05 rousalka spamd[2681]: mkdir /home/nim: Le fichier > existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line > 1467 > > (the system tells it to get lost, the file already exists) > > Dec 17 11:30:05 rousalka spamd[2681]: config: cannot write to > /home/nim/.spamassassin/user_prefs: Permission non accord?e > > (and spamd is not allowed to write it) > > Dec 17 11:30:05 rousalka spamd[2681]: spamd: failed to create readable > default_prefs: /home/nim/.spamassassin/user_prefs > > likewise pyzor is dead > > Dec 17 11:30:05 rousalka spamd[2681]: internal error > Dec 17 11:30:05 rousalka spamd[2681]: pyzor: check failed: internal error > > and the autowhitelist can not be modified, because spamd can not > create a lockfile > > Dec 17 11:30:05 rousalka spamd[2681]: locker: safe_lock: cannot create > tmp lockfile > /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2681 > for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e > Dec 17 11:30:05 rousalka spamd[2681]: auto-whitelist: open of > auto-whitelist file failed: locker: safe_lock: cannot create tmp > lockfile > /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2681 > for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e > Dec 17 11:30:05 rousalka spamd[2681]: Can't call method "finish" on an > undefined value at > /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/Plugin/AWL.pm line > 397. > > This on a fully relabeled selinux-policy-targeted-2.1.6-8 rawhide system > Funny this bug was just closed for FC4. What avc messages are you seeing? Current policy has userdom_manage_generic_user_home_dirs(spamd_t) userdom_manage_generic_user_home_files(spamd_t) Which should allow spamd_t to write to the users home directories. Dan -- From nicolas.mailhot at laposte.net Sat Dec 17 13:17:47 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Dec 2005 14:17:47 +0100 Subject: Using spamassassin with selinux In-Reply-To: <43A40CDC.6010302@redhat.com> References: <43A3ED26.6060406@laposte.net> <43A40CDC.6010302@redhat.com> Message-ID: <43A40FFB.3090605@laposte.net> Daniel J Walsh wrote: > Funny this bug was just closed for FC4. What avc messages are you seeing? > > > Current policy has > userdom_manage_generic_user_home_dirs(spamd_t) > userdom_manage_generic_user_home_files(spamd_t) > > Which should allow spamd_t to write to the users home directories. I'm not seeing anything closely related nowadays. I did at first but now it's failing without logging any clear avcs : # audit2allow < /var/log/audit/audit.log allow dovecot_auth_t tmp_t:dir getattr; allow saslauthd_t usr_t:lnk_file read; allow sysadm_su_t etc_runtime_t:file read; allow sysadm_su_t tmp_t:dir getattr; allow sysadm_su_t usr_t:lnk_file read; allow unconfined_t lib_t:file execmod; But shutting down selinux fixes the problem, so it's selinux-related -- Nicolas Mailhot From dant at cdkkt.com Sat Dec 17 20:26:35 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sat, 17 Dec 2005 12:26:35 -0800 Subject: Problem with VNC and SELinux: FC4 Message-ID: >From: fedora-list-bounces at redhat.com >[mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel B. Thurman >Sent: Friday, December 16, 2005 6:11 PM >To: For users of Fedora Core releases (E-mail) >Cc: Fedora SELinux support list for users & developers. >Subject: Problem with VNC and SELinux: FC4 > > > >Folks, > >With the new SELinux updates, it appears that root, >other than normal users can login to Fedora via VNC >Server? My VNC Server is setup such that I am using >xinitd for VNC Server requests. > >Another problem I noticed is that when I log into my >Fedora system via VNC as root user, and open a xterm >window and run a su - , I get back a >SElinux message: > >================================================ ># su - dan >Your default context is: user_u:system_r:kernel_t. > >Do you want to want to choose a different one? [n] >================================================ > >It is *possible* that this problem came up when >I had to make a copy of my filesystem to another >hard-disk for the purpose of creating a /boot >partition (my bad) and copied/restored the filesystem >back over to the main drive. I don't think I made >any copy/restore mistakes as I know the fs permissions >are correct but I cannot speak for filesystem journaling >or whatever that keeps track of the SELinux attributes. > >In any case, what can I do to resolve my VNC and/or su >issue knowing that SElinux has something to do with it? > >Thanks! >Dan Thurman > >-- >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.1.371 / Virus Database: 267.14.1/204 - Release >Date: 12/15/2005 > > Someone care to help me out here? I have been trying to remote login as a non-root user and VNC is trying to let me in, but for some reason is dropping the VNC client, thus denying me. Login as root works. I suspect that a selinux context is needed to allow remote non-root VNC user access? I had a private email sent to me saying that they had a similar problem as well but did not offer any solution for a fix. Anything I can do or research to narrow down this issue? Thanks, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 12/16/2005 From dant at cdkkt.com Sat Dec 17 22:30:28 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sat, 17 Dec 2005 14:30:28 -0800 Subject: Non-root console login issue! (was: Problem with VNC and SELinux: FC4) Message-ID: >From: fedora-list-bounces at redhat.com >[mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel B. Thurman >Sent: Friday, December 16, 2005 6:11 PM >To: For users of Fedora Core releases (E-mail) >Cc: Fedora SELinux support list for users & developers. >Subject: Problem with VNC and SELinux: FC4 > > > >Folks, > >With the new SELinux updates, it appears that root, >other than normal users can login to Fedora via VNC >Server? My VNC Server is setup such that I am using >xinitd for VNC Server requests. > >Another problem I noticed is that when I log into my >Fedora system via VNC as root user, and open a xterm >window and run a su - , I get back a >SElinux message: > >================================================ ># su - dan >Your default context is: user_u:system_r:kernel_t. > >Do you want to want to choose a different one? [n] >================================================ > >It is *possible* that this problem came up when >I had to make a copy of my filesystem to another >hard-disk for the purpose of creating a /boot >partition (my bad) and copied/restored the filesystem >back over to the main drive. I don't think I made >any copy/restore mistakes as I know the fs permissions >are correct but I cannot speak for filesystem journaling >or whatever that keeps track of the SELinux attributes. > >In any case, what can I do to resolve my VNC and/or su >issue knowing that SElinux has something to do with it? > >Thanks! >Dan Thurman > Problem is not related to SELinux and not really related to VNC. It turns out that I cannot log into the console as a non-root user and I get a message saying: ======================================================= Your session lasted less than 10 seconds. If you have not logged out yourself, this could mean that there is some installation problem or that you may be out of diskspace. Try logging in with one of the failsafe sessions to see if you can fix this problem. [] View details (~/.xsession-errors file) ======================================================= The problem here is that the .xsession-errors file does not exist. I also note from /var/log/message file: ======================================================= Dec 17 12:45:31 linux gdm(pam_unix)[16480]: session opened for user dant by (uid=0) Dec 17 12:45:32 linux gdm(pam_unix)[16480]: session closed for user dant Dec 17 12:45:32 linux dbus: avc: 0 AV entries and 0/512 buckets used, longest chain length 0 ======================================================= And from /var/log/audit/audit.log ======================================================= type=USER_AUTH msg=audit(1134858412.155:3929): user pid=3397 uid=0 auid=4294967295 msg='PAM authentication: user=dant exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 result=Success)' type=USER_ACCT msg=audit(1134858412.159:3930): user pid=3397 uid=0 auid=4294967295 msg='PAM accounting: user=dant exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 result=Success)' type=CRED_ACQ msg=audit(1134858412.247:3931): user pid=3397 uid=0 auid=4294967295 msg='PAM setcred: user=dant exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 result=Success)' type=USER_START msg=audit(1134858412.307:3932): user pid=3397 uid=0 auid=4294967295 msg='PAM session open: user=dant exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 result=Success)' ======================================================= File: # ls -l /usr/bin/gdm-binary -rwxr-xr-x 1 root root 251668 May 23 2005 /usr/bin/gdm-binary HALLLLLP! Please :-) Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 12/16/2005 From dant at cdkkt.com Sat Dec 17 23:07:04 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sat, 17 Dec 2005 15:07:04 -0800 Subject: Non-root console login issue! (was: Problem with VNC and SELinux:FC4) Message-ID: >From: fedora-list-bounces at redhat.com >[mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel B. Thurman >Sent: Saturday, December 17, 2005 2:30 PM >To: For users of Fedora Core releases >Cc: Fedora SELinux support list for users & developers. >Subject: Non-root console login issue! (was: Problem with VNC and >SELinux:FC4) > > >>From: fedora-list-bounces at redhat.com >>[mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel B. Thurman >>Sent: Friday, December 16, 2005 6:11 PM >>To: For users of Fedora Core releases (E-mail) >>Cc: Fedora SELinux support list for users & developers. >>Subject: Problem with VNC and SELinux: FC4 >> >> >> >>Folks, >> >>With the new SELinux updates, it appears that root, >>other than normal users can login to Fedora via VNC >>Server? My VNC Server is setup such that I am using >>xinitd for VNC Server requests. >> >>Another problem I noticed is that when I log into my >>Fedora system via VNC as root user, and open a xterm >>window and run a su - , I get back a >>SElinux message: >> >>================================================ >># su - dan >>Your default context is: user_u:system_r:kernel_t. >> >>Do you want to want to choose a different one? [n] >>================================================ >> >>It is *possible* that this problem came up when >>I had to make a copy of my filesystem to another >>hard-disk for the purpose of creating a /boot >>partition (my bad) and copied/restored the filesystem >>back over to the main drive. I don't think I made >>any copy/restore mistakes as I know the fs permissions >>are correct but I cannot speak for filesystem journaling >>or whatever that keeps track of the SELinux attributes. >> >>In any case, what can I do to resolve my VNC and/or su >>issue knowing that SElinux has something to do with it? >> >>Thanks! >>Dan Thurman >> > >Problem is not related to SELinux and not really related >to VNC. It turns out that I cannot log into the console >as a non-root user and I get a message saying: > >======================================================= >Your session lasted less than 10 seconds. If you have not >logged out yourself, this could mean that there is some >installation problem or that you may be out of diskspace. >Try logging in with one of the failsafe sessions to see if >you can fix this problem. > >[] View details (~/.xsession-errors file) >======================================================= > >The problem here is that the .xsession-errors file does >not exist. I also note from /var/log/message file: > >======================================================= >Dec 17 12:45:31 linux gdm(pam_unix)[16480]: session opened for >user dant by (uid=0) >Dec 17 12:45:32 linux gdm(pam_unix)[16480]: session closed for >user dant >Dec 17 12:45:32 linux dbus: avc: 0 AV entries and 0/512 >buckets used, longest chain length 0 >======================================================= > >And from /var/log/audit/audit.log >======================================================= >type=USER_AUTH msg=audit(1134858412.155:3929): user pid=3397 >uid=0 auid=4294967295 msg='PAM authentication: user=dant >exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >result=Success)' >type=USER_ACCT msg=audit(1134858412.159:3930): user pid=3397 >uid=0 auid=4294967295 msg='PAM accounting: user=dant >exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >result=Success)' >type=CRED_ACQ msg=audit(1134858412.247:3931): user pid=3397 >uid=0 auid=4294967295 msg='PAM setcred: user=dant >exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >result=Success)' >type=USER_START msg=audit(1134858412.307:3932): user pid=3397 >uid=0 auid=4294967295 msg='PAM session open: user=dant >exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >result=Success)' >======================================================= > >File: ># ls -l /usr/bin/gdm-binary >-rwxr-xr-x 1 root root 251668 May 23 2005 /usr/bin/gdm-binary > >HALLLLLP! Please :-) > >Dan > Sorry - had to add this tidbit.... seems that SElinux may be involved or maybe my file journaling is messed up after a "restore"? I tried to create a new user account to see if by doing this I would get a correct security context and be able to log into the console but WHOA!!! What is going on here!?!?!? ======================================================= [root at linux ~]# useradd dant2 useradd: cannot rewrite password file [root at linux ~]# ======================================================= File: /var/log/audit/audit.log: 94967295 msg='useradd: op=adding home directory acct=dant2 res=success' type=AVC msg=audit(1134859204.879:4004): avc: denied { create } for pid=19177 comm="useradd" name=".kde" scontext=root:system_r:kernel_t tcontext=user_u:object_r:user_home_t tclass=dir type=SYSCALL msg=audit(1134859204.879:4004): arch=40000003 syscall=39 success=no exit=-13 a0=bfd81470 a1=1ed a2=98fd2ef a3=ffffffff items=1 pid=19177 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" exe="/usr/sbin/useradd" type=CWD msg=audit(1134859204.879:4004): cwd="/root" type=PATH msg=audit(1134859204.879:4004): item=0 name="/home/dant2/.kde" flags=10 inode=1245989 dev=03:02 mode=040755 ouid=511 ogid=512 rdev=00:00 type=AVC msg=audit(1134859204.883:4005): avc: denied { create } for pid=19177 comm="useradd" name="passwd+" scontext=root:system_r:kernel_t tcontext=system_u:object_r:file_t tclass=file type=SYSCALL msg=audit(1134859204.883:4005): arch=40000003 syscall=5 success=no exit=-13 a0=bfd817e4 a1=8241 a2=1b6 a3=98f6f38 items=1 pid=19177 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" exe="/usr/sbin/useradd" type=CWD msg=audit(1134859204.883:4005): cwd="/root" type=PATH msg=audit(1134859204.883:4005): item=0 name="/etc/passwd+" flags=310 inode=1212417 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00 type=USER_CHAUTHTOK msg=audit(1134859204.883:4006): user pid=19177 uid=0 auid=4294967295 msg='useradd: op=adding user acct=dant2 res=failed' ======================================================= Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 12/16/2005 From beheer at net-care.nl Sun Dec 18 00:32:10 2005 From: beheer at net-care.nl (Mark Evers) Date: Sun, 18 Dec 2005 01:32:10 +0100 Subject: ProFTPD not showing all directorys. Message-ID: <002b01c6036a$7c4b3c80$3201a8c0@game01> Well, SELinux handed me another problem, i've been reading into the http://fedora.redhat.com/docs/selinux-faq-fc3/ hoping i would get my answer, without luck. The problem is, when i connect to my FC4's Proftpd server i'm missing alot of directorys and files, and they do excist, i checked using SSH At first i could only see the "homes" directory, then i tried a fixfiles relabel, it brought back some dir's, but not the ones that are most important like public_html. Then i tried to disable SELinux to see if it's really SELinux related, and like magic, there are the missing dir's. What i want, but can't find is a way for users to have full access to there home dir, they are chrooted so they can't look "beyond" there own home dir, and still use SELinux. To be honest, i'm verry new to SELinux and i'm still trying to figure this out, i like the idea of security alot, but i find it hard to get information about it, like how to check what policys are enabled, and what policys can be added. I've tried the system-config-security-level, and the only thing it showed me was the firewall. I'm using Shorewall so that's not usefull to me. I hope someone can help out. Thanks Mark Evers -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Sun Dec 18 11:08:27 2005 From: paul at city-fan.org (Paul Howarth) Date: Sun, 18 Dec 2005 11:08:27 +0000 Subject: ProFTPD not showing all directorys. In-Reply-To: <002b01c6036a$7c4b3c80$3201a8c0@game01> References: <002b01c6036a$7c4b3c80$3201a8c0@game01> Message-ID: <1134904107.7060.21.camel@laurel.intra.city-fan.org> On Sun, 2005-12-18 at 01:32 +0100, Mark Evers wrote: > Well, SELinux handed me another problem, i've been reading into the > http://fedora.redhat.com/docs/selinux-faq-fc3/ hoping i would get my > answer, > without luck. > > The problem is, when i connect to my FC4's Proftpd server i'm missing > alot of directorys and files, and they do excist, i checked using SSH > At first i could only see the "homes" directory, then i tried > a fixfiles relabel, it brought back some dir's, but not the ones that > are most important like public_html. > Then i tried to disable SELinux to see if it's really SELinux related, > and like magic, there are the missing dir's. > > What i want, but can't find is a way for users to have full access to > there home dir, they are chrooted so they can't look "beyond" there > own home dir, and still use SELinux. Have a look at "man ftpd_selinux"; you'll probably find the following helps: # setsebool -P ftp_home_dir and if you're running proftpd as a daemon rather than from xinetd (which is probably the case): # setsebool -P ftpd_is_daemon 1 Paul. From dravet at hotmail.com Sun Dec 18 16:26:47 2005 From: dravet at hotmail.com (Jason Dravet) Date: Sun, 18 Dec 2005 10:26:47 -0600 Subject: error installing selinux targeted policy Message-ID: I updated to todays rawhide and when yum was updating selinux-policy-targeted I saw the following message: Updating : selinux-policy-targeted ##################### [140/400] libsemanage.parse_module_headers: Data did not represent a module. Failed! Things seem to work as they did yesterday. FYI, Jason From dant at cdkkt.com Sun Dec 18 21:02:01 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sun, 18 Dec 2005 13:02:01 -0800 Subject: SELinux is screwing me up!!!! Help! Message-ID: Folks, I believe all of my problems started because I had backup and restored my filesystem and and *somehow* all or some of the selinux attributes may have been messed up. Reading the selinux manual, it says that you can rebuild it by touching a file: /.autorelabel and reboot. I did that, and I still have the same problem as before - nothing has changed. I checked some of the file-permissions such as /bin/su and note that they are correct and other files and directory - so at first mini-check it all appears to be correct. The restore appears correct throughout on precursory checks. The following are problem I am having.... 1) I cannot login as a non-root user! I have 4 non-root user accounts and yet I cannot log into any of them except as root! I get the following message when attempting to log in: ========================================== Your session lasted less than 10 seconds. If you have not logged out yourself, this could mean that there is some installation problem or that you may be out of diskspace. Try logging in with one of the failsafe sessions to see if you can fix this problem. [] View details (~/.xsession-errors file) ========================================== then I get kicked out of the login session. 2) As root user, when I `su - dant', I get this EVERY TIME: ========================================== Your default context is: user_u:system_r:kernel_t. Do you want to want to choose a different one? [n] ========================================== chosing the default lets me in as this user. Choosing 'n' gives me a list of context and choosing one lets me in. 3) As root, I tried to create a non-root user: # useradd joed /var/log/message says: type=USER_CHAUTHTOK msg=audit(1134936930.895:3557): user pid=19294 uid=0 auid=4294967295 msg='useradd: op=adding user acct=joed res=success' type=USER_CHAUTHTOK msg=audit(1134936930.895:3558): user pid=19294 uid=0 auid=4294967295 msg='useradd: op=adding home directory acct=joed res=success' type=AVC msg=audit(1134936931.415:3559): avc: denied { create } for pid=19294 comm="useradd" name=".kde" scontext=root:system_r:kernel_t tcontext=user_u:object_r:user_home_t tclass=dir type=SYSCALL msg=audit(1134936931.415:3559): arch=40000003 syscall=39 success=no exit=-13 a0=bfde8bf0 a1=1ed a2=92f92ef a3=ffffffff items=1 pid=19294 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" exe="/usr/sbin/useradd" type=CWD msg=audit(1134936931.415:3559): cwd="/root" type=PATH msg=audit(1134936931.415:3559): item=0 name="/home/joed/.kde" flags=10 inode=1245989 dev=03:02 mode=040755 ouid=511 ogid=512 rdev=00:00 type=AVC msg=audit(1134936931.419:3560): avc: denied { create } for pid=19294 comm="useradd" name="passwd+" scontext=root:system_r:kernel_t tcontext=system_u:object_r:etc_t tclass=file type=SYSCALL msg=audit(1134936931.419:3560): arch=40000003 syscall=5 success=no exit=-13 a0=bfde8f64 a1=8241 a2=1b6 a3=92f33b8 items=1 pid=19294 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" exe="/usr/sbin/useradd" type=CWD msg=audit(1134936931.419:3560): cwd="/root" type=PATH msg=audit(1134936931.419:3560): item=0 name="/etc/passwd+" flags=310 inode=1212417 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00 type=USER_CHAUTHTOK msg=audit(1134936931.419:3561): user pid=19294 uid=0 auid=4294967295 msg='useradd: op=adding user acct=joed res=failed' 4) Cannot 'yum update' successfully and these are the errors I see: Transaction Test Succeeded Running Transaction Installing: arts ####################### [ 1/26] error: unpacking of archive failed on file /usr/bin/artscat: cpio: lsetfilecon Installing: perl ####################### [ 2/26] error: unpacking of archive failed on file /usr/bin/a2p: cpio: lsetfilecon Installing: cups-libs ####################### [ 3/26] error: unpacking of archive failed on file /usr/lib/libcups.so.2: cpio: lsetfilecon error: %pre(kdelibs-3.5.0-0.1.fc4.i386) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping kdelibs-3.5.0-0.1.fc4 Installing: kdebase [ 5/26]warning: /etc/X11/xdm/kdmrc saved as /etc/X11/xdm/kdmrc.rpmorig Installing: kdebase ####################### [ 5/26] error: unpacking of archive failed on file /etc/X11/xdm/kdmrc: cpio: lsetfilecon Updating : kdenetwork ####################### [ 6/26] error: unpacking of archive failed on file /etc/pam.d/kppp: cpio: lsetfilecon Installing: kdebindings ####################### [ 7/26] error: unpacking of archive failed on file /usr/bin/embedjs: cpio: lsetfilecon Updating : kdemultimedia ####################### [ 8/26] error: unpacking of archive failed on file /etc/xdg/menus/applications-merged/kde-multimedia-music.menu: cpio: lsetfilecon Updating : kdegraphics ####################### [ 9/26] error: unpacking of archive failed on file /usr/bin/kcolorchooser: cpio: lsetfilecon Updating : kdegames ####################### [10/26] error: unpacking of archive failed on file /usr/bin/atlantik: cpio: lsetfilecon Installing: arts-devel ####################### [11/26] error: unpacking of archive failed on file /usr/bin/artsc-config: cpio: lsetfilecon Installing: kdelibs-devel ####################### [12/26] error: unpacking of archive failed on file /usr/bin/dcopidl: cpio: lsetfilecon Updating : kdeartwork ####################### [13/26] error: unpacking of archive failed on file /usr/bin/kbanner.kss: cpio: lsetfilecon Updating : cups ####################### [14/26] error: unpacking of archive failed on file /etc/cron.daily/cups: cpio: lsetfilecon Updating : system-config-nfs ####################### [15/26] error: unpacking of archive failed on file /etc/pam.d/system-config-nfs: cpio: lsetfilecon Updating : kdebindings-devel ####################### [16/26] error: unpacking of archive failed on file /usr/include/kde/kjsembed: cpio: lsetfilecon Updating : dhcp ####################### [17/26] error: unpacking of archive failed on file /etc/dhcpd.conf: cpio: lsetfilecon error: %preun(kdenetwork-3.4.2-0.fc4.2.i386) scriptlet failed, exit status 255 Cleanup : kdeartwork ####################### [18/26] error: %postun(kdeartwork-3.4.2-0.fc4.1.i386) scriptlet failed, exit status 255 error: %trigger(cups-1.1.23-15.1.i386) scriptlet failed, exit status 255 Cleanup : kdemultimedia ####################### [19/26] error: %postun(kdemultimedia-3.4.2-0.fc4.1.i386) scriptlet failed, exit status 255 error: %preun(system-config-nfs-1.3.11-0.fc4.1.noarch) scriptlet failed, exit status 255 Cleanup : kdebindings-devel ####################### [20/26] Cleanup : kdegraphics ####################### [21/26] error: %postun(kdegraphics-3.4.2-0.fc4.2.i386) scriptlet failed, exit status 25 I am at loss as to why I see a general "avc: denied {xxxxxxx}" messages interpersed in the /var/log/message and /var/log/audit/audit.log files such as shown below: /var/log/messages: ==================== === No idea what these are: Dec 12 21:48:06 linux dbus: avc: received policyload notice (seqno=3) Dec 12 21:48:06 linux dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Dec 12 21:48:06 linux dbus: avc: received policyload notice (seqno=3) Dec 12 21:48:06 linux dbus: avc: 0 AV entries and 0/512 buckets used, longest chain length 0 Dec 12 21:48:06 linux dbus: avc: received policyload notice (seqno=3) Dec 12 21:48:06 linux dbus: avc: 7 AV entries and 7/512 buckets used, longest chain length 1 === Relabeling problems shown below... Dec 17 18:35:50 linux kernel: SELinux: initialized (dev sdb1, type ext3), uses xattr Dec 17 18:35:50 linux kernel: audit(1134872391.398:2): avc: granted { setenforce } for pid=379 comm="rc.sysinit" scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Dec 17 18:35:50 linux kernel: audit(1134872392.086:3): avc: denied { relabelfrom } for pid=1236 comm="setfiles" name="__db.001" dev=hda2 ino=904713 scontext=system_u:system_r:kernel_t tcontext=root:object_r:file_t tclass=file Dec 17 18:35:50 linux kernel: audit(1134872412.527:4): avc: denied { relabelto } for pid=1236 comm="setfiles" name="root" dev=hda2 ino=671745 scontext=system_u:system_r:kernel_t tcontext=root:object_r:user_home_dir_t tclass=dir Dec 17 18:35:50 linux kernel: audit(1134872412.547:5): avc: denied { relabelto } for pid=1236 comm="setfiles" name="bin" dev=hda2 ino=671746 scontext=system_u:system_r:kernel_t tcontext=root:object_r:user_home_t tclass=dir Dec 17 18:35:50 linux kernel: audit(1134872412.559:6): avc: denied { relabelto } for pid=1236 comm="setfiles" name="doCerts" dev=hda2 ino=671747 scontext=system_u:system_r:kernel_t tcontext=root:object_r:user_home_t tclass=file Dec 17 18:35:50 linux kernel: audit(1134872412.951:7): avc: denied { relabelfrom } for pid=1236 comm="setfiles" name="khelpcenter" dev=hda2 ino=672118 scontext=system_u:system_r:kernel_t tcontext=root:object_r:file_t tclass=dir Dec 17 18:35:50 linux kernel: audit(1134872412.975:8): avc: denied { relabelto } for pid=1236 comm="setfiles" name="socket-linux.cdkkt.com" dev=hda2 ino=672307 scontext=system_u:system_r:kernel_t tcontext=root:object_r:user_home_t tclass=lnk_file Dec 17 18:35:50 linux kernel: audit(1134872413.031:9): avc: denied { relabelto } for pid=1236 comm="setfiles" name="libflashplayer.so" dev=hda2 ino=672362 scontext=system_u:system_r:kernel_t tcontext=root:object_r:lib_t tclass=file Dec 17 18:35:50 linux kernel: audit(1134873060.784:10): avc: denied { relabelfrom } for pid=1236 comm="setfiles" name="xterm" dev=hda2 ino=1565515 scontext=system_u:system_r:kernel_t tcontext=root:object_r:file_t tclass=lnk_file Dec 17 18:35:50 linux kernel: audit(1134873187.416:11): avc: denied { relabelto } for pid=1236 comm="setfiles" name="dant" dev=hda2 ino=1245501 scontext=system_u:system_r:kernel_t tcontext=user_u:object_r:user_home_dir_t tclass=dir Dec 17 18:35:50 linux kernel: audit(1134873187.416:12): avc: denied { relabelto } for pid=1236 comm="setfiles" name=".kde" dev=hda2 ino=1245502 scontext=system_u:system_r:kernel_t tcontext=user_u:object_r:user_home_t tclass=dir Dec 17 18:35:50 linux kernel: audit(1134873187.420:13): avc: denied { relabelto } for pid=1236 comm="setfiles" name="Autorun.desktop" dev=hda2 ino=1245504 scontext=system_u:system_r:kernel_t tcontext=user_u:object_r:user_home_t tclass=file Dec 17 18:35:50 linux kernel: audit(1134873187.492:14): avc: denied { relabelto } for pid=1236 comm="setfiles" name="socket-linux.cdkkt.com" dev=hda2 ino=1245588 scontext=system_u:system_r:kernel_t tcontext=user_u:object_r:user_home_t tclass=lnk_file Dec 17 18:35:50 linux kernel: audit(1134873191.264:15): avc: denied { relabelfrom } for pid=1236 comm="setfiles" name="verifyFS" dev=hdb1 ino=49063 scontext=system_u:system_r:kernel_t tcontext=root:object_r:samba_share_t tclass=file Dec 17 18:35:50 linux kernel: audit(1134873191.340:16): avc: denied { relabelfrom } for pid=1236 comm="setfiles" name="DenyHosts-1.1.2-python2.4.noarch.rpm" dev=hdb1 ino=1651599 scontext=system_u:system_r:kernel_t tcontext=root:object_r:default_t tclass=file Dec 17 18:35:50 linux kernel: audit(1134873218.749:17): avc: denied { relabelfrom } for pid=1236 comm="setfiles" name="defaults" dev=hdb3 ino=1697393 scontext=system_u:system_r:kernel_t tcontext=root:object_r:default_t tclass=dir Dec 17 18:35:50 linux kernel: audit(1134873319.356:18): avc: granted { setenforce } for pid=379 comm="rc.sysinit" scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Dec 17 18:35:50 linux kernel: Adding 2289252k swap on /dev/hda3. Priority:-1 extents:1 across:2289252k Any help would be appreciated! Kind regards, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 12/16/2005 From gauret at free.fr Mon Dec 19 08:07:17 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 19 Dec 2005 09:07:17 +0100 Subject: SELinux and Cacti (and other webapps) Message-ID: Hi all, We're trying to package cacti for Fedora Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 and we're running into an SELinux problem. Cacti is a web frontend to RRDTool, an improved version of MRTG (which you might know). There is a script, run by cron, which create the statistics databases, and put them in /var/lib/cacti. The log goes into /var/log/cacti. Then, the web interfaces lets the user see theses statistics. The problem is that SELinux won't let httpd access /var/lib/cacti : type=AVC msg=audit(1134978797.695:45154): avc: denied { read } for pid=2605 comm="rrdtool" name="localhost_proc_7.rrd" dev=sda2 ino=981003 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:var_lib_t tclass=file Httpd can't acces /var/log/cacti either. What should we do to make that work with SELinux ? Do we have to run chcon in the %post scriptlet (that sounds like an ugly hack) ? Should we move everything to /var/www ? Thanks for you help Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Programmer: A biological system designed to convert coffee and pizza into code. From ejtr at layer3.co.uk Mon Dec 19 08:56:20 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Mon, 19 Dec 2005 08:56:20 +0000 Subject: logwatch 7 breakage Message-ID: <1134982581.3035.13.camel@topaz.bugfinder.co.uk> Version 7 of logwatch includes a major restructure of its directory layout compared to version 6. For SELinux enforcing machines, there are 2 problems; scripts have moved from /etc/log.d/scripts to /usr/share/logwatch/scripts, and temporary file creation has moved to /var/cache/logwatch. It seems that version 6 worked by dint of Cron already having sufficient SELinux permissions to /etc and /tmp; logwatch has no domain of its own. I've added a couple of tweaks to my local strict policy as shown below, which seem to cover off its requirements for both Cron'ed and Manual invocations. TE .... # Allow Cron and Sudo invocations of logwatch to create temporary files type logwatch_tmp_t, file_type, sysadmfile, tmpfile; allow system_crond_t logwatch_tmp_t:file create_file_perms; allow system_crond_t logwatch_tmp_t:dir create_dir_perms; allow sysadm_t logwatch_tmp_t:file create_file_perms; allow sysadm_t logwatch_tmp_t:dir create_dir_perms; FC .... # Executable scripts belonging to the logwatch package outside of /usr/sbin /usr/share/logwatch/scripts/logwatch.pl -- system_u:object_r:sbin_t # Logwatch version 7 temporary spool area /var/cache/logwatch(/.*)? system_u:object_r:logwatch_tmp_t -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From mailinglists at lonecoder.net Mon Dec 19 09:05:14 2005 From: mailinglists at lonecoder.net (Tarek W.) Date: Mon, 19 Dec 2005 09:05:14 +0000 Subject: SELinux and Cacti (and other webapps) In-Reply-To: References: Message-ID: <1134983114.4409.7.camel@carve.home> A quick hack would be: chcon -R --reference=/var/www/html /var/lib/cacti Happy Hacking On Mon, 2005-12-19 at 09:07 +0100, Aurelien Bompard wrote: > Hi all, > > We're trying to package cacti for Fedora Extras: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175748 > and we're running into an SELinux problem. Cacti is a web frontend to > RRDTool, an improved version of MRTG (which you might know). > There is a script, run by cron, which create the statistics databases, and > put them in /var/lib/cacti. The log goes into /var/log/cacti. Then, the web > interfaces lets the user see theses statistics. > The problem is that SELinux won't let httpd access /var/lib/cacti : > type=AVC msg=audit(1134978797.695:45154): avc: denied { read } for > pid=2605 comm="rrdtool" name="localhost_proc_7.rrd" dev=sda2 ino=981003 > scontext=root:system_r:httpd_sys_script_t > tcontext=system_u:object_r:var_lib_t tclass=file > > Httpd can't acces /var/log/cacti either. > What should we do to make that work with SELinux ? Do we have to run chcon > in the %post scriptlet (that sounds like an ugly hack) ? Should we move > everything to /var/www ? > > Thanks for you help > > Aur?lien From symphony at ig.com.br Mon Dec 19 11:14:25 2005 From: symphony at ig.com.br (symphony) Date: Mon, 19 Dec 2005 09:14:25 -0200 Subject: SELinux in Fedora Message-ID: <20051219_111425_073131.symphony@ig.com.br> I'am a beginning in SELInux. Somebody could indicate an tutorial for installation and a configuration? Why I'm I try difficulties, after qualifying during the installation, in finding, creating and to compile the politics why the folder does not exist. Thanks Pierre From sds at tycho.nsa.gov Mon Dec 19 13:33:25 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 19 Dec 2005 08:33:25 -0500 Subject: Problem with VNC and SELinux: FC4 In-Reply-To: References: Message-ID: <1134999205.25240.32.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-12-16 at 18:11 -0800, Daniel B. Thurman wrote: > With the new SELinux updates, it appears that root, > other than normal users can login to Fedora via VNC > Server? My VNC Server is setup such that I am using > xinitd for VNC Server requests. > > Another problem I noticed is that when I log into my > Fedora system via VNC as root user, and open a xterm > window and run a su - , I get back a > SElinux message: > > ================================================ > # su - dan > Your default context is: user_u:system_r:kernel_t. > > Do you want to want to choose a different one? [n] > ================================================ > > It is *possible* that this problem came up when > I had to make a copy of my filesystem to another > hard-disk for the purpose of creating a /boot > partition (my bad) and copied/restored the filesystem > back over to the main drive. I don't think I made > any copy/restore mistakes as I know the fs permissions > are correct but I cannot speak for filesystem journaling > or whatever that keeps track of the SELinux attributes. > > In any case, what can I do to resolve my VNC and/or su > issue knowing that SElinux has something to do with it? /usr/sbin/sestatus -v | grep -v active shows what? -- Stephen Smalley National Security Agency From dant at cdkkt.com Mon Dec 19 15:44:01 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 19 Dec 2005 07:44:01 -0800 Subject: Problem with VNC and SELinux: FC4 Message-ID: >From: Stephen Smalley [mailto:sds at tycho.nsa.gov] >Sent: Monday, December 19, 2005 5:33 AM >To: Daniel B. Thurman >Cc: For users of Fedora Core releases (E-mail); Fedora SELinux support >list for users & developers. >Subject: Re: Problem with VNC and SELinux: FC4 > > >On Fri, 2005-12-16 at 18:11 -0800, Daniel B. Thurman wrote: >> With the new SELinux updates, it appears that root, >> other than normal users can login to Fedora via VNC >> Server? My VNC Server is setup such that I am using >> xinitd for VNC Server requests. >> >> Another problem I noticed is that when I log into my >> Fedora system via VNC as root user, and open a xterm >> window and run a su - , I get back a >> SElinux message: >> >> ================================================ >> # su - dan >> Your default context is: user_u:system_r:kernel_t. >> >> Do you want to want to choose a different one? [n] >> ================================================ >> >> It is *possible* that this problem came up when >> I had to make a copy of my filesystem to another >> hard-disk for the purpose of creating a /boot >> partition (my bad) and copied/restored the filesystem >> back over to the main drive. I don't think I made >> any copy/restore mistakes as I know the fs permissions >> are correct but I cannot speak for filesystem journaling >> or whatever that keeps track of the SELinux attributes. >> >> In any case, what can I do to resolve my VNC and/or su >> issue knowing that SElinux has something to do with it? > >/usr/sbin/sestatus -v | grep -v active shows what? > [ There are several threads to this issue - so I will be trying to update these threads to let others know of my progress. At this time, my system is running, I am able to login as non-root user into the gnome console, I am able to create and delete new users. It appears that selinux is now working good but I have yet to catch up to manual selinux disables for Kerberos and FrontPage because these were reset to defaults. So far, so good. Everything appears to look good however I am not certain I have solved all the 'yum update' #prelink# issues. Please read on for details if you want. I have provided you with the selinux status request in case there are other possible issues with selinux since I am no expert on this subject :-) ] Please note, that it took me several tries using fixfiles to reset (restore, and relabel) before all of the permissions denied messages stopped being displayed. Previously, I had done the restore command but while in selinix and single user mode (selinux was not disabled), where the restore had permissions denied on perhaps less than 200 files from X11 fonts, and other places throughout. I believe I may have gotten some selinux attribute recovery by doing selinix=0 and single user mode and running fixfiles and using the -F such as: /sbin/fixfiles -F -R -a -F relabel and then reboot. I had thought that running the command would have executed immediately but did not actually take effect until a reboot - which was odd to me - but perhaps this is normal? Manual says nothing about this behavior. The fixfiles with the restore command ran immediately in place - and this was while I was in single user mode with selinux in effect at the time. When I did an yum update but before running the above fixfile relabel command, I noticed that there was a lot of #prelinks# where KDE and GNOME was being updated/installed and it was basically saying something that these prelinks (post-installation?) was failing due to selinux permission denials (logs in audit.log) on the post-installation processes. It also could have been bad timimg on my part for thinking that 'yum update' would somehow restore my problems when I had no idea where to begin. When I tried to log into the gnome console as a non-root user, I did not actually click the checkbox at the time, but in doing so revealed to me that there was a problem executing the file: /usr/lib/libgnomeui-2.so Delving into this further, I saw the "#prelink#" files and noted that the file permission was 0600! So, I changed the permission for this library as: # chmod 755 /usr/lib/libgnomeui-2.so.0.1000.0.#prelink#.Hotj6j I have not yet tried to locate all of the other #prelink# files at this time. But for now, I can now log into gnome as a non-root user! I am providing per your request for the status, in case there may be other issues that I may not be aware of. Thanks for responding to my issue! # /usr/sbin/sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 20 Policy from config file: targeted Policy booleans: NetworkManager_disable_trans inactive allow_execmem active allow_execmod active allow_execstack active allow_ftpd_anon_write inactive allow_gssd_read_tmp active allow_httpd_anon_write inactive allow_httpd_sys_script_anon_write inactive allow_ifconfig_sys_module inactive allow_kerberos active allow_postgresql_use_pam inactive allow_rsync_anon_write inactive allow_saslauthd_read_shadow inactive allow_smbd_anon_write inactive allow_write_xshm inactive allow_ypbind inactive apmd_disable_trans inactive arpwatch_disable_trans inactive auditd_disable_trans inactive bluetooth_disable_trans inactive canna_disable_trans inactive cardmgr_disable_trans inactive comsat_disable_trans inactive cupsd_config_disable_trans inactive cupsd_disable_trans inactive cupsd_lpd_disable_trans inactive cvs_disable_trans inactive cyrus_disable_trans inactive dbskkd_disable_trans inactive dhcpc_disable_trans inactive dhcpd_disable_trans inactive dovecot_disable_trans inactive fingerd_disable_trans inactive ftp_home_dir active ftpd_disable_trans inactive ftpd_is_daemon active getty_disable_trans inactive gssd_disable_trans inactive hald_disable_trans inactive hotplug_disable_trans inactive howl_disable_trans inactive hplip_disable_trans inactive httpd_builtin_scripting active httpd_can_network_connect inactive httpd_disable_trans active httpd_enable_cgi active httpd_enable_ftp_server inactive httpd_enable_homedirs active httpd_ssi_exec active httpd_suexec_disable_trans inactive httpd_tty_comm inactive httpd_unified active inetd_child_disable_trans inactive inetd_disable_trans inactive innd_disable_trans inactive kadmind_disable_trans active klogd_disable_trans inactive krb5kdc_disable_trans active ktalkd_disable_trans inactive lpd_disable_trans inactive mysqld_disable_trans inactive named_disable_trans inactive named_write_master_zones inactive nfs_export_all_ro active nfs_export_all_rw active nfsd_disable_trans inactive nmbd_disable_trans active nscd_disable_trans inactive ntpd_disable_trans inactive pegasus_disable_trans inactive portmap_disable_trans inactive postfix_disable_trans inactive postgresql_disable_trans inactive pppd_can_insmod inactive pppd_disable_trans inactive pppd_for_user inactive pptp_disable_trans inactive privoxy_disable_trans inactive ptal_disable_trans inactive radiusd_disable_trans inactive radvd_disable_trans inactive read_default_t active rlogind_disable_trans inactive rpcd_disable_trans inactive rsync_disable_trans inactive samba_enable_home_dirs inactive saslauthd_disable_trans inactive secure_mode_insmod inactive secure_mode_policyload inactive slapd_disable_trans inactive smbd_disable_trans active snmpd_disable_trans inactive spamd_disable_trans inactive squid_connect_any inactive squid_disable_trans inactive stunnel_disable_trans inactive stunnel_is_daemon inactive syslogd_disable_trans inactive system_dbusd_disable_trans inactive telnetd_disable_trans inactive tftpd_disable_trans inactive udev_disable_trans inactive use_nfs_home_dirs inactive use_samba_home_dirs inactive uucpd_disable_trans inactive winbind_disable_trans active ypbind_disable_trans inactive ypserv_disable_trans inactive zebra_disable_trans inactive Process contexts: Current context: root:system_r:unconfined_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:getty_t /usr/sbin/sshd system_u:system_r:unconfined_t File contexts: Controlling term: root:object_r:devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 12/16/2005 From fedora at derekandkaren.com Tue Dec 20 01:11:25 2005 From: fedora at derekandkaren.com (Derek Poon) Date: Mon, 19 Dec 2005 17:11:25 -0800 Subject: Odd mount behavior mounting hfsplus Message-ID: <1135041085.4521.30.camel@charlie> Hi, I'd like to report an odd behavior that I traced to SELinux. To mount my Mac OS X partition automatically, I have the following line in my /etc/fstab: /dev/hda3 /Macintosh\040HD hfsplus ro 0 0 If I execute mount '/Macintosh HD' as root, this works fine. However, this mount fails during the boot process. If I execute (A) /etc/rc.d/init.d/netfs start as root, I get an error: mount: cannot mount block device /dev/hda3 read-only [FAILED] Running (A) under strace, I see mount("/dev/hda3", "/Macintosh HD", "hfsplus", MS_RDONLY|MS_POSIXACL| MS_ACTIVE|MS_NOUSER|0xec0000, 0x10037f58) = -1 EACCES (Permission denied) However, the following commands both succeed: (B) /bin/bash /etc/rc.d/init.d/netfs start (C) setenforce 0 ; /etc/rc.d/init.d/netfs start Obviously, (C) proves that SELinux is the culprit. The question is, under SELinux, why should (B) work while (A) fails? Since the netfs script has #!/bin/bash as the shebang line, shouldn't (A) and (B) be equivalent? My setup is FC4 on a Mac mini with all updates applied: selinux-policy-targeted-1.27.1-2.16.ppc.rpm libselinux-1.23.10-2.ppc.rpm util-linux-2.12p-9.12.ppc.rpm initscripts-2.6.14-1.1653_FC4.ppc.rpm kernel-2.6.14-1.1653_FC4.ppc.rpm (I realize that /etc/rc.d/init.d/rc.sysinit contains the same mount command as /etc/rc.d/init.d/netfs, but netfs is more convenient to test than rc.sysinit.) Derek From ben.youngdahl at gmail.com Tue Dec 20 05:16:47 2005 From: ben.youngdahl at gmail.com (Benjamin Youngdahl) Date: Mon, 19 Dec 2005 23:16:47 -0600 Subject: constraining an app in targeted policy Message-ID: <291399270512192116y443908b8x439c61f85d30ed50@mail.gmail.com> I have a question on locking down an application under the targeted policy. The policy module I've tried is below. I can see that the process has the appropriate type in "ps -Z".: root:system_r:bentest_t:SystemLow-SystemHigh 13127 pts/1 00:00:00 bentest But it still appears to have all the power of "unconfined_t". I did to a "restorecon -RF", and the files are appropriately labeled. Is it possible for an app to confine "unconfined_t", or should I be switching over to the replacement for the strict policy? (I think it is just called "mls" at this point, which is a confusing name considering that targeted itself is an "mls" it seems.) If I do need to switch to "selinux-policy-mls", is that policy ready for prime time? Apologies in advance if I'm way off base in my understanding. Thanks ! Ben ------------- policy_module(bentest,1.0.4) ######################################## # # Declarations # # Private type declarations type bentest_t; domain_type(bentest_t) domain_auto_trans(unconfined_t,bentest_exec_t,bentest_t) role system_r types bentest_t; type bentest_exec_t; domain_entry_file(bentest_t,bentest_exec_t) -------------- next part -------------- An HTML attachment was scrubbed... URL: From glorg at bk.ru Tue Dec 20 07:29:23 2005 From: glorg at bk.ru (Alexey Tarasov) Date: Tue, 20 Dec 2005 17:29:23 +1000 Subject: sendmail+greylist-milter problem Message-ID: <43A7B2D3.3020302@bk.ru> Greetings, Sorry, if same matters was discussed previously - I've not found any trails. If there is any FAQ with solution of my problem, please give me a link. Thanks for help. best regards, Alexey Tarasov --------------- Problem 1. Installed: sendmail-8.3.14, milter-greylist-2.0.2, selinux-policy-targeted-1.27.2-19 starting sendmail from init results in: maillog --- sendmail[1997]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1674: Xgreylist: local socket name /var/milter-greylist/milter-greylist.sock unsafe: Permission denied --- audit.log: --- type=AVC msg=audit(1135060778.168:5): avc: denied { getattr } for pid=1994 comm="newaliases" name="milter-greylist.sock" dev=dm-0 ino=7831655 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file type=SYSCALL msg=audit(1135060778.168:5): arch=40000003 syscall=196 success=no exit=-13 a0=bfd5995c a1=bfd598ac a2=b7c60ff4 a3=bfd598ac items=1 pid=1994 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 comm="newaliases" exe="/usr/sbin/sendmail.sendmail" type=AVC_PATH msg=audit(1135060778.168:5): path="/var/milter-greylist/milter-greylist.sock" type=PATH msg=audit(1135060778.168:5): item=0 name="/var/milter-greylist/milter-greylist.sock" flags=0 inode=7831655 dev=fd:00 mode=0140755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1135060778.260:6): avc: denied { getattr } for pid=1997 comm="sendmail" name="milter-greylist.sock" dev=dm-0 ino=7831655 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file type=SYSCALL msg=audit(1135060778.260:6): arch=40000003 syscall=196 success=no exit=-13 a0=bf89508c a1=bf894fdc a2=b7c9dff4 a3=bf894fdc items=1 pid=1997 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" type=AVC_PATH msg=audit(1135060778.260:6): path="/var/milter-greylist/milter-greylist.sock" type=PATH msg=audit(1135060778.260:6): item=0 name="/var/milter-greylist/milter-greylist.sock" flags=0 inode=7831655 dev=fd:00 mode=0140755 ouid=0 ogid=0 rdev=00:00 --- And this output is generated on system shutdown: --- type=AVC msg=audit(1135059155.814:79): avc: denied { getattr } for pid=3857 comm="K30sendmail" name="sendmail.pid" dev=dm-0 ino=7602305 scontext=system_u:system_r:sendmail_launch_t:s0 tcontext=root:object_r:var_run_t:s0 tclass=file type=SYSCALL msg=audit(1135059155.814:79): arch=40000003 syscall=195 success=no exit=-13 a0=8113cf8 a1=bfe421c8 a2=aedff4 a3=8113828 items=1 pid=3857 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="K30sendmail" exe="/bin/bash" type=AVC_PATH msg=audit(1135059155.814:79): path="/var/run/sendmail.pid" type=PATH msg=audit(1135059155.814:79): item=0 name="/var/run/sendmail.pid" flags=1 inode=7602305 dev=fd:00 mode=0100600 ouid=0 ogid=51 rdev=00:00 type=AVC msg=audit(1135059155.822:80): avc: denied { unlink } for pid=3864 comm="rm" name="sendmail.pid" dev=dm-0 ino=7602305 scontext=system_u:system_r:sendmail_launch_t:s0 tcontext=root:object_r:var_run_t:s0 tclass=file type=SYSCALL msg=audit(1135059155.822:80): arch=40000003 syscall=10 success=no exit=-13 a0=bfdabf03 a1=1 a2=8050204 a3=bfdab9e0 items=1 pid=3864 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="rm" exe="/bin/rm" type=PATH msg=audit(1135059155.822:80): item=0 name="/var/run/sendmail.pid" flags=10 inode=7602212 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1135059155.826:81): avc: denied { unlink } for pid=3865 comm="rm" name="sendmail" dev=dm-0 ino=7602307 scontext=system_u:system_r:sendmail_launch_t:s0 tcontext=root:object_r:var_lock_t:s0 tclass=file type=SYSCALL msg=audit(1135059155.826:81): arch=40000003 syscall=10 success=no exit=-13 a0=bff31eff a1=1 a2=8050204 a3=bff30f40 items=1 pid=3865 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="rm" exe="/bin/rm" type=PATH msg=audit(1135059155.826:81): item=0 name="/var/lock/subsys/sendmail" flags=10 inode=7602207 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1135059155.826:82): avc: denied { getattr } for pid=3857 comm="K30sendmail" name="sm-client.pid" dev=dm-0 ino=7602308 scontext=system_u:system_r:sendmail_launch_t:s0 tcontext=root:object_r:var_run_t:s0 tclass=file type=SYSCALL msg=audit(1135059155.826:82): arch=40000003 syscall=195 success=no exit=-13 a0=8113cf8 a1=bfe448b8 a2=aedff4 a3=8110710 items=1 pid=3857 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="K30sendmail" exe="/bin/bash" type=AVC_PATH msg=audit(1135059155.826:82): path="/var/run/sm-client.pid" type=PATH msg=audit(1135059155.826:82): item=0 name="/var/run/sm-client.pid" flags=1 inode=7602308 dev=fd:00 mode=0100644 ouid=51 ogid=51 rdev=00:00 --- #ls -lZ -rw------- root smmsp root:object_r:var_run_t sendmail.pid -rw-r--r-- smmsp smmsp root:object_r:var_run_t sm-client.pid -rw-r--r-- root root root:object_r:var_lock_t sendmail Problem 2. ping is called by bash script, executed by cron with root rights (comand line: ping -c 1 -w 5 > /dev/null ) --- type=AVC msg=audit(1133295301.930:2739): avc: denied { write } for pid=30341 comm="ping" name="[56893]" dev=pipefs ino=56893 scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0 tclass=fifo_file type=AVC msg=audit(1133295301.930:2739): avc: denied { read } for pid=30341 comm="ping" name="[56892]" dev=pipefs ino=56892 scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0 tclass=fifo_file --- Is any way to avoid such messages? From gauret at free.fr Tue Dec 20 10:28:24 2005 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 20 Dec 2005 11:28:24 +0100 Subject: SELinux and Cacti (and other webapps) References: <1134983114.4409.7.camel@carve.home> Message-ID: Tarek W. wrote: > A quick hack would be: > chcon -R --reference=/var/www/html /var/lib/cacti But that would be lost on relabel, right ? What is the best way to integrate this into the distro ? Push /var/lib/cacti as http_sys_content_t in the official policy ? Can we add file-context bits into some kind of file-contexts.d directory ? Thanks Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text ? From sds at tycho.nsa.gov Tue Dec 20 13:01:36 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 Dec 2005 08:01:36 -0500 Subject: Odd mount behavior mounting hfsplus In-Reply-To: <1135041085.4521.30.camel@charlie> References: <1135041085.4521.30.camel@charlie> Message-ID: <1135083696.3102.6.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-12-19 at 17:11 -0800, Derek Poon wrote: > Hi, > > I'd like to report an odd behavior that I traced to SELinux. To mount > my Mac OS X partition automatically, I have the following line in > my /etc/fstab: > /dev/hda3 /Macintosh\040HD hfsplus ro 0 0 > > If I execute mount '/Macintosh HD' as root, this works fine. > However, this mount fails during the boot process. > > > If I execute > (A) /etc/rc.d/init.d/netfs start > as root, I get an error: > mount: cannot mount block device /dev/hda3 read-only [FAILED] > > > Running (A) under strace, I see > mount("/dev/hda3", "/Macintosh HD", "hfsplus", MS_RDONLY|MS_POSIXACL| > MS_ACTIVE|MS_NOUSER|0xec0000, 0x10037f58) = -1 EACCES (Permission > denied) > > However, the following commands both succeed: > > (B) /bin/bash /etc/rc.d/init.d/netfs start > > (C) setenforce 0 ; /etc/rc.d/init.d/netfs start > > > Obviously, (C) proves that SELinux is the culprit. The question is, > under SELinux, why should (B) work while (A) fails? Since the netfs > script has #!/bin/bash as the shebang line, shouldn't (A) and (B) be > equivalent? Running the init script causes a domain transition, as you want the init script and any daemons it starts to run with a different set of permissions than the user shell. Running it via bash leaves it in the caller's domain (i.e. the user shell's domain), so it runs with those permissions. Check your /var/log/audit/audit.log for relevant AVC messages (or use /sbin/ausearch to search for and interpret such messages). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Dec 20 13:26:21 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 Dec 2005 08:26:21 -0500 Subject: constraining an app in targeted policy In-Reply-To: <291399270512192116y443908b8x439c61f85d30ed50@mail.gmail.com> References: <291399270512192116y443908b8x439c61f85d30ed50@mail.gmail.com> Message-ID: <1135085181.3102.30.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-12-19 at 23:16 -0600, Benjamin Youngdahl wrote: > I have a question on locking down an application under the targeted > policy. > > The policy module I've tried is below. I can see that the process has > the appropriate type in "ps -Z".: > > root:system_r:bentest_t:SystemLow-SystemHigh 13127 pts/1 00:00:00 > bentest > > But it still appears to have all the power of "unconfined_t". I did > to a "restorecon -RF", and the files are appropriately labeled. What makes you say it has all the power of unconfined_t? > Is it possible for an app to confine "unconfined_t", or should I be > switching over to the replacement for the strict policy? (I think it > is just called "mls" at this point, which is a confusing name > considering that targeted itself is an "mls" it seems.) You should be able to confine a particular application under targeted policy, just by putting it into its own domain, as you seem to be doing. No need to switch to strict policy for that. MLS has a specific meaning, not relevant here. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Dec 20 13:34:19 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 Dec 2005 08:34:19 -0500 Subject: SELinux and Cacti (and other webapps) In-Reply-To: References: <1134983114.4409.7.camel@carve.home> Message-ID: <1135085659.3102.39.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-20 at 11:28 +0100, Aurelien Bompard wrote: > Tarek W. wrote: > > A quick hack would be: > > chcon -R --reference=/var/www/html /var/lib/cacti > > But that would be lost on relabel, right ? > What is the best way to integrate this into the distro ? Push /var/lib/cacti > as http_sys_content_t in the official policy ? Can we add file-context bits > into some kind of file-contexts.d directory ? What is your target here? FC4 or FC5? In FC4, you'd have to push up the change into the policy sources, possibly as a new .fc file (but I'm not clear on whether you want /var/lib/cacti to be completely equivalent to /var/www/html as above or if you want a new type here so that you can still distinguish them for other purposes). In FC5, you will be able create a separate policy module package (via checkmodule and semodule_package) with a pre-compiled policy module and your own file_contexts info and ship it either as part of your package or as a separate xxx-policy package on which your package depends, and have it installed via semodule run from %post. Keeping it as a separate xxx-policy package is nice if you want to be able to update the policy for it later separate from updating the base package itself. -- Stephen Smalley National Security Agency From linux_4ever at yahoo.com Tue Dec 20 14:16:02 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 20 Dec 2005 06:16:02 -0800 (PST) Subject: rawhide policy error messages Message-ID: <20051220141602.28849.qmail@web51505.mail.yahoo.com> Hi, I updated selinux targeted policy in rawhide and got this: Running Transaction Installing: selinux-policy ######################### [1/3] Updating : selinux-policy-targeted ######################### [2/3] security: invalidating context system_u:object_r:hostname_exec_t:s0 security: invalidating context system_u:system_r:hostname_t:s0 libsemanage.parse_module_headers: Data did not represent a module. Failed! /sbin/restorecon reset /bin/hostname context system_u:object_r:unlabeled_t->system_u:object_r:bin_t /sbin/restorecon reset /usr/lib/dri/radeon_dri.so context system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t Cleanup : selinux-policy-targeted ######################### [3/3] Anything to worry about? Does the message from libsemanage actually give enough information to fix the problem? -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From steve at atc-nycorp.com Tue Dec 20 15:22:47 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Tue, 20 Dec 2005 10:22:47 -0500 Subject: constraining an app in targeted policy Message-ID: <60D45469A1AAD311A04C009027B6BF6805914477@server20.inside.oracorp.com> Stephen Smalley wrote: > On Mon, 2005-12-19 at 23:16 -0600, Benjamin Youngdahl wrote: >> I have a question on locking down an application under the targeted >> policy. >> >> The policy module I've tried is below. I can see that the process >> has the appropriate type in "ps -Z".: >> >> root:system_r:bentest_t:SystemLow-SystemHigh 13127 pts/1 00:00:00 >> bentest >> >> But it still appears to have all the power of "unconfined_t". I did >> to a "restorecon -RF", and the files are appropriately labeled. > > What makes you say it has all the power of unconfined_t? > Remove the allows from your .te file and see how much power it has. Or maybe there are some macros in there giving the domain permissions. Also, make sure you're not running in permissive mode. Stephen Brueckner, ATC-NY From ben.youngdahl at gmail.com Tue Dec 20 15:48:06 2005 From: ben.youngdahl at gmail.com (Benjamin Youngdahl) Date: Tue, 20 Dec 2005 09:48:06 -0600 Subject: constraining an app in targeted policy In-Reply-To: <1135085181.3102.30.camel@moss-spartans.epoch.ncsc.mil> References: <291399270512192116y443908b8x439c61f85d30ed50@mail.gmail.com> <1135085181.3102.30.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <291399270512200748l4f3d71cbuf2bb51ee6587ee88@mail.gmail.com> Stephen, thanks for your help. Why I thought the restricted application was running with all the power of an unconfined_t process is that the bentest script was: #!/bin/sh ps -Z touch /usr/bentest/touched touch /usr/touched All the commands in this file succeeded. I expected them all to fail (including the shell invocation itself), as I hadn't explicitly given any "allow"s to bentest_t. The file contexts were: /usr/bentest gen_context(system_u:object_r:bentest_t,s0) /usr/bentest/bentest -- gen_context(system_u:object_r:bentest_exec_t,s0) The system is running in enforcing mode according to "getenforce". The files were correctly labeled. I was running as root, but I expected that wouldn't matter. I must be misunderstanding the fundamentals here. Any help you can give would be greatly appreciated. Ben On 12/20/05, Stephen Smalley wrote: > > On Mon, 2005-12-19 at 23:16 -0600, Benjamin Youngdahl wrote: > > I have a question on locking down an application under the targeted > > policy. > > > > The policy module I've tried is below. I can see that the process has > > the appropriate type in "ps -Z".: > > > > root:system_r:bentest_t:SystemLow-SystemHigh 13127 pts/1 00:00:00 > > bentest > > > > But it still appears to have all the power of "unconfined_t". I did > > to a "restorecon -RF", and the files are appropriately labeled. > > What makes you say it has all the power of unconfined_t? > > > Is it possible for an app to confine "unconfined_t", or should I be > > switching over to the replacement for the strict policy? (I think it > > is just called "mls" at this point, which is a confusing name > > considering that targeted itself is an "mls" it seems.) > > You should be able to confine a particular application under targeted > policy, just by putting it into its own domain, as you seem to be doing. > No need to switch to strict policy for that. MLS has a specific > meaning, not relevant here. > > -- > Stephen Smalley > National Security Agency > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.youngdahl at gmail.com Tue Dec 20 15:56:07 2005 From: ben.youngdahl at gmail.com (Benjamin Youngdahl) Date: Tue, 20 Dec 2005 09:56:07 -0600 Subject: problem solved Message-ID: <291399270512200756m8155e56i751dd037c7a7e1b7@mail.gmail.com> Stephen I tracked the problem down to human error on my part. Thanks for the insights. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Tue Dec 20 19:14:49 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 Dec 2005 14:14:49 -0500 Subject: rawhide policy error messages In-Reply-To: <20051220141602.28849.qmail@web51505.mail.yahoo.com> References: <20051220141602.28849.qmail@web51505.mail.yahoo.com> Message-ID: <43A85829.9070108@redhat.com> Steve G wrote: > Hi, > > I updated selinux targeted policy in rawhide and got this: > > Running Transaction > Installing: selinux-policy ######################### [1/3] > Updating : selinux-policy-targeted ######################### [2/3] > security: invalidating context system_u:object_r:hostname_exec_t:s0 > security: invalidating context system_u:system_r:hostname_t:s0 > libsemanage.parse_module_headers: Data did not represent a module. > Failed! > /sbin/restorecon reset /bin/hostname context > system_u:object_r:unlabeled_t->system_u:object_r:bin_t > /sbin/restorecon reset /usr/lib/dri/radeon_dri.so context > system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t > Cleanup : selinux-policy-targeted ######################### [3/3] > > > Anything to worry about? Does the message from libsemanage actually give enough > information to fix the problem? > > There was really no error here. Basically I pulled hostname policy from targeted. So it reports this as an error. libsemanage then says Failed! Even though it continues and completes the reload. Why does the libary say Failed? What is this error Data did not represent a module? This is actually a very scary looking warning. Dan > -Steve > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From dwalsh at redhat.com Tue Dec 20 19:17:20 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 Dec 2005 14:17:20 -0500 Subject: constraining an app in targeted policy In-Reply-To: <291399270512200748l4f3d71cbuf2bb51ee6587ee88@mail.gmail.com> References: <291399270512192116y443908b8x439c61f85d30ed50@mail.gmail.com> <1135085181.3102.30.camel@moss-spartans.epoch.ncsc.mil> <291399270512200748l4f3d71cbuf2bb51ee6587ee88@mail.gmail.com> Message-ID: <43A858C0.6020608@redhat.com> Benjamin Youngdahl wrote: > Stephen, thanks for your help. > > Why I thought the restricted application was running with all the > power of an unconfined_t process is that the bentest script was: > #!/bin/sh > ps -Z > touch /usr/bentest/touched > touch /usr/touched > > All the commands in this file succeeded. I expected them all to fail > (including the shell invocation itself), as I hadn't explicitly given > any "allow"s to bentest_t. The file contexts were: > /usr/bentest > gen_context(system_u:object_r:bentest_t,s0) > /usr/bentest/bentest -- > gen_context(system_u:object_r:bentest_exec_t,s0) > > The system is running in enforcing mode according to "getenforce". > The files were correctly labeled. I was running as root, but I > expected that wouldn't matter. > > I must be misunderstanding the fundamentals here. Any help you can > give would be greatly appreciated. > Please show us your te file? > Ben > > On 12/20/05, *Stephen Smalley* > wrote: > > On Mon, 2005-12-19 at 23:16 -0600, Benjamin Youngdahl wrote: > > I have a question on locking down an application under the targeted > > policy. > > > > The policy module I've tried is below. I can see that the > process has > > the appropriate type in "ps -Z".: > > > > root:system_r:bentest_t:SystemLow-SystemHigh 13127 pts/1 00:00:00 > > bentest > > > > But it still appears to have all the power of "unconfined_t". I > did > > to a "restorecon -RF", and the files are appropriately labeled. > > What makes you say it has all the power of unconfined_t? > > > Is it possible for an app to confine "unconfined_t", or should I be > > switching over to the replacement for the strict policy? (I > think it > > is just called "mls" at this point, which is a confusing name > > considering that targeted itself is an "mls" it seems.) > > You should be able to confine a particular application under targeted > policy, just by putting it into its own domain, as you seem to be > doing. > No need to switch to strict policy for that. MLS has a specific > meaning, not relevant here. > > -- > Stephen Smalley > National Security Agency > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Tue Dec 20 19:20:25 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 Dec 2005 14:20:25 -0500 Subject: Non-root console login issue! (was: Problem with VNC and SELinux:FC4) In-Reply-To: References: Message-ID: <43A85979.20000@redhat.com> Daniel B. Thurman wrote: >> From: fedora-list-bounces at redhat.com >> [mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel B. Thurman >> Sent: Saturday, December 17, 2005 2:30 PM >> To: For users of Fedora Core releases >> Cc: Fedora SELinux support list for users & developers. >> Subject: Non-root console login issue! (was: Problem with VNC and >> SELinux:FC4) >> >> >> >>> From: fedora-list-bounces at redhat.com >>> [mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel B. Thurman >>> Sent: Friday, December 16, 2005 6:11 PM >>> To: For users of Fedora Core releases (E-mail) >>> Cc: Fedora SELinux support list for users & developers. >>> Subject: Problem with VNC and SELinux: FC4 >>> >>> >>> >>> Folks, >>> >>> With the new SELinux updates, it appears that root, >>> other than normal users can login to Fedora via VNC >>> Server? My VNC Server is setup such that I am using >>> xinitd for VNC Server requests. >>> >>> Another problem I noticed is that when I log into my >>> Fedora system via VNC as root user, and open a xterm >>> window and run a su - , I get back a >>> SElinux message: >>> >>> ================================================ >>> # su - dan >>> Your default context is: user_u:system_r:kernel_t. >>> >>> Do you want to want to choose a different one? [n] >>> ================================================ >>> >>> It is *possible* that this problem came up when >>> I had to make a copy of my filesystem to another >>> hard-disk for the purpose of creating a /boot >>> partition (my bad) and copied/restored the filesystem >>> back over to the main drive. I don't think I made >>> any copy/restore mistakes as I know the fs permissions >>> are correct but I cannot speak for filesystem journaling >>> or whatever that keeps track of the SELinux attributes. >>> >>> In any case, what can I do to resolve my VNC and/or su >>> issue knowing that SElinux has something to do with it? >>> >>> Thanks! >>> Dan Thurman >>> >>> >> Problem is not related to SELinux and not really related >> to VNC. It turns out that I cannot log into the console >> as a non-root user and I get a message saying: >> >> ======================================================= >> Your session lasted less than 10 seconds. If you have not >> logged out yourself, this could mean that there is some >> installation problem or that you may be out of diskspace. >> Try logging in with one of the failsafe sessions to see if >> you can fix this problem. >> >> [] View details (~/.xsession-errors file) >> ======================================================= >> >> The problem here is that the .xsession-errors file does >> not exist. I also note from /var/log/message file: >> >> ======================================================= >> Dec 17 12:45:31 linux gdm(pam_unix)[16480]: session opened for >> user dant by (uid=0) >> Dec 17 12:45:32 linux gdm(pam_unix)[16480]: session closed for >> user dant >> Dec 17 12:45:32 linux dbus: avc: 0 AV entries and 0/512 >> buckets used, longest chain length 0 >> ======================================================= >> >> And from /var/log/audit/audit.log >> ======================================================= >> type=USER_AUTH msg=audit(1134858412.155:3929): user pid=3397 >> uid=0 auid=4294967295 msg='PAM authentication: user=dant >> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >> result=Success)' >> type=USER_ACCT msg=audit(1134858412.159:3930): user pid=3397 >> uid=0 auid=4294967295 msg='PAM accounting: user=dant >> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >> result=Success)' >> type=CRED_ACQ msg=audit(1134858412.247:3931): user pid=3397 >> uid=0 auid=4294967295 msg='PAM setcred: user=dant >> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >> result=Success)' >> type=USER_START msg=audit(1134858412.307:3932): user pid=3397 >> uid=0 auid=4294967295 msg='PAM session open: user=dant >> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >> result=Success)' >> ======================================================= >> >> File: >> # ls -l /usr/bin/gdm-binary >> -rwxr-xr-x 1 root root 251668 May 23 2005 /usr/bin/gdm-binary >> >> HALLLLLP! Please :-) >> >> Dan >> >> > > Sorry - had to add this tidbit.... seems that SElinux may be > involved or maybe my file journaling is messed up after a "restore"? > > I tried to create a new user account to see if by doing this > I would get a correct security context and be able to log > into the console but WHOA!!! What is going on here!?!?!? > > ======================================================= > [root at linux ~]# useradd dant2 > useradd: cannot rewrite password file > [root at linux ~]# > ======================================================= > File: /var/log/audit/audit.log: > > 94967295 msg='useradd: op=adding home directory acct=dant2 res=success' > type=AVC msg=audit(1134859204.879:4004): avc: denied { create } for pid=19177 comm="useradd" name=".kde" scontext=root:system_r:kernel_t tcontext=user_u:object_r:user_home_t tclass=dir > type=SYSCALL msg=audit(1134859204.879:4004): arch=40000003 syscall=39 success=no exit=-13 a0=bfd81470 a1=1ed a2=98fd2ef a3=ffffffff items=1 pid=19177 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" exe="/usr/sbin/useradd" > type=CWD msg=audit(1134859204.879:4004): cwd="/root" > type=PATH msg=audit(1134859204.879:4004): item=0 name="/home/dant2/.kde" flags=10 inode=1245989 dev=03:02 mode=040755 ouid=511 ogid=512 rdev=00:00 > type=AVC msg=audit(1134859204.883:4005): avc: denied { create } for pid=19177 comm="useradd" name="passwd+" scontext=root:system_r:kernel_t tcontext=system_u:object_r:file_t tclass=file > type=SYSCALL msg=audit(1134859204.883:4005): arch=40000003 syscall=5 success=no exit=-13 a0=bfd817e4 a1=8241 a2=1b6 a3=98f6f38 items=1 pid=19177 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" exe="/usr/sbin/useradd" > type=CWD msg=audit(1134859204.883:4005): cwd="/root" > type=PATH msg=audit(1134859204.883:4005): item=0 name="/etc/passwd+" flags=310 inode=1212417 dev=03:02 mode=040755 ouid=0 ogid=0 rdev=00:00 > type=USER_CHAUTHTOK msg=audit(1134859204.883:4006): user pid=19177 uid=0 auid=4294967295 msg='useradd: op=adding user acct=dant2 res=failed' > ======================================================= > > Dan > > Looks like you have a labeling problem. file_t files should not exist if your system is properly labeled. This either indicates you booted with selinux=0 or you added additional disks. You can relabel by executing touch /.autorelabel reboot -- From ben.youngdahl at gmail.com Tue Dec 20 19:24:38 2005 From: ben.youngdahl at gmail.com (Benjamin Youngdahl) Date: Tue, 20 Dec 2005 13:24:38 -0600 Subject: Fwd: constraining an app in targeted policy In-Reply-To: <291399270512201123v3641158cv42723e685cf8958d@mail.gmail.com> References: <291399270512192116y443908b8x439c61f85d30ed50@mail.gmail.com> <1135085181.3102.30.camel@moss-spartans.epoch.ncsc.mil> <291399270512200748l4f3d71cbuf2bb51ee6587ee88@mail.gmail.com> <43A858C0.6020608@redhat.com> <291399270512201123v3641158cv42723e685cf8958d@mail.gmail.com> Message-ID: <291399270512201124j6231baedsc68c47144178d3ec@mail.gmail.com> Oops, forgot to CC the list in case anyone was curious on the specifics of the resolution. ---------- Forwarded message ---------- From: Benjamin Youngdahl Date: Dec 20, 2005 1:23 PM Subject: Re: constraining an app in targeted policy To: Daniel J Walsh Here you go -- was in a previous post but not the follow up that had the ".fc". The problem was solved by a reboot. Stephen has helped me see that it may have been caused by an unload that I did of the module. I thought (and am still pretty sure) that I relabeled the files after the unload/reinstall of the module, because I saw they had their context reset, but I may have botched that step. It's all working now, and I greatly appreciate the assistance of everyone. Have a great Holidays; I know I will, writing policy modules :) Ben ----- policy_module(bentest,1.0.4) ############################## ########## # # Declarations # # Private type declarations type bentest_t; domain_type(bentest_t) domain_auto_trans(unconfined_t,bentest_exec_t,bentest_t) role system_r types bentest_t; type bentest_exec_t; domain_entry_file(bentest_t,bentest_exec_t) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dant at cdkkt.com Tue Dec 20 19:34:23 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 20 Dec 2005 11:34:23 -0800 Subject: Non-root console login issue! (was: Problem with VNC ... SELinux:FC4) Message-ID: >From: fedora-list-bounces at redhat.com >[mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel J Walsh >Sent: Tuesday, December 20, 2005 11:20 AM >To: For users of Fedora Core releases >Cc: Fedora SELinux support list for users & developers. >Subject: Re: Non-root console login issue! (was: Problem with VNCand >SELinux:FC4) > > >Daniel B. Thurman wrote: >>> From: fedora-list-bounces at redhat.com >>> [mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel >B. Thurman >>> Sent: Saturday, December 17, 2005 2:30 PM >>> To: For users of Fedora Core releases >>> Cc: Fedora SELinux support list for users & developers. >>> Subject: Non-root console login issue! (was: Problem with VNC and >>> SELinux:FC4) >>> >>> >>> >>>> From: fedora-list-bounces at redhat.com >>>> [mailto:fedora-list-bounces at redhat.com]On Behalf Of Daniel >B. Thurman >>>> Sent: Friday, December 16, 2005 6:11 PM >>>> To: For users of Fedora Core releases (E-mail) >>>> Cc: Fedora SELinux support list for users & developers. >>>> Subject: Problem with VNC and SELinux: FC4 >>>> >>>> >>>> >>>> Folks, >>>> >>>> With the new SELinux updates, it appears that root, >>>> other than normal users can login to Fedora via VNC >>>> Server? My VNC Server is setup such that I am using >>>> xinitd for VNC Server requests. >>>> >>>> Another problem I noticed is that when I log into my >>>> Fedora system via VNC as root user, and open a xterm >>>> window and run a su - , I get back a >>>> SElinux message: >>>> >>>> ================================================ >>>> # su - dan >>>> Your default context is: user_u:system_r:kernel_t. >>>> >>>> Do you want to want to choose a different one? [n] >>>> ================================================ >>>> >>>> It is *possible* that this problem came up when >>>> I had to make a copy of my filesystem to another >>>> hard-disk for the purpose of creating a /boot >>>> partition (my bad) and copied/restored the filesystem >>>> back over to the main drive. I don't think I made >>>> any copy/restore mistakes as I know the fs permissions >>>> are correct but I cannot speak for filesystem journaling >>>> or whatever that keeps track of the SELinux attributes. >>>> >>>> In any case, what can I do to resolve my VNC and/or su >>>> issue knowing that SElinux has something to do with it? >>>> >>>> Thanks! >>>> Dan Thurman >>>> >>>> >>> Problem is not related to SELinux and not really related >>> to VNC. It turns out that I cannot log into the console >>> as a non-root user and I get a message saying: >>> >>> ======================================================= >>> Your session lasted less than 10 seconds. If you have not >>> logged out yourself, this could mean that there is some >>> installation problem or that you may be out of diskspace. >>> Try logging in with one of the failsafe sessions to see if >>> you can fix this problem. >>> >>> [] View details (~/.xsession-errors file) >>> ======================================================= >>> >>> The problem here is that the .xsession-errors file does >>> not exist. I also note from /var/log/message file: >>> >>> ======================================================= >>> Dec 17 12:45:31 linux gdm(pam_unix)[16480]: session opened for >>> user dant by (uid=0) >>> Dec 17 12:45:32 linux gdm(pam_unix)[16480]: session closed for >>> user dant >>> Dec 17 12:45:32 linux dbus: avc: 0 AV entries and 0/512 >>> buckets used, longest chain length 0 >>> ======================================================= >>> >>> And from /var/log/audit/audit.log >>> ======================================================= >>> type=USER_AUTH msg=audit(1134858412.155:3929): user pid=3397 >>> uid=0 auid=4294967295 msg='PAM authentication: user=dant >>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >>> result=Success)' >>> type=USER_ACCT msg=audit(1134858412.159:3930): user pid=3397 >>> uid=0 auid=4294967295 msg='PAM accounting: user=dant >>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >>> result=Success)' >>> type=CRED_ACQ msg=audit(1134858412.247:3931): user pid=3397 >>> uid=0 auid=4294967295 msg='PAM setcred: user=dant >>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >>> result=Success)' >>> type=USER_START msg=audit(1134858412.307:3932): user pid=3397 >>> uid=0 auid=4294967295 msg='PAM session open: user=dant >>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0 >>> result=Success)' >>> ======================================================= >>> >>> File: >>> # ls -l /usr/bin/gdm-binary >>> -rwxr-xr-x 1 root root 251668 May 23 2005 /usr/bin/gdm-binary >>> >>> HALLLLLP! Please :-) >>> >>> Dan >>> >>> >> >> Sorry - had to add this tidbit.... seems that SElinux may be >> involved or maybe my file journaling is messed up after a "restore"? >> >> I tried to create a new user account to see if by doing this >> I would get a correct security context and be able to log >> into the console but WHOA!!! What is going on here!?!?!? >> >> ======================================================= >> [root at linux ~]# useradd dant2 >> useradd: cannot rewrite password file >> [root at linux ~]# >> ======================================================= >> File: /var/log/audit/audit.log: >> >> 94967295 msg='useradd: op=adding home directory acct=dant2 >res=success' >> type=AVC msg=audit(1134859204.879:4004): avc: denied { >create } for pid=19177 comm="useradd" name=".kde" >scontext=root:system_r:kernel_t >tcontext=user_u:object_r:user_home_t tclass=dir >> type=SYSCALL msg=audit(1134859204.879:4004): arch=40000003 >syscall=39 success=no exit=-13 a0=bfd81470 a1=1ed a2=98fd2ef >a3=ffffffff items=1 pid=19177 auid=4294967295 uid=0 gid=0 >euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" >exe="/usr/sbin/useradd" >> type=CWD msg=audit(1134859204.879:4004): cwd="/root" >> type=PATH msg=audit(1134859204.879:4004): item=0 >name="/home/dant2/.kde" flags=10 inode=1245989 dev=03:02 >mode=040755 ouid=511 ogid=512 rdev=00:00 >> type=AVC msg=audit(1134859204.883:4005): avc: denied { >create } for pid=19177 comm="useradd" name="passwd+" >scontext=root:system_r:kernel_t >tcontext=system_u:object_r:file_t tclass=file >> type=SYSCALL msg=audit(1134859204.883:4005): arch=40000003 >syscall=5 success=no exit=-13 a0=bfd817e4 a1=8241 a2=1b6 >a3=98f6f38 items=1 pid=19177 auid=4294967295 uid=0 gid=0 >euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd" >exe="/usr/sbin/useradd" >> type=CWD msg=audit(1134859204.883:4005): cwd="/root" >> type=PATH msg=audit(1134859204.883:4005): item=0 >name="/etc/passwd+" flags=310 inode=1212417 dev=03:02 >mode=040755 ouid=0 ogid=0 rdev=00:00 >> type=USER_CHAUTHTOK msg=audit(1134859204.883:4006): user >pid=19177 uid=0 auid=4294967295 msg='useradd: op=adding user >acct=dant2 res=failed' >> ======================================================= >> >> Dan >> >> >Looks like you have a labeling problem. file_t files should not exist >if your system is properly labeled. This either indicates you booted >with selinux=0 or you added additional disks. > >You can relabel by executing > >touch /.autorelabel >reboot From: RE: [mostly solved] SELinux is screwing me up!!!! Help! Date: Mon 12/19/2005 8:21AM I did try the autorelabel as it did not work. It wasn't until I tried the following that seemed to steer clear of permissions problems encountered with the autorelabel method. ========================================== I think that I solved this problem by: 1) Booting in selinux=0 single 2) /sbin/fixfiles -F -R -a -F relabel 3) reboot ========================================== Sorry that you did not see this later thread. Dan > > >-- > > >-- >fedora-list mailing list >fedora-list at redhat.com >To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.1.371 / Virus Database: 267.14.1/207 - Release >Date: 12/19/2005 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005 From sds at tycho.nsa.gov Tue Dec 20 20:17:34 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 Dec 2005 15:17:34 -0500 Subject: rawhide policy error messages In-Reply-To: <43A85829.9070108@redhat.com> References: <20051220141602.28849.qmail@web51505.mail.yahoo.com> <43A85829.9070108@redhat.com> Message-ID: <1135109854.3102.134.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-20 at 14:14 -0500, Daniel J Walsh wrote: > There was really no error here. Basically I pulled hostname policy from > targeted. So it reports this as an error. > libsemanage then says Failed! Even though it continues and completes > the reload. Why does the libary say Failed? > What is this error Data did not represent a module? > This is actually a very scary looking warning. Looking at libsemanage, it seems that this error message indicates that the policy module package that you tried to install did not match the requested operation to libsemanage, e.g. you tried to install a base module as a non-base module or vice versa. Example: # /usr/sbin/semodule -i /etc/selinux/targeted/modules/active/base.pp libsemanage.parse_module_headers: Data did not represent a module. Failed! versus: # /usr/sbin/semodule -b /etc/selinux/targeted/modules/active/base.pp Such an error is indeed an error, and prevents installation of the module from proceeding. We should likely adjust the two error messages there to clarify what it means (one should be "did not represent a base module" and the other should be "did not represent a non-base module.") -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Dec 20 20:48:09 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 Dec 2005 15:48:09 -0500 Subject: Problem with VNC and SELinux: FC4 In-Reply-To: <36282A1733C57546BE392885C0618592057341@chaos.tcs.tcs-sec.com> References: <36282A1733C57546BE392885C0618592057341@chaos.tcs.tcs-sec.com> Message-ID: <43A86E09.8060200@redhat.com> Chad Hanson wrote: > > > >> Folks, >> >> With the new SELinux updates, it appears that root, >> other than normal users can login to Fedora via VNC >> Server? My VNC Server is setup such that I am using >> xinitd for VNC Server requests. >> >> > > A problem I noticed on FC4 with updates is that running VNC from initscripts > will cause user sessions to have a system_u:system_r:initrc_t context. If > you start a VNC server as the user from a shell, you get get the expected > behavior of unconfined_t session. > > >> Another problem I noticed is that when I log into my >> Fedora system via VNC as root user, and open a xterm >> window and run a su - , I get back a >> SElinux message: >> >> ================================================ >> # su - dan >> Your default context is: user_u:system_r:kernel_t. >> >> Do you want to want to choose a different one? [n] >> ================================================ >> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > To get vncserver working properly on Rawhide, you can change the context to unconfined_exec_t chcon -t unconfined_exec_t /usr/bin/vncserver -- From selinux at gmail.com Tue Dec 20 22:35:03 2005 From: selinux at gmail.com (Tom London) Date: Tue, 20 Dec 2005 14:35:03 -0800 Subject: java failure Message-ID: <4c4ba1530512201435g2b53b2bcxa981850432c9b5bc@mail.gmail.com> Running targeted/enforcing, latest rawhide(selinux-policy-targeted-2.1.6-11): executing 'java' produces "error spawning gij" audit.log shows: type=SELINUX_ERR msg=audit(1135117790.324:65): security_compute_sid: invalid context user_u:system_r:java_t:s0 for scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:java_exec_t:s0 tclass=process type=SYSCALL msg=audit(1135117790.324:65): arch=40000003 syscall=11 success=no exit=-13 a0=804877a a1=bff00d94 a2=9149040 a3=320cc0 items=1 pid=6726 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="java" exe="/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java" type=CWD msg=audit(1135117790.324:65): cwd="/home/tbl/Downloads/azureus" type=PATH msg=audit(1135117790.324:65): item=0 name="/usr/bin/gij" flags=101 inode=137573 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 This known? tom -- Tom London From dwalsh at redhat.com Tue Dec 20 23:01:09 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 Dec 2005 18:01:09 -0500 Subject: java failure In-Reply-To: <4c4ba1530512201435g2b53b2bcxa981850432c9b5bc@mail.gmail.com> References: <4c4ba1530512201435g2b53b2bcxa981850432c9b5bc@mail.gmail.com> Message-ID: <43A88D35.3070304@redhat.com> Tom London wrote: > Running targeted/enforcing, latest rawhide(selinux-policy-targeted-2.1.6-11): > > executing 'java' produces "error spawning gij" > > audit.log shows: > > type=SELINUX_ERR msg=audit(1135117790.324:65): security_compute_sid: > invalid context user_u:system_r:java_t:s0 for > scontext=user_u:system_r:unconfined_t:s0 > tcontext=system_u:object_r:java_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1135117790.324:65): arch=40000003 syscall=11 > success=no exit=-13 a0=804877a a1=bff00d94 a2=9149040 a3=320cc0 > items=1 pid=6726 auid=4294967295 uid=500 gid=500 euid=500 suid=500 > fsuid=500 egid=500 sgid=500 fsgid=500 comm="java" > exe="/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java" > type=CWD msg=audit(1135117790.324:65): cwd="/home/tbl/Downloads/azureus" > type=PATH msg=audit(1135117790.324:65): item=0 name="/usr/bin/gij" > flags=101 inode=137573 dev=fd:00 mode=0100755 ouid=0 ogid=0 > rdev=00:00 > > This known? > tom > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Try -13 out on ftp://people.redhat.com/dwalsh/SELinux/Fedora -- From selinux at gmail.com Tue Dec 20 23:41:22 2005 From: selinux at gmail.com (Tom London) Date: Tue, 20 Dec 2005 15:41:22 -0800 Subject: java failure In-Reply-To: <43A88D35.3070304@redhat.com> References: <4c4ba1530512201435g2b53b2bcxa981850432c9b5bc@mail.gmail.com> <43A88D35.3070304@redhat.com> Message-ID: <4c4ba1530512201541k33e736b8i67bc67c83d4692fa@mail.gmail.com> On 12/20/05, Daniel J Walsh wrote: > Tom London wrote: > > Running targeted/enforcing, latest rawhide(selinux-policy-targeted-2.1.6-11): > > > > executing 'java' produces "error spawning gij" > > > > audit.log shows: > > > > type=SELINUX_ERR msg=audit(1135117790.324:65): security_compute_sid: > > invalid context user_u:system_r:java_t:s0 for > > scontext=user_u:system_r:unconfined_t:s0 > > tcontext=system_u:object_r:java_exec_t:s0 tclass=process > > type=SYSCALL msg=audit(1135117790.324:65): arch=40000003 syscall=11 > > success=no exit=-13 a0=804877a a1=bff00d94 a2=9149040 a3=320cc0 > > items=1 pid=6726 auid=4294967295 uid=500 gid=500 euid=500 suid=500 > > fsuid=500 egid=500 sgid=500 fsgid=500 comm="java" > > exe="/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java" > > type=CWD msg=audit(1135117790.324:65): cwd="/home/tbl/Downloads/azureus" > > type=PATH msg=audit(1135117790.324:65): item=0 name="/usr/bin/gij" > > flags=101 inode=137573 dev=fd:00 mode=0100755 ouid=0 ogid=0 > > rdev=00:00 > > > > This known? > > tom > > -- > > Tom London > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > Try -13 out on ftp://people.redhat.com/dwalsh/SELinux/Fedora > Yup. Fixes it. tom -- Tom London From selinux.funchords at spameater.org Wed Dec 21 05:18:40 2005 From: selinux.funchords at spameater.org (selinux.funchords at spameater.org) Date: Tue, 20 Dec 2005 21:18:40 -0800 Subject: Curious Behavior doing routine redirection of ping output to file... Message-ID: <43A8E5B0.8040902@funchords.com> I'm not exactly a "newbie," but I'm diving a lot deeper than I ever have. This one has me a little wrapped around the axel, and if someone could help clear the fog, I'd appreciate it. The short version: I'm trying to redirect the output of ping to a file. I get a 0 byte file as a result. Where I am now: When selinux is permissive, it works as I expect it to. When this started, I had no idea that selinux was running or even what it was, exactly (I've been running this system for about two weeks). I've learned a lot since then. But I haven't figured out how to do anything other than flip bits on existing boolean rules and change the sestatus mode. For example, how do I fix the above problem? Current version: 2.6.14-1.1653_FC4 with selinux in targeted/enforced. When this began, I posted a message to www.fedoraforum.org ( http://www.fedoraforum.org/forum/showthread.php?t=88238 ) with the title, "BASH: How to redirect ping output to file?" Later, I found this from from /var/log/audit/audit.log ... type=AVC msg=audit(1134599953.748:32): avc: denied { write } for pid=5503 comm="ping" name="pingoutput2" dev=dm-0 ino=916895 scontext=root:system_r:ping_t tcontext=root:object_r:user_home_t tclass=file type=SYSCALL msg=audit(1134599953.748:32): arch=40000003 syscall=11 success=yes exit=0 a0=8d64360 a1=8d56400 a2=8d51520 a3=1 items=2 pid=5503 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ping" exe="/bin/ping" type=AVC_PATH msg=audit(1134599953.748:32): path="/root/pingoutput2" type=CWD msg=audit(1134599953.748:32): cwd="/root" type=PATH msg=audit(1134599953.748:32): item=0 name="/bin/ping" flags=101 inode=5499653 dev=fd:00 mode=0104755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1134599953.748:32): item=1 flags=101 inode=5892482 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 ... and I discovered the commands audit2why and audit2allow, which has this example in the audit2allow man pages ... $ cd /etc/selinux/$(SELINUXTYPE)/src/policy $ /usr/bin/audit2allow -i < /var/log/audit/audit.log >> domains/misc/local.te $ make load ... and that's where my zero-byte stack blows. I have no src directory under /etc/selinux/targeted, nor do I have anything at all on my system named domains. Still, I tried to follow the advice by mdkir'ing the necessary directories and creating a local.te file with the recommended "allow ping_t user_home_t:file write;" line in it. Then I typed 'make load' and I really think I actually heard something laugh at me. This is the way I learn best, and this isn't anything more than a curiousity to me. But from what I've told you so far, can you point me into the right direction? I did search the archive for this list, as well as the FC3 (which also seemed to point to these directories that I don't have). Thanks! Robb Topolski robb(at)funchords(dot)com http://www.funchords.com From rhally at mindspring.com Wed Dec 21 05:38:17 2005 From: rhally at mindspring.com (Richard Hally) Date: Wed, 21 Dec 2005 00:38:17 -0500 Subject: Curious Behavior doing routine redirection of ping output to file... In-Reply-To: <43A8E5B0.8040902@funchords.com> References: <43A8E5B0.8040902@funchords.com> Message-ID: <43A8EA49.4030504@mindspring.com> selinux.funchords at spameater.org wrote: > I'm not exactly a "newbie," but I'm diving a lot deeper than > I ever have. This one has me a little wrapped around the axel, and > if someone could help clear the fog, I'd appreciate it. > > The short version: > I'm trying to redirect the output of ping to a file. I get a 0 > byte file as a result. > > Where I am now: > When selinux is permissive, it works as I expect it to. > > When this started, I had no idea that selinux was running or even what > it was, exactly (I've been running this system for about two weeks). > I've learned a lot since then. But I haven't figured out how to do > anything other than flip bits on existing boolean rules and change > the sestatus mode. For example, how do I fix the above problem? > > Current version: 2.6.14-1.1653_FC4 with selinux in targeted/enforced. > > When this began, I posted a message to www.fedoraforum.org > ( http://www.fedoraforum.org/forum/showthread.php?t=88238 ) > with the title, "BASH: How to redirect ping output to file?" > > Later, I found this from from /var/log/audit/audit.log ... > type=AVC msg=audit(1134599953.748:32): avc: denied { write } for > pid=5503 comm="ping" name="pingoutput2" dev=dm-0 ino=916895 > scontext=root:system_r:ping_t tcontext=root:object_r:user_home_t > tclass=file > type=SYSCALL msg=audit(1134599953.748:32): arch=40000003 syscall=11 > success=yes exit=0 a0=8d64360 a1=8d56400 a2=8d51520 a3=1 items=2 > pid=5503 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 comm="ping" exe="/bin/ping" > type=AVC_PATH msg=audit(1134599953.748:32): path="/root/pingoutput2" > type=CWD msg=audit(1134599953.748:32): cwd="/root" > type=PATH msg=audit(1134599953.748:32): item=0 name="/bin/ping" > flags=101 inode=5499653 dev=fd:00 mode=0104755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1134599953.748:32): item=1 flags=101 inode=5892482 > dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > > ... and I discovered the commands audit2why and audit2allow, which has > this example in the audit2allow man pages ... > > $ cd /etc/selinux/$(SELINUXTYPE)/src/policy > $ /usr/bin/audit2allow -i < /var/log/audit/audit.log >> > domains/misc/local.te desired> > $ make load > > ... and that's where my zero-byte stack blows. > > I have no src directory under /etc/selinux/targeted, nor do I have > anything at all on my system named domains. Still, I tried to follow > the advice by mdkir'ing the necessary directories and creating a > local.te file with the recommended "allow ping_t user_home_t:file write;" > line in it. > Then I typed 'make load' and I really think I actually heard something > laugh at me. > This is the way I learn best, and this isn't anything more than a > curiousity to me. But from what I've told you so far, can you point > me into the right direction? > > I did search the archive for this list, as well as the FC3 (which > also seemed to point to these directories that I don't have). > > Thanks! > > Robb Topolski > robb(at)funchords(dot)com > http://www.funchords.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Looks like you need to download the corresponding source for the policy you are running e.g. selinux-policy-targeted-source for that audit2allow and make load to work. From selinux.funchords at spameater.org Wed Dec 21 06:18:04 2005 From: selinux.funchords at spameater.org (selinux.funchords at spameater.org) Date: Tue, 20 Dec 2005 22:18:04 -0800 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: <43A8EA49.4030504@mindspring.com> References: <43A8E5B0.8040902@funchords.com> <43A8EA49.4030504@mindspring.com> Message-ID: <43A8F39C.1060306@funchords.com> Richard Hally - rhally at mindspring.com wrote: > Looks like you need to download the corresponding source for the > policy you are running e.g. selinux-policy-targeted-source for that > audit2allow and make load to work. ... and that works! Thanks! Any idea why the rule is needed for a redirection by a ping command run by the root account? And if this is a FAQ, where is the best place to cut my teeth on this? -- Robb Topolski (selinux.funchords at spameater.org) http://www.funchords.com From pacifico at drizzle.com Wed Dec 21 06:26:45 2005 From: pacifico at drizzle.com (Al Pacifico) Date: Tue, 20 Dec 2005 22:26:45 -0800 Subject: Neophyte question re: httpd under SELinux Message-ID: <007001c605f7$846e4d00$6401a8c0@Laptop8100> I'm working on a CGI program in C, but recently SELinux seems to have tripped me up. I started with Tom Boutell's cgic and an example CGI program (provided in his source tree) that generates a JPEG on the fly. It ran fine months back with the following script: dir=$(dirname $0) /usr/sbin/httpd -X -k start -d $dir -e debug on my FC4 machine. Now, it's time to start testing the program I wrote, but my Apache (version 2.0.54, installed from Fedora RPM, if it matters) won't start unless I execute /usr/sbin/setenforce 0 before executing my script. (it took me a while to figure that one out!). In fact, /usr/sbin/httpd -v won't even work. I'm sure the SELinux policy has updated via yum since times when it worked, and that explains the change. I tried checking "Disable SELinux protection for httpd daemon" in the system-config-securitylevel dialog and relabelling my filesystems, but I still need to execute /usr/sbin/setenforce 0 beforehand to run my script that starts httpd with my CGI program. If it helps, the example CGI program (not the one I've written, but Tom Boutell's that formerly ran) is in the directory /home/myuser/Development/myproject/imageFromCGI_test/test and ls -l /home/myuser/Development/myproject/imageFromCGI_test/test outputs total 52 drwxrwxr-x 2 myuser apache 4096 Sep 9 10:03 cgi-bin drwxrwxr-x 2 myuser apache 4096 Sep 9 13:07 conf -rwxr-xr-x 1 root root 63 Dec 20 14:38 debug_CGI drwxrwxr-x 2 myuser apache 4096 Sep 9 12:08 htdocs drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 logs lrwxrwxrwx 1 root root 18 Sep 9 09:52 modules -> /etc/httpd/modules drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 run (probably only makes sense if you're accustomed to configuring apache; this directory is essentially the argument to the Apache ServerRoot directive). I inferred that the directory might be important since /sbin/service httpd start works fine, regardless of state of aforementioned checkbox. What bugs me is that I don't get any kind of warning... apache just never starts. Q: How do I get warnings? (grep avc /var/log/messages was of no help to my pea-brain) Q: What else do I need to change to alter this behavior? I understand that for a production machine, SELinux is a good thing. I hadn't installed it when I used FC2 and hadn't had much problem with FC3 or with FC4 until yesterday. I have to believe there is a better way than just turning it off. Thanks. -al Al Pacifico Seattle, WA From 1lnxraider at comcast.net Wed Dec 21 10:19:47 2005 From: 1lnxraider at comcast.net (Marcus O. White) Date: Wed, 21 Dec 2005 05:19:47 -0500 Subject: Neophyte question re: httpd under SELinux In-Reply-To: <007001c605f7$846e4d00$6401a8c0@Laptop8100> References: <007001c605f7$846e4d00$6401a8c0@Laptop8100> Message-ID: <1135160387.3368.47.camel@tbird> On Tue, 2005-12-20 at 22:26 -0800, Al Pacifico wrote: > I'm working on a CGI program in C, but recently SELinux seems to have > tripped me up. > > I started with Tom Boutell's cgic and an example CGI program (provided in > his source tree) that generates a JPEG on the fly. It ran fine months back > with the following script: > > dir=$(dirname $0) > /usr/sbin/httpd -X -k start -d $dir -e debug > > on my FC4 machine. > > Now, it's time to start testing the program I wrote, but my Apache (version > 2.0.54, installed from Fedora RPM, if it matters) won't start unless I > execute /usr/sbin/setenforce 0 before executing my script. (it took me a > while to figure that one out!). In fact, /usr/sbin/httpd -v won't even work. > I'm sure the SELinux policy has updated via yum since times when it worked, > and that explains the change. I tried checking "Disable SELinux protection > for httpd daemon" in the system-config-securitylevel dialog and relabelling > my filesystems, but I still need to execute /usr/sbin/setenforce 0 > beforehand to run my script that starts httpd with my CGI program. > > If it helps, the example CGI program (not the one I've written, but Tom > Boutell's that formerly ran) is in the directory > > /home/myuser/Development/myproject/imageFromCGI_test/test > > and > > ls -l /home/myuser/Development/myproject/imageFromCGI_test/test outputs > > total 52 > drwxrwxr-x 2 myuser apache 4096 Sep 9 10:03 cgi-bin > drwxrwxr-x 2 myuser apache 4096 Sep 9 13:07 conf > -rwxr-xr-x 1 root root 63 Dec 20 14:38 debug_CGI > drwxrwxr-x 2 myuser apache 4096 Sep 9 12:08 htdocs > drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 logs > lrwxrwxrwx 1 root root 18 Sep 9 09:52 modules -> /etc/httpd/modules > drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 run > > (probably only makes sense if you're accustomed to configuring apache; this > directory is essentially the argument to the Apache ServerRoot directive). > > I inferred that the directory might be important since /sbin/service httpd > start works fine, regardless of state of aforementioned checkbox. > > What bugs me is that I don't get any kind of warning... apache just never > starts. > Q: How do I get warnings? (grep avc /var/log/messages was of no help to my > pea-brain) > Q: What else do I need to change to alter this behavior? > > I understand that for a production machine, SELinux is a good thing. I > hadn't installed it when I used FC2 and hadn't had much problem with FC3 or > with FC4 until yesterday. I have to believe there is a better way than just > turning it off. > > Thanks. > -al > > Al Pacifico > Seattle, WA > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >From RHEL list: Gavin Young wrote: > Hey guys, hopefully someone out there can help me with this because I'm > an SELinux virgin so to speak. > > We have a RHEL v4 box running apache amongst other things. No changes > have been made to the standard Redhat policies. I'm no expert but I am trying to wade through Apache/selinux issues as well. You might find the following "beta" document helpful: ------------------- On Fri, 4 Mar 2005, Gavin Young wrote: > Hey guys, hopefully someone out there can help me with this because I'm > an SELinux virgin so to speak. > > We have a RHEL v4 box running apache amongst other things. No changes > have been made to the standard Redhat policies. > > We are wanting to run a perl based web app (Sql-Ledger) > from /usr/local/sql-ledger but SELinux is stopping us. > > With SELinux disabled it works correctly. When SELinux protection of the > HTTPD daemon is switched on the browser displays: Internal Server Error > and /var/log/messages reports > > Mar 3 15:13:23 zorb1 kernel: audit(1109816003.103:0): avc: denied > { execute } for pid=24711 exe=/usr/sbin/httpd name=login.pl dev=dm-0 > ino=9228595 scontext=root:system_r:httpd_t tcontext=root:object_r:usr_t > tclass=file > >> From what I can tell SELinux is stopping scripts being run from any > other directory apart from /var/www/cgi-bin. I have tried moving the > sql-ledger directory into cgi-bin but that doesn't appear to help > because it is still a sub-directory of cgi-bin. The release notes give a hint to the right direction but doesn't directly talk about cgi - you need to set the file contexts of the sql-ledger stuff as cgi-content, something like this: "chcon -R -h -t httpd_sys_script_exec_t " - Panu - ---------------------- What are the HTTPD Booleans set to? getsebool -a | grep httpd httpd_enable_cgi needs to be active, if it is not. That wouldn't generate the denial you have, so think of this as a "is it plugged in?" type of question. > We are wanting to run a perl based web app (Sql-Ledger) > from /usr/local/sql-ledger but SELinux is stopping us. This is where someone could correct me for best practices advise. You want to seriously consider moving the CGI program to the appropriate directory. Otherwise, you are trying to give Apache execute access to something inside of /usr/local/ ... To do this in /usr/local/, you will need to change policy or relabel /usr/local/ to make this happen, which will serve to reduce security on the system. > With SELinux disabled it works correctly. When SELinux protection of the > HTTPD daemon is switched on the browser displays: Internal Server Error > and /var/log/messages reports > > Mar 3 15:13:23 zorb1 kernel: audit(1109816003.103:0): avc: denied > { execute } for pid=24711 exe=/usr/sbin/httpd name=login.pl dev=dm-0 > ino=9228595 scontext=root:system_r:httpd_t tcontext=root:object_r:usr_t > tclass=file > > >From what I can tell SELinux is stopping scripts being run from any > other directory apart from /var/www/cgi-bin. I have tried moving the > sql-ledger directory into cgi-bin but that doesn't appear to help > because it is still a sub-directory of cgi-bin. That shouldn't be a problem. You just need to relabel the directory recursively. This should work, and is a good practice since it refers to the mapping of labels to directories/files as defined by the policy: restorecon -Rv /var/www/cgi-bin/sql-ledger/ If ls -Z doesn't show that the type is httpd_sys_script_t, do this: chcon -Rv -t httpd_sys_script_t /var/www/cgi-bin/sql-ledger/ > This problem must have come up before... Any help would be much > appreciated. Yeah, almost qualifies for a FAQ. Future updates to the Red Hat SELinux Guide[1] will likely address Apache more thoroughly. - Karsten [1] http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/index.html HTH Marcus O. From pacifico at drizzle.com Wed Dec 21 15:44:37 2005 From: pacifico at drizzle.com (Al Pacifico) Date: Wed, 21 Dec 2005 07:44:37 -0800 Subject: Neophyte question re: httpd under SELinux In-Reply-To: <1135160387.3368.47.camel@tbird> Message-ID: <008701c60645$733e7160$6401a8c0@Laptop8100> Marcus- Thanks for your response. This helped some, I think, but I still have my issues. The URL http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizin g.html#sn-httpd-booleans didn't contribute much. Output of ls -Z showed directories of my .../test directory as user_u:object_r:user_home_t. Changing context with chcon -Rv -t httpd_sys_script_t ./test (as root) did not work... lot of permission denied messages. My machine has a multidisk setup and /home is its own partition or disk; not sure if that matters. Output of getsebool -a | grep httpd is: allow_httpd_anon_write --> inactive allow_httpd_sys_script_anon_write --> inactive httpd_builtin_scripting --> active httpd_can_network_connect --> inactive httpd_disable_trans --> active httpd_enable_cgi --> active httpd_enable_ftp_server --> inactive httpd_enable_homedirs --> active httpd_ssi_exec --> active httpd_suexec_disable_trans --> inactive httpd_tty_comm --> inactive httpd_unified --> active I totally agree with the comment about placing files in the correct places, on a production machine. However, numerous apache modules come with testing suites that use the system httpd executable (appropriately) in other locations. I'm starting to believe that I should either use setenforce 0 when developing. If I do that, and forget to turn it back on, will there be some ugly ramifications later? I have to halt httpd from the console using ctrl-C because of the -X option, so I can't just stick setenforce 1 in my script. (Hmm.... how do I trap ctrl-C in a bash script?) I could switch to testing with lighttpd for CGI and SCGI, but I do need to test some apache modules for which that is not an option. Two things I still don't unmderstand: Why doesn't the "Disable SELinux protection for httpd daemon" checkbox just take care of the problem? My /var/log/messages didn't help me... doesn't show all those permission denied messages when I tried to recusively change the context in my .../test directory. Should I be looking elsewhere? Do I need to tell SELinux something? I'm sorry if my questions are pretty basic; I definitely fall in the category of 80% just want to get the job done and 20% want to know more. Thanks. -al -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Marcus O. White Sent: Wednesday, December 21, 2005 2:20 AM To: fedora-selinux-list at redhat.com Subject: Re: Neophyte question re: httpd under SELinux On Tue, 2005-12-20 at 22:26 -0800, Al Pacifico wrote: > I'm working on a CGI program in C, but recently SELinux seems to have > tripped me up. > > I started with Tom Boutell's cgic and an example CGI program (provided in > his source tree) that generates a JPEG on the fly. It ran fine months back > with the following script: > > dir=$(dirname $0) > /usr/sbin/httpd -X -k start -d $dir -e debug > > on my FC4 machine. > > Now, it's time to start testing the program I wrote, but my Apache (version > 2.0.54, installed from Fedora RPM, if it matters) won't start unless I > execute /usr/sbin/setenforce 0 before executing my script. (it took me a > while to figure that one out!). In fact, /usr/sbin/httpd -v won't even work. > I'm sure the SELinux policy has updated via yum since times when it worked, > and that explains the change. I tried checking "Disable SELinux protection > for httpd daemon" in the system-config-securitylevel dialog and relabelling > my filesystems, but I still need to execute /usr/sbin/setenforce 0 > beforehand to run my script that starts httpd with my CGI program. > > If it helps, the example CGI program (not the one I've written, but Tom > Boutell's that formerly ran) is in the directory > > /home/myuser/Development/myproject/imageFromCGI_test/test > > and > > ls -l /home/myuser/Development/myproject/imageFromCGI_test/test outputs > > total 52 > drwxrwxr-x 2 myuser apache 4096 Sep 9 10:03 cgi-bin > drwxrwxr-x 2 myuser apache 4096 Sep 9 13:07 conf > -rwxr-xr-x 1 root root 63 Dec 20 14:38 debug_CGI > drwxrwxr-x 2 myuser apache 4096 Sep 9 12:08 htdocs > drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 logs > lrwxrwxrwx 1 root root 18 Sep 9 09:52 modules -> /etc/httpd/modules > drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 run > > (probably only makes sense if you're accustomed to configuring apache; this > directory is essentially the argument to the Apache ServerRoot directive). > > I inferred that the directory might be important since /sbin/service httpd > start works fine, regardless of state of aforementioned checkbox. > > What bugs me is that I don't get any kind of warning... apache just never > starts. > Q: How do I get warnings? (grep avc /var/log/messages was of no help to my > pea-brain) > Q: What else do I need to change to alter this behavior? > > I understand that for a production machine, SELinux is a good thing. I > hadn't installed it when I used FC2 and hadn't had much problem with FC3 or > with FC4 until yesterday. I have to believe there is a better way than just > turning it off. > > Thanks. > -al > > Al Pacifico > Seattle, WA > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >From RHEL list: Gavin Young wrote: > Hey guys, hopefully someone out there can help me with this because I'm > an SELinux virgin so to speak. > > We have a RHEL v4 box running apache amongst other things. No changes > have been made to the standard Redhat policies. I'm no expert but I am trying to wade through Apache/selinux issues as well. You might find the following "beta" document helpful: ------------------- On Fri, 4 Mar 2005, Gavin Young wrote: > Hey guys, hopefully someone out there can help me with this because I'm > an SELinux virgin so to speak. > > We have a RHEL v4 box running apache amongst other things. No changes > have been made to the standard Redhat policies. > > We are wanting to run a perl based web app (Sql-Ledger) > from /usr/local/sql-ledger but SELinux is stopping us. > > With SELinux disabled it works correctly. When SELinux protection of the > HTTPD daemon is switched on the browser displays: Internal Server Error > and /var/log/messages reports > > Mar 3 15:13:23 zorb1 kernel: audit(1109816003.103:0): avc: denied > { execute } for pid=24711 exe=/usr/sbin/httpd name=login.pl dev=dm-0 > ino=9228595 scontext=root:system_r:httpd_t tcontext=root:object_r:usr_t > tclass=file > >> From what I can tell SELinux is stopping scripts being run from any > other directory apart from /var/www/cgi-bin. I have tried moving the > sql-ledger directory into cgi-bin but that doesn't appear to help > because it is still a sub-directory of cgi-bin. The release notes give a hint to the right direction but doesn't directly talk about cgi - you need to set the file contexts of the sql-ledger stuff as cgi-content, something like this: "chcon -R -h -t httpd_sys_script_exec_t " - Panu - ---------------------- What are the HTTPD Booleans set to? getsebool -a | grep httpd httpd_enable_cgi needs to be active, if it is not. That wouldn't generate the denial you have, so think of this as a "is it plugged in?" type of question. > We are wanting to run a perl based web app (Sql-Ledger) > from /usr/local/sql-ledger but SELinux is stopping us. This is where someone could correct me for best practices advise. You want to seriously consider moving the CGI program to the appropriate directory. Otherwise, you are trying to give Apache execute access to something inside of /usr/local/ ... To do this in /usr/local/, you will need to change policy or relabel /usr/local/ to make this happen, which will serve to reduce security on the system. > With SELinux disabled it works correctly. When SELinux protection of the > HTTPD daemon is switched on the browser displays: Internal Server Error > and /var/log/messages reports > > Mar 3 15:13:23 zorb1 kernel: audit(1109816003.103:0): avc: denied > { execute } for pid=24711 exe=/usr/sbin/httpd name=login.pl dev=dm-0 > ino=9228595 scontext=root:system_r:httpd_t tcontext=root:object_r:usr_t > tclass=file > > >From what I can tell SELinux is stopping scripts being run from any > other directory apart from /var/www/cgi-bin. I have tried moving the > sql-ledger directory into cgi-bin but that doesn't appear to help > because it is still a sub-directory of cgi-bin. That shouldn't be a problem. You just need to relabel the directory recursively. This should work, and is a good practice since it refers to the mapping of labels to directories/files as defined by the policy: restorecon -Rv /var/www/cgi-bin/sql-ledger/ If ls -Z doesn't show that the type is httpd_sys_script_t, do this: chcon -Rv -t httpd_sys_script_t /var/www/cgi-bin/sql-ledger/ > This problem must have come up before... Any help would be much > appreciated. Yeah, almost qualifies for a FAQ. Future updates to the Red Hat SELinux Guide[1] will likely address Apache more thoroughly. - Karsten [1] http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/in dex.html HTH Marcus O. -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list From russell at coker.com.au Wed Dec 21 15:59:13 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 22 Dec 2005 02:59:13 +1100 Subject: ping - was sendmail+greylist-milter problem In-Reply-To: <43A7B2D3.3020302@bk.ru> References: <43A7B2D3.3020302@bk.ru> Message-ID: <200512220259.23013.russell@coker.com.au> On Tuesday 20 December 2005 18:29, Alexey Tarasov wrote: > Problem 2. > ping is called by bash script, executed by cron with root rights (comand > line: ping -c 1 -w 5 > /dev/null ) > > --- > type=AVC msg=audit(1133295301.930:2739): avc: denied { write } for > pid=30341 comm="ping" name="[56893]" dev=pipefs ino=56893 > scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0 > tclass=fifo_file > type=AVC msg=audit(1133295301.930:2739): avc: denied { read } for > pid=30341 comm="ping" name="[56892]" dev=pipefs ino=56892 > scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0 > tclass=fifo_file allow domain crond_t:fifo_file rw_file_perms; An obvious solution to this would be to grant permissions somewhat equivalent to the above (actually we would not grant that, but it would creep towards it over time). But that sort of thing isn't what we really desire. I'm wondering whether the design of cron is ideal in this regard. Maybe it would be better if the functionality of collecting output and sending the email would be better performed after dropping privs. It would be easy enough to write a little program that spawns a program, collects it's output, and then email's such output (if any) to a specified address and then have cron call such a program. This would result in reducing the amount of code in the cron daemon (IE reducing the amount of code running with significant privs that can break the entire system if it is compromised), providing a neat email utility that can be used for other purposes, and making the SE Linux policy cleaner at the same time. What do you think of this idea? PS Please write two emails about two problems with two different subjects in future. -- 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 Dec 21 16:18:39 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 22 Dec 2005 03:18:39 +1100 Subject: sendmail+greylist-milter problem In-Reply-To: <43A7B2D3.3020302@bk.ru> References: <43A7B2D3.3020302@bk.ru> Message-ID: <200512220318.46283.russell@coker.com.au> On Tuesday 20 December 2005 18:29, Alexey Tarasov wrote: > Problem 1. > Installed: sendmail-8.3.14, milter-greylist-2.0.2, > selinux-policy-targeted-1.27.2-19 > > starting sendmail from init results in: > maillog > --- > sendmail[1997]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1674: > Xgreylist: local socket name /var/milter-greylist/milter-greylist.sock > unsafe: Permission denied The problem here is that there is no policy for greylist-milter (or any other milter for that matter). Currently there is policy for postgrey (the Postfix greylisting daemon which uses an interface that's conceptually identical to milter). I considered changing that to a greylisting policy, but that doesn't seem to be the correct solution. I am thinking of now writing a milter policy that is not specific to mail servers (which means I can't call it a "milter" policy as the term "milter" is specific to Sendmail - I need to find a suitable generic term for a MTA helper program). The idea is that the generic mta-helper policy will initially support postgrey and greylist-milter (the two I'm most aware of) and with small modifications to the fc file most milter-type programs. I'm sure that some milters will have different requirements, but a policy for generic milters won't preclude having specific policies for milters that need it. Of course this would mean that you can have a set of milters that all have access to interfere with each other, is it common to have multiple milters running in a situation where there is a great need to isolate them from each other? With the Postfix policy I used many domains, but I don't want to always be so free with creating new domains. With Postfix there is a limit to how many domains will be needed. But the number of milter programs can grow without limit (there's even a blog at http://www.milter.org/ to inform us about all the new milters that are being written). So we want to restrict the number of milters that get specific policy both to limit the size of the policy and the difficulty of users getting working systems. Comments? -- 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 tycho.nsa.gov Wed Dec 21 14:46:29 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 21 Dec 2005 09:46:29 -0500 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: <43A8F39C.1060306@funchords.com> References: <43A8E5B0.8040902@funchords.com> <43A8EA49.4030504@mindspring.com> <43A8F39C.1060306@funchords.com> Message-ID: <1135176389.18223.43.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-12-20 at 22:18 -0800, selinux.funchords at spameater.org wrote: > Richard Hally - rhally at mindspring.com wrote: > > > Looks like you need to download the corresponding source for the > > policy you are running e.g. selinux-policy-targeted-source for that > > audit2allow and make load to work. > > ... and that works! Thanks! > > Any idea why the rule is needed for a redirection by a ping command run > by the root account? And if this is a FAQ, where is the best place to > cut my teeth on this? http://selinux.sourceforge.net/resources.php3 -- Stephen Smalley National Security Agency From nicolas.mailhot at laposte.net Wed Dec 21 16:53:57 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 Dec 2005 17:53:57 +0100 (CET) Subject: sendmail+greylist-milter problem In-Reply-To: <200512220318.46283.russell@coker.com.au> References: <43A7B2D3.3020302@bk.ru> <200512220318.46283.russell@coker.com.au> Message-ID: <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> On Mer 21 d?cembre 2005 17:18, Russell Coker wrote: > The problem here is that there is no policy for greylist-milter (or any > other > milter for that matter). amavis+postfix has been included in default selinux policy for quite a long time. I'm pretty sure the policy applies to postfix+amavis too. (btw if someone could approve the amavisd-new FE package that would be great) Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Dec 21 19:31:56 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 Dec 2005 20:31:56 +0100 Subject: sendmail+greylist-milter problem In-Reply-To: <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> References: <43A7B2D3.3020302@bk.ru> <200512220318.46283.russell@coker.com.au> <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> Message-ID: <43A9ADAC.2000809@laposte.net> Nicolas Mailhot wrote: > On Mer 21 d?cembre 2005 17:18, Russell Coker wrote: > >> The problem here is that there is no policy for greylist-milter (or any >> other >> milter for that matter). > > amavis+postfix has been included in default selinux policy for quite a > long time. I'm pretty sure the policy applies to sendmail+amavisd > too. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Dec 21 21:49:04 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 Dec 2005 22:49:04 +0100 Subject: selinux kills SM Message-ID: <43A9CDD0.5040807@laposte.net> Hi, I don't really have the time to do a proper bug report, but today's selinux update in rawhide killed squirelmail+dovecot. Regards, -- Nicolas Mailhot From glorg at bk.ru Thu Dec 22 07:08:35 2005 From: glorg at bk.ru (Alexey Tarasov) Date: Thu, 22 Dec 2005 17:08:35 +1000 Subject: ping In-Reply-To: <200512220259.23013.russell@coker.com.au> References: <43A7B2D3.3020302@bk.ru> <200512220259.23013.russell@coker.com.au> Message-ID: <43AA50F3.5090305@bk.ru> Russell Coker wrote: >On Tuesday 20 December 2005 18:29, Alexey Tarasov wrote: > > >>Problem 2. >>ping is called by bash script, executed by cron with root rights (comand >>line: ping -c 1 -w 5 > /dev/null ) >> >>--- >>type=AVC msg=audit(1133295301.930:2739): avc: denied { write } for >>pid=30341 comm="ping" name="[56893]" dev=pipefs ino=56893 >>scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0 >>tclass=fifo_file >>type=AVC msg=audit(1133295301.930:2739): avc: denied { read } for >>pid=30341 comm="ping" name="[56892]" dev=pipefs ino=56892 >>scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0 >>tclass=fifo_file >> >> > >allow domain crond_t:fifo_file rw_file_perms; > >An obvious solution to this would be to grant permissions somewhat equivalent >to the above (actually we would not grant that, but it would creep towards it >over time). But that sort of thing isn't what we really desire. > >I'm wondering whether the design of cron is ideal in this regard. Maybe it >would be better if the functionality of collecting output and sending the >email would be better performed after dropping privs. It would be easy >enough to write a little program that spawns a program, collects it's output, >and then email's such output (if any) to a specified address and then have >cron call such a program. This would result in reducing the amount of code >in the cron daemon (IE reducing the amount of code running with significant >privs that can break the entire system if it is compromised), providing a >neat email utility that can be used for other purposes, and making the SE >Linux policy cleaner at the same time. > >What do you think of this idea? > > I'm really don't care who will collect output of executed program. Anyway, I may run own mail-agent to send this data. IMHO, collecting output data by crond is feature, that may be implemented in other way. This task is not really task of crond, which must only run progams at choosen time. As for me, I prefer set of programs with small functionality, flexible to configure, than big universal programs. >PS Please write two emails about two problems with two different subjects in >future. > > Ok, my fault. I've notice this behaviour of ping while was writing script for manual starting sendmail, not from init. From glorg at bk.ru Thu Dec 22 07:34:44 2005 From: glorg at bk.ru (Alexey Tarasov) Date: Thu, 22 Dec 2005 17:34:44 +1000 Subject: sendmail+greylist-milter problem In-Reply-To: <200512220318.46283.russell@coker.com.au> References: <43A7B2D3.3020302@bk.ru> <200512220318.46283.russell@coker.com.au> Message-ID: <43AA5714.8050102@bk.ru> Russell Coker wrote: >On Tuesday 20 December 2005 18:29, Alexey Tarasov wrote: > > >>Problem 1. >>Installed: sendmail-8.3.14, milter-greylist-2.0.2, >>selinux-policy-targeted-1.27.2-19 >> >>starting sendmail from init results in: >>maillog >>--- >>sendmail[1997]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1674: >>Xgreylist: local socket name /var/milter-greylist/milter-greylist.sock >>unsafe: Permission denied >> >> > >The problem here is that there is no policy for greylist-milter (or any other >milter for that matter). > > >I am thinking of now writing a milter policy that is not specific to mail >servers (which means I can't call it a "milter" policy as the term "milter" >is specific to Sendmail - I need to find a suitable generic term for a MTA >helper program). > mta_filter_t is good enough. >The idea is that the generic mta-helper policy will >initially support postgrey and greylist-milter (the two I'm most aware of) >and with small modifications to the fc file most milter-type programs. I'm >sure that some milters will have different requirements, but a policy for >generic milters won't preclude having specific policies for milters that need >it. Of course this would mean that you can have a set of milters that all >have access to interfere with each other, is it common to have multiple >milters running in a situation where there is a great need to isolate them >from each other? > > As far as i know, mostly chained filters are used: addittional filter - antispam - antivirus Commercial software sometimes mix them in one filter. As for open source - It's better to get all filters working in same context, than isolated but not working. Well known and thus more often used filters are using similar methods to plug in to mail transfer agent, so generic contexts will cover not all, but most of them. There is only one problem: generic contexts are better, but for commonly used software. Rare soft may be incompatible with them. >With the Postfix policy I used many domains, but I don't want to always be so >free with creating new domains. With Postfix there is a limit to how many >domains will be needed. But the number of milter programs can grow without >limit (there's even a blog at http://www.milter.org/ to inform us about all >the new milters that are being written). So we want to restrict the number >of milters that get specific policy both to limit the size of the policy and >the difficulty of users getting working systems. > > >Comments? > > > It's better to introduce mechanism for programs to add contexts to policies during installation progress (or detect somehow at start or ask user for installed programms or something else), then to add many domains that never will be used by specific user. There is variety of mail transfer programs as well other software (of course, mostly used only 3-4 of them, but...) and it's not good idea get in my system everything to work with something i'll never used or will use. From glorg at bk.ru Thu Dec 22 07:43:18 2005 From: glorg at bk.ru (Alexey Tarasov) Date: Thu, 22 Dec 2005 17:43:18 +1000 Subject: sendmail+greylist-milter problem In-Reply-To: <43A9ADAC.2000809@laposte.net> References: <43A7B2D3.3020302@bk.ru> <200512220318.46283.russell@coker.com.au> <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> <43A9ADAC.2000809@laposte.net> Message-ID: <43AA5916.1080908@bk.ru> Nicolas Mailhot wrote: >> >> amavis+postfix has been included in default selinux policy for quite a >> long time. I'm pretty sure the policy applies to sendmail+amavisd too. > > Thanks, I'll try to add similar lines to postfix + amavisd for sendmail to sendmail.te and network.te. From dwalsh at redhat.com Thu Dec 22 20:29:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 22 Dec 2005 15:29:24 -0500 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: <43A8F39C.1060306@funchords.com> References: <43A8E5B0.8040902@funchords.com> <43A8EA49.4030504@mindspring.com> <43A8F39C.1060306@funchords.com> Message-ID: <43AB0CA4.8030809@redhat.com> selinux.funchords at spameater.org wrote: > Richard Hally - rhally at mindspring.com wrote: > >> Looks like you need to download the corresponding source for the >> policy you are running e.g. selinux-policy-targeted-source for that >> audit2allow and make load to work. > > ... and that works! Thanks! > > Any idea why the rule is needed for a redirection by a ping command > run by the root account? And if this is a FAQ, where is the best > place to cut my teeth on this? > ping runs under the ping_t domain and it is not allowed to write to the home dir. When you redirect in shell, shell has the application open the file which is not allowed. A hack to get around this problem is ping XYZ | cat > /home/dwalsh/myping -- From dwalsh at redhat.com Thu Dec 22 20:32:51 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 22 Dec 2005 15:32:51 -0500 Subject: Neophyte question re: httpd under SELinux In-Reply-To: <008701c60645$733e7160$6401a8c0@Laptop8100> References: <008701c60645$733e7160$6401a8c0@Laptop8100> Message-ID: <43AB0D73.9030203@redhat.com> Al Pacifico wrote: > Marcus- > > Thanks for your response. > > This helped some, I think, but I still have my issues. > > The URL > http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizin > g.html#sn-httpd-booleans didn't contribute much. > > Output of ls -Z showed directories of my .../test directory as > user_u:object_r:user_home_t. > > Changing context with chcon -Rv -t httpd_sys_script_t ./test (as root) did > not work... lot of permission denied messages. My machine has a multidisk > setup and /home is its own partition or disk; not sure if that matters. > > Output of getsebool -a | grep httpd is: > > allow_httpd_anon_write --> inactive > allow_httpd_sys_script_anon_write --> inactive > httpd_builtin_scripting --> active > httpd_can_network_connect --> inactive > httpd_disable_trans --> active > httpd_enable_cgi --> active > httpd_enable_ftp_server --> inactive > httpd_enable_homedirs --> active > httpd_ssi_exec --> active > httpd_suexec_disable_trans --> inactive > httpd_tty_comm --> inactive > httpd_unified --> active > > I totally agree with the comment about placing files in the correct places, > on a production machine. However, numerous apache modules come with testing > suites that use the system httpd executable (appropriately) in other > locations. > > I'm starting to believe that I should either use setenforce 0 when > developing. If I do that, and forget to turn it back on, will there be some > ugly ramifications later? I have to halt httpd from the console using ctrl-C > because of the -X option, so I can't just stick setenforce 1 in my script. > (Hmm.... how do I trap ctrl-C in a bash script?) I could switch to testing > with lighttpd for CGI and SCGI, but I do need to test some apache modules > for which that is not an option. > > Two things I still don't unmderstand: > Why doesn't the "Disable SELinux protection for httpd daemon" checkbox just > take care of the problem? > My /var/log/messages didn't help me... doesn't show all those permission > denied messages when I tried to recusively change the context in my .../test > directory. Should I be looking elsewhere? Do I need to tell SELinux > something? > > I'm sorry if my questions are pretty basic; I definitely fall in the > category of 80% just want to get the job done and 20% want to know more. > > Thanks. > -al > > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com > [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Marcus O. White > Sent: Wednesday, December 21, 2005 2:20 AM > To: fedora-selinux-list at redhat.com > Subject: Re: Neophyte question re: httpd under SELinux > > On Tue, 2005-12-20 at 22:26 -0800, Al Pacifico wrote: > >> I'm working on a CGI program in C, but recently SELinux seems to have >> tripped me up. >> >> I started with Tom Boutell's cgic and an example CGI program (provided in >> his source tree) that generates a JPEG on the fly. It ran fine months back >> with the following script: >> >> dir=$(dirname $0) >> /usr/sbin/httpd -X -k start -d $dir -e debug >> >> on my FC4 machine. >> >> Now, it's time to start testing the program I wrote, but my Apache >> > (version > >> 2.0.54, installed from Fedora RPM, if it matters) won't start unless I >> execute /usr/sbin/setenforce 0 before executing my script. (it took me a >> while to figure that one out!). In fact, /usr/sbin/httpd -v won't even >> > work. > >> I'm sure the SELinux policy has updated via yum since times when it >> > worked, > >> and that explains the change. I tried checking "Disable SELinux protection >> for httpd daemon" in the system-config-securitylevel dialog and >> > relabelling > >> my filesystems, but I still need to execute /usr/sbin/setenforce 0 >> beforehand to run my script that starts httpd with my CGI program. >> >> If it helps, the example CGI program (not the one I've written, but Tom >> Boutell's that formerly ran) is in the directory >> >> /home/myuser/Development/myproject/imageFromCGI_test/test >> >> and >> >> ls -l /home/myuser/Development/myproject/imageFromCGI_test/test outputs >> >> total 52 >> drwxrwxr-x 2 myuser apache 4096 Sep 9 10:03 cgi-bin >> drwxrwxr-x 2 myuser apache 4096 Sep 9 13:07 conf >> -rwxr-xr-x 1 root root 63 Dec 20 14:38 debug_CGI >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:08 htdocs >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 logs >> lrwxrwxrwx 1 root root 18 Sep 9 09:52 modules -> /etc/httpd/modules >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 run >> >> (probably only makes sense if you're accustomed to configuring apache; >> > this > >> directory is essentially the argument to the Apache ServerRoot directive). >> >> I inferred that the directory might be important since /sbin/service httpd >> start works fine, regardless of state of aforementioned checkbox. >> >> What bugs me is that I don't get any kind of warning... apache just never >> starts. >> Q: How do I get warnings? (grep avc /var/log/messages was of no help to my >> pea-brain) >> Q: What else do I need to change to alter this behavior? >> >> I understand that for a production machine, SELinux is a good thing. I >> hadn't installed it when I used FC2 and hadn't had much problem with FC3 >> > or > >> with FC4 until yesterday. I have to believe there is a better way than >> > just > >> turning it off. >> >> Thanks. >> -al >> >> Al Pacifico >> Seattle, WA >> >> >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > >From RHEL list: > > Gavin Young wrote: > >> Hey guys, hopefully someone out there can help me with this because >> > I'm > >> an SELinux virgin so to speak. >> >> We have a RHEL v4 box running apache amongst other things. No changes >> have been made to the standard Redhat policies. >> > > I'm no expert but I am trying to wade through Apache/selinux issues as > well. > You might find the following "beta" document helpful: > > ng.html#sn-httpd-booleans> > > ------------------- > On Fri, 4 Mar 2005, Gavin Young wrote: > > >> Hey guys, hopefully someone out there can help me with this because >> > I'm > >> an SELinux virgin so to speak. >> >> We have a RHEL v4 box running apache amongst other things. No changes >> have been made to the standard Redhat policies. >> >> We are wanting to run a perl based web app (Sql-Ledger) >> from /usr/local/sql-ledger but SELinux is stopping us. >> >> With SELinux disabled it works correctly. When SELinux protection of >> > the > >> HTTPD daemon is switched on the browser displays: Internal Server >> > Error > >> and /var/log/messages reports >> >> Mar 3 15:13:23 zorb1 kernel: audit(1109816003.103:0): avc: denied >> { execute } for pid=24711 exe=/usr/sbin/httpd name=login.pl dev=dm-0 >> ino=9228595 scontext=root:system_r:httpd_t >> > tcontext=root:object_r:usr_t > >> tclass=file >> >> >>> From what I can tell SELinux is stopping scripts being run from any >>> >> other directory apart from /var/www/cgi-bin. I have tried moving the >> sql-ledger directory into cgi-bin but that doesn't appear to help >> because it is still a sub-directory of cgi-bin. >> > > The release notes give a hint to the right direction but doesn't > directly > talk about cgi - you need to set the file contexts of the sql-ledger > stuff > as cgi-content, something like this: > "chcon -R -h -t httpd_sys_script_exec_t " > > - Panu - > > ---------------------- > > What are the HTTPD Booleans set to? > > getsebool -a | grep httpd > > httpd_enable_cgi needs to be active, if it is not. That wouldn't > generate the denial you have, so think of this as a "is it plugged in?" > type of question. > > >> We are wanting to run a perl based web app (Sql-Ledger) >> from /usr/local/sql-ledger but SELinux is stopping us. >> > > This is where someone could correct me for best practices advise. > > You want to seriously consider moving the CGI program to the appropriate > directory. Otherwise, you are trying to give Apache execute access to > something inside of /usr/local/ ... > > To do this in /usr/local/, you will need to change policy or > relabel /usr/local/ to make this happen, which will serve to reduce > security on the system. > > >> With SELinux disabled it works correctly. When SELinux protection of >> > the > >> HTTPD daemon is switched on the browser displays: Internal Server >> > Error > >> and /var/log/messages reports >> >> Mar 3 15:13:23 zorb1 kernel: audit(1109816003.103:0): avc: denied >> { execute } for pid=24711 exe=/usr/sbin/httpd name=login.pl dev=dm-0 >> ino=9228595 scontext=root:system_r:httpd_t >> > tcontext=root:object_r:usr_t > >> tclass=file >> >> >From what I can tell SELinux is stopping scripts being run from any >> other directory apart from /var/www/cgi-bin. I have tried moving the >> sql-ledger directory into cgi-bin but that doesn't appear to help >> because it is still a sub-directory of cgi-bin. >> > > That shouldn't be a problem. You just need to relabel the directory > recursively. This should work, and is a good practice since it refers > to the mapping of labels to directories/files as defined by the policy: > > restorecon -Rv /var/www/cgi-bin/sql-ledger/ > > If ls -Z doesn't show that the type is httpd_sys_script_t, do this: > > chcon -Rv -t httpd_sys_script_t /var/www/cgi-bin/sql-ledger/ > > >> This problem must have come up before... Any help would be much >> appreciated. >> > > Yeah, almost qualifies for a FAQ. > > Future updates to the Red Hat SELinux Guide[1] will likely address > Apache more thoroughly. > > - Karsten > [1] > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/in > dex.html > > HTH > > Marcus O. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > What avc messages are you seeing. With httpd_enable_homedirs turned on apache should be able to read your homedirs. If you are seeing file_t in your /var/log/audit/audit.log then you probably need to relabel your system. touch /.autorelabel reboot -- From rnicholsNOSPAM at comcast.net Fri Dec 23 02:40:03 2005 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Thu, 22 Dec 2005 20:40:03 -0600 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: <43AB0CA4.8030809@redhat.com> References: <43A8E5B0.8040902@funchords.com> <43A8EA49.4030504@mindspring.com> <43A8F39C.1060306@funchords.com> <43AB0CA4.8030809@redhat.com> Message-ID: Daniel J Walsh wrote: > ping runs under the ping_t domain and it is not allowed to write to the > home dir. When you redirect in shell, shell has the application open > the file which is not allowed. A hack to get around this problem is > > ping XYZ | cat > /home/dwalsh/myping It's actually the shell that opens the file for input or output redirection, so apparently SELinux is denying a write to a file that is already open for writing. Curious. -- Bob Nichols Yes, "NOSPAM" is really part of my email address. From adpacifico at yahoo.com Fri Dec 23 06:05:31 2005 From: adpacifico at yahoo.com (Al Pacifico) Date: Thu, 22 Dec 2005 22:05:31 -0800 (PST) Subject: Fwd: FW: Neophyte question re: httpd under SELinux Message-ID: <20051223060531.29795.qmail@web35907.mail.mud.yahoo.com> > -----Original Message----- > From: Daniel J Walsh [mailto:dwalsh at redhat.com] > Sent: Thursday, December 22, 2005 12:33 PM > To: Al Pacifico > Cc: fedora-selinux-list at redhat.com > Subject: Re: Neophyte question re: httpd under > SELinux > > Al Pacifico wrote: > > Marcus- > > > > Thanks for your response. > > > > This helped some, I think, but I still have my > issues. > > > > The URL > > > http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizin > > g.html#sn-httpd-booleans didn't contribute much. > > > > Output of ls -Z showed directories of my .../test > directory as > > user_u:object_r:user_home_t. > > > > Changing context with chcon -Rv -t > httpd_sys_script_t ./test (as root) did > > not work... lot of permission denied messages. My > machine has a multidisk > > setup and /home is its own partition or disk; not > sure if that matters. > > > > Output of getsebool -a | grep httpd is: > > > > allow_httpd_anon_write --> inactive > > allow_httpd_sys_script_anon_write --> inactive > > httpd_builtin_scripting --> active > > httpd_can_network_connect --> inactive > > httpd_disable_trans --> active > > httpd_enable_cgi --> active > > httpd_enable_ftp_server --> inactive > > httpd_enable_homedirs --> active > > httpd_ssi_exec --> active > > httpd_suexec_disable_trans --> inactive > > httpd_tty_comm --> inactive > > httpd_unified --> active > > > > I totally agree with the comment about placing > files in the correct > places, > > on a production machine. However, numerous apache > modules come with > testing > > suites that use the system httpd executable > (appropriately) in other > > locations. > > > > I'm starting to believe that I should either use > setenforce 0 when > > developing. If I do that, and forget to turn it > back on, will there be > some > > ugly ramifications later? I have to halt httpd > from the console using > ctrl-C > > because of the -X option, so I can't just stick > setenforce 1 in my script. > > (Hmm.... how do I trap ctrl-C in a bash script?) I > could switch to testing > > with lighttpd for CGI and SCGI, but I do need to > test some apache modules > > for which that is not an option. > > > > Two things I still don't unmderstand: > > Why doesn't the "Disable SELinux protection for > httpd daemon" checkbox > just > > take care of the problem? > > My /var/log/messages didn't help me... doesn't > show all those permission > > denied messages when I tried to recusively change > the context in my > .../test > > directory. Should I be looking elsewhere? Do I > need to tell SELinux > > something? > > > > I'm sorry if my questions are pretty basic; I > definitely fall in the > > category of 80% just want to get the job done and > 20% want to know more. > > > > Thanks. > > -al > > > > -----Original Message----- > > From: fedora-selinux-list-bounces at redhat.com > > [mailto:fedora-selinux-list-bounces at redhat.com] On > Behalf Of Marcus O. > White > > Sent: Wednesday, December 21, 2005 2:20 AM > > To: fedora-selinux-list at redhat.com > > Subject: Re: Neophyte question re: httpd under > SELinux > > > > On Tue, 2005-12-20 at 22:26 -0800, Al Pacifico > wrote: > > > >> I'm working on a CGI program in C, but recently > SELinux seems to have > >> tripped me up. > >> > >> I started with Tom Boutell's cgic and an example > CGI program (provided in > >> his source tree) that generates a JPEG on the > fly. It ran fine months > back > >> with the following script: > >> > >> dir=$(dirname $0) > >> /usr/sbin/httpd -X -k start -d $dir -e debug > >> > >> on my FC4 machine. > >> > >> Now, it's time to start testing the program I > wrote, but my Apache > >> > > (version > > > >> 2.0.54, installed from Fedora RPM, if it matters) > won't start unless I > >> execute /usr/sbin/setenforce 0 before executing > my script. (it took me a > >> while to figure that one out!). In fact, > /usr/sbin/httpd -v won't even > >> > > work. > > > >> I'm sure the SELinux policy has updated via yum > since times when it > >> > > worked, > > > >> and that explains the change. I tried checking > "Disable SELinux > protection > >> for httpd daemon" in the > system-config-securitylevel dialog and > >> > > relabelling > > > >> my filesystems, but I still need to execute > /usr/sbin/setenforce 0 > >> beforehand to run my script that starts httpd > with my CGI program. > >> > >> If it helps, the example CGI program (not the one > I've written, but Tom > >> Boutell's that formerly ran) is in the directory > >> > >> > /home/myuser/Development/myproject/imageFromCGI_test/test > > >> > >> and > >> > >> ls -l > /home/myuser/Development/myproject/imageFromCGI_test/test > outputs > >> > >> total 52 > >> drwxrwxr-x 2 myuser apache 4096 Sep 9 10:03 > cgi-bin > >> drwxrwxr-x 2 myuser apache 4096 Sep 9 13:07 > conf > >> -rwxr-xr-x 1 root root 63 Dec 20 14:38 > debug_CGI > >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:08 > htdocs > >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 > logs > >> lrwxrwxrwx 1 root root 18 Sep 9 09:52 > modules -> /etc/httpd/modules > >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 run > >> > >> (probably only makes sense if you're accustomed > to configuring apache; > >> > > this > > > >> directory is essentially the argument to the > Apache ServerRoot > directive). > >> > >> I inferred that the directory might be important > since /sbin/service > httpd > >> start works fine, regardless of state of > aforementioned checkbox. > >> > >> What bugs me is that I don't get any kind of > warning... apache just never > >> starts. > >> Q: How do I get warnings? (grep avc > /var/log/messages was of no help to > my > >> pea-brain) > >> Q: What else do I need to change to alter this > behavior? > >> > >> I understand that for a production machine, > SELinux is a good thing. I > >> hadn't installed it when I used FC2 and hadn't > had much problem with FC3 > >> > > or > > > >> with FC4 until yesterday. I have to believe there > is a better way than > >> > > just > > > >> turning it off. > >> > >> Thanks. > >> -al > >> > >> Al Pacifico > >> Seattle, WA > >> > >> > >> > >> > >> -- > >> fedora-selinux-list mailing list > >> fedora-selinux-list at redhat.com > >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> > > > > >From RHEL list: > > > > Gavin Young wrote: > > > >> Hey guys, hopefully someone out there can help me > with this because > >> > > I'm > > > >> an SELinux virgin so to speak. > >> > >> We have a RHEL v4 box running apache amongst > other things. No changes > >> have been made to the standard Redhat policies. > >> > > > > I'm no expert but I am trying to wade through > Apache/selinux issues as > > well. > > You might find the following "beta" document > helpful: > > > > > > ng.html#sn-httpd-booleans> > > > > ------------------- > > On Fri, 4 Mar 2005, Gavin Young wrote: > > > > > >> Hey guys, hopefully someone out there can help me > with this because > >> > > I'm > > > >> an SELinux virgin so to speak. > >> > >> We have a RHEL v4 box running apache amongst > other things. No changes > >> have been made to the standard Redhat policies. > >> > >> We are wanting to run a perl based web app > (Sql-Ledger) > >> from /usr/local/sql-ledger but SELinux is > stopping us. > >> > >> With SELinux disabled it works correctly. When > SELinux protection of > >> > > the > > > >> HTTPD daemon is switched on the browser displays: > Internal Server > >> > > Error > > > >> and /var/log/messages reports > >> > >> Mar 3 15:13:23 zorb1 kernel: > audit(1109816003.103:0): avc: denied > >> { execute } for pid=24711 exe=/usr/sbin/httpd > name=login.pl dev=dm-0 > >> ino=9228595 scontext=root:system_r:httpd_t > >> > > tcontext=root:object_r:usr_t > > > >> tclass=file > >> > >> > >>> From what I can tell SELinux is stopping scripts > being run from any > >>> > >> other directory apart from /var/www/cgi-bin. I > have tried moving the > >> sql-ledger directory into cgi-bin but that > doesn't appear to help > >> because it is still a sub-directory of cgi-bin. > >> > > > > The release notes give a hint to the right > direction but doesn't > > directly > > talk about cgi - you need to set the file contexts > of the sql-ledger > > stuff > > as cgi-content, something like this: > > "chcon -R -h -t httpd_sys_script_exec_t slq-ledger directory>" > > > > - Panu - > > > > ---------------------- > > > > What are the HTTPD Booleans set to? > > > > getsebool -a | grep httpd > > > > httpd_enable_cgi needs to be active, if it is not. > That wouldn't > > generate the denial you have, so think of this as > a "is it plugged in?" > > type of question. > > > > > >> We are wanting to run a perl based web app > (Sql-Ledger) > >> from /usr/local/sql-ledger but SELinux is > stopping us. > >> > > > > This is where someone could correct me for best > practices advise. > > > > You want to seriously consider moving the CGI > program to the appropriate > > directory. Otherwise, you are trying to give > Apache execute access to > > something inside of /usr/local/ ... > > > > To do this in /usr/local/, you will need to change > policy or > > relabel /usr/local/ to make this happen, which > will serve to reduce > > security on the system. > > > > > >> With SELinux disabled it works correctly. When > SELinux protection of > >> > > the > > > >> HTTPD daemon is switched on the browser displays: > Internal Server > >> > > Error > > > >> and /var/log/messages reports > >> > >> Mar 3 15:13:23 zorb1 kernel: > audit(1109816003.103:0): avc: denied > >> { execute } for pid=24711 exe=/usr/sbin/httpd > name=login.pl dev=dm-0 > >> ino=9228595 scontext=root:system_r:httpd_t > >> > > tcontext=root:object_r:usr_t > > > >> tclass=file > >> > >> >From what I can tell SELinux is stopping scripts > being run from any > >> other directory apart from /var/www/cgi-bin. I > have tried moving the > >> sql-ledger directory into cgi-bin but that > doesn't appear to help > >> because it is still a sub-directory of cgi-bin. > >> > > > > That shouldn't be a problem. You just need to > relabel the directory > > recursively. This should work, and is a good > practice since it refers > > to the mapping of labels to directories/files as > defined by the policy: > > > > restorecon -Rv /var/www/cgi-bin/sql-ledger/ > > > > If ls -Z doesn't show that the type is > httpd_sys_script_t, do this: > > > > chcon -Rv -t httpd_sys_script_t > /var/www/cgi-bin/sql-ledger/ > > > > > >> This problem must have come up before... Any help > would be much > >> appreciated. > >> > > > > Yeah, almost qualifies for a FAQ. > > > > Future updates to the Red Hat SELinux Guide[1] > will likely address > > Apache more thoroughly. > > > > - Karsten > > [1] > > > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/in > > dex.html > > > > HTH > > > > Marcus O. > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > What avc messages are you seeing. With > httpd_enable_homedirs turned on > apache should be able to read your homedirs. > If you are seeing file_t in your > /var/log/audit/audit.log then you > probably need to relabel your system. > > touch /.autorelabel > reboot > > -- > > > > > Thanks, Daniel! Still stumped. I've reduced this to a simple case that can be executed on any FC4 box (updated via yum) that has the httpd RPM and SELinux, so that you might be able to look on your machine. [root at powell imageFromCGI_test]# /usr/sbin/httpd -V [root at powell imageFromCGI_test]# /usr/sbin/setenforce 0 [root at powell imageFromCGI_test]# /usr/sbin/httpd -V Server version: Apache/2.0.54 Server built: Sep 2 2005 11:54:18 [root at powell imageFromCGI_test]# /usr/sbin/setenforce 1 [root at powell imageFromCGI_test]# /usr/sbin/httpd -V [root at powell imageFromCGI_test]# Output of grep AVC /var/log/audit/audit.log now ends with: type=AVC msg=audit(1135317046.340:535): avc: granted { setenforce } for pid=8452 comm="setenforce" scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security type=AVC msg=audit(1135317060.595:536): avc: granted { setenforce } for pid=8454 comm="setenforce" scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Shouldn't there have been a message following the last line saying my execution of /usr/sbin/httpd -V was denied? Output of getsebool -a | grep httpd is still: allow_httpd_anon_write --> inactive allow_httpd_sys_script_anon_write --> inactive httpd_builtin_scripting --> active httpd_can_network_connect --> inactive httpd_disable_trans --> active httpd_enable_cgi --> active httpd_enable_ftp_server --> inactive httpd_enable_homedirs --> active httpd_ssi_exec --> active httpd_suexec_disable_trans --> inactive httpd_tty_comm --> inactive httpd_unified --> active Any ideas? Clearly, I'm missing something, here. -al __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From russell at coker.com.au Fri Dec 23 11:47:45 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 23 Dec 2005 22:47:45 +1100 Subject: sendmail+greylist-milter problem In-Reply-To: <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> References: <43A7B2D3.3020302@bk.ru> <200512220318.46283.russell@coker.com.au> <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> Message-ID: <200512232247.53665.russell@coker.com.au> On Thursday 22 December 2005 03:53, "Nicolas Mailhot" wrote: > On Mer 21 d?cembre 2005 17:18, Russell Coker wrote: > > The problem here is that there is no policy for greylist-milter (or any > > other > > milter for that matter). > > amavis+postfix has been included in default selinux policy for quite a > long time. I'm pretty sure the policy applies to sendmail+amavis too. I should have thought of Amavis, I wrote a good chunk of the Amavis policy. You are correct that it SHOULD work with Sendmail, I designed it such that it would work with Sendmail and Qmail but I've never tested it with anything other than Postfix. I'll use the mta_filter_t domain that Alexey suggests and make Amavis such a filter as well. -- 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 linux_4ever at yahoo.com Fri Dec 23 16:12:29 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 23 Dec 2005 08:12:29 -0800 (PST) Subject: acpid avcs Message-ID: <20051223161229.76594.qmail@web51515.mail.yahoo.com> Hi...from my logs: type=PATH msg=audit(12/23/2005 10:36:04.030:20507) : item=0 name=(null) inode=14909846 dev=03:07 mode=socket,666 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:var_run_t:s0 type=SOCKADDR msg=audit(12/23/2005 10:36:04.030:20507) : saddr=local /var/run/acpid.socket type=SYSCALL msg=audit(12/23/2005 10:36:04.030:20507) : arch=x86_64 syscall=connect success=no exit=-13(Permission denied) a0=4 a1=7fffffbf25c0 a2=6e a3=7fffffbf2428 items=1 pid=2242 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi subj=system_u:system_r:hald_t:s0 type=AVC msg=audit(12/23/2005 10:36:04.030:20507) : avc: denied { write } for pid=2242 comm=hald-addon-acpi name=acpid.socket dev=hda7 ino=14909846 scontext=system_u:system_r:hald_t:s0 context=system_u:object_r:var_run_t:s0 tclass=sock_file This just scrolls for hours and hours... -Steve __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From linux_4ever at yahoo.com Fri Dec 23 16:33:58 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 23 Dec 2005 08:33:58 -0800 (PST) Subject: samba share avcs Message-ID: <20051223163359.84451.qmail@web51501.mail.yahoo.com> Hi, This is a long standing problem that causes me to do "setenforce 0". I wished there was a boolean to just turn of checking of samba or a streamlined way for samba to relabel things on startup. In any event, I have a share, /src, which I want to access across the network. It fails. This is what I see in the logs: type=PATH msg=audit(12/23/2005 10:37:26.180:20524) : item=0 name=gtk+-2.8.9/gdk-pixbuf/pixops/pixops.c inode=1934832 dev=03:07 mode=dir,755 ouid=sgrubb ogid=sgrubb rdev=00:00 obj=user_u:object_r:user_home_t:s0 type=CWD msg=audit(12/23/2005 10:37:26.180:20524) : cwd=/src type=SYSCALL msg=audit(12/23/2005 10:37:26.180:20524) : arch=x86_64 syscall=stat success=no exit=-13(Permission denied) a0=7fffffe1c720 a1=7fffffe1b120 a2=7fffffe1b120 a3=7fffffe1aaec items=1 pid=23380 auid=root uid=nobody gid=root euid=nobody suid=root fsuid=nobody egid=nobody sgid=nobody fsgid=nobody comm=smbd exe=/usr/sbin/smbd subj=root:system_r:smbd_t:s0 type=AVC msg=audit(12/23/2005 10:37:26.180:20524) : avc: denied { search } for pid=23380 comm=smbd name=gtk+-2.8.9 dev=hda7 ino=1934832 scontext=root:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=dir What is the correct solution for this? -Steve __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From dragoran at feuerpokemon.de Sat Dec 24 08:34:48 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 24 Dec 2005 09:34:48 +0100 Subject: how does selinux get initialized durring bootup? Message-ID: <43AD0828.5060605@feuerpokemon.de> as you can see here: http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 there is a bug in initng that after booting selinux is not working. what needs to be done in the boot process to get selinux working ? have searched in the initscripts and have'nt found anything that helps. From dwalsh at redhat.com Sat Dec 24 12:31:57 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 24 Dec 2005 07:31:57 -0500 Subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file... In-Reply-To: References: <43A8E5B0.8040902@funchords.com> <43A8EA49.4030504@mindspring.com> <43A8F39C.1060306@funchords.com> <43AB0CA4.8030809@redhat.com> Message-ID: <43AD3FBD.8050902@redhat.com> Robert Nichols wrote: > Daniel J Walsh wrote: >> ping runs under the ping_t domain and it is not allowed to write to >> the home dir. When you redirect in shell, shell has the application >> open the file which is not allowed. A hack to get around this >> problem is >> >> ping XYZ | cat > /home/dwalsh/myping > > It's actually the shell that opens the file for input or output > redirection, so apparently SELinux is denying a write to a file > that is already open for writing. Curious. > That would seem logical, but from the kernel's perspective it looks like the ping command is opening the file on redirection. IE Stdout gets replaced with the write to the file. SELinux blocks on read/write not open. -- From dwalsh at redhat.com Sat Dec 24 12:43:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 24 Dec 2005 07:43:08 -0500 Subject: acpid avcs In-Reply-To: <20051223161229.76594.qmail@web51515.mail.yahoo.com> References: <20051223161229.76594.qmail@web51515.mail.yahoo.com> Message-ID: <43AD425C.3090606@redhat.com> Steve G wrote: > Hi...from my logs: > > type=PATH msg=audit(12/23/2005 10:36:04.030:20507) : item=0 name=(null) > inode=14909846 dev=03:07 mode=socket,666 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:var_run_t:s0 > type=SOCKADDR msg=audit(12/23/2005 10:36:04.030:20507) : saddr=local > /var/run/acpid.socket > type=SYSCALL msg=audit(12/23/2005 10:36:04.030:20507) : arch=x86_64 > syscall=connect success=no exit=-13(Permission denied) a0=4 a1=7fffffbf25c0 > a2=6e a3=7fffffbf2428 items=1 pid=2242 auid=unknown(4294967295) uid=root > gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi > subj=system_u:system_r:hald_t:s0 > type=AVC msg=audit(12/23/2005 10:36:04.030:20507) : avc: denied { write } > for pid=2242 comm=hald-addon-acpi name=acpid.socket dev=hda7 ino=14909846 > scontext=system_u:system_r:hald_t:s0 context=system_u:object_r:var_run_t:s0 > tclass=sock_file > > This just scrolls for hours and hours... > > You have a mislabled socket file in /var/run. restorecon -v /var/run/acpid.socket ls -lZ /var/run/acpid.socket srw-rw-rw- root root system_u:object_r:apmd_var_run_t /var/run/acpid.socket > -Steve > > > > __________________________________________ > Yahoo! DSL ? Something to write home about. > Just $16.99/mo. or less. > dsl.yahoo.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From dwalsh at redhat.com Sat Dec 24 12:53:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 24 Dec 2005 07:53:31 -0500 Subject: samba share avcs In-Reply-To: <20051223163359.84451.qmail@web51501.mail.yahoo.com> References: <20051223163359.84451.qmail@web51501.mail.yahoo.com> Message-ID: <43AD44CB.6020903@redhat.com> Steve G wrote: > Hi, > > This is a long standing problem that causes me to do "setenforce 0". I wished > there was a boolean to just turn of checking of samba or a streamlined way for > samba to relabel things on startup. In any event, I have a share, /src, which I > want to access across the network. It fails. This is what I see in the logs: > > type=PATH msg=audit(12/23/2005 10:37:26.180:20524) : item=0 > name=gtk+-2.8.9/gdk-pixbuf/pixops/pixops.c inode=1934832 dev=03:07 mode=dir,755 > ouid=sgrubb ogid=sgrubb rdev=00:00 obj=user_u:object_r:user_home_t:s0 > type=CWD msg=audit(12/23/2005 10:37:26.180:20524) : cwd=/src > type=SYSCALL msg=audit(12/23/2005 10:37:26.180:20524) : arch=x86_64 syscall=stat > success=no exit=-13(Permission denied) a0=7fffffe1c720 a1=7fffffe1b120 > a2=7fffffe1b120 a3=7fffffe1aaec items=1 pid=23380 auid=root uid=nobody gid=root > euid=nobody suid=root fsuid=nobody egid=nobody sgid=nobody fsgid=nobody comm=smbd > exe=/usr/sbin/smbd subj=root:system_r:smbd_t:s0 > type=AVC msg=audit(12/23/2005 10:37:26.180:20524) : avc: denied { search } for > pid=23380 comm=smbd name=gtk+-2.8.9 dev=hda7 ino=1934832 > scontext=root:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_t:s0 > tclass=dir > > What is the correct solution for this? > > -Steve > chcon -r -t samba_share_t /src You can also use public_content_t if you want other sharing protocols access to the files (http, ftp, rsync) man samba_selinux > > > > __________________________________ > Yahoo! for Good - Make a difference this year. > http://brand.yahoo.com/cybergivingweek2005/ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From russell at coker.com.au Sun Dec 25 11:29:55 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 25 Dec 2005 22:29:55 +1100 Subject: sendmail+greylist-milter problem In-Reply-To: <200512232247.53665.russell@coker.com.au> References: <43A7B2D3.3020302@bk.ru> <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> <200512232247.53665.russell@coker.com.au> Message-ID: <200512252230.03647.russell@coker.com.au> On Friday 23 December 2005 22:47, Russell Coker wrote: > On Thursday 22 December 2005 03:53, "Nicolas Mailhot" > > wrote: > > On Mer 21 d?cembre 2005 17:18, Russell Coker wrote: > > > The problem here is that there is no policy for greylist-milter (or any > > > other > > > milter for that matter). > > > > amavis+postfix has been included in default selinux policy for quite a > > long time. I'm pretty sure the policy applies to sendmail+amavis too. > > I should have thought of Amavis, I wrote a good chunk of the Amavis policy. > You are correct that it SHOULD work with Sendmail, I designed it such that > it would work with Sendmail and Qmail but I've never tested it with > anything other than Postfix. > > I'll use the mta_filter_t domain that Alexey suggests and make Amavis such > a filter as well. I've attached a first cut at the policy for the mta_filter_t, I still have other things to do but I believe that the policy in this patch is only an improvement over the current situation and is therefore worth merging. This replaces the postgrey.te and postgrey.fc files as postgrey will run in the same domain (but my patch doesn't remove those files). Note that the ifdef(`distro_mandriva' does not imply that you would run SE Linux on Mandriva (much more work would need to be done for that), merely that if you want to force Mandriva packages to work on Fedora then you need to have the policy support the directories that they choose. Mandriva seems to be the only distribution with Postgrey RPMs. I haven't yet got Amavis working on my test machine so the Amavis policy isn't merged. Amavis requires some extra work because it has the daemon to get new virus definitions (freshclam). My plan is that the daemon to get new virus definitions will run in a separate domain and write to files that are read-only for the mta_filter_t domain. Of course if freshclam is cracked then you could end up with a virus definition that marks every message as being a virus (which would be really bad), but gives it a little extra isolation from the mail server domains. Among other things I plan to have a boolean to determine whether the mta_filter_t domain can do TCP/UDP networking, preventing the filter from making connections to the outside world could be very useful. Incidentally if someone wants to package Postgrey and Amavis for Fedora Extras then that would be really good. PS Alexy, I'm not sure if you want to get involved in SE Linux policy development to the level of testing this patch out. If not then just wait a week or so and this will become a standard policy feature. PPS Happy holidays everyone! -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 6037 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Sun Dec 25 11:57:51 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 25 Dec 2005 12:57:51 +0100 Subject: sendmail+greylist-milter problem In-Reply-To: <200512252230.03647.russell@coker.com.au> References: <43A7B2D3.3020302@bk.ru> <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> <200512232247.53665.russell@coker.com.au> <200512252230.03647.russell@coker.com.au> Message-ID: <43AE893F.1090404@laPoste.net> Russell Coker a ?crit : > Incidentally if someone wants to package Postgrey and Amavis for Fedora Extras > then that would be really good. There is a fairly good amavis package in FE bugzilla waiting for someone to authorise it. I've been running it fopr months without problems, and I'm not alone, so it only needs someone with both perl experoence and review rights to be approved. Please take a peek at it. Regards, -- Nicolas Mailhot From glorg at bk.ru Sun Dec 25 13:57:15 2005 From: glorg at bk.ru (Alexey Tarasov) Date: Sun, 25 Dec 2005 23:57:15 +1000 Subject: sendmail+greylist-milter problem In-Reply-To: <200512252230.03647.russell@coker.com.au> References: <43A7B2D3.3020302@bk.ru> <55506.192.54.193.35.1135184037.squirrel@rousalka.dyndns.org> <200512232247.53665.russell@coker.com.au> <200512252230.03647.russell@coker.com.au> Message-ID: <1259774832.20051225235715@bk.ru> > PS Alexy, I'm not sure if you want to get involved in SE Linux policy > development to the level of testing this patch out. If not then just wait a > week or so and this will become a standard policy feature. Thanks, nothing prevents me from waiting some time and nothing doing meanwhile... New Year anyway. But I've noticed some moments in patch: --- +/var/lib/milter-greylist(/.*)? system_u:object_r:mta_filter_var_lib_t:s0 +/var/lib/milter-greylist/run/milter-greylist.sock -s system_u:object_r:mta_filter_var_run_t:s0 +/usr/sbin/milter-greylist -- system_u:object_r:mta_filter_exec_t:s0 --- By default (make, make install), $DESTDIR is not set, so Makefile from milter-greylist 2.0.2 ${INSTALL} -d -m 755 -o ${USER} ${DESTDIR}/var/milter-greylist create db and stuff dir /var/milter-greylist, not /var/lib/milter-greylist Default locations, defined in greylist.conf, are: #pidfile "/var/run/milter-greylist.pid" #socket "/var/milter-greylist/milter-greylist.sock" #dumpfile "/var/milter-greylist/greylist.db" Also, executable milter_greylist placed to /usr/local/sbin: prefix= /usr/local exec_prefix= ${prefix} SBINDIR= ${exec_prefix}/sbin ${INSTALL} -m 755 milter-greylist ${DESTDIR}${SBINDIR} May be, it's just in newest versions of milter-greylist. > PPS Happy holidays everyone! Same to you. From russell at coker.com.au Sun Dec 25 13:35:43 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 26 Dec 2005 00:35:43 +1100 Subject: sendmail+greylist-milter problem In-Reply-To: <1259774832.20051225235715@bk.ru> References: <43A7B2D3.3020302@bk.ru> <200512252230.03647.russell@coker.com.au> <1259774832.20051225235715@bk.ru> Message-ID: <200512260035.50051.russell@coker.com.au> On Monday 26 December 2005 00:57, Alexey Tarasov wrote: > But I've noticed some moments in patch: > --- > +/var/lib/milter-greylist(/.*)? system_u:object_r:mta_filter_var_lib_t:s0 > +/var/lib/milter-greylist/run/milter-greylist.sock -s > system_u:object_r:mta_filter_var_run_t:s0 +/usr/sbin/milter-greylist -- > system_u:object_r:mta_filter_exec_t:s0 --- > By default (make, make install), $DESTDIR is not set, so Makefile from > milter-greylist 2.0.2 > > ${INSTALL} -d -m 755 -o ${USER} ${DESTDIR}/var/milter-greylist > > create db and stuff dir /var/milter-greylist, not /var/lib/milter-greylist /var/lib is a more appropriate location and is the location used in the Fedora Extras package (which is what I'm supporting with my policy). Also the socket file belongs under /var/run according to my interpretation of the FHS, I've added an update to a bugzilla entry for the milter-greylist package with this suggestion. > Default locations, defined in greylist.conf, are: > > #pidfile "/var/run/milter-greylist.pid" > #socket "/var/milter-greylist/milter-greylist.sock" > #dumpfile "/var/milter-greylist/greylist.db" Good point about the pid file, that's something I forgot. I've updated the policy on my test machine, next time I release a patch I'll include it. > Also, executable milter_greylist placed to /usr/local/sbin: Policy that we release will always be for programs that are packaged as RPMs, such programs will be under (/usr)?/s?bin not under /usr/local. -- 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 selinux at gmail.com Sun Dec 25 19:19:14 2005 From: selinux at gmail.com (Tom London) Date: Sun, 25 Dec 2005 11:19:14 -0800 Subject: acpid avcs In-Reply-To: <43AD425C.3090606@redhat.com> References: <20051223161229.76594.qmail@web51515.mail.yahoo.com> <43AD425C.3090606@redhat.com> Message-ID: <4c4ba1530512251119v40f5cd39wa25241b981047ec3@mail.gmail.com> On 12/24/05, Daniel J Walsh wrote: > Steve G wrote: > > Hi...from my logs: > > > > type=PATH msg=audit(12/23/2005 10:36:04.030:20507) : item=0 name=(null) > > inode=14909846 dev=03:07 mode=socket,666 ouid=root ogid=root rdev=00:00 > > obj=system_u:object_r:var_run_t:s0 > > type=SOCKADDR msg=audit(12/23/2005 10:36:04.030:20507) : saddr=local > > /var/run/acpid.socket > > type=SYSCALL msg=audit(12/23/2005 10:36:04.030:20507) : arch=x86_64 > > syscall=connect success=no exit=-13(Permission denied) a0=4 a1=7fffffbf25c0 > > a2=6e a3=7fffffbf2428 items=1 pid=2242 auid=unknown(4294967295) uid=root > > gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > > comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi > > subj=system_u:system_r:hald_t:s0 > > type=AVC msg=audit(12/23/2005 10:36:04.030:20507) : avc: denied { write } > > for pid=2242 comm=hald-addon-acpi name=acpid.socket dev=hda7 ino=14909846 > > scontext=system_u:system_r:hald_t:s0 context=system_u:object_r:var_run_t:s0 > > tclass=sock_file > > > > This just scrolls for hours and hours... > > > > > You have a mislabled socket file in /var/run. > > restorecon -v /var/run/acpid.socket > ls -lZ /var/run/acpid.socket > srw-rw-rw- root root system_u:object_r:apmd_var_run_t /var/run/acpid.socket > > > -Steve > > Uhhh, a bit more here: I get many 100s of these (while running latest rawhide, targeted/enforcing): ---- type=PATH msg=audit(12/25/2005 11:15:38.770:1619) : item=0 flags=follow inode=2142287 dev=fd:00 mode=socket,666 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(12/25/2005 11:15:38.770:1619) : nargs=3 a0=4 a1=bffabfb6 a2=6e type=SOCKADDR msg=audit(12/25/2005 11:15:38.770:1619) : saddr=local /var/run/acpid.socket type=AVC_PATH msg=audit(12/25/2005 11:15:38.770:1619) : path=/var/run/acpid.socket type=SYSCALL msg=audit(12/25/2005 11:15:38.770:1619) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bffabf80 a2=4 a3=989d030 items=1 pid=2719 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi type=AVC msg=audit(12/25/2005 11:15:38.770:1619) : avc: denied { connectto } for pid=2719 comm=hald-addon-acpi name=acpid.socket scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:crond_t:s0 tclass=unix_stream_socket ---- type=PATH msg=audit(12/25/2005 11:15:43.774:1620) : item=0 flags=follow inode=2142287 dev=fd:00 mode=socket,666 ouid=root ogid=root rdev=00:00 type=SOCKETCALL msg=audit(12/25/2005 11:15:43.774:1620) : nargs=3 a0=4 a1=bffabfb6 a2=6e type=SOCKADDR msg=audit(12/25/2005 11:15:43.774:1620) : saddr=local /var/run/acpid.socket type=AVC_PATH msg=audit(12/25/2005 11:15:43.774:1620) : path=/var/run/acpid.socket type=SYSCALL msg=audit(12/25/2005 11:15:43.774:1620) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bffabf80 a2=4 a3=989d030 items=1 pid=2719 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi type=AVC msg=audit(12/25/2005 11:15:43.774:1620) : avc: denied { connectto } for pid=2719 comm=hald-addon-acpi name=acpid.socket scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:crond_t:s0 tclass=unix_stream_socket Strange thing is, /var/run/acpid.socket is NOT labeled crond_t, but apmd_var_run_t: [root at tlondon ~]# ls -lZ /var/run/acpi* srw-rw-rw- root root system_u:object_r:apmd_var_run_t /var/run/acpid.socket [root at tlondon ~]# tom -- Tom London From selinux at gmail.com Sun Dec 25 20:50:03 2005 From: selinux at gmail.com (Tom London) Date: Sun, 25 Dec 2005 12:50:03 -0800 Subject: acpid avcs In-Reply-To: <4c4ba1530512251119v40f5cd39wa25241b981047ec3@mail.gmail.com> References: <20051223161229.76594.qmail@web51515.mail.yahoo.com> <43AD425C.3090606@redhat.com> <4c4ba1530512251119v40f5cd39wa25241b981047ec3@mail.gmail.com> Message-ID: <4c4ba1530512251250vbc32932j67c7fbb631ec7849@mail.gmail.com> On 12/25/05, Tom London wrote: > On 12/24/05, Daniel J Walsh wrote: > > Steve G wrote: > > > Hi...from my logs: > > > > > > type=PATH msg=audit(12/23/2005 10:36:04.030:20507) : item=0 name=(null) > > > inode=14909846 dev=03:07 mode=socket,666 ouid=root ogid=root rdev=00:00 > > > obj=system_u:object_r:var_run_t:s0 > > > type=SOCKADDR msg=audit(12/23/2005 10:36:04.030:20507) : saddr=local > > > /var/run/acpid.socket > > > type=SYSCALL msg=audit(12/23/2005 10:36:04.030:20507) : arch=x86_64 > > > syscall=connect success=no exit=-13(Permission denied) a0=4 a1=7fffffbf25c0 > > > a2=6e a3=7fffffbf2428 items=1 pid=2242 auid=unknown(4294967295) uid=root > > > gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > > > comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi > > > subj=system_u:system_r:hald_t:s0 > > > type=AVC msg=audit(12/23/2005 10:36:04.030:20507) : avc: denied { write } > > > for pid=2242 comm=hald-addon-acpi name=acpid.socket dev=hda7 ino=14909846 > > > scontext=system_u:system_r:hald_t:s0 context=system_u:object_r:var_run_t:s0 > > > tclass=sock_file > > > > > > This just scrolls for hours and hours... > > > > > > > > You have a mislabled socket file in /var/run. > > > > restorecon -v /var/run/acpid.socket > > ls -lZ /var/run/acpid.socket > > srw-rw-rw- root root system_u:object_r:apmd_var_run_t /var/run/acpid.socket > > > > > -Steve > > > > Uhhh, a bit more here: I get many 100s of these (while running latest > rawhide, targeted/enforcing): > ---- > type=PATH msg=audit(12/25/2005 11:15:38.770:1619) : item=0 > flags=follow inode=2142287 dev=fd:00 mode=socket,666 ouid=root > ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(12/25/2005 11:15:38.770:1619) : nargs=3 a0=4 > a1=bffabfb6 a2=6e > type=SOCKADDR msg=audit(12/25/2005 11:15:38.770:1619) : saddr=local > /var/run/acpid.socket > type=AVC_PATH msg=audit(12/25/2005 11:15:38.770:1619) : > path=/var/run/acpid.socket > type=SYSCALL msg=audit(12/25/2005 11:15:38.770:1619) : arch=i386 > syscall=socketcall(connect) success=no exit=-13(Permission denied) > a0=3 a1=bffabf80 a2=4 a3=989d030 items=1 pid=2719 > auid=unknown(4294967295) uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root comm=hald-addon-acpi > exe=/usr/libexec/hald-addon-acpi > type=AVC msg=audit(12/25/2005 11:15:38.770:1619) : avc: denied { > connectto } for pid=2719 comm=hald-addon-acpi name=acpid.socket > scontext=system_u:system_r:hald_t:s0 > tcontext=system_u:system_r:crond_t:s0 tclass=unix_stream_socket > ---- > type=PATH msg=audit(12/25/2005 11:15:43.774:1620) : item=0 > flags=follow inode=2142287 dev=fd:00 mode=socket,666 ouid=root > ogid=root rdev=00:00 > type=SOCKETCALL msg=audit(12/25/2005 11:15:43.774:1620) : nargs=3 a0=4 > a1=bffabfb6 a2=6e > type=SOCKADDR msg=audit(12/25/2005 11:15:43.774:1620) : saddr=local > /var/run/acpid.socket > type=AVC_PATH msg=audit(12/25/2005 11:15:43.774:1620) : > path=/var/run/acpid.socket > type=SYSCALL msg=audit(12/25/2005 11:15:43.774:1620) : arch=i386 > syscall=socketcall(connect) success=no exit=-13(Permission denied) > a0=3 a1=bffabf80 a2=4 a3=989d030 items=1 pid=2719 > auid=unknown(4294967295) uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root comm=hald-addon-acpi > exe=/usr/libexec/hald-addon-acpi > type=AVC msg=audit(12/25/2005 11:15:43.774:1620) : avc: denied { > connectto } for pid=2719 comm=hald-addon-acpi name=acpid.socket > scontext=system_u:system_r:hald_t:s0 > tcontext=system_u:system_r:crond_t:s0 tclass=unix_stream_socket > > Strange thing is, /var/run/acpid.socket is NOT labeled crond_t, but > apmd_var_run_t: > [root at tlondon ~]# ls -lZ /var/run/acpi* > srw-rw-rw- root root system_u:object_r:apmd_var_run_t > /var/run/acpid.socket > [root at tlondon ~]# > A bit more on this: [root at tlondon ~]# ps gaxZ | grep crond_t system_u:system_r:crond_t:SystemLow-SystemHigh 2639 ? Ss 0:00 crond system_u:system_r:crond_t:SystemLow-SystemHigh 2656 ? Ss 0:00 /usr/sbin/atd system_u:system_r:crond_t 4295 ? SNs 0:00 /usr/sbin/acpid system_u:system_r:crond_t 4307 ? SNs 0:00 cupsd [root at tlondon ~]# Should acpid and cupsd be running as crond_t? [root at tlondon ~]# ls -lZ /usr/sbin/acpid -rwxr-x--- root root system_u:object_r:apmd_exec_t /usr/sbin/acpid [root at tlondon ~]# ls -lZ /usr/sbin/cupsd -rwxr-xr-x root root system_u:object_r:cupsd_exec_t /usr/sbin/cupsd [root at tlondon ~]# Is there a missing transition (or some such)? tom -- Tom London From dwalsh at redhat.com Tue Dec 27 20:34:01 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 27 Dec 2005 15:34:01 -0500 Subject: acpid avcs In-Reply-To: <4c4ba1530512251250vbc32932j67c7fbb631ec7849@mail.gmail.com> References: <20051223161229.76594.qmail@web51515.mail.yahoo.com> <43AD425C.3090606@redhat.com> <4c4ba1530512251119v40f5cd39wa25241b981047ec3@mail.gmail.com> <4c4ba1530512251250vbc32932j67c7fbb631ec7849@mail.gmail.com> Message-ID: <43B1A539.3020403@redhat.com> Tom London wrote: > On 12/25/05, Tom London wrote: > >> On 12/24/05, Daniel J Walsh wrote: >> >>> Steve G wrote: >>> >>>> Hi...from my logs: >>>> >>>> type=PATH msg=audit(12/23/2005 10:36:04.030:20507) : item=0 name=(null) >>>> inode=14909846 dev=03:07 mode=socket,666 ouid=root ogid=root rdev=00:00 >>>> obj=system_u:object_r:var_run_t:s0 >>>> type=SOCKADDR msg=audit(12/23/2005 10:36:04.030:20507) : saddr=local >>>> /var/run/acpid.socket >>>> type=SYSCALL msg=audit(12/23/2005 10:36:04.030:20507) : arch=x86_64 >>>> syscall=connect success=no exit=-13(Permission denied) a0=4 a1=7fffffbf25c0 >>>> a2=6e a3=7fffffbf2428 items=1 pid=2242 auid=unknown(4294967295) uid=root >>>> gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root >>>> comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi >>>> subj=system_u:system_r:hald_t:s0 >>>> type=AVC msg=audit(12/23/2005 10:36:04.030:20507) : avc: denied { write } >>>> for pid=2242 comm=hald-addon-acpi name=acpid.socket dev=hda7 ino=14909846 >>>> scontext=system_u:system_r:hald_t:s0 context=system_u:object_r:var_run_t:s0 >>>> tclass=sock_file >>>> >>>> This just scrolls for hours and hours... >>>> >>>> >>>> >>> You have a mislabled socket file in /var/run. >>> >>> restorecon -v /var/run/acpid.socket >>> ls -lZ /var/run/acpid.socket >>> srw-rw-rw- root root system_u:object_r:apmd_var_run_t /var/run/acpid.socket >>> >>> >>>> -Steve >>>> >>>> >> Uhhh, a bit more here: I get many 100s of these (while running latest >> rawhide, targeted/enforcing): >> ---- >> type=PATH msg=audit(12/25/2005 11:15:38.770:1619) : item=0 >> flags=follow inode=2142287 dev=fd:00 mode=socket,666 ouid=root >> ogid=root rdev=00:00 >> type=SOCKETCALL msg=audit(12/25/2005 11:15:38.770:1619) : nargs=3 a0=4 >> a1=bffabfb6 a2=6e >> type=SOCKADDR msg=audit(12/25/2005 11:15:38.770:1619) : saddr=local >> /var/run/acpid.socket >> type=AVC_PATH msg=audit(12/25/2005 11:15:38.770:1619) : >> path=/var/run/acpid.socket >> type=SYSCALL msg=audit(12/25/2005 11:15:38.770:1619) : arch=i386 >> syscall=socketcall(connect) success=no exit=-13(Permission denied) >> a0=3 a1=bffabf80 a2=4 a3=989d030 items=1 pid=2719 >> auid=unknown(4294967295) uid=root gid=root euid=root suid=root >> fsuid=root egid=root sgid=root fsgid=root comm=hald-addon-acpi >> exe=/usr/libexec/hald-addon-acpi >> type=AVC msg=audit(12/25/2005 11:15:38.770:1619) : avc: denied { >> connectto } for pid=2719 comm=hald-addon-acpi name=acpid.socket >> scontext=system_u:system_r:hald_t:s0 >> tcontext=system_u:system_r:crond_t:s0 tclass=unix_stream_socket >> ---- >> type=PATH msg=audit(12/25/2005 11:15:43.774:1620) : item=0 >> flags=follow inode=2142287 dev=fd:00 mode=socket,666 ouid=root >> ogid=root rdev=00:00 >> type=SOCKETCALL msg=audit(12/25/2005 11:15:43.774:1620) : nargs=3 a0=4 >> a1=bffabfb6 a2=6e >> type=SOCKADDR msg=audit(12/25/2005 11:15:43.774:1620) : saddr=local >> /var/run/acpid.socket >> type=AVC_PATH msg=audit(12/25/2005 11:15:43.774:1620) : >> path=/var/run/acpid.socket >> type=SYSCALL msg=audit(12/25/2005 11:15:43.774:1620) : arch=i386 >> syscall=socketcall(connect) success=no exit=-13(Permission denied) >> a0=3 a1=bffabf80 a2=4 a3=989d030 items=1 pid=2719 >> auid=unknown(4294967295) uid=root gid=root euid=root suid=root >> fsuid=root egid=root sgid=root fsgid=root comm=hald-addon-acpi >> exe=/usr/libexec/hald-addon-acpi >> type=AVC msg=audit(12/25/2005 11:15:43.774:1620) : avc: denied { >> connectto } for pid=2719 comm=hald-addon-acpi name=acpid.socket >> scontext=system_u:system_r:hald_t:s0 >> tcontext=system_u:system_r:crond_t:s0 tclass=unix_stream_socket >> >> Strange thing is, /var/run/acpid.socket is NOT labeled crond_t, but >> apmd_var_run_t: >> [root at tlondon ~]# ls -lZ /var/run/acpi* >> srw-rw-rw- root root system_u:object_r:apmd_var_run_t >> /var/run/acpid.socket >> [root at tlondon ~]# >> >> > A bit more on this: > > [root at tlondon ~]# ps gaxZ | grep crond_t > system_u:system_r:crond_t:SystemLow-SystemHigh 2639 ? Ss 0:00 crond > system_u:system_r:crond_t:SystemLow-SystemHigh 2656 ? Ss 0:00 /usr/sbin/atd > system_u:system_r:crond_t 4295 ? SNs 0:00 /usr/sbin/acpid > system_u:system_r:crond_t 4307 ? SNs 0:00 cupsd > [root at tlondon ~]# > > Should acpid and cupsd be running as crond_t? > > [root at tlondon ~]# ls -lZ /usr/sbin/acpid > -rwxr-x--- root root system_u:object_r:apmd_exec_t /usr/sbin/acpid > [root at tlondon ~]# ls -lZ /usr/sbin/cupsd > -rwxr-xr-x root root system_u:object_r:cupsd_exec_t /usr/sbin/cupsd > [root at tlondon ~]# > > Is there a missing transition (or some such)? > tom > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Fixed in selinux-policy-*-2.1.6-17.noarch.rpm -- From jbrindle at tresys.com Wed Dec 28 00:02:03 2005 From: jbrindle at tresys.com (Joshua Brindle) Date: Tue, 27 Dec 2005 19:02:03 -0500 Subject: SELinux Symposium Registration now open Message-ID: <43B1D5FB.403@tresys.com> The SELinux Symposium attendee registration is now open. For information on the symposium, the agenda, pricing and to register online please see the SELinux Symposium web page at http://selinux-symposium.org/. From linux_4ever at yahoo.com Wed Dec 28 15:25:53 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 28 Dec 2005 07:25:53 -0800 (PST) Subject: logwatch/pidof avcs Message-ID: <20051228152554.85533.qmail@web51507.mail.yahoo.com> Hi, I'm using today's rawhide and see these scroll occasionally: type=PATH msg=audit(12/28/2005 09:47:17.210:107) : item=0 name=/proc/2675/stat inode=175308814 dev=00:03 mode=file,444 ouid=root ogid=root rdev=00:00 obj=system_u:system_r:local_login_t:s0-s0:c0.c255 type=CWD msg=audit(12/28/2005 09:47:17.210:107) : cwd=/ type=SYSCALL msg=audit(12/28/2005 09:47:17.210:107) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=7fffffbaa110 a1=0 a2=1b6 a3=0 items=1 pid=3204 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=pidof exe=/sbin/killall5 subj=system_u:system_r:crond_t:s0 type=AVC msg=audit(12/28/2005 09:47:17.210:107) : avc: denied { read } for pid=3204 comm=pidof name=stat dev=proc ino=175308814 scontext=system_u:system_r:crond_t:s0 tcontext=system_u:system_r:local_login_t:s0-s0:c0.c255 tclass=file This occurs for a number of /prod/pid/stat entries. It appears to be coming from logwatch. -Steve __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From ejtr at layer3.co.uk Wed Dec 28 16:58:51 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Wed, 28 Dec 2005 16:58:51 +0000 Subject: Sun Java browser plugin fixup Message-ID: <1135789131.3070.37.camel@topaz.bugfinder.co.uk> SELinux strict policy: selinux-policy-strict-sources-1.27.1-2.16 has a problem with the Sun Java Plugin to Firefox in this RPM: jre-1.5.0_06-fcs.i586.rpm I'm reasonably sure that the SELinux policy used to work with the Sun Java 1.4.2 plugin. As best I can judge, an earlier SELinux policy upgrade broke the functionality; the issue only came to light when I upgraded and tested the later Java 1.5 RPM on my workstation. FWIW, Java 1.4.2 also breaks without the fixup. As best I can judge, no extra tweaks of boolean settings - with the possible exception of disable_mozilla_trans itself - provide an alternative fixup. My current boolean settings which appear to be Browser/Java relevant: [root at workstation policy]# getsebool -a | egrep 'content|mozilla|java| exec' | grep -v httpd allow_execmem --> active allow_execmod --> active allow_execstack --> inactive allow_java_execstack --> inactive allow_mplayer_execstack --> inactive cdrecord_read_content --> active disable_mozilla_trans --> inactive mail_read_content --> active mozilla_read_content --> inactive read_untrusted_content --> active write_untrusted_content --> active [root at workstation policy]# Using the test page at "http://javatester.org", I've tweaked my SELinux policy to stop it Firefox crashing when SELinux is enforcing. The fixup below allows the Firefox process itself to create this socket: /tmp/jpsock.150_06. and then let the Java VM process talk to it: [root at workstation misc]# tail -20 localpolicy.te ... # Java Socket problem fixup type_transition user_mozilla_t tmp_t:sock_file user_untrusted_content_tmp_t; allow user_mozilla_t { user_untrusted_content_tmp_t }:sock_file { read setattr getattr write unlink create }; auditallow user_mozilla_t { user_untrusted_content_tmp_t }:sock_file { read setattr getattr write unlink create }; allow user_mozilla_javaplugin_t { user_untrusted_content_tmp_t }:sock_file { read getattr write }; auditallow user_mozilla_javaplugin_t { user_untrusted_content_tmp_t }:sock_file { read getattr write }; .... Presumably a more complete macro fix would change either mozilla_domain itself: define(`mozilla_domain', ... ######### Java plugin ifdef(`java.te', ` type_transition $1_mozilla_t tmp_t:sock_file $1_untrusted_content_tmp_t; allow $1_mozilla_t { $1_untrusted_content_tmp_t }:sock_file { create getattr setattr read write unlink }; allow $1_mozilla_javaplugin_t { $1_untrusted_content_tmp_t }:sock_file { getattr read write }; javaplugin_domain($1_mozilla, $1) ') dnl java.te ... or the javaplugin_domain macro itself with: define(`javaplugin_domain',` ... type_transition $1_t tmp_t:sock_file $2_untrusted_content_tmp_t; allow $1_t { $2_untrusted_content_tmp_t }:sock_file { create getattr setattr read write unlink }; allow $1_javaplugin_t { $2_untrusted_content_tmp_t }:sock_file { getattr read write }; ... Ted Firefox startup and Java related messages: Dec 23 15:24:19 workstation kernel: audit(1135351459.515:529): avc: granted { create } for pid=6022 comm="firefox-bin" name="jpsock.150_06.6022" scontext=user_u:user_r:user_mozilla_t tcontext=user_u:object_r:user_untrusted_content_tmp_t tclass=sock_file Dec 23 15:24:19 workstation kernel: audit(1135351459.515:530): avc: granted { setattr } for pid=6022 comm="firefox-bin" name="jpsock.150_06.6022" dev=hda10 ino=33 scontext=user_u:user_r:user_mozilla_t tcontext=user_u:object_r:user_untrusted_content_tmp_t tclass=sock_file Dec 23 15:24:19 workstation kernel: audit(1135351459.551:531): avc: denied { execute } for pid=6042 comm="java_vm" name="classes.jsa" dev=hda6 ino=652990 scontext=user_u:user_r:user_mozilla_javaplugin_t tcontext=root:object_r:lib_t tclass=file Dec 23 15:24:20 workstation kernel: audit(1135351460.007:532): avc: denied { search } for pid=6042 comm="java_vm" name=".icons" dev=hda8 ino=323381 scontext=user_u:user_r:user_mozilla_javaplugin_t tcontext=user_u:object_r:user_home_t tclass=dir Dec 23 15:24:20 workstation kernel: audit(1135351460.007:533): avc: denied { search } for pid=6042 comm="java_vm" name=".icons" dev=hda8 ino=323381 scontext=user_u:user_r:user_mozilla_javaplugin_t tcontext=user_u:object_r:user_home_t tclass=dir Dec 23 15:24:20 workstation kernel: audit(1135351460.483:534): avc: granted { execmem } for pid=6022 comm="firefox-bin" scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_mozilla_t tclass=process Dec 23 15:24:20 workstation kernel: audit(1135351460.487:535): avc: granted { write } for pid=6042 comm="java_vm" name="jpsock.150_06.6022" dev=hda10 ino=33 scontext=user_u:user_r:user_mozilla_javaplugin_t tcontext=user_u:object_r:user_untrusted_content_tmp_t tclass=sock_file Dec 23 15:24:20 workstation kernel: audit(1135351460.655:536): avc: denied { search } for pid=6042 comm="java_vm" name=".icons" dev=hda8 ino=323381 scontext=user_u:user_r:user_mozilla_javaplugin_t tcontext=user_u:object_r:user_home_t tclass=dir Dec 23 15:24:20 workstation kernel: audit(1135351460.655:537): avc: denied { search } for pid=6042 comm="java_vm" name=".icons" dev=hda8 ino=323381 scontext=user_u:user_r:user_mozilla_javaplugin_t tcontext=user_u:object_r:user_home_t tclass=dir Dec 23 15:24:23 workstation kernel: audit(1135351463.767:538): avc: denied { listen } for pid=6064 comm="java_vm" scontext=user_u:user_r:user_mozilla_javaplugin_t tcontext=user_u:user_r:user_mozilla_javaplugin_t tclass=tcp_socket -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From justin.conover at gmail.com Thu Dec 29 16:24:23 2005 From: justin.conover at gmail.com (Justin Conover) Date: Thu, 29 Dec 2005 10:24:23 -0600 Subject: reiser4 +selinux Message-ID: Does anyone know if reiser4 has the XATTRs added to handle selinux now? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Fri Dec 30 16:03:23 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 30 Dec 2005 11:03:23 -0500 Subject: logwatch/pidof avcs In-Reply-To: <20051228152554.85533.qmail@web51507.mail.yahoo.com> References: <20051228152554.85533.qmail@web51507.mail.yahoo.com> Message-ID: <43B55A4B.7080705@redhat.com> Steve G wrote: > Hi, > > I'm using today's rawhide and see these scroll occasionally: > > type=PATH msg=audit(12/28/2005 09:47:17.210:107) : item=0 name=/proc/2675/stat > inode=175308814 dev=00:03 mode=file,444 ouid=root ogid=root rdev=00:00 > obj=system_u:system_r:local_login_t:s0-s0:c0.c255 > type=CWD msg=audit(12/28/2005 09:47:17.210:107) : cwd=/ > type=SYSCALL msg=audit(12/28/2005 09:47:17.210:107) : arch=x86_64 syscall=open > success=no exit=-13(Permission denied) a0=7fffffbaa110 a1=0 a2=1b6 a3=0 items=1 > pid=3204 auid=unknown(4294967295) uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root comm=pidof exe=/sbin/killall5 > subj=system_u:system_r:crond_t:s0 > type=AVC msg=audit(12/28/2005 09:47:17.210:107) : avc: denied { read } for > pid=3204 comm=pidof name=stat dev=proc ino=175308814 > scontext=system_u:system_r:crond_t:s0 > tcontext=system_u:system_r:local_login_t:s0-s0:c0.c255 tclass=file > > This occurs for a number of /prod/pid/stat entries. It appears to be coming from > logwatch. > > -Steve > > > I have added a logwatch policy. Do you know what logwatch is trying to do? Does it need this capability? This is caused because of MCS. Basically a s0 process is trying to read a s0-s0:co.c255 file. Dan > > > __________________________________ > Yahoo! for Good - Make a difference this year. > http://brand.yahoo.com/cybergivingweek2005/ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From dwalsh at redhat.com Fri Dec 30 16:20:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 30 Dec 2005 11:20:24 -0500 Subject: logwatch 7 breakage In-Reply-To: <1134982581.3035.13.camel@topaz.bugfinder.co.uk> References: <1134982581.3035.13.camel@topaz.bugfinder.co.uk> Message-ID: <43B55E48.1080305@redhat.com> Ted Rule wrote: > Version 7 of logwatch includes a major restructure of its directory > layout compared to version 6. > > For SELinux enforcing machines, there are 2 problems; scripts have moved > from /etc/log.d/scripts to /usr/share/logwatch/scripts, and temporary > file creation has moved to /var/cache/logwatch. > > It seems that version 6 worked by dint of Cron already having sufficient > SELinux permissions to /etc and /tmp; logwatch has no domain of its own. > > I've added a couple of tweaks to my local strict policy as shown below, > which seem to cover off its requirements for both Cron'ed and Manual > invocations. > > > TE .... > > # Allow Cron and Sudo invocations of logwatch to create temporary files > type logwatch_tmp_t, file_type, sysadmfile, tmpfile; > allow system_crond_t logwatch_tmp_t:file create_file_perms; > allow system_crond_t logwatch_tmp_t:dir create_dir_perms; > allow sysadm_t logwatch_tmp_t:file create_file_perms; > allow sysadm_t logwatch_tmp_t:dir create_dir_perms; > > FC .... > > # Executable scripts belonging to the logwatch package outside > of /usr/sbin > /usr/share/logwatch/scripts/logwatch.pl -- system_u:object_r:sbin_t > > # Logwatch version 7 temporary spool area > /var/cache/logwatch(/.*)? system_u:object_r:logwatch_tmp_t > > > > Added logwatch policy which should handle this. -- From linux_4ever at yahoo.com Sat Dec 31 13:45:52 2005 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 31 Dec 2005 05:45:52 -0800 (PST) Subject: selinux policy upgrade avcs Message-ID: <20051231134552.69649.qmail@web51514.mail.yahoo.com> Hi, When yum updates my rawhide policy, I get these avcs: type=PATH msg=audit(12/29/2005 08:26:52.659:120) : item=0 name=/etc/mtab inode=11403372 dev=03:07 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:etc_runtime_t:s0 type=CWD msg=audit(12/29/2005 08:26:52.659:120) : cwd=/ type=SYSCALL msg=audit(12/29/2005 08:26:52.659:120) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=3446313756 a1=0 a2=1b6 a3=0 items=1 pid=2472 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty1 comm=load_policy exe=/usr/sbin/load_policy subj=root:system_r:load_policy_t:s0-s0:c0.c255 type=AVC msg=audit(12/29/2005 08:26:52.659:120) : avc: denied { read } for pid=2472 comm=load_policy name=mtab dev=hda7 ino=11403372 scontext=root:system_r:load_policy_t:s0-s0:c0.c255 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file -Steve __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From linux_4ever at yahoo.com Sat Dec 31 13:48:20 2005 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 31 Dec 2005 05:48:20 -0800 (PST) Subject: logwatch/pidof avcs In-Reply-To: <43B55A4B.7080705@redhat.com> Message-ID: <20051231134820.8732.qmail@web51506.mail.yahoo.com> >Do you know what logwatch is trying to do? Not offhand. I'll look through it. Its probably buried inside some perl stuff. I'll see if I can find the exact spot that's doing this. -Steve __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From tdiehl at rogueind.com Sat Dec 31 17:36:17 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sat, 31 Dec 2005 12:36:17 -0500 (EST) Subject: Selinux warning? Message-ID: Hi all, I have an EL4 box that every time I do su - vmail I get the following warnings in the log: Dec 31 12:25:22 roger su(pam_unix)[2055]: session opened for user vmail by root(uid=0) Dec 31 12:25:22 roger su[2055]: Warning! Could not relabel /dev/pts/3 with user_u:object_r:initrc_devpts_t, not relabeling.Operation not permitted This started after I changed the UID in /etc/passwd and the gid in /etc/group. (roger pts4) # ll -Z /dev/pts/3 crw------- root tty root:object_r:initrc_devpts_t /dev/pts/3 (roger pts4) # Is there something that needs to be done for selinux when I change a u/gid?? Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com