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@xxxxxxxxxxxxx> wrote:
On Sun, 2010-01-17 at 21:21 -0700, Jason Shaw wrote:(extended cc line to include fedora and upstream selinux lists).
> 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)?
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@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
