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