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@xxxxxx> wrote:
On Tuesday 19 January 2010 01:07:53 pm Jason Shaw wrote:The ingress/egress and secmark controls should work regardless of the socket
> 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?
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
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
