selinux December 2005

selinux@lists.fedoraproject.org

48 participants
63 discussions

localpolicy.fc settings not always honoured
by Ted Rule 14 Dec '05

14 Dec '05

For a personal requirement, I was trying to tweak SELinux strict sources policy so that the OpenOffice main binary had a non-default label, i.e. "soffice_exec_t". I found that despite setting the file_context override in localpolicy.fc, a restorecon kept flipping the file_context back to bin_t, implying that the loaded policy had ignored my localpolicy settings. I eventually found that the settings in distros.fc appeared to be overriding whatever I did, provided it had a regex match for the file in question. In other words, "restorecon" used the file_context as set by the last matching regex in /etc/selinux/strict/contexts/files/file_contexts The implication is that the Makefile for the policy doesn't guarantee to arrange things such that localpolicy.fc can always be used to apply local policy overrides. I had always assumed this to be the case. On most occasions, localpolicy.fc will override. My problem here was that distros.fc contains a "wilder" regex which happened to match the file_context I was trying to tweak. A grep of the relevant sections of localpolicy.fc and distros.fc are shown below. I was finding that an override for this file: /usr/lib/openoffice.org2.0/program/soffice was matching this in distros.fc /usr/lib/.*/program(/.*)? Could the Makefile be rearranged to ensure that local settings always override the default policy, please? Ted Policy in use is: selinux-policy-strict-sources-1.27.1-2.16 [root@workstation policy]# pwd /etc/selinux/strict/src/policy [root@workstation policy]# [root@workstation policy]# grep program file_contexts/distros.fc /usr/lib/.*/program(/.*)? system_u:object_r:bin_t /usr/lib/.*/program/.*\.so.* system_u:object_r:shlib_t /usr/lib/.*/program/libicudata\.so.* -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libsts645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libvclplug_gen645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libwrp645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libswd680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/librecentfile\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsvx680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libcomphelp4gcc3\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsoffice\.so -- system_u:object_r:texrel_shlib_t [root@workstation policy]# [root@workstation policy]# grep program file_contexts/program/localpolicy.fc #/usr/lib/openoffice.org2.0/program/libsoffice.so -- system_u:object_r:texrel_shlib_t /usr/lib/openoffice.org2.0/program/soffice -- system_u:object_r:soffice_exec_t /usr/lib/openoffice.org2.0/program/soffice.bin -- system_u:object_r:soffice_exec_t [root@workstation policy]# [root@workstation files]# pwd /etc/selinux/strict/contexts/files [root@workstation files]# grep program file_contexts # when the security policy is installed. The setfiles program # listed here anyway so that if the setfiles program is used on a running # cvs program #/usr/lib/openoffice.org2.0/program/libsoffice.so -- system_u:object_r:texrel_shlib_t /usr/lib/openoffice.org2.0/program/soffice -- system_u:object_r:soffice_exec_t /usr/lib/openoffice.org2.0/program/soffice.bin -- system_u:object_r:soffice_exec_t # rsync program # sysstat and other sar programs # Add programs here which should not be confined by SELinux # Add programs here which should not be confined by SELinux # uucico program /usr/lib/.*/program(/.*)? system_u:object_r:bin_t /usr/lib/.*/program/.*\.so.* system_u:object_r:shlib_t /usr/lib/.*/program/libicudata\.so.* -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libsts645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libvclplug_gen645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libwrp645li\.so -- system_u:object_r:texrel_shlib_t /usr/lib/.*/program/libswd680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/librecentfile\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsvx680li\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libcomphelp4gcc3\.so -- system_u:object_r:texrel_shlib_t /usr/lib(64)?/.*/program/libsoffice\.so -- system_u:object_r:texrel_shlib_t [root@workstation files]# -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/

3 2

Making httpd work with trac and svn
by Robin Bowes 14 Dec '05

14 Dec '05

Hi, I'm using httpd, trac, and svn on FC4 with svnmailer providing svn commit notifications. I've found I have to add the following local policies to allow this combination to work: # Needed to allow httpd to send ticket notifications via # direct connection to smtp port as httpd user allow httpd_t smtp_port_t:tcp_socket name_connect; # Needed to allow svnmailer to execute and send commit notifications # using sendmail as httpd user allow httpd_t trac_var_t:file execute; allow httpd_t trac_var_t:file execute_no_trans; allow restorecon_t devpts_t:chr_file getattr; allow httpd_t sbin_t:lnk_file read; Is there a better way to do this, i.e. without adding these missing TEs? R.

