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.
--
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
