selinux January 2010 archive
Main Archive Page > Month Archives  > selinux archives
selinux: Re: Assigning a Type to Network Interfaces

Re: Assigning a Type to Network Interfaces

From: Jason Shaw <js44352_at_nospam>
Date: Tue Jan 19 2010 - 18:07:53 GMT
To: Stephen Smalley <sds@tycho.nsa.gov>


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?

Thank you.

On Tue, Jan 19, 2010 at 7:20 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Sun, 2010-01-17 at 21:21 -0700, Jason Shaw wrote:
> > Just wanted to follow-up to see if I am misunderstanding the purpose
> > of semanage -interface. Once a type is assigned to an interface such
> > as eth0, should an application running in its own domain be able to
> > bind to the interface without an allow rule (using net_raw, tcp, or
> > udp)?
>
> (extended cc line to include fedora and upstream selinux lists).
>
> There are no netif-based checks during bind(2). There can be
> netif-based checks during packet send/recv, but the legacy checks were
> obsoleted and removed as I noted, and the newer checks require
> additional configuration (iptables for SECMARK, netlabel or ipsec for
> labeled networking).
>
> > On Thu, Jan 14, 2010 at 7:37 AM, Stephen Smalley <sds@tycho.nsa.gov>
> > wrote:
> >
> > On Thu, 2010-01-14 at 07:08 -0700, Jason Shaw wrote:
> > > I need help understanding if SELinux supports restricting a
> > confined
> > > application from binding to specific network interfaces. I
> > cannot seem
> > > to make this work under F11 and F12 (using targeted, mls,
> > and
> > > reference policies), or under RHEL 5.3U3 targeted.
> > >
> > > Details:
> > > - I have a system with two network interfaces: eth0 and
> > eth1.
> > > - I have an application that must only be allowed to read
> > data from
> > > eth0 (raw and tcp).
> > > - I do not need to label packets.
> > >
> > > Here's what I have tried
> > > 1) In a new policy module, I create new types: myApp_exec_t,
> > myApp_t,
> > > myApp_eth0_t, myApp_eth1_t.
> > > 2) I use semanage -fcontext to label my application's
> > executable file
> > > as myApp_exec_t
> > > 3) I assign eth0 with a new type: 'semanage interface -a -t
> > > myApp_eth0_t eth0'
> > > 4) I assign eth1 with a new type: 'semanage interface -a -t
> > > myApp_eth1_t eth1'
> > > 5) In my policy module, I allow the following: "allow
> > myApp_t
> > > self:capability net raw", and "allow myApp_t self:tcp_socket
> > { accept
> > > read }"
> > > 6) I verify that when I execute my application, using ps
> > -efZ it is
> > > running in the myApp_t domain (has transitioned properly
> > from
> > > unconfined_t)
> > >
> > > The problem is, my app can read raw or tcp data from either
> > eth0 or
> > > eth1 even though both interfaces have been assigned
> > different types
> > > using semanage -interface.
> > >
> > > Is this because 'allow myApp_t self:capability net_raw' does
> > not
> > > distinguish between network interfaces? Is my understanding
> > of
> > > semanage -interface incorrect - shouldn't labeling the
> > interface
> > > result in no ability to use the interface unless explicitly
> > allowed?
> >
> >
> > The legacy network permission checks were removed in Linux
> > 2.6.30, and
> > even prior to that they had been disabled for a long time by
> > default
> > unless you set /selinux/compat_net to 1. These days you need
> > to use
> > secmark or the newer ingress/egress permission checks to
> > achieve the
> > same effect. Using secmark requires you to configure
> > iptables SECMARK
> > targets to label the packets. Using ingress/egress requires
> > you to
> > configure labeled networking (netlabel or labeled ipsec) and
> > make sure
> > that /selinux/policy_capabilities/network_peer_controls exists
> > and is
> > set to 1 (requires Linux >= 2.6.25 and a policy built with
> > that
> > capability). See:
> > http://paulmoore.livejournal.com/4281.html
> > http://paulmoore.livejournal.com/2128.html
> >
> > --
> > Stephen Smalley
> > National Security Agency
> >
> >
> --
> Stephen Smalley
> National Security Agency
>
>

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux