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

[Daniel J Walsh]

Tom London wrote:

>On 5/29/05, Ivan Gyurdiev <ivg2 at cornell.edu> 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.
>>
>>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?
>>
>>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.
>>
>>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.
>>
>>    
>>
>>>+allow ptal_t port_t:tcp_socket name_bind;
>>>      
>>>
>>This lets it bind to any port... why not a specific one?
>>
>>--
>>Ivan Gyurdiev <ivg2 at cornell.edu>
>>Cornell University
>>
>>
>>    
>>
>My error on can_network_tcp().  Should be 'can_network_tcp(ptal_t)'. I
>agree with your comment on 'name_bind'.
>
>I thought 'can_network_tcp()' was just a combination of the client and
>server cases.
>
>Regarding specific port.  Yeah, you're correct.  ptal-photod wants to
>connect on 5703:
>May 28 10:01:53 fedora kernel: audit(1117299713.078:31): avc:  denied 
>{ name_bind } for  pid=3576 comm="ptal-photod" src=5703
>scontext=root:system_r:ptal_t tcontext=system_u:object_r:port_t
>tclass=tcp_socket
>
>Havent't done this before.
>
>So I do this by adding something like the following to net_contexts?
>ifdef(`cups.te', `portcon tcp 5703 system_u:object_r:ptal_port_t')
>
>and add something like the following to types/network.te?
>ifdef(`cups.te', `type ptal_port_t, port_type, reserved_port_type;')
>
>and then change 'allow ptal_t port_t:tcp_socket name_bind' to?
>allow ptal_t ptal_t:ptal_port_t name_bind;
>
>Is that right? A better/simpler way to do this?
>   tom
>  
>
Can ptal be a client?  If not then you should call
can_network_server_tcp

If it can be a client, you need a name_connect allow rule.



--