From: "Christopher J. PeBenito" <cpebenito@tresys.com>
To: Daniel J Walsh <dwalsh@redhat.com>
Cc: James Morris <jmorris@redhat.com>,
Casey Schaufler <casey@schaufler-ca.com>,
gyurdiev@redhat.com, Joshua Brindle <jbrindle@tresys.com>,
Karl MacMillan <kmacmillan@tresys.com>,
selinux@tycho.nsa.gov
Subject: Re: Iptables discussion
Date: Mon, 25 Jul 2005 14:24:28 -0400 [thread overview]
Message-ID: <1122315868.13068.200.camel@sgc> (raw)
In-Reply-To: <42E50756.5030302@redhat.com>
On Mon, 2005-07-25 at 11:37 -0400, Daniel J Walsh wrote:
> With the current way that policy is written all devices get the
> netif_type by default. This type is then only used in the can_network
> macros.
>
> define(`base_can_network',`
> ...
> #
> # Allow the domain to send or receive using any network interface.
> # netif_type is a type attribute for all network interface types.
> #
> allow $1 netif_type:netif { $2_send rawip_send };
> allow $1 netif_type:netif { $2_recv rawip_recv };
> ...
>
>
> Since we would want to take this ability away from a specific device,
> we would need some kind of boolean or tunable to take away the
> netif_type for say the ethernet device.
I think the better way would be to change the way the policy works,
rather then conditionally applying the attribute. The default should
probably be to not have any netifcon statements except for interfaces we
want different behavior. The above macro would be changed to use
netif_t as the target, rather then netif_type. Then all interface types
still keep the netif_type attribute, so the privilege of using all
interfaces still exists, if needed, but since there are no netifcons,
all interfaces fall back to the initial sid type (netif_t). When the
user wants different behaviors for a specific interface, then the tool
would add the netifcon to the policy, and add the appropriate rules to
the policy.
To make this work better, then the can_network*() macros could be
modified to have an additional optional parameter to specify which
interface(s) to use. Then if the interface is supplied, the specified
interface type is used; otherwise, the generic interface (netif_t) is
used.
So you could have:
can_network(apache_t)
and then to change it to only use eth0,
can_network(apache_t,eth0_netif_t)
and label the external interface in net_contexts:
netifcon eth0 system_u:object_r:eth0_netif_t system_u:object_r:unlabeled_t
or perhaps the type could just be shortened to just eth0, and the type
name inferred. This would then just result in a one line policy change,
and a netifcon for each specified interface.
The reference policy does not have the can_network() style macros, but
rather specifies ports, nodes, and netifs interfaces separately, so this
would also be fairly simple. So the apache policy might start out with
this:
corenet_tcp_sendrecv_generic_if(apache_t)
to use generic (netif_t) interfaces, and to make it use the "external"
interfaces eth1 and eth2, we just change it to
corenet_tcp_sendrecv_external_if(apache_t)
and label the external interfaces by adding this in corenetwork:
network_interface(external, eth1,s0, eth2,s0)
(sensitivity would be dropped on non MLS policies)
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2005-07-25 18:27 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-21 17:40 [ libsepol 2/6] Ports Ivan Gyurdiev
2005-07-21 18:04 ` Joshua Brindle
2005-07-21 18:06 ` Ivan Gyurdiev
2005-07-21 18:27 ` Ivan Gyurdiev
2005-07-21 19:35 ` Karl MacMillan
2005-07-21 19:38 ` Ivan Gyurdiev
2005-07-21 20:30 ` Karl MacMillan
2005-07-21 20:47 ` Ivan Gyurdiev
2005-07-21 21:06 ` Joshua Brindle
2005-07-21 21:06 ` Ivan Gyurdiev
2005-07-21 21:15 ` Joshua Brindle
2005-07-21 21:25 ` Ivan Gyurdiev
2005-07-21 23:34 ` Joshua Brindle
2005-07-22 11:53 ` Iptables discussion Ivan Gyurdiev
2005-07-22 12:31 ` Daniel J Walsh
2005-07-22 12:46 ` Karl MacMillan
2005-07-22 13:44 ` Ivan Gyurdiev
2005-07-22 14:19 ` Karl MacMillan
2005-07-22 14:24 ` Ivan Gyurdiev
2005-07-22 15:28 ` Karl MacMillan
2005-07-22 18:18 ` Ivan Gyurdiev
2005-07-22 18:40 ` Karl MacMillan
2005-07-22 19:01 ` Ivan Gyurdiev
2005-07-22 14:42 ` Daniel J Walsh
2005-07-22 15:28 ` Karl MacMillan
2005-07-22 14:51 ` Joshua Brindle
2005-07-22 14:51 ` Joshua Brindle
2005-07-22 15:39 ` Ivan Gyurdiev
2005-07-22 15:57 ` Karl MacMillan
2005-07-22 16:14 ` Ivan Gyurdiev
2005-07-22 16:31 ` Karl MacMillan
2005-07-22 17:59 ` Ivan Gyurdiev
2005-07-22 16:28 ` Ivan Gyurdiev
2005-07-22 17:28 ` Jason Tang
2005-07-22 17:54 ` Ivan Gyurdiev
2005-07-22 18:28 ` Jason Tang
2005-07-22 18:32 ` Ivan Gyurdiev
2005-07-22 19:19 ` Joshua Brindle
2005-07-22 19:44 ` Ivan Gyurdiev
2005-07-22 19:56 ` Joshua Brindle
2005-07-22 20:18 ` Ivan Gyurdiev
2005-07-22 20:56 ` Ivan Gyurdiev
2005-07-22 15:46 ` Casey Schaufler
2005-07-22 15:54 ` Joshua Brindle
2005-07-22 16:11 ` Frank Mayer
2005-07-22 18:56 ` Casey Schaufler
2005-07-24 5:25 ` James Morris
2005-07-24 15:28 ` Casey Schaufler
2005-07-25 4:24 ` James Morris
2005-07-25 15:37 ` Daniel J Walsh
2005-07-25 18:24 ` Christopher J. PeBenito [this message]
2005-07-25 18:28 ` Ivan Gyurdiev
2005-07-25 18:43 ` Ivan Gyurdiev
2005-07-25 18:55 ` Daniel J Walsh
2005-07-25 19:01 ` Joshua Brindle
2005-07-25 19:53 ` Ivan Gyurdiev
2005-07-25 22:42 ` Joshua Brindle
2005-07-26 0:07 ` Ivan Gyurdiev
2005-07-26 0:13 ` Joshua Brindle
2005-07-22 12:37 ` Karl MacMillan
-- strict thread matches above, loose matches on Subject: below --
2005-07-22 14:54 Chad Hanson
2005-07-24 5:08 ` James Morris
2005-07-25 21:00 Chad Hanson
2005-07-25 21:04 Chad Hanson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1122315868.13068.200.camel@sgc \
--to=cpebenito@tresys.com \
--cc=casey@schaufler-ca.com \
--cc=dwalsh@redhat.com \
--cc=gyurdiev@redhat.com \
--cc=jbrindle@tresys.com \
--cc=jmorris@redhat.com \
--cc=kmacmillan@tresys.com \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.