From chepkov at yahoo.com Tue Nov 3 16:14:20 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Tue, 3 Nov 2009 08:14:20 -0800 (PST) Subject: Selinux and Reviewboard Message-ID: <476552.68248.qm@web36804.mail.mud.yahoo.com> Hi, I am trying to install ReviewBoard (www.reviewboard.org) on selinux enabled server and there are a lot of problems so far. I wonder if anybody have the policy they could share. I got to the point where I get these: time->Tue Nov 3 16:06:41 2009 type=SYSCALL msg=audit(1257264401.953:9042): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=20d4b0 a2=5 a3=802 items=0 ppid=3448 pid=3450 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=user_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1257264401.953:9042): avc: denied { execute } for pid=3450 comm="httpd" path="/var/www/reviews/tmp/egg_cache/MySQL_python-1.2.3c1-py2.4-linux-x86_64.egg-tmp/_mysql.so" dev=sda1 ino=378349 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Tue Nov 3 16:06:41 2009 type=SYSCALL msg=audit(1257264401.553:9041): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=205848 a2=5 a3=802 items=0 ppid=3448 pid=3450 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=user_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1257264401.553:9041): avc: denied { execute } for pid=3450 comm="httpd" path="/var/www/reviews/tmp/egg_cache/cmemcache-0.95-py2.4-linux-x86_64.egg-tmp/_cmemcache.so" dev=sda1 ino=378290 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file As far as I understand the code creates dynamic libraries which it tries to execute later. I obviously need to handle this carefully, so I need an expert advise. Thank you. Sincerely yours, Vadym Chepkov From dwalsh at redhat.com Wed Nov 4 14:43:21 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 04 Nov 2009 09:43:21 -0500 Subject: Selinux and Reviewboard In-Reply-To: <476552.68248.qm@web36804.mail.mud.yahoo.com> References: <476552.68248.qm@web36804.mail.mud.yahoo.com> Message-ID: <4AF19309.7060500@redhat.com> On 11/03/2009 11:14 AM, Vadym Chepkov wrote: > Hi, > > I am trying to install ReviewBoard (www.reviewboard.org) on selinux enabled server and there are a lot of problems so far. I wonder if anybody have the policy they could share. I got to the point where I get these: > > time->Tue Nov 3 16:06:41 2009 > type=SYSCALL msg=audit(1257264401.953:9042): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=20d4b0 a2=5 a3=802 items=0 ppid=3448 pid=3450 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=user_u:system_r:httpd_t:s0 key=(null) > type=AVC msg=audit(1257264401.953:9042): avc: denied { execute } for pid=3450 comm="httpd" path="/var/www/reviews/tmp/egg_cache/MySQL_python-1.2.3c1-py2.4-linux-x86_64.egg-tmp/_mysql.so" dev=sda1 ino=378349 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > ---- > time->Tue Nov 3 16:06:41 2009 > type=SYSCALL msg=audit(1257264401.553:9041): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=205848 a2=5 a3=802 items=0 ppid=3448 pid=3450 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=user_u:system_r:httpd_t:s0 key=(null) > type=AVC msg=audit(1257264401.553:9041): avc: denied { execute } for pid=3450 comm="httpd" path="/var/www/reviews/tmp/egg_cache/cmemcache-0.95-py2.4-linux-x86_64.egg-tmp/_cmemcache.so" dev=sda1 ino=378290 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > > As far as I understand the code creates dynamic libraries which it tries to execute later. I obviously need to handle this carefully, so I need an expert advise. Thank you. > > Sincerely yours, > Vadym Chepkov > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > This looks like it was created in /tmp and mv'd to this directory? The label of this directory should be /var/www/reviews/tmp/egg_cache/MySQL_python-1.2.3c1-py2.4-linux-x86_64.egg-tmp/_mysql.so # /usr/sbin/matchpathcon /var/www/reviews/tmp/egg_cache/MySQL_python-1.2.3c1-py2.4-linux-x86_64.egg-tmp/_mysql.so /var/www/reviews/tmp/egg_cache/MySQL_python-1.2.3c1-py2.4-linux-x86_64.egg-tmp/_mysql.so system_u:object_r:httpd_sys_content_t:s0 It should definitely not be tmp_t. From olivares14031 at yahoo.com Wed Nov 4 21:19:50 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 4 Nov 2009 13:19:50 -0800 (PST) Subject: Oopps, sealert hit an error! :( Message-ID: <919262.48914.qm@web52601.mail.re2.yahoo.com> I see the following Opps, sealert hit an error! Traceback (most recent call last): File "/usr/bin/sealert", line 970, in run_as_dbus_service(username) File "/usr/bin/sealert", line 97, in run_as_dbus_service app = SEAlert(user, dbus_service.presentation_manager, watch_setroubleshootd=True) File "/usr/bin/sealert", line 616, in __init__ self.browser = BrowserApplet(self.username, self.alert_client) File "/usr/lib/python2.6/site-packages/setroubleshoot/browser.py", line 404, in __init__ self.check_policy() File "/usr/lib/python2.6/site-packages/setroubleshoot/browser.py", line 448, in check_policy pl = yb.doPackageLists(patterns=['selinux-policy']) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1759, in doPackageLists avail = self.pkgSack.returnNewestByNameArch(patterns=patterns, File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 720, in pkgSack = property(fget=lambda self: self._getSacks(), File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 549, in _getSacks self.repos.populateSack(which=repos) File "/usr/lib/python2.6/site-packages/yum/repos.py", line 277, in populateSack sack.populate(repo, mdtype, callback, cacheonly) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 187, in populate dobj = repo_cache_function(xml, csum) File "/usr/lib/python2.6/site-packages/sqlitecachec.py", line 46, in getPrimary self.repoid)) TypeError: Can not open SQL database: unable to open database file Thanks, Antonio From dwalsh at redhat.com Mon Nov 9 22:44:22 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 Nov 2009 17:44:22 -0500 Subject: Oopps, sealert hit an error! :( In-Reply-To: <919262.48914.qm@web52601.mail.re2.yahoo.com> References: <919262.48914.qm@web52601.mail.re2.yahoo.com> Message-ID: <4AF89B46.2000403@redhat.com> On 11/04/2009 04:19 PM, Antonio Olivares wrote: > I see the following > > Opps, sealert hit an error! > > Traceback (most recent call last): > File "/usr/bin/sealert", line 970, in > run_as_dbus_service(username) > File "/usr/bin/sealert", line 97, in run_as_dbus_service > app = SEAlert(user, dbus_service.presentation_manager, watch_setroubleshootd=True) > File "/usr/bin/sealert", line 616, in __init__ > self.browser = BrowserApplet(self.username, self.alert_client) > File "/usr/lib/python2.6/site-packages/setroubleshoot/browser.py", line 404, in __init__ > self.check_policy() > File "/usr/lib/python2.6/site-packages/setroubleshoot/browser.py", line 448, in check_policy > pl = yb.doPackageLists(patterns=['selinux-policy']) > File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1759, in doPackageLists > avail = self.pkgSack.returnNewestByNameArch(patterns=patterns, > File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 720, in > pkgSack = property(fget=lambda self: self._getSacks(), > File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 549, in _getSacks > self.repos.populateSack(which=repos) > File "/usr/lib/python2.6/site-packages/yum/repos.py", line 277, in populateSack > sack.populate(repo, mdtype, callback, cacheonly) > File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 187, in populate > dobj = repo_cache_function(xml, csum) > File "/usr/lib/python2.6/site-packages/sqlitecachec.py", line 46, in getPrimary > self.repoid)) > TypeError: Can not open SQL database: unable to open database file > > > Thanks, > > Antonio > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Something is wrong with your yum setup? From joliver at john-oliver.net Mon Nov 9 23:27:04 2009 From: joliver at john-oliver.net (John Oliver) Date: Mon, 9 Nov 2009 15:27:04 -0800 Subject: semodule: Failed! Message-ID: <20091109232704.GA4290@ns.sdsitehosting.net> [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | audit2allow #============= nagios_t ============== allow nagios_t var_t:dir read; [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | audit2allow -M nagios ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i nagios.pp [root at mda-services4 ~]# semodule -i nagios.pp libsepol.print_missing_requirements: nagios's global requirements were not met: type/attribute nagios_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! What on Earth does that mean??? -- *********************************************************************** * John Oliver http://www.john-oliver.net/ * * * *********************************************************************** From domg472 at gmail.com Tue Nov 10 13:51:49 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 10 Nov 2009 14:51:49 +0100 Subject: semodule: Failed! In-Reply-To: <20091109232704.GA4290@ns.sdsitehosting.net> References: <20091109232704.GA4290@ns.sdsitehosting.net> Message-ID: <1257861109.2663.12.camel@localhost> On Mon, 2009-11-09 at 15:27 -0800, John Oliver wrote: > [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | > audit2allow > > > #============= nagios_t ============== > allow nagios_t var_t:dir read; > [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | > audit2allow -M nagios > ******************** IMPORTANT *********************** > To make this policy package active, execute: > > semodule -i nagios.pp > > [root at mda-services4 ~]# semodule -i nagios.pp > libsepol.print_missing_requirements: nagios's global requirements were > not met: type/attribute nagios_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > > > What on Earth does that mean??? > It means you (probably) did something that is not so smart: My guess is that you have overwritten the distributed nagios module. I think that, because you show me this: semodule -i nagios.pp And i assume you have probably did that before. The problem is that you are trying to install (and have been installing) a custom module with the same name of a distributed module: [root at notebook3 admin]# semodule -l | grep nagios nagios 1.8.0 In simple human language: You have overwritten the nagios module that came with you distribution with a custom nagios module. To undo this, either for a update of selinux-policy and selinux-policy (this should overwrite you custom nagios module with the one that comes with your distribution) or you can just install the distribution nagios modules from: [root at notebook3 admin]# ls /usr/share/selinux/targeted | grep nagios nagios.pp.bz2 The lesson to be learned from this experience is: If you decide to install a custom module; then make sure that you give it a unigue name (for example: grep nagios /var/log/audit/audit.log | audit2allow -M mynagios; semodule -i mynagios.pp) Because if there is already a module installed by that name you will overwrite it. From joliver at john-oliver.net Tue Nov 10 19:17:16 2009 From: joliver at john-oliver.net (John Oliver) Date: Tue, 10 Nov 2009 11:17:16 -0800 Subject: semodule: Failed! In-Reply-To: <1257861109.2663.12.camel@localhost> References: <20091109232704.GA4290@ns.sdsitehosting.net> <1257861109.2663.12.camel@localhost> Message-ID: <20091110191716.GA7466@ns.sdsitehosting.net> On Tue, Nov 10, 2009 at 02:51:49PM +0100, Dominick Grift wrote: > On Mon, 2009-11-09 at 15:27 -0800, John Oliver wrote: > > [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | > > audit2allow > > > > > > #============= nagios_t ============== > > allow nagios_t var_t:dir read; > > [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | > > audit2allow -M nagios > > ******************** IMPORTANT *********************** > > To make this policy package active, execute: > > > > semodule -i nagios.pp > > > > [root at mda-services4 ~]# semodule -i nagios.pp > > libsepol.print_missing_requirements: nagios's global requirements were > > not met: type/attribute nagios_t > > libsemanage.semanage_link_sandbox: Link packages failed > > semodule: Failed! > > > > > > > > What on Earth does that mean??? > > > It means you (probably) did something that is not so smart: > > My guess is that you have overwritten the distributed nagios module. Ahh! Actually, the distributed module wasn't installed at all, as nagios was installed after the fact. So, I removed mine and added the distributed one, and nagios will start. However, there's still at least one rule missing from the distributed module (and yes, I updated the selinux related RPMs): type=AVC msg=audit(1257880340.235:135261): avc: denied { read write } for pid=15599 comm="ping" path="/var/nagios/spool/checkresults/checkemlez9" dev=dm-0 ino=196622 scontext=user_u:system_r:ping_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file [root at mda-services4 ~]# tail -50 /var/log/audit/audit.log | grep nagios | audit2allow #============= ping_t ============== allow ping_t var_t:file { read write }; libselinux-1.33.4-5.5.el5 libselinux-utils-1.33.4-5.5.el5 selinux-policy-2.4.6-255.el5_4.1 libselinux-python-1.33.4-5.5.el5 selinux-policy-targeted-2.4.6-255.el5_4.1 -- *********************************************************************** * John Oliver http://www.john-oliver.net/ * * * *********************************************************************** From domg472 at gmail.com Tue Nov 10 19:44:55 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 10 Nov 2009 20:44:55 +0100 Subject: semodule: Failed! In-Reply-To: <20091110191716.GA7466@ns.sdsitehosting.net> References: <20091109232704.GA4290@ns.sdsitehosting.net> <1257861109.2663.12.camel@localhost> <20091110191716.GA7466@ns.sdsitehosting.net> Message-ID: <1257882295.21107.8.camel@localhost> On Tue, 2009-11-10 at 11:17 -0800, John Oliver wrote: > On Tue, Nov 10, 2009 at 02:51:49PM +0100, Dominick Grift wrote: > > On Mon, 2009-11-09 at 15:27 -0800, John Oliver wrote: > > > [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | > > > audit2allow > > > > > > > > > #============= nagios_t ============== > > > allow nagios_t var_t:dir read; > > > [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | > > > audit2allow -M nagios > > > ******************** IMPORTANT *********************** > > > To make this policy package active, execute: > > > > > > semodule -i nagios.pp > > > > > > [root at mda-services4 ~]# semodule -i nagios.pp > > > libsepol.print_missing_requirements: nagios's global requirements were > > > not met: type/attribute nagios_t > > > libsemanage.semanage_link_sandbox: Link packages failed > > > semodule: Failed! > > > > > > > > > > > > What on Earth does that mean??? > > > > > It means you (probably) did something that is not so smart: > > > > My guess is that you have overwritten the distributed nagios module. > > Ahh! > > Actually, the distributed module wasn't installed at all, as nagios was > installed after the fact. So, I removed mine and added the distributed > one, and nagios will start. However, there's still at least one rule > missing from the distributed module (and yes, I updated the selinux > related RPMs): > > type=AVC msg=audit(1257880340.235:135261): avc: denied { read write } > for pid=15599 comm="ping" > path="/var/nagios/spool/checkresults/checkemlez9" dev=dm-0 ino=196622 > scontext=user_u:system_r:ping_t:s0 tcontext=user_u:object_r:var_t:s0 > tclass=file > [root at mda-services4 ~]# tail -50 /var/log/audit/audit.log | grep nagios > | audit2allow > > > #============= ping_t ============== > allow ping_t var_t:file { read write }; > > > libselinux-1.33.4-5.5.el5 > libselinux-utils-1.33.4-5.5.el5 > selinux-policy-2.4.6-255.el5_4.1 > libselinux-python-1.33.4-5.5.el5 > selinux-policy-targeted-2.4.6-255.el5_4.1 > Yes i bet the nagios policy is full of bugs. A quick workaround to solve this issue is to label /var/nagios/spool/ type nagios_spool_t and then use audit2allow to allow ping rw nagios_spool_t files: echo "policy_module(mynagiospatch1, 0.0.1)" > mynagiospatch1.te echo "require { type nagios_spool_t, ping_t; }" >> mynagiospatch1.te echo "allow ping_t nagios_spool_t:file rw_file_perms;" >> mynagiospatch1.te echo "/var/nagios/spool(/.*)? gen_context(system_u:object_r:nagios_spool_t, s0)" >> mynagiospatch1.te make -f /usr/share/selinux/devel/Makefile mynagiospatch1.pp semodule -i mynagiospatch1.pp restorecon -R -v /var/nagios/spool Note that this is a ugly workaround and it should be deinstalled as soon as a solution is implemented in fedora policy (please report a bug) My guess is that after this you will probably get more denials. hth From dwalsh at redhat.com Tue Nov 10 19:58:21 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 10 Nov 2009 14:58:21 -0500 Subject: semodule: Failed! In-Reply-To: <1257882295.21107.8.camel@localhost> References: <20091109232704.GA4290@ns.sdsitehosting.net> <1257861109.2663.12.camel@localhost> <20091110191716.GA7466@ns.sdsitehosting.net> <1257882295.21107.8.camel@localhost> Message-ID: <4AF9C5DD.9080207@redhat.com> On 11/10/2009 02:44 PM, Dominick Grift wrote: > On Tue, 2009-11-10 at 11:17 -0800, John Oliver wrote: >> On Tue, Nov 10, 2009 at 02:51:49PM +0100, Dominick Grift wrote: >>> On Mon, 2009-11-09 at 15:27 -0800, John Oliver wrote: >>>> [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | >>>> audit2allow >>>> >>>> >>>> #============= nagios_t ============== >>>> allow nagios_t var_t:dir read; >>>> [root at mda-services4 ~]# grep nagios /var/log/audit/audit.log | >>>> audit2allow -M nagios >>>> ******************** IMPORTANT *********************** >>>> To make this policy package active, execute: >>>> >>>> semodule -i nagios.pp >>>> >>>> [root at mda-services4 ~]# semodule -i nagios.pp >>>> libsepol.print_missing_requirements: nagios's global requirements were >>>> not met: type/attribute nagios_t >>>> libsemanage.semanage_link_sandbox: Link packages failed >>>> semodule: Failed! >>>> >>>> >>>> >>>> What on Earth does that mean??? >>>> >>> It means you (probably) did something that is not so smart: >>> >>> My guess is that you have overwritten the distributed nagios module. >> >> Ahh! >> >> Actually, the distributed module wasn't installed at all, as nagios was >> installed after the fact. So, I removed mine and added the distributed >> one, and nagios will start. However, there's still at least one rule >> missing from the distributed module (and yes, I updated the selinux >> related RPMs): >> >> type=AVC msg=audit(1257880340.235:135261): avc: denied { read write } >> for pid=15599 comm="ping" >> path="/var/nagios/spool/checkresults/checkemlez9" dev=dm-0 ino=196622 >> scontext=user_u:system_r:ping_t:s0 tcontext=user_u:object_r:var_t:s0 >> tclass=file >> [root at mda-services4 ~]# tail -50 /var/log/audit/audit.log | grep nagios >> | audit2allow >> >> >> #============= ping_t ============== >> allow ping_t var_t:file { read write }; >> >> >> libselinux-1.33.4-5.5.el5 >> libselinux-utils-1.33.4-5.5.el5 >> selinux-policy-2.4.6-255.el5_4.1 >> libselinux-python-1.33.4-5.5.el5 >> selinux-policy-targeted-2.4.6-255.el5_4.1 >> > Yes i bet the nagios policy is full of bugs. > > A quick workaround to solve this issue is to label /var/nagios/spool/ > type nagios_spool_t and then use audit2allow to allow ping rw > nagios_spool_t files: > > echo "policy_module(mynagiospatch1, 0.0.1)" > mynagiospatch1.te > echo "require { type nagios_spool_t, ping_t; }" >> mynagiospatch1.te > echo "allow ping_t nagios_spool_t:file rw_file_perms;" >> > mynagiospatch1.te > echo "/var/nagios/spool(/.*)? > gen_context(system_u:object_r:nagios_spool_t, s0)" >> mynagiospatch1.te > make -f /usr/share/selinux/devel/Makefile mynagiospatch1.pp > semodule -i mynagiospatch1.pp > restorecon -R -v /var/nagios/spool > > Note that this is a ugly workaround and it should be deinstalled as soon > as a solution is implemented in fedora policy (please report a bug) > > My guess is that after this you will probably get more denials. > > hth > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Why is nagios using /var/nagios/spool instead of /var/spool/nagios? From domg472 at gmail.com Tue Nov 10 21:05:59 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 10 Nov 2009 22:05:59 +0100 Subject: idea: customizable_types.local Message-ID: <1257887159.11014.6.camel@localhost> Now we have restorecond -u running and it can be a pain. especially for people that write their own custom modules. for example i have a backup script that can write anywhere in user_home_t. be it ~ or ~/Downloads. It write the backups with a special type, But restorecond -u resets it to user_home_t even before its finished writing ;) Here comes customizable_types in. This can be used to add the type to it so that restorecond -u doesnt try to reset it. Thats cool, but what if you update your selinux policy? will customizable_types be overwritten? Maybe it would be good to have a customizable_types.local so that you can add your customizable types there and not have to worry about policy updates or restorecond -u. What do you think about this idea? From Moray.Henderson at ict.om.org Wed Nov 11 12:09:14 2009 From: Moray.Henderson at ict.om.org (Moray Henderson (ICT)) Date: Wed, 11 Nov 2009 12:09:14 +0000 Subject: idea: customizable_types.local In-Reply-To: <1257887159.11014.6.camel@localhost> References: <1257887159.11014.6.camel@localhost> Message-ID: <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> Dominick Wrote: >Now we have restorecond -u running and it can be a pain. especially for >people that write their own custom modules. > >for example i have a backup script that can write anywhere in >user_home_t. be it ~ or ~/Downloads. > >It write the backups with a special type, But restorecond -u resets it >to user_home_t even before its finished writing ;) > >Here comes customizable_types in. This can be used to add the type to it >so that restorecond -u doesnt try to reset it. > >Thats cool, but what if you update your selinux policy? will >customizable_types be overwritten? Maybe it would be good to have a >customizable_types.local so that you can add your customizable types >there and not have to worry about policy updates or restorecond -u. > >What do you think about this idea? I remember how I discovered customizable_types in the first place - I wanted files to be reset from their old setting to the new one, and the command that was supposed to do it updated every file except the ones I particularly needed. I had set everything correctly in file_contexts - then eventually discovered that there was *another* file that told the system to disregard file_contexts for certain file contexts. I remember thinking - WHY? Isn't file_contexts supposed to be the place where you configure file contexts? Call me old-fashioned, but as a solution for your problem, I would recommend adding file context instructions to your policy so that restorecond sets your backup files to the correct context. Adding a new customizable file may sound like a neat solution, but in practice it would mean that someone trying to debug "Why doesn't this file have the right context?" now has to know about three different places that the problem might be coming from. By the way, I also agree with Matthew Ife's thread from last month about the need for good, practical documentation on how to use SELinux in real system administration rather than conceptual theory. It's especially important for those who learned the theory under an older version, but need to do things with the new. I had such a struggle with customizable_types because it wasn't there in RHEL 4. Moray. "To err is human. To purr, feline" From domg472 at gmail.com Wed Nov 11 12:28:31 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 11 Nov 2009 13:28:31 +0100 Subject: idea: customizable_types.local In-Reply-To: <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> References: <1257887159.11014.6.camel@localhost> <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> Message-ID: <20091111122830.GA3590@notebook3.grift.internal> On Wed, Nov 11, 2009 at 12:09:14PM +0000, Moray Henderson (ICT) wrote: > Dominick Wrote: > >Now we have restorecond -u running and it can be a pain. especially for > >people that write their own custom modules. > > > >for example i have a backup script that can write anywhere in > >user_home_t. be it ~ or ~/Downloads. > > > >It write the backups with a special type, But restorecond -u resets it > >to user_home_t even before its finished writing ;) > > > >Here comes customizable_types in. This can be used to add the type to it > >so that restorecond -u doesnt try to reset it. > > > >Thats cool, but what if you update your selinux policy? will > >customizable_types be overwritten? Maybe it would be good to have a > >customizable_types.local so that you can add your customizable types > >there and not have to worry about policy updates or restorecond -u. > > > >What do you think about this idea? > > I remember how I discovered customizable_types in the first place - I wanted files to be reset from their old setting to the new one, and the command that was supposed to do it updated every file except the ones I particularly needed. I had set everything correctly in file_contexts - then eventually discovered that there was *another* file that told the system to disregard file_contexts for certain file contexts. I remember thinking - WHY? Isn't file_contexts supposed to be the place where you configure file contexts? > > Call me old-fashioned, but as a solution for your problem, I would recommend adding file context instructions to your policy so that restorecond sets your backup files to the correct context. That is just the issue. Sometimes it is not feasible or sometimes its not possible to add a context specification. For example the name of you backup file is changable and also its location. You might call it backup.tgz and store it in ~ or call it bla.tgz and store it in ~/Documents (just an example. Same goes for example what if you have a irc client confined and it has dcc enable and you download a file to a random location in $home? Another example is kismet, it will store logs where ever you start it. So if you start it in ~ it will (try to) put the logs there. So lets say you allow kistmet to manage files with kismet_home_t in user_home_t, Run kismet and it starts logging to ~, along comes restorecond -u and resets the contexts of the logs to user_home_t (to which kismet incidentally cannot write/append) > > Adding a new customizable file may sound like a neat solution, but in practice it would mean that someone trying to debug "Why doesn't this file have the right context?" now has to know about three different places that the problem might be coming from. > > By the way, I also agree with Matthew Ife's thread from last month about the need for good, practical documentation on how to use SELinux in real system administration rather than conceptual theory. It's especially important for those who learned the theory under an older version, but need to do things with the new. I had such a struggle with customizable_types because it wasn't there in RHEL 4. > > > Moray. > "To err is human. To purr, feline" > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Wed Nov 11 12:41:02 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 11 Nov 2009 13:41:02 +0100 Subject: idea: customizable_types.local In-Reply-To: <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> References: <1257887159.11014.6.camel@localhost> <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> Message-ID: <20091111124102.GB3590@notebook3.grift.internal> On Wed, Nov 11, 2009 at 12:09:14PM +0000, Moray Henderson (ICT) wrote: > Dominick Wrote: > >Now we have restorecond -u running and it can be a pain. especially for > >people that write their own custom modules. > > > >for example i have a backup script that can write anywhere in > >user_home_t. be it ~ or ~/Downloads. > > > >It write the backups with a special type, But restorecond -u resets it > >to user_home_t even before its finished writing ;) > > > >Here comes customizable_types in. This can be used to add the type to it > >so that restorecond -u doesnt try to reset it. > > > >Thats cool, but what if you update your selinux policy? will > >customizable_types be overwritten? Maybe it would be good to have a > >customizable_types.local so that you can add your customizable types > >there and not have to worry about policy updates or restorecond -u. > > > >What do you think about this idea? > > I remember how I discovered customizable_types in the first place - I wanted files to be reset from their old setting to the new one, and the command that was supposed to do it updated every file except the ones I particularly needed. I had set everything correctly in file_contexts - then eventually discovered that there was *another* file that told the system to disregard file_contexts for certain file contexts. I remember thinking - WHY? Isn't file_contexts supposed to be the place where you configure file contexts? > > Call me old-fashioned, but as a solution for your problem, I would recommend adding file context instructions to your policy so that restorecond sets your backup files to the correct context. > > Adding a new customizable file may sound like a neat solution, but in practice it would mean that someone trying to debug "Why doesn't this file have the right context?" now has to know about three different places that the problem might be coming from. > > By the way, I also agree with Matthew Ife's thread from last month about the need for good, practical documentation on how to use SELinux in real system administration rather than conceptual theory. It's especially important for those who learned the theory under an older version, but need to do things with the new. I had such a struggle with customizable_types because it wasn't there in RHEL 4. > So i have been thinking about for example: semanage customizable -a -t irssi_home_t $ semanage customizable -l irssi_home_t kismet_home_t mybackup_script_home_t semanage customizable -d -t irssi_home_t > > Moray. > "To err is human. To purr, feline" > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Wed Nov 11 12:51:06 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 11 Nov 2009 13:51:06 +0100 Subject: idea: customizable_types.local In-Reply-To: <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> References: <1257887159.11014.6.camel@localhost> <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> Message-ID: <20091111125106.GC3590@notebook3.grift.internal> On Wed, Nov 11, 2009 at 12:09:14PM +0000, Moray Henderson (ICT) wrote: > Dominick Wrote: > >Now we have restorecond -u running and it can be a pain. especially for > >people that write their own custom modules. > > > >for example i have a backup script that can write anywhere in > >user_home_t. be it ~ or ~/Downloads. > > > >It write the backups with a special type, But restorecond -u resets it > >to user_home_t even before its finished writing ;) > > > >Here comes customizable_types in. This can be used to add the type to it > >so that restorecond -u doesnt try to reset it. > > > >Thats cool, but what if you update your selinux policy? will > >customizable_types be overwritten? Maybe it would be good to have a > >customizable_types.local so that you can add your customizable types > >there and not have to worry about policy updates or restorecond -u. > > > >What do you think about this idea? > > I remember how I discovered customizable_types in the first place - I wanted files to be reset from their old setting to the new one, and the command that was supposed to do it updated every file except the ones I particularly needed. I had set everything correctly in file_contexts - then eventually discovered that there was *another* file that told the system to disregard file_contexts for certain file contexts. I remember thinking - WHY? Isn't file_contexts supposed to be the place where you configure file contexts? > > Call me old-fashioned, but as a solution for your problem, I would recommend adding file context instructions to your policy so that restorecond sets your backup files to the correct context. > > Adding a new customizable file may sound like a neat solution, but in practice it would mean that someone trying to debug "Why doesn't this file have the right context?" now has to know about three different places that the problem might be coming from. I can also use this argument to my advantage: What if i have a policy that allows some domain to manage a file in user_home_t with its own type (example blah_home_t). I start the confined domain and notice that any file created by it has user_home_t (instead of blah_home_t), whilst i implicitly defined a type transition. I would expect the file to have the type that i defined and not user_home_t. That is confusing as well. > > By the way, I also agree with Matthew Ife's thread from last month about the need for good, practical documentation on how to use SELinux in real system administration rather than conceptual theory. It's especially important for those who learned the theory under an older version, but need to do things with the new. I had such a struggle with customizable_types because it wasn't there in RHEL 4. > > > Moray. > "To err is human. To purr, feline" > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Moray.Henderson at ict.om.org Wed Nov 11 16:04:15 2009 From: Moray.Henderson at ict.om.org (Moray Henderson (ICT)) Date: Wed, 11 Nov 2009 16:04:15 +0000 Subject: idea: customizable_types.local In-Reply-To: <20091111122830.GA3590@notebook3.grift.internal> References: <1257887159.11014.6.camel@localhost> <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> <20091111122830.GA3590@notebook3.grift.internal> Message-ID: <211227D58676844E9EFBA3414EC92E880517E169DC@QTS-MBXCLSTR1.global.local> Dominick wrote: > >Thats cool, but what if you update your selinux policy? will > >customizable_types be overwritten? Maybe it would be good to have a > >customizable_types.local so that you can add your customizable types > >there and not have to worry about policy updates or restorecond -u. I've checked selinux-policy-targeted-2.4.6-255.el5_4.1, and customizable_types is marked as a config file. It would be overwritten, but you would get an rpmsave file so that you could reapply custom changes. Some of the other files in the contexts dir are config(noreplace); maybe making this one noreplace too would be the better solution. >That is just the issue. Sometimes it is not feasible or sometimes its not >possible to add a context specification. >For example the name of you backup file is changable and also its location. >You might call it backup.tgz and store it in ~ or call it bla.tgz and >store it in ~/Documents (just an example. Would /home/.*/.+\.tgz -- mybackup_script_home_t do it? Although I would have my backup scripts use more standardised names and locations anyway. >Another example is kismet, it will store logs where ever you start it. So >if you start it in ~ it will (try to) put the logs there. So lets say you >allow kistmet to manage files with kismet_home_t in user_home_t, Run >kismet and it starts logging to ~, along comes restorecond -u and resets >the contexts of the logs to user_home_t (to which kismet incidentally >cannot write/append) Not familiar with kismet. Creating logs wherever it is started sounds like bad behaviour quite apart from any SELinux implications, especially if there really is no way to distinguish a kismet log from any other random *.log file. Maybe a wrapper script to ensure it starts in a consistent location? You're right though, that must be the sort of thing customizable_types was designed for. >What if i have a policy that allows some domain to manage a file in >user_home_t with its own type (example blah_home_t). I start the confined >domain and notice that any file created by it has user_home_t (instead of >blah_home_t), whilst i implicitly defined a type transition. > >I would expect the file to have the type that i defined and not >user_home_t. That is confusing as well. So far when I have been creating policy I have been able to identify unique locations or filename patterns for the files whose types I need to manage. I put those into the .fc file when writing my policy and therefore the files do get the types I define. Your way is more flexible than mine, but it would come at the cost of adding another bit of complexity to SELinux - and when it comes to SELinux and complexity, "adding more" is not the first thing I think of :-) Moray. "To err is human. To purr, feline" From domg472 at gmail.com Wed Nov 11 17:21:53 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 11 Nov 2009 18:21:53 +0100 Subject: idea: customizable_types.local In-Reply-To: <211227D58676844E9EFBA3414EC92E880517E169DC@QTS-MBXCLSTR1.global.local> References: <1257887159.11014.6.camel@localhost> <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> <20091111122830.GA3590@notebook3.grift.internal> <211227D58676844E9EFBA3414EC92E880517E169DC@QTS-MBXCLSTR1.global.local> Message-ID: <1257960114.3748.2.camel@localhost> On Wed, 2009-11-11 at 16:04 +0000, Moray Henderson (ICT) wrote: > Dominick wrote: > > > >Thats cool, but what if you update your selinux policy? will > > >customizable_types be overwritten? Maybe it would be good to have a > > >customizable_types.local so that you can add your customizable types > > >there and not have to worry about policy updates or restorecond -u. > > I've checked selinux-policy-targeted-2.4.6-255.el5_4.1, and customizable_types is marked as a config file. It would be overwritten, but you would get an rpmsave file so that you could reapply custom changes. Some of the other files in the contexts dir are config(noreplace); maybe making this one noreplace too would be the better solution. > > > > >That is just the issue. Sometimes it is not feasible or sometimes its not > >possible to add a context specification. > >For example the name of you backup file is changable and also its location. > >You might call it backup.tgz and store it in ~ or call it bla.tgz and > >store it in ~/Documents (just an example. > > Would > > /home/.*/.+\.tgz -- mybackup_script_home_t That would be too broad. Not every *.tgz in $home is also actually a backup :) > do it? Although I would have my backup scripts use more standardised names and locations anyway. > The backup is just an example. > > >Another example is kismet, it will store logs where ever you start it. So > >if you start it in ~ it will (try to) put the logs there. So lets say you > >allow kistmet to manage files with kismet_home_t in user_home_t, Run > >kismet and it starts logging to ~, along comes restorecond -u and resets > >the contexts of the logs to user_home_t (to which kismet incidentally > >cannot write/append) > > Not familiar with kismet. Creating logs wherever it is started sounds like bad behaviour quite apart from any SELinux implications, especially if there really is no way to distinguish a kismet log from any other random *.log file. Maybe a wrapper script to ensure it starts in a consistent location? You're right though, that must be the sort of thing customizable_types was designed for. > > > >What if i have a policy that allows some domain to manage a file in > >user_home_t with its own type (example blah_home_t). I start the confined > >domain and notice that any file created by it has user_home_t (instead of > >blah_home_t), whilst i implicitly defined a type transition. > > > >I would expect the file to have the type that i defined and not > >user_home_t. That is confusing as well. > > So far when I have been creating policy I have been able to identify unique locations or filename patterns for the files whose types I need to manage. I put those into the .fc file when writing my policy and therefore the files do get the types I define. > > Your way is more flexible than mine, but it would come at the cost of adding another bit of complexity to SELinux - and when it comes to SELinux and complexity, "adding more" is not the first thing I think of :-) > complexity or flexibility? (i guess a little bit of both) > > Moray. > "To err is human. To purr, feline" > > > > -- > 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 Wed Nov 11 19:06:06 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 11 Nov 2009 14:06:06 -0500 Subject: idea: customizable_types.local In-Reply-To: <1257960114.3748.2.camel@localhost> References: <1257887159.11014.6.camel@localhost> <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> <20091111122830.GA3590@notebook3.grift.internal> <211227D58676844E9EFBA3414EC92E880517E169DC@QTS-MBXCLSTR1.global.local> <1257960114.3748.2.camel@localhost> Message-ID: <4AFB0B1E.6010402@redhat.com> On 11/11/2009 12:21 PM, Dominick Grift wrote: > On Wed, 2009-11-11 at 16:04 +0000, Moray Henderson (ICT) wrote: >> Dominick wrote: >> >>>> Thats cool, but what if you update your selinux policy? will >>>> customizable_types be overwritten? Maybe it would be good to have a >>>> customizable_types.local so that you can add your customizable types >>>> there and not have to worry about policy updates or restorecond -u. >> >> I've checked selinux-policy-targeted-2.4.6-255.el5_4.1, and customizable_types is marked as a config file. It would be overwritten, but you would get an rpmsave file so that you could reapply custom changes. Some of the other files in the contexts dir are config(noreplace); maybe making this one noreplace too would be the better solution. >> >> >> >>> That is just the issue. Sometimes it is not feasible or sometimes its not >>> possible to add a context specification. >>> For example the name of you backup file is changable and also its location. >>> You might call it backup.tgz and store it in ~ or call it bla.tgz and >>> store it in ~/Documents (just an example. >> >> Would >> >> /home/.*/.+\.tgz -- mybackup_script_home_t > > That would be too broad. Not every *.tgz in $home is also actually a > backup :) > >> do it? Although I would have my backup scripts use more standardised names and locations anyway. >> > > The backup is just an example. > >> >>> Another example is kismet, it will store logs where ever you start it. So >>> if you start it in ~ it will (try to) put the logs there. So lets say you >>> allow kistmet to manage files with kismet_home_t in user_home_t, Run >>> kismet and it starts logging to ~, along comes restorecond -u and resets >>> the contexts of the logs to user_home_t (to which kismet incidentally >>> cannot write/append) >> >> Not familiar with kismet. Creating logs wherever it is started sounds like bad behaviour quite apart from any SELinux implications, especially if there really is no way to distinguish a kismet log from any other random *.log file. Maybe a wrapper script to ensure it starts in a consistent location? You're right though, that must be the sort of thing customizable_types was designed for. >> >> >>> What if i have a policy that allows some domain to manage a file in >>> user_home_t with its own type (example blah_home_t). I start the confined >>> domain and notice that any file created by it has user_home_t (instead of >>> blah_home_t), whilst i implicitly defined a type transition. >>> >>> I would expect the file to have the type that i defined and not >>> user_home_t. That is confusing as well. >> >> So far when I have been creating policy I have been able to identify unique locations or filename patterns for the files whose types I need to manage. I put those into the .fc file when writing my policy and therefore the files do get the types I define. >> >> Your way is more flexible than mine, but it would come at the cost of adding another bit of complexity to SELinux - and when it comes to SELinux and complexity, "adding more" is not the first thing I think of :-) >> > complexity or flexibility? (i guess a little bit of both) >> >> Moray. >> "To err is human. To purr, feline" >> >> >> >> -- >> 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 > > customizable_types predates the semange fcontext stuff. The main idea was admins were throwing http_sys_content_t labels around with chcon and restorecon/setfiles was removing the labels. With semanage fcontext, customizable_types became much less important. I would recommend setting the labeling for the homedir or turning off restorecond from the autostart. Or adding entries to customizable_types. I think we can change the designation of customizable_types in the spec file to change rpm to not overwrite changes, since I don't intend to add more customizable types to base policy. From domg472 at gmail.com Wed Nov 11 19:26:56 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 11 Nov 2009 20:26:56 +0100 Subject: idea: customizable_types.local In-Reply-To: <4AFB0B1E.6010402@redhat.com> References: <1257887159.11014.6.camel@localhost> <211227D58676844E9EFBA3414EC92E880517E169B7@QTS-MBXCLSTR1.global.local> <20091111122830.GA3590@notebook3.grift.internal> <211227D58676844E9EFBA3414EC92E880517E169DC@QTS-MBXCLSTR1.global.local> <1257960114.3748.2.camel@localhost> <4AFB0B1E.6010402@redhat.com> Message-ID: <1257967616.3748.12.camel@localhost> On Wed, 2009-11-11 at 14:06 -0500, Daniel J Walsh wrote: > On 11/11/2009 12:21 PM, Dominick Grift wrote: > > On Wed, 2009-11-11 at 16:04 +0000, Moray Henderson (ICT) wrote: > >> Dominick wrote: > >> > >>>> Thats cool, but what if you update your selinux policy? will > >>>> customizable_types be overwritten? Maybe it would be good to have a > >>>> customizable_types.local so that you can add your customizable types > >>>> there and not have to worry about policy updates or restorecond -u. > >> > >> I've checked selinux-policy-targeted-2.4.6-255.el5_4.1, and customizable_types is marked as a config file. It would be overwritten, but you would get an rpmsave file so that you could reapply custom changes. Some of the other files in the contexts dir are config(noreplace); maybe making this one noreplace too would be the better solution. > >> > >> > >> > >>> That is just the issue. Sometimes it is not feasible or sometimes its not > >>> possible to add a context specification. > >>> For example the name of you backup file is changable and also its location. > >>> You might call it backup.tgz and store it in ~ or call it bla.tgz and > >>> store it in ~/Documents (just an example. > >> > >> Would > >> > >> /home/.*/.+\.tgz -- mybackup_script_home_t > > > > That would be too broad. Not every *.tgz in $home is also actually a > > backup :) > > > >> do it? Although I would have my backup scripts use more standardised names and locations anyway. > >> > > > > The backup is just an example. > > > >> > >>> Another example is kismet, it will store logs where ever you start it. So > >>> if you start it in ~ it will (try to) put the logs there. So lets say you > >>> allow kistmet to manage files with kismet_home_t in user_home_t, Run > >>> kismet and it starts logging to ~, along comes restorecond -u and resets > >>> the contexts of the logs to user_home_t (to which kismet incidentally > >>> cannot write/append) > >> > >> Not familiar with kismet. Creating logs wherever it is started sounds like bad behaviour quite apart from any SELinux implications, especially if there really is no way to distinguish a kismet log from any other random *.log file. Maybe a wrapper script to ensure it starts in a consistent location? You're right though, that must be the sort of thing customizable_types was designed for. > >> > >> > >>> What if i have a policy that allows some domain to manage a file in > >>> user_home_t with its own type (example blah_home_t). I start the confined > >>> domain and notice that any file created by it has user_home_t (instead of > >>> blah_home_t), whilst i implicitly defined a type transition. > >>> > >>> I would expect the file to have the type that i defined and not > >>> user_home_t. That is confusing as well. > >> > >> So far when I have been creating policy I have been able to identify unique locations or filename patterns for the files whose types I need to manage. I put those into the .fc file when writing my policy and therefore the files do get the types I define. > >> > >> Your way is more flexible than mine, but it would come at the cost of adding another bit of complexity to SELinux - and when it comes to SELinux and complexity, "adding more" is not the first thing I think of :-) > >> > > complexity or flexibility? (i guess a little bit of both) > >> > >> Moray. > >> "To err is human. To purr, feline" > >> > >> > >> > >> -- > >> 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 > > > > > customizable_types predates the semange fcontext stuff. The main idea was admins were throwing http_sys_content_t labels around with chcon and restorecon/setfiles was removing the labels. > > With semanage fcontext, customizable_types became much less important. > > I would recommend setting the labeling for the homedir or turning off restorecond from the autostart. > Or adding entries to customizable_types. I think we can change the designation of customizable_types in the spec file to change rpm to not overwrite changes, since I don't intend to add more customizable types to base policy. By the way, if i remember my argument for putting httpd_user* types in customizable_types correct, then i think we can by now remove them again from customizable_types as currently you can add home dir context specifications with semanage. I think my argument at the time was that admins could not add custom locations with semanage fcontext in /home/*/. This works fine now. To be honest, and i hope i am wrong, i think that you may not take into account the behavior of user apps and the prospect of more and more confined user apps in the future. By excluding the customized_types file from being updated i think the issue may be solved. However i am not sure whether the policy needs to be rebuild after manual modification. From ejtr at layer3.co.uk Fri Nov 13 14:53:38 2009 From: ejtr at layer3.co.uk (Ted Rule) Date: Fri, 13 Nov 2009 14:53:38 +0000 Subject: Apache/PHP mail function SELinux permissions Message-ID: <4AFD72F2.4030901@layer3.co.uk> I've had a "problem" recently with SELinux permissions related to PHP's mail functions. These appear to give rise to two different classes of error, one for read permissions on the httpd_t domain itself, and one for read/write permission on a file in the httpd_tmp_t domain. aureport gives this: $ sudo aureport -a |grep system_mail |head 6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116101 7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116102 17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116124 23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116136 24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116136 30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116148 31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116148 39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116168 40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116168 48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116181 Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5 Looking in more detail at ausearch we see that the httpd_t related avc is apparently related to an "eventpoll" file descriptor, whilst the httpd_tmp_t avc is probably for a file created by php in /tmp. Looking at the php source code itself, I see that it is simply opening a temporary file containing the body of the Email and pouring it via a pipe into an instance of sendmail via popen(). As such, it seems likely that both classes of avc's are simply file descriptors "leaking" into the popen'ed child process running in the system_mail_t domain. Sadly, for other reasons, the Apache hosts are still in permissive, so it's currently unclear to me whether the PHP mail function would fail completely if either of these permissions are denied in enforcing mode, but it makes me wonder whether there would be any sense in a wider solution to leaky descriptors which caused popen() itself to close all file descriptors other than STDIN/STDOUT/STDERR if the popen'ed executable implies a domain transition. Alternatively, one might envisage a set of selinux booleans which allowed a more granular control of leaked descriptors outside of STDIN/STDOUT/STDERR. The other potential policy improvement would be for system_mail_t to simply "dontaudit" denials relating to eventpoll class file descriptors and temporary files in context *_tmp_t. time->Sun Oct 25 13:12:48 2009 type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11 success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0 ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs ino=129640960 scontext=user_u:system_r:system _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file ---- time->Sun Oct 25 13:15:57 2009 type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11 success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0 ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256476557.234:116102): avc: denied { read write } for pid=22099 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Sun Oct 25 13:39:46 2009 type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11 success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0 ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256477986.012:116124): avc: denied { read write } for pid=23560 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Sun Oct 25 13:43:04 2009 type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11 success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0 ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs ino=129701955 scontext=user_u:system_r:system _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file type=AVC msg=audit(1256478184.954:116136): avc: denied { read write } for pid=23802 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Sun Oct 25 13:52:57 2009 type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11 success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0 ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs ino=129734033 scontext=user_u:system_r:system _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file type=AVC msg=audit(1256478777.377:116148): avc: denied { read write } for pid=24439 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- -- Ted Rule Director, Layer3 Systems Ltd Layer3 Systems Limited is registered in England. Company no 3130393 W: http://www.layer3.co.uk/ From dwalsh at redhat.com Fri Nov 13 15:29:39 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 13 Nov 2009 10:29:39 -0500 Subject: Apache/PHP mail function SELinux permissions In-Reply-To: <4AFD72F2.4030901@layer3.co.uk> References: <4AFD72F2.4030901@layer3.co.uk> Message-ID: <4AFD7B63.7040408@redhat.com> On 11/13/2009 09:53 AM, Ted Rule wrote: > > I've had a "problem" recently with SELinux permissions related to PHP's > mail functions. These appear to give rise to two different classes of error, > one for read permissions on the httpd_t domain itself, and one for > read/write permission on a file in the httpd_tmp_t domain. > > aureport gives this: > > $ sudo aureport -a |grep system_mail |head > 6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file > read user_u:system_r:httpd_t:s0 denied 116101 > 7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file > read write user_u:object_r:httpd_tmp_t:s0 denied 116102 > 17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file > read write user_u:object_r:httpd_tmp_t:s0 denied 116124 > 23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file > read write user_u:object_r:httpd_tmp_t:s0 denied 116136 > 24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file > read user_u:system_r:httpd_t:s0 denied 116136 > 30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file > read write user_u:object_r:httpd_tmp_t:s0 denied 116148 > 31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file > read user_u:system_r:httpd_t:s0 denied 116148 > 39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file > read write user_u:object_r:httpd_tmp_t:s0 denied 116168 > 40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file > read user_u:system_r:httpd_t:s0 denied 116168 > 48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file > read write user_u:object_r:httpd_tmp_t:s0 denied 116181 > > Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5 > > Looking in more detail at ausearch we see that the httpd_t related avc > is apparently related to an "eventpoll" file descriptor, whilst the > httpd_tmp_t > avc is probably for a file created by php in /tmp. > > Looking at the php source code itself, I see that it is simply opening a > temporary file containing the body of the Email and pouring it via a > pipe into an instance of sendmail via popen(). > > As such, it seems likely that both classes of avc's are simply file > descriptors "leaking" into the popen'ed child process running in the > system_mail_t domain. > > Sadly, for other reasons, the Apache hosts are still in permissive, so > it's currently unclear to me whether the PHP mail function would fail > completely if either > of these permissions are denied in enforcing mode, but it makes me > wonder whether there would be any sense in a wider solution to leaky > descriptors which caused popen() itself to close all file descriptors > other than STDIN/STDOUT/STDERR if the popen'ed executable implies a > domain transition. Alternatively, one might envisage a set of selinux > booleans which allowed a more granular control of leaked descriptors > outside of STDIN/STDOUT/STDERR. > > > The other potential policy improvement would be for system_mail_t to > simply "dontaudit" denials relating to eventpoll class file descriptors > and temporary files in context *_tmp_t. > > > > > time->Sun Oct 25 13:12:48 2009 > type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11 > success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0 > ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid= > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > subj=user_u:system_r:system_mail_t:s0 key=(null) > type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for > pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs > ino=129640960 scontext=user_u:system_r:system > _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file > ---- > time->Sun Oct 25 13:15:57 2009 > type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11 > success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0 > ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid= > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > subj=user_u:system_r:system_mail_t:s0 key=(null) > type=AVC msg=audit(1256476557.234:116102): avc: denied { read write } > for pid=22099 comm="sendmail" > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > ---- > time->Sun Oct 25 13:39:46 2009 > type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11 > success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0 > ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid= > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > subj=user_u:system_r:system_mail_t:s0 key=(null) > type=AVC msg=audit(1256477986.012:116124): avc: denied { read write } > for pid=23560 comm="sendmail" > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > ---- > time->Sun Oct 25 13:43:04 2009 > type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11 > success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0 > ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid= > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > subj=user_u:system_r:system_mail_t:s0 key=(null) > type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for > pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs > ino=129701955 scontext=user_u:system_r:system > _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file > type=AVC msg=audit(1256478184.954:116136): avc: denied { read write } > for pid=23802 comm="sendmail" > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > ---- > time->Sun Oct 25 13:52:57 2009 > type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11 > success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0 > ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid= > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > subj=user_u:system_r:system_mail_t:s0 key=(null) > type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for > pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs > ino=129734033 scontext=user_u:system_r:system > _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file > type=AVC msg=audit(1256478777.377:116148): avc: denied { read write } > for pid=24439 comm="sendmail" > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > ---- > > > Is mail working? IE Is the mail being sent? These look like leaked file descriptors. From ejtr at layer3.co.uk Fri Nov 13 18:13:54 2009 From: ejtr at layer3.co.uk (Ted Rule) Date: Fri, 13 Nov 2009 18:13:54 +0000 Subject: Apache/PHP mail function SELinux permissions In-Reply-To: <4AFD7B63.7040408@redhat.com> References: <4AFD72F2.4030901@layer3.co.uk> <4AFD7B63.7040408@redhat.com> Message-ID: <1258136034.8846.7.camel@topaz.bugfinder.co.uk> On Fri, 2009-11-13 at 10:29 -0500, Daniel J Walsh wrote: > On 11/13/2009 09:53 AM, Ted Rule wrote: > > > > I've had a "problem" recently with SELinux permissions related to PHP's > > mail functions. These appear to give rise to two different classes of error, > > one for read permissions on the httpd_t domain itself, and one for > > read/write permission on a file in the httpd_tmp_t domain. > > > > aureport gives this: > > > > $ sudo aureport -a |grep system_mail |head > > 6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file > > read user_u:system_r:httpd_t:s0 denied 116101 > > 7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file > > read write user_u:object_r:httpd_tmp_t:s0 denied 116102 > > 17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file > > read write user_u:object_r:httpd_tmp_t:s0 denied 116124 > > 23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file > > read write user_u:object_r:httpd_tmp_t:s0 denied 116136 > > 24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file > > read user_u:system_r:httpd_t:s0 denied 116136 > > 30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file > > read write user_u:object_r:httpd_tmp_t:s0 denied 116148 > > 31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file > > read user_u:system_r:httpd_t:s0 denied 116148 > > 39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file > > read write user_u:object_r:httpd_tmp_t:s0 denied 116168 > > 40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file > > read user_u:system_r:httpd_t:s0 denied 116168 > > 48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file > > read write user_u:object_r:httpd_tmp_t:s0 denied 116181 > > > > Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5 > > > > Looking in more detail at ausearch we see that the httpd_t related avc > > is apparently related to an "eventpoll" file descriptor, whilst the > > httpd_tmp_t > > avc is probably for a file created by php in /tmp. > > > > Looking at the php source code itself, I see that it is simply opening a > > temporary file containing the body of the Email and pouring it via a > > pipe into an instance of sendmail via popen(). > > > > As such, it seems likely that both classes of avc's are simply file > > descriptors "leaking" into the popen'ed child process running in the > > system_mail_t domain. > > > > Sadly, for other reasons, the Apache hosts are still in permissive, so > > it's currently unclear to me whether the PHP mail function would fail > > completely if either > > of these permissions are denied in enforcing mode, but it makes me > > wonder whether there would be any sense in a wider solution to leaky > > descriptors which caused popen() itself to close all file descriptors > > other than STDIN/STDOUT/STDERR if the popen'ed executable implies a > > domain transition. Alternatively, one might envisage a set of selinux > > booleans which allowed a more granular control of leaked descriptors > > outside of STDIN/STDOUT/STDERR. > > > > > > The other potential policy improvement would be for system_mail_t to > > simply "dontaudit" denials relating to eventpoll class file descriptors > > and temporary files in context *_tmp_t. > > > > > > > > > > time->Sun Oct 25 13:12:48 2009 > > type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11 > > success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0 > > ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid= > > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > > subj=user_u:system_r:system_mail_t:s0 key=(null) > > type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for > > pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs > > ino=129640960 scontext=user_u:system_r:system > > _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file > > ---- > > time->Sun Oct 25 13:15:57 2009 > > type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11 > > success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0 > > ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid= > > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > > subj=user_u:system_r:system_mail_t:s0 key=(null) > > type=AVC msg=audit(1256476557.234:116102): avc: denied { read write } > > for pid=22099 comm="sendmail" > > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > > ---- > > time->Sun Oct 25 13:39:46 2009 > > type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11 > > success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0 > > ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid= > > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > > subj=user_u:system_r:system_mail_t:s0 key=(null) > > type=AVC msg=audit(1256477986.012:116124): avc: denied { read write } > > for pid=23560 comm="sendmail" > > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > > ---- > > time->Sun Oct 25 13:43:04 2009 > > type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11 > > success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0 > > ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid= > > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > > subj=user_u:system_r:system_mail_t:s0 key=(null) > > type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for > > pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs > > ino=129701955 scontext=user_u:system_r:system > > _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file > > type=AVC msg=audit(1256478184.954:116136): avc: denied { read write } > > for pid=23802 comm="sendmail" > > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > > ---- > > time->Sun Oct 25 13:52:57 2009 > > type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11 > > success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0 > > ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid= > > 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 > > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > > subj=user_u:system_r:system_mail_t:s0 key=(null) > > type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for > > pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs > > ino=129734033 scontext=user_u:system_r:system > > _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file > > type=AVC msg=audit(1256478777.377:116148): avc: denied { read write } > > for pid=24439 comm="sendmail" > > path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 > > 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 > > tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file > > ---- > > > > > > > Is mail working? IE Is the mail being sent? These look like leaked file descriptors. Mail from Apache/PHP is working, but as I mentioned, the server is in permissive mode, so I can't tell whether it would stop working were we to move to enforcing. Whilst I could add some custom rules to work round this if need be, my more general thought was whether a cleaner overall solution to leaked descriptors via popen() might be possible. -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From dwalsh at redhat.com Fri Nov 13 19:16:46 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 13 Nov 2009 14:16:46 -0500 Subject: Apache/PHP mail function SELinux permissions In-Reply-To: <1258136034.8846.7.camel@topaz.bugfinder.co.uk> References: <4AFD72F2.4030901@layer3.co.uk> <4AFD7B63.7040408@redhat.com> <1258136034.8846.7.camel@topaz.bugfinder.co.uk> Message-ID: <4AFDB09E.20906@redhat.com> On 11/13/2009 01:13 PM, Ted Rule wrote: > On Fri, 2009-11-13 at 10:29 -0500, Daniel J Walsh wrote: >> On 11/13/2009 09:53 AM, Ted Rule wrote: >>> >>> I've had a "problem" recently with SELinux permissions related to PHP's >>> mail functions. These appear to give rise to two different classes of error, >>> one for read permissions on the httpd_t domain itself, and one for >>> read/write permission on a file in the httpd_tmp_t domain. >>> >>> aureport gives this: >>> >>> $ sudo aureport -a |grep system_mail |head >>> 6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read user_u:system_r:httpd_t:s0 denied 116101 >>> 7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read write user_u:object_r:httpd_tmp_t:s0 denied 116102 >>> 17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read write user_u:object_r:httpd_tmp_t:s0 denied 116124 >>> 23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read write user_u:object_r:httpd_tmp_t:s0 denied 116136 >>> 24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read user_u:system_r:httpd_t:s0 denied 116136 >>> 30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read write user_u:object_r:httpd_tmp_t:s0 denied 116148 >>> 31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read user_u:system_r:httpd_t:s0 denied 116148 >>> 39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read write user_u:object_r:httpd_tmp_t:s0 denied 116168 >>> 40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read user_u:system_r:httpd_t:s0 denied 116168 >>> 48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file >>> read write user_u:object_r:httpd_tmp_t:s0 denied 116181 >>> >>> Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5 >>> >>> Looking in more detail at ausearch we see that the httpd_t related avc >>> is apparently related to an "eventpoll" file descriptor, whilst the >>> httpd_tmp_t >>> avc is probably for a file created by php in /tmp. >>> >>> Looking at the php source code itself, I see that it is simply opening a >>> temporary file containing the body of the Email and pouring it via a >>> pipe into an instance of sendmail via popen(). >>> >>> As such, it seems likely that both classes of avc's are simply file >>> descriptors "leaking" into the popen'ed child process running in the >>> system_mail_t domain. >>> >>> Sadly, for other reasons, the Apache hosts are still in permissive, so >>> it's currently unclear to me whether the PHP mail function would fail >>> completely if either >>> of these permissions are denied in enforcing mode, but it makes me >>> wonder whether there would be any sense in a wider solution to leaky >>> descriptors which caused popen() itself to close all file descriptors >>> other than STDIN/STDOUT/STDERR if the popen'ed executable implies a >>> domain transition. Alternatively, one might envisage a set of selinux >>> booleans which allowed a more granular control of leaked descriptors >>> outside of STDIN/STDOUT/STDERR. >>> >>> >>> The other potential policy improvement would be for system_mail_t to >>> simply "dontaudit" denials relating to eventpoll class file descriptors >>> and temporary files in context *_tmp_t. >>> >>> >>> >>> >>> time->Sun Oct 25 13:12:48 2009 >>> type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11 >>> success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0 >>> ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid= >>> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >>> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >>> subj=user_u:system_r:system_mail_t:s0 key=(null) >>> type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for >>> pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs >>> ino=129640960 scontext=user_u:system_r:system >>> _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file >>> ---- >>> time->Sun Oct 25 13:15:57 2009 >>> type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11 >>> success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0 >>> ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid= >>> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >>> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >>> subj=user_u:system_r:system_mail_t:s0 key=(null) >>> type=AVC msg=audit(1256476557.234:116102): avc: denied { read write } >>> for pid=22099 comm="sendmail" >>> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >>> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >>> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >>> ---- >>> time->Sun Oct 25 13:39:46 2009 >>> type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11 >>> success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0 >>> ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid= >>> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >>> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >>> subj=user_u:system_r:system_mail_t:s0 key=(null) >>> type=AVC msg=audit(1256477986.012:116124): avc: denied { read write } >>> for pid=23560 comm="sendmail" >>> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >>> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >>> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >>> ---- >>> time->Sun Oct 25 13:43:04 2009 >>> type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11 >>> success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0 >>> ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid= >>> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >>> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >>> subj=user_u:system_r:system_mail_t:s0 key=(null) >>> type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for >>> pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs >>> ino=129701955 scontext=user_u:system_r:system >>> _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file >>> type=AVC msg=audit(1256478184.954:116136): avc: denied { read write } >>> for pid=23802 comm="sendmail" >>> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >>> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >>> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >>> ---- >>> time->Sun Oct 25 13:52:57 2009 >>> type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11 >>> success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0 >>> ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid= >>> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >>> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >>> subj=user_u:system_r:system_mail_t:s0 key=(null) >>> type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for >>> pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs >>> ino=129734033 scontext=user_u:system_r:system >>> _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file >>> type=AVC msg=audit(1256478777.377:116148): avc: denied { read write } >>> for pid=24439 comm="sendmail" >>> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >>> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >>> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >>> ---- >>> >>> >>> >> Is mail working? IE Is the mail being sent? These look like leaked file descriptors. > > Mail from Apache/PHP is working, but as I mentioned, the server is in > permissive mode, so I can't tell whether it would stop working were we > to move to enforcing. > > Whilst I could add some custom rules to work round this if need be, my > more general thought was whether a cleaner overall solution to leaked > descriptors via popen() might be possible. > > > > Well not likely considering the about of code that is in apache. The problem with running stuff within the apache process, you get all of the loadable apache modules which you do not know where they were created. All calls would need to be fcntl(fd, F_SETFD, FD_CLOEXEC) From deleriux at airattack-central.com Sat Nov 14 00:32:59 2009 From: deleriux at airattack-central.com (Matthew Ife) Date: Sat, 14 Nov 2009 00:32:59 +0000 Subject: file contexts labelling - possible bug? Message-ID: <1258158779.6160.8.camel@home.localdomain> This might just be me being daft in some sense but I have come across the following situation and was hoping someone could shed light on it. Part of setting up kerberos involves creating a principal database with the kdb5_util command. When you setup the database (typically as unconfined_t on a default installation) it puts various files in; /var/kerberos/krb5kdc of which include the principal database itself and various controls such as a lock file. This folder gets the context krb5kdc_conf_t and a few file contexts exist in the fcontext database to manage the additional creation of files in side, one of which is the principal.ok file which is used as a lock file. When creating the lock file with the command above it should get the label (according to fcontexts) of krb5kdc_lock_t as a regex exists such as: /var/kerberos/krb5kdc/principal.*\.ok system_u:object_r:krb5kdc_lock_t But, the file gets the parent directory context of conf_t. Likewise, removing the lock file manually and touching the file again also demonstrates the same behavior. If you then run restorecon/fixfiles on the directory it will correctly reset the file to the right location. I've checked with strace to see if something strange happens (if the principal.ok file gets created as a temp name then moved) but there is no such behaviour. Thus I'm stuck in understanding whats going on. Why does default filesystem labelling give the file conf_t and restorecon give it the (correct) lock_t? From dwalsh at redhat.com Mon Nov 16 19:15:57 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 16 Nov 2009 14:15:57 -0500 Subject: file contexts labelling - possible bug? In-Reply-To: <1258158779.6160.8.camel@home.localdomain> References: <1258158779.6160.8.camel@home.localdomain> Message-ID: <4B01A4ED.8020907@redhat.com> On 11/13/2009 07:32 PM, Matthew Ife wrote: > This might just be me being daft in some sense but I have come across > the following situation and was hoping someone could shed light on it. > > Part of setting up kerberos involves creating a principal database with > the kdb5_util command. > > When you setup the database (typically as unconfined_t on a default > installation) it puts various files in; > /var/kerberos/krb5kdc > of which include the principal database itself and various controls such > as a lock file. > > This folder gets the context krb5kdc_conf_t and a few file contexts > exist in the fcontext database to manage the additional creation of > files in side, one of which is the principal.ok file which is used as a > lock file. > > When creating the lock file with the command above it should get the > label (according to fcontexts) of krb5kdc_lock_t as a regex exists such > as: > /var/kerberos/krb5kdc/principal.*\.ok system_u:object_r:krb5kdc_lock_t > > But, the file gets the parent directory context of conf_t. Likewise, > removing the lock file manually and touching the file again also > demonstrates the same behavior. If you then run restorecon/fixfiles on > the directory it will correctly reset the file to the right location. > > I've checked with strace to see if something strange happens (if the > principal.ok file gets created as a temp name then moved) but there is > no such behaviour. Thus I'm stuck in understanding whats going on. Why > does default filesystem labelling give the file conf_t and restorecon > give it the (correct) lock_t? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > I wrote a blog a long time ago explaining how files get their labels. http://danwalsh.livejournal.com/2639.html The problem here is that kdb5_util would need to have SELinux awareness in order to create the files with the correct context. Kerberos libraries have this awareness built into them in Fedora, but I guess this tool does not. You should open a bugzilla on it. From gene at czarc.net Tue Nov 17 13:06:41 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 17 Nov 2009 08:06:41 -0500 Subject: BZ 533427 Message-ID: <200911170806.41387.gene@czarc.net> https://bugzilla.redhat.com/show_bug.cgi?id=533427 was first reported 6 November and on 6 November you reported that the problem was fixed in selinux- policy-3.6.32-42.fc12.noarch WHERE IS selinux-policy-3.6.32-42.fc12.noarch ???? Today is 17 November. This update (or a later/more-recent version) has not appeared in either updates or updates-testing for F12. This impacts the abrt package's ability to report meaningful bugs! Gene -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.roys at gtri.gatech.edu Tue Nov 17 13:11:35 2009 From: joshua.roys at gtri.gatech.edu (Joshua Roys) Date: Tue, 17 Nov 2009 08:11:35 -0500 Subject: BZ 533427 In-Reply-To: <200911170806.41387.gene@czarc.net> References: <200911170806.41387.gene@czarc.net> Message-ID: <4B02A107.8000300@gtri.gatech.edu> On 11/17/2009 08:06 AM, Gene Czarcinski wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=533427 was first reported 6 > November and on 6 November you reported that the problem was fixed in > selinux-policy-3.6.32-42.fc12.noarch > > WHERE IS selinux-policy-3.6.32-42.fc12.noarch ???? > > Today is 17 November. This update (or a later/more-recent version) has > not appeared in either updates or updates-testing for F12. > > This impacts the abrt package's ability to report meaningful bugs! > > Gene > Hello, I found an even newer release in koji and bodhi, -46: http://koji.fedoraproject.org/koji/buildinfo?buildID=141477 https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-46.fc12 Josh From dwalsh at redhat.com Tue Nov 17 14:00:47 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 17 Nov 2009 09:00:47 -0500 Subject: BZ 533427 In-Reply-To: <200911170806.41387.gene@czarc.net> References: <200911170806.41387.gene@czarc.net> Message-ID: <4B02AC8F.6040702@redhat.com> On 11/17/2009 08:06 AM, Gene Czarcinski wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=533427 was first reported 6 > November and on 6 November you reported that the problem was fixed in selinux- > policy-3.6.32-42.fc12.noarch > > WHERE IS selinux-policy-3.6.32-42.fc12.noarch ???? > > Today is 17 November. This update (or a later/more-recent version) has not > appeared in either updates or updates-testing for F12. > > This impacts the abrt package's ability to report meaningful bugs! > > Gene > -46 should be in updates-testing. When F12 is about to ship packages do not flow as quickly. From gene at czarc.net Tue Nov 17 17:31:20 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 17 Nov 2009 12:31:20 -0500 Subject: BZ 533427 In-Reply-To: <4B02AC8F.6040702@redhat.com> References: <200911170806.41387.gene@czarc.net> <4B02AC8F.6040702@redhat.com> Message-ID: <200911171231.20404.gene@czarc.net> On Tuesday 17 November 2009 09:00:47 Daniel J Walsh wrote: > On 11/17/2009 08:06 AM, Gene Czarcinski wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=533427 was first reported 6 > > November and on 6 November you reported that the problem was fixed in > > selinux- policy-3.6.32-42.fc12.noarch > > > > WHERE IS selinux-policy-3.6.32-42.fc12.noarch ???? > > > > Today is 17 November. This update (or a later/more-recent version) has > > not appeared in either updates or updates-testing for F12. > > > > This impacts the abrt package's ability to report meaningful bugs! > > > > Gene > > -46 should be in updates-testing. > > When F12 is about to ship packages do not flow as quickly. > Quickly?? Ten days to get a package pushed?? I just checked updates-testing and there is nothing. Since the mirror might not have picked up an update yet, I also checked download.fedora.redhat.com and there are no selinux-* packages in update or update-testing. Currently, there are 38 CC users on BZ 533427 which indicates to me that a number of us "leading edgers" have gotten this problem. Yes, I could go around the standard way of updating to get the fix but why should I need to do that? I am a big fan of SELinux and do not want to disable it or even to put it into permissive mode. However, SELinux is getting in the way of abrt functioning. Usually, I find that SELinux fixes are distributed in a very timely manner. Something is broken here. Gene From tibbs at math.uh.edu Tue Nov 17 17:43:58 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 17 Nov 2009 11:43:58 -0600 Subject: BZ 533427 In-Reply-To: <200911171231.20404.gene@czarc.net> (Gene Czarcinski's message of "Tue, 17 Nov 2009 12:31:20 -0500") References: <200911170806.41387.gene@czarc.net> <4B02AC8F.6040702@redhat.com> <200911171231.20404.gene@czarc.net> Message-ID: >>>>> "GC" == Gene Czarcinski writes: GC> Quickly?? Ten days to get a package pushed?? Wow. If you really really want it right this instant and aren't willing to wait for the volunteers that provide this operating system to you to work through everything they have to do to get Fedora 12 out the door in addition to the work of getting updates and such out for Fedora 11 and 10, why don't you: Check the source out of CVS and build it yourself? Download the build from koji? http://koji.fedoraproject.org/koji/packageinfo?packageID=32 and pick a build for the OS version you want. Probably http://koji.fedoraproject.org/koji/buildinfo?buildID=140508 It's all made available to you, all the source, the buildsystem, everything. If you simply can't wait for the updates process to catch up, you have plenty of other means to get the software. - J< From gene at czarc.net Tue Nov 17 20:14:28 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 17 Nov 2009 15:14:28 -0500 Subject: BZ 533427 In-Reply-To: References: <200911170806.41387.gene@czarc.net> <200911171231.20404.gene@czarc.net> Message-ID: <200911171514.28552.gene@czarc.net> On Tuesday 17 November 2009 12:43:58 Jason L Tibbitts III wrote: > >>>>> "GC" == Gene Czarcinski writes: > > GC> Quickly?? Ten days to get a package pushed?? > > Wow. If you really really want it right this instant and aren't willing > to wait for the volunteers that provide this operating system to you to > work through everything they have to do to get Fedora 12 out the door in > addition to the work of getting updates and such out for Fedora 11 and > 10, why don't you: > > Check the source out of CVS and build it yourself? > > Download the build from koji? > http://koji.fedoraproject.org/koji/packageinfo?packageID=32 and pick a > build for the OS version you want. Probably > http://koji.fedoraproject.org/koji/buildinfo?buildID=140508 > > It's all made available to you, all the source, the buildsystem, > everything. If you simply can't wait for the updates process to catch > up, you have plenty of other means to get the software. > Unfortunately, you have missed the entire point of my email! Yes, I can go get an update from koji, or get the source and do it myself, or simply apply the "fix" suggested by audit2allow, or set permissive mode, or disable selinux. Any of these would get around the problem. But, this would not be the "official" selinux-policy package update. The problem in https://bugzilla.redhat.com/show_bug.cgi?id=533427 impacts the abrt package's ability to function properly. The abrt package is a really good new feature in Fedora 12 and should help resolve problems more quickly since it provides a lot more information than many users include in the handcrafted reports (myself included). The problem was reported on 6 November 2009 at 13:33 EDT and Dan Walsh responded on 6 November 2008 at 14:38 EDT (a bit over an hour) that the problem was fixed in selinux-policy-3.6.32-42.fc12.noarch and the BZ report was closed as fixed in rawhide (perhaps closing this problem so quickly was an error). Today is 17 November 2009 and Fedora 12 is GA but there is no "day zero" fix for the problem ... not even in updates-testing (last I checked around 1400 EST). I claim that something in the process of getting fixes out (at least selinux-policy fixes) is broken. This is what I am trying to get fixed so users do not set permissive mode or simply disable selinux. Gene -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.santore at internexusconnect.net Tue Nov 17 20:32:19 2009 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Tue, 17 Nov 2009 20:32:19 +0000 Subject: BZ 533427 In-Reply-To: <200911171514.28552.gene@czarc.net> References: <200911170806.41387.gene@czarc.net> <200911171231.20404.gene@czarc.net> <200911171514.28552.gene@czarc.net> Message-ID: <4B030853.7020803@internexusconnect.net> On 17/11/09 20:14, Gene Czarcinski wrote: > > On Tuesday 17 November 2009 12:43:58 Jason L Tibbitts III wrote: > > > >>>>> "GC" == Gene Czarcinski writes: > > > > > > GC> Quickly?? Ten days to get a package pushed?? > > > > > > Wow. If you really really want it right this instant and aren't willing > > > to wait for the volunteers that provide this operating system to you to > > > work through everything they have to do to get Fedora 12 out the door in > > > addition to the work of getting updates and such out for Fedora 11 and > > > 10, why don't you: > > > > > > Check the source out of CVS and build it yourself? > > > > > > Download the build from koji? > > > http://koji.fedoraproject.org/koji/packageinfo?packageID=32 and pick a > > > build for the OS version you want. Probably > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=140508 > > > > > > It's all made available to you, all the source, the buildsystem, > > > everything. If you simply can't wait for the updates process to catch > > > up, you have plenty of other means to get the software. > > > > > Unfortunately, you have missed the entire point of my email! > > Yes, I can go get an update from koji, or get the source and do it > myself, or simply apply the "fix" suggested by audit2allow, or set > permissive mode, or disable selinux. Any of these would get around the > problem. But, this would not be the "official" selinux-policy package > update. > > The problem in https://bugzilla.redhat.com/show_bug.cgi?id=533427 > impacts the abrt package's ability to function properly. The abrt > package is a really good new feature in Fedora 12 and should help > resolve problems more quickly since it provides a lot more information > than many users include in the handcrafted reports (myself included). > > The problem was reported on 6 November 2009 at 13:33 EDT and Dan Walsh > responded on 6 November 2008 at 14:38 EDT (a bit over an hour) that > the problem was fixed in selinux-policy-3.6.32-42.fc12.noarch and the > BZ report was closed as fixed in rawhide (perhaps closing this problem > so quickly was an error). > > Today is 17 November 2009 and Fedora 12 is GA but there is no "day > zero" fix for the problem ... not even in updates-testing (last I > checked around 1400 EST). I claim that something in the process of > getting fixes out (at least selinux-policy fixes) is broken. This is > what I am trying to get fixed so users do not set permissive mode or > simply disable selinux. > > Gene > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list We were change frozen, as F12 was about to get released. Further, F12 was beta until today, so you have no reason to complain, as it is not supported, and last not least, the mirrors are currently syncing loads of stuff, which will add a delay. Can this list now get back to selinux as a topic ? Fedora infra and releng issues are really off-topic here. Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Thawte Notary For Fedora related issues, please email me at: TSantore at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3388 bytes Desc: S/MIME Cryptographic Signature URL: From bruno at wolff.to Tue Nov 17 20:37:28 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 17 Nov 2009 14:37:28 -0600 Subject: BZ 533427 In-Reply-To: <4B030853.7020803@internexusconnect.net> References: <200911170806.41387.gene@czarc.net> <200911171231.20404.gene@czarc.net> <200911171514.28552.gene@czarc.net> <4B030853.7020803@internexusconnect.net> Message-ID: <20091117203728.GC5468@wolff.to> On Tue, Nov 17, 2009 at 20:32:19 +0000, Tristan Santore wrote: > We were change frozen, as F12 was about to get released. Further, > F12 was beta until today, so you have no reason to complain, as it > is not supported, and last not least, the mirrors are currently > syncing loads of stuff, which will add a delay. Stuff has been pushable through bodhi for about a week. > Can this list now get back to selinux as a topic ? Fedora infra and > releng issues are really off-topic here. I think he may have been hoping that Dan would intervene or at least comment why the policy was not suitable to be pushed. Gene, you might try raising this issue with the QA guys. I think they are more likely to feel as you do and try to get the problem fixed. From mike.cloaked at gmail.com Tue Nov 17 21:36:44 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Tue, 17 Nov 2009 13:36:44 -0800 (PST) Subject: equivalent contexts in f12 - has the command changed? Message-ID: <26396485.post@talk.nabble.com> I just tried to do semanage fcontext -a -e /home /opt/Local/home but it failed saying: -e not valid for fcontext objects Can't create lock file '/var/cache/abrt/pyhook-1258493827-2356.lock': Permission denied Traceback (most recent call last): File "/usr/sbin/semanage", line 501, in process_args(sys.argv[1:]) File "/usr/sbin/semanage", line 392, in process_args OBJECT.add_equal(target, equal) AttributeError: fcontextRecords instance has no attribute 'add_equal' Has this command become obsolete in f12? if so what is the equivalent that I should use? It used to work fine in f11. -- View this message in context: http://old.nabble.com/equivalent-contexts-in-f12---has-the-command-changed--tp26396485p26396485.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From mike.cloaked at gmail.com Tue Nov 17 22:06:39 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Tue, 17 Nov 2009 14:06:39 -0800 (PST) Subject: equivalent contexts in f12 - has the command changed? In-Reply-To: <26396485.post@talk.nabble.com> References: <26396485.post@talk.nabble.com> Message-ID: <26396569.post@talk.nabble.com> Mike Cloaked wrote: > > I just tried to do > semanage fcontext -a -e /home /opt/Local/home > > but it failed saying: > -e not valid for fcontext objects > Can't create lock file '/var/cache/abrt/pyhook-1258493827-2356.lock': > Permission denied > Traceback (most recent call last): > File "/usr/sbin/semanage", line 501, in > process_args(sys.argv[1:]) > File "/usr/sbin/semanage", line 392, in process_args > OBJECT.add_equal(target, equal) > AttributeError: fcontextRecords instance has no attribute 'add_equal' > > Has this command become obsolete in f12? if so what is the equivalent that > I should use? It used to work fine in f11. > ABRT kindly filed the following for me: https://bugzilla.redhat.com/show_bug.cgi?id=538197 -- View this message in context: http://old.nabble.com/equivalent-contexts-in-f12---has-the-command-changed--tp26396485p26396569.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From mike.cloaked at gmail.com Tue Nov 17 22:19:36 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Tue, 17 Nov 2009 14:19:36 -0800 (PST) Subject: equivalent contexts in f12 - has the command changed? In-Reply-To: <26396569.post@talk.nabble.com> References: <26396485.post@talk.nabble.com> <26396569.post@talk.nabble.com> Message-ID: <26397854.post@talk.nabble.com> Mike Cloaked wrote: > > > > Mike Cloaked wrote: >> >> I just tried to do >> semanage fcontext -a -e /home /opt/Local/home >> >> but it failed saying: >> -e not valid for fcontext objects >> Can't create lock file '/var/cache/abrt/pyhook-1258493827-2356.lock': >> Permission denied >> Traceback (most recent call last): >> File "/usr/sbin/semanage", line 501, in >> process_args(sys.argv[1:]) >> File "/usr/sbin/semanage", line 392, in process_args >> OBJECT.add_equal(target, equal) >> AttributeError: fcontextRecords instance has no attribute 'add_equal' >> >> Has this command become obsolete in f12? if so what is the equivalent >> that I should use? It used to work fine in f11. >> > > ABRT kindly filed the following for me: > https://bugzilla.redhat.com/show_bug.cgi?id=538197 > The command: semanage fcontext -l -C gives a similar denial.... -- View this message in context: http://old.nabble.com/equivalent-contexts-in-f12---has-the-command-changed--tp26396485p26397854.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From dwalsh at redhat.com Tue Nov 17 22:57:14 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 17 Nov 2009 17:57:14 -0500 Subject: BZ 533427 In-Reply-To: <200911171514.28552.gene@czarc.net> References: <200911170806.41387.gene@czarc.net> <200911171231.20404.gene@czarc.net> <200911171514.28552.gene@czarc.net> Message-ID: <4B032A4A.10000@redhat.com> On 11/17/2009 03:14 PM, Gene Czarcinski wrote: > On Tuesday 17 November 2009 12:43:58 Jason L Tibbitts III wrote: >>>>>>> "GC" == Gene Czarcinski writes: >> >> GC> Quickly?? Ten days to get a package pushed?? >> >> Wow. If you really really want it right this instant and aren't willing >> to wait for the volunteers that provide this operating system to you to >> work through everything they have to do to get Fedora 12 out the door in >> addition to the work of getting updates and such out for Fedora 11 and >> 10, why don't you: >> >> Check the source out of CVS and build it yourself? >> >> Download the build from koji? >> http://koji.fedoraproject.org/koji/packageinfo?packageID=32 and pick a >> build for the OS version you want. Probably >> http://koji.fedoraproject.org/koji/buildinfo?buildID=140508 >> >> It's all made available to you, all the source, the buildsystem, >> everything. If you simply can't wait for the updates process to catch >> up, you have plenty of other means to get the software. >> > > Unfortunately, you have missed the entire point of my email! > > Yes, I can go get an update from koji, or get the source and do it myself, or > simply apply the "fix" suggested by audit2allow, or set permissive mode, or > disable selinux. Any of these would get around the problem. But, this would > not be the "official" selinux-policy package update. > > The problem in https://bugzilla.redhat.com/show_bug.cgi?id=533427 impacts the > abrt package's ability to function properly. The abrt package is a really > good new feature in Fedora 12 and should help resolve problems more quickly > since it provides a lot more information than many users include in the > handcrafted reports (myself included). No it should not. abrt_t is a permissive domain. node=(removed) type=SYSCALL msg=audit(1257529975.949:596): arch=40000003 syscall=39 success=yes exit=0 a0=9779660 a1=1ed a2=38f6868 a3=9259050 items=0 ppid=17113 pid=17114 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="yum" exe="/usr/bin/python" subj=unconfined_u:system_r:abrt_t:s0 key=(null) If you look at the AVC you will see success=yes. Which indicates that the AVC did not block anything. So if abrt is not working properly for some reason, it is not SELinux causing the problem. > > The problem was reported on 6 November 2009 at 13:33 EDT and Dan Walsh > responded on 6 November 2008 at 14:38 EDT (a bit over an hour) that the > problem was fixed in selinux-policy-3.6.32-42.fc12.noarch and the BZ report was > closed as fixed in rawhide (perhaps closing this problem so quickly was an > error). > No the problem was we were frozen while F12 was moving to the Mirrors. I held off on posting an updated selinux-policy package til the last second, so I can fix as many bugs in F12 policy as possible soon after F12 ships (Today). I waited to request the package until I got Mondays AVC's in. Monday is the busiest day of the week for AVC/Bugzillas. Since I do not review them over the weekend. I posted to updates-testing at 2009-11-16 19:36:03 And it now says it is moving to the mirrors. > Today is 17 November 2009 and Fedora 12 is GA but there is no "day zero" fix > for the problem ... not even in updates-testing (last I checked around 1400 > EST). I claim that something in the process of getting fixes out (at least > selinux-policy fixes) is broken. This is what I am trying to get fixed so > users do not set permissive mode or simply disable selinux. > > Gene > > > > > -- > 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 Nov 17 22:59:02 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 17 Nov 2009 17:59:02 -0500 Subject: equivalent contexts in f12 - has the command changed? In-Reply-To: <26397854.post@talk.nabble.com> References: <26396485.post@talk.nabble.com> <26396569.post@talk.nabble.com> <26397854.post@talk.nabble.com> Message-ID: <4B032AB6.7020300@redhat.com> On 11/17/2009 05:19 PM, Mike Cloaked wrote: > > > > Mike Cloaked wrote: >> >> >> >> Mike Cloaked wrote: >>> >>> I just tried to do >>> semanage fcontext -a -e /home /opt/Local/home >>> >>> but it failed saying: >>> -e not valid for fcontext objects >>> Can't create lock file '/var/cache/abrt/pyhook-1258493827-2356.lock': >>> Permission denied >>> Traceback (most recent call last): >>> File "/usr/sbin/semanage", line 501, in >>> process_args(sys.argv[1:]) >>> File "/usr/sbin/semanage", line 392, in process_args >>> OBJECT.add_equal(target, equal) >>> AttributeError: fcontextRecords instance has no attribute 'add_equal' >>> >>> Has this command become obsolete in f12? if so what is the equivalent >>> that I should use? It used to work fine in f11. >>> >> >> ABRT kindly filed the following for me: >> https://bugzilla.redhat.com/show_bug.cgi?id=538197 >> > > The command: > semanage fcontext -l -C > gives a similar denial.... Can you grab the policycoreutils package out of updates-testing and check whether it fixes your problem. From mike.cloaked at gmail.com Wed Nov 18 07:31:42 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Tue, 17 Nov 2009 23:31:42 -0800 (PST) Subject: equivalent contexts in f12 - has the command changed? In-Reply-To: <4B032AB6.7020300@redhat.com> References: <26396485.post@talk.nabble.com> <26396569.post@talk.nabble.com> <26397854.post@talk.nabble.com> <4B032AB6.7020300@redhat.com> Message-ID: <26403502.post@talk.nabble.com> Daniel J Walsh wrote: > > >> gives a similar denial.... > Can you grab the policycoreutils package out of updates-testing and check > whether it fixes your problem. > > OK I will try that tonight when I get back to the machine. -- View this message in context: http://old.nabble.com/equivalent-contexts-in-f12---has-the-command-changed--tp26396485p26403502.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From mike.cloaked at gmail.com Wed Nov 18 22:00:30 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Wed, 18 Nov 2009 14:00:30 -0800 (PST) Subject: equivalent contexts in f12 - has the command changed? In-Reply-To: <26403502.post@talk.nabble.com> References: <26396485.post@talk.nabble.com> <26396569.post@talk.nabble.com> <26397854.post@talk.nabble.com> <4B032AB6.7020300@redhat.com> <26403502.post@talk.nabble.com> Message-ID: <26416566.post@talk.nabble.com> Mike Cloaked wrote: > > > > Daniel J Walsh wrote: >> >> >>> gives a similar denial.... >> Can you grab the policycoreutils package out of updates-testing and check >> whether it fixes your problem. >> >> > > OK I will try that tonight when I get back to the machine. > Yes that fixed it - thank you. -- View this message in context: http://old.nabble.com/equivalent-contexts-in-f12---has-the-command-changed--tp26396485p26416566.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From gene at czarc.net Wed Nov 18 22:44:45 2009 From: gene at czarc.net (Gene Czarcinski) Date: Wed, 18 Nov 2009 17:44:45 -0500 Subject: BZ 533427 In-Reply-To: <20091117203728.GC5468@wolff.to> References: <200911170806.41387.gene@czarc.net> <4B030853.7020803@internexusconnect.net> <20091117203728.GC5468@wolff.to> Message-ID: <200911181744.45663.gene@czarc.net> On Tuesday 17 November 2009 15:37:28 Bruno Wolff III wrote: > On Tue, Nov 17, 2009 at 20:32:19 +0000, > > Tristan Santore wrote: > > We were change frozen, as F12 was about to get released. Further, > > F12 was beta until today, so you have no reason to complain, as it > > is not supported, and last not least, the mirrors are currently > > syncing loads of stuff, which will add a delay. > > Stuff has been pushable through bodhi for about a week. > > > Can this list now get back to selinux as a topic ? Fedora infra and > > releng issues are really off-topic here. > > I think he may have been hoping that Dan would intervene or at least > comment why the policy was not suitable to be pushed. Yes! > > Gene, you might try raising this issue with the QA guys. I think they are > more likely to feel as you do and try to get the problem fixed. I thought of posting this to the test list also but I normally avoid posting the same problem to multiple lists. I will do that now. As far as F12 only being GA recently, a an individual who has been installing the development spins (alpha, beta, and all of the RCx), I have been running F12 since RC3 or RC4 timeframe and anyone else could also ... especially with F12 updates and F12 updates-testing being available in parallel. Gene From bruno at wolff.to Wed Nov 18 23:03:00 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 18 Nov 2009 17:03:00 -0600 Subject: BZ 533427 In-Reply-To: <200911181744.45663.gene@czarc.net> References: <200911170806.41387.gene@czarc.net> <4B030853.7020803@internexusconnect.net> <20091117203728.GC5468@wolff.to> <200911181744.45663.gene@czarc.net> Message-ID: <20091118230300.GA30391@wolff.to> On Wed, Nov 18, 2009 at 17:44:45 -0500, Gene Czarcinski wrote: > > I thought of posting this to the test list also but I normally avoid posting > the same problem to multiple lists. I will do that now. > > As far as F12 only being GA recently, a an individual who has been installing > the development spins (alpha, beta, and all of the RCx), I have been running > F12 since RC3 or RC4 timeframe and anyone else could also ... especially with > F12 updates and F12 updates-testing being available in parallel. It looks like the update is out now. I got 3.6.32-46 today in updates or updates-testing, so it looks like its available to more normal people now. (Though the mirrors may need some time to get it because of the higher than normal load.) From dwalsh at redhat.com Thu Nov 19 22:11:27 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 19 Nov 2009 17:11:27 -0500 Subject: BZ 533427 In-Reply-To: <20091118230300.GA30391@wolff.to> References: <200911170806.41387.gene@czarc.net> <4B030853.7020803@internexusconnect.net> <20091117203728.GC5468@wolff.to> <200911181744.45663.gene@czarc.net> <20091118230300.GA30391@wolff.to> Message-ID: <4B05C28F.4070709@redhat.com> On 11/18/2009 06:03 PM, Bruno Wolff III wrote: > On Wed, Nov 18, 2009 at 17:44:45 -0500, > Gene Czarcinski wrote: >> >> I thought of posting this to the test list also but I normally avoid posting >> the same problem to multiple lists. I will do that now. >> >> As far as F12 only being GA recently, a an individual who has been installing >> the development spins (alpha, beta, and all of the RCx), I have been running >> F12 since RC3 or RC4 timeframe and anyone else could also ... especially with >> F12 updates and F12 updates-testing being available in parallel. > > It looks like the update is out now. I got 3.6.32-46 today in updates or > updates-testing, so it looks like its available to more normal people now. > (Though the mirrors may need some time to get it because of the higher than > normal load.) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > I have released it out of updated-testing and tomorrow will put the next update into updates-testing. Probably will do this every Friday for the next few weeks, until the bugzillas calm down. Of course if people give the thumbs up the release will get pushed sooner. From mschenck at limewire.com Thu Nov 19 23:03:50 2009 From: mschenck at limewire.com (Michael Schenck) Date: Thu, 19 Nov 2009 18:03:50 -0500 Subject: Selinux + qemu + lvm issues Message-ID: <4B05CED6.4010507@limewire.com> I'm running CentOS 5.4 and am trying to allow qemu to use LVM LV's for storage. I created this file form audit2allow: module kvm 1.0; require { type qemu_t; type fixed_disk_device_t; class blk_file read; class blk_file getattr; } allow qemu_t fixed_disk_device_t:blk_file { read getattr }; I use this script to load it: #!/bin/sh # Puppet Template # Serial: 2008120401 SE_LOCAL=/etc/selinux/local /usr/bin/checkmodule -M -m -o ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.te /usr/bin/semodule_package -o ${SE_LOCAL}/kvm.pp -m ${SE_LOCAL}/kvm.mod /usr/sbin/semodule -i ${SE_LOCAL}/kvm.pp /bin/rm ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.pp When I try to load it, it fails with the following error: [root at HostKVM2:/etc/selinux/local]# ./kvm-setup.sh /usr/bin/checkmodule: loading policy configuration from /etc/selinux/local/kvm.te /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 6) to /etc/selinux/local/kvm.mod libsepol.check_assertion_helper: assertion on line 0 violated by allow qemu_t fixed_disk_device_t:blk_file { read }; libsepol.check_assertions: 1 assertion violations occured libsemanage.semanage_expand_sandbox: Expand module failed /usr/sbin/semodule: Failed! Can someone tell me what I'm doing wrong? Best regards, Michael Schenck -- Michael Schenck - Senior Systems Administrator - LimeWire LLC Phone: 212-775-3046 E-mail: mschenck at limewire.com From domg472 at gmail.com Thu Nov 19 23:37:51 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 20 Nov 2009 00:37:51 +0100 Subject: Selinux + qemu + lvm issues In-Reply-To: <4B05CED6.4010507@limewire.com> References: <4B05CED6.4010507@limewire.com> Message-ID: <1258673871.4751.9.camel@localhost> On Thu, 2009-11-19 at 18:03 -0500, Michael Schenck wrote: > I'm running CentOS 5.4 and am trying to allow qemu to use LVM LV's for > storage. I created this file form audit2allow: > > module kvm 1.0; > > require { > type qemu_t; > type fixed_disk_device_t; > class blk_file read; > class blk_file getattr; > } > > allow qemu_t fixed_disk_device_t:blk_file { read getattr }; > > I use this script to load it: > #!/bin/sh > > # Puppet Template > # Serial: 2008120401 > > SE_LOCAL=/etc/selinux/local > > /usr/bin/checkmodule -M -m -o ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.te > /usr/bin/semodule_package -o ${SE_LOCAL}/kvm.pp -m ${SE_LOCAL}/kvm.mod > /usr/sbin/semodule -i ${SE_LOCAL}/kvm.pp > > /bin/rm ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.pp > > When I try to load it, it fails with the following error: > [root at HostKVM2:/etc/selinux/local]# ./kvm-setup.sh > /usr/bin/checkmodule: loading policy configuration from > /etc/selinux/local/kvm.te > /usr/bin/checkmodule: policy configuration loaded > /usr/bin/checkmodule: writing binary representation (version 6) to > /etc/selinux/local/kvm.mod > libsepol.check_assertion_helper: assertion on line 0 violated by allow > qemu_t fixed_disk_device_t:blk_file { read }; > libsepol.check_assertions: 1 assertion violations occured > libsemanage.semanage_expand_sandbox: Expand module failed > /usr/sbin/semodule: Failed! > > > Can someone tell me what I'm doing wrong? Why not just label the block device properly like everyone else? chcon -t virt_image_t /pathto/blk_file > Best regards, > Michael Schenck > From mschenck at limewire.com Fri Nov 20 14:45:55 2009 From: mschenck at limewire.com (Michael Schenck) Date: Fri, 20 Nov 2009 09:45:55 -0500 Subject: Selinux + qemu + lvm issues In-Reply-To: <1258673871.4751.9.camel@localhost> References: <4B05CED6.4010507@limewire.com> <1258673871.4751.9.camel@localhost> Message-ID: <4B06ABA3.20108@limewire.com> I could do that, The downside is that this will have to be done for every new virtual machine. - Michael Schenck On 11/19/2009 06:37 PM, Dominick Grift wrote: > On Thu, 2009-11-19 at 18:03 -0500, Michael Schenck wrote: > >> I'm running CentOS 5.4 and am trying to allow qemu to use LVM LV's for >> storage. I created this file form audit2allow: >> >> module kvm 1.0; >> >> require { >> type qemu_t; >> type fixed_disk_device_t; >> class blk_file read; >> class blk_file getattr; >> } >> >> allow qemu_t fixed_disk_device_t:blk_file { read getattr }; >> >> I use this script to load it: >> #!/bin/sh >> >> # Puppet Template >> # Serial: 2008120401 >> >> SE_LOCAL=/etc/selinux/local >> >> /usr/bin/checkmodule -M -m -o ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.te >> /usr/bin/semodule_package -o ${SE_LOCAL}/kvm.pp -m ${SE_LOCAL}/kvm.mod >> /usr/sbin/semodule -i ${SE_LOCAL}/kvm.pp >> >> /bin/rm ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.pp >> >> When I try to load it, it fails with the following error: >> [root at HostKVM2:/etc/selinux/local]# ./kvm-setup.sh >> /usr/bin/checkmodule: loading policy configuration from >> /etc/selinux/local/kvm.te >> /usr/bin/checkmodule: policy configuration loaded >> /usr/bin/checkmodule: writing binary representation (version 6) to >> /etc/selinux/local/kvm.mod >> libsepol.check_assertion_helper: assertion on line 0 violated by allow >> qemu_t fixed_disk_device_t:blk_file { read }; >> libsepol.check_assertions: 1 assertion violations occured >> libsemanage.semanage_expand_sandbox: Expand module failed >> /usr/sbin/semodule: Failed! >> >> >> Can someone tell me what I'm doing wrong? >> > Why not just label the block device properly like everyone else? > > chcon -t virt_image_t /pathto/blk_file > > >> Best regards, >> Michael Schenck >> >> > > -- Michael Schenck - Senior Systems Administrator - LimeWire LLC Phone: 212-775-3046 E-mail: mschenck at limewire.com From domg472 at gmail.com Fri Nov 20 14:51:21 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 20 Nov 2009 15:51:21 +0100 Subject: Selinux + qemu + lvm issues In-Reply-To: <4B06ABA3.20108@limewire.com> References: <4B05CED6.4010507@limewire.com> <1258673871.4751.9.camel@localhost> <4B06ABA3.20108@limewire.com> Message-ID: <4B06ACE9.1050100@gmail.com> On 11/20/2009 03:45 PM, Michael Schenck wrote: > I could do that, The downside is that this will have to be done for > every new virtual machine. in current fedora and el6 it get done automatically. i heard someone mention that this feature may also get implemented in a future el5 update. until then its best to semanage / chcon , virt_image_t > - Michael Schenck > > On 11/19/2009 06:37 PM, Dominick Grift wrote: >> On Thu, 2009-11-19 at 18:03 -0500, Michael Schenck wrote: >> >>> I'm running CentOS 5.4 and am trying to allow qemu to use LVM LV's for >>> storage. I created this file form audit2allow: >>> >>> module kvm 1.0; >>> >>> require { >>> type qemu_t; >>> type fixed_disk_device_t; >>> class blk_file read; >>> class blk_file getattr; >>> } >>> >>> allow qemu_t fixed_disk_device_t:blk_file { read getattr }; >>> >>> I use this script to load it: >>> #!/bin/sh >>> >>> # Puppet Template >>> # Serial: 2008120401 >>> >>> SE_LOCAL=/etc/selinux/local >>> >>> /usr/bin/checkmodule -M -m -o ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.te >>> /usr/bin/semodule_package -o ${SE_LOCAL}/kvm.pp -m ${SE_LOCAL}/kvm.mod >>> /usr/sbin/semodule -i ${SE_LOCAL}/kvm.pp >>> >>> /bin/rm ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.pp >>> >>> When I try to load it, it fails with the following error: >>> [root at HostKVM2:/etc/selinux/local]# ./kvm-setup.sh >>> /usr/bin/checkmodule: loading policy configuration from >>> /etc/selinux/local/kvm.te >>> /usr/bin/checkmodule: policy configuration loaded >>> /usr/bin/checkmodule: writing binary representation (version 6) to >>> /etc/selinux/local/kvm.mod >>> libsepol.check_assertion_helper: assertion on line 0 violated by allow >>> qemu_t fixed_disk_device_t:blk_file { read }; >>> libsepol.check_assertions: 1 assertion violations occured >>> libsemanage.semanage_expand_sandbox: Expand module failed >>> /usr/sbin/semodule: Failed! >>> >>> >>> Can someone tell me what I'm doing wrong? >>> >> Why not just label the block device properly like everyone else? >> >> chcon -t virt_image_t /pathto/blk_file >> >> >>> Best regards, >>> Michael Schenck >>> >>> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From mschenck at limewire.com Fri Nov 20 14:57:34 2009 From: mschenck at limewire.com (Michael Schenck) Date: Fri, 20 Nov 2009 09:57:34 -0500 Subject: Selinux + qemu + lvm issues In-Reply-To: <4B06ACE9.1050100@gmail.com> References: <4B05CED6.4010507@limewire.com> <1258673871.4751.9.camel@localhost> <4B06ABA3.20108@limewire.com> <4B06ACE9.1050100@gmail.com> Message-ID: <4B06AE5E.4020907@limewire.com> Ok great! Thanks a lot. On 11/20/2009 09:51 AM, Dominick Grift wrote: > rent fedora and el6 it get done automatical -- Michael Schenck - Senior Systems Administrator - LimeWire LLC Phone: 212-775-3046 E-mail: mschenck at limewire.com From dwalsh at redhat.com Fri Nov 20 14:58:04 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 20 Nov 2009 09:58:04 -0500 Subject: Selinux + qemu + lvm issues In-Reply-To: <4B06ACE9.1050100@gmail.com> References: <4B05CED6.4010507@limewire.com> <1258673871.4751.9.camel@localhost> <4B06ABA3.20108@limewire.com> <4B06ACE9.1050100@gmail.com> Message-ID: <4B06AE7C.4020603@redhat.com> On 11/20/2009 09:51 AM, Dominick Grift wrote: > On 11/20/2009 03:45 PM, Michael Schenck wrote: >> I could do that, The downside is that this will have to be done for >> every new virtual machine. > > in current fedora and el6 it get done automatically. i heard someone > mention that this feature may also get implemented in a future el5 update. > > until then its best to semanage / chcon , virt_image_t > >> - Michael Schenck >> >> On 11/19/2009 06:37 PM, Dominick Grift wrote: >>> On Thu, 2009-11-19 at 18:03 -0500, Michael Schenck wrote: >>> >>>> I'm running CentOS 5.4 and am trying to allow qemu to use LVM LV's for >>>> storage. I created this file form audit2allow: >>>> >>>> module kvm 1.0; >>>> >>>> require { >>>> type qemu_t; >>>> type fixed_disk_device_t; >>>> class blk_file read; >>>> class blk_file getattr; >>>> } >>>> >>>> allow qemu_t fixed_disk_device_t:blk_file { read getattr }; >>>> >>>> I use this script to load it: >>>> #!/bin/sh >>>> >>>> # Puppet Template >>>> # Serial: 2008120401 >>>> >>>> SE_LOCAL=/etc/selinux/local >>>> >>>> /usr/bin/checkmodule -M -m -o ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.te >>>> /usr/bin/semodule_package -o ${SE_LOCAL}/kvm.pp -m ${SE_LOCAL}/kvm.mod >>>> /usr/sbin/semodule -i ${SE_LOCAL}/kvm.pp >>>> >>>> /bin/rm ${SE_LOCAL}/kvm.mod ${SE_LOCAL}/kvm.pp >>>> >>>> When I try to load it, it fails with the following error: >>>> [root at HostKVM2:/etc/selinux/local]# ./kvm-setup.sh >>>> /usr/bin/checkmodule: loading policy configuration from >>>> /etc/selinux/local/kvm.te >>>> /usr/bin/checkmodule: policy configuration loaded >>>> /usr/bin/checkmodule: writing binary representation (version 6) to >>>> /etc/selinux/local/kvm.mod >>>> libsepol.check_assertion_helper: assertion on line 0 violated by allow >>>> qemu_t fixed_disk_device_t:blk_file { read }; >>>> libsepol.check_assertions: 1 assertion violations occured >>>> libsemanage.semanage_expand_sandbox: Expand module failed >>>> /usr/sbin/semodule: Failed! >>>> >>>> >>>> Can someone tell me what I'm doing wrong? >>>> >>> Why not just label the block device properly like everyone else? >>> >>> chcon -t virt_image_t /pathto/blk_file >>> >>> >>>> Best regards, >>>> Michael Schenck >>>> >>>> >>> >>> >> >> > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Yes if you run virtual machine on blk devices currently in RHEL5 you will need to label the blk devices. svirt does this automatically in F11 and beyond and in RHEL6. We are hoping to get the functionality back into RHEL5.6. From domg472 at gmail.com Sat Nov 21 13:42:49 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 21 Nov 2009 14:42:49 +0100 Subject: Add new ksm domain. Message-ID: <4B07EE59.9080508@gmail.com> Attached is ksm module. If virtualization is installed then ksm and ksmtuned services are enabled by default. Currently they run in initrc_t. It seems the initrc_t domain has sufficient permissions for ksm tune daemon. The policy is not thoroughly tested yet and so i left ksmtuned_t permissive. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ksm.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ksm.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ksm.te URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From zaina.afoulki at ensi-bourges.fr Sat Nov 21 20:41:07 2009 From: zaina.afoulki at ensi-bourges.fr (Zaina AFOULKI) Date: Sat, 21 Nov 2009 21:41:07 +0100 (CET) Subject: List of all alert types Message-ID: <4dfdfd1c0cfd24e4cee7ab8dd7852c83.squirrel@webmail.ensi-bourges.fr> Hello, I'm quite new to using SELinux, I noticed that each alert in /var/log/audit/audit.log starts with the type, examples : type=USER_ROLE_CHANGE type=USER_START type=USER_AUTH I'm trying to develop a graphical interface for SELinux alerts... Is there a way I can get the list of all types ? I searched for a while and couldn't find it, your help will be greatly appreciated. Thanks in advance, -- Zaina AFOULKI ?tudiante ? l'Ecole Nationale Sup?rieure d'Ing?nieurs de Bourges. 1?re ann?e S?curit? et Technologies Informatiques From domg472 at gmail.com Sun Nov 22 10:39:37 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 22 Nov 2009 11:39:37 +0100 Subject: Add new ksm domain. In-Reply-To: <4B07EE59.9080508@gmail.com> References: <4B07EE59.9080508@gmail.com> Message-ID: <4B0914E9.7050708@gmail.com> On 11/21/2009 02:42 PM, Dominick Grift wrote: > Attached is ksm module. If virtualization is installed then ksm and > ksmtuned services are enabled by default. > > Currently they run in initrc_t. It seems the initrc_t domain has > sufficient permissions for ksm tune daemon. > > The policy is not thoroughly tested yet and so i left ksmtuned_t permissive. Patch: allow ksmtuned_t self:capability sys_ptrace; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From jonathanhoover at hotmail.com Sun Nov 22 16:39:41 2009 From: jonathanhoover at hotmail.com (Jonathan Hoover) Date: Sun, 22 Nov 2009 10:39:41 -0600 Subject: Denial Msg - apache, mogrify, perl, cgi, postgres, setenforce delay Message-ID: Hello all, One of our developers has a fairly simple script that uploads an image to a server, via a cgi perl script. The box is Fedora 11, all up to date. He is using the CGI and the File::Basename perl modules. He is also using mogrify from the ImageMagick package to change the width of the uploaded file, and save it as a thumbnail. This is called in perl via system("mogrify $args"). This seems to succeed, as the thumbnail file is created and valid. Finally, a record is added to a postgresql database. What's puzzling is that with SELinux in permissive mode, all goes as expected, with the following messages logged. With it set to enforcing, though, we get an error from postgresql about more expressions than target columns, with what appears to be the filehandle to the image. >From /var/log/messages: Nov 22 10:16:02 kilby setroubleshoot: SELinux is preventing mogrify (httpd_sys_script_t) "getsched" httpd_sys_script_t. For complete SELinux messages. run sealert -l 201e87d5-7250-4a96-a3ab-6b148b40f206 >From /var/log/audit/audit.log, these two: type=AVC msg=audit(1258906560.216:220051): avc: denied { getsched } for pid=31641 comm="mogrify" scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:system_r:httpd_sys_script_t:s0 tclass=process type=SYSCALL msg=audit(1258906560.216:220051): arch=40000003 syscall=242 success=no exit=-13 a0=7b99 a1=80 a2=bfe5a490 a3=80 items=0 ppid=31638 pid=31641 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=433 comm="mogrify" exe="/usr/bin/mogrify" subj=unconfined_u:system_r:httpd_sys_script_t:s0 key=(null) >From my apache.err.log, only when SELinux is set to enforcing: [Sat Nov 21 17:08:27 2009] [error] [client 64.198.x.x] DBD::Pg::st execute failed: ERROR: INSERT has more expressions than target columns at /www/website/htdocs/modules//dbfunc.pl line 23, line 192., referer: http://64.198.x.x/add-listing.cgi So, a few questions: 1. I notice a somewhat random delay of 10 to 30 minutes before the script works after a "setenforce 0". Likewise, it takes some amount of time after a "setenforce 1" before the script breaks. Is there supposed to be a delay? This makes troubleshooting very difficult, because you don't really know if it's enforcing yet or not. I noticed this message in /var/log/messages, and thought it might be related to the delay: Nov 22 09:57:33 kilby dbus: Can't send to audit system: USER_AVC avc: received setenforce notice (enforcing=1)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?) 2. What is the "getsched" action that mogrify is attempting? 3. Why the httpd_sys_script_t context? 4. Should the file upload and mogrify be creating files with a httpd_sys_content_rw_t context? The "rw" read/write part I was a little concerned by. 5. Any idea why this is throwing a postgres error? I would have expected the mogrify to not work given the error messages in /var/log/messages and /var/log/audit/audit.log - but that works just fine. Plus, the INSERT seems to be just fine actually, as I have the developer spitting that out in the page that is returned. Thanks in advance, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Sun Nov 22 18:53:13 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 22 Nov 2009 19:53:13 +0100 Subject: Denial Msg - apache, mogrify, perl, cgi, postgres, setenforce delay In-Reply-To: References: Message-ID: <1258915993.12576.16.camel@localhost> On Sun, 2009-11-22 at 10:39 -0600, Jonathan Hoover wrote: > Hello all, > > One of our developers has a fairly simple script that uploads an image > to a server, via a cgi perl script. The box is Fedora 11, all up to > date. He is using the CGI and the File::Basename perl modules. He is > also using mogrify from the ImageMagick package to change the width of > the uploaded file, and save it as a thumbnail. This is called in perl > via system("mogrify $args"). This seems to succeed, as the thumbnail > file is created and valid. Finally, a record is added to a postgresql > database. > > What's puzzling is that with SELinux in permissive mode, all goes as > expected, with the following messages logged. With it set to > enforcing, though, we get an error from postgresql about more > expressions than target columns, with what appears to be the > filehandle to the image. > > >From /var/log/messages: > Nov 22 10:16:02 kilby setroubleshoot: SELinux is preventing mogrify > (httpd_sys_script_t) "getsched" httpd_sys_script_t. For complete > SELinux messages. run sealert -l 201e87d5-7250-4a96-a3ab-6b148b40f206 > > >From /var/log/audit/audit.log, these two: > type=AVC msg=audit(1258906560.216:220051): avc: denied { getsched } > for pid=31641 comm="mogrify" > scontext=unconfined_u:system_r:httpd_sys_script_t:s0 > tcontext=unconfined_u:system_r:httpd_sys_script_t:s0 tclass=process > > type=SYSCALL msg=audit(1258906560.216:220051): arch=40000003 > syscall=242 success=no exit=-13 a0=7b99 a1=80 a2=bfe5a490 a3=80 > items=0 ppid=31638 pid=31641 auid=0 uid=48 gid=48 euid=48 suid=48 > fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=433 comm="mogrify" > exe="/usr/bin/mogrify" > subj=unconfined_u:system_r:httpd_sys_script_t:s0 key=(null) > > >From my apache.err.log, only when SELinux is set to enforcing: > [Sat Nov 21 17:08:27 2009] [error] [client 64.198.x.x] DBD::Pg::st > execute failed: ERROR: INSERT has more expressions than target > columns at /www/website/htdocs/modules//dbfunc.pl line 23, > line 192., referer: > http://64.198.x.x/add-listing.cgi > > So, a few questions: > > 1. I notice a somewhat random delay of 10 to 30 minutes before the > script works after a "setenforce 0". Likewise, it takes some amount of > time after a "setenforce 1" before the script breaks. Is there > supposed to be a delay? This makes troubleshooting very difficult, > because you don't really know if it's enforcing yet or not. I noticed > this message in /var/log/messages, and thought it might be related to > the delay: Nov 22 09:57:33 kilby dbus: Can't send to audit system: > USER_AVC avc: received setenforce notice (enforcing=1)#012: > exe="?" (sauid=81, hostname=?, addr=?, terminal=?) The delay is (likely) not SELinux related no. The message reflects a bug in dbus and this is unrelated and not harmful. > 2. What is the "getsched" action that mogrify is attempting? get schedule i believe. It is a permission. "The getpriority, sched_getscheduler, and sched_getparam calls are controlled using the getsched permission." > 3. Why the httpd_sys_script_t context? This is the confined environment for apache (default) system scripts. files in /var/www/cgi-bin. > 4. Should the file upload and mogrify be creating files with a > httpd_sys_content_rw_t context? The "rw" read/write part I was a > little concerned by. Yes the confined apache system environment is allowed to only create objects in locations labelled httpd_sys_content_rw_t and files created there automatically inherit the type of the parent location. > 5. Any idea why this is throwing a postgres error? I would have > expected the mogrify to not work given the error messages > in /var/log/messages and /var/log/audit/audit.log - but that works > just fine. Plus, the INSERT seems to be just fine actually, as I have > the developer spitting that out in the page that is returned. I guess mogrify could not do its job good enough (if at all) for postgresql to accept it due to the getsched permission missing. You could decide you modify the sys script environment to allow the getsched permission or you could distribute your webapp with a customized tailor made policy (environment/domain) module for the script. This way consumers will not have to alter existing environments/domains, but they will be required to install the policy module that you have included with your distribution. Since your webapp is required to create objects, your consumers will have to configure SELinux to allow it to be able to do so without a custom module as well. By including a custom policy you can take care of both policy and labeling for them. > Thanks in advance, > Jon > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From m.roth at 5-cent.us Mon Nov 23 19:20:36 2009 From: m.roth at 5-cent.us (m.roth at 5-cent.us) Date: Mon, 23 Nov 2009 12:20:36 -0700 (MST) Subject: selinux and smagent Message-ID: <60697.165.112.92.128.1259004036.squirrel@host290.hostmonster.com> Apologies if this has been covered a million times; if so, please point me to the post or thread that answers this. selinux has an error-handling problem. It complains (we're running it in permissive mode, or it would be real grief): host= type=AVC msg=audit(1259003353.282:46730): avc: denied { write } for pid=27369 comm="LLAWP" path="/var/log/httpd/smagent.log" dev=sda3 ino=46107891 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:httpd_log_t:s0 tclass=file host= type=SYSCALL msg=audit(1259003353.282:46730): arch=c000003e syscall=1 per=400000 success=yes exit=124 a0=15 a1=2aaaab249000 a2=7c a3=7473657571655273 items=0 ppid=1 pid=27369 auid=32870 uid=48 gid=0 euid=48 suid=48 fsuid=48 egid=0 sgid=0 fsgid=0 tty=(none) ses=4473 comm="LLAWP" exe="/usr/local/opt/smwa-6qmr5-cr013-rhas30-x86-64/webagent/bin/LLAWP" subj=user_u:system_r:httpd_t:s0 key=(null) Now, running sealert tells me to set httpd_unified to 1. I've done this, several times, and no joy, so obviously it is *not* the actual error. I've also tried restorecon. So, what's the actual error? I'm really tired of this, on more than one server, cluttering my logs.... Thanks in advance. mark From dwalsh at redhat.com Mon Nov 23 19:38:38 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 Nov 2009 14:38:38 -0500 Subject: selinux and smagent In-Reply-To: <60697.165.112.92.128.1259004036.squirrel@host290.hostmonster.com> References: <60697.165.112.92.128.1259004036.squirrel@host290.hostmonster.com> Message-ID: <4B0AE4BE.2080508@redhat.com> On 11/23/2009 02:20 PM, m.roth at 5-cent.us wrote: > Apologies if this has been covered a million times; if so, please point me > to the post or thread that answers this. > > selinux has an error-handling problem. It complains (we're running it in > permissive mode, or it would be real grief): > host= type=AVC msg=audit(1259003353.282:46730): avc: denied { > write } for pid=27369 comm="LLAWP" path="/var/log/httpd/smagent.log" > dev=sda3 ino=46107891 scontext=user_u:system_r:httpd_t:s0 > tcontext=user_u:object_r:httpd_log_t:s0 tclass=file > > host= type=SYSCALL msg=audit(1259003353.282:46730): > arch=c000003e syscall=1 per=400000 success=yes exit=124 a0=15 > a1=2aaaab249000 a2=7c a3=7473657571655273 items=0 ppid=1 pid=27369 > auid=32870 uid=48 gid=0 euid=48 suid=48 fsuid=48 egid=0 sgid=0 fsgid=0 > tty=(none) ses=4473 comm="LLAWP" > exe="/usr/local/opt/smwa-6qmr5-cr013-rhas30-x86-64/webagent/bin/LLAWP" > subj=user_u:system_r:httpd_t:s0 key=(null) > > Now, running sealert tells me to set httpd_unified to 1. I've done this, > several times, and no joy, so obviously it is *not* the actual error. > > I've also tried restorecon. > > So, what's the actual error? I'm really tired of this, on more than one > server, cluttering my logs.... > > Thanks in advance. > > mark > > -- > 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 Mon Nov 23 19:38:46 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 Nov 2009 14:38:46 -0500 Subject: selinux and smagent In-Reply-To: <60697.165.112.92.128.1259004036.squirrel@host290.hostmonster.com> References: <60697.165.112.92.128.1259004036.squirrel@host290.hostmonster.com> Message-ID: <4B0AE4C6.8000208@redhat.com> On 11/23/2009 02:20 PM, m.roth at 5-cent.us wrote: > Apologies if this has been covered a million times; if so, please point me > to the post or thread that answers this. > > selinux has an error-handling problem. It complains (we're running it in > permissive mode, or it would be real grief): > host= type=AVC msg=audit(1259003353.282:46730): avc: denied { > write } for pid=27369 comm="LLAWP" path="/var/log/httpd/smagent.log" > dev=sda3 ino=46107891 scontext=user_u:system_r:httpd_t:s0 > tcontext=user_u:object_r:httpd_log_t:s0 tclass=file > > host= type=SYSCALL msg=audit(1259003353.282:46730): > arch=c000003e syscall=1 per=400000 success=yes exit=124 a0=15 > a1=2aaaab249000 a2=7c a3=7473657571655273 items=0 ppid=1 pid=27369 > auid=32870 uid=48 gid=0 euid=48 suid=48 fsuid=48 egid=0 sgid=0 fsgid=0 > tty=(none) ses=4473 comm="LLAWP" > exe="/usr/local/opt/smwa-6qmr5-cr013-rhas30-x86-64/webagent/bin/LLAWP" > subj=user_u:system_r:httpd_t:s0 key=(null) > > Now, running sealert tells me to set httpd_unified to 1. I've done this, > several times, and no joy, so obviously it is *not* the actual error. > > I've also tried restorecon. > > So, what's the actual error? I'm really tired of this, on more than one > server, cluttering my logs.... > > Thanks in advance. > > mark > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Have you reported this bug to webagent? They should be opening the log file for append, not for write. Simplest thing you could do is build a loadable policy module to allow this, or dontaudit it # grep avc /var/log/audit/audit.log | audit2allow -M mywebagent # semodule -i mywebagent.pp Then you can install the mywebagent.pp file on all offending machines. From domg472 at gmail.com Mon Nov 23 19:42:19 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 23 Nov 2009 20:42:19 +0100 Subject: selinux and smagent In-Reply-To: <60697.165.112.92.128.1259004036.squirrel@host290.hostmonster.com> References: <60697.165.112.92.128.1259004036.squirrel@host290.hostmonster.com> Message-ID: <20091123194218.GA2458@localhost.localdomain> On Mon, Nov 23, 2009 at 12:20:36PM -0700, m.roth at 5-cent.us wrote: > Apologies if this has been covered a million times; if so, please point me > to the post or thread that answers this. > > selinux has an error-handling problem. It complains (we're running it in > permissive mode, or it would be real grief): > host= type=AVC msg=audit(1259003353.282:46730): avc: denied { > write } for pid=27369 comm="LLAWP" path="/var/log/httpd/smagent.log" > dev=sda3 ino=46107891 scontext=user_u:system_r:httpd_t:s0 > tcontext=user_u:object_r:httpd_log_t:s0 tclass=file SELinux permissive mode means all access is granted but "would be" denials are logged as if they were denied. With that said lets look at the denial: your webapp (or whatever LLAWP is) is trying to write to the smagent.log file that is located in /var/log/httpd/smagent.log. httpd (apache) and webapps that run with apaches permission are not allowed to "write" to their log files. This is because a compromized apache or webapp could erase its trail from the log file. Apache knows this ans instead of writing, apache opens the log file for "append" which it is allowed (apache and webapp can append to their log file but not write) The best solution to this problem is to tell the author/maintainer of the webapp to fix his code to open the smagent.log file for append instead of write. A not so good solution is to label the smagent.log file with a type that apache/ and webapps can write to (remember that the webapp can then also remove entries from the log file) I wouldnt trust that webapp knowing that it opens the log file for writing, as this tells me the author of the code may not be focussing on security or doesnt give security as much attention as it deserves. chcon -t httpd_sys_content_rw_t /var/log/httpd/smagent.log setsebool allow_httpd_anon_write on would allow apache and any webapps that run with apaches privileges to write tothe smagent.log file This may not work in the long run. if the webapp tries to rotate the log file. (it may write to it but it may not create new log files in that location) Also the labelling that results from chcon is not persistent. Meaning if you run restorecon /var/log/httpd/smagent.log after the chcon command showed above, the security attributes of the file will be reset to the system wide attribute of the location. The semanage fcontext -a -t httpd_sys_content_rw_t /var/log/httpd/smagent.log command followed by a restorecon /var/log/httpd/smagent.log would solve that issue. Another option is to permit apache and webapps running with apaches permissions to write to log files. This is not encouraged. Again its best to just report a bug to the author of the webapp/module that you are running and ask him if he could change the webapp to append only to logfiles instead of writing to them. Tell him that if the webapp gets cracked, the comprized webapp could wipe it trail. (bad) hth > > host= type=SYSCALL msg=audit(1259003353.282:46730): > arch=c000003e syscall=1 per=400000 success=yes exit=124 a0=15 > a1=2aaaab249000 a2=7c a3=7473657571655273 items=0 ppid=1 pid=27369 > auid=32870 uid=48 gid=0 euid=48 suid=48 fsuid=48 egid=0 sgid=0 fsgid=0 > tty=(none) ses=4473 comm="LLAWP" > exe="/usr/local/opt/smwa-6qmr5-cr013-rhas30-x86-64/webagent/bin/LLAWP" > subj=user_u:system_r:httpd_t:s0 key=(null) > > Now, running sealert tells me to set httpd_unified to 1. I've done this, > several times, and no joy, so obviously it is *not* the actual error. > > I've also tried restorecon. > > So, what's the actual error? I'm really tired of this, on more than one > server, cluttering my logs.... > > Thanks in advance. > > mark > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From paul at city-fan.org Mon Nov 23 21:28:58 2009 From: paul at city-fan.org (Paul Howarth) Date: Mon, 23 Nov 2009 21:28:58 +0000 Subject: F-12 arpwatch AVCs Message-ID: <20091123212858.31b120ac@city-fan.org> Just updated my DHCP/arpwatch box to F-12 and needed to add this to local policy: kernel_read_network_state(arpwatch_t) AVCs: type=AVC msg=audit(1258984783.886:788): avc: denied { read } for pid=4592 comm="arpwatch" name="dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file type=SYSCALL msg=audit(1258984783.886:788): arch=c000003e syscall=2 success=no exit=-13 a0=3e9aa1f9d5 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=4592 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) type=SYSCALL msg=audit(1258984783.894:789): arch=c000003e syscall=54 success=yes exit=0 a0=0 a1=107 a2=1 a3=7fff6c6ebff0 items=0 ppid=1 pid=4592 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) type=AVC msg=audit(1259008591.308:107843): avc: denied { read } for pid=4085 comm="arpwatch" name="dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file type=AVC msg=audit(1259008591.308:107843): avc: denied { open } for pid=4085 comm="arpwatch" name="dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file type=SYSCALL msg=audit(1259008591.308:107843): arch=c000003e syscall=2 success=yes exit=0 a0=3e9aa1f9d5 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=4085 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) type=AVC msg=audit(1259008591.308:107844): avc: denied { getattr } for pid=4085 comm="arpwatch" path="/proc/4085/net/dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file type=SYSCALL msg=audit(1259008591.308:107844): arch=c000003e syscall=5 success=yes exit=0 a0=0 a1=7fff01307210 a2=7fff01307210 a3=7fff01307110 items=0 ppid=1 pid=4085 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) type=SYSCALL msg=audit(1259008591.317:107845): arch=c000003e syscall=54 success=yes exit=0 a0=0 a1=107 a2=1 a3=7fff01307560 items=0 ppid=1 pid=4085 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) Cheers, Paul. From dwalsh at redhat.com Mon Nov 23 23:40:50 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 Nov 2009 18:40:50 -0500 Subject: F-12 arpwatch AVCs In-Reply-To: <20091123212858.31b120ac@city-fan.org> References: <20091123212858.31b120ac@city-fan.org> Message-ID: <4B0B1D82.9080807@redhat.com> On 11/23/2009 04:28 PM, Paul Howarth wrote: > Just updated my DHCP/arpwatch box to F-12 and needed to add this to > local policy: > > kernel_read_network_state(arpwatch_t) > > AVCs: > > type=AVC msg=audit(1258984783.886:788): avc: denied { read } for pid=4592 comm="arpwatch" name="dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file > type=SYSCALL msg=audit(1258984783.886:788): arch=c000003e syscall=2 success=no exit=-13 a0=3e9aa1f9d5 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=4592 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) > type=SYSCALL msg=audit(1258984783.894:789): arch=c000003e syscall=54 success=yes exit=0 a0=0 a1=107 a2=1 a3=7fff6c6ebff0 items=0 ppid=1 pid=4592 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) > type=AVC msg=audit(1259008591.308:107843): avc: denied { read } for pid=4085 comm="arpwatch" name="dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file > type=AVC msg=audit(1259008591.308:107843): avc: denied { open } for pid=4085 comm="arpwatch" name="dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file > type=SYSCALL msg=audit(1259008591.308:107843): arch=c000003e syscall=2 success=yes exit=0 a0=3e9aa1f9d5 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=4085 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) > type=AVC msg=audit(1259008591.308:107844): avc: denied { getattr } for pid=4085 comm="arpwatch" path="/proc/4085/net/dev" dev=proc ino=4026531931 scontext=unconfined_u:system_r:arpwatch_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file > type=SYSCALL msg=audit(1259008591.308:107844): arch=c000003e syscall=5 success=yes exit=0 a0=0 a1=7fff01307210 a2=7fff01307210 a3=7fff01307110 items=0 ppid=1 pid=4085 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) > type=SYSCALL msg=audit(1259008591.317:107845): arch=c000003e syscall=54 > success=yes exit=0 a0=0 a1=107 a2=1 a3=7fff01307560 items=0 ppid=1 > pid=4085 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=1 comm="arpwatch" exe="/usr/sbin/arpwatch" > subj=unconfined_u:system_r:arpwatch_t:s0 key=(null) > > Cheers, Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Sorry you missed this weeks boat, Just released 49 to updates testing. Fixed in -50. From domg472 at gmail.com Tue Nov 24 11:27:36 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 24 Nov 2009 12:27:36 +0100 Subject: Add new ksm domain. In-Reply-To: <4B07EE59.9080508@gmail.com> References: <4B07EE59.9080508@gmail.com> Message-ID: <4B0BC328.9000106@gmail.com> On 11/21/2009 02:42 PM, Dominick Grift wrote: > Attached is ksm module. If virtualization is installed then ksm and > ksmtuned services are enabled by default. > > Currently they run in initrc_t. It seems the initrc_t domain has > sufficient permissions for ksm tune daemon. > > The policy is not thoroughly tested yet and so i left ksmtuned_t permissive. Anther patch: allow ksmtuned_t self:capability sys_tty_config; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From goeran at uddeborg.se Tue Nov 24 17:23:17 2009 From: goeran at uddeborg.se (=?utf-8?Q?G=C3=B6ran?= Uddeborg) Date: Tue, 24 Nov 2009 18:23:17 +0100 Subject: The story behind by default permissive domains Message-ID: <19212.5765.780263.886931@gargle.gargle.HOWL> After switching to F12 policy I've started getting SELinux alerts from setroubleshoot looking like this Summary: SELinux is preventing ntop (ntop_t) "create" ntop_t. Detailed Description: [ntop has a permissive type (ntop_t). This access was not denied.] I thought permissive domains was meant as a debugging and development tool. But I haven't (knowingly) made ntop_t permissive. And the command suggested in the user guide, semodule -l | grep permissive, returns nothing. So it seems ntop_t is permissive by default somehow. Is the reasoning behind domains that are permissive by default documented somewhere? A blog I should read or so? Can I find out what other domains are also permissive? (I haven't yet upgraded ntop to F12, so this particular AVC might be because I run an old version. This mail is a question about the concept of domains that are permissive from the start, not this AVC.) From domg472 at gmail.com Tue Nov 24 18:18:57 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 24 Nov 2009 19:18:57 +0100 Subject: The story behind by default permissive domains In-Reply-To: <19212.5765.780263.886931@gargle.gargle.HOWL> References: <19212.5765.780263.886931@gargle.gargle.HOWL> Message-ID: <20091124181856.GA13539@localhost.localdomain> On Tue, Nov 24, 2009 at 06:23:17PM +0100, G?ran Uddeborg wrote: > After switching to F12 policy I've started getting SELinux alerts from > setroubleshoot looking like this > > Summary: > > SELinux is preventing ntop (ntop_t) "create" ntop_t. > > Detailed Description: > > [ntop has a permissive type (ntop_t). This access was not denied.] > > I thought permissive domains was meant as a debugging and development > tool. But I haven't (knowingly) made ntop_t permissive. And the > command suggested in the user guide, semodule -l | grep permissive, > returns nothing. > > So it seems ntop_t is permissive by default somehow. Is the reasoning > behind domains that are permissive by default documented somewhere? A > blog I should read or so? Can I find out what other domains are also > permissive? > > (I haven't yet upgraded ntop to F12, so this particular AVC might be > because I run an old version. This mail is a question about the > concept of domains that are permissive from the start, not this AVC.) Well i am not sure what Fedoras' policy is on this, but to me, Fedora is a development platform. Permissive domains put domain into permissive state. This usually done during development of modules so that i can be tested without end-users running a risk of losing functionality. So, Yes in a production environment you probably would not see permissive domains but since Fedora is a development platform, policy is still tested in a permissive state. In Enterprise Linux you should not see permissive domains. It could also be that Fedora forgot to remove the permissive declaration from the module, but i doubt that. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Tue Nov 24 20:17:06 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 Nov 2009 15:17:06 -0500 Subject: The story behind by default permissive domains In-Reply-To: <19212.5765.780263.886931@gargle.gargle.HOWL> References: <19212.5765.780263.886931@gargle.gargle.HOWL> Message-ID: <4B0C3F42.2090807@redhat.com> On 11/24/2009 12:23 PM, G?ran Uddeborg wrote: > After switching to F12 policy I've started getting SELinux alerts from > setroubleshoot looking like this > > Summary: > > SELinux is preventing ntop (ntop_t) "create" ntop_t. > > Detailed Description: > > [ntop has a permissive type (ntop_t). This access was not denied.] > > I thought permissive domains was meant as a debugging and development > tool. But I haven't (knowingly) made ntop_t permissive. And the > command suggested in the user guide, semodule -l | grep permissive, > returns nothing. > > So it seems ntop_t is permissive by default somehow. Is the reasoning > behind domains that are permissive by default documented somewhere? A > blog I should read or so? Can I find out what other domains are also > permissive? > > (I haven't yet upgraded ntop to F12, so this particular AVC might be > because I run an old version. This mail is a question about the > concept of domains that are permissive from the start, not this AVC.) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Our thoughts on permissive domains was when we introduce a new domain during a release, we will run it permissive until the end of a release. ntop was added to F12, it is permissive until F13, In F13 it will be enforcing. This allows us to get all of the AVC messages for ntop without blowing it up in the real world. I don't remember if I blogged on this idea, or not. From goeran at uddeborg.se Tue Nov 24 20:56:41 2009 From: goeran at uddeborg.se (=?utf-8?Q?G=C3=B6ran?= Uddeborg) Date: Tue, 24 Nov 2009 21:56:41 +0100 Subject: The story behind by default permissive domains In-Reply-To: <4B0C3F42.2090807@redhat.com> References: <19212.5765.780263.886931@gargle.gargle.HOWL> <4B0C3F42.2090807@redhat.com> Message-ID: <19212.18569.916353.581823@gargle.gargle.HOWL> Daniel J Walsh: > Our thoughts on permissive domains was when we introduce a new > domain during a release, we will run it permissive until the end of > a release. Makes sense. So then I'll report issues like these as usual when I find them. (After having upgraded to the F12 version of applications, of course.) From dwalsh at redhat.com Tue Nov 24 22:51:43 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 Nov 2009 17:51:43 -0500 Subject: The story behind by default permissive domains In-Reply-To: <19212.18569.916353.581823@gargle.gargle.HOWL> References: <19212.5765.780263.886931@gargle.gargle.HOWL> <4B0C3F42.2090807@redhat.com> <19212.18569.916353.581823@gargle.gargle.HOWL> Message-ID: <4B0C637F.3030501@redhat.com> On 11/24/2009 03:56 PM, G?ran Uddeborg wrote: > Daniel J Walsh: >> Our thoughts on permissive domains was when we introduce a new >> domain during a release, we will run it permissive until the end of >> a release. > > Makes sense. So then I'll report issues like these as usual when I > find them. (After having upgraded to the F12 version of applications, > of course.) Yes that is the goal to gather as many AVC messages as possible to make it feasible to remove permissive in F13. From braden at endoframe.com Wed Nov 25 11:00:53 2009 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 25 Nov 2009 06:00:53 -0500 Subject: execstack fun Message-ID: <1259146853.17257.67.camel@localhost> I develop software on Fedora. Since upgrading to Fedora 12, I now trip over this when my program tries to dlopen libjvm.so: SELinux is preventing /var/user/braden/openvrml-dbg/examples/.libs/lt-sdl-viewer from making the program stack executable. Changing the context of the executable each time it's built isn't especially practical; and disabling this check for everything on the system isn't especially desirable. Is there a better way to manage this? -- Braden McDaniel From dwalsh at redhat.com Wed Nov 25 12:26:14 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 25 Nov 2009 07:26:14 -0500 Subject: execstack fun In-Reply-To: <1259146853.17257.67.camel@localhost> References: <1259146853.17257.67.camel@localhost> Message-ID: <4B0D2266.2010605@redhat.com> On 11/25/2009 06:00 AM, Braden McDaniel wrote: > I develop software on Fedora. Since upgrading to Fedora 12, I now trip > over this when my program tries to dlopen libjvm.so: > > SELinux is preventing /var/user/braden/openvrml-dbg/examples/.libs/lt-sdl-viewer > from making the program stack executable. > > Changing the context of the executable each time it's built isn't > especially practical; and disabling this check for everything on the > system isn't especially desirable. Is there a better way to manage > this? > > I was planning to bring this up for discussion. I could write a rule that says unconfined_t->user_home_t->unconfined_execmem_t unconfined_t->user_tmp_t->unconfined_execmem_t Which would mean that any executables executed from the home dir would execute in execmem_t since we do not know if they are java/mono/or some other lang that requiers execmem/execstack. This would allow us to stop all executables that are installed on the system to require correct labeling. What do you think? From tibbs at math.uh.edu Wed Nov 25 16:25:34 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 25 Nov 2009 10:25:34 -0600 Subject: execstack fun In-Reply-To: <4B0D2266.2010605@redhat.com> (Daniel J. Walsh's message of "Wed, 25 Nov 2009 07:26:14 -0500") References: <1259146853.17257.67.camel@localhost> <4B0D2266.2010605@redhat.com> Message-ID: >>>>> "DJW" == Daniel J Walsh writes: DJW> Which would mean that any executables executed from the home dir DJW> would execute in execmem_t since we do not know if they are DJW> java/mono/or some other lang that requiers execmem/execstack. How would this work for home directories on NFS? (Actually I've always been unsure of how NFS home directories are supposed to be handled, especially when they're automounted and may be accessed by multiple different operating systems.) - J< From braden at endoframe.com Wed Nov 25 17:23:27 2009 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 25 Nov 2009 12:23:27 -0500 Subject: execstack fun In-Reply-To: <4B0D2266.2010605@redhat.com> References: <1259146853.17257.67.camel@localhost> <4B0D2266.2010605@redhat.com> Message-ID: <1259169807.3530.14.camel@localhost> On Wed, 2009-11-25 at 07:26 -0500, Daniel J Walsh wrote: > On 11/25/2009 06:00 AM, Braden McDaniel wrote: > > I develop software on Fedora. Since upgrading to Fedora 12, I now trip > > over this when my program tries to dlopen libjvm.so: > > > > SELinux is preventing /var/user/braden/openvrml-dbg/examples/.libs/lt-sdl-viewer > > from making the program stack executable. > > > > Changing the context of the executable each time it's built isn't > > especially practical; and disabling this check for everything on the > > system isn't especially desirable. Is there a better way to manage > > this? > > > > > I was planning to bring this up for discussion. I could write a rule that says > > unconfined_t->user_home_t->unconfined_execmem_t > unconfined_t->user_tmp_t->unconfined_execmem_t > > > Which would mean that any executables executed from the home dir would execute in execmem_t since we do not know if they are java/mono/or some other lang that requiers execmem/execstack. > > This would allow us to stop all executables that are installed on the system to require correct labeling. > > > What do you think? Sounds reasonable. But mine is not an expert opinion. -- Braden McDaniel From dwalsh at redhat.com Wed Nov 25 19:13:20 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 25 Nov 2009 14:13:20 -0500 Subject: execstack fun In-Reply-To: References: <1259146853.17257.67.camel@localhost> <4B0D2266.2010605@redhat.com> Message-ID: <4B0D81D0.4090603@redhat.com> On 11/25/2009 11:25 AM, Jason L Tibbitts III wrote: >>>>>> "DJW" == Daniel J Walsh writes: > > DJW> Which would mean that any executables executed from the home dir > DJW> would execute in execmem_t since we do not know if they are > DJW> java/mono/or some other lang that requiers execmem/execstack. > > How would this work for home directories on NFS? (Actually I've always > been unsure of how NFS home directories are supposed to be handled, > especially when they're automounted and may be accessed by multiple > different operating systems.) > > - J< > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > In the case of nfs homedir, the homedir is labeled nfs_t, so the transition would have to be unconfined_t->nfs_t->unconfined_execmem_t unconfined_t->cifs_t->unconfined_execmem_t for samba home dirs. From domg472 at gmail.com Wed Nov 25 20:00:50 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 25 Nov 2009 21:00:50 +0100 Subject: libcgroup policy (concept) Message-ID: <4B0D8CF2.1040907@gmail.com> Attached policy targets some libcgroup stuff. The policy is largely untested (i do have it running on a few servers here but i get some avc denials that i am not quite sure what to do with) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libcgroup.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libcgroup.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libcgroup.te URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_fs_interact_with_cgroup_fs_for_initrc_and_cgconfig.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_fs_interact_with_cgroup_fs_for_initrc_and_cgconfig.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_fs_interact_with_cgroup_fs_for_initrc_and_cgconfig.te URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_initrc_to_allow_cgconf_cgrulesengd_manage_files_on_cgroup_fs.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_initrc_to_allow_cgconf_cgrulesengd_manage_files_on_cgroup_fs.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_initrc_to_allow_cgconf_cgrulesengd_manage_files_on_cgroup_fs.te URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From domg472 at gmail.com Thu Nov 26 12:16:37 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 26 Nov 2009 13:16:37 +0100 Subject: 3.7.3-1 nsplugin Message-ID: <4B0E71A5.7060308@gmail.com> > type=SYSCALL msg=audit(1259237381.086:26296): arch=c000003e syscall=84 success=yes exit=68719476864 a0=168e400 a1=7fff3a1c4260 a2=ffffffffffffffa8 a3=fffffff4 items=0 ppid=5802 pid=5935 auid=501 uid=501 gid=503 euid=501 suid=501 fsuid=501 egid=503 sgid=503 fsgid=503 tty=(none) ses=1 comm="npviewer.bin" exe="/usr/lib64/nspluginwrapper/npviewer.bin" subj=staff_u:staff_r:nsplugin_t:s0 key=(null) > type=AVC msg=audit(1259237381.086:26296): avc: denied { rmdir } for pid=5935 comm="npviewer.bin" name=".pulse" dev=dm-1 ino=909380 scontext=staff_u:staff_r:nsplugin_t:s0 tcontext=staff_u:object_r:gnome_home_t:s0 tclass=dir > allow nsplugin_t gnome_home_t:dir { search getattr setattr rmdir }; Why is .pulse even gnome_home_t and why is .pulse-cookie user_home_t. Looks to me these locations are owned by pulseaudio not gnome. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From domg472 at gmail.com Thu Nov 26 21:57:10 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 26 Nov 2009 22:57:10 +0100 Subject: screen wants to set attributes of user tty device Message-ID: <20091126215709.GA1929@localhost.localdomain> I got this one using screen in tty1: userdom_setattr_user_ttys(staff_screen_t) thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From method at manicmethod.com Fri Nov 27 20:31:14 2009 From: method at manicmethod.com (Joshua Brindle) Date: Fri, 27 Nov 2009 15:31:14 -0500 Subject: The SELinux Documentation Project In-Reply-To: <4AC1130D.8000601@manicmethod.com> References: <4AC1130D.8000601@manicmethod.com> Message-ID: <4B103712.2050709@manicmethod.com> Joshua Brindle wrote: > As we discussed at Linux Plumbers Conference during the 'Making SELinux > Easier to Use" talk we have some document deficiencies in the SELinux > project. > We have gotten some good contributions to the documentation project over the last couple months but there is always more to do. I've updated the Documentation TODO at: with some docs we'd like written and some guidance on what the format should be. Use cases would be particularly appreciated. If you haven't gone to the documentation wiki lately take a look at and see what's been added. Thanks for the help of the contributors and hopefully this effort will go a long way toward gaining users and keeping SELinux enabled. From domg472 at gmail.com Sat Nov 28 12:17:45 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 28 Nov 2009 13:17:45 +0100 Subject: The SELinux Documentation Project In-Reply-To: <4B103712.2050709@manicmethod.com> References: <4AC1130D.8000601@manicmethod.com> <4B103712.2050709@manicmethod.com> Message-ID: <4B1114E9.7060806@gmail.com> On 11/27/2009 09:31 PM, Joshua Brindle wrote: > Joshua Brindle wrote: >> As we discussed at Linux Plumbers Conference during the 'Making SELinux >> Easier to Use" talk we have some document deficiencies in the SELinux >> project. >> > > > > We have gotten some good contributions to the documentation project over > the last couple months but there is always more to do. I've updated the > Documentation TODO at: > > > > with some docs we'd like written and some guidance on what the format > should be. Use cases would be particularly appreciated. > > If you haven't gone to the documentation wiki lately take a look at > > > > and see what's been added. > > Thanks for the help of the contributors and hopefully this effort will > go a long way toward gaining users and keeping SELinux enabled. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Attached is a concept i wrote today about Locking down webapps with CGI. This was a topic in the todo list. Would be nice if someone could proof-read this and when modified/accepted publish it. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Locking_down_webapps_by_using_CGI.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From method at manicmethod.com Sat Nov 28 19:10:50 2009 From: method at manicmethod.com (Joshua Brindle) Date: Sat, 28 Nov 2009 14:10:50 -0500 Subject: The SELinux Documentation Project In-Reply-To: <4B1114E9.7060806@gmail.com> References: <4AC1130D.8000601@manicmethod.com> <4B103712.2050709@manicmethod.com> <4B1114E9.7060806@gmail.com> Message-ID: <4B1175BA.1060604@manicmethod.com> Dominick Grift wrote: > On 11/27/2009 09:31 PM, Joshua Brindle wrote: >> Joshua Brindle wrote: >>> As we discussed at Linux Plumbers Conference during the 'Making SELinux >>> Easier to Use" talk we have some document deficiencies in the SELinux >>> project. >>> >> >> >> We have gotten some good contributions to the documentation project over >> the last couple months but there is always more to do. I've updated the >> Documentation TODO at: >> >> >> >> with some docs we'd like written and some guidance on what the format >> should be. Use cases would be particularly appreciated. >> >> If you haven't gone to the documentation wiki lately take a look at >> >> >> >> and see what's been added. >> >> Thanks for the help of the contributors and hopefully this effort will >> go a long way toward gaining users and keeping SELinux enabled. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Attached is a concept i wrote today about Locking down webapps with CGI. > This was a topic in the todo list. > > Would be nice if someone could proof-read this and when > modified/accepted publish it. It's a wiki :) Just put it up there and others can make modifications. There are actually a couple people who are decent at copy editing that have done some work on the wiki so if we get technical content up there they can do what they do to clean it up. From roland at astrofoto.org Sun Nov 29 04:35:56 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sat, 28 Nov 2009 23:35:56 -0500 Subject: SELinux won't let dovecot connect to postgresql Message-ID: <4B11FA2C.8040000@astrofoto.org> I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs installed. I have a small user database set up for email authentication. The issue I'm having is that when I am in enforcing mode, dovecot can't connect to the database. Turning off enforcing mode lets it work. I'm having trouble diagnosing where the denial is taking place as I don't see any avc messages in /var/log/messages that relate to dovecot. The only messages I'm getting are in /var/log/maillog from dovecot like this: Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to maildb: could not connect to server: Permission denied Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running on host "fred.flinstone.org" and accepting Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on port 5432? The answer to the questions is "yes" it is running and accepting connections. Whether or not enforcing mode is on, when logged in, I can connect to the database via $ psql -h fred.flinstone.org maildb I *think* this is a result of updating on Nov 18. I have not changed the default selinux mode since the host was set up back in September. At that point, I set it to enforcing mode after working out a few issues. On Nov 18, a lot of things were updated, but among there were Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64 Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64 Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64 Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch Today, I did another update, hoping it would cure the problem and got these revisions Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch but the behavior is unchanged, I still have to turn off enforcing mode. Any clues on what I need to do to get this to work? Or where to look for clues since, as I mentioned, I can't even find log entries that would clue me in. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From justinmattock at gmail.com Sun Nov 29 05:05:36 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sat, 28 Nov 2009 21:05:36 -0800 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B11FA2C.8040000@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> Message-ID: <4B120120.6030608@gmail.com> On 11/28/09 20:35, Roland Roberts wrote: > I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs > installed. I have a small user database set up for email authentication. > The issue I'm having is that when I am in enforcing mode, dovecot can't > connect to the database. Turning off enforcing mode lets it work. I'm > having trouble diagnosing where the denial is taking place as I don't > see any avc messages in /var/log/messages that relate to dovecot. The > only messages I'm getting are in /var/log/maillog from dovecot like this: > > Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to > maildb: could not connect to server: Permission denied > Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running > on host "fred.flinstone.org" and accepting > Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on > port 5432? > > The answer to the questions is "yes" it is running and accepting > connections. Whether or not enforcing mode is on, when logged in, I can > connect to the database via > > $ psql -h fred.flinstone.org maildb > > I *think* this is a result of updating on Nov 18. I have not changed the > default selinux mode since the host was set up back in September. At > that point, I set it to enforcing mode after working out a few issues. > On Nov 18, a lot of things were updated, but among there were > > Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch > Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64 > Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64 > Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64 > Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch > Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch > > Today, I did another update, hoping it would cure the problem and got > these revisions > > Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch > Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch > > but the behavior is unchanged, I still have to turn off enforcing mode. > > Any clues on what I need to do to get this to work? Or where to look for > clues since, as I mentioned, I can't even find log entries that would > clue me in. > > roland > Maybe you just need to either make enableaudit or check the file labels to make sure things are legit, Justin P. Mattock From thomas-lists at nybeta.com Sun Nov 29 05:11:28 2009 From: thomas-lists at nybeta.com (Thomas Harold) Date: Sun, 29 Nov 2009 00:11:28 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B11FA2C.8040000@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> Message-ID: <4B120280.40406@nybeta.com> On 11/28/2009 11:35 PM, Roland Roberts wrote: > I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs > installed. I have a small user database set up for email > authentication. The issue I'm having is that when I am in enforcing > mode, dovecot can't connect to the database. Turning off enforcing > mode lets it work. I'm having trouble diagnosing where the denial is > taking place as I don't see any avc messages in /var/log/messages > that relate to dovecot. The only messages I'm getting are in > /var/log/maillog from dovecot like this I think that you have to have the setroubleshoot service running in order to get SELinux errors in /var/log/messages. https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ > Any clues on what I need to do to get this to work? Or where to look > for clues since, as I mentioned, I can't even find log entries that > would clue me in. First step is to look in /var/log/messages for "sealert" lines (assuming that the setroubleshoot service is running). The meat of the details of the denial will be in /var/log/audit/audit.log. # egrep "(dovecot|postgres)" /var/log/audit/audit* | audit2allow It'll probably spit out something like: allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect; Depending on what database server you are running, of course. You'll want to set your system to "permissive" and let SELinux gather messages in the audit.log. Then you can run audit2allow once, check its suggestions, and then create and apply a new policy. From roland at astrofoto.org Sun Nov 29 05:29:23 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sun, 29 Nov 2009 00:29:23 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B120280.40406@nybeta.com> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> Message-ID: <4B1206B3.5050304@astrofoto.org> Thomas Harold wrote: > I think that you have to have the setroubleshoot service running in > order to get SELinux errors in /var/log/messages. > > https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ Hmmm, I seem to have both setroubleshoot and setroubleshoot-server packages installed, but much of that package talks about turning on the setroubleshoot service; the file for that should be in /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages verify as correct (rpm -V) and rpm -qil does not show any such file in the inventory. There is a file /usr/sbin/setroubleshootd which is what I would expect for the daemon, but no file in /etc/rc.d/init.d references it. Odd. And if I try to manually launch it, it runs briefly, leaves a zero-length log file in /var/log/setroubleshoot/setroubleshootd.log. Note that I am *not* on a X11 desktop on this host. It is a server, and while it has X installed, it is in run level 3. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From thomas-lists at nybeta.com Sun Nov 29 05:43:00 2009 From: thomas-lists at nybeta.com (Thomas Harold) Date: Sun, 29 Nov 2009 00:43:00 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1206B3.5050304@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> Message-ID: <4B1209E4.5050203@nybeta.com> On 11/29/2009 12:29 AM, Roland Roberts wrote: > > Hmmm, I seem to have both setroubleshoot and setroubleshoot-server > packages installed, but much of that package talks about turning on the > setroubleshoot service; the file for that should be in > /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages > verify as correct (rpm -V) and rpm -qil does not show any such file in > the inventory. There is a file /usr/sbin/setroubleshootd which is what I > would expect for the daemon, but no file in /etc/rc.d/init.d references > it. Odd. And if I try to manually launch it, it runs briefly, leaves a > zero-length log file in /var/log/setroubleshoot/setroubleshootd.log. You could try uninstalling and then reinstalling the setroubleshoot package. Specifically "setroubleshoot-server" package contains the daemon and init.d file and only depends on the -plugins package. Even on our servers, the setroubleshoot.log file is generally empty. I'm guessing that you'll only see content there if the daemon fails to initialize or has errors. From roland at astrofoto.org Sun Nov 29 05:49:30 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sun, 29 Nov 2009 00:49:30 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1209E4.5050203@nybeta.com> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1209E4.5050203@nybeta.com> Message-ID: <4B120B6A.7080502@astrofoto.org> Thomas Harold wrote: > You could try uninstalling and then reinstalling the setroubleshoot > package. Specifically "setroubleshoot-server" package contains the > daemon and init.d file and only depends on the -plugins package. But it doesn't seem to include the init.d file, or is rpm -qil not telling me what I think it is telling me: 572 root> rpm -qil setroubleshoot-server | grep /etc /etc/audisp/plugins.d/sedispatch.conf /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf /etc/logrotate.d/setroubleshoot /etc/setroubleshoot /etc/setroubleshoot/setroubleshoot.cfg roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From roland at astrofoto.org Sun Nov 29 05:56:15 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sun, 29 Nov 2009 00:56:15 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B120B6A.7080502@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1209E4.5050203@nybeta.com> <4B120B6A.7080502@astrofoto.org> Message-ID: <4B120CFF.90503@astrofoto.org> Roland Roberts wrote: > Thomas Harold wrote: >> You could try uninstalling and then reinstalling the setroubleshoot >> package. Specifically "setroubleshoot-server" package contains the >> daemon and init.d file and only depends on the -plugins package. Oo-oo. I just discovered something *very* interesting. When I first set up this host, I set it up in parallel with the existing host it was replacing and it had a different host name. I find, in /var/lib/setroubleshoot/audit_listener_database.xml, the old host name. Perhaps that's why I'm not getting my messages. I'm going to try correcting the host name there. I'm not sure if I *need* to reboot, but I'm not sure what processes will need to be restarted if I don't. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From roland at astrofoto.org Sun Nov 29 06:05:59 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sun, 29 Nov 2009 01:05:59 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B120CFF.90503@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1209E4.5050203@nybeta.com> <4B120B6A.7080502@astrofoto.org> <4B120CFF.90503@astrofoto.org> Message-ID: <4B120F47.2000901@astrofoto.org> Roland Roberts wrote: > Roland Roberts wrote: >> Thomas Harold wrote: >>> You could try uninstalling and then reinstalling the setroubleshoot >>> package. Specifically "setroubleshoot-server" package contains the >>> daemon and init.d file and only depends on the -plugins package. > > Oo-oo. I just discovered something *very* interesting. When I first > set up this host, I set it up in parallel with the existing host it > was replacing and it had a different host name. I find, in > /var/lib/setroubleshoot/audit_listener_database.xml, the old host > name. Perhaps that's why I'm not getting my messages. I'm going to > try correcting the host name there. I'm not sure if I *need* to > reboot, but I'm not sure what processes will need to be restarted if I > don't. Well, that by itself is not sufficient. But perhaps these two lines in syslog are a clue if only I could decipher them: dbus: avc: received setenforce notice (enforcing=0) tycho dbus: Can't send to audit system: USER_AVC avc: received setenforce notice (enforcing=0)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?) roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From thomas-lists at nybeta.com Sun Nov 29 06:07:27 2009 From: thomas-lists at nybeta.com (Thomas Harold) Date: Sun, 29 Nov 2009 01:07:27 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B120B6A.7080502@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1209E4.5050203@nybeta.com> <4B120B6A.7080502@astrofoto.org> Message-ID: <4B120F9F.3030502@nybeta.com> On 11/29/2009 12:49 AM, Roland Roberts wrote: > Thomas Harold wrote: >> You could try uninstalling and then reinstalling the setroubleshoot >> package. Specifically "setroubleshoot-server" package contains the >> daemon and init.d file and only depends on the -plugins package. > > But it doesn't seem to include the init.d file, or is rpm -qil not > telling me what I think it is telling me: > > 572 root> rpm -qil setroubleshoot-server | grep /etc > /etc/audisp/plugins.d/sedispatch.conf > /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf > /etc/logrotate.d/setroubleshoot > /etc/setroubleshoot > /etc/setroubleshoot/setroubleshoot.cfg > Not sure, that's sounding more like a Fedora issue then an SELinux issue (and I'm not running Fedora, I'm running RHEL/CentOS). But a bit of google-fu turned up: http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html (the linked message was posted by Daniel J Walsh) Basically, they've restructured things back in June 2009. So you'll probably have to go digging in the audit.log file for the AVC messages. # grep "AVC" /var/log/audit/audit.log From roland at astrofoto.org Sun Nov 29 06:11:51 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sun, 29 Nov 2009 01:11:51 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B120F9F.3030502@nybeta.com> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1209E4.5050203@nybeta.com> <4B120B6A.7080502@astrofoto.org> <4B120F9F.3030502@nybeta.com> Message-ID: <4B1210A7.8000307@astrofoto.org> Thomas Harold wrote: > On 11/29/2009 12:49 AM, Roland Roberts wrote: >> But it doesn't seem to include the init.d file, or is rpm -qil not >> telling me what I think it is telling me: >> >> 572 root> rpm -qil setroubleshoot-server | grep /etc >> /etc/audisp/plugins.d/sedispatch.conf >> /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf >> /etc/logrotate.d/setroubleshoot >> /etc/setroubleshoot >> /etc/setroubleshoot/setroubleshoot.cfg >> > > Not sure, that's sounding more like a Fedora issue then an SELinux > issue (and I'm not running Fedora, I'm running RHEL/CentOS). But a > bit of google-fu turned up: > > http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html > > (the linked message was posted by Daniel J Walsh) > > Basically, they've restructured things back in June 2009. So you'll > probably have to go digging in the audit.log file for the AVC messages. > > # grep "AVC" /var/log/audit/audit.log Thanks. Maybe I'll file a report with bugzilla. Not sure that my missing messages are a bug, but there is nothing in /var/log/audit/audit.log with "avc". In any event, it's past my bedtime here for today g'nite. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From justinmattock at gmail.com Sun Nov 29 06:35:01 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sat, 28 Nov 2009 22:35:01 -0800 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B120F47.2000901@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1209E4.5050203@nybeta.com> <4B120B6A.7080502@astrofoto.org> <4B120CFF.90503@astrofoto.org> <4B120F47.2000901@astrofoto.org> Message-ID: <4B121615.9000701@gmail.com> On 11/28/09 22:05, Roland Roberts wrote: > Roland Roberts wrote: >> Roland Roberts wrote: >>> Thomas Harold wrote: >>>> You could try uninstalling and then reinstalling the setroubleshoot >>>> package. Specifically "setroubleshoot-server" package contains the >>>> daemon and init.d file and only depends on the -plugins package. >> >> Oo-oo. I just discovered something *very* interesting. When I first >> set up this host, I set it up in parallel with the existing host it >> was replacing and it had a different host name. I find, in >> /var/lib/setroubleshoot/audit_listener_database.xml, the old host >> name. Perhaps that's why I'm not getting my messages. I'm going to try >> correcting the host name there. I'm not sure if I *need* to reboot, >> but I'm not sure what processes will need to be restarted if I don't. > > Well, that by itself is not sufficient. But perhaps these two lines in > syslog are a clue if only I could decipher them: > > dbus: avc: received setenforce notice (enforcing=0) > tycho dbus: Can't send to audit system: USER_AVC avc: received > setenforce notice (enforcing=0)#012: exe="?" (sauid=81, hostname=?, > addr=?, terminal=?) > > roland > why is dbus sending a setenforce=0 call? Justin P. Mattock From gui1ty_fedora at penguinpee.nl Sun Nov 29 10:11:56 2009 From: gui1ty_fedora at penguinpee.nl (Sandro Janke) Date: Sun, 29 Nov 2009 11:11:56 +0100 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1206B3.5050304@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> Message-ID: <4B1248EC.2060403@penguinpee.nl> On 11/29/2009 06:29 AM, Roland Roberts wrote: > Thomas Harold wrote: >> I think that you have to have the setroubleshoot service running in >> order to get SELinux errors in /var/log/messages. >> >> https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ > > Hmmm, I seem to have both setroubleshoot and setroubleshoot-server > packages installed, but much of that package talks about turning on the > setroubleshoot service; the file for that should be in > /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages > verify as correct (rpm -V) and rpm -qil does not show any such file in > the inventory. There is a file /usr/sbin/setroubleshootd which is what I > would expect for the daemon, but no file in /etc/rc.d/init.d references > it. Odd. And if I try to manually launch it, it runs briefly, leaves a > zero-length log file in /var/log/setroubleshoot/setroubleshootd.log. > > Note that I am *not* on a X11 desktop on this host. It is a server, and > while it has X installed, it is in run level 3. Actually, you don't need to have any of the setroubleshoot packages installed to get AVC messages logged. What you need is auditd running and it will log AVC messages to /var/log/audit/audit.log With setroubleshoot-server installed you can watch the logged messages using: # sealert -a /var/log/audit/audit.log The output will be long and in the style of setroubleshoot browser, so take your measures. Another tool - from the audit package - that can prove very useful is ausearch. It will search the audit logs for messages matching the given criteria. From justinmattock at gmail.com Sun Nov 29 10:18:19 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sun, 29 Nov 2009 02:18:19 -0800 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1248EC.2060403@penguinpee.nl> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> Message-ID: <4B124A6B.5010905@gmail.com> On 11/29/09 02:11, Sandro Janke wrote: > On 11/29/2009 06:29 AM, Roland Roberts wrote: >> Thomas Harold wrote: >>> I think that you have to have the setroubleshoot service running in >>> order to get SELinux errors in /var/log/messages. >>> >>> https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ >> >> Hmmm, I seem to have both setroubleshoot and setroubleshoot-server >> packages installed, but much of that package talks about turning on the >> setroubleshoot service; the file for that should be in >> /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages >> verify as correct (rpm -V) and rpm -qil does not show any such file in >> the inventory. There is a file /usr/sbin/setroubleshootd which is what I >> would expect for the daemon, but no file in /etc/rc.d/init.d references >> it. Odd. And if I try to manually launch it, it runs briefly, leaves a >> zero-length log file in /var/log/setroubleshoot/setroubleshootd.log. >> >> Note that I am *not* on a X11 desktop on this host. It is a server, and >> while it has X installed, it is in run level 3. > > Actually, you don't need to have any of the setroubleshoot packages > installed to get AVC messages logged. What you need is auditd running > and it will log AVC messages to /var/log/audit/audit.log > > With setroubleshoot-server installed you can watch the logged messages > using: > > # sealert -a /var/log/audit/audit.log > > The output will be long and in the style of setroubleshoot browser, so > take your measures. > > Another tool - from the audit package - that can prove very useful is > ausearch. It will search the audit logs for messages matching the given > criteria. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > agree.. In my case I normaly just do: audit2allow -d > to_the_allow_rules audit2allow -i /var/log/*(and the rest of the log messages havng any left over avc's to define into the policy); Justin P. Mattock From justinmattock at gmail.com Sun Nov 29 10:36:23 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sun, 29 Nov 2009 02:36:23 -0800 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1248EC.2060403@penguinpee.nl> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> Message-ID: <4B124EA7.2030605@gmail.com> keep in mind this is running the latest git refpolicy and everything. You can use these tools(setools)although normally try to keep things as simple as possible, especially during development(that is until things get worked out); Justin P. Mattock From roland at astrofoto.org Mon Nov 30 01:44:59 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sun, 29 Nov 2009 20:44:59 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1248EC.2060403@penguinpee.nl> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> Message-ID: <4B13239B.7060708@astrofoto.org> On 11/29/2009 05:11 AM, Sandro Janke wrote: > Actually, you don't need to have any of the setroubleshoot packages > installed to get AVC messages logged. What you need is auditd running > and it will log AVC messages to /var/log/audit/audit.log > > With setroubleshoot-server installed you can watch the logged messages > using: > > # sealert -a /var/log/audit/audit.log > > The output will be long and in the style of setroubleshoot browser, so > take your measures. > > Another tool - from the audit package - that can prove very useful is > ausearch. It will search the audit logs for messages matching the > given criteria. But I'm not getting any messages there. And changing enforcing mode fixes the problem, so it seems like it has to be SELinux, but with no log, I can't figure out what rule needs to be changed. -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From roland at astrofoto.org Mon Nov 30 01:46:35 2009 From: roland at astrofoto.org (Roland Roberts) Date: Sun, 29 Nov 2009 20:46:35 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B124A6B.5010905@gmail.com> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> <4B124A6B.5010905@gmail.com> Message-ID: <4B1323FB.5020804@astrofoto.org> On 11/29/2009 05:18 AM, Justin P. Mattock wrote: > In my case I normaly just do: > audit2allow -d > to_the_allow_rules > audit2allow -i /var/log/*(and the rest of > the log messages havng any left over avc's > to define into the policy); Guys, you're driving me crazy :-/ I can't *find* a log entry to fix. There's nothing where it's supposed to be. So...if you agree that that looks like a bug, I'll just go on and file a bug. Otherwise I'm really stuck. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From eparis at redhat.com Mon Nov 30 02:27:24 2009 From: eparis at redhat.com (Eric Paris) Date: Sun, 29 Nov 2009 21:27:24 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1323FB.5020804@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> <4B124A6B.5010905@gmail.com> <4B1323FB.5020804@astrofoto.org> Message-ID: <1259548044.31191.18.camel@localhost> On Sun, 2009-11-29 at 20:46 -0500, Roland Roberts wrote: > On 11/29/2009 05:18 AM, Justin P. Mattock wrote: > > In my case I normaly just do: > > audit2allow -d > to_the_allow_rules > > audit2allow -i /var/log/*(and the rest of > > the log messages havng any left over avc's > > to define into the policy); > > Guys, you're driving me crazy :-/ I can't *find* a log entry to fix. > There's nothing where it's supposed to be. So...if you agree that that > looks like a bug, I'll just go on and file a bug. Otherwise I'm really > stuck. I see that my F12 policy has a rule that allows dovecot_t to talk to postgresql_port_t. Not certain if it is controlled by a boolean which is toggled wrong on your system or if you are having some other problem, so lets start by seeing the actual avc denial. AVCs can end up either in /var/log/messages or /var/log/audit/audit.log (depending on the system setup.) Also in permissive move denials are only logged one time. So you won't see a denial every time it ~would~ have triggered. To flush the selinux cache I typically suggest you set the system enforcing and back permissive quickly. So lets do these steps. setenforce 1 setenforce 0 reproduce problem (or what would be a problem) grep -i avc /var/log/messages grep -i avc /var/log/audit/audit.log If both of those come up blank you likely are hitting a problem that is being 'dontaudit' I believe you said F11 (if not and it is old enough to not understand semodule -DB let me know as there are other ways to do this on older systems)? If so do these steps semodule -DB setenforce 1 setenforce 0 reproduce problem (or what would be a problem) grep -i avc /var/log/messages /var/log/audit/audit.log semodule -B Let us know the output this time. Hopefully we can get to the bottom of this. -Eric From justinmattock at gmail.com Mon Nov 30 02:30:48 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sun, 29 Nov 2009 18:30:48 -0800 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1323FB.5020804@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> <4B124A6B.5010905@gmail.com> <4B1323FB.5020804@astrofoto.org> Message-ID: <4B132E58.6070004@gmail.com> On 11/29/09 17:46, Roland Roberts wrote: > On 11/29/2009 05:18 AM, Justin P. Mattock wrote: >> In my case I normaly just do: >> audit2allow -d > to_the_allow_rules >> audit2allow -i /var/log/*(and the rest of >> the log messages havng any left over avc's >> to define into the policy); > > Guys, you're driving me crazy :-/ I can't *find* a log entry to fix. > There's nothing where it's supposed to be. So...if you agree that that > looks like a bug, I'll just go on and file a bug. Otherwise I'm really > stuck. > > roland > What you might try is in the source tree of the policy (/usr/share/selinux/*) do a make clean make enableaudit make policy make install make load(reboot) then you should be able to see some avc's in /var/log/messages,audit.log. keep in mind if this is the targeted policy you might have to download the source for that policy then(depending on binary/monolithic) build your module for that policy(semodule) once you've collected the extra dontaudit avc's(/var/log/*) that's probably preventing you from going further. Justin P. Mattock From dpquigl at tycho.nsa.gov Mon Nov 30 13:05:12 2009 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 30 Nov 2009 08:05:12 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B1210A7.8000307@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1209E4.5050203@nybeta.com> <4B120B6A.7080502@astrofoto.org> <4B120F9F.3030502@nybeta.com> <4B1210A7.8000307@astrofoto.org> Message-ID: <1259586312.2341.7.camel@moss-terrapins.epoch.ncsc.mil> On Sun, 2009-11-29 at 01:11 -0500, Roland Roberts wrote: > Thomas Harold wrote: > > On 11/29/2009 12:49 AM, Roland Roberts wrote: > >> But it doesn't seem to include the init.d file, or is rpm -qil not > >> telling me what I think it is telling me: > >> > >> 572 root> rpm -qil setroubleshoot-server | grep /etc > >> /etc/audisp/plugins.d/sedispatch.conf > >> /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf > >> /etc/logrotate.d/setroubleshoot > >> /etc/setroubleshoot > >> /etc/setroubleshoot/setroubleshoot.cfg > >> > > > > Not sure, that's sounding more like a Fedora issue then an SELinux > > issue (and I'm not running Fedora, I'm running RHEL/CentOS). But a > > bit of google-fu turned up: > > > > http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html > > > > (the linked message was posted by Daniel J Walsh) > > > > Basically, they've restructured things back in June 2009. So you'll > > probably have to go digging in the audit.log file for the AVC messages. > > > > # grep "AVC" /var/log/audit/audit.log > > Thanks. Maybe I'll file a report with bugzilla. Not sure that my > missing messages are a bug, but there is nothing in > /var/log/audit/audit.log with "avc". In any event, it's past my bedtime > here for today > > g'nite. > > roland > Just as a bit of advice for the future. You are better off using the ausearch command to find denials. You can narrow it down to just AVC denials by using ausearch -m AVC. After that you can restrict based on time using some of the other flags for the utility. Dave