Questions about network_macros [ was: Re: more ptal_t (strict) ]

Daniel J Walsh dwalsh at redhat.com
Mon May 30 09:35:15 UTC 2005


Ivan Gyurdiev wrote:

>>+can_network_tcp(ptal_t, self)
>>    
>>
>
>Can someone clarify how networking rules are supposed to work.
>
>1) There is poor documentation on all network macros - they all
>take 2 or 3 arguments, and only one is documented.
>  
>
There should be 9 that are used
can_network (Allow all network activity)
can_network_server  (tcp and udp, requires a name_bind)
can_network_client   (tcp and udp, requires a name_connect)
can_network_client_udp (udp requires)
can_network_client_tcp (tcp requires a name_connect)
can_network_server_udp (udp requires a name_bind)
can_network_server_tcp (tcp requires a name_bind)
can_network_tcp (tcp requires a name_connect and a name_bind)
can_network_udp (udp requires a name_bind)

The other port type parameter can be used to "lock down" udp connects 
since name_connect does not work for udp.

>2) There is optional socket type and port type. Looking at policy,
>those don't seem to be used very often. Is that a bad thing?
>
>  
>
socket type is used to lock down tcp/udp,  port type is used to lock 
down whicp ports udp can connect to.
socket type is basically used by other macros.

>3) Then there's name_connect and name_bind.
>Why are those not incorporated in any network macros,
>but at the same time you have the ability to specify a port type
>in base_can_network. 
>  
>
I don't recall why, but name_connect was added the way it was because 
name_bind was done that way. 
Also passing a lot of parameters in macros is somewhat frowned on, since 
it complicates the code quite
a bit.  It was decided to break these functions in to multiple function 
calls.

>Basically I've been writing:
>
>can_network_client(domain)
>allow domain specific_port:tcp_socket/udp_socket name_connect;
>
>can_network_server(domain)
>allow domain specific_port:tcp_socket/udp_socket name_bind;
>
>Now this seems wrong - what's are the proper rules?
>It seems to me that name_bind and name_connect should be integrated
>w/ network_macros, and I should specify a port/socket_type on network 
>macros that I invoke.
>
>.... 
>Then there wouldn't be need for special purpose name_connect macros
>like can_resolve, can_ldap...
>
>define(`can_ldap',`
>ifdef(`slapd.te',`
>can_network_client_tcp($1, `ldap_port_t')
>allow $1 ldap_port_t:tcp_socket name_connect;
>')
>')
>
>Why does slapd.te have to be present to name_connect to a ldap port?
>This seems wrong... I need to connect to ldap from evolution.
>The ldap port is not defined in slapd.te.
>
>  
>
It is wrong.  I will fix.

>>+allow ptal_t port_t:tcp_socket name_bind;
>>    
>>
>
>This lets it bind to any port... why not a specific one?
>
>  
>
Not sure.  Does ptal use portmap?  If not then this is a bug.

-- 





More information about the fedora-selinux-list mailing list