All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kyle Moffett <kyle@moffetthome.net>
To: Paul Moore <paul.moore@hp.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	russell@coker.com.au,
	Michal Svoboda <michal.svoboda@agents.felk.cvut.cz>,
	selinux@tycho.nsa.gov, Joshua Brindle <jbrindle@tresys.com>
Subject: Re: MCS and default labels
Date: Wed, 30 Sep 2009 09:49:51 -0400	[thread overview]
Message-ID: <f73f7ab80909300649n785436b6nb15dc62d13713b2@mail.gmail.com> (raw)
In-Reply-To: <200909300919.35275.paul.moore@hp.com>

On Wed, Sep 30, 2009 at 09:19, Paul Moore <paul.moore@hp.com> wrote:
> On Tuesday 29 September 2009 11:51:42 pm Kyle Moffett wrote:
>>  (C)  Processes which are *not* s4 may communicate over the network
>> only when protected by IPsec, and only if the IPsec connection is
>> specifically negotiated using certificates/keys based on the level of
>> the data being protected.
>
> I think the tricky part here is the "... certificates/keys based on the level
> of the data ..." statement.  Is is sufficient to have one certificate per
> host/node as long as you have one SA per label?

Unfortunately not.  Imagine that the device is some kind of network
appliance, router, etc.  You would not want to reconfigure your
storage server or router every time you add a new node.  Beyond that,
different data levels probably have different protection requirements.
 For instance, say you have a physical network that is safe to
transport "personal data" unprotected, but not  "trade secrets" (IE:
the network itself is s0:c1):

  * When you send data between "s0" processes across the network, you
would want to save CPU and enable better network debugging by just
using AH (the data doesn't need protection against exposure, just
against contamination).

  * When you send data between "trade secrets" (s0:c2) processes
across the network, that *does* need protection, and so you would use
ESP.

For a lot of government classified-data systems, there's a lot more
levels than that, and some levels require different key-lengths or
algorithms.  I'm afraid that for the purposes I am interested in, a
separate root-CA per MLS level is really the only practical
configuration.

Given that, I guess the question is, how hard would it be to modify
racoon and/or the kernel to give me the behavior I want?

Cheers,
Kyle Moffett


--
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:[~2009-09-30 13:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08  5:58 MCS and default labels Michal Svoboda
2009-09-08 15:35 ` Stephen Smalley
2009-09-08 16:36   ` Michal Svoboda
2009-09-08 17:10     ` Stephen Smalley
2009-09-09 10:06       ` Michal Svoboda
2009-09-09 12:17         ` Stephen Smalley
2009-09-09 13:19           ` Michal Svoboda
2009-09-09 13:34             ` Stephen Smalley
2009-09-09 13:59               ` Michal Svoboda
2009-09-09 14:34                 ` Stephen Smalley
2009-09-14  8:19           ` Michal Svoboda
2009-09-14 12:20             ` Stephen Smalley
2009-09-14 13:00               ` Stephen Smalley
2009-09-15  6:32               ` Michal Svoboda
2009-09-15 11:16                 ` Stephen Smalley
2009-09-27  7:34           ` Russell Coker
2009-09-28 13:37             ` Stephen Smalley
2009-09-28 20:57               ` Russell Coker
2009-09-28 23:22               ` Kyle Moffett
2009-09-29 12:21                 ` Stephen Smalley
2009-09-29 13:54                   ` Kyle Moffett
2009-09-29 20:54                     ` Paul Moore
2009-09-30  3:51                       ` Kyle Moffett
2009-09-30 13:19                         ` Paul Moore
2009-09-30 13:49                           ` Kyle Moffett [this message]
2009-09-30 14:20                             ` 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=f73f7ab80909300649n785436b6nb15dc62d13713b2@mail.gmail.com \
    --to=kyle@moffetthome.net \
    --cc=jbrindle@tresys.com \
    --cc=michal.svoboda@agents.felk.cvut.cz \
    --cc=paul.moore@hp.com \
    --cc=russell@coker.com.au \
    --cc=sds@tycho.nsa.gov \
    --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.