>> 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 };
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!
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
