On 08/29/2010 10:17 PM, Mr Dash Four wrote: > >>> Yeah, but as part of the same policy I also need to bind to and >>> send/receive tcp packets on the tun0 interface (as I posted before - I >>> need 2 active interfaces)! Where does that go if I have to use the bind >>> statement? >>> >> >> So you would additionally add: >> >> corenet_tcp_sendrecv_tun0_if(myapp_t) >> corenet_tcp_bind_mysqld_port(myapp_t) >> >> That would allow myapp_t to also tcp sendrecv tun0 network interface. >> and it would allow myapp_t to bind tcp sockets to mysqld ports. >> >> But i think i see where this is going: >> >> Because now myapp_t can also connect to mysqld ports via the tun0 >> network interface. Something you probably wanted to prevent. >> >> Additionally now myapp_t can also listen on the lo network interface. >> Also something you probably wanted to prevent. >> > Exactly!!! > > The whole point of this entire thread is to see how to split both > interfaces and define various permissions, which are interface dependant. > > If I cannot do that with the above macros, then there must be another > way, hence why I would need to see what has been generated after > corenetwork.te.m4 has done its job! I cannot, for one second, believe > that it is not possible - what is the point of labelling the network > interfaces if you cannot specify which permissions go to which interface?! > > Actually....wait a second! > > > Looking back at the macros all this translates to something like: > > allow myapp_t lo_netif_t:netif { tcp_send tcp_recv }; > allow myapp_t mysqld_port_t:tcp_socket { name_connect }; > > Correct? > > If so, then I have myapp_t bound to lo_netif_t (lo interface, sending > and receiving tcp packets) AND mysqld_port_t (on the same interface and > allow connections to be made on it), right? > > What if I define another type and name it, say, 'myapp_tun0_t' at the > beginning of my policy file and then issue this: > > allow myapp_tun0_t tun0_netif_t:netif { tcp_send tcp_recv }; > allow myapp_tun0_t voip_sandbox_port_t:tcp_socket { name_bind }; And what if another instance of the same app may use lo_netif_t and not tun0_netif_t. How are you going to define which domain the app should run in? > This will bind my newly defined type (myapp_tun0_t) to the tun0 > interface AND then bind to my (also defined) voip_sandbox port (i.e. > listen for connections, but ONLY on the tun0 interface). Would that > separate both permissions for both ports as they relate to different > types? If so ... mission accomplished? > > >> I am not sure how to best deal with this problem. >> > I offered something above, though I am not sure if the two types defined > (myapp_t and myapp_tun0_t) would sit together in one policy file and how > would this be permitted in one executable file/type - that is the > unknown for me. All this, if the above is doable, of course! >
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux