localpolicy.fc settings not always honoured
by Ted Rule
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/
18 years, 4 months
Making httpd work with trac and svn
by Robin Bowes
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.
18 years, 4 months
Adding two new booleans to httpd to tighten it's security.
by Daniel J Walsh
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
--
18 years, 4 months
Interesting reading on exec* access checks.
by Daniel J Walsh
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. :^)
--
18 years, 4 months
RE: Problems with httpd and SElinux.
by Dan Thurman
>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
18 years, 4 months
issue with named
by Craig White
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
18 years, 4 months
RE: default deny for uncofined_t using targeted?
by Steve Brueckner
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
18 years, 4 months
Re: Adding two new booleans to httpd to tighten it's security.
by Nicolas Mailhot
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
18 years, 4 months
Where is policy source?
by Yuichi Nakamura
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/
18 years, 4 months
sandboxing rpms
by Benjamin Youngdahl
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
18 years, 4 months
