All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Venkat Yekkirala <vyekkirala@TrustedCS.com>
Cc: jmorris@namei.org, netdev@vger.kernel.org, selinux@tycho.nsa.gov,
	davem@davemloft.net, sds@tycho.nsa.gov, eparis@redhat.com
Subject: Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in  MLS environments)
Date: Mon, 26 Jun 2006 21:53:47 -0400	[thread overview]
Message-ID: <200606262153.48251.paul.moore@hp.com> (raw)
In-Reply-To: <44A0684D.9080904@trustedcs.com>

On Monday 26 June 2006 7:05 pm, Venkat Yekkirala wrote:
> USER REQUIREMENTS:
>
> The broad user requirements for labeled networking would be that of
> information labeling and flow control. Specifically,
>
> 1. Data labeling:
> 	a. data must be labeled where it originates.
> 	b. data must retain that label (or its interpretation in a given domain)
> 	   when conveyed in a trustworthy manner.

{snip}

> PROPOSED DESIGN:
>
> Given the above requirements the following design is proposed:
>
> On the outbound (OTBND):
>
> The following applies to locally-generated (OUTPUT) as well as forwarded
> (FORWARD) traffic.
>
> 1.	OUTPUT ONLY:
> 	a. Set secmark of the packet to the label of the socket unless its a
> 	   datagram, the process is privileged and is allowed to specify
> 	   a different label for the datagram per policy (R1a, R3a, R3c).
>
> 	b. If there's no real socket to take the label from, and this packet is
> 	   in response to a received packet, use the level from the received
> 	   packet, taking the TE portion of the context from the pseudo-socket
> 	   on whose behalf the packet is being sent.
>

Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take 
the label of the process/domain which sends the data to the socket?  After 
all, the process/domain is the "origin" of the data.  This seems to be 
particularly important in the case of fork()-then-exec() where you could have 
a socket created at a different context from the domain currently writing to 
it.

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

WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul.moore@hp.com>
To: Venkat Yekkirala <vyekkirala@trustedcs.com>
Cc: jmorris@namei.org, netdev@vger.kernel.org, selinux@tycho.nsa.gov,
	davem@davemloft.net, sds@tycho.nsa.gov, eparis@redhat.com
Subject: Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in  MLS environments)
Date: Mon, 26 Jun 2006 21:53:47 -0400	[thread overview]
Message-ID: <200606262153.48251.paul.moore@hp.com> (raw)
In-Reply-To: <44A0684D.9080904@trustedcs.com>

On Monday 26 June 2006 7:05 pm, Venkat Yekkirala wrote:
> USER REQUIREMENTS:
>
> The broad user requirements for labeled networking would be that of
> information labeling and flow control. Specifically,
>
> 1. Data labeling:
> 	a. data must be labeled where it originates.
> 	b. data must retain that label (or its interpretation in a given domain)
> 	   when conveyed in a trustworthy manner.

{snip}

> PROPOSED DESIGN:
>
> Given the above requirements the following design is proposed:
>
> On the outbound (OTBND):
>
> The following applies to locally-generated (OUTPUT) as well as forwarded
> (FORWARD) traffic.
>
> 1.	OUTPUT ONLY:
> 	a. Set secmark of the packet to the label of the socket unless its a
> 	   datagram, the process is privileged and is allowed to specify
> 	   a different label for the datagram per policy (R1a, R3a, R3c).
>
> 	b. If there's no real socket to take the label from, and this packet is
> 	   in response to a received packet, use the level from the received
> 	   packet, taking the TE portion of the context from the pseudo-socket
> 	   on whose behalf the packet is being sent.
>

Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take 
the label of the process/domain which sends the data to the socket?  After 
all, the process/domain is the "origin" of the data.  This seems to be 
particularly important in the case of fork()-then-exec() where you could have 
a socket created at a different context from the domain currently writing to 
it.

-- 
paul moore
linux security @ hp

  parent reply	other threads:[~2006-06-27  1:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-26 23:05 Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments) Venkat Yekkirala
2006-06-26 23:05 ` Venkat Yekkirala
2006-06-27  0:29 ` James Morris
2006-06-27  0:29   ` James Morris
2006-06-27  1:53 ` Paul Moore [this message]
2006-06-27  1:53   ` Paul Moore
2006-06-27 15:45 ` Venkat Yekkirala
2006-06-27 15:45   ` Venkat Yekkirala
2006-06-27 15:47   ` Venkat Yekkirala
2006-06-27 15:47     ` Venkat Yekkirala

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=200606262153.48251.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=davem@davemloft.net \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=netdev@vger.kernel.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.