Re: netif labelling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux