Adding two new booleans to httpd to tighten it's security.

Adding two new booleans to httpd to tighten it's security.

[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

-- 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Adding two new booleans to httpd to tighten it's security.

[Daniel J Walsh]

Joe Orton wrote:
> On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote:
>   
>> Currently policy allows httpd to connect to relay ports and to 
>> mysql/postgres ports.
>>
>> Adding these booleans
>>    * httpd_can_network_relay
>>    * httpd_can_network_connect_db
>>
>> And turning this feature off by default.  This is going into tonights 
>> reference policy and into FC4 test release.
>>     
>
> Do you mean FC4 or FC5?  This should not go in an FC4 update 
> off-by-default since it will break working setups.  Make it 
> on-by-default if you want to ship this to FC4 users and off-by-default 
> with a big release note for FC5.
>   
Ok plan is to add this to FC4 With relay and database network connect 
turned on by default.
> What's the difference between httpd_can_network_relay and 
> httpd_can_network_connect?
>   
They are just more specific.  They allow specific connections to relay 
ports (http, ftp, gopher etc) and database ports (mysql and postgres).
> Do we still have the problem that httpd cannot reap idle children 
> properly when the latter is set?  That really really does need to work 
> by default.
>
>   
Do you have a bugzilla for this?
> joe
>   


-- 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Adding two new booleans to httpd to tighten it's security.

[Daniel J Walsh]

Robert L Cochran wrote:
> Joe Orton wrote:
>
>> On Fri, Dec 09, 2005 at 03:58:14PM -0500, Daniel J Walsh wrote:
>>  
>>
>>> Currently policy allows httpd to connect to relay ports and to 
>>> mysql/postgres ports.
>>>
>>> Adding these booleans
>>>   * httpd_can_network_relay
>>>   * httpd_can_network_connect_db
>>>
>>> And turning this feature off by default.  This is going into 
>>> tonights reference policy and into FC4 test release.
>>>   
>>
>> Do you mean FC4 or FC5?  This should not go in an FC4 update 
>> off-by-default since it will break working setups.  Make it 
>> on-by-default if you want to ship this to FC4 users and 
>> off-by-default with a big release note for FC5.
>>
>> What's the difference between httpd_can_network_relay and 
>> httpd_can_network_connect?
>>
>> Do we still have the problem that httpd cannot reap idle children 
>> properly when the latter is set?  That really really does need to 
>> work by default.
>>
>> joe
>>
>> -- 
>> fedora-selinux-list mailing list
>> fedora-selinux-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>
>>
>>  
>>
> I'd like to completely agree with Joe. I'm beginning to have quite a 
> lot invested in httpd, PHP and related database code and I don't want 
> SELinux breaking what is there without a lot of warning. For new 
> installs of FC4, I've been forced to turn off SELinux support for 
> these applications. They simply don't work otherwise.
>
> Bob Cochran
> Greenbelt. Maryland, USA
>
>
Have your reported your problems here or in bugzilla?

-- 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Adding two new booleans to httpd to tighten it's security.

[Tom London]

VMWare has problems with execmem as previously reported:
type=AVC msg=audit(1134338328.000:56): avc: denied { execmem } for
pid=5215 comm="ld-linux.so.2"
scontext=root:system_r:unconfined_t:s0-s0:c0.c255
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1134338328.000:56): arch=40000003 syscall=125
success=no exit=-13 a0=bfc78000 a1=1000 a2=1000007 a3=98b6e0 items=0
pid=5215 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 comm="ld-linux.so.2" exe="/lib/ld-2.3.90.so"

and
time->Sun Dec 11 13:05:51 2005
type=AVC_PATH msg=audit(1134335151.660:39):
path="/usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0"
type=SYSCALL msg=audit(1134335151.660:39): arch=40000003 syscall=125 per=400000
success=no exit=-13 a0=b7c99000 a1=7b000 a2=5 a3=bfc5a1e0 items=0
pid=4418 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 comm="vmware" exe="/usr/lib/vmware/bin/vmware"
type=AVC msg=audit(1134335151.660:39): avc:  denied  { execmod } for
pid=4418 comm="vmware" name="libgdk-x11-2.0.so.0" dev=dm-0 ino=343461
scontext=root:system_r:unconfined_t:s0-s0:c0.c255
tcontext=system_u:object_r:lib_t:s0 tclass=file


Reply from VMware on my complaint about execmem issues:


As your system refuses to execute even /lib/ld-2.3.90.so (if I
understand it correctly), you seems to have some problem...

None of VMware parts (at least I believe) require executable stack or
heap. Applications which need it explicitly call mmap with PROT_EXEC.
Another question is whether libraries we ship are correctly tagged to
signal this - but it should not be problem as you can install all
libraries VMware needs from your distribution, VMware just ships
libraries it was linked with as it is simpler for us to ship you
libgdk-whatever than (finding and) explaining that you must to install
some-strange-package-with-no-gdk-in-filename to get VMware to work. On
"correct" system with all libraries you should be able to run vmware
directly by /usr/lib/vmware/bin/vmware. Apparently your system is
missing at least openssl097...
--------------------------------------------


My understanding from this thread on how execmem works is that calling
mmap with PROT_EXEC can (will?) still trigger execmem.  Right?

Here is the link to the discussion thread: Please hop on to help/clarify!
http://www.vmware.com/community/thread.jspa?messageID=320149&#320149

thanks,
   tom
--
Tom London


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Adding two new booleans to httpd to tighten it's security.

[Tom London]

Here is the response from vmware:

VMware generates lots of code on the fly, so flipping PROT_EXEC with
PROT_WRITE would not reasonably work. Especially not in the
multithreaded environment where it would continuously cause IPIs to be
send between processors, slowing down everything. If SELinux default
policy authors decided that they cannot trust applications, then I'm
afraid that you'll have to create special policy for VMware.

libgdk-x11's library from vmware's directory will be used only if
libraries on your host are found to be inadequate. Try
'VMWARE_USE_SHIPPED_GTK=no vmware' and it should tell you which
libraries are missing on your box. After you'll install them then
libgdk-x11 from /usr/lib should be used.

-------------------------------------------------------------
I haven't gotten the library test working yet.....

tom
--
Tom London


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.