netif labelling

[Dominick Grift]

On 08/29/2010 08:10 PM, Mr Dash Four wrote:
> 
>> i would probably use s0 - mls_systemhigh if possible for compatibility
>> with mls policy
>>   
> Noted.
> 
>>> Also, as part of the policy I wish to enable/restrict the program to
>>> connect on mysqld port, but ONLY on the local (lo) interface and then
>>> listen/bind on a predefined port but on the tun0 interface. How do I do
>>> that? There are 2 relevant macros in corenetwork.te.m4 for this:
>>>
>>> corenet_tcp_bind_voip_sandbox_port(voip_sandbox_t)
>>> corenet_tcp_connect_mysqld_port(voip_sandbox_t)
>>>     
>>
>> those are unrelated to netif related policy.
>> Basically when you declare a netif type there are probably interface
>> create that provide access to your network interface type. That is what
>> governs whether your app can or cannot use it. If your app cannot use a
>> network interface, then it cannot use it to connect to mysqld.
>>   
> You've lost me here.
> 
> In my policy I would need to do the following: 1) allow access to

example:

corenet_tcp_sendrecv_lo_if(myapp_t)
corenet_tcp_connect_mysqld_port(myapp_t)

It means myapp_t can only tcp sendrecv on netif_lo_t.
And it can connect to mysqld tcp ports.

so:

It can only connect to mysqld tcp ports using the lo interface because
thats the only interface it can tcp sendrecv.

> lo:mysqld, BUT restrict access to tun0:mysqld; and 2) allow bind on
> tun0:voip_sandbox, BUT restrict access to lo:voip_sandbox if such
> attempts are made.
> 
> In other words, both lo and tun0 as interfaces should be allowed (and
> properly labelled) - I presume with network_interface(..) - as mentioned
> in my previous post (every other access to another interface, if exist,
> should be restricted), though different ports should be enabled for
> different network interfaces.
> 
> The point I made above is that corenet_tcp_bind_$1_port and
> corenet_tcp_connect_$1 do not allow me to specify on which interface I
> need this to be allowed!
> 
> If I am able to decipher this macro I will certainly be able to create a
> group of statements for the 2 different interfaces, but as it stands I
> seem to be able to define voip_sandbox port binding on ANY interface as
> well as connecting to mysqld port also on ANY interface, which is not
> what I want.
> 
> 
>> The $1_$2 is probably some hack to make it work. its just the single
>> parameter $3 (domain)
>>   
> Is there any way I could 'expand' these statements and see what this
> really is made of?
> 
>>> If I manage to 'decipher' these I may restrict the above statements to
>>> the proper net device type if there is no suitable other macro found,
>>> but as it stands I am a bit stuck!
>>>
>>>     
>>
>> Like i said above the rule has nothing to do with network interfaces. It
>> governs access for specified domain to connect to tcp ports.
>>   
> Which is not what I need really as I would like to specify/govern access
> for specific domain to connect/bind to tcp ports on specific interface!
> 
>> Also you've taken the above interface block from the template file. This
>> file is used to automatically generate interfaces for declared port
>> types.
>>   
> 
> What do you mean? I thought this is a part of the policy as statements
> from this file are used by a lot of policy modules, or are you saying
> this transforms to something else?

I mean the corenetwork module works a bit different than the common
modules. In that it uses a template to generate interfaces for declared
port types automatically. Thats where it uses the file you were looking
at for. Its not an normal interface file and it should not be used
manually. Theres a script in refpolicy that does it for you.

All you need to do is declare network object types and build the policy,
then the script will generate the interfaces for you, unlike it does
with most other modules.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100829/8ef0c2fb/attachment-0001.bin