On Mon, Sep 28, 2009 at 05:44:09PM +0200, Roberto Sassu wrote:
> On Monday 28 September 2009 15:38:23 Dominick Grift wrote:
> > 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.
> >
> Sorry, i tried to use the 2 line above but the compile process fails with
> message:
>
> ---------------------
> Compiling targeted base module
> /usr/bin/checkmodule -M -U allow base.conf -o tmp/base.mod
> /usr/bin/checkmodule: loading policy configuration from base.conf
> tmp/rolemap.conf":1320:ERROR 'The context for SID netif is multiply defined' at
> token 'sid' on line 1006589:
> sid netif system_u:object_r:netif_eth0_t:s0
> sid devnull system_u:object_r:null_device_t:s0
> /usr/bin/checkmodule: error(s) encountered while parsing configuration
> make: *** [tmp/base.mod] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.JFoPCq (%install)
> ----------------------
>
> Instead i noted that when applying my patch in the file corenetwork.if, there
> is present this interface:
>
> interface(`corenet_tcp_sendrecv_eth0_if',`
> gen_require(`
> type eth0_netif_t;
> ')
>
> allow $1 eth0_netif_t:netif { tcp_send tcp_recv egress ingress };
> ')
>
OK, well the interface seems correct but your call to it throws a syntax error. I guess this might in that case be related to type sshdlow_t.
It might be a good idea to check whether that type is a usable domain type.
>
> > > 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?
> >
>
> Yes, but unfortunately i've not considered that remote accesses were denied
> due to a bad configuration of mls levels.
> Then, using the ssh_server_template, the ssh server is always able to
> transition to whatever domain. I'm currently finding what rules must be
> commented to explicitly define domains transitions.
>
>
>
> > > 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
> >
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Attachment:
pgp3YN4nMjpUi.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
