Label eth0 with a MCS security category?

[Jason Shaw]

In the example below with the foo_user_t, my understanding is that after the
new type is created, it should be assigned to a role, and then the role
assigned to a user.

The problem I am seeing is that after I assign the new role to the user, id
-Z still shows the defualt unconfined_r role assigned.

Details:

// labeled the network interfaces
semanage interface –a –t netif_t –r s0:c4 eth0
semanage interface –a –t netif_t –r s0:c5 eth1

// created a new type

module netIfControl 1.0;

require {
 # allow icmp as part of tcp
 class netif { tcp_send tcp_recv };
 type netif_t
};

# define a new type
type user_1_t;

# define a new role and assign the type to it
# later assign the new role to the user using semanage

role accessNetworkInterface_r types user_1_t;

# define what the type is permitted to do
allow user_1_t netif_t:netif { tcp_send tcp_recv };

// compile, package and load module
checkmodule -M -m -o netIfControl.mod netIfCntrol.te
semodule_package -o netIfControl.pp -m netIfControl.mod
semodule -i netIfControl.pp

// no errors reported

// Create a new SeLinux user and assign to the networkInterface_r role

semanage user -a -L s0 -r S0:c5 -R networkInterface_r -P user
networkInterface _u

// Map the new SELinux user to a Linux user

semanage login -m -s networkInterface_u -r s0:c5 user_1

// Login via ssh as user_1
id -Z
user:u system_r:unconfined_t:s0




On Mon, Aug 24, 2009 at 3:58 PM, Paul Moore <paul.moore at hp.com> wrote:

>  On Sunday 23 August 2009 09:51:26 pm James Morris wrote:
> > On Fri, 21 Aug 2009, Jason Shaw wrote:
> > > In FC-11, under the targeted policy, is it possible to label an
> ethernet
> > > interface (such as eth0, eth1) with a specific MCS category?
> > >
> > > Example:
> > > 1) Use semanage to assign user1 to s0:c5
> > > 3) Assign eth0 to s0:c4 (Can this be done?)
> > > 4) Assign eth1 to s0:c5
> > >
> > > Desired result: if user1 tries to ping -I eth1 <ip_address> the ping
> > > command will work (as both eth1 and user1 have category c5). If user1
> > > tries to ping -I eth0 <ip_address>, the ping command will not work
> > > (category mismatch between user and eth1).
> >
> > It should be possible to do this via iptables and SECMARK.
> >
> > i.e. match all packets on ethN and label with the MCS category then use
> > the SELinux packet flow policy rules.
> >
> > I haven't looked at this stuff for a while, so cc'ing Paul Moore, who
> > maintains the code.
>
> [NOTE: I'm not currently subscribed to fedora-selinux-list, feel free to
> fwd]
>
> Hi Jason,
>
> Using your example as a guide, there are actually two ways to accomplish
> what
> you want to do.  The first approach James already mentioned: Secmark.  The
> second approach uses the network ingress/egress controls.  The best choice
> for
> your particular case is going to likely depend on whatever other SELinux
> network access controls you have in place and which administration
> mechanism
> you prefer ... however, here is a quick overview of what is involved for
> both.
>
>  * Secmark
>   - Establish a iptables rules marking the outbound packets
>        # iptables -t mangle -A OUTPUT -o eth0 -j SECMARK \
>       --selctx system_u:object_r:foo_packet_t:s0:c4
>        # iptables -t mangle -A OUTPUT -o eth1 -j SECMARK \
>       --selctx system_u:object_r:foo_packet_t:s0:c5
>   - Ensure you have the right SELinux policy in place
>        allow foo_user_t foo_packet_t:packet { send };
>
>  * Ingress/Egress Controls
>   - Label the interfaces
>        # semanage interface -a -t netif_t -r s0:c4 eth0
>        # semanage interface -a -t netif_t -r s0:c5 eth1
>   - Ensure you have the right SELinux policy in place
>        allow foo_user_t netif_t:netif { egress };
>
> The examples above are pretty simple but they should get you going in the
> right direction - if you have any questions don't hesitate to ask.
>
> --
> paul moore
> linux @ hp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20090825/729edf99/attachment.htm>