Assigning a Type to Network Interfaces

[Jason Shaw]

Here is what I found. Using netlabelctl, I could successfully restrict all
inbound/outbound network access to the system on a specific interface. I
could then permit only SSH into the system via allow rules associated with
the peer label assigned using netlabelctl unlbl.That worked great. In fact,
I'm really excited to explore other possibilities using netlabelctl as it
has many valuable possible uses.

However, I found that my test app (with the allow rule below), could still
read and display packet data coming in on any interface even with all
interfaces assigned a unique peer_t using netlabelctl unlbl add. This was
true when no explicit allow rules were added for the test app (running in
myAPP_t). So while netlabelctl did require explicit allow rules for SSH to
send/receive data (I beleive for sshd_t), an allow rule was not required to
read raw data off of the interface for myAPP_t.

allow myApp_t self:packet_socket { create read bind ioctl };

My understanding is that a packet socket is read at the device driver level.
As such, is it possible that the packet socket is being read before
netlabelctl enforcements are taking place?

On Tue, Jan 19, 2010 at 3:54 PM, Paul Moore <paul.moore at hp.com> wrote:

> On Tuesday 19 January 2010 01:07:53 pm Jason Shaw wrote:
> > Can netif checks be enabled for 'packet_socket read'? If so, how?
> >
> > My app requires this allow rule:
> > allow myApp_t self:packet_socket { create read bind ioctl };
> >
> > Currently, with this rule in place and the app running in its own
> > domain, it can read data from any interface. If I am understanding
> > correclty, with a netif-based check enabled for packet_socket read, could
> > the application then be restricted to read from a specific eth interface
> > as opposed to being able read from any eth interface?
>
> The ingress/egress and secmark controls should work regardless of the
> socket
> type, so there _should_ be no problem with packet sockets.  Assuming you
> want to use the ingress/egress controls you would need to do the following:
>
>  1. Ensure you have the right policy loaded
>
>    For the examples shown here you will need to create two new types,
>    "foo_netif_t" and "foo_peer_t", as well as the policy rules to allow
>    them to work.  Stephen has already pointed you to some blog entries
>    explaining what you need to do, so we'll consider this step as an
>    exercise for the reader :)
>
>  2. Label the interface
>
>    You've already got this figured out for the most part, but for the
>    record, the following will assign type "foo_netif_t" to eth0 and
>    display the configured interface labels:
>
>    # semanage interface -a -t foo_netif_t eth0
>    # semanage interface -l
>
>  3. Configure a static network peer label (assumes unlabeled traffic)
>
>    If you aren't using a form of network peer labeling, e.g. labeled
>    IPsec or CIPSO, you'll need to enable some form of per-packet
>    peer labeling for the controls to take effect (otherwise the
>    packets are unlabeled and the controls just don't make sense).
>    In order to configure a static network peer label you need to ensure
>    that you have "netlabelctl" installed:
>
>    # yum install netlabel_tools
>
>    From here you should read the netlabelctl man page (lots of good
>    examples) and then come back to this email ... I'll wait .... okay,
>    now you can go ahead and configure a static peer label; the following
>    will assign the label "system_u:object_r:foo_peer_t:s0" to all
>    IPv4 traffic coming in on eth0:
>
>    # netlabelctl unlbl add interface:eth0 address:0.0.0.0/0 \
>      label:system_u:object_r:foo_peer_t:s0
>
> At this point everything should be up and running, if not let us know :)
>
> Good luck!
>
> --
> paul moore
> linux @ hp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/selinux/attachments/20100201/e179c1e8/attachment.html