2 6

Adding two new booleans to httpd to tighten it's security.
by Daniel J Walsh 14 Dec '05

14 Dec '05

Currently policy allows httpd to connect to relay ports and to mysql/postgres ports. Adding these booleans * httpd_can_network_relay * httpd_can_network_connect_db And turning this feature off by default. This is going into tonights reference policy and into FC4 test release. If we had these turned off we would have prevented the last apache worm virus. This could cause problems for people who run httpd relays or have their apache databases talking to mysql and postgres databases over the network. You can turn the features back on by executing: setsebool -P httpd_can_network_relay=1 or setsebool -P httpd_can_network_connect_db=1 Will consider adding this feature to RHEL in a future update. Comments? Dan --

9 18

Interesting reading on exec* access checks.
by Daniel J Walsh 13 Dec '05

13 Dec '05

http://people.redhat.com/drepper/selinux-mem.html We are planning on turning off allow_execmem, allow_execmod, allow_execheap for unconfined_t in targeted policy. We are working to clean up any problems this might cause. This will add additional security features to Userspace, but might cause headaches. If you have the latest policy installed on Rawhide selinux-policy-targeted-2.1.0-3 or later you can try it out by running setsebool -P allow_execmem=0 allow_execmod=0 allow_execheap=0 You might need to relabel /usr/lib and /lib. Any help would be appreciated. :^) --

5 7

RE: Problems with httpd and SElinux.
by Dan Thurman 13 Dec '05

13 Dec '05

>From: fedora-selinux-list-bounces(a)redhat.com >[mailto:fedora-selinux-list-bounces@redhat.com]On Behalf Of Daniel B. >Thurman >Sent: Tuesday, November 08, 2005 3:43 PM >To: Robert Cahn; Daniel J Walsh >Cc: fedora-list(a)redhat.com; fedora-selinux-list(a)redhat.com >Subject: RE: Problems with httpd and SElinux. > > >>From: Daniel J Walsh [mailto:dwalsh@redhat.com] >>Sent: Monday, November 07, 2005 9:30 AM >>To: Daniel B. Thurman >>Cc: fedora-selinux-list(a)redhat.com >>Subject: Re: Problems with httpd and SElinux. >> >> >>Daniel B. Thurman wrote: >>> Folks, >>> >>> I was asked to post this information here. To explain things, >>> I have installed FrontPage extensions on FC4 but not realizing >>> that I had to first disable SElinux for httpd first, but to make >>> a long story short, I was able to install FP and then restore >>> SElinux protections for httpd, but on reboot, SElinux refused >>> to allow httpd to start and I suspect it had something to do >>> with the FrontPage additions to the /etc/httpd/conf/httpd.conf >>> file. I currently have SElinux protections turned off for >>> https. Below is the audit file, hope it helps show the problem. >>> >>> type=AVC msg=audit(1131056930.757:251): avc: denied { >>name_bind } for pid=4946 comm="httpd" src=8090 >>scontext=root:system_r:httpd_t >>tcontext=system_u:object_r:port_t tclass=tcp_socket >>> type=SYSCALL msg=audit(1131056930.757:251): arch=40000003 >>syscall=102 success=no exit=-13 a0=2 a1=bfc779f0 a2=750218 >>a3=8b8da58 items=0 pid=4946 auid=4294967295 uid=0 gid=0 euid=0 >>suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" >exe="/usr/sbin/httpd" >>> type=SOCKADDR msg=audit(1131056930.757:251): >>saddr=0A001F9A000000000000000000000000000000000000000000000000 >>> type=SOCKETCALL msg=audit(1131056930.757:251): nargs=3 a0=5 >>a1=8b8da84 a2=1c >>> >>> Kind regards, >>> Dan >>> >>> >>We do not currently allow apache to listen on port 8090, >>but this looks legitimate, so I will add to policy. >>You can install policy (selinux-policy-targeted-sources >>for now and add a line to: >>/etc/selinux/targeted/src/policy/domains/misc/local.te >>portcon tcp 8090 system_u:object_r:http_port_t >> >>Then execute make -c /etc/selinux/targeted/src/policy load >> >>and you should be able to use that port. >> > >The information you gave me above does not work. I got all >sorts of compile errors. BTW, the make should be "make -C". > >>From Paul Howarth, I tried: >============================================= >If you want httpd to be able to listen on port 8090, and you have the >policy sources installed, you can do this by adding the following line >to /etc/selinux/targeted/src/policy/net_contexts: > >portcon tcp 8090 system_u:object_r:http_port_t > >Then you need to compile and reload the security contexts: ># make -C /etc/selinux/targeted/src/policy reload >============================================= > >This all compiles fine now. > >Testing to see if httpd can now restart with the new policies: >1) setsebool -P httpd_disable_trans 0 >2) Restart httpd for this to take effect: service httpd restart > >Httpd can restart with no failure messages. The httpd server >now runs fine. > >HOWEVER - Testing FrontPage client against my FC4 box FAILS to >connect and the reason revealed in /var/log/httpd/error_log: > >[Tue Nov 08 15:25:40 2005] [error] (13)Permission denied: >Could not create key file >"/usr/local/frontpage/version5.0/apache-fp/suidkey.17096" in >FrontPageInit(). Until this problem is fixed, the FrontPage >security patch is disabled and the FrontPage extensions may >not work correctly. > >I suspect that there is a SElinux policy that is preventing the FP >client program from creating and deleting the suidkey file it needs >in order to startup and begin listening for FP Client requests. Please >note that the process number is created and destroyed for the >suidkey file >and this is happening from within the httpd service file and >has nothing >to do with the FP client connection attempts. SELinux policy >is preventing >the service file from creating and destroying this file. > >So - in order to get back the successful FP client connections >as before, >performing these steps: > >1) setsebool -P httpd_disable_trans 1 >2) Restart httpd for this to take effect: service httpd restart > >The httpd/error_log error message does not appear and I can now >connect with to the FC4 with the FP client. > >Dan Thurman. > >-- Huh? Who resent this? This one was sent 11/7/2005... I replied back to Daniel J Walsh with an attachment with the output of /var/log/audit/audit_log file that showed why *many* denials that were occuring with SElinux preventing the FrontPage process from working within httpd. In case Daniel did not get it, I am attaching the file again. ============================================== Daniel J. Walsh: ================ >>What did you see for AVC messages in /var/log/messages or >>/var/log/audit/audit.log? >> > >Please see the attached file. It is the /var/log/audit/audit.log >file and is 13k compressed. I tried best as I could to trucate to >relevant logs pertaining to httpd/fp issues. Please let me know if >you need anything else. ============================================== Kind regards, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.0/167 - Release Date: 11/11/2005

3 2

issue with named
by Craig White 13 Dec '05

13 Dec '05

from /var/log/messages Dec 12 05:11:48 srv1 named[18083]: /var/named/clsurvey.com.hosts.jnl: create: permission denied Dec 12 05:11:48 srv1 kernel: audit(1134389508.478:0): avc: denied { add_name } for pid=18084 comm=named name=clsurvey.com.hosts.jnl scontext=root:system_r:named_t tcontext=system_u:object_r:named_zone_t tclass=dir Dec 12 05:11:48 srv1 named[18083]: client 192.168.1.1#33259: updating zone 'clsurvey.com/IN': error: journal open failed: unexpected error I have added to /etc/selinux/targeted/src/policy/domains/local.te allow named_t named_zone_t:dir write; and then make reload but the problem doesn't go away. Suggestions? Thanks Craig

3 4

RE: default deny for uncofined_t using targeted?
by Steve Brueckner 13 Dec '05

13 Dec '05

