> 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. So why don't we add name_connect and name_bind to the macros where required. > 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. I don't argue with the breaking of calls - that seems like a good idea, but if you say name_bind and name_connect are required in certain scenarios, then we should probably add those to the networking macros. For example, the port_type argument in base_can_macros could be used for name_connect, not only for send_msg/rcv_msg. For name_bind I guess you'd need another argument, since servers should be able to send/receive to all ports (actually - should this be all unrestristed ports?) > >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; I'm thinking something like: - include name_bind and name_connect where appropriate - require socket_type (but only if udp/tcp not specified) - include port_type in server for the port that server can bind to (maybe require port_type too - why is all of this optional if you want to enforce stricter policy?) can_network_client(domain, socket_type, (, port_type)?); can_network_client_(tcp|udp) (domain (,port_type)?); socket_type - type of socket over which to communicate port_type - server port the client is authorized to talk to can_network_server(domain, socket_type, (, port_type)?); can_network_server_(tcp_udp) (domain (,port_type)?); socket_type - type of socket over which to communicate port_type - server port the server is authorized to bind to/listen on (it can connect to all unrestricted ports (but not name_connect?)); or something like that... Then instead of calling can_resolve: can_network_client_udp(domain, dns_port_t) or can_network_client(domain, udp_socket, dns_port_t) Instead of can_ldap: can_network_client_tcp(domain, ldap_port_t) or can_network_client(domain, tcp_socket, ldap_port_t) -- Ivan Gyurdiev <ivg2@xxxxxxxxxxx> Cornell University -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
