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.
next prev parent 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.