All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: James Morris <jmorris@namei.org>
Cc: selinux@tycho.nsa.gov, sds@tycho.nsa.gov, cpebenito@tresys.com,
	vyekkirala@trustedcs.com
Subject: Re: Q: SECMARK controls on forwarded packets
Date: Wed, 9 Jan 2008 15:48:10 -0500	[thread overview]
Message-ID: <200801091548.10359.paul.moore@hp.com> (raw)
In-Reply-To: <Xine.LNX.4.64.0801100100590.9291@us.intercode.com.au>

On Wednesday 09 January 2008 9:04:43 am James Morris wrote:
> It'd be interesting to see what some fully worked network policy
> would look like ...

Everything below is based on the patches found here (the very observant 
will notice slight differences in permission ordering from previous 
mailing list patch postings):

 * http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing

The following is an example of what permissions are needed for the 
various send/receive/forward network tasks using the "new and improved" 
network controls.  In addition, while policy is not ordered, I've 
ordered the allow rules in the order in which the kernel performs the 
access checks.  I've also left out the labeled IPsec SA polmatch checks 
since those are unchanged and add some noise to the rules below.

If anyone has any comments/problems/objections please speak up quickly 
so we can get everything straightened out as soon as possible.

 - basic subj/obj definitions

   socket_t  = socket's label
   peer_t    = peer label as determined by NetLabel and/or labeled IPsec
   secmark_t = secmark/iptables label
   netif_t   = network interface label
   node_t    = network address label

 - inbound locally consumed traffic permissions

   # is TOP_SECRET traffic allowed on this network?
   allow peer_t netif_t:netif ingress;
   allow peer_t node_t:node recvfrom;
   # is apache allowed to receive traffic from firefox?
   allow socket_t peer_t:peer recv;
   # is apache allowed to receive web traffic?
   allow socket_t secmark_t:packet recv;

 - outbound locally generated traffic permissions
   
   # is apache allowed to send web traffic?
   allow socket_t secmark_t:packet send;
   # is TOP_SECRET traffic allowed on this network?
   allow socket_t netif_t:netif egress;
   allow socket_t node_t:node sendto;

 - inbound forwaded traffic permissions

   # is TOP_SECRET traffic allowed on this network?   
   allow peer_t netif_t:netif ingress;
   allow peer_t node_t:node recvfrom;
   # is apache allowed to forward web traffic through this system?
   allow peer_t secmark_t:packet forward_in;

 - outbound forwarded traffic permissions

   # is apache allowed to forward web traffic through this system?
   allow peer_t secmark_t:packet forward_out;
   # is TOP_SECRET traffic allowed on this network?
   allow peer_t netif_t:netif egress;
   allow peer_t node_t:node sendto;

-- 
paul moore
linux security @ hp

--
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.

  reply	other threads:[~2008-01-09 20:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09  4:30 Q: SECMARK controls on forwarded packets Paul Moore
2008-01-09 12:51 ` Stephen Smalley
2008-01-09 13:30   ` Paul Moore
2008-01-09 13:39     ` Stephen Smalley
2008-01-09 15:36       ` Paul Moore
2008-01-09 14:04 ` James Morris
2008-01-09 20:48   ` Paul Moore [this message]
2008-01-09 23:35     ` Paul Moore
2008-01-10 15:32     ` Chad Hanson
2008-01-10 16:47       ` Paul Moore
2008-01-10 18:56         ` Joshua Brindle
2008-01-10 19:10           ` Paul Moore
2008-01-10 20:04             ` Joshua Brindle
2008-01-10 20:07               ` Paul Moore

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=200801091548.10359.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=cpebenito@tresys.com \
    --cc=jmorris@namei.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=vyekkirala@trustedcs.com \
    /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.