Re: Limiting the power of can_network, improving the security of strict policy.

[Russell Coker <rcoker@redhat.com>]

On Wed, 2004-10-27 at 11:04 -0400, Daniel J Walsh wrote:
> Finally we are looking into limiting the power of can_network.  
> Currently any daemon that has can_network can receive
> and establish TCP/UDP connections.  The only thing not provided is 
> name_bind.  I want to break this out to eliminate the
> ability for daemons also to connect.  So an incoming only daemon, can 
> not establish a connection back out.  To do this
> I have modified create_socket_perms and eliminated the connect call.  I 
> have added a connect_socket_perms which includes
> the create_socket_perms.  This has caused many changes to be made in 
> policy, and I am not sure if it was a good idea?

I think it might be better to leave create_socket_perms as it is and
have another macro connected_socket_perms which doesn't have create
access.

> Also I modified can_network to take a second parameter of the type of 
> the connection (udp or tcp).  This allows you to turn off tcp, connections
> on a UDP application.  (I am not sure you can do this for a tcp only app 
> if they are going to use name service.)

What if we have two new macros can_tcp_network() and can_udp_network()
which can_network() invokes.

> Is this a good idea or am I wasting my time?

It's a great idea!  But I think some minor changes to the way that
backward compatability works would be good.

--
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.