[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-selinux-list
Subject: Re: Assigning a Type to Network Interfaces
From: Jason Shaw <js44352 () gmail ! com>
Date: 2010-02-01 17:44:56
Message-ID: c63e41181002010944v23df202ft127bcc4e3eeaa172 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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
>
[Attachment #5 (text/html)]
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>allow myApp_t self:packet_socket { create read bind ioctl };</div>
<div> </div>
<div>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?</div> <div> </div>
<div class="gmail_quote">On Tue, Jan 19, 2010 at 3:54 PM, Paul Moore <span \
dir="ltr"><<a href="mailto:paul.moore@hp.com">paul.moore@hp.com</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px \
0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div class="im">On Tuesday 19 January 2010 \
01:07:53 pm Jason Shaw wrote:<br>> Can netif checks be enabled for \
'packet_socket read'? If so, how?<br>><br>> My app requires this allow \
rule:<br>> allow myApp_t self:packet_socket { create read bind ioctl };<br> \
><br>> Currently, with this rule in place and the app running in its \
own<br>> domain, it can read data from any interface. If I am \
understanding<br>> correclty, with a netif-based check enabled for packet_socket \
read, could<br> > the application then be restricted to read from a specific eth \
interface<br>> as opposed to being able read from any eth \
interface?<br><br></div>The ingress/egress and secmark controls should work \
regardless of the socket<br> type, so there _should_ be no problem with packet \
sockets. Assuming you<br>want to use the ingress/egress controls you would need to \
do the following:<br><br> 1. Ensure you have the right policy loaded<br><br> For \
the examples shown here you will need to create two new types,<br> \
"foo_netif_t" and "foo_peer_t", as well as the policy rules to \
allow<br> them to work. Stephen has already pointed you to some blog entries<br> \
explaining what you need to do, so we'll consider this step as an<br> exercise \
for the reader :)<br><br> 2. Label the interface<br><br> You've already got \
this figured out for the most part, but for the<br> record, the following will \
assign type "foo_netif_t" to eth0 and<br> display the configured interface \
labels:<br><br> # semanage interface -a -t foo_netif_t eth0<br> # semanage \
interface -l<br><br> 3. Configure a static network peer label (assumes unlabeled \
traffic)<br><br> If you aren't using a form of network peer labeling, e.g. \
labeled<br> IPsec or CIPSO, you'll need to enable some form of per-packet<br> \
peer labeling for the controls to take effect (otherwise the<br> packets are \
unlabeled and the controls just don't make sense).<br> In order to configure a \
static network peer label you need to ensure<br> that you have \
"netlabelctl" installed:<br><br> # yum install netlabel_tools<br><br> \
From here you should read the netlabelctl man page (lots of good<br> examples) and \
then come back to this email ... I'll wait .... okay,<br> now you can go ahead \
and configure a static peer label; the following<br> will assign the label \
"system_u:object_r:foo_peer_t:s0" to all<br> IPv4 traffic coming in on \
eth0:<br><br> # netlabelctl unlbl add interface:eth0 address:<a \
href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> \<br> \
label:system_u:object_r:foo_peer_t:s0<br><br>At this point everything should be up \
and running, if not let us know :)<br><br>Good luck!<br><font \
color="#888888"><br>--<br>paul moore<br>linux @ hp<br></font></blockquote> </div><br>
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic