fedora-selinux August 2010 archive
Main Archive Page > Month Archives  > fedora-selinux archives
fedora-selinux: Re: netif labelling

Re: netif labelling

From: Dominick Grift <domg472_at_nospam>
Date: Sun Aug 29 2010 - 20:22:56 GMT
To: Mr Dash Four <mr.dash.four@googlemail.com>

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!
>

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux