All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Kyle Moffett <kyle@moffetthome.net>
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: Tue, 29 Sep 2009 16:54:07 -0400	[thread overview]
Message-ID: <200909291654.07458.paul.moore@hp.com> (raw)
In-Reply-To: <f73f7ab80909290654l25863d74n7b5919028cfde66d@mail.gmail.com>

On Tuesday 29 September 2009 09:54:56 am Kyle Moffett wrote:
> The problem is that there is no way to do catch-all rules *based* on
> the MLS label.  For example, if I have a TopSecret wire and I want to
> allow (for example) Unclass and TS//SI/TK traffic over it without
> risking mixing of data or exposure, there is no way for me to set it
> up without a lot of manual and duplicated configuration.  What I want
> to happen is:

Just a few questions so I'm clear on your problem.

>   (1) If any of 8 different SELinux domains of TS-level processes (IE:
> s4) try to communicate out the network interface, the policy is "none"

So any of the eight domains can send network traffic w/o IPsec as long as 
their MLS label is "s4" ...

>   (2) If those *same* SELinux domains with any of TS//SI/TK (s4:c1),
> TS//BYEMAN (s4:c2) try to communicate, the policy should be
> "esp/transport//require", using *different* certificates depending on
> the domain.

... and these same eight domains need to send network traffic using IPsec/ESP 
when their MLS label is "s4:c1" or "s4:c2" (do you really mean different 
certificates for each connection, which implies a new phase-1 IKE negotiation 
or did you simply mean new ESP SAs?)

>   (3) Again, if those *same* SELinux domains with U (IE: s1) try to
> communicate, the policy would be "ah/transport//require", (and yet
> more certificates).

... and if these same eight domains need to send network traffic using 
IPsec/AH when their MLS label is "s1" (once again, do you really mean SA 
instead of cert)?

> If it's possible to do this with the existing tools, that's great, but
> I played around with it for a good long while and was not able to work
> out a way to do so.

The different IPsec configurations per label is a little interesting, and not 
something that I've heard of people using (until just now).  I'd have to go 
spelunking in the code but I'm pretty sure you can't pick SPD rules based on 
security labels (you can authorize access to a rule using labels, but I don't 
believe the label acts as a selector).  I imagine you could get something 
working with manual SA creation but that is too ugly to spend much time 
thinking about it.

At this point I have to ask some workaround type questions - can you isolate 
the traffic using traditional IPsec traffic selectors instead of labels, e.g. 
protocol/port?  Is there any harm in applying both AH and ESP to all traffic 
that needs IPsec protection?  Do you need to convey the type information 
across the wire or is the MLS label sufficient?  Depending on your answers we 
may be able to arrive at a solution with the existing code.

-- 
paul moore
linux @ 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:[~2009-09-29 20:54 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 [this message]
2009-09-30  3:51                       ` Kyle Moffett
2009-09-30 13:19                         ` Paul Moore
2009-09-30 13:49                           ` Kyle Moffett
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=200909291654.07458.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=jbrindle@tresys.com \
    --cc=kyle@moffetthome.net \
    --cc=michal.svoboda@agents.felk.cvut.cz \
    --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.