Stephen Smalley wrote: > On Fri, 2005-11-18 at 15:17 +0000, Paul Howarth wrote: >> Won't that kill all network access, including via localhost, rather >> than just eth0 access? > > Well, yes, good point ;) > > Also looks like Dan reworked the old netifcon statements and netif > types as part of the network macro work. > > Ok, so one approach might be to: > - Add a netifcon statement to policy/net_contexts (between the > portcon entries and the nodecon entries) to distinguish eth0: > netifcon eth0 system_u:object_r:netif_eth0_t > system_u:object_r:unlabeled_t - Add the type to > policy/types/network.te (or anywhere in the policy): type > netif_eth0_t, netif_type; - Change the allow rule in > unconfined_domain from allow $1 netif_type:netif *; > to: > allow $1 netif_t:netif *; > so that unconfined_t no longer gets access to all netif types, just > the default one (which covers loopback). > > Looks like macros/network_macros.te already limits itself to > netif_t:netif, so it will also cease granting access to eth0 when you > make the above changes without needing to modify the macro itself. Well this seemed to be working, but then something strange happened. I wanted ssh to work over eth0, so I added this to domains/program/ssh.te: auditallow sshd_t netif_type:netif *; allow sshd_t netif_type:netif *; This single change allowed ssh to use eth0, but apparently it also allows anything in unconfined_t to access eth0 also! For example, when I run nmap 192.168.1.109 it is no longer blocked: type=AVC msg=audit(1134421016.167:1744): avc: granted { rawip_send } for pid=2854 comm="nmap" saddr=192.168.1.80 src=55724 daddr=192.168.1.209 dest=1502 netif=eth0 scontext=root:system_r:unconfined_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Am I missing something fundamental or is this a bug? It seems to me that giving sshd_t access to eth0 shouldn't also cause everyone in unconfined_t to have access to eth0. Thanks for your help so far, Stephen Brueckner, ATC-NY

2 1

Re: Adding two new booleans to httpd to tighten it's security.
by Nicolas Mailhot 12 Dec '05

12 Dec '05

On Sam 10 décembre 2005 21:59, Nicolas Mailhot wrote: > > On Sam 10 décembre 2005 21:37, Ulrich Drepper wrote: >> Nicolas Mailhot wrote: >>> avc: denied { execmem } for pid=2950 comm="thunderbird-bin" >>> scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 >>> tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process >> >> If this really happens then this is a terrible bug in tbird. It's >> nothing which should be patched with the policy. By not adding the >> support to catch these problems early the code won't be fixed. >> >> New rules are often added for a specific purpose: discover bugs in >> programs and stop existing threats. It would be wrong to not attack >> these as soon as possible. > > It really happens, at least there (and thunderbird hasn't been updated, > only selinux was - so it was happening before). > > So there are lots of work to do with existing rules before even thinking > of moving to new bits like httpd port policy. Vanilla x86_64 thunderbird (thunderbird-1.5-0.5.1.rc1) (installed a week ago when evo started dying on no ascii folders), only extension : enigmail 0.93.1 (not that it actually works) Rawhide killed evo a week ago (#174931) It killed thunderbird today I'm running out of imap clients. I still have squirrelmail, and it's not even the rawhide one, since that one started misbehaving at least a month before (#162852) Do you want a bug entry for this problem too ? Regards, -- Nicolas Mailhot

3 11

Where is policy source?
by Yuichi Nakamura 12 Dec '05

12 Dec '05

Hi. I've begun to try Rawhide. I installed FC5-test1 and did yum update. Policy is now reference policy(selinux-policy-targeted-2.1.2-2). However, I can not find selinux-policy-targeted-source package for refpolicy. Where is policy source? How do I edit policy? --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) SELinux Policy Editor: http://seedit.sourceforge.net/

2 2

sandboxing rpms
by Benjamin Youngdahl 12 Dec '05

12 Dec '05

Greetings. My understanding is that RPM packages will be able to install policy modules in FC5, an improvement over a monolithic policy. I have a couple of questions about the implementation: 1. Is it possible to provide a temporary policy (either external, or with an RPM) that constains what the specific RPM's installation can do? The motivation here is that when I install an RPM, it would be nice if I would be able to get a declarative list of what the RPM wants access to do. The RPM tool might summarize before installing the package what the package will be allowed to do, by parsing this "installation sandbox" policy. 2. Is it possible to limit (or discover easily in advance) what changes to the system policy are being made by the RPM's policy modules? The motivation being that I want to be sure that the policy modules installed by an RPM are well behaved concerning overall system constraints. Apologies in advance if these questions are way off-base, or belong somewhere else. Thanks for your thoughts, Ben

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux December 2005