Re: Custom labeling network interfaces

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

 



On Mon, Sep 28, 2009 at 03:06:48PM +0200, Roberto Sassu wrote:
> I downloaded the source policy and i created this patch:
> ----------------
> --- serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in.old      
> 2009-09-28 12:09:24.617041763 +0200
> +++ serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in  2009-09-28 
> 12:09:51.410362006 +0200
> @@ -261,6 +261,11 @@ network_interface(lo, lo,s0 - mls_system
>  typealias netif_t alias { lo_netif_t netif_lo_t };
>  ')
> 
> +build_option(`enable_mls',`
> +network_interface(eth0, eth0,s0 - mls_systemhigh)
> +')
> +
> +
>  ########################################
>  #
>  # Unconfined access to this module
> -----------------
> 
> 
> Then i recompiled the whole policy using the spec file, i installed it and i 
> relabeled the entire file system.
> The problem is that i'm not able to use the new interfaces, for example 
> "corenet_tcp_sendrecv_eth0_if".  When building a custom module that calls it, 
> the following message appears:
> 
> -----------------
> Compiling targeted userdom module
> /usr/bin/checkmodule:  loading policy configuration from tmp/userdom.tmp
> userdom.te":64:ERROR 'syntax error' at token 'corenet_tcp_sendrecv_eth0_if' on 
> line 151624:
>         corenet_tcp_sendrecv_eth0_if(sshdlow_t)
> #line 64
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> make: *** [tmp/userdom.mod] Error 1
> -----------------
> 
> In the patch described above i miss the line typealias netif.... because i 
> suppose that if eth0_netif_t is an alias of netif_t, allowing an access rule 
> for the last type means granting the privilege for all interfaces. 

I think your declaration is wrong:

Try this instead:

type netif_eth0_t, netif_type;
sid netif gen_context(system_u:object_r:netif_eth0_t,s0 - mls_systemhigh)

The syntax error signals that you interface call does not exists
corenet_tcp_sendrecv_eth0_if

That would make sense, since the declaration was wrong (non existant)

.. Although i am not sure, it has been a long time since i tried it.



> 
> Lastly i have another question about the ssh server and its ability to set new 
> domains for processes of remote users.
> I want to have two different servers, one which is able to set all possible 
> domains for the shell, another which have a capability to set only a subset of 
> domain. To accomplish this task i used the interface "ssh_server_template", i 
> copied from the file ssh.te all rules that involve the domain sshd_t and i 
> added the following lines:
> 
> -------------------
> interface(`ssh_server_users_interaction',`
> 	gen_require(`
> 		type $1_t, shell_exec_t;
> 		type $2;
> 	')
> 
> 	allow $1_t $2: process transition;
> 	allow $2 $1_t:process sigchld;
> 	allow $1_t $2:process { siginh };     
> 	dontaudit $1_t $2:process { noatsecure };
> ')
> -------------------
> 
> Is this correct or there's a way for that to be circumvented?
> Thanks for replies.

Not sure about this one. sorry. Did you test it?
> 
> 
> 
> On Saturday 26 September 2009 18:29:48 Dominick Grift wrote:
> > On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote:
> > > Hi all
> > >
> > > i want to create a set of rules that allow the administrator to decide
> > > the network interfaces on which daemons can listen to.
> > >
> > > To do this i created a custom policy module to define the type
> > > eth0_netif_t which is bound to the eth0 interface.
> > >
> > > type eth0_netif_t, netif_type;
> > > typeattribute eth0_netif_t netif_type;
> > >
> > >
> > > ifdef(`enable_mls',`
> > >
> > > gen_require(`type unlabeled_t;')
> > > netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 -
> > > mls_systemhigh) gen_context(system_u:object_r:unlabeled_t,s0 -
> > > mls_systemhigh)
> > >
> > > ')
> > >
> > > Next, i executed the following command:
> > >
> > > semanage interface -a -t eth0_netif_t eth0
> > >
> > > Then, without adding extra rules i tried to start the sshd daemon on this
> > > interface and the operation was successful. I see with the apol utility
> > > that sshd is allowed to bind on the generic interface netif_t but not on
> > > eth0_netif_t.
> > >
> > > How it's possible to explicitly grant the permission to listen on eth0
> > > for each daemon which needs it?
> > 
> > These types are declared in the corenetwork source policy, which is
> >  compiled into the base module. For you to be able to implement policy with
> >  regard to how domains can interact with network interface object type you
> >  would have to edit the policy. For example:
> > 
> > This is from apache.te:
> > 
> > corenet_tcp_sendrecv_all_if(httpd_t)
> > corenet_udp_sendrecv_all_if(httpd_t)
> > 
> > Which means that httpd_t can send and receive tcp and udp packets using all
> >  network interfaces. So these rule would have to be removed/replaced by
> >  rules that explicitly define how and which network interfaces httpd_t can
> >  access.
> > 
> > This would have to be done for each domain that has access to network
> >  interfaces via the "all_if" interfaces.
> > 
> > So if you really want to make this work, you should download the
> >  selinux-policy.src.rpm corresponding to the selinux-policy version that
> >  you currently have installed. Then extract the source rpm and prep the
> >  source ( apply the included patch(es) to the extracted included
> >  serefpolicy.tgz.
> > 
> > Then you would have to declare your custom interface object type in
> >  corenetwork.te.in and remove the "all_if" interface calls from each module
> >  that calls it. Replace it with rules the you want to enforce. When you
> >  build the policy interfaces will be automatically created by the
> >  corenetwork module. You can call these interfaces instead of using "local
> >  policy"
> > 
> > After you have modified the policy you would "clean the source" and
> >  repackage it (serefpolicy.tgz). Since you have already applies any
> >  included patches by redhat when you have "preparated the source" you no
> >  longer have to patch the source, thus you can remove any lines where it
> >  refers to 'patch' from the selinux-policy.spec that is included with the
> >  source rpm.
> > 
> > Also "bump" the version in the spec file so that it can be installed
> >  without forcing installation.
> > 
> > Then you would simply rebuild the selinux-policy.src.rpm using rpm-devtools
> >  (rpmbuild -ba selinux-policy.spec), and update your policy with rpm -Uvh
> >  selinux-policy*.rpm
> > 
> > The problem with this method though is that from that point you are the
> >  maintainer of your implemented policy, meaning you can no longer blindly
> >  update from the redhat packages if you do not want your modification to be
> >  resetted.
> > 
> > With EL5 this is not such a big problem since EL5 selinux-policy does not
> >  get updated very often.
> > 
> > hth
> > 
> > > Thanks in advance for replies.
> > >
> > > --
> > > fedora-selinux-list mailing list
> > > fedora-selinux-list@xxxxxxxxxx
> > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > 
> 
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Attachment: pgp094WhAyWT0.pgp
Description: PGP signature

--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

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

  Powered by Linux