RE: [RFC 0/5] Static/fallback external labels for NetLabel

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> > Good. Are you using the upstream or the LSPP kernel? I vaguely
> > remember James asking for stuff to be tested on the LSPP kernel
> > before being ported and presented upstream, but I am now not sure
> > if that applied only to development under the LSPP umbrella.
> > I will be OK either way. I presume Eric would love to see it be the
> > LSPP kernel.
> 
> I'm pretty sure it is the other way around - patches get submitted to
> mainline, vetted there, and then if accepted, back ported to distro
> kernels.

OK, thanks. This would be proper and distro-neutral.

Paul, is davem's net-2.6.24 git cool with you or would you
prefer the stable 2.6.22.5? Or would James' selinu-2.6 git
be proper?

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Wednesday, August 29 2007 12:15:31 pm Venkat Yekkirala wrote:
> > > Good. Are you using the upstream or the LSPP kernel? I vaguely
> > > remember James asking for stuff to be tested on the LSPP kernel
> > > before being ported and presented upstream, but I am now not sure
> > > if that applied only to development under the LSPP umbrella.
> > > I will be OK either way. I presume Eric would love to see it be the
> > > LSPP kernel.
> >
> > I'm pretty sure it is the other way around - patches get submitted to
> > mainline, vetted there, and then if accepted, back ported to distro
> > kernels.
>
> OK, thanks. This would be proper and distro-neutral.
>
> Paul, is davem's net-2.6.24 git cool with you or would you
> prefer the stable 2.6.22.5? Or would James' selinu-2.6 git
> be proper?

For right now go ahead and back against Linus' linux-2.6 tree and I'll deal 
with any merge issues once I get a git tree going.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> Please keep sending RFCs/patches to the SELinux list while we 
> sort out all of 
> the implementation details and I'll see about setting up a 
> git tree where we 
> can do all of the bigger/intrusive changes.  This should make 
> it easier for 
> us to work together and people who are interesting in testing the new 
> features will have a working tree to pull from.  Once things 
> are looking good 
> I'll work to get all of the contributed patches upstream.

Good. Are you using the upstream or the LSPP kernel? I vaguely
remember James asking for stuff to be tested on the LSPP kernel
before being ported and presented upstream, but I am now not sure
if that applied only to development under the LSPP umbrella.
I will be OK either way. I presume Eric would love to see it be the
LSPP kernel.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Wed, 2007-08-29 at 11:29 -0400, Venkat Yekkirala wrote:
> > Please keep sending RFCs/patches to the SELinux list while we 
> > sort out all of 
> > the implementation details and I'll see about setting up a 
> > git tree where we 
> > can do all of the bigger/intrusive changes.  This should make 
> > it easier for 
> > us to work together and people who are interesting in testing the new 
> > features will have a working tree to pull from.  Once things 
> > are looking good 
> > I'll work to get all of the contributed patches upstream.
> 
> Good. Are you using the upstream or the LSPP kernel? I vaguely
> remember James asking for stuff to be tested on the LSPP kernel
> before being ported and presented upstream, but I am now not sure
> if that applied only to development under the LSPP umbrella.
> I will be OK either way. I presume Eric would love to see it be the
> LSPP kernel.

I'm pretty sure it is the other way around - patches get submitted to
mainline, vetted there, and then if accepted, back ported to distro
kernels.

-- 
Stephen Smalley
National Security Agency


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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

Very well said. This should make for a nice chapter/section in SELinux by
Example.

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
> Sent: Wednesday, August 29, 2007 9:56 AM
> To: Joshua Brindle
> Cc: Joe Nall; Darrel Goeddel; Venkat Yekkirala; selinux@tycho.nsa.gov;
> James Morris; Darrel Goeddel; Stephen Smalley; kaigai@ak.jp.nec.com;
> Eric Paris
> Subject: Re: [RFC 0/5] Static/fallback external labels for NetLabel
> 
> 
> On Wednesday, August 29 2007 10:26:55 am Joshua Brindle wrote:
> > Paul Moore wrote:
> > > On Wednesday, August 29 2007 12:11:14 am Joshua Brindle wrote:
> > >> Because of
> > >> what I said above I think we should 1) not do node based 
> fallbacks and
> > >> 2) not do nic alias-level fallbacks. This is the safe 
> option (as already
> > >> pointed out) and minimizes trust in untrustworthy things 
> (eg., addresses
> > >> coming from the network).
> > >>
> > >> OTOH it may make some peoples lives easier to allow 
> this. It is a false
> > >> sense of security though so I vote for doing nic level 
> fallbacks only
> > >> and if someone *really* wants to do this they can just 
> plug several nics
> > >> into the same network (hopefully they'd recognize the 
> horrible things
> > >> they are doing if it is explicit like that).
> > >>
> > >> It sounds like the decision is still up in the air 
> though, does anyone
> > >> inherently disagree with me here?
> > >
> > > I guess every decision is technically up in the air until the
> > > changes/patches are included in a released kernel, 
> however, I'm pretty
> > > confident that host level granularity of both fallback 
> labels and flow
> > > control peer label filtering is "the right thing".
> > >
> > > I understand your point about not extending trust beyond 
> the level of the
> > > physical wire, that is very easy to 
> rationalize/understand.  However,
> > > from a practical real-world scenario (see my home network 
> behind a NAT
> > > box example, as well as others) I think there is real 
> value in extending
> > > the labeling beyond the wire to the host/network level.  
> SELinux has
> > > always made some allowances to facilitate adoption and 
> ease of use, i.e.
> > > unconfined_t, but has been careful to make sure that 
> these concessions
> > > were always at the discretion of the system 
> administrator.  Fallback
> > > labeling and peer flow controls are configuration options 
> which are only
> > > available to the system administrator and providing host level
> > > granularity can be a significant benefit to a lot of people.
> >
> > concessions are fine when the ramifications are understood, 
> unconfined_t
> > is pretty obvious.
> 
> I tend to think host level fallback labels are pretty obvious 
> too, at least as 
> obvious as unconfined_t if not more so.  The only way to 
> truly understand the 
> ramifications of unconfined_t are to actually look at the 
> policy and examine 
> all of the interactions between unconfined_t and all of the 
> types/attributes 
> defined in policy.  Short circuiting this by making an 
> assumption based on 
> the connotative meaning of the name "unconfined" is just as 
> dangerous, if not 
> more so in my opinion, then host level fallbacks.  Explaining the 
> ramifications of host level fallback labels are pretty 
> simple, here is my 
> quick take:
> 
>  "Choosing to enable multiple fallback labels per interface, i.e.
>   network or host level fallbacks, can be dangerous as it is possible
>   for malicious computers to masquerade as other computers with a
>   different fallback label.  Only use network or host level fallback
>   labels when you can guarantee the security of the network."
> 
> > But when there are security people that believe host 
> > based labeling buys anything then it may be an 
> inappropriate concession.
> 
> I think the key difference between the two sides here is the 
> acceptable level 
> or risk, or the level of assurance.  From what I gather, Joe 
> and the TCS guys 
> are deploying systems in installations where they are able to 
> put a fair 
> amount of trust in the network such that host level fallback 
> labels do not 
> introduce an unacceptable amount of risk.  Your argument 
> assumes a network 
> with no trust where host level fallback labels present a very 
> unacceptable 
> risk.
> 
> Both arguments are correct, the question is what level of 
> functionality do we 
> want to provide?
> 
> > I mean, if I can get on your network and in a matter of seconds take
> > over both your IP and MAC address it isn't good. Worse, I could use
> > something like ettercap and MiM you without you even 
> knowing (and even
> > inject data into the stream).
> 
> Yep, I think we're all familiar with ARP cache poisoning and 
> all the other 
> wonderful things you can do the network.
> 
> > The last email from Joe shows that even security centric 
> people are fine
> > with this situation in a 'medium assurance' environment, if medium
> > assurance means trivially bypassable please count me out. A single 
> > shared network is in no way medium assurance IMO, there is 
> no inherent
> > security when you are on a single network (save for fancy 
> switches that
> > do mac filtering and ip locking per port, how many people 
> actually use
> > those features though).
> 
> I'm making this argument up a bit as I go, so bear with me ...
> 
> You essentially define a network by the machines connected to 
> it, which means 
> that if you can control the machines on that network then you 
> effectively 
> control the network.  Joe is arguing the case for 
> installations where he does 
> control all of the machines on the network.
> 
> > One interesting thing that just occurred to me is vlans. 
> I'm not sure
> > how vlans are implemented on Linux (do they get their own interface
> > names?) but they are much better than the alternative which 
> lets anyone
> > do anything on a single network.
> 
> Like everything else I think this depends on the 
> configuration.  If you have 
> multiple vlans on a single wire and unknown machines on that 
> wire than vlan 
> separation is no different from IP address separation.
> 
> -- 
> 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.

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> I am assuming that the *_socket checks used by netlabel would be 
> checking against the new peer label that is in (at least 
> near) the skb, 
> is that right?  If so, the *_socket checks also take care of the peer 
> label coming from loopback.  This would be a bit of a policy change 

I doubt it since NetLabel currently already uses the xfrm label,
if available, as the base sid.

> since the *_socket checks now apply to domains (not just the 
> base type 
> from the initial sid) since the loopback traffic goes through 
> the same 
> checks.  I at least hope we don't add another, separate, 
> check for the 
> loopback case...
> 
> That was just one idea, but I definitely think the 
> unification should be 
> a goal of this exercise.
> 
> -- 
> 
> Darrel
> 

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Tuesday, August 28 2007 2:02:02 pm Venkat Yekkirala wrote:
> > I am assuming that the *_socket checks used by netlabel would be
> > checking against the new peer label that is in (at least
> > near) the skb,
> > is that right?  If so, the *_socket checks also take care of the peer
> > label coming from loopback.  This would be a bit of a policy change
>
> I doubt it since NetLabel currently already uses the xfrm label,
> if available, as the base sid.

I think that will change to the following (I'm currently working on patches 
for this), pseudo code below:

int get_peer_sid(skb, *sid)
{
	xfrm_sid = get_xfrm_sid(skb);
	nlbl_sid = get_nlbl_sid(skb);

	if (nlbl_sid != SECSID_NULL && xfrm_sid != SECSID_NULL) {
		if (type_nlbl_sid(skb) == FALLBACK) {
			*sid = xfrm_sid;
			return 0;
		} else if (compare_sid_mls(nlbl_sid, xfrm_sid) == 0) {
			*sid = xfrm_sid;
			return 0;
		} else
			return -1;
	} else if (nlbl_sid != SECSID_NULL) {
		*sid = nlbl_sid;
		return 0;
	} else if (xfrm_sid != SECSID_NULL) {
		*sid = xfrm_sid;
		return 0;
	}

	*sid = SECSID_NULL;
	return 0;
}

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
> Sent: Tuesday, August 28, 2007 9:52 AM
> To: Venkat Yekkirala
> Cc: selinux@tycho.nsa.gov; James Morris; Darrel Goeddel; Stephen
> Smalley; kaigai@ak.jp.nec.com; joe@nall.com; Eric Paris
> Subject: Re: [RFC 0/5] Static/fallback external labels for NetLabel
> 
> 
> On Monday, August 27 2007 6:09:12 pm Venkat Yekkirala wrote:
> > [Darrel has made me aware I am breaking threads; will fix this
> > in a day or two]
> 
> I'm really curious at this point, someday you guys are going 
> to have to 
> explain how your email system works ;)
> 
> > > -----Original Message-----
> > > From: Paul Moore [mailto:paul.moore@hp.com]
> >
> > (snip)
> >
> > > > Also, in the forwarding case, while the original 
> xfrm-label should
> > > > still be around in the labeled-IPSec to 
> non-labeled-IPSec case, I
> > > > would imagine in the NetLabel case, the option field 
> would lose the
> > > > "original" label in a DOI gateway instance (if and when 
> NateLabel
> > > > does this), right?
> > >
> > > Yes, once you change the packet's label on the wire you have
> > > to potential to
> > > change the packet's label.  However, simply changing the
> > > label to reflect a
> > > different CIPSO DOI (I assume that is the DOI you were
> > > talking about?)
> >
> > Yes.
> >
> > > shouldn't change the NetLabel/CIPSO label as seen by SELinux
> > > since the only
> > > thing the on-the-wire label translation would be doing is
> > > translating the
> > > label between two different security domains/DOIs, the
> > > semantic value of the
> > > label should be preserved.
> > >
> > > I would consider removing the NetLabel/CIPSO label from a
> > > packet to be the
> > > same as relabeling a packet to unlabeled_t and I still
> > > believe that the
> > > kernel should not get involved in packet relabeling at this
> > > point, leave that
> > > up to userspace.
> >
> > Traditionally anyway, the original label has been used all the
> > way thru for flow-control, etc., since that's the original label
> > of the packet. I believe the packet losing the label is just
> > a recognition of the fact that the packet can't explicitly
> > carry the label onto the other network, but the label is
> > implicit from what I understand.
> 
> Okay, I understand your point now; I still don't think this 
> is too much of a 
> problem.  As you pointed out below we are most likely going 
> to need a final 
> catch-all flow control hook for the default, no-config case 
> (more on this 
> below) and this appears to be an excellent place to make the final 
> on-the-wire labeling decision for forwarded packets that make use of 
> CIPSOesque labeling protocols.  There is also the 
> ip_build_options() hook 
> which I keep talking about, but it may happen to early in the 
> forwarding 
> patch to be useful, I would have to check the stack.  
> Regardless, I'm pretty 
> confident that whatever hooks we put in place to control 
> packet flow should 
> be sufficient to handle the on-the-wire labeling we want/need 
> so lets move on 
> to defining those hooks and see where that leaves us.

As for xfrm, the patch we have already does this. I will send a version
out once we make a final decision on the filtering aspect. Major pieces
missing will be loopback labeling, fallback, OTW labeling for NetLabel
as you talked about earlier, compatibility coding etc. You can perhaps
take by patch and add these to it?

(snip)
> > > As far as I can tell there is still one important issue we
> > > need to resolve -
> > > how to introduce new packet access checks without causing a
> > > regression for
> > > users with older policy.  This of course is tied to the
> > > desire to have a
> > > default/unlabeled_t packet access check in the case where the
> > > admin has not
> > > explicitly setup any SECFILTER points/gates/etc.  Can we live
> > > without a
> > > default check?
> >
> > I highly doubt it. We have erred on the side of caution on this
> > in our patch since we didn't want any inadvertent flows between
> > Secret and TS networks for example. This also obviously retains
> > the SELinux philosophy of no allows by default.
> 
> I noticed there was no comment about how to avoid 
> compatibility issues :)
> 
> I agree that having a default, flow control "catch 
> all"/unlabeled_t check is a 
> good idea and preserved the SELinux philosophy but doing so 
> without breaking 
> the flow of packets in/out/through a system with old policy 
> is not an easy 
> task.  At some point in the future, if we want to reconcile 
> all of the peer 
> label access checks to a single object class, we'll probably 
> need to do 
> something similar to the compat_net (compat_net_peer?) flag.  

We could actually do this as part of this, correct (unless I
missed any one's objections elsewhere).

> If we want to 
> get the flow control functionality in sooner we'll need 
> something more 
> elegant.

Could you please elaborate on this.

> 
> <mental note>
> We should probably look at putting the old compat_net bits in 
> the feature 
> removal queue if they aren't already ...
> </mental note>

I wonder what the current standard is for removing deprecated
code. Is there a certain number of versions we need to wait or
does it vary based on what's been deprecated?

(snip)

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Venkat Yekkirala wrote:
>> -----Original Message-----
>> From: Paul Moore [mailto:paul.moore@hp.com]
 >>
>> I agree that having a default, flow control "catch 
>> all"/unlabeled_t check is a 
>> good idea and preserved the SELinux philosophy but doing so 
>> without breaking 
>> the flow of packets in/out/through a system with old policy 
>> is not an easy 
>> task.  At some point in the future, if we want to reconcile 
>> all of the peer 
>> label access checks to a single object class, we'll probably 
>> need to do 
>> something similar to the compat_net (compat_net_peer?) flag.  
> 
> We could actually do this as part of this, correct (unless I
> missed any one's objections elsewhere).

I agree  - bring it on.  We're unifying the on-the-wire labeling 
mechanism by making sure that they agree if more than one is use.  That 
is a good start.  I'd really like to continue on here and get the 
unified access check so we don't have to do netlabel style and labeled 
ipsec style peer access checks.  The target context for both the 
association checks and the *_socket (netlabel) checks will be the same. 
  Why not just drop the association checks since the *idea* is now 
covered in the *_socket checks?

I am assuming that the *_socket checks used by netlabel would be 
checking against the new peer label that is in (at least near) the skb, 
is that right?  If so, the *_socket checks also take care of the peer 
label coming from loopback.  This would be a bit of a policy change 
since the *_socket checks now apply to domains (not just the base type 
from the initial sid) since the loopback traffic goes through the same 
checks.  I at least hope we don't add another, separate, check for the 
loopback case...

That was just one idea, but I definitely think the unification should be 
a goal of this exercise.

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Tuesday, August 28 2007 1:39:05 pm Darrel Goeddel wrote:
> Venkat Yekkirala wrote:
> >> -----Original Message-----
> >> From: Paul Moore [mailto:paul.moore@hp.com]
> >>
> >> I agree that having a default, flow control "catch
> >> all"/unlabeled_t check is a
> >> good idea and preserved the SELinux philosophy but doing so
> >> without breaking
> >> the flow of packets in/out/through a system with old policy
> >> is not an easy
> >> task.  At some point in the future, if we want to reconcile
> >> all of the peer
> >> label access checks to a single object class, we'll probably
> >> need to do
> >> something similar to the compat_net (compat_net_peer?) flag.
> >
> > We could actually do this as part of this, correct (unless I
> > missed any one's objections elsewhere).
>
> I agree  - bring it on.  We're unifying the on-the-wire labeling
> mechanism by making sure that they agree if more than one is use.  That
> is a good start.  I'd really like to continue on here and get the
> unified access check so we don't have to do netlabel style and labeled
> ipsec style peer access checks.

Me too.  I was originally talking about the possibility of finding a clever 
backwards compatible way to do flow control, however, I'm not sure it's worth 
the work and we should just include all of the flow control and revised peer 
label access checks into one patchset that makes use of compat_net_peer.

> The target context for both the 
> association checks and the *_socket (netlabel) checks will be the same.
>   Why not just drop the association checks since the *idea* is now
> covered in the *_socket checks?

I agree, the association checks made sense at one point, they don't anymore.  
However, we should probably run this by the policy guys (are any of you 
listening to this thread?) before we get to far - I can't imagine they would 
object.

> I am assuming that the *_socket checks used by netlabel would be
> checking against the new peer label that is in (at least near) the skb,
> is that right?  If so, the *_socket checks also take care of the peer
> label coming from loopback.  This would be a bit of a policy change
> since the *_socket checks now apply to domains (not just the base type
> from the initial sid) since the loopback traffic goes through the same
> checks.  I at least hope we don't add another, separate, check for the
> loopback case...
>
> That was just one idea, but I definitely think the unification should be
> a goal of this exercise.

My goal is that for packets being locally consumed we have _one_ access check 
(not including flow controls checks or netfilter label checks) which would be 
similar to the following:

 allow socket_t peer_label_t:peer recv;

Regardless of how the peer label was provided (labeled IPsec, remote CIPSO 
host, fallback peer label, loopback, etc.)  The advantages to doing this are 
many and I'm struggling to find a drawback.

Also, as an added bonus, if we manage to pull this off, I think we should be 
able to successfully solve that nagging world peace problem ;)

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

> > Okay, I understand your point now; I still don't think this
> > is too much of a
> > problem.  As you pointed out below we are most likely going
> > to need a final
> > catch-all flow control hook for the default, no-config case
> > (more on this
> > below) and this appears to be an excellent place to make the final
> > on-the-wire labeling decision for forwarded packets that make use of
> > CIPSOesque labeling protocols.  There is also the
> > ip_build_options() hook
> > which I keep talking about, but it may happen to early in the
> > forwarding
> > patch to be useful, I would have to check the stack.
> > Regardless, I'm pretty
> > confident that whatever hooks we put in place to control
> > packet flow should
> > be sufficient to handle the on-the-wire labeling we want/need
> > so lets move on
> > to defining those hooks and see where that leaves us.
>
> As for xfrm, the patch we have already does this.

Yep, that's why I tried to say "CIPSOesque"; this is one area where the 
standard IPsec processing is rather helpful.

> I will send a version 
> out once we make a final decision on the filtering aspect.

Great.  FWIW, I think we are there.  Flow control filtering should be done 
when a packet enters the system and when it exits the system, regardless of 
it's destination (locally consumed, forwarded).  For packets entering the 
system checks should be done between the peer label and the receiving 
interface as well as the peer label and the source address (with support for 
netmasks).  For packets leaving the system checks should be done between the 
peer label and the sending interface as well as the peer label and the 
destination address (with support for netmasks).

> Major pieces 
> missing will be loopback labeling, fallback, OTW labeling for NetLabel
> as you talked about earlier, compatibility coding etc. You can perhaps
> take by patch and add these to it?

There is a _lot_ of work to do and I don't expect to get it all done next 
week.  It's going to take some time to get everything in place and working 
together.  Those features which we can safely integrate with the existing 
code base we should do (fallback and loopback labeling should be safe) but 
the rest will probably involve a compat_net type of solution and should 
probably be merged together into one kernel release.

Please keep sending RFCs/patches to the SELinux list while we sort out all of 
the implementation details and I'll see about setting up a git tree where we 
can do all of the bigger/intrusive changes.  This should make it easier for 
us to work together and people who are interesting in testing the new 
features will have a working tree to pull from.  Once things are looking good 
I'll work to get all of the contributed patches upstream.

> > I noticed there was no comment about how to avoid
> > compatibility issues :)
> >
> > I agree that having a default, flow control "catch
> > all"/unlabeled_t check is a
> > good idea and preserved the SELinux philosophy but doing so
> > without breaking
> > the flow of packets in/out/through a system with old policy
> > is not an easy
> > task.  At some point in the future, if we want to reconcile
> > all of the peer
> > label access checks to a single object class, we'll probably
> > need to do
> > something similar to the compat_net (compat_net_peer?) flag.
>
> We could actually do this as part of this, correct (unless I
> missed any one's objections elsewhere).
>
> > If we want to
> > get the flow control functionality in sooner we'll need
> > something more
> > elegant.
>
> Could you please elaborate on this.

I'll will in response to Darrel's mail as he gets into this a bit more

> > <mental note>
> > We should probably look at putting the old compat_net bits in
> > the feature
> > removal queue if they aren't already ...
> > </mental note>
>
> I wonder what the current standard is for removing deprecated
> code. Is there a certain number of versions we need to wait or
> does it vary based on what's been deprecated?

All I'm aware of is Documentation/feature-removal-schedule.txt.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

(snip)
> Hmm, so in summary, you (TCS) don't see a need for flow 
> control of 
> fallback 

or generically peer (right?; just trying to make sure I am not missing
anything subtle here ...)

> labels with granularity greater then a single host and if 
> really pushed 
> interface level granularity would most likely suffice.  I'll 
> venture that 
> host/network level granularity might be nice for normal users 
> who only have 
> one interface which connects to multiple networks, e.g. the 
> person sitting at 
> home on a private home network which also connects to the 
> big-bad-internet 
> via a nat box provided by their ISP.

You are right. I think the whole thing boils down to what you trust and
this can theoretically vary from case to case. For example, if one trusts
a host to compartmentalize/segregate/mac services appropriately but cannot
do OTW labeling, and they trust the network path to it (say by use of
IPSec),
it's conceivable that they may want the ability to fallback per-port
(granted
it could get challenging with the use of ephemeral ports by clients) and
further
flow-control per-port as well. But I guess we could always start with the
current ideas on what can *reasonably* and *commonly* be trusted, which it
looks like would be the netif and the node (usually using IPSec as you
mention below)
and see how far that will take us in the real world. At least this should
meet
our current needs. I would be curious to see specifically what other current
users such as Joe Nall, Ted Toth and others would like to see. IOW, will
this
meet their needs. An explicit (N)ACK would be great.

> 
> This now has me rethinking the need for a full featured 
> netfilter based 
> mechanism for flow control (SECFILTER).  I'm wondering if we 
> would be better 
> served by simple hooks in the network device layer for in/out 
> and possible 
> forward.  As James pointed out in the off-list discussion, the whole 
> netfilter mechanism seems like a bit much for what we actually need.

Agreed.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 28, 2007, at 11:13 AM, Venkat Yekkirala wrote:
>
> You are right. I think the whole thing boils down to what you trust  
> and
> this can theoretically vary from case to case. For example, if one  
> trusts
> a host to compartmentalize/segregate/mac services appropriately but  
> cannot
> do OTW labeling, and they trust the network path to it (say by use of
> IPSec),
> it's conceivable that they may want the ability to fallback per-port
> (granted
> it could get challenging with the use of ephemeral ports by  
> clients) and
> further
> flow-control per-port as well. But I guess we could always start  
> with the
> current ideas on what can *reasonably* and *commonly* be trusted,  
> which it
> looks like would be the netif and the node (usually using IPSec as you
> mention below)
> and see how far that will take us in the real world. At least this  
> should
> meet
> our current needs. I would be curious to see specifically what  
> other current
> users such as Joe Nall, Ted Toth and others would like to see. IOW,  
> will
> this
> meet their needs. An explicit (N)ACK would be great.

 From an untrustworthy host (no MAC enforcement), every port ought to be
the same for Bell-Lapadula MAC purposes.

I'm sure there are some fringe cases that would violate that rule, but
they can be handled with IP aliasing on the untrusted host.

joe

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Tuesday, August 28 2007 12:13:03 pm Venkat Yekkirala wrote:
> (snip)
>
> > Hmm, so in summary, you (TCS) don't see a need for flow
> > control of
> > fallback
>
> or generically peer (right?; just trying to make sure I am not missing
> anything subtle here ...)

Yes, typo on my part see my mail to Darrel.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

[Darrel has made me aware I am breaking threads; will fix this
in a day or two]

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
(snip)
> 
> > Also, in the forwarding case, while the original xfrm-label should
> > still be around in the labeled-IPSec to non-labeled-IPSec case, I
> > would imagine in the NetLabel case, the option field would lose the
> > "original" label in a DOI gateway instance (if and when NateLabel
> > does this), right?
> 
> Yes, once you change the packet's label on the wire you have 
> to potential to 
> change the packet's label.  However, simply changing the 
> label to reflect a 
> different CIPSO DOI (I assume that is the DOI you were 
> talking about?) 

Yes.

> shouldn't change the NetLabel/CIPSO label as seen by SELinux 
> since the only 
> thing the on-the-wire label translation would be doing is 
> translating the 
> label between two different security domains/DOIs, the 
> semantic value of the 
> label should be preserved.
> 
> I would consider removing the NetLabel/CIPSO label from a 
> packet to be the 
> same as relabeling a packet to unlabeled_t and I still 
> believe that the 
> kernel should not get involved in packet relabeling at this 
> point, leave that 
> up to userspace.

Traditionally anyway, the original label has been used all the
way thru for flow-control, etc., since that's the original label
of the packet. I believe the packet losing the label is just
a recognition of the fact that the packet can't explicitly
carry the label onto the other network, but the label is
implicit from what I understand.

For example, in the case of xfrm, the label should be preserved
in the skb->sp field all the way thru, and so we should be able
to prevent a Top Secret xfrm-labeled packet from being forwarded
to a Secret interface even when the packet needs to be sent
in the clear (or using non-labeled IPsec) onto the Secret network.
In the NetLabel case, I wonder if we could use the
same special IP Option that we would use for Loopback packet labeling
to carry the "original" label thru to the last check and
strip it out before it gets on the wire? If this is possible, then
I guess we would need to take care to plant this option on the
packet after it has undergone any xfrms?


> 
> > >  The second idea was to
> > > divide the secmark
> > > field in the sk_buff into two 16 bit sub-fields effectively
> > > shortening peer
> > > and secmark SIDs to 16 bits.
> >
> > I would vote for this (or some variant). This has 2 advantages:
> >
> > 1. Resolve the external labels just once and plant it in the
> >    split secmark.
> >
> > 2. Also use this for a loopback packet labeling (as also pointed
> >    out by you later).
> 
> I'm slowly warming up to the idea of splitting the secmark 
> field, although I 
> still remain very concerned about the long term effects and 
> compatibility 
> issues.  Yes, there is the potential for a network SID mapper 
> but I'm not 
> very excited about that idea right now.  I guess what I'd 
> like to see is 
> something similar to the change below go through a few 
> iterations of testing 
> before we make up our minds.

Sounds like a plan.

>  We'd also need to entire 
> SELinux braintrust to 
> agree to the idea, and aside from Stephen and James, I'm not 
> sure they are 
> still reading this thread.
> 
> Index: linux-2.6_misc/security/selinux/ss/sidtab.c
> ===================================================================
> --- linux-2.6_misc.orig/security/selinux/ss/sidtab.c
> +++ linux-2.6_misc/security/selinux/ss/sidtab.c
> @@ -212,7 +212,7 @@ int sidtab_context_to_sid(struct sidtab
>                 if (sid)
>                         goto unlock_out;
>                 /* No SID exists for the context.  Allocate a 
> new one. */
> -               if (s->next_sid == UINT_MAX || s->shutdown) {
> +               if (s->next_sid > 0x0000ffff || s->shutdown) {
>                         ret = -ENOMEM;
>                         goto unlock_out;
> 
> Let's figure out what we need for flow control and forwarding 
> and then we can 
> start a separate thread regarding 16 bit SIDs to get 
> everyone's attention.

Sure.

> 
> > >  * Loopback/Localhost peer packet labeling
> > >
> > > This has been a long standing requirement which at first
> > > glance seems like it
> > > would be simple to achieve but in practice it has proven
> > > quiet difficult to
> > > implement.  Current solutions to the problem involve using either
> > > NetLabel/CIPSO or labeled IPsec over loopback to provide 
> peer labels,
> > > unfortunately both have drawbacks.  NetLabel/CIPSO is
> > > currently limited to
> > > only conveying the MLS sensitivity label over the wire and
> > > only then for IPv4
> > > packets.
> >
> > This can perhaps be worked-around by passing the sid verbatim
> > using a special IP option (I believe suggested by Pete looking
> > at the Symposium minutes).
> 
> Yep, this is basically the idea behind Selopt or similar.
> 
> > >  * Packet flow control
> > >
> > > Another long standing goal that has not seen much success
> > > over the years.  The
> > > two approaches currently being considered are: per-interface
> > > checks against
> > > the peer label with the possibility of an additional
> > > forwarding hook/check if
> > > needed for labeling purposes, as well as an iptables 
> based filtering
> > > mechanism which has already been discussed off and on on the
> > > public SELinux
> > > and LSPP mailing lists (SECFILTER/SECPOINT).  The idea behind
> > > the iptables
> > > based filtering mechanism is that "filter points" could be
> > > defined using
> > > iptables/netfilter which would provide very granular access
> > > control checks.
> > > The big question that is currently being debated is how much
> > > granularity is
> > > needed and how much makes sense?
> >
> > I believe this is hard to predict for the general case.
> 
> Yep, I believe you're right and the fact that this discussion 
> has gone on for 
> quite some time without any real obvious answer makes me 
> think we won't 
> arrive at one.  In that case, I guess we should just provide the most 
> granularity possible and let the admins sort it out (the 
> SECFILTER idea).
> 
> As far as I can tell there is still one important issue we 
> need to resolve - 
> how to introduce new packet access checks without causing a 
> regression for 
> users with older policy.  This of course is tied to the 
> desire to have a 
> default/unlabeled_t packet access check in the case where the 
> admin has not 
> explicitly setup any SECFILTER points/gates/etc.  Can we live 
> without a 
> default check?

I highly doubt it. We have erred on the side of caution on this
in our patch since we didn't want any inadvertent flows between
Secret and TS networks for example. This also obviously retains
the SELinux philosophy of no allows by default.

> It certainly makes the implementation cleaner and the 
> compatibility issues less of a concern.  Thoughts?
> 
> > >  * Fallback labels
> > >
> > > The simple idea that started this whole discussion.  The need
> > > for a usable
> > > peer label fallback mechanism is understood by everyone but
> > > the granularity
> > > with which peer fallback labels are assigned are still a
> > > source of debate.
> > > The idea is wether the granularity proposed in this NetLabel
> > > patchset which
> > > allows per-host/subnet granularity for each interface is
> > > enough, and if not
> > > is a very granular iptables/netfilter peer label assignment
> > > of fallback
> > > labels required?  This topic did come up briefly some time
> > > ago on the public
> > > mailing list between Joshua Brindle and myself and we 
> agreed that the
> > > granularity presented in this patchset is sufficient,
> > > however, not everyone
> > > feels this way so we are still discussing the best solution.
> >
> > Well, there may be a case, where there's a need to identify an
> > sshd_t peer different from a httpd_t peer. Or a http_client_t
> > peer from an rss_aggregator_t peer. Scalability from coarse to
> > granular should meet the entire spectrum of general cases.
> 
> Yes, but you're not really distinguishing between a ssh_t 
> peer and a http_t 
> peer, e.g. ssh -p 80, which is what troubles me about port 
> level granularity.  
> I sent another mail earlier which I believe described these 
> concerns a bit 
> better.

I missed it earlier. We have been brainstorming on this among
myself, Chad and Darrel and our current thinking (assuming I am
putting it forward correctly) is that if one limits trust to the
interface, it actually seems to make sense to allow defaults at
just the interface level and further it seems to make sense to
have the same level of granularity for both the fallback and the
filtering case. At least for MLS, it seems enough to have the ability
to define fallbacks as also perform filtering at just the interface level.
The question to be debated is if for TE, we need granularity
beyond the interface for fallbacks and flow-control.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Monday, August 27 2007 6:09:12 pm Venkat Yekkirala wrote:
> [Darrel has made me aware I am breaking threads; will fix this
> in a day or two]

I'm really curious at this point, someday you guys are going to have to 
explain how your email system works ;)

> > -----Original Message-----
> > From: Paul Moore [mailto:paul.moore@hp.com]
>
> (snip)
>
> > > Also, in the forwarding case, while the original xfrm-label should
> > > still be around in the labeled-IPSec to non-labeled-IPSec case, I
> > > would imagine in the NetLabel case, the option field would lose the
> > > "original" label in a DOI gateway instance (if and when NateLabel
> > > does this), right?
> >
> > Yes, once you change the packet's label on the wire you have
> > to potential to
> > change the packet's label.  However, simply changing the
> > label to reflect a
> > different CIPSO DOI (I assume that is the DOI you were
> > talking about?)
>
> Yes.
>
> > shouldn't change the NetLabel/CIPSO label as seen by SELinux
> > since the only
> > thing the on-the-wire label translation would be doing is
> > translating the
> > label between two different security domains/DOIs, the
> > semantic value of the
> > label should be preserved.
> >
> > I would consider removing the NetLabel/CIPSO label from a
> > packet to be the
> > same as relabeling a packet to unlabeled_t and I still
> > believe that the
> > kernel should not get involved in packet relabeling at this
> > point, leave that
> > up to userspace.
>
> Traditionally anyway, the original label has been used all the
> way thru for flow-control, etc., since that's the original label
> of the packet. I believe the packet losing the label is just
> a recognition of the fact that the packet can't explicitly
> carry the label onto the other network, but the label is
> implicit from what I understand.

Okay, I understand your point now; I still don't think this is too much of a 
problem.  As you pointed out below we are most likely going to need a final 
catch-all flow control hook for the default, no-config case (more on this 
below) and this appears to be an excellent place to make the final 
on-the-wire labeling decision for forwarded packets that make use of 
CIPSOesque labeling protocols.  There is also the ip_build_options() hook 
which I keep talking about, but it may happen to early in the forwarding 
patch to be useful, I would have to check the stack.  Regardless, I'm pretty 
confident that whatever hooks we put in place to control packet flow should 
be sufficient to handle the on-the-wire labeling we want/need so lets move on 
to defining those hooks and see where that leaves us.

> For example, in the case of xfrm, the label should be preserved
> in the skb->sp field all the way thru, and so we should be able
> to prevent a Top Secret xfrm-labeled packet from being forwarded
> to a Secret interface even when the packet needs to be sent
> in the clear (or using non-labeled IPsec) onto the Secret network.
> In the NetLabel case, I wonder if we could use the
> same special IP Option that we would use for Loopback packet labeling
> to carry the "original" label thru to the last check and
> strip it out before it gets on the wire? 

At present I'm thinking that the "special IP option" would be a CIPSO option 
with a freeform tag similar to Selopt, however, nothing is set in stone.  The 
prospect of trying to sell a non IANA listed/approved IP option upstream is 
not very appealing to me, however, if we want IPv6 compat with Trusted 
Solaris we may have to do just that ... sigh.  Regardless, see my comments 
above about moving forward with the design of LSM hooks for packet flow 
first.

> > > >  * Packet flow control
> > > >
> > > > Another long standing goal that has not seen much success
> > > > over the years.  The
> > > > two approaches currently being considered are: per-interface
> > > > checks against
> > > > the peer label with the possibility of an additional
> > > > forwarding hook/check if
> > > > needed for labeling purposes, as well as an iptables
> >
> > based filtering
> >
> > > > mechanism which has already been discussed off and on on the
> > > > public SELinux
> > > > and LSPP mailing lists (SECFILTER/SECPOINT).  The idea behind
> > > > the iptables
> > > > based filtering mechanism is that "filter points" could be
> > > > defined using
> > > > iptables/netfilter which would provide very granular access
> > > > control checks.
> > > > The big question that is currently being debated is how much
> > > > granularity is
> > > > needed and how much makes sense?
> > >
> > > I believe this is hard to predict for the general case.
> >
> > Yep, I believe you're right and the fact that this discussion
> > has gone on for
> > quite some time without any real obvious answer makes me
> > think we won't
> > arrive at one.  In that case, I guess we should just provide the most
> > granularity possible and let the admins sort it out (the
> > SECFILTER idea).
> >
> > As far as I can tell there is still one important issue we
> > need to resolve -
> > how to introduce new packet access checks without causing a
> > regression for
> > users with older policy.  This of course is tied to the
> > desire to have a
> > default/unlabeled_t packet access check in the case where the
> > admin has not
> > explicitly setup any SECFILTER points/gates/etc.  Can we live
> > without a
> > default check?
>
> I highly doubt it. We have erred on the side of caution on this
> in our patch since we didn't want any inadvertent flows between
> Secret and TS networks for example. This also obviously retains
> the SELinux philosophy of no allows by default.

I noticed there was no comment about how to avoid compatibility issues :)

I agree that having a default, flow control "catch all"/unlabeled_t check is a 
good idea and preserved the SELinux philosophy but doing so without breaking 
the flow of packets in/out/through a system with old policy is not an easy 
task.  At some point in the future, if we want to reconcile all of the peer 
label access checks to a single object class, we'll probably need to do 
something similar to the compat_net (compat_net_peer?) flag.  If we want to 
get the flow control functionality in sooner we'll need something more 
elegant.

<mental note>
We should probably look at putting the old compat_net bits in the feature 
removal queue if they aren't already ...
</mental note>

> > > >  * Fallback labels
> > > >
> > > > The simple idea that started this whole discussion.  The need
> > > > for a usable
> > > > peer label fallback mechanism is understood by everyone but
> > > > the granularity
> > > > with which peer fallback labels are assigned are still a
> > > > source of debate.
> > > > The idea is wether the granularity proposed in this NetLabel
> > > > patchset which
> > > > allows per-host/subnet granularity for each interface is
> > > > enough, and if not
> > > > is a very granular iptables/netfilter peer label assignment
> > > > of fallback
> > > > labels required?  This topic did come up briefly some time
> > > > ago on the public
> > > > mailing list between Joshua Brindle and myself and we
> >
> > agreed that the
> >
> > > > granularity presented in this patchset is sufficient,
> > > > however, not everyone
> > > > feels this way so we are still discussing the best solution.
> > >
> > > Well, there may be a case, where there's a need to identify an
> > > sshd_t peer different from a httpd_t peer. Or a http_client_t
> > > peer from an rss_aggregator_t peer. Scalability from coarse to
> > > granular should meet the entire spectrum of general cases.
> >
> > Yes, but you're not really distinguishing between a ssh_t
> > peer and a http_t
> > peer, e.g. ssh -p 80, which is what troubles me about port
> > level granularity.
> > I sent another mail earlier which I believe described these
> > concerns a bit
> > better.
>
> I missed it earlier. We have been brainstorming on this among
> myself, Chad and Darrel and our current thinking (assuming I am
> putting it forward correctly) is that if one limits trust to the
> interface, it actually seems to make sense to allow defaults at
> just the interface level and further it seems to make sense to
> have the same level of granularity for both the fallback and the
> filtering case. At least for MLS, it seems enough to have the ability
> to define fallbacks as also perform filtering at just the interface level.
> The question to be debated is if for TE, we need granularity
> beyond the interface for fallbacks and flow-control.

I'm not hearing a real use case for granularity greater than a single host yet 
and I think everyone who has an opinion has already voiced it.  While I 
understand the argument for keeping the same level of granularity for both 
the flow controls checks and the fallback label, I see no compelling reason 
to keep parity here and further I see potential problems with allowing that 
fine of a granularity for a fallback label.

I'll leave this open for new arguments as I'm still messing with the patches, 
but I'm going to continue with the current approach of static/fallback 
labeling based on the interface/network.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Venkat Yekkirala wrote:
<snip>
>> From: Paul Moore [mailto:paul.moore@hp.com]
>> Yes, but you're not really distinguishing between a ssh_t 
>> peer and a http_t 
>> peer, e.g. ssh -p 80, which is what troubles me about port 
>> level granularity.  
>> I sent another mail earlier which I believe described these 
>> concerns a bit 
>> better.
> 
> I missed it earlier. We have been brainstorming on this among
> myself, Chad and Darrel and our current thinking (assuming I am
> putting it forward correctly) is that if one limits trust to the
> interface, it actually seems to make sense to allow defaults at
> just the interface level and further it seems to make sense to
> have the same level of granularity for both the fallback and the
> filtering case. At least for MLS, it seems enough to have the ability
> to define fallbacks as also perform filtering at just the interface level.
> The question to be debated is if for TE, we need granularity
> beyond the interface for fallbacks and flow-control.

We batted around a bunch of ideas and it almost always seemed that the 
granularity of fallback labels should match the granularity of the flow 
control checks.  As Venkat stated, anything past the netif is really 
extending turst on our part, whether it is for applying a fallback label 
or performing an access check.  If we apply fallbacks at the host level, 
we should also allow flow control at the host level.  It doesn't seem to 
make sense that we would say "info from 1.2.3.4 is SECRET", but not be 
able to "info going to 1.2.3.4 should be SECRET).  I personally don't 
see a current need to go past host for either, and even host *could* be 
argued away in my eyes.  That being said, I would never be opposed to 
flexibility.

NOTE that I said almost in my first sentence...  The only "opposing" 
scenario that seemed intuitive to me was apply fallbacks using 
network/netmask only and apply flow checks at interface only.  An 
example of operation would be:

netif access rules:
eth1	SECRET	10.0.1.0/24
eth2	TS	10.0.2.0/24

host fallback labels:
10.0.1.100/32	SYSHI
10.0.1.0/24	SECRET
10.0.2.0/24	TS

That CON host would obviously get denied coming in if it was not using 
some on-the-wire labeling because it would be assigned a label of SYSHI, 
which would be blocked at the netif flow check.  I'm sure something is 
wrong with the host label/netif access check idea, but I can't put my 
finger on it...  Too much trust in the IP address and routing?

Paul, why the netif/host combo in the original netlabel fallback patch? 
  Why not just hosts (or really network/netmask)?  Can we make the

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Darrel Goeddel wrote:
> Paul, why the netif/host combo in the original netlabel fallback patch? 
>  Why not just hosts (or really network/netmask)?  Can we make the
> 

Sorry, don't know what happened to the rest of the text...

Can we make the netif optional or add a wildcard netif?  That would 
allow for a truly generic fallback if desired.  Currently if you add a 
new interface, you need to go back and add a new rule (I think, could be 
wrong since I haven't actually tried it).

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Tuesday, August 28 2007 10:58:16 am Darrel Goeddel wrote:
> Venkat Yekkirala wrote:
> <snip>
>
> >> From: Paul Moore [mailto:paul.moore@hp.com]
> >> Yes, but you're not really distinguishing between a ssh_t
> >> peer and a http_t
> >> peer, e.g. ssh -p 80, which is what troubles me about port
> >> level granularity.
> >> I sent another mail earlier which I believe described these
> >> concerns a bit
> >> better.
> >
> > I missed it earlier. We have been brainstorming on this among
> > myself, Chad and Darrel and our current thinking (assuming I am
> > putting it forward correctly) is that if one limits trust to the
> > interface, it actually seems to make sense to allow defaults at
> > just the interface level and further it seems to make sense to
> > have the same level of granularity for both the fallback and the
> > filtering case. At least for MLS, it seems enough to have the ability
> > to define fallbacks as also perform filtering at just the interface
> > level. The question to be debated is if for TE, we need granularity
> > beyond the interface for fallbacks and flow-control.
>
> We batted around a bunch of ideas and it almost always seemed that the
> granularity of fallback labels should match the granularity of the flow
> control checks.  As Venkat stated, anything past the netif is really
> extending turst on our part, whether it is for applying a fallback label
> or performing an access check.  If we apply fallbacks at the host level,
> we should also allow flow control at the host level.  It doesn't seem to
> make sense that we would say "info from 1.2.3.4 is SECRET", but not be
> able to "info going to 1.2.3.4 should be SECRET).  I personally don't
> see a current need to go past host for either, and even host *could* be
> argued away in my eyes.  That being said, I would never be opposed to
> flexibility.

Hmm, so in summary, you (TCS) don't see a need for flow control of fallback 
labels with granularity greater then a single host and if really pushed 
interface level granularity would most likely suffice.  I'll venture that 
host/network level granularity might be nice for normal users who only have 
one interface which connects to multiple networks, e.g. the person sitting at 
home on a private home network which also connects to the big-bad-internet 
via a nat box provided by their ISP.

This now has me rethinking the need for a full featured netfilter based 
mechanism for flow control (SECFILTER).  I'm wondering if we would be better 
served by simple hooks in the network device layer for in/out and possible 
forward.  As James pointed out in the off-list discussion, the whole 
netfilter mechanism seems like a bit much for what we actually need.

> NOTE that I said almost in my first sentence...  The only "opposing"
> scenario that seemed intuitive to me was apply fallbacks using
> network/netmask only and apply flow checks at interface only.  An
> example of operation would be:
>
> netif access rules:
> eth1	SECRET	10.0.1.0/24
> eth2	TS	10.0.2.0/24
>
> host fallback labels:
> 10.0.1.100/32	SYSHI
> 10.0.1.0/24	SECRET
> 10.0.2.0/24	TS
>
> That CON host would obviously get denied coming in if it was not using
> some on-the-wire labeling because it would be assigned a label of SYSHI,
> which would be blocked at the netif flow check.  I'm sure something is
> wrong with the host label/netif access check idea, but I can't put my
> finger on it...  Too much trust in the IP address and routing?

Well, we kinda have to trust that IP works correctly as it is beyond our 
control - we only get to effect the box, not the networks it attached to.  If 
you can't trust the network make use of something like IPsec which can at 
least provide you data confidentiality/integrity/auth.

> Paul, why the netif/host combo in the original netlabel fallback patch?
>   Why not just hosts (or really network/netmask)?
{patched in from the other email}
> Can we make the netif optional or add a wildcard netif?  That would allow
> for a truly generic fallback if desired.  Currently if you add a new
> interface, you need to go back and add a new rule (I think, could be wrong
> since I haven't actually tried it). 

Sure, I can add a default netif which is used if a match isn't found.  I 
originally considered adding one (the NetLabel domain mapping mechanism has a 
default rule match) but it seemed a little "dangerous" at the time, although 
I think I was just being too cautious.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 28, 2007, at 10:51 AM, Paul Moore wrote:
>
> Hmm, so in summary, you (TCS) don't see a need for flow control of  
> fallback
> labels with granularity greater then a single host and if really  
> pushed
> interface level granularity would most likely suffice.  I'll  
> venture that
> host/network level granularity might be nice for normal users who  
> only have
> one interface which connects to multiple networks, e.g. the person  
> sitting at
> home on a private home network which also connects to the big-bad- 
> internet
> via a nat box provided by their ISP.

This matches my CMW experience. Interface labeling is a must. Per  
host/net
default labeling is very useful, but isn't a show-stopper. Per host/net
default labeling is particularly useful when testing since most of us  
don't
have a a dozen physical interfaces and associated infrastructure for  
test.

Will interface aliases (eth0:1) be able to take on different labels from
their base interface?

joe

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
> On Aug 28, 2007, at 10:51 AM, Paul Moore wrote:
> > Hmm, so in summary, you (TCS) don't see a need for flow control of
> > fallback
> > labels with granularity greater then a single host and if really
> > pushed
> > interface level granularity would most likely suffice.  I'll
> > venture that
> > host/network level granularity might be nice for normal users who
> > only have
> > one interface which connects to multiple networks, e.g. the person
> > sitting at
> > home on a private home network which also connects to the big-bad-
> > internet
> > via a nat box provided by their ISP.
>
> This matches my CMW experience. Interface labeling is a must. Per
> host/net
> default labeling is very useful, but isn't a show-stopper. Per host/net
> default labeling is particularly useful when testing since most of us
> don't
> have a a dozen physical interfaces and associated infrastructure for
> test.

That's good to know others have the same needs/requirements.  We've been going 
around in circles for a while now but I think we are finally starting to 
settle on what we need.

> Will interface aliases (eth0:1) be able to take on different labels from
> their base interface?

Not sure, it all depends on if an interface alias ends up creating a separate 
net_device struct in the kernel, I don't have the answer to this off the top 
of my head.  What is your preference?

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 28, 2007, at 1:51 PM, Paul Moore wrote:

> On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
>>
>> Will interface aliases (eth0:1) be able to take on different  
>> labels from
>> their base interface?
>
> Not sure, it all depends on if an interface alias ends up creating  
> a separate
> net_device struct in the kernel, I don't have the answer to this  
> off the top
> of my head.  What is your preference?

That interface aliases be independently labeled.

joe


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Tue, 2007-08-28 at 14:10 -0500, Joe Nall wrote:
> On Aug 28, 2007, at 1:51 PM, Paul Moore wrote:
> 
> > On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
> >>
> >> Will interface aliases (eth0:1) be able to take on different  
> >> labels from
> >> their base interface?
> >
> > Not sure, it all depends on if an interface alias ends up creating  
> > a separate
> > net_device struct in the kernel, I don't have the answer to this  
> > off the top
> > of my head.  What is your preference?
> 
> That interface aliases be independently labeled.

Per Spencer Shimko's recent posting, setting a netifcon on an interface
alias (ala eth0:1) has no effect - the kernel just uses the real
interface label at all times.  Which is arguably the right thing to do -
an object's label shouldn't change just because it is accessed by
another name (pathnames vs. inodes comes to mind here).

-- 
Stephen Smalley
National Security Agency


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Joe Nall wrote:
>
> On Aug 28, 2007, at 1:51 PM, Paul Moore wrote:
>
>> On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
>>>
>>> Will interface aliases (eth0:1) be able to take on different labels 
>>> from
>>> their base interface?
>>
>> Not sure, it all depends on if an interface alias ends up creating a 
>> separate
>> net_device struct in the kernel, I don't have the answer to this off 
>> the top
>> of my head.  What is your preference?
>
> That interface aliases be independently labeled.

I completely agree with Stephen here. Accessing the same physical piece 
of hardware (on the same wire) through a different 'name' provides 
basically nothing. Most people I've talked to aren't even comfortable 
using nics that share the same chips on board (eg., dual nics on the 
motherboard). Ofcourse those people are somehow mislead into believing 
that there is any security gain there since all the network data ends up 
in the same place eventually.

OTOH using a single nic with multiple ipsec associations (with different 
keys ofcourse) could provide a benefit, depending on what your 
requirements are.


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 28, 2007, at 2:48 PM, Joshua Brindle wrote:

> Joe Nall wrote:
>>
>> On Aug 28, 2007, at 1:51 PM, Paul Moore wrote:
>>
>>> On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
>>>>
>>>> Will interface aliases (eth0:1) be able to take on different  
>>>> labels from
>>>> their base interface?
>>>
>>> Not sure, it all depends on if an interface alias ends up  
>>> creating a separate
>>> net_device struct in the kernel, I don't have the answer to this  
>>> off the top
>>> of my head.  What is your preference?
>>
>> That interface aliases be independently labeled.
>
> I completely agree with Stephen here. Accessing the same physical  
> piece of hardware (on the same wire) through a different 'name'  
> provides basically nothing.

Except convenience. Different IP address, different behavior. I can  
be happy either way.

> Most people I've talked to aren't even comfortable using nics that  
> share the same chips on board (eg., dual nics on the motherboard).

We had the same issue with quad port ethernet cards because they had  
a shared PCI interface chip. After looking at the driver, the concern  
was not wholly unfounded ...

joe

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Joe Nall wrote:
>
> On Aug 28, 2007, at 2:48 PM, Joshua Brindle wrote:
>
>> Joe Nall wrote:
>>>
>>> On Aug 28, 2007, at 1:51 PM, Paul Moore wrote:
>>>
>>>> On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
>>>>>
>>>>> Will interface aliases (eth0:1) be able to take on different 
>>>>> labels from
>>>>> their base interface?
>>>>
>>>> Not sure, it all depends on if an interface alias ends up creating 
>>>> a separate
>>>> net_device struct in the kernel, I don't have the answer to this 
>>>> off the top
>>>> of my head.  What is your preference?
>>>
>>> That interface aliases be independently labeled.
>>
>> I completely agree with Stephen here. Accessing the same physical 
>> piece of hardware (on the same wire) through a different 'name' 
>> provides basically nothing.
>
> Except convenience. Different IP address, different behavior. I can be 
> happy either way.

It is misusing an abstraction, the same way as(as Stephen said) having 
different access control on two paths that refer to the same inode.

It should be no surprise that I was just informed by the apparmor devs 
that they do plan to allow differing access between interface aliases.

>
>> Most people I've talked to aren't even comfortable using nics that 
>> share the same chips on board (eg., dual nics on the motherboard).
>
> We had the same issue with quad port ethernet cards because they had a 
> shared PCI interface chip. After looking at the driver, the concern 
> was not wholly unfounded ...

Well.. You still aren't buying anything by avoiding this situation, the 
drivers are all in the same process space (even if they are different 
drivers), the same network stack will be used, etc. You might be able to 
sleep at night but what is the security gain?


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Joshua Brindle wrote:
> Joe Nall wrote:
>>
>> On Aug 28, 2007, at 2:48 PM, Joshua Brindle wrote:
>>
>>> Joe Nall wrote:
>>>>
>>>> On Aug 28, 2007, at 1:51 PM, Paul Moore wrote:
>>>>
>>>>> On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
>>>>>>
>>>>>> Will interface aliases (eth0:1) be able to take on different 
>>>>>> labels from
>>>>>> their base interface?
>>>>>
>>>>> Not sure, it all depends on if an interface alias ends up creating 
>>>>> a separate
>>>>> net_device struct in the kernel, I don't have the answer to this 
>>>>> off the top
>>>>> of my head.  What is your preference?
>>>>
>>>> That interface aliases be independently labeled.
>>>
>>> I completely agree with Stephen here. Accessing the same physical 
>>> piece of hardware (on the same wire) through a different 'name' 
>>> provides basically nothing.
>>
>> Except convenience. Different IP address, different behavior. I can 
>> be happy either way.
>
> It is misusing an abstraction, the same way as(as Stephen said) having 
> different access control on two paths that refer to the same inode.
>
> It should be no surprise that I was just informed by the apparmor devs 
> that they do plan to allow differing access between interface aliases.
>

the more I think about this the less it matters. Doing labeling based on 
node is really the exact same thing as labeling based on interface aliases.

node 192.168.1.1/24  = net_foo_t
node 192.168.2.1/24  = net_bar_t

or

eth0:1 (which is 192.168.1.1 with /24 netmask) = net_foo_t
eth0:2 (which is 192.168.2.1 with /24 netmask) = net_bar_t

see, no difference :)

So if we allow node based then alias isn't any different. also netfilter 
lets you select on interface aliases so in some way we already allow 
this behavior.

>>
>>> Most people I've talked to aren't even comfortable using nics that 
>>> share the same chips on board (eg., dual nics on the motherboard).
>>
>> We had the same issue with quad port ethernet cards because they had 
>> a shared PCI interface chip. After looking at the driver, the concern 
>> was not wholly unfounded ...
>
> Well.. You still aren't buying anything by avoiding this situation, 
> the drivers are all in the same process space (even if they are 
> different drivers), the same network stack will be used, etc. You 
> might be able to sleep at night but what is the security gain?



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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Joshua Brindle wrote:
> Joshua Brindle wrote:
>> Joe Nall wrote:
>>>
>>> On Aug 28, 2007, at 2:48 PM, Joshua Brindle wrote:
>>>
>>>> Joe Nall wrote:
>>>>>
>>>>> On Aug 28, 2007, at 1:51 PM, Paul Moore wrote:
>>>>>
>>>>>> On Tuesday, August 28 2007 12:18:05 pm Joe Nall wrote:
>>>>>>>
>>>>>>> Will interface aliases (eth0:1) be able to take on different 
>>>>>>> labels from
>>>>>>> their base interface?
>>>>>>
>>>>>> Not sure, it all depends on if an interface alias ends up 
>>>>>> creating a separate
>>>>>> net_device struct in the kernel, I don't have the answer to this 
>>>>>> off the top
>>>>>> of my head.  What is your preference?
>>>>>
>>>>> That interface aliases be independently labeled.
>>>>
>>>> I completely agree with Stephen here. Accessing the same physical 
>>>> piece of hardware (on the same wire) through a different 'name' 
>>>> provides basically nothing.
>>>
>>> Except convenience. Different IP address, different behavior. I can 
>>> be happy either way.
>>
>> It is misusing an abstraction, the same way as(as Stephen said) 
>> having different access control on two paths that refer to the same 
>> inode.
>>
>> It should be no surprise that I was just informed by the apparmor 
>> devs that they do plan to allow differing access between interface 
>> aliases.
>>
>
> the more I think about this the less it matters. Doing labeling based 
> on node is really the exact same thing as labeling based on interface 
> aliases.
>
> node 192.168.1.1/24  = net_foo_t
> node 192.168.2.1/24  = net_bar_t
>
> or
>
> eth0:1 (which is 192.168.1.1 with /24 netmask) = net_foo_t
> eth0:2 (which is 192.168.2.1 with /24 netmask) = net_bar_t
>
> see, no difference :)
>
> So if we allow node based then alias isn't any different. also 
> netfilter lets you select on interface aliases so in some way we 
> already allow this behavior.

Ok, I think my brain is still catching up on this thread. Because of 
what I said above I think we should 1) not do node based fallbacks and 
2) not do nic alias-level fallbacks. This is the safe option (as already 
pointed out) and minimizes trust in untrustworthy things (eg., addresses 
coming from the network).

OTOH it may make some peoples lives easier to allow this. It is a false 
sense of security though so I vote for doing nic level fallbacks only 
and if someone *really* wants to do this they can just plug several nics 
into the same network (hopefully they'd recognize the horrible things 
they are doing if it is explicit like that).

It sounds like the decision is still up in the air though, does anyone 
inherently disagree with me here?


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 28, 2007, at 11:11 PM, Joshua Brindle wrote:
>>
>> the more I think about this the less it matters. Doing labeling  
>> based on node is really the exact same thing as labeling based on  
>> interface aliases.
>>
>> node 192.168.1.1/24  = net_foo_t
>> node 192.168.2.1/24  = net_bar_t
>>
>> or
>>
>> eth0:1 (which is 192.168.1.1 with /24 netmask) = net_foo_t
>> eth0:2 (which is 192.168.2.1 with /24 netmask) = net_bar_t
>>
>> see, no difference :)
>>
>> So if we allow node based then alias isn't any different. also  
>> netfilter lets you select on interface aliases so in some way we  
>> already allow this behavior.
>
> Ok, I think my brain is still catching up on this thread. Because  
> of what I said above I think we should 1) not do node based  
> fallbacks and 2) not do nic alias-level fallbacks. This is the safe  
> option (as already pointed out) and minimizes trust in  
> untrustworthy things (eg., addresses coming from the network).

If we install and maintain a router (in a locked box with IP admin  
disabled), we are allowed to trust (label based on) the router's IP  
address. If we put a single PC behind the router and NAT or route to  
it specifically, we are allowed to trust the IP address of the PC  
(since it is provided by the router). So there are circumstances  
where the IP address of an untrustworthy OS is itself trustworthy in  
the eyes of our accreditors.

> OTOH it may make some peoples lives easier to allow this. It is a  
> false sense of security though so I vote for doing nic level  
> fallbacks only and if someone *really* wants to do this they can  
> just plug several nics into the same network (hopefully they'd  
> recognize the horrible things they are doing if it is explicit like  
> that).

1) no node fallbacks
2) no alias fallbacks
3) no nic fallbacks

What is ok? A brick with color coded ethernet jacks painted on it?

It is important to allow the flexibility to network with less  
advanced systems. This is a medium assurance OS. IP address, network  
and interface have all been used as discriminators at this assurance  
level for years.

> It sounds like the decision is still up in the air though, does  
> anyone inherently disagree with me here?

Yes. I want it all :)

joe

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Joe Nall wrote:
>
> On Aug 28, 2007, at 11:11 PM, Joshua Brindle wrote:
>>>
>>> the more I think about this the less it matters. Doing labeling 
>>> based on node is really the exact same thing as labeling based on 
>>> interface aliases.
>>>
>>> node 192.168.1.1/24  = net_foo_t
>>> node 192.168.2.1/24  = net_bar_t
>>>
>>> or
>>>
>>> eth0:1 (which is 192.168.1.1 with /24 netmask) = net_foo_t
>>> eth0:2 (which is 192.168.2.1 with /24 netmask) = net_bar_t
>>>
>>> see, no difference :)
>>>
>>> So if we allow node based then alias isn't any different. also 
>>> netfilter lets you select on interface aliases so in some way we 
>>> already allow this behavior.
>>
>> Ok, I think my brain is still catching up on this thread. Because of 
>> what I said above I think we should 1) not do node based fallbacks 
>> and 2) not do nic alias-level fallbacks. This is the safe option (as 
>> already pointed out) and minimizes trust in untrustworthy things 
>> (eg., addresses coming from the network).
>
> If we install and maintain a router (in a locked box with IP admin 
> disabled), we are allowed to trust (label based on) the router's IP 
> address. If we put a single PC behind the router and NAT or route to 
> it specifically, we are allowed to trust the IP address of the PC 
> (since it is provided by the router). So there are circumstances where 
> the IP address of an untrustworthy OS is itself trustworthy in the 
> eyes of our accreditors.
>

eh? Except not. anything on the same lan as the router can pretend to be 
said router via both mac address and ip. ip is absolutely not reliable 
unless its going over ipsec (in which case you'd just use ipsec 
labeling) or the network is completely isolated (in which case you'd 
just use interface labeling).



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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 29, 2007, at 9:04 AM, Joshua Brindle wrote:

> Joe Nall wrote:
>>
>> On Aug 28, 2007, at 11:11 PM, Joshua Brindle wrote:
>>>>
>>>> the more I think about this the less it matters. Doing labeling  
>>>> based on node is really the exact same thing as labeling based  
>>>> on interface aliases.
>>>>
>>>> node 192.168.1.1/24  = net_foo_t
>>>> node 192.168.2.1/24  = net_bar_t
>>>>
>>>> or
>>>>
>>>> eth0:1 (which is 192.168.1.1 with /24 netmask) = net_foo_t
>>>> eth0:2 (which is 192.168.2.1 with /24 netmask) = net_bar_t
>>>>
>>>> see, no difference :)
>>>>
>>>> So if we allow node based then alias isn't any different. also  
>>>> netfilter lets you select on interface aliases so in some way we  
>>>> already allow this behavior.
>>>
>>> Ok, I think my brain is still catching up on this thread. Because  
>>> of what I said above I think we should 1) not do node based  
>>> fallbacks and 2) not do nic alias-level fallbacks. This is the  
>>> safe option (as already pointed out) and minimizes trust in  
>>> untrustworthy things (eg., addresses coming from the network).
>>
>> If we install and maintain a router (in a locked box with IP admin  
>> disabled), we are allowed to trust (label based on) the router's  
>> IP address. If we put a single PC behind the router and NAT or  
>> route to it specifically, we are allowed to trust the IP address  
>> of the PC (since it is provided by the router). So there are  
>> circumstances where the IP address of an untrustworthy OS is  
>> itself trustworthy in the eyes of our accreditors.
>>
>
> eh? Except not. anything on the same lan as the router can pretend  
> to be said router via both mac address and ip. ip is absolutely not  
> reliable unless its going over ipsec (in which case you'd just use  
> ipsec labeling) or the network is completely isolated (in which  
> case you'd just use interface labeling).

Switches with MAC filters, physical security on the switches and  
fiber, no IP admin on the switches and alerts when a port gets  
locked. $$$$ to install and admin.

joe

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Joe Nall wrote:
>
> On Aug 29, 2007, at 9:04 AM, Joshua Brindle wrote:
>
>> Joe Nall wrote:
>>>
>>> On Aug 28, 2007, at 11:11 PM, Joshua Brindle wrote:
>>>>>
>>>>> the more I think about this the less it matters. Doing labeling 
>>>>> based on node is really the exact same thing as labeling based on 
>>>>> interface aliases.
>>>>>
>>>>> node 192.168.1.1/24  = net_foo_t
>>>>> node 192.168.2.1/24  = net_bar_t
>>>>>
>>>>> or
>>>>>
>>>>> eth0:1 (which is 192.168.1.1 with /24 netmask) = net_foo_t
>>>>> eth0:2 (which is 192.168.2.1 with /24 netmask) = net_bar_t
>>>>>
>>>>> see, no difference :)
>>>>>
>>>>> So if we allow node based then alias isn't any different. also 
>>>>> netfilter lets you select on interface aliases so in some way we 
>>>>> already allow this behavior.
>>>>
>>>> Ok, I think my brain is still catching up on this thread. Because 
>>>> of what I said above I think we should 1) not do node based 
>>>> fallbacks and 2) not do nic alias-level fallbacks. This is the safe 
>>>> option (as already pointed out) and minimizes trust in 
>>>> untrustworthy things (eg., addresses coming from the network).
>>>
>>> If we install and maintain a router (in a locked box with IP admin 
>>> disabled), we are allowed to trust (label based on) the router's IP 
>>> address. If we put a single PC behind the router and NAT or route to 
>>> it specifically, we are allowed to trust the IP address of the PC 
>>> (since it is provided by the router). So there are circumstances 
>>> where the IP address of an untrustworthy OS is itself trustworthy in 
>>> the eyes of our accreditors.
>>>
>>
>> eh? Except not. anything on the same lan as the router can pretend to 
>> be said router via both mac address and ip. ip is absolutely not 
>> reliable unless its going over ipsec (in which case you'd just use 
>> ipsec labeling) or the network is completely isolated (in which case 
>> you'd just use interface labeling).
>
> Switches with MAC filters, physical security on the switches and 
> fiber, no IP admin on the switches and alerts when a port gets locked. 
> $$$$ to install and admin.

Yes, I mentioned such switches in a different post. It doesn't matter, 
Paul already convinced me that host based labeling is useful in some 
situations and can be an acceptable risk :) You win.



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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Wednesday, August 29 2007 12:11:14 am Joshua Brindle wrote:
> Ok, I think my brain is still catching up on this thread.

My brain gave up quite a while ago ... it's just nerves banging away at the 
keyboard now :)

> Because of 
> what I said above I think we should 1) not do node based fallbacks and
> 2) not do nic alias-level fallbacks. This is the safe option (as already
> pointed out) and minimizes trust in untrustworthy things (eg., addresses
> coming from the network).
>
> OTOH it may make some peoples lives easier to allow this. It is a false
> sense of security though so I vote for doing nic level fallbacks only
> and if someone *really* wants to do this they can just plug several nics
> into the same network (hopefully they'd recognize the horrible things
> they are doing if it is explicit like that).
>
> It sounds like the decision is still up in the air though, does anyone
> inherently disagree with me here?

I guess every decision is technically up in the air until the changes/patches 
are included in a released kernel, however, I'm pretty confident that host 
level granularity of both fallback labels and flow control peer label 
filtering is "the right thing".

I understand your point about not extending trust beyond the level of the 
physical wire, that is very easy to rationalize/understand.  However, from a 
practical real-world scenario (see my home network behind a NAT box example, 
as well as others) I think there is real value in extending the labeling 
beyond the wire to the host/network level.  SELinux has always made some 
allowances to facilitate adoption and ease of use, i.e. unconfined_t, but has 
been careful to make sure that these concessions were always at the 
discretion of the system administrator.  Fallback labeling and peer flow 
controls are configuration options which are only available to the system 
administrator and providing host level granularity can be a significant 
benefit to a lot of people.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Paul Moore wrote:
> On Wednesday, August 29 2007 12:11:14 am Joshua Brindle wrote:
>   
>> Ok, I think my brain is still catching up on this thread.
>>     
>
> My brain gave up quite a while ago ... it's just nerves banging away at the 
> keyboard now :)
>
>   
>> Because of 
>> what I said above I think we should 1) not do node based fallbacks and
>> 2) not do nic alias-level fallbacks. This is the safe option (as already
>> pointed out) and minimizes trust in untrustworthy things (eg., addresses
>> coming from the network).
>>
>> OTOH it may make some peoples lives easier to allow this. It is a false
>> sense of security though so I vote for doing nic level fallbacks only
>> and if someone *really* wants to do this they can just plug several nics
>> into the same network (hopefully they'd recognize the horrible things
>> they are doing if it is explicit like that).
>>
>> It sounds like the decision is still up in the air though, does anyone
>> inherently disagree with me here?
>>     
>
> I guess every decision is technically up in the air until the changes/patches 
> are included in a released kernel, however, I'm pretty confident that host 
> level granularity of both fallback labels and flow control peer label 
> filtering is "the right thing".
>
> I understand your point about not extending trust beyond the level of the 
> physical wire, that is very easy to rationalize/understand.  However, from a 
> practical real-world scenario (see my home network behind a NAT box example, 
> as well as others) I think there is real value in extending the labeling 
> beyond the wire to the host/network level.  SELinux has always made some 
> allowances to facilitate adoption and ease of use, i.e. unconfined_t, but has 
> been careful to make sure that these concessions were always at the 
> discretion of the system administrator.  Fallback labeling and peer flow 
> controls are configuration options which are only available to the system 
> administrator and providing host level granularity can be a significant 
> benefit to a lot of people.
>   

concessions are fine when the ramifications are understood, unconfined_t 
is pretty obvious. But when there are security people that believe host 
based labeling buys anything then it may be an inappropriate concession. 
I mean, if I can get on your network and in a matter of seconds take 
over both your IP and MAC address it isn't good. Worse, I could use 
something like ettercap and MiM you without you even knowing (and even 
inject data into the stream).

The last email from Joe shows that even security centric people are fine 
with this situation in a 'medium assurance' environment, if medium 
assurance means trivially bypassable please count me out. A single 
shared network is in no way medium assurance IMO, there is no inherent 
security when you are on a single network (save for fancy switches that 
do mac filtering and ip locking per port, how many people actually use 
those features though).

One interesting thing that just occurred to me is vlans. I'm not sure 
how vlans are implemented on Linux (do they get their own interface 
names?) but they are much better than the alternative which lets anyone 
do anything on a single network.


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Wednesday, August 29 2007 10:26:55 am Joshua Brindle wrote:
> Paul Moore wrote:
> > On Wednesday, August 29 2007 12:11:14 am Joshua Brindle wrote:
> >> Because of
> >> what I said above I think we should 1) not do node based fallbacks and
> >> 2) not do nic alias-level fallbacks. This is the safe option (as already
> >> pointed out) and minimizes trust in untrustworthy things (eg., addresses
> >> coming from the network).
> >>
> >> OTOH it may make some peoples lives easier to allow this. It is a false
> >> sense of security though so I vote for doing nic level fallbacks only
> >> and if someone *really* wants to do this they can just plug several nics
> >> into the same network (hopefully they'd recognize the horrible things
> >> they are doing if it is explicit like that).
> >>
> >> It sounds like the decision is still up in the air though, does anyone
> >> inherently disagree with me here?
> >
> > I guess every decision is technically up in the air until the
> > changes/patches are included in a released kernel, however, I'm pretty
> > confident that host level granularity of both fallback labels and flow
> > control peer label filtering is "the right thing".
> >
> > I understand your point about not extending trust beyond the level of the
> > physical wire, that is very easy to rationalize/understand.  However,
> > from a practical real-world scenario (see my home network behind a NAT
> > box example, as well as others) I think there is real value in extending
> > the labeling beyond the wire to the host/network level.  SELinux has
> > always made some allowances to facilitate adoption and ease of use, i.e.
> > unconfined_t, but has been careful to make sure that these concessions
> > were always at the discretion of the system administrator.  Fallback
> > labeling and peer flow controls are configuration options which are only
> > available to the system administrator and providing host level
> > granularity can be a significant benefit to a lot of people.
>
> concessions are fine when the ramifications are understood, unconfined_t
> is pretty obvious.

I tend to think host level fallback labels are pretty obvious too, at least as 
obvious as unconfined_t if not more so.  The only way to truly understand the 
ramifications of unconfined_t are to actually look at the policy and examine 
all of the interactions between unconfined_t and all of the types/attributes 
defined in policy.  Short circuiting this by making an assumption based on 
the connotative meaning of the name "unconfined" is just as dangerous, if not 
more so in my opinion, then host level fallbacks.  Explaining the 
ramifications of host level fallback labels are pretty simple, here is my 
quick take:

 "Choosing to enable multiple fallback labels per interface, i.e.
  network or host level fallbacks, can be dangerous as it is possible
  for malicious computers to masquerade as other computers with a
  different fallback label.  Only use network or host level fallback
  labels when you can guarantee the security of the network."

> But when there are security people that believe host 
> based labeling buys anything then it may be an inappropriate concession.

I think the key difference between the two sides here is the acceptable level 
or risk, or the level of assurance.  From what I gather, Joe and the TCS guys 
are deploying systems in installations where they are able to put a fair 
amount of trust in the network such that host level fallback labels do not 
introduce an unacceptable amount of risk.  Your argument assumes a network 
with no trust where host level fallback labels present a very unacceptable 
risk.

Both arguments are correct, the question is what level of functionality do we 
want to provide?

> I mean, if I can get on your network and in a matter of seconds take
> over both your IP and MAC address it isn't good. Worse, I could use
> something like ettercap and MiM you without you even knowing (and even
> inject data into the stream).

Yep, I think we're all familiar with ARP cache poisoning and all the other 
wonderful things you can do the network.

> The last email from Joe shows that even security centric people are fine
> with this situation in a 'medium assurance' environment, if medium
> assurance means trivially bypassable please count me out. A single 
> shared network is in no way medium assurance IMO, there is no inherent
> security when you are on a single network (save for fancy switches that
> do mac filtering and ip locking per port, how many people actually use
> those features though).

I'm making this argument up a bit as I go, so bear with me ...

You essentially define a network by the machines connected to it, which means 
that if you can control the machines on that network then you effectively 
control the network.  Joe is arguing the case for installations where he does 
control all of the machines on the network.

> One interesting thing that just occurred to me is vlans. I'm not sure
> how vlans are implemented on Linux (do they get their own interface
> names?) but they are much better than the alternative which lets anyone
> do anything on a single network.

Like everything else I think this depends on the configuration.  If you have 
multiple vlans on a single wire and unknown machines on that wire than vlan 
separation is no different from IP address separation.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Paul Moore wrote:
> On Wednesday, August 29 2007 10:26:55 am Joshua Brindle wrote:
>   
>> Paul Moore wrote:
>>     
>>> On Wednesday, August 29 2007 12:11:14 am Joshua Brindle wrote:
>>>       
>>>> Because of
>>>> what I said above I think we should 1) not do node based fallbacks and
>>>> 2) not do nic alias-level fallbacks. This is the safe option (as already
>>>> pointed out) and minimizes trust in untrustworthy things (eg., addresses
>>>> coming from the network).
>>>>
>>>> OTOH it may make some peoples lives easier to allow this. It is a false
>>>> sense of security though so I vote for doing nic level fallbacks only
>>>> and if someone *really* wants to do this they can just plug several nics
>>>> into the same network (hopefully they'd recognize the horrible things
>>>> they are doing if it is explicit like that).
>>>>
>>>> It sounds like the decision is still up in the air though, does anyone
>>>> inherently disagree with me here?
>>>>         
>>> I guess every decision is technically up in the air until the
>>> changes/patches are included in a released kernel, however, I'm pretty
>>> confident that host level granularity of both fallback labels and flow
>>> control peer label filtering is "the right thing".
>>>
>>> I understand your point about not extending trust beyond the level of the
>>> physical wire, that is very easy to rationalize/understand.  However,
>>> from a practical real-world scenario (see my home network behind a NAT
>>> box example, as well as others) I think there is real value in extending
>>> the labeling beyond the wire to the host/network level.  SELinux has
>>> always made some allowances to facilitate adoption and ease of use, i.e.
>>> unconfined_t, but has been careful to make sure that these concessions
>>> were always at the discretion of the system administrator.  Fallback
>>> labeling and peer flow controls are configuration options which are only
>>> available to the system administrator and providing host level
>>> granularity can be a significant benefit to a lot of people.
>>>       
>> concessions are fine when the ramifications are understood, unconfined_t
>> is pretty obvious.
>>     
>
> I tend to think host level fallback labels are pretty obvious too, at least as 
> obvious as unconfined_t if not more so.  The only way to truly understand the 
> ramifications of unconfined_t are to actually look at the policy and examine 
> all of the interactions between unconfined_t and all of the types/attributes 
> defined in policy.  Short circuiting this by making an assumption based on 
> the connotative meaning of the name "unconfined" is just as dangerous, if not 
> more so in my opinion, then host level fallbacks.  Explaining the 
> ramifications of host level fallback labels are pretty simple, here is my 
> quick take:
>
>  "Choosing to enable multiple fallback labels per interface, i.e.
>   network or host level fallbacks, can be dangerous as it is possible
>   for malicious computers to masquerade as other computers with a
>   different fallback label.  Only use network or host level fallback
>   labels when you can guarantee the security of the network."
>
>   
>> But when there are security people that believe host 
>> based labeling buys anything then it may be an inappropriate concession.
>>     
>
> I think the key difference between the two sides here is the acceptable level 
> or risk, or the level of assurance.  From what I gather, Joe and the TCS guys 
> are deploying systems in installations where they are able to put a fair 
> amount of trust in the network such that host level fallback labels do not 
> introduce an unacceptable amount of risk.  Your argument assumes a network 
> with no trust where host level fallback labels present a very unacceptable 
> risk.
>
> Both arguments are correct, the question is what level of functionality do we 
> want to provide?
>
>   

Hrm.. I'm not exactly known as the 'practical' SELinux guy.. I suppose 
if the network is completely trusted (which is the same case for CIPSO, 
which we support) and bad guys can't get on said network I guess this 
could be an acceptable risk... *sigh*

>> I mean, if I can get on your network and in a matter of seconds take
>> over both your IP and MAC address it isn't good. Worse, I could use
>> something like ettercap and MiM you without you even knowing (and even
>> inject data into the stream).
>>     
>
> Yep, I think we're all familiar with ARP cache poisoning and all the other 
> wonderful things you can do the network.
>
>   

It was just illustrative.
>> The last email from Joe shows that even security centric people are fine
>> with this situation in a 'medium assurance' environment, if medium
>> assurance means trivially bypassable please count me out. A single 
>> shared network is in no way medium assurance IMO, there is no inherent
>> security when you are on a single network (save for fancy switches that
>> do mac filtering and ip locking per port, how many people actually use
>> those features though).
>>     
>
> I'm making this argument up a bit as I go, so bear with me ...
>
> You essentially define a network by the machines connected to it, which means 
> that if you can control the machines on that network then you effectively 
> control the network.  Joe is arguing the case for installations where he does 
> control all of the machines on the network.
>
>   

Alright, you've convinced me, I won't be opposed to host based labeling 
and if someone is dumb enough to use it in an unsafe way I guess that is 
their fault, not ours :)

>> One interesting thing that just occurred to me is vlans. I'm not sure
>> how vlans are implemented on Linux (do they get their own interface
>> names?) but they are much better than the alternative which lets anyone
>> do anything on a single network.
>>     
>
> Like everything else I think this depends on the configuration.  If you have 
> multiple vlans on a single wire and unknown machines on that wire than vlan 
> separation is no different from IP address separation.
>   

Well, at least with vlans, assuming the switches are doing their job 
(and I'd tend to trust them alot more than Linux) you can't change your 
vlan, you are confined to the vlan the switch gives you, which can 
happen in multiple ways, per port, with x.509 authentication, etc.

unknown machines are still given some vlan by the switch, it could be 
switch port based or just the default for non-configured machines, vlans 
aren't hard to correctly configure in my experience. IMO this is a much 
safer alternative to plain host based labeling, if I have some time 
(haha) I might look at how they are implemented in Linux to see if maybe 
we could leverage their use.


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Wednesday, August 29 2007 11:08:26 am Joshua Brindle wrote:
> Alright, you've convinced me, I won't be opposed to host based labeling
> and if someone is dumb enough to use it in an unsafe way I guess that is
> their fault, not ours :)

Thank you :)

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Paul Moore wrote:
> On Tuesday, August 28 2007 10:58:16 am Darrel Goeddel wrote:
>> Venkat Yekkirala wrote:
>> <snip>
>>
>>>> From: Paul Moore [mailto:paul.moore@hp.com]
>>>> Yes, but you're not really distinguishing between a ssh_t
>>>> peer and a http_t
>>>> peer, e.g. ssh -p 80, which is what troubles me about port
>>>> level granularity.
>>>> I sent another mail earlier which I believe described these
>>>> concerns a bit
>>>> better.
>>> I missed it earlier. We have been brainstorming on this among
>>> myself, Chad and Darrel and our current thinking (assuming I am
>>> putting it forward correctly) is that if one limits trust to the
>>> interface, it actually seems to make sense to allow defaults at
>>> just the interface level and further it seems to make sense to
>>> have the same level of granularity for both the fallback and the
>>> filtering case. At least for MLS, it seems enough to have the ability
>>> to define fallbacks as also perform filtering at just the interface
>>> level. The question to be debated is if for TE, we need granularity
>>> beyond the interface for fallbacks and flow-control.
>> We batted around a bunch of ideas and it almost always seemed that the
>> granularity of fallback labels should match the granularity of the flow
>> control checks.  As Venkat stated, anything past the netif is really
>> extending turst on our part, whether it is for applying a fallback label
>> or performing an access check.  If we apply fallbacks at the host level,
>> we should also allow flow control at the host level.  It doesn't seem to
>> make sense that we would say "info from 1.2.3.4 is SECRET", but not be
>> able to "info going to 1.2.3.4 should be SECRET).  I personally don't
>> see a current need to go past host for either, and even host *could* be
>> argued away in my eyes.  That being said, I would never be opposed to
>> flexibility.
> 
> Hmm, so in summary, you (TCS) don't see a need for flow control of fallback 
> labels with granularity greater then a single host and if really pushed 
> interface level granularity would most likely suffice.  I'll venture that 
> host/network level granularity might be nice for normal users who only have 
> one interface which connects to multiple networks, e.g. the person sitting at 
> home on a private home network which also connects to the big-bad-internet 
> via a nat box provided by their ISP.

I don't see the need for the granularity of flow control mechanisms to 
go beyond the host level.  I also don't see the need to apply fallback 
labels at a granularity greater than host level.  Note that they are 
separate items, not just flow control for fallback labels (as phrased in 
your response), but flow control for all labels.

I agree that the ability to define fallback labels at the host level is 
useful as well, just not absolutely *necessary* (so they are still 
debatable).  Seems easy enough, so we should probably do it.  The only 
really super cool thing with netif only fallback labels and flow checks 
is that the netif rules (unused in the non-compat_net case) already have 
an interface label and a msg label.  Oh the possibilities...

> This now has me rethinking the need for a full featured netfilter based 
> mechanism for flow control (SECFILTER).  I'm wondering if we would be better 
> served by simple hooks in the network device layer for in/out and possible 
> forward.  As James pointed out in the off-list discussion, the whole 
> netfilter mechanism seems like a bit much for what we actually need.

I agree here as well.  It was necessary when I was talking about 
"re-purposing" SECMARK, but not that SECMARK makes it though unscathed, 
I'm not sure it is necessary (hopefully I won't have an epiphany after 
hitting send...).  However, if we are assigning fallback labels at a 
host level granularity, should we restrict flow at the same level?  If 
so, is the iptables mechanism the easiest route (the default unlabeled 
check cimplicates this), or would we want to do a netif flow check and a 
host flow check (using the existing nodecon rules?).

As long as forwarded traffic hit both the in and out flow checks, I 
don't think we need a separate forward check.  The forward check would 
really have to be one of those weird "triplet" checks that would take in 
the peer label, the incoming interface label, and the outgoing interface 
label.  The flow_out check is obvious in postroute_last.  We have a spot 
around xfrm_policy_check where the flow_in check fits nicely and catches 
forwarded traffic as well as locally bound traffic.

>> NOTE that I said almost in my first sentence...  The only "opposing"
>> scenario that seemed intuitive to me was apply fallbacks using
>> network/netmask only and apply flow checks at interface only.  An
>> example of operation would be:
>>
>> netif access rules:
>> eth1	SECRET	10.0.1.0/24
>> eth2	TS	10.0.2.0/24
>>
>> host fallback labels:
>> 10.0.1.100/32	SYSHI
>> 10.0.1.0/24	SECRET
>> 10.0.2.0/24	TS
>>
>> That CON host would obviously get denied coming in if it was not using
>> some on-the-wire labeling because it would be assigned a label of SYSHI,
>> which would be blocked at the netif flow check.  I'm sure something is
>> wrong with the host label/netif access check idea, but I can't put my
>> finger on it...  Too much trust in the IP address and routing?
> 
> Well, we kinda have to trust that IP works correctly as it is beyond our 
> control - we only get to effect the box, not the networks it attached to.  If 
> you can't trust the network make use of something like IPsec which can at 
> least provide you data confidentiality/integrity/auth.
> 
>> Paul, why the netif/host combo in the original netlabel fallback patch?
>>   Why not just hosts (or really network/netmask)?
> {patched in from the other email}
>> Can we make the netif optional or add a wildcard netif?  That would allow
>> for a truly generic fallback if desired.  Currently if you add a new
>> interface, you need to go back and add a new rule (I think, could be wrong
>> since I haven't actually tried it). 
> 
> Sure, I can add a default netif which is used if a match isn't found.  I 
> originally considered adding one (the NetLabel domain mapping mechanism has a 
> default rule match) but it seemed a little "dangerous" at the time, although 
> I think I was just being too cautious.

Cool.  That would give the flexibility to define netif only based 
fallbacks (using 0.0.0.0/0) and host only fallbacks (using the defalut 
if) or some combo of the two.

eth0:0.0.0.0/0		confidential
eth1:0.0.0.0/0		secret
eth2:0.0.0.0/0		ts
any:0.0.0.0/0		systemhigh

or...

any:10.0.1.0/24		confidential
any:10.0.2.0/24		secret
any:10.0.3.0/24		ts
any:0.0.0.0/0		systemhigh

That would work, right?

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Tuesday, August 28 2007 1:23:40 pm Darrel Goeddel wrote:
> Paul Moore wrote:
> > Hmm, so in summary, you (TCS) don't see a need for flow control of
> > fallback labels with granularity greater then a single host and if really
> > pushed interface level granularity would most likely suffice.  I'll
> > venture that host/network level granularity might be nice for normal
> > users who only have one interface which connects to multiple networks,
> > e.g. the person sitting at home on a private home network which also
> > connects to the big-bad-internet via a nat box provided by their ISP.
>
> I don't see the need for the granularity of flow control mechanisms to
> go beyond the host level.  I also don't see the need to apply fallback
> labels at a granularity greater than host level.  Note that they are
> separate items, not just flow control for fallback labels (as phrased in
> your response), but flow control for all labels.

Yes, that was a typo/braino what I mean to say was "... you (TCS) don't see a 
need for flow control _or_ [not "of"] fallback labels ..."

> > This now has me rethinking the need for a full featured netfilter based
> > mechanism for flow control (SECFILTER).  I'm wondering if we would be
> > better served by simple hooks in the network device layer for in/out and
> > possible forward.  As James pointed out in the off-list discussion, the
> > whole netfilter mechanism seems like a bit much for what we actually
> > need.
>
> I agree here as well.  It was necessary when I was talking about
> "re-purposing" SECMARK, but not that SECMARK makes it though unscathed,
> I'm not sure it is necessary (hopefully I won't have an epiphany after
> hitting send...).  However, if we are assigning fallback labels at a
> host level granularity, should we restrict flow at the same level?

I think leaving flow control with host level granularity makes sense, actually 
I think interface level is probably "safe" but host level granularity may 
make it easier to apply the controls to a more general case.

> If 
> so, is the iptables mechanism the easiest route (the default unlabeled
> check cimplicates this), or would we want to do a netif flow check and a
> host flow check (using the existing nodecon rules?).

I'm almost certain netfilter/iptables is more than we need here and drags a 
unnecessary dependency into the mix.  How we go about defining the 
relationship in policy (netif/nodecon or something new?) is something we 
should discuss with the policy folks before settling on anything.

> As long as forwarded traffic hit both the in and out flow checks, I
> don't think we need a separate forward check.  The forward check would
> really have to be one of those weird "triplet" checks that would take in
> the peer label, the incoming interface label, and the outgoing interface
> label.

Yes, like we discussed earlier, the only real reason I can see for having a 
forwarding hook is if we needed for on-the-wire labeling.  An access check 
here doesn't sound like it would be serving any real need.

> The flow_out check is obvious in postroute_last.  We have a spot 
> around xfrm_policy_check where the flow_in check fits nicely and catches
> forwarded traffic as well as locally bound traffic.

That's good.  I like it when we can do things without adding new hooks, it 
keeps the netdev people from throwing stuff ;)

> >> Can we make the netif optional or add a wildcard netif?  That would
> >> allow for a truly generic fallback if desired.  Currently if you add a
> >> new interface, you need to go back and add a new rule (I think, could be
> >> wrong since I haven't actually tried it).
> >
> > Sure, I can add a default netif which is used if a match isn't found.  I
> > originally considered adding one (the NetLabel domain mapping mechanism
> > has a default rule match) but it seemed a little "dangerous" at the time,
> > although I think I was just being too cautious.
>
> Cool.  That would give the flexibility to define netif only based
> fallbacks (using 0.0.0.0/0) and host only fallbacks (using the defalut
> if) or some combo of the two.
>
> eth0:0.0.0.0/0		confidential
> eth1:0.0.0.0/0		secret
> eth2:0.0.0.0/0		ts

This you can do now (it works for IPv6 too) ...

> any:0.0.0.0/0		systemhigh

... but not this ...

> any:10.0.1.0/24		confidential
> any:10.0.2.0/24		secret
> any:10.0.3.0/24		ts
> any:0.0.0.0/0		systemhigh

... or this ...

> That would work, right?

... as soon as I can make the changes.  It seems that lately I've been 
spending almost all of my time typing into my email client and not my 
editor :)  (I'm not complaining, we're having a good discussion here, I just 
look forward to actually acting on 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.

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> 
> Actually, after reading Josh's mail I'm now thinking 
> "netfilter label" is 
> probably a better choice.  After all, the bikeshed will need 
> to be repainted 
> in a few years ... ;)

I like "netfilter label" as well (I take it most admins know what
netfilter is; otherwise firewall label?)

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Monday, August 27 2007 9:02:32 am Venkat Yekkirala wrote:
> > Actually, after reading Josh's mail I'm now thinking
> > "netfilter label" is
> > probably a better choice.  After all, the bikeshed will need
> > to be repainted
> > in a few years ... ;)
>
> I like "netfilter label" as well (I take it most admins know what
> netfilter is; otherwise firewall label?)

I like both "firewall" and "netfilter" label.  I'm tempted to stick 
with "netfilter label" for right now simply because it better matches it up 
with the kernel mechanism that assigns the label.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> > What do other people think?  I know you've got an opinion Casey ...

Might I add "firewall" label?

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> > It makes me uncomfortable to hear you say that XFRM is 
> SELinux specific
> > and that it needs to be integrated with NetLabel, which 
> currently isn't.
> > I know that Smack isn't upstream yet. Nonetheless, I would 
> hate to see
> > underlying mechanisms that currently provide useful 
> facilities become
> > SELinux specific.
> >   
> 
> Joy will know better but I don't think there is anything 
> really SELinux 
> specific about XRFM. As far as the racoon support goes it just 
> serializes and sends over a string context, algorithm and 
> DOI.

This is correct.

> The LSM 
> would responsible for verifying the context when it is set. One thing 
> you'd have to figure out as an LSM writer is how to reconcile 
> multiple 
> incoming labels, much like we are trying to do right now. There are 
> already function pointers in the security_ops struct for 
> managing xfrm 
> security data, it shouldn't be any problem for you to use them.

Right.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
> Sent: Friday, August 24, 2007 11:31 AM
> To: selinux@tycho.nsa.gov
> Cc: James Morris; Darrel Goeddel; Stephen Smalley; 
> kaigai@ak.jp.nec.com;
> joe@nall.com; Eric Paris
> Subject: Re: [RFC 0/5] Static/fallback external labels for NetLabel
> 
> 
> For those of you who are still paying attention to this 
> thread you may have 
> been wondering why it went quiet all of a sudden; well, the 
> thread didn't go 
> quiet, it went off-list.  Needless to say, we'd like to bring 
> the discussion 
> back on-list so that others can participate, or at the very 
> least get some 
> cheap entertainment on a Friday afternoon.  The discussion 
> was pretty lively 
> so it's not really practical to replay the entire off-list 
> thread here but 
> I'll try to hit upon where we are currently at as well as some of the 
> highlights that brought us to this point.
> 
> If anyone who was a part of the discussion has anything to 
> add to these notes, 
> feel free.
> 
>  * Packet labels (one or two)
> 
> There was quite a bit of debate about the possibility of 
> going from the two 
> packet labels we have currently, external and internal, to a 
> single packet 
> label.  In order to consolidate the two labels there were two 
> approaches 
> considered: a form of "reconciliation" similar to what was 
> discussed earlier 
> this year, and the elimination of internal labels so that 
> only the external 
> label would be used.  After much discussion it was deemed 
> that the two 
> labels, as currently defined/used, are truly independent 
> labels used for two 
> different purposes and that "reconciliation" was still a bad 
> idea and should 
> not be pursued.  Further, while SECMARK and internal labeling 
> have been slow 
> to be adopted in the major distributions it still serves a 
> useful purpose and 
> should not be eliminated.  The end result was the majority, 
> including Stephen 
> and James, voting to continue with the two packet labels as 
> they currently 
> exist.
> 
> One thing that did arise during the discussion was the slow 
> realization that 
> the names for the two packet labels are probably not as 
> descriptive as they 
> should be and that has most likely led to a certain amount of 
> confusion.  In 
> an effort to help make the two different label types more 
> clear it was 
> decided to start calling the external labels "peer labels" as 
> the external 
> label always represents the label of the peer who originated 
> the packet and 
> it's data.  It was also decided to start calling the internal 
> labels "secmark 
> labels", while the compat_net mechanism still exists it is 
> deprecated in 
> favor of the SECMARK mechanism which is the only way to 
> set/manipulate the 
> internal label.
> 
> As a reminder, below is a definition of the two types of labels.
> 
> Secmark, or internal, labels are essentially a means for 
> integrating the 
> traditional firewall rules with SELinux mandatory access 
> controls.  The 
> secmark labels allow policy writers and security 
> administrators to meet 
> security goals similar to the following:
>  "Only allow Apache to accept connections over tcp/80 from 
>   192.168.0.0/24, restricting it to my local network and not
>   the Big-Bad-Internet."
>  -- or --
>  "Only allow a particular instance of Firefox to connect to
>   1.2.3.4 over tcp/443, restricting it to my online banking
>   site."
> 
> Peer, or external, labels, furnished by NetLabel or labeled 
> IPsec/XFRM, 
> provide the domain/context/label of the process which generated the 
> packet/data.  The external labels allow policy writers and security 
> administrators to meet security goals similar to the following:
>  "This instance of Apache serves sensitive financial data and
>   I only want specific clients/peers/domains to be able to access
>   the data from this Apache instance."
>  -- or --
>  "I want to ensure that users connecting to the login server over
>   a Secret connection run in a Secret domain."

Good description (and I am finally with you guys here).

> 
>  * Splitting the SECMARK field
> 
> After it was agreed to continue using both the peer and 
> secmark labels the 
> discussion turned to how best to propagate those labels with 
> the packet.  As 
> you probably know there is a 32 bit field already in the 
> packet/sk_buff 
> structure which is currently used exclusively by the secmark 
> label.  Once 
> again, there were two approaches considered.  The first was 
> the continuation 
> of the status quo where the secmark label is determined by 
> looking directly 
> at the secmark field in the sk_buff, "sk_buff.secmark", and 
> the peer label is 
> determined through a function call with the sk_buff as an 
> argument, "peer_label(sk_buff)".

This should be possible, with the obvious drawback that of a
performance overhead of "resolving" all the different "peer"
labels each time we need it (for example at each filter point).

Also, in the forwarding case, while the original xfrm-label should
still be around in the labeled-IPSec to non-labeled-IPSec case, I
would imagine in the NetLabel case, the option field would lose the
"original" label in a DOI gateway instance (if and when NateLabel
does this), right?

>  The second idea was to 
> divide the secmark 
> field in the sk_buff into two 16 bit sub-fields effectively 
> shortening peer 
> and secmark SIDs to 16 bits.

I would vote for this (or some variant). This has 2 advantages:

1. Resolve the external labels just once and plant it in the
   split secmark.

2. Also use this for a loopback packet labeling (as also pointed
   out by you later).

> 
> While there is still no final agreement on the best way 
> forward, there does 
> seem to be agreement that the split secmark field offers a 
> good deal of 
> implementation convenience/cleanliness but it requires either 
> a reduction in 
> the system's SID space from 32 bits to 16 bits (4.<mumble> 
> billion unique 
> labels down to 65 thousand unique labels for all 
> subjects/objects on the 
> system) or some sort of additional internal SID mapping 
> mechanism which has 
> yet to be defined.  Both of which have the potential for introducing 
> compatibility problems.
> 
>  * Loopback/Localhost peer packet labeling
> 
> This has been a long standing requirement which at first 
> glance seems like it 
> would be simple to achieve but in practice it has proven 
> quiet difficult to 
> implement.  Current solutions to the problem involve using either 
> NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, 
> unfortunately both have drawbacks.  NetLabel/CIPSO is 
> currently limited to 
> only conveying the MLS sensitivity label over the wire and 
> only then for IPv4 
> packets.

This can perhaps be worked-around by passing the sid verbatim
using a special IP option (I believe suggested by Pete looking
at the Symposium minutes).

>  Labeled IPsec can convey the full SELinux 
> label/context of the peer 
> for both IPv4 and IPv6 but is difficult to configure and introduces 
> unnecessary overhead for packets that never leave the machine.

(snip)

>  * Packet flow control
> 
> Another long standing goal that has not seen much success 
> over the years.  The 
> two approaches currently being considered are: per-interface 
> checks against 
> the peer label with the possibility of an additional 
> forwarding hook/check if 
> needed for labeling purposes, as well as an iptables based filtering 
> mechanism which has already been discussed off and on on the 
> public SELinux 
> and LSPP mailing lists (SECFILTER/SECPOINT).  The idea behind 
> the iptables 
> based filtering mechanism is that "filter points" could be 
> defined using 
> iptables/netfilter which would provide very granular access 
> control checks.  
> The big question that is currently being debated is how much 
> granularity is 
> needed and how much makes sense? 

I believe this is hard to predict for the general case.

While in some cases you could get away with the use of fine-grained
labeling of packets and then subjecting them to interface-only
controls, I would imagine an approach that can scale from coarse to
granular would make the most sense for the general case.

For the MLS-case, we seem to need at least node-level granularity.

> 
>  * Fallback labels
> 
> The simple idea that started this whole discussion.  The need 
> for a usable 
> peer label fallback mechanism is understood by everyone but 
> the granularity 
> with which peer fallback labels are assigned are still a 
> source of debate.  
> The idea is wether the granularity proposed in this NetLabel 
> patchset which 
> allows per-host/subnet granularity for each interface is 
> enough, and if not 
> is a very granular iptables/netfilter peer label assignment 
> of fallback 
> labels required?  This topic did come up briefly some time 
> ago on the public 
> mailing list between Joshua Brindle and myself and we agreed that the 
> granularity presented in this patchset is sufficient, 
> however, not everyone 
> feels this way so we are still discussing the best solution.

Well, there may be a case, where there's a need to identify an
sshd_t peer different from a httpd_t peer. Or a http_client_t
peer from an rss_aggregator_t peer. Scalability from coarse to
granular should meet the entire spectrum of general cases. 

> 
> As part of the peer fallback label discussion it became 
> apparent to everyone 
> that better integration/cooperation between the NetLabel and 
> XFRM labeling 
> mechanisms is needed.  The strict separation worked well in 
> the beginning but 
> as we start to develop a richer set of functionality the two labeling 
> mechanisms need to work better together to ensure the 
> consistency of the 
> network access controls.  If the approach put forward in this 
> patch set is 
> agreed upon as the right way to solve the peer fallback 
> problem I will be 
> modifying it to take into account XFRM labels so that the 
> NetLabel provided 
> fallback peer label will only be used when there is no XFRM 
> or NetLabel/CIPSO 
> label on the packet.  Further, work will be done to ensure 
> that when both a 
> XFRM and NetLabel/CIPSO label are present on an incoming 
> packet that the 
> labels are the same, otherwise the packet will be dropped/rejected.

Yep.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Monday, August 27 2007 8:44:17 am Venkat Yekkirala wrote:
> >  * Splitting the SECMARK field
> >
> > After it was agreed to continue using both the peer and
> > secmark labels the
> > discussion turned to how best to propagate those labels with
> > the packet.  As
> > you probably know there is a 32 bit field already in the
> > packet/sk_buff
> > structure which is currently used exclusively by the secmark
> > label.  Once
> > again, there were two approaches considered.  The first was
> > the continuation
> > of the status quo where the secmark label is determined by
> > looking directly
> > at the secmark field in the sk_buff, "sk_buff.secmark", and
> > the peer label is
> > determined through a function call with the sk_buff as an
> > argument, "peer_label(sk_buff)".
>
> This should be possible, with the obvious drawback that of a
> performance overhead of "resolving" all the different "peer"
> labels each time we need it (for example at each filter point).

True.

> Also, in the forwarding case, while the original xfrm-label should
> still be around in the labeled-IPSec to non-labeled-IPSec case, I
> would imagine in the NetLabel case, the option field would lose the
> "original" label in a DOI gateway instance (if and when NateLabel
> does this), right?

Yes, once you change the packet's label on the wire you have to potential to 
change the packet's label.  However, simply changing the label to reflect a 
different CIPSO DOI (I assume that is the DOI you were talking about?) 
shouldn't change the NetLabel/CIPSO label as seen by SELinux since the only 
thing the on-the-wire label translation would be doing is translating the 
label between two different security domains/DOIs, the semantic value of the 
label should be preserved.

I would consider removing the NetLabel/CIPSO label from a packet to be the 
same as relabeling a packet to unlabeled_t and I still believe that the 
kernel should not get involved in packet relabeling at this point, leave that 
up to userspace.

> >  The second idea was to
> > divide the secmark
> > field in the sk_buff into two 16 bit sub-fields effectively
> > shortening peer
> > and secmark SIDs to 16 bits.
>
> I would vote for this (or some variant). This has 2 advantages:
>
> 1. Resolve the external labels just once and plant it in the
>    split secmark.
>
> 2. Also use this for a loopback packet labeling (as also pointed
>    out by you later).

I'm slowly warming up to the idea of splitting the secmark field, although I 
still remain very concerned about the long term effects and compatibility 
issues.  Yes, there is the potential for a network SID mapper but I'm not 
very excited about that idea right now.  I guess what I'd like to see is 
something similar to the change below go through a few iterations of testing 
before we make up our minds.  We'd also need to entire SELinux braintrust to 
agree to the idea, and aside from Stephen and James, I'm not sure they are 
still reading this thread.

Index: linux-2.6_misc/security/selinux/ss/sidtab.c
===================================================================
--- linux-2.6_misc.orig/security/selinux/ss/sidtab.c
+++ linux-2.6_misc/security/selinux/ss/sidtab.c
@@ -212,7 +212,7 @@ int sidtab_context_to_sid(struct sidtab
                if (sid)
                        goto unlock_out;
                /* No SID exists for the context.  Allocate a new one. */
-               if (s->next_sid == UINT_MAX || s->shutdown) {
+               if (s->next_sid > 0x0000ffff || s->shutdown) {
                        ret = -ENOMEM;
                        goto unlock_out;

Let's figure out what we need for flow control and forwarding and then we can 
start a separate thread regarding 16 bit SIDs to get everyone's attention.

> >  * Loopback/Localhost peer packet labeling
> >
> > This has been a long standing requirement which at first
> > glance seems like it
> > would be simple to achieve but in practice it has proven
> > quiet difficult to
> > implement.  Current solutions to the problem involve using either
> > NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
> > unfortunately both have drawbacks.  NetLabel/CIPSO is
> > currently limited to
> > only conveying the MLS sensitivity label over the wire and
> > only then for IPv4
> > packets.
>
> This can perhaps be worked-around by passing the sid verbatim
> using a special IP option (I believe suggested by Pete looking
> at the Symposium minutes).

Yep, this is basically the idea behind Selopt or similar.

> >  * Packet flow control
> >
> > Another long standing goal that has not seen much success
> > over the years.  The
> > two approaches currently being considered are: per-interface
> > checks against
> > the peer label with the possibility of an additional
> > forwarding hook/check if
> > needed for labeling purposes, as well as an iptables based filtering
> > mechanism which has already been discussed off and on on the
> > public SELinux
> > and LSPP mailing lists (SECFILTER/SECPOINT).  The idea behind
> > the iptables
> > based filtering mechanism is that "filter points" could be
> > defined using
> > iptables/netfilter which would provide very granular access
> > control checks.
> > The big question that is currently being debated is how much
> > granularity is
> > needed and how much makes sense?
>
> I believe this is hard to predict for the general case.

Yep, I believe you're right and the fact that this discussion has gone on for 
quite some time without any real obvious answer makes me think we won't 
arrive at one.  In that case, I guess we should just provide the most 
granularity possible and let the admins sort it out (the SECFILTER idea).

As far as I can tell there is still one important issue we need to resolve - 
how to introduce new packet access checks without causing a regression for 
users with older policy.  This of course is tied to the desire to have a 
default/unlabeled_t packet access check in the case where the admin has not 
explicitly setup any SECFILTER points/gates/etc.  Can we live without a 
default check?  It certainly makes the implementation cleaner and the 
compatibility issues less of a concern.  Thoughts?

> >  * Fallback labels
> >
> > The simple idea that started this whole discussion.  The need
> > for a usable
> > peer label fallback mechanism is understood by everyone but
> > the granularity
> > with which peer fallback labels are assigned are still a
> > source of debate.
> > The idea is wether the granularity proposed in this NetLabel
> > patchset which
> > allows per-host/subnet granularity for each interface is
> > enough, and if not
> > is a very granular iptables/netfilter peer label assignment
> > of fallback
> > labels required?  This topic did come up briefly some time
> > ago on the public
> > mailing list between Joshua Brindle and myself and we agreed that the
> > granularity presented in this patchset is sufficient,
> > however, not everyone
> > feels this way so we are still discussing the best solution.
>
> Well, there may be a case, where there's a need to identify an
> sshd_t peer different from a httpd_t peer. Or a http_client_t
> peer from an rss_aggregator_t peer. Scalability from coarse to
> granular should meet the entire spectrum of general cases.

Yes, but you're not really distinguishing between a ssh_t peer and a http_t 
peer, e.g. ssh -p 80, which is what troubles me about port level granularity.  
I sent another mail earlier which I believe described these concerns a bit 
better.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

> -----Original Message-----
> From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com]
> Sent: Friday, August 24, 2007 12:37 PM
> To: Paul Moore; selinux@tycho.nsa.gov
> Cc: James Morris; Darrel Goeddel; Stephen Smalley; 
> kaigai@ak.jp.nec.com;
> joe@nall.com; Eric Paris
> Subject: RE: [RFC 0/5] Static/fallback external labels for NetLabel
> 
> 
> I will go ahead and offer my comments to the below in my
> personal capacity.
> 
> > -----Original Message-----
> > From: Paul Moore [mailto:paul.moore@hp.com]
> (snip)
> > As a reminder, below is a definition of the two types of labels.
> > 
> > Secmark, or internal, labels are essentially a means for 
> > integrating the 
> > traditional firewall rules with SELinux mandatory access 
> > controls.  The 
> > secmark labels allow policy writers and security 
> > administrators to meet 
> > security goals similar to the following:
> >  "Only allow Apache to accept connections over tcp/80 from 
> >   192.168.0.0/24, restricting it to my local network and not
> >   the Big-Bad-Internet."
> >  -- or --
> >  "Only allow a particular instance of Firefox to connect to
> >   1.2.3.4 over tcp/443, restricting it to my online banking
> >   site."
> > 
> 
> Secmark is currently playing the role of arbitrating between
> a socket and a packet, based on the internal knowledge of the
> packet. I don't see why this "internal" label of the packet
> couldn't be the internally defined peer label that MUST be
> the same as any external peer label coming in with the packet.
> 
> Thus the current socket Vs. packet.recv check would be 
> retained intact.
> 
> For the outgoing, the packet would get it's label from the socket
> and then the check would whether the label on the packet matches
> the "internally" defined "local" label. There can further be a
> socket Vs. packet.send, but this will typically boil down to
> can a httpd_t socket send a httpd_t packet (if and when the
> ability to write a packet to a socket with a label different
> from the socket's, the target of the check would then be
> that label).
> 
> Essentially, the following characterization:
> 
> One would define what peers are "expected" to come in with what
> characteristics using iptables selectors. Similarly, one would
> define what local domains are expected to go out with what
> characteristics using iptables selectors. A label coming in with
> a packet MUST match the "expected" label or the packet will 
> be dropped.
> For the outgoing also, a packet's label (domain label from the socket)
> MUST match the "expected" label (defined using iptables 
> selectors) or the
> packet will be dropped.
> 
> We also inherently have flow control in the above.

Also, this doesn't mean we couldn't have additional flow control
at the interface or node levels for added assurance and to meet
controlled interface requirements. Its just that even without these
additional flow-controls, we do have flow-control for forwarded packets
built-in.

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

RE: [RFC 0/5] Static/fallback external labels for NetLabel

[Venkat Yekkirala]

I will go ahead and offer my comments to the below in my
personal capacity.

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
(snip)
> As a reminder, below is a definition of the two types of labels.
> 
> Secmark, or internal, labels are essentially a means for 
> integrating the 
> traditional firewall rules with SELinux mandatory access 
> controls.  The 
> secmark labels allow policy writers and security 
> administrators to meet 
> security goals similar to the following:
>  "Only allow Apache to accept connections over tcp/80 from 
>   192.168.0.0/24, restricting it to my local network and not
>   the Big-Bad-Internet."
>  -- or --
>  "Only allow a particular instance of Firefox to connect to
>   1.2.3.4 over tcp/443, restricting it to my online banking
>   site."
> 

Secmark is currently playing the role of arbitrating between
a socket and a packet, based on the internal knowledge of the
packet. I don't see why this "internal" label of the packet
couldn't be the internally defined peer label that MUST be
the same as any external peer label coming in with the packet.

Thus the current socket Vs. packet.recv check would be retained intact.

For the outgoing, the packet would get it's label from the socket
and then the check would whether the label on the packet matches
the "internally" defined "local" label. There can further be a
socket Vs. packet.send, but this will typically boil down to
can a httpd_t socket send a httpd_t packet (if and when the
ability to write a packet to a socket with a label different
from the socket's, the target of the check would then be
that label).

Essentially, the following characterization:

One would define what peers are "expected" to come in with what
characteristics using iptables selectors. Similarly, one would
define what local domains are expected to go out with what
characteristics using iptables selectors. A label coming in with
a packet MUST match the "expected" label or the packet will be dropped.
For the outgoing also, a packet's label (domain label from the socket)
MUST match the "expected" label (defined using iptables selectors) or the
packet will be dropped.

We also inherently have flow control in the above.

> Peer, or external, labels, furnished by NetLabel or labeled 
> IPsec/XFRM, 
> provide the domain/context/label of the process which generated the 
> packet/data.  The external labels allow policy writers and security 
> administrators to meet security goals similar to the following:
>  "This instance of Apache serves sensitive financial data and
>   I only want specific clients/peers/domains to be able to access
>   the data from this Apache instance."
>  -- or --
>  "I want to ensure that users connecting to the login server over
>   a Secret connection run in a Secret domain."
> 
>  * Splitting the SECMARK field

Having a single label for a packet, essentially, the label of the
data contained in the packet, would greatly simplify things and
IMHO easier to understand.

(snip)

>  * Packet flow control
> 
> Another long standing goal that has not seen much success 
> over the years.  The 
> two approaches currently being considered are: per-interface 
> checks against 
> the peer label with the possibility of an additional 
> forwarding hook/check if 
> needed for labeling purposes, as well as an iptables based filtering 
> mechanism which has already been discussed off and on on the 
> public SELinux 
> and LSPP mailing lists (SECFILTER/SECPOINT).  The idea behind 
> the iptables 
> based filtering mechanism is that "filter points" could be 
> defined using 
> iptables/netfilter which would provide very granular access 
> control checks.  
> The big question that is currently being debated is how much 
> granularity is 
> needed and how much makes sense? 

See the above.

> 
>  * Fallback labels
> 
> The simple idea that started this whole discussion.  The need 
> for a usable 
> peer label fallback mechanism is understood by everyone but 
> the granularity 
> with which peer fallback labels are assigned are still a 
> source of debate.  
> The idea is wether the granularity proposed in this NetLabel 
> patchset which 
> allows per-host/subnet granularity for each interface is 
> enough, and if not 
> is a very granular iptables/netfilter peer label assignment 
> of fallback 
> labels required?  This topic did come up briefly some time 
> ago on the public 
> mailing list between Joshua Brindle and myself and we agreed that the 
> granularity presented in this patchset is sufficient, 
> however, not everyone 
> feels this way so we are still discussing the best solution.

I am one of those that feel that non-granular fallbacks would
be restrictive enough for the general case. We would essentially
need per interface/node/port granularity, which is easily
accomplished via iptables.

> 
> As part of the peer fallback label discussion it became 
> apparent to everyone 
> that better integration/cooperation between the NetLabel and 
> XFRM labeling 
> mechanisms is needed.  The strict separation worked well in 
> the beginning but 
> as we start to develop a richer set of functionality the two labeling 
> mechanisms need to work better together to ensure the 
> consistency of the 
> network access controls.  If the approach put forward in this 
> patch set is 
> agreed upon as the right way to solve the peer fallback 
> problem I will be 
> modifying it to take into account XFRM labels so that the 
> NetLabel provided 
> fallback peer label will only be used when there is no XFRM 
> or NetLabel/CIPSO 
> label on the packet.  Further, work will be done to ensure 
> that when both a 
> XFRM and NetLabel/CIPSO label are present on an incoming 
> packet that the 
> labels are the same, otherwise the packet will be dropped/rejected.

I agree here.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Friday 24 August 2007 1:37:22 pm Venkat Yekkirala wrote:
> >  * Fallback labels
> >
> > The simple idea that started this whole discussion.  The need
> > for a usable
> > peer label fallback mechanism is understood by everyone but
> > the granularity
> > with which peer fallback labels are assigned are still a
> > source of debate.
> > The idea is wether the granularity proposed in this NetLabel
> > patchset which
> > allows per-host/subnet granularity for each interface is
> > enough, and if not
> > is a very granular iptables/netfilter peer label assignment
> > of fallback
> > labels required?  This topic did come up briefly some time
> > ago on the public
> > mailing list between Joshua Brindle and myself and we agreed that the
> > granularity presented in this patchset is sufficient,
> > however, not everyone
> > feels this way so we are still discussing the best solution.
>
> I am one of those that feel that non-granular fallbacks would
> be restrictive enough for the general case. We would essentially
> need per interface/node/port granularity, which is easily
> accomplished via iptables.

Help me understand why including the port is important for selecting a 
fallback label.

If we use the remote peer's port, the source port for the packet, it is going 
to be very hard to create a desired match since in most cases a random, 
ephemeral would be used by the client application.  Using the local 
destination port is probably a bit more reasonable, as well as predictable, 
but it would seem to encourage creating application specific/dependent 
labeling at the system level which I'm not certain is a good idea.  If the 
application needs a specific fallback label to operate, it might be a good 
candidate for providing it's own fallback label when getpeercon() returns an 
error.

However, the thing that concerns me most about allowing fallback label 
selectors to have granularity greater than a single host is that it would 
open the door for misinterpreting a unlabeled/single-label remote peer as 
multi-label remote peer.  I'm still on the fence as if this is really 
important or not, but if there is no compelling reason for offering greater 
than host granularity I'm tempted to vote against it.

I'd really appreciate some scenarios that demonstrate the need for greater 
than host granularity but all I've seen (or can remember right now) so far 
have been use cases that require only host level granularity.  I think it 
would help everyone better understand what we need.

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

[RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

This patchset adds the static/fallback labeling feature to NetLabel that has
been requested on the SELinux mailing list more and more recently.  This new
bit of functionality also matches what can be found on similar trusted/labeled
OSs such as Trusted Solaris, HP-UX CMW, etc.  This patchset it not yet ready
for "upstreaming" so please do not pull this into any tree bound for the
mainline kernel; I still need to do more review and testing of the code.
However, I know there are several of you on this list that have been anxiously
awaiting this patchset so I thought I would make an early release so you could
get a peek and test it out.  I won't be able to work on this patchset much, if
at all, between August 10th and the 20th so don't expect an update from me
until the end of August.

The basic idea is that currently there is no method for providing an external
label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO
or labeled IPsec is not in use.  This patch adds a mechanism for providing a
static fallback label, specified per interface/network, which is used when
a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.

For those of you wishing to try this patchset, it is backed against Linus'
linux-2.6 git tree from the afternoon of August 6th, but I don't imagine you'll
have many problems applying the patchset to later trees at this point in the
2.6.23 release cycle.  In addition to the kernel patches you will also need a
modified version of netlabelctl from the netlabel_tools package.  A very crude
version of the modified tools can be found in the netlabel_tools SVN repository
in the static_label branch.  Please check the NetLabel website on SourceForge,
http://netlabel.sf.net, for information on the SVN repository.  The three new
netlabelctl commands are as follows:

 # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>] label:<LABEL>
 # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
 # netlabelctl -p unlbl list

   DEV = interface, examples: eth0, lo
   ADDR = IP address, examples: 192.168.0.3, ::1
   MASK = IP address mask length, examples 8, 24, 64
   LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2

For example, if you wanted to label all inbound traffic on eth1 from
192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you would
type:

 # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
                         label:system_u:object_r:staticlabel_t:s7

Both IPv4 and IPv6 addresses can be used and if the address mask is ommitted
from the command the address is assumed to be a host address, not a network,
and the maximum mask size for that address family is used.  If you do not wish
to specify an address, simply use a address mask of zero, "/0", which will
cause all addresses within that address family to match.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[KaiGai Kohei]

Paul,

Thanks so much! I was looking forward to your patch set.

I tried to build kernel with the patch and configure a fallbacked label,
but the netlabelctl returns the following error message:

[root@masu ~]# netlabelctl unlbl add interface:eth0 address:192.168.11.0/24 \
>                                    label:system_u:system_r:unconfined_t:s0
netlabelctl: error, invalid argument or parameter
[root@masu ~]# netlabelctl -p unlbl list
Allow unlabeled packets : on
[root@masu ~]#

The kernel config contains CONFIG_NETLABEL=y, and the netlabelctl command
is built from the latest svn repository.
Are any more configurations necessary?

Thanks,

Paul Moore wrote:
> This patchset adds the static/fallback labeling feature to NetLabel that has
> been requested on the SELinux mailing list more and more recently.  This new
> bit of functionality also matches what can be found on similar trusted/labeled
> OSs such as Trusted Solaris, HP-UX CMW, etc.  This patchset it not yet ready
> for "upstreaming" so please do not pull this into any tree bound for the
> mainline kernel; I still need to do more review and testing of the code.
> However, I know there are several of you on this list that have been anxiously
> awaiting this patchset so I thought I would make an early release so you could
> get a peek and test it out.  I won't be able to work on this patchset much, if
> at all, between August 10th and the 20th so don't expect an update from me
> until the end of August.
> 
> The basic idea is that currently there is no method for providing an external
> label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO
> or labeled IPsec is not in use.  This patch adds a mechanism for providing a
> static fallback label, specified per interface/network, which is used when
> a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.
> 
> For those of you wishing to try this patchset, it is backed against Linus'
> linux-2.6 git tree from the afternoon of August 6th, but I don't imagine you'll
> have many problems applying the patchset to later trees at this point in the
> 2.6.23 release cycle.  In addition to the kernel patches you will also need a
> modified version of netlabelctl from the netlabel_tools package.  A very crude
> version of the modified tools can be found in the netlabel_tools SVN repository
> in the static_label branch.  Please check the NetLabel website on SourceForge,
> http://netlabel.sf.net, for information on the SVN repository.  The three new
> netlabelctl commands are as follows:
> 
>  # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>] label:<LABEL>
>  # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
>  # netlabelctl -p unlbl list
> 
>    DEV = interface, examples: eth0, lo
>    ADDR = IP address, examples: 192.168.0.3, ::1
>    MASK = IP address mask length, examples 8, 24, 64
>    LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2
> 
> For example, if you wanted to label all inbound traffic on eth1 from
> 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you would
> type:
> 
>  # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
>                          label:system_u:object_r:staticlabel_t:s7
> 
> Both IPv4 and IPv6 addresses can be used and if the address mask is ommitted
> from the command the address is assumed to be a host address, not a network,
> and the maximum mask size for that address family is used.  If you do not wish
> to specify an address, simply use a address mask of zero, "/0", which will
> cause all addresses within that address family to match.
> 


-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday 09 August 2007 6:57:43 am KaiGai Kohei wrote:
> Thanks so much! I was looking forward to your patch set.
>
> I tried to build kernel with the patch and configure a fallbacked label,
> but the netlabelctl returns the following error message:
>
> [root@masu ~]# netlabelctl unlbl add interface:eth0 address:192.168.11.0/24
>                label:system_u:system_r:unconfined_t:s0
> netlabelctl: error, invalid argument or parameter
>
> The kernel config contains CONFIG_NETLABEL=y, and the netlabelctl command
> is built from the latest svn repository.
> Are any more configurations necessary?

Thanks for taking the time to try it out, sorry it wasn't more successful :/

It looks like you are using the userspace from sources under the "head/" 
directory.  In order to get the new features you need to use the sources 
under the "branches/static_label" directory.

 * http://netlabel.svn.sf.net/viewvc/netlabel/netlabel_tools/branches

I apologize, I probably wasn't as clear about this as I should have been in my 
original posting.

Here are the commands, in order, that I used to fetch and build the 
static_label branch of the netlabel_tools package:

 # svn co https://netlabel.svn.sf.net/svnroot/netlabel netlabel
 # cd netlabel/netlabel_tools/branches/static_label
 # make

If you run into any more problems, or have any questions let me know.

Thanks again for your help.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Tue, 2007-08-07 at 10:14 -0400, Paul Moore wrote:
> This patchset adds the static/fallback labeling feature to NetLabel that has
> been requested on the SELinux mailing list more and more recently.  This new
> bit of functionality also matches what can be found on similar trusted/labeled
> OSs such as Trusted Solaris, HP-UX CMW, etc.  This patchset it not yet ready
> for "upstreaming" so please do not pull this into any tree bound for the
> mainline kernel; I still need to do more review and testing of the code.
> However, I know there are several of you on this list that have been anxiously
> awaiting this patchset so I thought I would make an early release so you could
> get a peek and test it out.  I won't be able to work on this patchset much, if
> at all, between August 10th and the 20th so don't expect an update from me
> until the end of August.
> 
> The basic idea is that currently there is no method for providing an external
> label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO
> or labeled IPsec is not in use.  This patch adds a mechanism for providing a
> static fallback label, specified per interface/network, which is used when
> a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.
> 
> For those of you wishing to try this patchset, it is backed against Linus'
> linux-2.6 git tree from the afternoon of August 6th, but I don't imagine you'll
> have many problems applying the patchset to later trees at this point in the
> 2.6.23 release cycle.  In addition to the kernel patches you will also need a
> modified version of netlabelctl from the netlabel_tools package.  A very crude
> version of the modified tools can be found in the netlabel_tools SVN repository
> in the static_label branch.  Please check the NetLabel website on SourceForge,
> http://netlabel.sf.net, for information on the SVN repository.  The three new
> netlabelctl commands are as follows:
> 
>  # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>] label:<LABEL>
>  # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
>  # netlabelctl -p unlbl list
> 
>    DEV = interface, examples: eth0, lo
>    ADDR = IP address, examples: 192.168.0.3, ::1
>    MASK = IP address mask length, examples 8, 24, 64
>    LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2
> 
> For example, if you wanted to label all inbound traffic on eth1 from
> 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you would
> type:
> 
>  # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
>                          label:system_u:object_r:staticlabel_t:s7
> 
> Both IPv4 and IPv6 addresses can be used and if the address mask is ommitted
> from the command the address is assumed to be a host address, not a network,
> and the maximum mask size for that address family is used.  If you do not wish
> to specify an address, simply use a address mask of zero, "/0", which will
> cause all addresses within that address family to match.

Hi,

I like the functionality, but I don't like having yet another mechanism
and configuration, and I'm concerned about it being netlabel-centric.
Especially when we already have a more generic and flexible mechanism
for specifying packet labels, i.e. secmark.

The only reason to not use secmark today for a fallback mechanism is the
current separation between 'internal' and 'external' labels.  But I
don't believe that separation is necessary or useful, and secmark today
is effectively unused.  The original usage scenario for it simply hasn't
materialized.

Meanwhile, getting secmark employed, not only as a mechanism for
assigning default labels (via iptables rules) but also as a seamless way
of propagating labels with socket buffers would solve a lot of our
current limitations.  We'd get loopback labeling for free, flexible and
generic fallback labeling, forwarding controls would become
straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
NetLabel would benefit from it as well.  There are alternative
implementation approaches, but none as clean and efficient and reliable.
There was a reason we put a sid in the sk_buff in the original SELinux
implementations (prior to Linux 2.6 merge).

I've had some initial discussions with James, and he seemed open to
revisiting this notion, so I think we need to take another look.
  
-- 
Stephen Smalley
National Security Agency


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> I like the functionality, but I don't like having yet another mechanism
> and configuration, and I'm concerned about it being netlabel-centric.

NetLabel has always been designed as a framework to support multiple different 
types of labeling protocols/mechanisms.  Adding this bit of functionality to 
NetLabel isn't a major departure from the existing architecture.  The only 
real substantial changes to the underlying NetLabel framework are the passing 
of the IP address family to some of the NetLabel APIs (minor tweak) and the 
addition of a secid field to the NetLabel security attributes struct (also a 
pretty minor tweak).

I'm also a little confused about your concern over this new feature being 
NetLabel-centric?  I guess I don't understand how that is a problem, further 
explanation might help ...

I understand your concern regarding the additional configuration.  While 
netlabelctl and netlabel_tools are not new, they may be new to users who want 
to make use of this new feature.  On an older thread Josh and I had a bit of 
a discussion regarding this and while we never really arrived at a magic 
solution we did talk about integrating some, or all, of the netlabelctl 
functionality into semanage.  This wouldn't be that difficult as most of 
the "intelligence" in netlabelctl is already in a separate library; adding 
that library to semanage should not be that difficult.  Would that help ease 
your configuration concerns?

> The only reason to not use secmark today for a fallback mechanism is the
> current separation between 'internal' and 'external' labels.  But I
> don't believe that separation is necessary or useful, and secmark today
> is effectively unused.  The original usage scenario for it simply hasn't
> materialized.
>
> Meanwhile, getting secmark employed, not only as a mechanism for
> assigning default labels (via iptables rules) but also as a seamless way
> of propagating labels with socket buffers would solve a lot of our
> current limitations.  We'd get loopback labeling for free, flexible and
> generic fallback labeling, forwarding controls would become
> straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> NetLabel would benefit from it as well.  There are alternative
> implementation approaches, but none as clean and efficient and reliable.
> There was a reason we put a sid in the sk_buff in the original SELinux
> implementations (prior to Linux 2.6 merge).
>
> I've had some initial discussions with James, and he seemed open to
> revisiting this notion, so I think we need to take another look.

I still think merging the two types of packet labels, "internal" 
and "external" is a mistake; I stated my reasoning a few times before so I 
will save people following this thread from reading it again.

However, I agree that packet labeling is in a "weird" state right now and 
there is a lot of room for improvement.  Bearing in mind your comments that 
SECMARK is effectively unused due to lack of demand and that having two types 
of packet labels is not helpful I wonder if the following would a worthwhile 
effort:

 * Do away with internal label concept completely, but leave the SECMARK
   secid field in the sk_buff struct.  This includes removing the SECMARK
   related MAC checks on incoming traffic, whether we bring back compat_net
   or not is not important.
 * Convert the external labeling protocols to make use of the SECMARK secid
   field in the sk_buff struct.  The advantage to NetLabel and explicit
   labeling protocols is really marginal but this should be a huge win for
   labeled IPsec.

As you stated above, there are some obvious advantages here including "free" 
loopback labeling, easier implementation of general iptables forwarding 
controls in the future, as well as some general implementation cleanups in 
the existing code.  If we did decide to go this route, I think I would prefer 
to keep a fallback/static labeling mechanism similar to what is being done in 
this patchset, with the obvious change being made to utilize the new SECMARK 
secid value.  We've seen all of the issues that come to light when we start 
to make use of iptables to set labels on packets and not all of them have 
elegant solutions; one could even argue this is one of the reasons SECMARK as 
an internal label has failed to achieve much use.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > I like the functionality, but I don't like having yet another mechanism
> > and configuration, and I'm concerned about it being netlabel-centric.
> 
> NetLabel has always been designed as a framework to support multiple different 
> types of labeling protocols/mechanisms.  Adding this bit of functionality to 
> NetLabel isn't a major departure from the existing architecture.  The only 
> real substantial changes to the underlying NetLabel framework are the passing 
> of the IP address family to some of the NetLabel APIs (minor tweak) and the 
> addition of a secid field to the NetLabel security attributes struct (also a 
> pretty minor tweak).
> 
> I'm also a little confused about your concern over this new feature being 
> NetLabel-centric?  I guess I don't understand how that is a problem, further 
> explanation might help ...

We want a fallback mechanism that is agnostic to the labeled networking
mechanism.  netlabel may be a "framework" but only for a particular
subset of such mechanisms, i.e. explicit packet labeling.  Putting
functionality into it that should also apply to xfrm labeling is wrong.

> I understand your concern regarding the additional configuration.  While 
> netlabelctl and netlabel_tools are not new, they may be new to users who want 
> to make use of this new feature.  On an older thread Josh and I had a bit of 
> a discussion regarding this and while we never really arrived at a magic 
> solution we did talk about integrating some, or all, of the netlabelctl 
> functionality into semanage.  This wouldn't be that difficult as most of 
> the "intelligence" in netlabelctl is already in a separate library; adding 
> that library to semanage should not be that difficult.  Would that help ease 
> your configuration concerns?

I don't care what we call the userland tool; it is still using
netlabel-specific interfaces and infrastructure.  And re-inventing the
secmark wheel.

> > The only reason to not use secmark today for a fallback mechanism is the
> > current separation between 'internal' and 'external' labels.  But I
> > don't believe that separation is necessary or useful, and secmark today
> > is effectively unused.  The original usage scenario for it simply hasn't
> > materialized.
> >
> > Meanwhile, getting secmark employed, not only as a mechanism for
> > assigning default labels (via iptables rules) but also as a seamless way
> > of propagating labels with socket buffers would solve a lot of our
> > current limitations.  We'd get loopback labeling for free, flexible and
> > generic fallback labeling, forwarding controls would become
> > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > NetLabel would benefit from it as well.  There are alternative
> > implementation approaches, but none as clean and efficient and reliable.
> > There was a reason we put a sid in the sk_buff in the original SELinux
> > implementations (prior to Linux 2.6 merge).
> >
> > I've had some initial discussions with James, and he seemed open to
> > revisiting this notion, so I think we need to take another look.
> 
> I still think merging the two types of packet labels, "internal" 
> and "external" is a mistake; I stated my reasoning a few times before so I 
> will save people following this thread from reading it again.

No one is using the "internal" labels AFAIK, and conceptually, I don't
see a security goal that you would enforce that way that isn't more
cleanly expressed (and more useful) in terms of "external" label.

> However, I agree that packet labeling is in a "weird" state right now and 
> there is a lot of room for improvement.  Bearing in mind your comments that 
> SECMARK is effectively unused due to lack of demand and that having two types 
> of packet labels is not helpful I wonder if the following would a worthwhile 
> effort:
> 
>  * Do away with internal label concept completely, but leave the SECMARK
>    secid field in the sk_buff struct.  This includes removing the SECMARK
>    related MAC checks on incoming traffic, whether we bring back compat_net
>    or not is not important.

Agree with the first part, but not the second.  The secmark packet
checks are actually what we want, with some modification.  IOW, we want
a unified set of checks independent of labeled networking mechanism so
that we can have coherent policy.  And while we do away with any
separate notion of "internal" vs "external", we'd still use iptables
secmark rules to define and apply the fallback labels - that is more
expressive and generic than your approach.

>  * Convert the external labeling protocols to make use of the SECMARK secid
>    field in the sk_buff struct.  The advantage to NetLabel and explicit
>    labeling protocols is really marginal but this should be a huge win for
>    labeled IPsec.

I'm not so sure it is so marginal for netlabel - being able to use a
field from the skb (once initially set for the packet) instead of
inspecting the payload should be a win.

> As you stated above, there are some obvious advantages here including "free" 
> loopback labeling, easier implementation of general iptables forwarding 
> controls in the future, as well as some general implementation cleanups in 
> the existing code.  If we did decide to go this route, I think I would prefer 
> to keep a fallback/static labeling mechanism similar to what is being done in 
> this patchset, with the obvious change being made to utilize the new SECMARK 
> secid value.  We've seen all of the issues that come to light when we start 
> to make use of iptables to set labels on packets and not all of them have 
> elegant solutions; one could even argue this is one of the reasons SECMARK as 
> an internal label has failed to achieve much use.

You'll have to elaborate on that one; defining an iptables rule to apply
a fallback label seems much more general and expressive than the
netlabelctl approach.

-- 
Stephen Smalley
National Security Agency


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday 09 August 2007 9:54:23 am Stephen Smalley wrote:
> On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> > On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > I'm also a little confused about your concern over this new feature being
> > NetLabel-centric?  I guess I don't understand how that is a problem,
> > further explanation might help ...
>
> We want a fallback mechanism that is agnostic to the labeled networking
> mechanism.  netlabel may be a "framework" but only for a particular
> subset of such mechanisms, i.e. explicit packet labeling.  Putting
> functionality into it that should also apply to xfrm labeling is wrong.

I guess this is always going to be a bit of a religious argument then, as I 
tend to think of this feature as a static external label and implementing 
this feature as part of an existing external labeling system/framework makes 
the most sense to me.  Regardless, it's probably best to focus on the other 
issues in this thread, namely what to do with SECMARK, first as that will 
have a huge impact on this topic.

> > I understand your concern regarding the additional configuration.  While
> > netlabelctl and netlabel_tools are not new, they may be new to users who
> > want to make use of this new feature.  On an older thread Josh and I had
> > a bit of a discussion regarding this and while we never really arrived at
> > a magic solution we did talk about integrating some, or all, of the
> > netlabelctl functionality into semanage.  This wouldn't be that difficult
> > as most of the "intelligence" in netlabelctl is already in a separate
> > library; adding that library to semanage should not be that difficult. 
> > Would that help ease your configuration concerns?
>
> I don't care what we call the userland tool; it is still using
> netlabel-specific interfaces and infrastructure.

> And re-inventing the secmark wheel.

Well, only if you redefine SECMARK to a greater scope that what it is used for 
today.  Granted, both this new static/fallback label feature use IP header 
information to derive a packet label but that's about the only similarity I 
see here.  If we do decide to redefine SECMARK then you'll be correct, no 
need for this patchset.

> > > The only reason to not use secmark today for a fallback mechanism is
> > > the current separation between 'internal' and 'external' labels.  But I
> > > don't believe that separation is necessary or useful, and secmark today
> > > is effectively unused.  The original usage scenario for it simply
> > > hasn't materialized.
> > >
> > > Meanwhile, getting secmark employed, not only as a mechanism for
> > > assigning default labels (via iptables rules) but also as a seamless
> > > way of propagating labels with socket buffers would solve a lot of our
> > > current limitations.  We'd get loopback labeling for free, flexible and
> > > generic fallback labeling, forwarding controls would become
> > > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > > NetLabel would benefit from it as well.  There are alternative
> > > implementation approaches, but none as clean and efficient and
> > > reliable. There was a reason we put a sid in the sk_buff in the
> > > original SELinux implementations (prior to Linux 2.6 merge).
> > >
> > > I've had some initial discussions with James, and he seemed open to
> > > revisiting this notion, so I think we need to take another look.
> >
> > I still think merging the two types of packet labels, "internal"
> > and "external" is a mistake; I stated my reasoning a few times before so
> > I will save people following this thread from reading it again.
>
> No one is using the "internal" labels AFAIK, and conceptually, I don't
> see a security goal that you would enforce that way that isn't more
> cleanly expressed (and more useful) in terms of "external" label.

Okay, so let's get rid of the "internal" label.

> > However, I agree that packet labeling is in a "weird" state right now and
> > there is a lot of room for improvement.  Bearing in mind your comments
> > that SECMARK is effectively unused due to lack of demand and that having
> > two types of packet labels is not helpful I wonder if the following would
> > a worthwhile effort:
> >
> >  * Do away with internal label concept completely, but leave the SECMARK
> >    secid field in the sk_buff struct.  This includes removing the SECMARK
> >    related MAC checks on incoming traffic, whether we bring back
> > compat_net or not is not important.
>
> Agree with the first part, but not the second.  The secmark packet
> checks are actually what we want, with some modification.  IOW, we want
> a unified set of checks independent of labeled networking mechanism so
> that we can have coherent policy.

Looking again at what I typed, I realized I worded it very poorly.  What I 
mean was that we should remove the iptables/SECMARK hooks so that the 
iptables bits no longer set the label of a packet, i.e. remove the internal 
labeling as we know it today.

> And while we do away with any 
> separate notion of "internal" vs "external", we'd still use iptables
> secmark rules to define and apply the fallback labels - that is more
> expressive and generic than your approach.

My main concern with this goes back to the failed secid-reconciliation 
efforts; the key problem here has to do with the behavior of getpeercon().  
As it stands right now, in the case of of a UNIX domain socket we return the 
label of the domain on the other end, the same with network sockets.  The 
current proposed static/fallback mechanism is intentionally coarse grained 
with the granularity limit being a single IP address/host.  My reasoning 
being that if the other host is not able or willing to send labeled traffic 
we should treat it as a single label host.  This seems to mesh well with what 
has been done in the past.

If we adopt the revised SECMARK/iptables method then this is no guaranteed to 
be the case.  With the added flexibility/granularity of iptables we could 
arrive in a situation where a single IP address/host could take on multiple 
different labels based on the type of connection.  Maybe this is what you 
want, but it is a departure from what we do today as well as what I've heard 
has been done in the past.  Then again, just because we've always done it 
this way doesn't mean it's the best solution.

> >  * Convert the external labeling protocols to make use of the SECMARK
> > secid field in the sk_buff struct.  The advantage to NetLabel and
> > explicit labeling protocols is really marginal but this should be a huge
> > win for labeled IPsec.
>
> I'm not so sure it is so marginal for netlabel - being able to use a
> field from the skb (once initially set for the packet) instead of
> inspecting the payload should be a win.

>From a functionality standpoint it is marginal for explicitly labeled packets 
because you already have the label as part of the packet's header/payload; 
that is what I was referring to.  I agree there are some obvious performance 
advantages if you have to look at the label twice.

> > As you stated above, there are some obvious advantages here including
> > "free" loopback labeling, easier implementation of general iptables
> > forwarding controls in the future, as well as some general implementation
> > cleanups in the existing code.  If we did decide to go this route, I
> > think I would prefer to keep a fallback/static labeling mechanism similar
> > to what is being done in this patchset, with the obvious change being
> > made to utilize the new SECMARK secid value.  We've seen all of the
> > issues that come to light when we start to make use of iptables to set
> > labels on packets and not all of them have elegant solutions; one could
> > even argue this is one of the reasons SECMARK as an internal label has
> > failed to achieve much use.
>
> You'll have to elaborate on that one; defining an iptables rule to apply
> a fallback label seems much more general and expressive than the
> netlabelctl approach.

See my comments above about the difference in getpeercon() behavior.  There 
are also implementation issues regarding the use of iptables, the "flush all" 
case being a good example.  Yes, there have been solutions tossed around but 
nothing concrete.  There is also the ongoing debate about how to properly 
generate iptables rules in policy, without a good solution here anything we 
do that uses iptables to label packets is going to have a hard time getting 
adopted by users.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Thu, 9 Aug 2007, Paul Moore wrote:


> See my comments above about the difference in getpeercon() behavior.  There 
> are also implementation issues regarding the use of iptables, the "flush all" 
> case being a good example.

You need cap_net_admin, so it is technically controllable in terms of 
MAC.

It may also be possible to create a new table which has finer-grained MAC 
controls.


-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Thu, 2007-08-09 at 10:48 -0400, Paul Moore wrote:
> On Thursday 09 August 2007 9:54:23 am Stephen Smalley wrote:
> > On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> > > On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > > I'm also a little confused about your concern over this new feature being
> > > NetLabel-centric?  I guess I don't understand how that is a problem,
> > > further explanation might help ...
> >
> > We want a fallback mechanism that is agnostic to the labeled networking
> > mechanism.  netlabel may be a "framework" but only for a particular
> > subset of such mechanisms, i.e. explicit packet labeling.  Putting
> > functionality into it that should also apply to xfrm labeling is wrong.
> 
> I guess this is always going to be a bit of a religious argument then, as I 
> tend to think of this feature as a static external label and implementing 
> this feature as part of an existing external labeling system/framework makes 
> the most sense to me.  Regardless, it's probably best to focus on the other 
> issues in this thread, namely what to do with SECMARK, first as that will 
> have a huge impact on this topic.

I agree with that last sentence ;) 

> > > I understand your concern regarding the additional configuration.  While
> > > netlabelctl and netlabel_tools are not new, they may be new to users who
> > > want to make use of this new feature.  On an older thread Josh and I had
> > > a bit of a discussion regarding this and while we never really arrived at
> > > a magic solution we did talk about integrating some, or all, of the
> > > netlabelctl functionality into semanage.  This wouldn't be that difficult
> > > as most of the "intelligence" in netlabelctl is already in a separate
> > > library; adding that library to semanage should not be that difficult. 
> > > Would that help ease your configuration concerns?
> >
> > I don't care what we call the userland tool; it is still using
> > netlabel-specific interfaces and infrastructure.
> 
> > And re-inventing the secmark wheel.
> 
> Well, only if you redefine SECMARK to a greater scope that what it is used for 
> today.  Granted, both this new static/fallback label feature use IP header 
> information to derive a packet label but that's about the only similarity I 
> see here.  If we do decide to redefine SECMARK then you'll be correct, no 
> need for this patchset.

Exactly.

> > > > The only reason to not use secmark today for a fallback mechanism is
> > > > the current separation between 'internal' and 'external' labels.  But I
> > > > don't believe that separation is necessary or useful, and secmark today
> > > > is effectively unused.  The original usage scenario for it simply
> > > > hasn't materialized.
> > > >
> > > > Meanwhile, getting secmark employed, not only as a mechanism for
> > > > assigning default labels (via iptables rules) but also as a seamless
> > > > way of propagating labels with socket buffers would solve a lot of our
> > > > current limitations.  We'd get loopback labeling for free, flexible and
> > > > generic fallback labeling, forwarding controls would become
> > > > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > > > NetLabel would benefit from it as well.  There are alternative
> > > > implementation approaches, but none as clean and efficient and
> > > > reliable. There was a reason we put a sid in the sk_buff in the
> > > > original SELinux implementations (prior to Linux 2.6 merge).
> > > >
> > > > I've had some initial discussions with James, and he seemed open to
> > > > revisiting this notion, so I think we need to take another look.
> > >
> > > I still think merging the two types of packet labels, "internal"
> > > and "external" is a mistake; I stated my reasoning a few times before so
> > > I will save people following this thread from reading it again.
> >
> > No one is using the "internal" labels AFAIK, and conceptually, I don't
> > see a security goal that you would enforce that way that isn't more
> > cleanly expressed (and more useful) in terms of "external" label.
> 
> Okay, so let's get rid of the "internal" label.

Yep, a packet has a single label at any given time.  Period.
That label can get refined over time as we get more information,
starting from e.g. the receiving network device and sending address and
working our way up to an actual label associated with the packet via
netlabel or labeled xfrm.

Any other model is too confusing and yields curious behavior as the
distinct labels can become inconsistent with one another.

> > > However, I agree that packet labeling is in a "weird" state right now and
> > > there is a lot of room for improvement.  Bearing in mind your comments
> > > that SECMARK is effectively unused due to lack of demand and that having
> > > two types of packet labels is not helpful I wonder if the following would
> > > a worthwhile effort:
> > >
> > >  * Do away with internal label concept completely, but leave the SECMARK
> > >    secid field in the sk_buff struct.  This includes removing the SECMARK
> > >    related MAC checks on incoming traffic, whether we bring back
> > > compat_net or not is not important.
> >
> > Agree with the first part, but not the second.  The secmark packet
> > checks are actually what we want, with some modification.  IOW, we want
> > a unified set of checks independent of labeled networking mechanism so
> > that we can have coherent policy.
> 
> Looking again at what I typed, I realized I worded it very poorly.  What I 
> mean was that we should remove the iptables/SECMARK hooks so that the 
> iptables bits no longer set the label of a packet, i.e. remove the internal 
> labeling as we know it today.

Disagree.  Letting a label be initially associated with a packet via
iptables is very useful.

> > And while we do away with any 
> > separate notion of "internal" vs "external", we'd still use iptables
> > secmark rules to define and apply the fallback labels - that is more
> > expressive and generic than your approach.
> 
> My main concern with this goes back to the failed secid-reconciliation 
> efforts; the key problem here has to do with the behavior of getpeercon().  
> As it stands right now, in the case of of a UNIX domain socket we return the 
> label of the domain on the other end, the same with network sockets.  The 
> current proposed static/fallback mechanism is intentionally coarse grained 
> with the granularity limit being a single IP address/host.  My reasoning 
> being that if the other host is not able or willing to send labeled traffic 
> we should treat it as a single label host.  This seems to mesh well with what 
> has been done in the past.

The selection granularity is up to the person configuring the iptables
rules, so no harm there in providing him with more options but only
using the coarse-grained choices.

> If we adopt the revised SECMARK/iptables method then this is no guaranteed to 
> be the case.  With the added flexibility/granularity of iptables we could 
> arrive in a situation where a single IP address/host could take on multiple 
> different labels based on the type of connection.  Maybe this is what you 
> want, but it is a departure from what we do today as well as what I've heard 
> has been done in the past.  Then again, just because we've always done it 
> this way doesn't mean it's the best solution.

My preference would be to have it assigned a single default/fallback
label based on iptables, and then overridden after a permission check if
labeled networking is in use.  No other mutations.

> > >  * Convert the external labeling protocols to make use of the SECMARK
> > > secid field in the sk_buff struct.  The advantage to NetLabel and
> > > explicit labeling protocols is really marginal but this should be a huge
> > > win for labeled IPsec.
> >
> > I'm not so sure it is so marginal for netlabel - being able to use a
> > field from the skb (once initially set for the packet) instead of
> > inspecting the payload should be a win.
> 
> >From a functionality standpoint it is marginal for explicitly labeled packets 
> because you already have the label as part of the packet's header/payload; 
> that is what I was referring to.  I agree there are some obvious performance 
> advantages if you have to look at the label twice.

Propagation/preservation of the label throughout also gets simpler and
more reliable, and possibly goes beyond what you can do today.  How do
you deal with ICMP replies currently?

> > > As you stated above, there are some obvious advantages here including
> > > "free" loopback labeling, easier implementation of general iptables
> > > forwarding controls in the future, as well as some general implementation
> > > cleanups in the existing code.  If we did decide to go this route, I
> > > think I would prefer to keep a fallback/static labeling mechanism similar
> > > to what is being done in this patchset, with the obvious change being
> > > made to utilize the new SECMARK secid value.  We've seen all of the
> > > issues that come to light when we start to make use of iptables to set
> > > labels on packets and not all of them have elegant solutions; one could
> > > even argue this is one of the reasons SECMARK as an internal label has
> > > failed to achieve much use.
> >
> > You'll have to elaborate on that one; defining an iptables rule to apply
> > a fallback label seems much more general and expressive than the
> > netlabelctl approach.
> 
> See my comments above about the difference in getpeercon() behavior.  There 
> are also implementation issues regarding the use of iptables, the "flush all" 
> case being a good example.  Yes, there have been solutions tossed around but 
> nothing concrete.  There is also the ongoing debate about how to properly 
> generate iptables rules in policy, without a good solution here anything we 
> do that uses iptables to label packets is going to have a hard time getting 
> adopted by users.

We don't generate netlabelctl configuration or ipsec configuration from
policy, so this isn't really different.  Ultimately, you'd have some
front-end tool that lets you configure labeled networking, including
selection of mechanism (NetLabel/CIPSO or NetLabel/other or labeled
IPSEC), selection of appropriate settings for that mechanism, and
fallbacks (via secmark).

Separate table would likely be useful.

-- 
Stephen Smalley
National Security Agency


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday, August 9 2007 12:01:46 pm Stephen Smalley wrote:
> On Thu, 2007-08-09 at 10:48 -0400, Paul Moore wrote:
> > On Thursday 09 August 2007 9:54:23 am Stephen Smalley wrote:
> > > On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> > If we adopt the revised SECMARK/iptables method then this is no
> > guaranteed to be the case.  With the added flexibility/granularity of
> > iptables we could arrive in a situation where a single IP address/host
> > could take on multiple different labels based on the type of connection. 
> > Maybe this is what you want, but it is a departure from what we do today
> > as well as what I've heard has been done in the past.  Then again, just
> > because we've always done it this way doesn't mean it's the best
> > solution.
>
> My preference would be to have it assigned a single default/fallback
> label based on iptables, and then overridden after a permission check if
> labeled networking is in use.  No other mutations.
>
> > > >  * Convert the external labeling protocols to make use of the SECMARK
> > > > secid field in the sk_buff struct.  The advantage to NetLabel and
> > > > explicit labeling protocols is really marginal but this should be a
> > > > huge win for labeled IPsec.
> > >
> > > I'm not so sure it is so marginal for netlabel - being able to use a
> > > field from the skb (once initially set for the packet) instead of
> > > inspecting the payload should be a win.
> > >
> > >From a functionality standpoint it is marginal for explicitly labeled
> > > packets
> >
> > because you already have the label as part of the packet's
> > header/payload; that is what I was referring to.  I agree there are some
> > obvious performance advantages if you have to look at the label twice.
>
> Propagation/preservation of the label throughout also gets simpler and
> more reliable, and possibly goes beyond what you can do today.

Um, okay ... what are you trying to sell me here ;)  I never said this 
particular point is good/bad, just that I don't see this single point as 
reason enough to go through with the changes you are proposing (from a 
NetLabel point of view).

> How do you deal with ICMP replies currently?

For CIPSO they are labeled based on the packet which caused the ICMP message 
to be generated as dictated by the draft.

> > > > As you stated above, there are some obvious advantages here including
> > > > "free" loopback labeling, easier implementation of general iptables
> > > > forwarding controls in the future, as well as some general
> > > > implementation cleanups in the existing code.  If we did decide to go
> > > > this route, I think I would prefer to keep a fallback/static labeling
> > > > mechanism similar to what is being done in this patchset, with the
> > > > obvious change being made to utilize the new SECMARK secid value. 
> > > > We've seen all of the issues that come to light when we start to make
> > > > use of iptables to set labels on packets and not all of them have
> > > > elegant solutions; one could even argue this is one of the reasons
> > > > SECMARK as an internal label has failed to achieve much use.
> > >
> > > You'll have to elaborate on that one; defining an iptables rule to
> > > apply a fallback label seems much more general and expressive than the
> > > netlabelctl approach.
> >
> > See my comments above about the difference in getpeercon() behavior. 
> > There are also implementation issues regarding the use of iptables, the
> > "flush all" case being a good example.  Yes, there have been solutions
> > tossed around but nothing concrete.  There is also the ongoing debate
> > about how to properly generate iptables rules in policy, without a good
> > solution here anything we do that uses iptables to label packets is going
> > to have a hard time getting adopted by users.
>
> We don't generate netlabelctl configuration or ipsec configuration from
> policy, so this isn't really different.  Ultimately, you'd have some
> front-end tool that lets you configure labeled networking, including
> selection of mechanism (NetLabel/CIPSO or NetLabel/other or labeled
> IPSEC), selection of appropriate settings for that mechanism, and
> fallbacks (via secmark).

Doesn't this hit at some of the same arguments you had against this patchset 
regarding configuration at the start of this thread.

> Separate table would likely be useful.

Yes, probably even a requirement to help preserve the sanity of the admins.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Thu, 9 Aug 2007, Paul Moore wrote:

> However, I agree that packet labeling is in a "weird" state right now and 
> there is a lot of room for improvement.  Bearing in mind your comments that 
> SECMARK is effectively unused due to lack of demand and that having two types 
> of packet labels is not helpful I wonder if the following would a worthwhile 
> effort:

I think a big factor here is that the OS integration work has not been 
done, and there's a (general) lack of high-level tools for managing 
SELinux.  The functionality, in terms of providing complete coverage of 
the OS, is required.

> 
>  * Do away with internal label concept completely, but leave the SECMARK
>    secid field in the sk_buff struct.  This includes removing the SECMARK
>    related MAC checks on incoming traffic, whether we bring back compat_net
>    or not is not important.

Removing the secmark checks would leave us without a good way to perform 
local network labeling & control.

We should probably schedule compat_net removal per the kernel deprecation 
schedule guidelines.

>  * Convert the external labeling protocols to make use of the SECMARK secid
>    field in the sk_buff struct.  The advantage to NetLabel and explicit
>    labeling protocols is really marginal but this should be a huge win for
>    labeled IPsec.

The way we were discussing this (off-list) was that we'd allow iptables 
secmark labeling to set fallback/default labels, which may be overridden 
by external labeling (Netlabel, IPsec).


-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday 09 August 2007 9:59:53 am James Morris wrote:
> On Thu, 9 Aug 2007, Paul Moore wrote:
> >  * Convert the external labeling protocols to make use of the SECMARK
> > secid field in the sk_buff struct.  The advantage to NetLabel and
> > explicit labeling protocols is really marginal but this should be a huge
> > win for labeled IPsec.
>
> The way we were discussing this (off-list) was that we'd allow iptables
> secmark labeling to set fallback/default labels, which may be overridden
> by external labeling (Netlabel, IPsec).

If I understand you correctly, SECMARK would continue as SECMARK as we know it 
today, the only real difference is that if getpeercon() would return failure 
because NetLabel or labeled IPsec was not in use we would return the SECMARK 
label?

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Thu, 2007-08-09 at 10:50 -0400, Paul Moore wrote:
> On Thursday 09 August 2007 9:59:53 am James Morris wrote:
> > On Thu, 9 Aug 2007, Paul Moore wrote:
> > >  * Convert the external labeling protocols to make use of the SECMARK
> > > secid field in the sk_buff struct.  The advantage to NetLabel and
> > > explicit labeling protocols is really marginal but this should be a huge
> > > win for labeled IPsec.
> >
> > The way we were discussing this (off-list) was that we'd allow iptables
> > secmark labeling to set fallback/default labels, which may be overridden
> > by external labeling (Netlabel, IPsec).
> 
> If I understand you correctly, SECMARK would continue as SECMARK as we know it 
> today, the only real difference is that if getpeercon() would return failure 
> because NetLabel or labeled IPsec was not in use we would return the SECMARK 
> label?

Except that secmark would also be used as the means of propagating the
label with the skb throughout the stack, thereby enabling loopback
labeling and flow control.  So secmark gets initialized via iptables to
a fallback (or left unlabeled if no iptables match exists), then
replaced (after a consistency check) if labeled networking is in use
with the explicit or implicit label.  Then the secmark gets used
everywhere for permission checking - it represents the most accurate
label we know for the packet at any given time.

-- 
Stephen Smalley
National Security Agency


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Paul Moore wrote:
> On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
>> I like the functionality, but I don't like having yet another mechanism
>> and configuration, and I'm concerned about it being netlabel-centric.
> 
> NetLabel has always been designed as a framework to support multiple
different 
> types of labeling protocols/mechanisms.  Adding this bit of functionality
to 
> NetLabel isn't a major departure from the existing architecture.  The only

> real substantial changes to the underlying NetLabel framework are the
passing 
> of the IP address family to some of the NetLabel APIs (minor tweak) and
the 
> addition of a secid field to the NetLabel security attributes struct (also
a 
> pretty minor tweak).
> 
> I'm also a little confused about your concern over this new feature being 
> NetLabel-centric?  I guess I don't understand how that is a problem,
further 
> explanation might help ...

I actually have a question regarding this.  This all seems to be aimed at
getting
getpeercon to always return our "best knowledge" of what the peer's context
actually
is.  This is excellent - we need this functionality.  getpeercon will return
the
xfrm label (which is, by mechanism, the context of the peer) if labeled
ipsec is
being used, correct?  netlabel will then modify that label with it's own
idea
of the peer, correct?  Doesn't that mean a secret peer (using labeled ipsec)
will
now actually look like a top_secret peer if there is a "fallback" that
specifies
this host as top_secret?  I think this is currently a problem with
"fighting"
mechanism that attempt to give information regarding the peer.  There is no
consistency between them.  A true fallback would have to occur *before* any
peer
provided label information would be processed.  I also think that there must
be consistency forced between the different peer labeling mechanisms.  If I
get
packets that are specified as top_secret via CIPSO over an ipsec association
labeled as user_u:user_r:user_t:secret, that packet should die.

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday 09 August 2007 10:41:09 am Darrel Goeddel wrote:
> ... I also think that there must be consistency forced between the different
> peer labeling mechanisms.  If I get packets that are specified as top_secret
> via CIPSO over an ipsec association labeled as user_u:user_r:user_t:secret,
> that packet should die. 

Yes.  This is one of the places in the labeled networking code that has always 
bothered me.  The current mashup of labels was rather a poor attempt at 
compromise by everyone involved and I think everyone will agree that we need 
to come up with a better solution.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Paul Moore wrote:
> On Thursday 09 August 2007 10:41:09 am Darrel Goeddel wrote:
>> ... I also think that there must be consistency forced between the
different
>> peer labeling mechanisms.  If I get packets that are specified as
top_secret
>> via CIPSO over an ipsec association labeled as
user_u:user_r:user_t:secret,
>> that packet should die. 
> 
> Yes.  This is one of the places in the labeled networking code that has
always 
> bothered me.  The current mashup of labels was rather a poor attempt at 
> compromise by everyone involved and I think everyone will agree that we
need 
> to come up with a better solution.

That is what I was afraid of...  So we currently have a problem where
getpeercon
can distort the MLS portion of the peer's context in the case of CIPSO and
labeled ipsec being employed.  The netlabel fallback mechanism will
exacerbate
this problem by making making it much easier to exploit the problem because
labeled ipsec with fallback is very desirable.  I want to treat hosts on a
certain net as secret in general, but I also want to allow some
administrative
connections at systemhigh using labled ipsec.  In this case, the fallback
would
be trumping my attempts to provide my real local context to the server I am
trying to connect to.  It is real scary in the opposite case - a top_secret
fallback MLS level trumping a lowly user's unclassified ipsec label and
giving
him access to a whole bunch of goodies...  I really think using secmark as
a fallback, below the peer provided labeling information, is going to be the
best
solution to this problem.

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > I like the functionality, but I don't like having yet another mechanism
> > and configuration, and I'm concerned about it being netlabel-centric.
> 
> NetLabel has always been designed as a framework to support multiple
> different 
> types of labeling protocols/mechanisms.  Adding this bit of functionality to 
> NetLabel isn't a major departure from the existing architecture.  The only 
> real substantial changes to the underlying NetLabel framework are the passing
> 
> of the IP address family to some of the NetLabel APIs (minor tweak) and the 
> addition of a secid field to the NetLabel security attributes struct (also a 
> pretty minor tweak).
> 
> I'm also a little confused about your concern over this new feature being 
> NetLabel-centric?  I guess I don't understand how that is a problem, further 
> explanation might help ...
> 
> I understand your concern regarding the additional configuration.  While 
> netlabelctl and netlabel_tools are not new, they may be new to users who want
> 
> to make use of this new feature.  On an older thread Josh and I had a bit of 
> a discussion regarding this and while we never really arrived at a magic 
> solution we did talk about integrating some, or all, of the netlabelctl 
> functionality into semanage.  This wouldn't be that difficult as most of 
> the "intelligence" in netlabelctl is already in a separate library; adding 
> that library to semanage should not be that difficult.  Would that help ease 
> your configuration concerns?
> 
> > The only reason to not use secmark today for a fallback mechanism is the
> > current separation between 'internal' and 'external' labels.  But I
> > don't believe that separation is necessary or useful, and secmark today
> > is effectively unused.  The original usage scenario for it simply hasn't
> > materialized.
> >
> > Meanwhile, getting secmark employed, not only as a mechanism for
> > assigning default labels (via iptables rules) but also as a seamless way
> > of propagating labels with socket buffers would solve a lot of our
> > current limitations.  We'd get loopback labeling for free, flexible and
> > generic fallback labeling, forwarding controls would become
> > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > NetLabel would benefit from it as well.  There are alternative
> > implementation approaches, but none as clean and efficient and reliable.
> > There was a reason we put a sid in the sk_buff in the original SELinux
> > implementations (prior to Linux 2.6 merge).
> >
> > I've had some initial discussions with James, and he seemed open to
> > revisiting this notion, so I think we need to take another look.
> 
> I still think merging the two types of packet labels, "internal" 
> and "external" is a mistake; I stated my reasoning a few times before so I 
> will save people following this thread from reading it again.
> 
> However, I agree that packet labeling is in a "weird" state right now and 
> there is a lot of room for improvement.  Bearing in mind your comments that 
> SECMARK is effectively unused due to lack of demand and that having two types
> 
> of packet labels is not helpful I wonder if the following would a worthwhile 
> effort:
> 
>  * Do away with internal label concept completely, but leave the SECMARK
>    secid field in the sk_buff struct.  This includes removing the SECMARK
>    related MAC checks on incoming traffic, whether we bring back compat_net
>    or not is not important.
>  * Convert the external labeling protocols to make use of the SECMARK secid
>    field in the sk_buff struct.  The advantage to NetLabel and explicit
>    labeling protocols is really marginal but this should be a huge win for
>    labeled IPsec.

If y'all are going to look at this, please consider that secid's are
SELinux specific and using them in system interfaces is an impediment
to the development of other schemes. One important reason that Smack is
using netlabel in favor of secmark is that secid interface.

> As you stated above, there are some obvious advantages here including "free" 
> loopback labeling, easier implementation of general iptables forwarding 
> controls in the future, as well as some general implementation cleanups in 
> the existing code.  If we did decide to go this route, I think I would prefer
> 
> to keep a fallback/static labeling mechanism similar to what is being done in
> 
> this patchset, with the obvious change being made to utilize the new SECMARK 
> secid value.  We've seen all of the issues that come to light when we start 
> to make use of iptables to set labels on packets and not all of them have 
> elegant solutions; one could even argue this is one of the reasons SECMARK as
> 
> an internal label has failed to achieve much use.
> 
> -- 
> 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.
> 
> 
> 


Casey Schaufler
casey@schaufler-ca.com

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Thu, 2007-08-09 at 08:32 -0700, Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> 
> > On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > > I like the functionality, but I don't like having yet another mechanism
> > > and configuration, and I'm concerned about it being netlabel-centric.
> > 
> > NetLabel has always been designed as a framework to support multiple
> > different 
> > types of labeling protocols/mechanisms.  Adding this bit of functionality to 
> > NetLabel isn't a major departure from the existing architecture.  The only 
> > real substantial changes to the underlying NetLabel framework are the passing
> > 
> > of the IP address family to some of the NetLabel APIs (minor tweak) and the 
> > addition of a secid field to the NetLabel security attributes struct (also a 
> > pretty minor tweak).
> > 
> > I'm also a little confused about your concern over this new feature being 
> > NetLabel-centric?  I guess I don't understand how that is a problem, further 
> > explanation might help ...
> > 
> > I understand your concern regarding the additional configuration.  While 
> > netlabelctl and netlabel_tools are not new, they may be new to users who want
> > 
> > to make use of this new feature.  On an older thread Josh and I had a bit of 
> > a discussion regarding this and while we never really arrived at a magic 
> > solution we did talk about integrating some, or all, of the netlabelctl 
> > functionality into semanage.  This wouldn't be that difficult as most of 
> > the "intelligence" in netlabelctl is already in a separate library; adding 
> > that library to semanage should not be that difficult.  Would that help ease 
> > your configuration concerns?
> > 
> > > The only reason to not use secmark today for a fallback mechanism is the
> > > current separation between 'internal' and 'external' labels.  But I
> > > don't believe that separation is necessary or useful, and secmark today
> > > is effectively unused.  The original usage scenario for it simply hasn't
> > > materialized.
> > >
> > > Meanwhile, getting secmark employed, not only as a mechanism for
> > > assigning default labels (via iptables rules) but also as a seamless way
> > > of propagating labels with socket buffers would solve a lot of our
> > > current limitations.  We'd get loopback labeling for free, flexible and
> > > generic fallback labeling, forwarding controls would become
> > > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > > NetLabel would benefit from it as well.  There are alternative
> > > implementation approaches, but none as clean and efficient and reliable.
> > > There was a reason we put a sid in the sk_buff in the original SELinux
> > > implementations (prior to Linux 2.6 merge).
> > >
> > > I've had some initial discussions with James, and he seemed open to
> > > revisiting this notion, so I think we need to take another look.
> > 
> > I still think merging the two types of packet labels, "internal" 
> > and "external" is a mistake; I stated my reasoning a few times before so I 
> > will save people following this thread from reading it again.
> > 
> > However, I agree that packet labeling is in a "weird" state right now and 
> > there is a lot of room for improvement.  Bearing in mind your comments that 
> > SECMARK is effectively unused due to lack of demand and that having two types
> > 
> > of packet labels is not helpful I wonder if the following would a worthwhile 
> > effort:
> > 
> >  * Do away with internal label concept completely, but leave the SECMARK
> >    secid field in the sk_buff struct.  This includes removing the SECMARK
> >    related MAC checks on incoming traffic, whether we bring back compat_net
> >    or not is not important.
> >  * Convert the external labeling protocols to make use of the SECMARK secid
> >    field in the sk_buff struct.  The advantage to NetLabel and explicit
> >    labeling protocols is really marginal but this should be a huge win for
> >    labeled IPsec.
> 
> If y'all are going to look at this, please consider that secid's are
> SELinux specific and using them in system interfaces is an impediment
> to the development of other schemes. One important reason that Smack is
> using netlabel in favor of secmark is that secid interface.

The secid notion is the only reason we have a field in the sk_buff at
all.  The original security blob in the sk_buff was rejected by David
Miller when the LSM networking hooks were put forward by James; it comes
back to lifecycle management and overhead.  The secmark (just another
name for a secid) construct in contrast avoids the lifecycle management
requirement and due to its small fixed size avoids significant bloat.
There is considerable doubt that we could even get it expanded to being
a u64, much less turned into a security blob.

-- 
Stephen Smalley
National Security Agency


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:


> > If y'all are going to look at this, please consider that secid's are
> > SELinux specific and using them in system interfaces is an impediment
> > to the development of other schemes. One important reason that Smack is
> > using netlabel in favor of secmark is that secid interface.
> 
> The secid notion is the only reason we have a field in the sk_buff at
> all.  The original security blob in the sk_buff was rejected by David
> Miller when the LSM networking hooks were put forward by James; it comes
> back to lifecycle management and overhead.  The secmark (just another
> name for a secid) construct in contrast avoids the lifecycle management
> requirement and due to its small fixed size avoids significant bloat.
> There is considerable doubt that we could even get it expanded to being
> a u64, much less turned into a security blob.

This is the answer I expected. I did have to raise the question.
I will stick with netlabel/cipso, and "ambient" labels rather than
the suggested secid based default scheme, at least for the time being.
Thank you.


Casey Schaufler
casey@schaufler-ca.com

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Stephen Smalley wrote:
> On Tue, 2007-08-07 at 10:14 -0400, Paul Moore wrote:
>> This patchset adds the static/fallback labeling feature to NetLabel that
has
>> been requested on the SELinux mailing list more and more recently.  This
new
>> bit of functionality also matches what can be found on similar
trusted/labeled
>> OSs such as Trusted Solaris, HP-UX CMW, etc.  This patchset it not yet
ready
>> for "upstreaming" so please do not pull this into any tree bound for the
>> mainline kernel; I still need to do more review and testing of the code.
>> However, I know there are several of you on this list that have been
anxiously
>> awaiting this patchset so I thought I would make an early release so you
could
>> get a peek and test it out.  I won't be able to work on this patchset
much, if
>> at all, between August 10th and the 20th so don't expect an update from
me
>> until the end of August.
>>
>> The basic idea is that currently there is no method for providing an
external
>> label to fallback on if a labeled networking mechanism such as
NetLabel/CIPSO
>> or labeled IPsec is not in use.  This patch adds a mechanism for
providing a
>> static fallback label, specified per interface/network, which is used
when
>> a NetLabel recognized labeling protocol (at this point CIPSO) is not in
use.
>>
>> For those of you wishing to try this patchset, it is backed against
Linus'
>> linux-2.6 git tree from the afternoon of August 6th, but I don't imagine
you'll
>> have many problems applying the patchset to later trees at this point in
the
>> 2.6.23 release cycle.  In addition to the kernel patches you will also
need a
>> modified version of netlabelctl from the netlabel_tools package.  A very
crude
>> version of the modified tools can be found in the netlabel_tools SVN
repository
>> in the static_label branch.  Please check the NetLabel website on
SourceForge,
>> http://netlabel.sf.net, for information on the SVN repository.  The three
new
>> netlabelctl commands are as follows:
>>
>>  # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>]
label:<LABEL>
>>  # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
>>  # netlabelctl -p unlbl list
>>
>>    DEV = interface, examples: eth0, lo
>>    ADDR = IP address, examples: 192.168.0.3, ::1
>>    MASK = IP address mask length, examples 8, 24, 64
>>    LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2
>>
>> For example, if you wanted to label all inbound traffic on eth1 from
>> 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you
would
>> type:
>>
>>  # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
>>                          label:system_u:object_r:staticlabel_t:s7
>>
>> Both IPv4 and IPv6 addresses can be used and if the address mask is
ommitted
>> from the command the address is assumed to be a host address, not a
network,
>> and the maximum mask size for that address family is used.  If you do not
wish
>> to specify an address, simply use a address mask of zero, "/0", which
will
>> cause all addresses within that address family to match.
> 
> Hi,
> 
> I like the functionality, but I don't like having yet another mechanism
> and configuration, and I'm concerned about it being netlabel-centric.
> Especially when we already have a more generic and flexible mechanism
> for specifying packet labels, i.e. secmark.
> 
> The only reason to not use secmark today for a fallback mechanism is the
> current separation between 'internal' and 'external' labels.  But I
> don't believe that separation is necessary or useful, and secmark today
> is effectively unused.  The original usage scenario for it simply hasn't
> materialized.

I agree whole-heartedly with the above statements.  I actually use the
secmark
mechanism and labeled ipsec, but unfortunately I need a patched kernel to
make
the useful in in regards to the issues of flow control (providing a
mechanism
for a controlled network interface) and loopback labeling.  These are
necessary
features for the user base I work with.  This user base happens to be the
LSPP
crowd, folks that needed a certified platform, but now they can't use the
certified
platform because it is woefully lacking in the network control department.

> Meanwhile, getting secmark employed, not only as a mechanism for
> assigning default labels (via iptables rules) but also as a seamless way
> of propagating labels with socket buffers would solve a lot of our
> current limitations.  We'd get loopback labeling for free, flexible and
> generic fallback labeling, forwarding controls would become
> straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> NetLabel would benefit from it as well.  There are alternative
> implementation approaches, but none as clean and efficient and reliable.
> There was a reason we put a sid in the sk_buff in the original SELinux
> implementations (prior to Linux 2.6 merge).
> 
> I've had some initial discussions with James, and he seemed open to
> revisiting this notion, so I think we need to take another look.

Because of the position I am in (needing to find something workable for
actual
users), I have been trying to get my head aounrd the state of SELinux
networking,
the ideas that have been talked about in the past, and how we can prevent
the
SELinux networking infrastructure from resembling a Rube-Goldberg machine.
I'll
be presenting some of the problems I perceive along with some very high
level
ideas early next week.

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Thu, 9 Aug 2007, Darrel Goeddel wrote:

> Because of the position I am in (needing to find something workable for
> actual
> users), I have been trying to get my head aounrd the state of SELinux
> networking,
> the ideas that have been talked about in the past, and how we can prevent
> the
> SELinux networking infrastructure from resembling a Rube-Goldberg machine.
> I'll
> be presenting some of the problems I perceive along with some very high
> level
> ideas early next week.

I think the problem we have faced in this area here is not enough focus on 
general usability, and how to make this stuff useful beyond "lspp" 
customers.  It is essential for SELinux to succeed that it is generally 
useful, and capable of addressing general security requirements, otherwise 
we _effectively_ end up with a Trusted Solaris style fork, where you have 
this odd code in the corner that most people don't and won't use.

The proposal outlined in my last email is:

- Retain existing secmark facilities, allowing them to be used as a way to 
provide default/fallback labeling

- Allow external labeling (IPsec, CIPSO) to override the secmark labels

This gives us loopback labeling, the ability to retain the general 
usability of only local iptables-based labeling, and a very simple 
mechanism for integrating external labeling.

Does this address all of your requirements ?

If not, please explain what's missing.



- James
-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

James Morris wrote:
> On Thu, 9 Aug 2007, Darrel Goeddel wrote:
> 
>> Because of the position I am in (needing to find something workable for
>> actual
>> users), I have been trying to get my head aounrd the state of SELinux
>> networking,
>> the ideas that have been talked about in the past, and how we can prevent
>> the
>> SELinux networking infrastructure from resembling a Rube-Goldberg
machine.
>> I'll
>> be presenting some of the problems I perceive along with some very high
>> level
>> ideas early next week.
> 
> I think the problem we have faced in this area here is not enough focus on

> general usability, and how to make this stuff useful beyond "lspp" 
> customers.  It is essential for SELinux to succeed that it is generally 
> useful, and capable of addressing general security requirements, otherwise

> we _effectively_ end up with a Trusted Solaris style fork, where you have 
> this odd code in the corner that most people don't and won't use.

I am in full agreement.  In fact I fear we may have started down that road
and
need to look at the big picture to avoid going further (and possibly back up
a bit...)  Part of the problem set that I am looking at include the
complexity
of the network controls in general.  It seems that what people really want
is
to think of the peer when deciding on whether or not we can do a little
networking.  I'll get into this more when I think I have a good enough
understanding of some of the issues (why couldn't this have all waited a
bit...).  I would be interested in hearing if people think that this does
not
make sense because I don't want to waste a bunch of time getting focused on
that (confirmation of the desire is also welcome).

OK, I'll give a quick thought right now:

It seems like "can system_u:system_r:ntpd_t:secret (ntp daemon) talk
to system_u:system_r:ntp_t:secret (peer ntp client)" is a much more sensible
question to address than "can system_u:system_r:ntpd_t:secret receive a
system_u:system_r:ntp_client_pkt_t packet, through a
system_u:system_r:unlabeled_t:systemhigh association (which may not really
exist), through a system_u:system_r:unlabeled_t:systemhigh socket"?

The socket vs secmark check seems to become intuitive and the others are no
longer necessary when everything is seen as the context of the peer (whether
it be from our iptables definition or explicit info from the peer itself).

Yes, I was all in favor of treating the packet as data in the past - that is
still very intuitive to me as there is no process inside of it.  However, I
realize the nicety of treating the packet as an extension of the peer
process.
If we pick one and stick with it, things are much easier to understand and
therefore configure properly.  I am now choosing the peer domain instead of
the packet data idea for my further thoughts...

> The proposal outlined in my last email is:
> 
> - Retain existing secmark facilities, allowing them to be used as a way to

> provide default/fallback labeling
> 
> - Allow external labeling (IPsec, CIPSO) to override the secmark labels
> 
> This gives us loopback labeling, the ability to retain the general 
> usability of only local iptables-based labeling, and a very simple 
> mechanism for integrating external labeling.
> 
> Does this address all of your requirements ?

Yes.  That is the foundation of the labeling process.  There are details
such as making sure that multiple sources of peer-provided label information
are in agreement, but the foundation is solid and simple.

> If not, please explain what's missing.

As far as labeling goes, we are good.  We'll need to do something
constructive
with those labels as well.  I think the above example that gives meaning to
the socket vs. secmark check shows how we could look at things in a simpler,
more intuitive way.  We'll also need to address the checks on outbound
(locally
generated and forwarded) traffic.  Good news is that getpeercon work for
free,
just return secmark, and it will actually give you *the* label that was used
for the access check :)

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 9, 2007, at 11:42 AM, Darrel Goeddel wrote:

>  (why couldn't this have all waited a bit...)

Paul is addressing a real need. Like many things that really need  
doing and take time, multiple people are simultaneously working on it.

I installed the netlabel patches and have tested them with good  
results in MLS/permissive at a few levels (s0, s2:c0.c253,  
s2:c0.c253). More testing to follow.

netlabelctl unlbl add interface:eth0 address:10.211.55.8/32  
label:user_u:object_r:user_t:s2:c0.c253

/netlabelctl unlbl list
accept:on
interface:eth0,address: 
192.168.20.253/32,label:"user_u:object_r:user_t:s0"
interface:eth0,address: 
10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"

getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'

for a connection from 10.211.55.8.

This is a big improvement in linux labeled networking functionality.

joe

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Joe Nall wrote:
> On Aug 9, 2007, at 11:42 AM, Darrel Goeddel wrote:
> 
>>  (why couldn't this have all waited a bit...)
> 
> Paul is addressing a real need. Like many things that really need  
> doing and take time, multiple people are simultaneously working on it.
> 
> I installed the netlabel patches and have tested them with good  
> results in MLS/permissive at a few levels (s0, s2:c0.c253,  
> s2:c0.c253). More testing to follow.
> 
> netlabelctl unlbl add interface:eth0 address:10.211.55.8/32  
> label:user_u:object_r:user_t:s2:c0.c253
> 
> /netlabelctl unlbl list
> accept:on
> interface:eth0,address: 
> 192.168.20.253/32,label:"user_u:object_r:user_t:s0"
> interface:eth0,address: 
> 10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"
> 
> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'
> 
> for a connection from 10.211.55.8.
> 
> This is a big improvement in linux labeled networking functionality.

As described in an earlier email, from my not-yet-full grasp on the patch,
this is a vulnerability waiting to happen in the event of using netlabel
fallback contexts alongside labeled ipsec.  That is not an improvement.
If there were consistency checks between the various forms of external
labels, this would not be an issue and the functionality would indeed
be an improvement.  Again, I do not have a test case, but Paul's response
to my query about getpeercon returning a netlabel modified version of
the xfrm label seemed to validate my concern.

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joe Nall]

On Aug 9, 2007, at 2:47 PM, Darrel Goeddel wrote:
>> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I  
>> A L'
>>
>> for a connection from 10.211.55.8.
>>
>> This is a big improvement in linux labeled networking functionality.
>
> As described in an earlier email, from my not-yet-full grasp on the  
> patch,
> this is a vulnerability waiting to happen in the event of using  
> netlabel
> fallback contexts alongside labeled ipsec.

Which would be a configuration error. There are lots of dangerous but  
useful tools (rm, dd). I have ipsec and netlabel configured. I'll try  
crossing the streams and see if we get total protonic reversal.

>  That is not an improvement.

We will have to disagree. It is a big improvement in functionality.  
It may not be the final approach, but it is the only one I can  
evaluate today.

joe

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Stephen Smalley]

On Thu, 2007-08-09 at 15:12 -0500, Joe Nall wrote:
> On Aug 9, 2007, at 2:47 PM, Darrel Goeddel wrote:
> >> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I  
> >> A L'
> >>
> >> for a connection from 10.211.55.8.
> >>
> >> This is a big improvement in linux labeled networking functionality.
> >
> > As described in an earlier email, from my not-yet-full grasp on the  
> > patch,
> > this is a vulnerability waiting to happen in the event of using  
> > netlabel
> > fallback contexts alongside labeled ipsec.
> 
> Which would be a configuration error. There are lots of dangerous but  
> useful tools (rm, dd). I have ipsec and netlabel configured. I'll try  
> crossing the streams and see if we get total protonic reversal.
> 
> >  That is not an improvement.
> 
> We will have to disagree. It is a big improvement in functionality.  
> It may not be the final approach, but it is the only one I can  
> evaluate today.

I think we all agree that it is important functionality to have, it is
just a matter of doing it in a way that works cleanly for all labeled
networking mechanisms (netlabel and labeled IPSEC) and ideally leverages
infrastructure that we already have (secmark).

-- 
Stephen Smalley
National Security Agency


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Joe Nall wrote:
> On Aug 9, 2007, at 2:47 PM, Darrel Goeddel wrote:
>>> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I  
>>> A L'
>>>
>>> for a connection from 10.211.55.8.
>>>
>>> This is a big improvement in linux labeled networking functionality.
>> As described in an earlier email, from my not-yet-full grasp on the  
>> patch,
>> this is a vulnerability waiting to happen in the event of using  
>> netlabel
>> fallback contexts alongside labeled ipsec.
> 
> Which would be a configuration error. There are lots of dangerous but  
> useful tools (rm, dd). I have ipsec and netlabel configured. I'll try  
> crossing the streams and see if we get total protonic reversal.

If netlabel and labeled ipsec are mutually exclusive, then the idea of
implementing the fallback contexts in netlabel is only helping one specific
use case and muddying the waters for a comprehensive solution in the future.
I think it is is a novel idea but not suitable for upstream inclusion on
those grounds.  If there were no conflicts with other existing labeling
mechanisms, I'd be all for it.

It also seems to be internally defining and external label, which seems to
be against the rules ;)

>>  That is not an improvement.
> 
> We will have to disagree. It is a big improvement in functionality.  
> It may not be the final approach, but it is the only one I can  
> evaluate today.

Agreed.  If the "fallback" context wouldn't actually replace a real peer
context supplied by the peer itself, this would be useful.  I'm sure it
can be made to operate this way if this patch set would be deemed the
way-to-go in the end.

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday, August 9 2007 5:18:28 pm Darrel Goeddel wrote:
> Agreed.  If the "fallback" context wouldn't actually replace a real peer
> context supplied by the peer itself, this would be useful.  I'm sure it
> can be made to operate this way if this patch set would be deemed the
> way-to-go in the end.

Darrel is right, I believe we can fix up the issues he presented today without 
too much fuss, however, at this point it's not clear to me this patchset 
would be accepted.  I'm happy to keep working on these patches, but I suspect 
it will get an explicit NACK from either James or Stephen; if one or both of 
you could clarify this I would appreciate it.

For better or worse I'm leaving tommorrow, August 10th, on vacation and I 
won't be back in front of a computer until the 20th.  I realized it's a bit 
of a "party-foul" to push a patch out for comments like this then disappear 
for a week, but up until today no one really had much to say about this idea 
so I wasn't quite expecting the discussion we had today ;)

That said, I'm sure you guys will keep talking about this (I hope you do 
anyway), just don't think I'm ignoring you - I'll do that when I get back ;)

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday, August 9 2007 3:47:43 pm Darrel Goeddel wrote:
> Joe Nall wrote:
> > On Aug 9, 2007, at 11:42 AM, Darrel Goeddel wrote:
> >>  (why couldn't this have all waited a bit...)
> >
> > Paul is addressing a real need. Like many things that really need
> > doing and take time, multiple people are simultaneously working on it.
> >
> > I installed the netlabel patches and have tested them with good
> > results in MLS/permissive at a few levels (s0, s2:c0.c253,
> > s2:c0.c253). More testing to follow.
> >
> > netlabelctl unlbl add interface:eth0 address:10.211.55.8/32
> > label:user_u:object_r:user_t:s2:c0.c253
> >
> > /netlabelctl unlbl list
> > accept:on
> > interface:eth0,address:
> > 192.168.20.253/32,label:"user_u:object_r:user_t:s0"
> > interface:eth0,address:
> > 10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"
> >
> > getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'
> >
> > for a connection from 10.211.55.8.
> >
> > This is a big improvement in linux labeled networking functionality.
>
> As described in an earlier email, from my not-yet-full grasp on the patch,
> this is a vulnerability waiting to happen in the event of using netlabel
> fallback contexts alongside labeled ipsec.  That is not an improvement.
> If there were consistency checks between the various forms of external
> labels, this would not be an issue and the functionality would indeed
> be an improvement.  Again, I do not have a test case, but Paul's response
> to my query about getpeercon returning a netlabel modified version of
> the xfrm label seemed to validate my concern.

This is more of a general issue between NetLabel and labeled IPsec, it is not 
specific to the fallback approach.  For better or worse, this particular 
problem is not new.

If the powers that be decide to redefine SECMARK and move forward with that 
approach then we can fix the issue with the new design.  If we want to fix it 
in the status quo we could probably do something like this ... (simple patch 
to describe a basic fix to the problem, not necessarily complete or even 
compile tested).

Index: linux-2.6_extlbl-fix/security/selinux/hooks.c
===================================================================
--- linux-2.6_extlbl-fix.orig/security/selinux/hooks.c
+++ linux-2.6_extlbl-fix/security/selinux/hooks.c
@@ -3152,7 +3152,14 @@ static void selinux_skb_extlbl_sid(struc
                                          SECINITSID_NETMSG : xfrm_sid),
                                         &nlbl_sid) != 0)
                nlbl_sid = SECSID_NULL;
-       *sid = (nlbl_sid == SECSID_NULL ? xfrm_sid : nlbl_sid);
+
+       if (nlbl_sid != SECSID_NULL && xfrm_sid != SECSID_NULL &&
+           nlbl_sid != xfrm_sid)
+               *sid = SECSID_NULL;
+       else if (nlbl_sid != SECSID_NULL)
+               *sid = nlbl_sid;
+       else
+               *sid = xfrm_sid;
 }

It's likely we would want/need a bit more, but I don't believe it's a 
difficult problem to fix with the current approach.  In fact, regardless of 
what we chose to do in the future, unless we can do it probably is a good 
idea to fix in in the current design as well.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Thursday 09 August 2007 10:09:14 am Darrel Goeddel wrote:
> Because of the position I am in (needing to find something workable for
> actual
> users), I have been trying to get my head aounrd the state of SELinux
> networking,
> the ideas that have been talked about in the past, and how we can prevent
> the
> SELinux networking infrastructure from resembling a Rube-Goldberg machine.
> I'll
> be presenting some of the problems I perceive along with some very high
> level
> ideas early next week.

Such a tease! ;)

I assume from other, previous discussions you are currently using the 
secid-reconciliation patches?

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Paul Moore wrote:
> On Thursday 09 August 2007 10:09:14 am Darrel Goeddel wrote:
>> Because of the position I am in (needing to find something workable for
>> actual
>> users), I have been trying to get my head around the state of SELinux
>> networking,
>> the ideas that have been talked about in the past, and how we can prevent
>> the
>> SELinux networking infrastructure from resembling a Rube-Goldberg
machine.
>> I'll
>> be presenting some of the problems I perceive along with some very high
>> level
>> ideas early next week.
> 
> Such a tease! ;)

Sorry, I'm getting slow as I age, and I'm going out of town tomorrow.

> I assume from other, previous discussions you are currently using the 
> secid-reconciliation patches?

Yes and no - we've evolved a bit from them.  We implemented a completely
orthogonal peer context mechanism - basically the "reconciled" sid and we
have that in an *cough*expanded*cough* skb.  We kept the idea of external
and internal labels (which, BTW, I find to be really unwieldy and confusing
in
practice - anyone else actually use this stuff?).  We have a hodgepodge that
keeps the standard RHEL5 idea in place and adds loopback labeling and flow
control.  It works but it is a bear to figure out and I wouldn't suggest it
for an upstream implementation.  Our constraint (self-imposed) for this
was "meet our needs without modifying already-in-place controls".  We need
to look at the big picture to get something sensible from the ground up
and not just tack more stuff on.  Our current implementation is not the
desired end goal - the community needs to come up with that somehow.

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Paul Moore wrote:
> On Thursday 09 August 2007 10:09:14 am Darrel Goeddel wrote:
>> Because of the position I am in (needing to find something workable for
>> actual
>> users), I have been trying to get my head aounrd the state of SELinux
>> networking,
>> the ideas that have been talked about in the past, and how we can prevent
>> the
>> SELinux networking infrastructure from resembling a Rube-Goldberg
machine.
>> I'll
>> be presenting some of the problems I perceive along with some very high
>> level
>> ideas early next week.
> 
> Such a tease! ;)

Here's a general high-level idea.  Remember that this is in no way a
proposal
(yet) because I'm not even sure if it makes sense.  It is a very simple
idea,
but it should prove to be flexible enough to handle everything.  I make no
claims as to its workability, or it implementability given the fact that we
should offer some kind of backwards compatibility.  I think this would be
something that one might come up with if they were starting from scratch (I
seriously doubt that the current mechanisms would ever come out of an
intentional up-front design).  It is just a vision of my perfect scenario
(perfect until I figure out that it doesn't do what I need it to do)...
Please try to look at this from a clean slate as well as a retrofit
point-of-view.

picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
(when commenting, please refrain from belittling my artistic skills)

The high level ideas are (I'll be using sid and context interchangeably,
but I think we can all figure that one out):

- The secmark (lowercase, denoting the secmark field in the skb) will
  always contain the peer's context.  The secmark will begin life as the
  unlabeled sid - we don't know who we are dealing with yet.  If the
  SECMARK (uppercase denoting the SECMARK iptables module) facility find
  a match for the skb, we will replace the secmark with the context
  specified by the matching rule - this is the fallback label, our best
  guess as to who we are dealing with.  In the event of the peer supplying
  context information (complete context via ipsec, mls level via cipso,
  or type information via carrier pigeon), the peer supplied context
  information will be evaluated and verified for some sort of consistency
  if there is more than one source of information.  If the context created
  with consideration of all peer supplied info checks out, that will then
  replace the current secmark value.  That's it for secmark - we now have
  the best idea of who the peer really is in there.

- OK, one more bit about what is in secmark.  For locally generated
  traffic, it is the domain of the process, err... socket.  Still the
  peer context, just from a real reliable source.

- The secmark, and nothing else, will be used for all flow control checks
  as well as the access check at consumption (process reading from the
  socket).  This means that policy represents who we can talk to, not
  what association we can use, or what socket we can recvfrom, or what
  internal label we can read from.  Yes, secmark does it all - yeah :)

- A new SECFILTER iptables module is in place to perform flow control
  checks.  Just as we have used the expressiveness (either fine grained
  or coarse grained - your choice) of iptables to define fallback labels
  for packets based on their attributes, we want to be able to define
  access check based on those attributes.  It is here where we can say
  that only http_client_t can get to port 80 on this machine, or that
  only a secret packet can leave the machine through the eth1 device.
  The SECFILTER mechanism will be able to distinguish controls for
  incoming, outgoing, and forwarded traffic.  In the absence of a
  matching "target context" from SECFILTER, the secmark will be checked
  against the unlabeled context (no SECFILTER - no label).  

- Since the secmark for locally generated traffic is the context of
  the sender and that is preserved as the packet gets bounced back up
  to the local peer, we have labeled localhost.  We can even put flow
  control checks on that to boot!

- getpeeron() will return the value of secmark.  This will be the same
  context that was actually used by the access check and it is the same
  context that considered locally defined fallbacks as well as peer
  supplied information.

so, I think these ideas would:
- provide flow control
- enable loopback labeling
- provide one label instead of three possibly conflicting labels for an
  skb
- streamline, simplify, make sense of access checks regarding skbs
- simplify understanding of what the skb context is - the peer's context
- enable a more reliable, safe, and informative getpeercon result


I'm not sure that any of these ideas are particularly new, but I'm
hoping that this particular combination of previously presented ideas
makes a bit of sense.  I'm sure that I will get tons of useful commentary
to incorporate, and I thank you in advance :)  That's why I wanted to
toss something out there now.

I'm off for a weekend trip, so please don't feel that I am ignoring all
of the scathing criticisms that will be coming tomorrow...  I'll ignore
all of that next week when I return ;)

We'll be working through some prototypes to make sure that the ideas
that we present are at least somewhat feasible - unlike the blue sky
idea presented here (although that'll get prototyped to see if it is
workable - I hope it is).

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Thu, 9 Aug 2007, Darrel Goeddel wrote:

> picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
> (when commenting, please refrain from belittling my artistic skills)

I think this looks good in terms of labeling via secmark, although it 
hides external labeling.

> - A new SECFILTER iptables module is in place to perform flow control
>   checks.  Just as we have used the expressiveness (either fine grained
>   or coarse grained - your choice) of iptables to define fallback labels
>   for packets based on their attributes, we want to be able to define
>   access check based on those attributes.  It is here where we can say
>   that only http_client_t can get to port 80 on this machine, or that
>   only a secret packet can leave the machine through the eth1 device.
>   The SECFILTER mechanism will be able to distinguish controls for
>   incoming, outgoing, and forwarded traffic.  In the absence of a
>   matching "target context" from SECFILTER, the secmark will be checked
>   against the unlabeled context (no SECFILTER - no label).  

This seems problematic.  The secmark model is currently based upon 
iptables rules being used to classify and label traffic, with access 
control performed within SELinux based upon those labels and permission 
types.  So, the access control decisions are performed via the AVC and 
according to SELinux policy.

In the case of local labeling, the packet is labeled based upon the port 
(and any other iptables selector), so you don't need to have a separate 
mechanism  i.e. the packet will only be labled as http_client_t if it's 
leaving via port 80 and also part of a validated connection.

Not sure what the answer is for applying controls to externally labeled 
packets.  It seems like a special case, though, and that typically, the 
network interface is the only thing you really want to check here.  If so, 
perhaps we implement a secmark (packet label) vs. netif check once 
external labeling has been applied.

So, the packet control permissions using secmark would be something like:

socket layer  : send, recv
network layer : flow_in, flow_forward, flow_out
link layer    : netif_in, netif_out

I think this will make sense to users due to the layering, and separation 
of labeling and access control.

The order of mediation is:

Inbound to local:
 
   netif_in -> flow_in -> recv

Forward:

   netif_in -> flow_forward -> netif_out

Outbound from local:

   send -> flow_out -> netif_out


Now, labeling is not so simple :-)

We have local labeling via secmark, which needs to be applied first and 
then potentially overridden.

Then we have two differnt forms of external labeling, with differing 
mechanisms and policy constructs.

For general and non-legacy users, we need to be focused on IPsec labeling.  

I'm not sure what the answer is for making it more usable at this stage, 
although if we don't make significant improvements, people will never use 
it.  Any bright ideas? :-)



- James 
-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

James Morris wrote:
> On Thu, 9 Aug 2007, Darrel Goeddel wrote:
> 
>> picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
>> (when commenting, please refrain from belittling my artistic skills)
> 
> I think this looks good in terms of labeling via secmark, although it 
> hides external labeling.

The external labeling was left (rather intentionally at this point) as a
black box.  The reason for this is that there can only be one label so just
wanted to show that the secmark field will be overidden with the
"peer provided" (external) label if it exists.  That could either be an xfrm
label, a netlbl label, or an *agreement* of the two.  In the case of CIPSO
over an labeled xfrm, I'd say that the xfrm context and the netlbl modified
context must be equal or the packet is dropped on the grounds that it is
invalid (can't be secret and top_secret all at once).  Once the peer
information has been taken into account, the idea of "external labeling"
goes away because we are now just dealing with the one and only label.

>> - A new SECFILTER iptables module is in place to perform flow control
>>   checks.  Just as we have used the expressiveness (either fine grained
>>   or coarse grained - your choice) of iptables to define fallback labels
>>   for packets based on their attributes, we want to be able to define
>>   access check based on those attributes.  It is here where we can say
>>   that only http_client_t can get to port 80 on this machine, or that
>>   only a secret packet can leave the machine through the eth1 device.
>>   The SECFILTER mechanism will be able to distinguish controls for
>>   incoming, outgoing, and forwarded traffic.  In the absence of a
>>   matching "target context" from SECFILTER, the secmark will be checked
>>   against the unlabeled context (no SECFILTER - no label).  
> 
> This seems problematic.  The secmark model is currently based upon 
> iptables rules being used to classify and label traffic, with access 
> control performed within SELinux based upon those labels and permission 
> types.  So, the access control decisions are performed via the AVC and 
> according to SELinux policy.

SECFILTER would be obtaining an access decision from the security server.
The subject of that access would be the secmark on the packet (peer domain)
and the object would be the context of the matching SECFILTER rule.  So
SECMARK provides the fallback for the subject label in the absense of a
peer-provided label and SECFILTER provides the object label.

An important aspect that is that there needs to be a check against the
unlabeled context if the SECFILTER mechanism did not provide a match to
ensure that the security server was consulted for every packet.  This
would catch the case where the modules was not active or the SECFILTER
ruleset was not able to match the traffic.

> In the case of local labeling, the packet is labeled based upon the port 
> (and any other iptables selector), so you don't need to have a separate 
> mechanism  i.e. the packet will only be labled as http_client_t if it's 
> leaving via port 80 and also part of a validated connection.
> 
> Not sure what the answer is for applying controls to externally labeled 
> packets.

There is no distinction here because the secmark is the only label, whether
or not the label came from a SECMARK rule like:

iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK \
        --selctx system_u:object_r:http_client_t:s0

or from a labeled xfrm, it is treated the same.

Since the SECMARK facility is just providing the fallback labels, the
actual flow controls are provided by the SECFILTER rules.  These rules
specify the "gates" that the skb is going to traverse.  Let's say we want
to make eth0 an "internal" only network and eth1 and external network -
we would have SECFILTER rules like:

iptables -t filter -A INPUT -i eth0 -j SECFILTER \
        --selctx system_u:object_r:internal_t:s0
iptables -t filter -A INPUT -i eth1 -j SECFILTER \
        --selctx system_u:object_r:external_t:s0
iptables -t filter -A OUTPUT -o eth0 -j SECFILTER \
        --selctx system_u:object_r:internal_t:s0
iptables -t filter -A OPTPUT -o eth1 -j SECFILTER \
        --selctx system_u:object_r:external_t:s0
iptables -t filter -A FORWARD -i eth0 -o eth1 -j SECFILTER \
        --selctx system_u:object_r:cross_the_line_t:s0
iptables -t filter -A FORWARD -i eth1 -o eth0 -j SECFILTER \
        --selctx system_u:object_r:cross_the_line_t:s0

The flow control policy arbitration would be defined as:

allow http_client_t packet:internal_t { flow_in flow_out };
allow httpd_t packet:internal_t { flow_in flow_out };

Maybe we want to allow external access from an ssl connection.  A
SECMARK rule like:

iptables -t mangle -A INPUT -p tcp --dport 443 -j SECMARK \
        --selctx system_u:object_r:https_client_t:s0

and policy like:

allow https_client_t packet:external_t { flow_in flow_out };
allow httpd_t packet:external_t { flow_in flow_out };

take care of that.  Note that httpd_t is the domain of the webserver
in the above examples.

> It seems like a special case, though, and that typically, the 
> network interface is the only thing you really want to check here.  If so,

> perhaps we implement a secmark (packet label) vs. netif check once 
> external labeling has been applied.
> 
> So, the packet control permissions using secmark would be something like:
> 
> socket layer  : send, recv

The recv check at the socket layer becomes socket (proxy for local process)
receiving information from the secmark (peer process).  This process vs.
process style check didn't seem to have a natural fit with sending the
information because the peer isn't as well known as it could be in the
receive case.  For this reason, send is actually absent in this idea right
now.
If there were a process vs. process check on send the peer process could
only
be identified through the SECMARK fallback labels.

> network layer : flow_in, flow_forward, flow_out
> link layer    : netif_in, netif_out

The flexibility of the SECFILTER mechanism should make it adequate for
these two.  My example above shows SECFILTER being used for the link layer
checks.  The thought had crossed my mind to include another layer earlier,
but then I realized that I was adding another check that probably wasn't
necessary.

> I think this will make sense to users due to the layering, and separation 
> of labeling and access control.
> 
> The order of mediation is:
> 
> Inbound to local:
>  
>    netif_in -> flow_in -> recv
> 
> Forward:
> 
>    netif_in -> flow_forward -> netif_out
> 
> Outbound from local:
> 
>    send -> flow_out -> netif_out

There's that darn send again...  The flow_out check from SECFILTER is really
performing the duties of the current send operation.  It would be providing
a way to say "can information from this process (with it's context conveyed
through the secmark on the skb) flow through this security gate?".  It is
here that one could say only httpd_t could flow_out to port 80, just like
SECMARK currently allows.  Note that this is a more granular approach to
constructing SECFILTER rules than I presented above.

The above layering makes perfect sense to me and I can live with that if it
is
deemed necessary.  Do you think the extra check will help with usability?
Usually
I would think that an extra thing to think about would make it harder, but I
am
not sure in this case.

> Now, labeling is not so simple :-)

Maybe that answers my question ;)

> We have local labeling via secmark, which needs to be applied first and 
> then potentially overridden.

Yep, this is our fallback in the absence of peer-provided information.

> Then we have two differnt forms of external labeling, with differing 
> mechanisms and policy constructs.
> 
> For general and non-legacy users, we need to be focused on IPsec labeling.


Yep, but they all convey the same information in this scheme - the label of
the peer process.  So the label is treated the same way no matter where it
comes from (as I mentioned above, I think simultaneous use of netlbl and
labeled xfrm should require and agreement on context).  IMHO, this
unification
of the label to one abstraction simplifies things greatly.  Now we can
always
perform the same check - "Can process A (local) receive info from process B
(peer)?".

> I'm not sure what the answer is for making it more usable at this stage, 
> although if we don't make significant improvements, people will never use 
> it.  Any bright ideas? :-)

Does anything I tried to clarify above shed a different light on things in
you eyes?  I think the basic tenants are:

- secmark is always the label of the peer, and getpeercon() returns it

- a packet goes though "filter points", the packet is the subject and the
 "filter point" is the object it must pass through (these filters happen
  at input, output, and forwarding)

- a socket reading a packet must be able to listen to the peer that created
 it - a slightly new meaning for current socket vs. secmark access check

This is a drastic simplification of the whole system.  I think it is much
easier from a conceptual level and it allows more control that the previous
system.  I'm just wondering what hidden problems there are with the
simplification?

-- 

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Tue, 14 Aug 2007, Darrel Goeddel wrote:

> The recv check at the socket layer becomes socket (proxy for local 
> process)
> receiving information from the secmark (peer process).  This process vs.
> process style check didn't seem to have a natural fit with sending the
> information because the peer isn't as well known as it could be in the
> receive case.  For this reason, send is actually absent in this idea 
> right now.
> If there were a process vs. process check on send the peer process could
> only
> be identified through the SECMARK fallback labels.

Perhaps I'm missing something, but the send check is necessary for e.g. 
"can a httpd_server_t socket send an smtp_client_t packet" ?

What you're calling fallback labels will likely be the only labels a 
normal user encounters.

> There's that darn send again...  The flow_out check from SECFILTER is 
> really performing the duties of the current send operation.

I think there's a slight misunderstanding here.  I'm proposing not having 
SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.

Discussion of security gates and similar I think will really confuse 
people, as will the idea of labeling such abstract entities, which is 
heading down a similar path to earlier proposals on this topic.

> - a packet goes though "filter points", the packet is the subject and the
>  "filter point" is the object it must pass through (these filters happen
>   at input, output, and forwarding)

What they really are is the boundary of network layer of the machine, 
which is to say, the boundary of machine itself in terms of network 
functionality.  i.e. once a packet is accepted into the IP stack, it can 
be forwarded, delivered etc.

So, allowing flow_in means "the packet can flow into this machine", and 
similar for flow_forward and flow_out.

The socket recv/send checks are against the endpoint (at least, as 
delegated by an authorized endpoint via the socket).

The netif_in and netif_out allow checking of the packet flowing across 
specific physical interfaces.

I don't think we need to add any new abstractions here, and these should 
be understandable by people who can configure networking.

> - a socket reading a packet must be able to listen to the peer that 
>   created it - a slightly new meaning for current socket vs. secmark 
>   access check

I'm not sure what this means.


-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

James Morris wrote:
> On Tue, 14 Aug 2007, Darrel Goeddel wrote:
> 
>> The recv check at the socket layer becomes socket (proxy for local 
>> process)
>> receiving information from the secmark (peer process).  This process vs.
>> process style check didn't seem to have a natural fit with sending the
>> information because the peer isn't as well known as it could be in the
>> receive case.  For this reason, send is actually absent in this idea 
>> right now.
>> If there were a process vs. process check on send the peer process could
>> only
>> be identified through the SECMARK fallback labels.
> 
> Perhaps I'm missing something, but the send check is necessary for e.g. 
> "can a httpd_server_t socket send an smtp_client_t packet" ?

The send check would be necessary for that particular type of check.  In
the proposed scheme, that particular question would never arise.  The
skb is merely an extension of the socket, much as the socket is an
extension of the process.  The question is now "can httpd_server_t
flow_out of an smtp_t network entity?"  I'm having trouble coming up with
nice terminology for that one.  How's this for the question - "can an
httpd_server_t packet go to a destination with certain characteristics?"

> What you're calling fallback labels will likely be the only labels a 
> normal user encounters.

That is correct.  In the absence of labeled network (just about all cases),
the SECMARK facility will provide the label of the peer.

>> There's that darn send again...  The flow_out check from SECFILTER is 
>> really performing the duties of the current send operation.
> 
> I think there's a slight misunderstanding here.  I'm proposing not having 
> SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.

That would provide flow control only at the interface level.  That is
certainly better than the current lack of flow control ability, but it
does not offer the flexibility of the iptables mechanism.  It also gives us
different controls over forwarded traffic.  Instead of the ability of
the unique forward check that SECFILTER would provide, we are limited
to using the in and out netif checks.  We can no longer say that sysadm_t
traffic can come into the machine, sysadm_t traffic can go out of the
machine, but sysadm_t traffic can not pass through the machine.

> Discussion of security gates and similar I think will really confuse 
> people, as will the idea of labeling such abstract entities, which is 
> heading down a similar path to earlier proposals on this topic.

I think a lot of the previous confusion came from some of the
following points:

- trying to use secmark as BOTH an implicit fallback context AND
 a flow control point
- the transitions from secmark to xfrm to NetLabel, etc., that were
 thrown in to allow domain->packet->domain

I'm avoiding those issues with these simple rules:

- SECMARK is used only for establishing a fallback context for the peer
- SECFILTER is used only for performing the flow control checks
- the packet always carries the peer's context, not a data context

>> - a packet goes though "filter points", the packet is the subject and the
>>  "filter point" is the object it must pass through (these filters happen
>>   at input, output, and forwarding)
> 
> What they really are is the boundary of network layer of the machine, 
> which is to say, the boundary of machine itself in terms of network 
> functionality.  i.e. once a packet is accepted into the IP stack, it can 
> be forwarded, delivered etc.
> 
> So, allowing flow_in means "the packet can flow into this machine", and 
> similar for flow_forward and flow_out.
> 
> The socket recv/send checks are against the endpoint (at least, as 
> delegated by an authorized endpoint via the socket).

The recv check makes sense.  The socket is getting a packet from peer
peer_domain_t:secret, can the socket read that in?  The label of
peer_domain_t:secret came from the SECMARK mechanism which arrived at
that label based on the characteristics of the sender.  The
peer_domain_t:secret could have just as easily been explicitly conveyed
by the sender.

Does it make sense to make that check for outgoing traffic?  There is
no way to have peer-provided information about the receiver, you only
know where the info is going, not who will actually get it.  Yes, I
understand that I double standard here because I somehow believe that
the src characteristics for incoming packets are more useful than the
dst characteristics for outgoing packets.  I don't love outgoing
packets any less - I am giving the incoming more credibility because
there _can_ be real information about the context in that case.

Using SECMARK for the target of the outgoing access check means that we
are back to needing another place to store the "target" info in the skb,
or the SECMARK module will be performing the access check (via LSM to
the security server) :(  This is the reason SECFILTER came about - to
separate the labeling mechanism from the enforcement mechanism.  I
think the separation adds clarity.

SECFILTER really is doing the same job for outgoing traffic as the current
usage of SECMARK, the only difference is that the subject comes from the
skb (same as the socket for locally generated traffic) and the decision
is made in the SECFILTER module, not delayed (which needs storage) until
later.

I'll bang my head around here to see what kind of functionality would be
missing (as opposed to the SECMARK/SECFILTER combo) with what you are
suggesting.  I'll try to come up with some diagrams for the different
methods that are being discussed to make sure we are on the same page.
Since you are going for "no SECFILTER", how are you envisioning the
network layer checks you described before being (flow_in, flow_forward,
flow_out) handled?  Or are you saying the idea should go, not just the
SECFILTER way of doing it?

> The netif_in and netif_out allow checking of the packet flowing across 
> specific physical interfaces.
> 
> I don't think we need to add any new abstractions here, and these should 
> be understandable by people who can configure networking.
> 
>> - a socket reading a packet must be able to listen to the peer that 
>>   created it - a slightly new meaning for current socket vs. secmark 
>>   access check
> 
> I'm not sure what this means.

The socket vs. secmark check conceptually means "can the local process
read this type of information" right now.  By having the secmark field
always convey the context of the peer, the check takes on a slightly
different meaning - "can the local process read information written by
the peer process?".

-- 

Darrel



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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Wed, 15 Aug 2007, Darrel Goeddel wrote:

> > 
> > Perhaps I'm missing something, but the send check is necessary for e.g. 
> > "can a httpd_server_t socket send an smtp_client_t packet" ?
> 
> The send check would be necessary for that particular type of check.  In
> the proposed scheme, that particular question would never arise.  The
> skb is merely an extension of the socket, much as the socket is an
> extension of the process.  The question is now "can httpd_server_t
> flow_out of an smtp_t network entity?"  I'm having trouble coming up with
> nice terminology for that one.  How's this for the question - "can an
> httpd_server_t packet go to a destination with certain characteristics?"

I don't see the problem.  The skb is labeled by SECMARK and optionally 
external labeling, and then the check is applied.

There is no need for for new terminology or abstractions, it is simply 
"Can socket_t send packet_t" ?

> > What you're calling fallback labels will likely be the only labels a 
> > normal user encounters.
> 
> That is correct.  In the absence of labeled network (just about all cases),
> the SECMARK facility will provide the label of the peer.

Not really.  It will be a label describing what we know about the packet, 
which in the case of local labeling, is based only on local attributes 
(e.g. destination port, derived from existing connection etc.).

Once external labeling is applied, what we know will become more specific, 
and ultimately, could be the label of the peer.

> >> There's that darn send again...  The flow_out check from SECFILTER is 
> >> really performing the duties of the current send operation.
> > 
> > I think there's a slight misunderstanding here.  I'm proposing not having 
> > SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.
> 
> That would provide flow control only at the interface level.  That is
> certainly better than the current lack of flow control ability, but it
> does not offer the flexibility of the iptables mechanism.

It's not needed here -- the flexibility is provided in the selection and 
classification of packets.  What you need here is the ability to control 
which interfaces a packet can flow across, and this does not call for the 
use of a generalized and separate mechanism.

> It also gives us
> different controls over forwarded traffic.  Instead of the ability of
> the unique forward check that SECFILTER would provide, we are limited
> to using the in and out netif checks.  We can no longer say that sysadm_t
> traffic can come into the machine, sysadm_t traffic can go out of the
> machine, but sysadm_t traffic can not pass through the machine.

The forward check will be performed via the flow_forward hook.

> > Discussion of security gates and similar I think will really confuse 
> > people, as will the idea of labeling such abstract entities, which is 
> > heading down a similar path to earlier proposals on this topic.
> 
> I think a lot of the previous confusion came from some of the
> following points:
> 
> - trying to use secmark as BOTH an implicit fallback context AND
>  a flow control point
> - the transitions from secmark to xfrm to NetLabel, etc., that were
>  thrown in to allow domain->packet->domain
> 
> I'm avoiding those issues with these simple rules:
> 
> - SECMARK is used only for establishing a fallback context for the peer

Not in the general case, only when external labeling is in use.

> - SECFILTER is used only for performing the flow control checks

Unnecessary and complicated.  SELinux hooks can do this within the 
existing framework.

> - the packet always carries the peer's context, not a data context

What is a "data context"?

The label always simply has the most specific current information about 
the packet.  It may be some default for all packets, it may be based upon 
local attributes, or it may carry the label of the peer.

> >> - a packet goes though "filter points", the packet is the subject and 
> >>   the "filter point" is the object it must pass through (these 
> >>   filters happen
> >>   at input, output, and forwarding)
> > 
> > What they really are is the boundary of network layer of the machine, 
> > which is to say, the boundary of machine itself in terms of network 
> > functionality.  i.e. once a packet is accepted into the IP stack, it can 
> > be forwarded, delivered etc.
> > 
> > So, allowing flow_in means "the packet can flow into this machine", and 
> > similar for flow_forward and flow_out.
> > 
> > The socket recv/send checks are against the endpoint (at least, as 
> > delegated by an authorized endpoint via the socket).
> 
> The recv check makes sense.  The socket is getting a packet from peer
> peer_domain_t:secret, can the socket read that in?  The label of
> peer_domain_t:secret came from the SECMARK mechanism which arrived at
> that label based on the characteristics of the sender.  The
> peer_domain_t:secret could have just as easily been explicitly conveyed
> by the sender.
> 
> Does it make sense to make that check for outgoing traffic?  There is
> no way to have peer-provided information about the receiver, you only
> know where the info is going, not who will actually get it.  Yes, I
> understand that I double standard here because I somehow believe that
> the src characteristics for incoming packets are more useful than the
> dst characteristics for outgoing packets.  I don't love outgoing
> packets any less - I am giving the incoming more credibility because
> there _can_ be real information about the context in that case.

So, you trust the characteristics of a packet arriving from the network 
more than those on locally generated packets?

Keep in mind that we are also able to leverage connection tracking, so the 
vast majority of packet labeling via secmark will have been validated as 
being part of an existing connection.

> Using SECMARK for the target of the outgoing access check means that we
> are back to needing another place to store the "target" info in the skb,

I need a concrete example.  What target information?  How is it used?

> SECFILTER really is doing the same job for outgoing traffic as the current
> usage of SECMARK, the only difference is that the subject comes from the
> skb (same as the socket for locally generated traffic) and the decision
> is made in the SECFILTER module, not delayed (which needs storage) until
> later.

I don't understand.

> I'll bang my head around here to see what kind of functionality would be
> missing (as opposed to the SECMARK/SECFILTER combo) with what you are
> suggesting.  I'll try to come up with some diagrams for the different
> methods that are being discussed to make sure we are on the same page.
> Since you are going for "no SECFILTER", how are you envisioning the
> network layer checks you described before being (flow_in, flow_forward,
> flow_out) handled?  Or are you saying the idea should go, not just the
> SECFILTER way of doing it?

Well, we need something for the forwarding case at least.  Is it enough to 
have just a flow_forward check which matches the packet label against 
kernel_t ?  

e.g. "Can this machine forward a packet labeled intranet_t" ?

> 
> > The netif_in and netif_out allow checking of the packet flowing across 
> > specific physical interfaces.
> > 
> > I don't think we need to add any new abstractions here, and these should 
> > be understandable by people who can configure networking.
> > 
> >> - a socket reading a packet must be able to listen to the peer that 
> >>   created it - a slightly new meaning for current socket vs. secmark 
> >>   access check
> > 
> > I'm not sure what this means.
> 
> The socket vs. secmark check conceptually means "can the local process
> read this type of information" right now. 

The secmark label can be anything at all, so it means whatever its labeled 
with.  e.g. someone could label all traffic passing over eth0 as "secret", 
or "sysadm_t"

> By having the secmark field
> always convey the context of the peer, the check takes on a slightly
> different meaning - "can the local process read information written by
> the peer process?".

As mentioned, it carries the most specific currently available information 
about the packet.  What it means in terms of distributed information flow 
is thus context-specific.

Without a specific field for e.g. peer_sid, which always only means the 
peer, policy development & analysis will need to be "aware" of what the 
label represents in a specific situation.

I think this is an acceptable trade-off, as the users of external labeling 
where such concepts are also critical also tend to have access to policy 
expertise and can tightly control the policy and deployment.


- James
-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

For those of you who are still paying attention to this thread you may have 
been wondering why it went quiet all of a sudden; well, the thread didn't go 
quiet, it went off-list.  Needless to say, we'd like to bring the discussion 
back on-list so that others can participate, or at the very least get some 
cheap entertainment on a Friday afternoon.  The discussion was pretty lively 
so it's not really practical to replay the entire off-list thread here but 
I'll try to hit upon where we are currently at as well as some of the 
highlights that brought us to this point.

If anyone who was a part of the discussion has anything to add to these notes, 
feel free.

 * Packet labels (one or two)

There was quite a bit of debate about the possibility of going from the two 
packet labels we have currently, external and internal, to a single packet 
label.  In order to consolidate the two labels there were two approaches 
considered: a form of "reconciliation" similar to what was discussed earlier 
this year, and the elimination of internal labels so that only the external 
label would be used.  After much discussion it was deemed that the two 
labels, as currently defined/used, are truly independent labels used for two 
different purposes and that "reconciliation" was still a bad idea and should 
not be pursued.  Further, while SECMARK and internal labeling have been slow 
to be adopted in the major distributions it still serves a useful purpose and 
should not be eliminated.  The end result was the majority, including Stephen 
and James, voting to continue with the two packet labels as they currently 
exist.

One thing that did arise during the discussion was the slow realization that 
the names for the two packet labels are probably not as descriptive as they 
should be and that has most likely led to a certain amount of confusion.  In 
an effort to help make the two different label types more clear it was 
decided to start calling the external labels "peer labels" as the external 
label always represents the label of the peer who originated the packet and 
it's data.  It was also decided to start calling the internal labels "secmark 
labels", while the compat_net mechanism still exists it is deprecated in 
favor of the SECMARK mechanism which is the only way to set/manipulate the 
internal label.

As a reminder, below is a definition of the two types of labels.

Secmark, or internal, labels are essentially a means for integrating the 
traditional firewall rules with SELinux mandatory access controls.  The 
secmark labels allow policy writers and security administrators to meet 
security goals similar to the following:
 "Only allow Apache to accept connections over tcp/80 from 
  192.168.0.0/24, restricting it to my local network and not
  the Big-Bad-Internet."
 -- or --
 "Only allow a particular instance of Firefox to connect to
  1.2.3.4 over tcp/443, restricting it to my online banking
  site."

Peer, or external, labels, furnished by NetLabel or labeled IPsec/XFRM, 
provide the domain/context/label of the process which generated the 
packet/data.  The external labels allow policy writers and security 
administrators to meet security goals similar to the following:
 "This instance of Apache serves sensitive financial data and
  I only want specific clients/peers/domains to be able to access
  the data from this Apache instance."
 -- or --
 "I want to ensure that users connecting to the login server over
  a Secret connection run in a Secret domain."

 * Splitting the SECMARK field

After it was agreed to continue using both the peer and secmark labels the 
discussion turned to how best to propagate those labels with the packet.  As 
you probably know there is a 32 bit field already in the packet/sk_buff 
structure which is currently used exclusively by the secmark label.  Once 
again, there were two approaches considered.  The first was the continuation 
of the status quo where the secmark label is determined by looking directly 
at the secmark field in the sk_buff, "sk_buff.secmark", and the peer label is 
determined through a function call with the sk_buff as an 
argument, "peer_label(sk_buff)".  The second idea was to divide the secmark 
field in the sk_buff into two 16 bit sub-fields effectively shortening peer 
and secmark SIDs to 16 bits.

While there is still no final agreement on the best way forward, there does 
seem to be agreement that the split secmark field offers a good deal of 
implementation convenience/cleanliness but it requires either a reduction in 
the system's SID space from 32 bits to 16 bits (4.<mumble> billion unique 
labels down to 65 thousand unique labels for all subjects/objects on the 
system) or some sort of additional internal SID mapping mechanism which has 
yet to be defined.  Both of which have the potential for introducing 
compatibility problems.

 * Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it 
would be simple to achieve but in practice it has proven quiet difficult to 
implement.  Current solutions to the problem involve using either 
NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, 
unfortunately both have drawbacks.  NetLabel/CIPSO is currently limited to 
only conveying the MLS sensitivity label over the wire and only then for IPv4 
packets.  Labeled IPsec can convey the full SELinux label/context of the peer 
for both IPv4 and IPv6 but is difficult to configure and introduces 
unnecessary overhead for packets that never leave the machine.

The solution for this problem is tightly coupled with the decision to 
split/not-split the secmark field in the sk_buff structure.  If the secmark 
field were split then the peer label could be set directly in the packet to 
the originating socket and then preserved across the loopback 
pseudo-interface for use on the receiving/inbound side.  However, this does 
require splitting the secmark field and all that goes along with it (see 
above).  If the secmark field were not split then the solution is to continue 
to develop the peer labeling mechanisms to support loopback labeling.  Joy 
Latten from IBM has been working on better support for IPsec over loopback 
(although I'm not sure of it's current status) and I am steadily working 
towards a more full featured NetLabel which would be able to convey a full 
SELinux context over the wire/loopback.

 * Packet flow control

Another long standing goal that has not seen much success over the years.  The 
two approaches currently being considered are: per-interface checks against 
the peer label with the possibility of an additional forwarding hook/check if 
needed for labeling purposes, as well as an iptables based filtering 
mechanism which has already been discussed off and on on the public SELinux 
and LSPP mailing lists (SECFILTER/SECPOINT).  The idea behind the iptables 
based filtering mechanism is that "filter points" could be defined using 
iptables/netfilter which would provide very granular access control checks.  
The big question that is currently being debated is how much granularity is 
needed and how much makes sense? 

 * Fallback labels

The simple idea that started this whole discussion.  The need for a usable 
peer label fallback mechanism is understood by everyone but the granularity 
with which peer fallback labels are assigned are still a source of debate.  
The idea is wether the granularity proposed in this NetLabel patchset which 
allows per-host/subnet granularity for each interface is enough, and if not 
is a very granular iptables/netfilter peer label assignment of fallback 
labels required?  This topic did come up briefly some time ago on the public 
mailing list between Joshua Brindle and myself and we agreed that the 
granularity presented in this patchset is sufficient, however, not everyone 
feels this way so we are still discussing the best solution.

As part of the peer fallback label discussion it became apparent to everyone 
that better integration/cooperation between the NetLabel and XFRM labeling 
mechanisms is needed.  The strict separation worked well in the beginning but 
as we start to develop a richer set of functionality the two labeling 
mechanisms need to work better together to ensure the consistency of the 
network access controls.  If the approach put forward in this patch set is 
agreed upon as the right way to solve the peer fallback problem I will be 
modifying it to take into account XFRM labels so that the NetLabel provided 
fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO 
label on the packet.  Further, work will be done to ensure that when both a 
XFRM and NetLabel/CIPSO label are present on an incoming packet that the 
labels are the same, otherwise the packet will be dropped/rejected.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Fri, 24 Aug 2007, Paul Moore wrote:

> implementation convenience/cleanliness but it requires either a reduction in 
> the system's SID space from 32 bits to 16 bits (4.<mumble> billion unique 
> labels down to 65 thousand unique labels for all subjects/objects on the 
> system) or some sort of additional internal SID mapping mechanism which has 
> yet to be defined.

To clarify, with a network SID mapper, it means that we are only limiting 
the total number of SIDs being used over the wire at some time, not the 
total number of SIDs on the system.

Decoupling network representation of SIDs is likely a good idea anyway, 
for this and NFS.


- James
-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> For those of you who are still paying attention to this thread you may have 
> been wondering why it went quiet all of a sudden; well, the thread didn't go 
> quiet, it went off-list.

Boo.

> ...
> 
>  * Packet labels (one or two)
> 
> ... voting to continue with the two packet labels as they currently 
> exist.

For SELinux this appears prudent. For those using other schemes
the difference may be less obvious, but I see you discuss that
more below.

> One thing that did arise during the discussion was the slow realization that 
> the names for the two packet labels are probably not as descriptive as they 
> should be and that has most likely led to a certain amount of confusion.  In 
> an effort to help make the two different label types more clear it was 
> decided to start calling the external labels "peer labels" as the external 
> label always represents the label of the peer who originated the packet and 
> it's data.  It was also decided to start calling the internal labels "secmark
> 
> labels", while the compat_net mechanism still exists it is deprecated in 
> favor of the SECMARK mechanism which is the only way to set/manipulate the 
> internal label.

Hmm. In one case the name reflects the purpose (label of peer) and
in the other the name reflects the mechanism (label used in SECMARK).
I like the clarification of the former as it tells an LSM writer
what to use the label for, while I dislike the latter because it
does nothing to help me understand the intent of the mechanism.
 
> As a reminder, below is a definition of the two types of labels.
> 
> Secmark, or internal, labels are essentially a means for integrating the 
> traditional firewall rules with SELinux mandatory access controls.

Is it really intended that Secmark is an SELinux specific mechanism?
Yes, yes, I understand that SELinux is the only upstream LSM and all
that. If it is intended only as a component of SELinux going forward
regardless of alternative LSM availability maybe that should be more
explicit in the related documentation. I would personally be
disappointed if the mechanism were unavailable to other LSMs, but that
is of course your call.

> The 
> secmark labels allow policy writers and security administrators to meet 
> security goals similar to the following:
>  "Only allow Apache to accept connections over tcp/80 from 
>   192.168.0.0/24, restricting it to my local network and not
>   the Big-Bad-Internet."
>  -- or --
>  "Only allow a particular instance of Firefox to connect to
>   1.2.3.4 over tcp/443, restricting it to my online banking
>   site."
> 
> Peer, or external, labels, furnished by NetLabel or labeled IPsec/XFRM, 
> provide the domain/context/label of the process which generated the 
> packet/data.

As I mentioned earlier, I like this definition because it describes
the intent of the facility and provides guidance to those who would
extend the facility or use it to other ends.

> The external labels allow policy writers and security 
> administrators to meet security goals similar to the following:
>  "This instance of Apache serves sensitive financial data and
>   I only want specific clients/peers/domains to be able to access
>   the data from this Apache instance."
>  -- or --
>  "I want to ensure that users connecting to the login server over
>   a Secret connection run in a Secret domain."
> 
>  * Splitting the SECMARK field
> 
> After it was agreed to continue using both the peer and secmark labels the 
> discussion turned to how best to propagate those labels with the packet.  As 
> you probably know there is a 32 bit field already in the packet/sk_buff 
> structure which is currently used exclusively by the secmark label.  Once 
> again, there were two approaches considered.  The first was the continuation 
> of the status quo where the secmark label is determined by looking directly 
> at the secmark field in the sk_buff, "sk_buff.secmark", and the peer label is
> 
> determined through a function call with the sk_buff as an 
> argument, "peer_label(sk_buff)".

Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff),
or security_peer_label(sk_buff)?

> The second idea was to divide the secmark ... the potential for
> introducing compatibility problems.

Yup.

>  * Loopback/Localhost peer packet labeling
> 
> This has been a long standing requirement which at first glance seems like it
> 
> would be simple to achieve but in practice it has proven quiet difficult to 
> implement.  Current solutions to the problem involve using either 
> NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, 
> unfortunately both have drawbacks.  NetLabel/CIPSO is currently limited to 
> only conveying the MLS sensitivity label over the wire and only then for IPv4
> 
> packets.  Labeled IPsec can convey the full SELinux label/context of the peer
> 
> for both IPv4 and IPv6 but is difficult to configure and introduces 
> unnecessary overhead for packets that never leave the machine.

In the early Smack development I experimented with a scheme that
was very like CIPSO with the exception that it carried the MAC
information directly. That would be a smack_t for me, but it
would do u32s just fine. I abandoned it in favor of CIPSO to
reduce the changes outside of the LSM, but it would be easy to
resurrect. It has the disadvantage that you have to be careful
to avoid going off the box since there's no RFC supporting it.
I seem to recall there is an "approved" scheme lurking in the
networking header files, but I never persued that.

> The solution for this problem is tightly coupled with the decision to 
> split/not-split the secmark field in the sk_buff structure.  If the secmark 
> field were split then the peer label could be set directly in the packet to 
> the originating socket and then preserved across the loopback 
> pseudo-interface for use on the receiving/inbound side.  However, this does 
> require splitting the secmark field and all that goes along with it (see 
> above).  If the secmark field were not split then the solution is to continue
> 
> to develop the peer labeling mechanisms to support loopback labeling.  Joy 
> Latten from IBM has been working on better support for IPsec over loopback 
> (although I'm not sure of it's current status) and I am steadily working 
> towards a more full featured NetLabel which would be able to convey a full 
> SELinux context over the wire/loopback.

So how big is a "full" context?

>  * Packet flow control
> 
> ... 
> 
>  * Fallback labels
> 
> The simple idea that started this whole discussion.  The need for a usable 
> peer label fallback mechanism is understood by everyone but the granularity 
> with which peer fallback labels are assigned are still a source of debate.  
> The idea is wether the granularity proposed in this NetLabel patchset which 
> allows per-host/subnet granularity for each interface is enough, and if not 
> is a very granular iptables/netfilter peer label assignment of fallback 
> labels required?  This topic did come up briefly some time ago on the public 
> mailing list between Joshua Brindle and myself and we agreed that the 
> granularity presented in this patchset is sufficient, however, not everyone 
> feels this way so we are still discussing the best solution.
> 
> As part of the peer fallback label discussion it became apparent to everyone 
> that better integration/cooperation between the NetLabel and XFRM labeling 
> mechanisms is needed.  The strict separation worked well in the beginning but
> 
> as we start to develop a richer set of functionality the two labeling 
> mechanisms need to work better together to ensure the consistency of the 
> network access controls.  If the approach put forward in this patch set is 
> agreed upon as the right way to solve the peer fallback problem I will be 
> modifying it to take into account XFRM labels so that the NetLabel provided 
> fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO
> 
> label on the packet.  Further, work will be done to ensure that when both a 
> XFRM and NetLabel/CIPSO label are present on an incoming packet that the 
> labels are the same, otherwise the packet will be dropped/rejected.

It makes me uncomfortable to hear you say that XFRM is SELinux specific
and that it needs to be integrated with NetLabel, which currently isn't.
I know that Smack isn't upstream yet. Nonetheless, I would hate to see
underlying mechanisms that currently provide useful facilities become
SELinux specific.

Thank you.


Casey Schaufler
casey@schaufler-ca.com

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Friday, August 24 2007 3:02:00 pm Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > For those of you who are still paying attention to this thread you may
> > have been wondering why it went quiet all of a sudden; well, the thread
> > didn't go quiet, it went off-list.
>
> Boo.

I know, I know ...

> > One thing that did arise during the discussion was the slow realization
> > that the names for the two packet labels are probably not as descriptive
> > as they should be and that has most likely led to a certain amount of
> > confusion.  In an effort to help make the two different label types more
> > clear it was decided to start calling the external labels "peer labels"
> > as the external label always represents the label of the peer who
> > originated the packet and it's data.  It was also decided to start
> > calling the internal labels "secmark labels", while the compat_net
> > mechanism still exists it is deprecated in favor of the SECMARK mechanism
> > which is the only way to set/manipulate the internal label.
>
> Hmm. In one case the name reflects the purpose (label of peer) and
> in the other the name reflects the mechanism (label used in SECMARK).
> I like the clarification of the former as it tells an LSM writer
> what to use the label for, while I dislike the latter because it
> does nothing to help me understand the intent of the mechanism.

Feel free to suggest something better, I don't think anyone was ever really in 
love with the term "secmark label".  I believe at one point Stephen 
suggested "iptables label", does that sound any better?

> > As a reminder, below is a definition of the two types of labels.
> >
> > Secmark, or internal, labels are essentially a means for integrating the
> > traditional firewall rules with SELinux mandatory access controls.
>
> Is it really intended that Secmark is an SELinux specific mechanism?

I don't see why it _has_ to be a SELinux specific mechanism.  I understand 
that some of the netfilter code is SELinux specific (mostly the part dealing 
with SELinux secctx/secid conversions) but you could either change that to 
the more generic LSM secctx/secid conversion API or simply augment it for 
SMACK (I even see some nice case statements already in place to make things 
easy for you).

However, all of this assumes that the LSM has a functional 
label-to-32bit-token mapping mechanism similar to what SELinux has with the 
SID concept.  I know, and understand why, you are not a big fan of this for 
SMACK but secids/tokens are a reality in several parts of the kernel and I 
don't expect that to change anytime soon.  You don't have to implement a 
label/token mapping mechanism I guess, but you won't be able to make use of 
kernel subsystems which require it.

> Yes, yes, I understand that SELinux is the only upstream LSM and all
> that. If it is intended only as a component of SELinux going forward
> regardless of alternative LSM availability maybe that should be more
> explicit in the related documentation.

Documentation?  Who has documentation?!  ;)

You make a good point, one that became clear to me over the course of the 
discussion is that we need better documentation about the SELinux/LSM network 
access controls work in the kernel.  Josh wrote up a nice blog entry a while 
ago about how to make some of it work in userspace (no NetLabel instructions, 
though ... tsk tsk <g>!) but we don't have anyting for kernel hack[er]s.  One 
of the things that made it on to my todo list (but I haven't shared this with 
anyone until now) is a document/wiki-entry describing how things work in the 
kernel, and I'll be sure to point out which things are SELinux specific 
(which is pretty few, if any).

> I would personally be 
> disappointed if the mechanism were unavailable to other LSMs, but that
> is of course your call.

As long as their is an LSM my opinion is that all mechanisms which live 
outside the LSM and/or provide services to LSM modules should be agnostic of 
any one particular LSM.  However, this does not mean that the is must deal 
only with binary/string/secctx labels; if it makes sense to deal strictly 
with secid tokens then so be it.

> >  * Splitting the SECMARK field
> >
> > After it was agreed to continue using both the peer and secmark labels
> > the discussion turned to how best to propagate those labels with the
> > packet.  As you probably know there is a 32 bit field already in the
> > packet/sk_buff structure which is currently used exclusively by the
> > secmark label.  Once again, there were two approaches considered.  The
> > first was the continuation of the status quo where the secmark label is
> > determined by looking directly at the secmark field in the sk_buff,
> > "sk_buff.secmark", and the peer label is
> >
> > determined through a function call with the sk_buff as an
> > argument, "peer_label(sk_buff)".
>
> Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff),
> or security_peer_label(sk_buff)?

At this point I'm thinking this would be internal/specific to the LSM; SMACK 
and other LSMs cand devise whatever internal mechanism they want.  SMACK for 
example only has one labeling mechanism that I can see so this is kind of a 
moot point for you, just make use of the NetLabel API to get the security 
attributes/label of a packet.  For SELinux it's not quite so simple as both 
NetLabel and XFRM can provide peer label information, in order to make it 
easier I was suggesting providing a single wrapper function that would take 
into account all peer labeling mechanisms and return the correct peer label.

> >  * Loopback/Localhost peer packet labeling
> >
> > This has been a long standing requirement which at first glance seems
> > like it
> >
> > would be simple to achieve but in practice it has proven quiet difficult
> > to implement.  Current solutions to the problem involve using either
> > NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
> > unfortunately both have drawbacks.  NetLabel/CIPSO is currently limited
> > to only conveying the MLS sensitivity label over the wire and only then
> > for IPv4
> >
> > packets.  Labeled IPsec can convey the full SELinux label/context of the
> > peer
> >
> > for both IPv4 and IPv6 but is difficult to configure and introduces
> > unnecessary overhead for packets that never leave the machine.
>
> In the early Smack development I experimented with a scheme that
> was very like CIPSO with the exception that it carried the MAC
> information directly.

I am thinking along the same lines for NetLabel/CIPSO, similar to the old 
Selopt concept.  I'm also considering adding some additional fields/info to 
carry additional information that used to passed along via MaxSix/SAMP; more 
on that when I get to that work item.

> That would be a smack_t for me, but it would do u32s just fine.

While having to deal only with secids would make life easier, it might be 
possible to offer alternate option formats for different LSMs (as long as 
they were in mainline).

> It has the disadvantage that you have to be careful 
> to avoid going off the box since there's no RFC supporting it.

Yes, indeed.  Although in the case of NetLabel/CIPSO we have the wonderful 
(well, not so wonderful if your a router vendor) FIPS defined "freeform" tag 
which would allow us to stuff whatever we want so long as it fits in the IP 
header length limitations.  That said, I'm currently tossing around ways to 
leverage the ip_build_options() routine to provide destination specific 
NetLabel labeling in conjunction with the existing per-domain labeling.

IPv6 is of course, a different story.

> I seem to recall there is an "approved" scheme lurking in the
> networking header files, but I never persued that.

I have absolutely no idea what you are talking about here.

> > The solution for this problem is tightly coupled with the decision to
> > split/not-split the secmark field in the sk_buff structure.  If the
> > secmark field were split then the peer label could be set directly in the
> > packet to the originating socket and then preserved across the loopback
> > pseudo-interface for use on the receiving/inbound side.  However, this
> > does require splitting the secmark field and all that goes along with it
> > (see above).  If the secmark field were not split then the solution is to
> > continue
> >
> > to develop the peer labeling mechanisms to support loopback labeling. 
> > Joy Latten from IBM has been working on better support for IPsec over
> > loopback (although I'm not sure of it's current status) and I am steadily
> > working towards a more full featured NetLabel which would be able to
> > convey a full SELinux context over the wire/loopback.
>
> So how big is a "full" context?

See my comments above.  In the case of SELinux I would probably simply just 
pass the SID directly over loopback for performance reasons.

> >  * Fallback labels
> >
> > The simple idea that started this whole discussion.  The need for a
> > usable peer label fallback mechanism is understood by everyone but the
> > granularity with which peer fallback labels are assigned are still a
> > source of debate. The idea is wether the granularity proposed in this
> > NetLabel patchset which allows per-host/subnet granularity for each
> > interface is enough, and if not is a very granular iptables/netfilter
> > peer label assignment of fallback labels required?  This topic did come
> > up briefly some time ago on the public mailing list between Joshua
> > Brindle and myself and we agreed that the granularity presented in this
> > patchset is sufficient, however, not everyone feels this way so we are
> > still discussing the best solution.
> >
> > As part of the peer fallback label discussion it became apparent to
> > everyone that better integration/cooperation between the NetLabel and
> > XFRM labeling mechanisms is needed.  The strict separation worked well in
> > the beginning but
> >
> > as we start to develop a richer set of functionality the two labeling
> > mechanisms need to work better together to ensure the consistency of the
> > network access controls.  If the approach put forward in this patch set
> > is agreed upon as the right way to solve the peer fallback problem I will
> > be modifying it to take into account XFRM labels so that the NetLabel
> > provided fallback peer label will only be used when there is no XFRM or
> > NetLabel/CIPSO
> >
> > label on the packet.  Further, work will be done to ensure that when both
> > a XFRM and NetLabel/CIPSO label are present on an incoming packet that
> > the labels are the same, otherwise the packet will be dropped/rejected.
>
> It makes me uncomfortable to hear you say that XFRM is SELinux specific
> and that it needs to be integrated with NetLabel, which currently isn't.

Relax, I plan on making the integration/cooperation within SELinux.  I'm still 
working on the patches (just started thinking/coding yesterday) but as it 
stands the only real change to NetLabel will be the addition of label source 
information in the netlbl_lsm_secattr struct, i.e. is this a CIPSO label, a 
unlabeled/fallback label, etc.

> I know that Smack isn't upstream yet.

Slacker :)

> Nonetheless, I would hate to see 
> underlying mechanisms that currently provide useful facilities become
> SELinux specific.

As long as the LSM is in place, so would I.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[James Morris]

On Fri, 24 Aug 2007, Paul Moore wrote:

> Feel free to suggest something better, I don't think anyone was ever really in 
> love with the term "secmark label".  I believe at one point Stephen 
> suggested "iptables label", does that sound any better?

I like packet label, because it's a label based on the attributes of the 
packet.


-- 
James Morris
<jmorris@namei.org>

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Friday, August 24 2007 4:17:00 pm James Morris wrote:
> On Fri, 24 Aug 2007, Paul Moore wrote:
> > Feel free to suggest something better, I don't think anyone was ever
> > really in love with the term "secmark label".  I believe at one point
> > Stephen suggested "iptables label", does that sound any better?
>
> I like packet label, because it's a label based on the attributes of the
> packet.

[Sorry, I forgot about this suggestion when replying]

I was always a little nervous that just the term "packet label" would get 
confusing ... are we talking about the "peer" packet label or the "packet" 
packet label ... but I see your point.

What do other people think?  I know you've got an opinion Casey ...

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Paul Moore wrote:
> On Friday, August 24 2007 4:17:00 pm James Morris wrote:
>   
>> On Fri, 24 Aug 2007, Paul Moore wrote:
>>     
>>> Feel free to suggest something better, I don't think anyone was ever
>>> really in love with the term "secmark label".  I believe at one point
>>> Stephen suggested "iptables label", does that sound any better?
>>>       
>> I like packet label, because it's a label based on the attributes of the
>> packet.
>>     
>
> [Sorry, I forgot about this suggestion when replying]
>
> I was always a little nervous that just the term "packet label" would get 
> confusing ... are we talking about the "peer" packet label or the "packet" 
> packet label ... but I see your point.
>
>   
I agree, packet is ambiguous, it could mean the label thats in the 
packet in the CIPSO field. netfilter label or iptables label (I prefer 
the former since that is the real mechanism that does it, iptables could 
be replaced with a new userspace interface anytime...)

> What do other people think?  I know you've got an opinion Casey ...
>   


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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:


> > Hmm. In one case the name reflects the purpose (label of peer) and
> > in the other the name reflects the mechanism (label used in SECMARK).
> > I like the clarification of the former as it tells an LSM writer
> > what to use the label for, while I dislike the latter because it
> > does nothing to help me understand the intent of the mechanism.
> 
> Feel free to suggest something better, I don't think anyone was ever really
> in 
> love with the term "secmark label".  I believe at one point Stephen 
> suggested "iptables label", does that sound any better?

It does because it describes the intended use.

> 
> > > As a reminder, below is a definition of the two types of labels.
> > >
> > > Secmark, or internal, labels are essentially a means for integrating the
> > > traditional firewall rules with SELinux mandatory access controls.
> >
> > Is it really intended that Secmark is an SELinux specific mechanism?
> 
> I don't see why it _has_ to be a SELinux specific mechanism.  I understand 
> that some of the netfilter code is SELinux specific (mostly the part dealing 
> with SELinux secctx/secid conversions) but you could either change that to 
> the more generic LSM secctx/secid conversion API or simply augment it for 
> SMACK (I even see some nice case statements already in place to make things 
> easy for you).

I can see where the mechanism is intended for generality and
where there is strong SELinux influence. I always get nervous
when what looks like a general mechanism is described in terms
of a specific use to which it gets put.

> However, all of this assumes that the LSM has a functional 
> label-to-32bit-token mapping mechanism similar to what SELinux has with the 
> SID concept.  I know, and understand why, you are not a big fan of this for 
> SMACK but secids/tokens are a reality in several parts of the kernel and I 
> don't expect that to change anytime soon.  You don't have to implement a 
> label/token mapping mechanism I guess, but you won't be able to make use of 
> kernel subsystems which require it.

Having come to that realization myself while trying to deal with
the audit code (which would be easily repairable were it not for xfrm)
I've been working on accomodating this particularily.

> > Yes, yes, I understand that SELinux is the only upstream LSM and all
> > that. If it is intended only as a component of SELinux going forward
> > regardless of alternative LSM availability maybe that should be more
> > explicit in the related documentation.
> 
> Documentation?  Who has documentation?!  ;)
> 
> You make a good point, one that became clear to me over the course of the 
> discussion is that we need better documentation about the SELinux/LSM network
> 
> access controls work in the kernel.  Josh wrote up a nice blog entry a while 
> ago about how to make some of it work in userspace (no NetLabel instructions,
> 
> though ... tsk tsk <g>!) but we don't have anyting for kernel hack[er]s.  One
> 
> of the things that made it on to my todo list (but I haven't shared this with
> 
> anyone until now) is a document/wiki-entry describing how things work in the 
> kernel, and I'll be sure to point out which things are SELinux specific 
> (which is pretty few, if any).

I expect that the actual dependencies are isolated. Where they
exist it would be nice for them to be explicit.

> > I would personally be 
> > disappointed if the mechanism were unavailable to other LSMs, but that
> > is of course your call.
> 
> As long as their is an LSM my opinion is that all mechanisms which live 
> outside the LSM and/or provide services to LSM modules should be agnostic of 
> any one particular LSM.  However, this does not mean that the is must deal 
> only with binary/string/secctx labels; if it makes sense to deal strictly 
> with secid tokens then so be it.

Maybe we can fix that in 3.0. That is, I'll accept it for now,
but someday we really ought to revisit the decision.

> > >  * Splitting the SECMARK field
> > >
> > > After it was agreed to continue using both the peer and secmark labels
> > > the discussion turned to how best to propagate those labels with the
> > > packet.  As you probably know there is a 32 bit field already in the
> > > packet/sk_buff structure which is currently used exclusively by the
> > > secmark label.  Once again, there were two approaches considered.  The
> > > first was the continuation of the status quo where the secmark label is
> > > determined by looking directly at the secmark field in the sk_buff,
> > > "sk_buff.secmark", and the peer label is
> > >
> > > determined through a function call with the sk_buff as an
> > > argument, "peer_label(sk_buff)".
> >
> > Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff),
> > or security_peer_label(sk_buff)?
> 
> At this point I'm thinking this would be internal/specific to the LSM; SMACK 
> and other LSMs cand devise whatever internal mechanism they want.  SMACK for 
> example only has one labeling mechanism that I can see so this is kind of a 
> moot point for you, just make use of the NetLabel API to get the security 
> attributes/label of a packet.  For SELinux it's not quite so simple as both 
> NetLabel and XFRM can provide peer label information, in order to make it 
> easier I was suggesting providing a single wrapper function that would take 
> into account all peer labeling mechanisms and return the correct peer label.

Sound.

> > >  * Loopback/Localhost peer packet labeling
> > >
> > > This has been a long standing requirement which at first glance seems
> > > like it
> > >
> > > would be simple to achieve but in practice it has proven quiet difficult
> > > to implement.  Current solutions to the problem involve using either
> > > NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
> > > unfortunately both have drawbacks.  NetLabel/CIPSO is currently limited
> > > to only conveying the MLS sensitivity label over the wire and only then
> > > for IPv4
> > >
> > > packets.  Labeled IPsec can convey the full SELinux label/context of the
> > > peer
> > >
> > > for both IPv4 and IPv6 but is difficult to configure and introduces
> > > unnecessary overhead for packets that never leave the machine.
> >
> > In the early Smack development I experimented with a scheme that
> > was very like CIPSO with the exception that it carried the MAC
> > information directly.
> 
> I am thinking along the same lines for NetLabel/CIPSO, similar to the old 
> Selopt concept.  I'm also considering adding some additional fields/info to 
> carry additional information that used to passed along via MaxSix/SAMP; more 
> on that when I get to that work item.
> 
> > That would be a smack_t for me, but it would do u32s just fine.
> 
> While having to deal only with secids would make life easier, it might be 
> possible to offer alternate option formats for different LSMs (as long as 
> they were in mainline).

Well, you could define the interface to take a pointer and length,
thereby leaving it up to the LSM. Heck, SELinux could use it to
pass two sids instead of one that way.

> > It has the disadvantage that you have to be careful 
> > to avoid going off the box since there's no RFC supporting it.
> 
> Yes, indeed.  Although in the case of NetLabel/CIPSO we have the wonderful 
> (well, not so wonderful if your a router vendor) FIPS defined "freeform" tag 
> which would allow us to stuff whatever we want so long as it fits in the IP 
> header length limitations.  That said, I'm currently tossing around ways to 
> leverage the ip_build_options() routine to provide destination specific 
> NetLabel labeling in conjunction with the existing per-domain labeling.
> 
> IPv6 is of course, a different story.

Indeed.

> > I seem to recall there is an "approved" scheme lurking in the
> > networking header files, but I never persued that.
> 
> I have absolutely no idea what you are talking about here.

It might even have been selopt. 
 
> > > The solution for this problem is tightly coupled with the decision to
> > > split/not-split the secmark field in the sk_buff structure.  If the
> > > secmark field were split then the peer label could be set directly in the
> > > packet to the originating socket and then preserved across the loopback
> > > pseudo-interface for use on the receiving/inbound side.  However, this
> > > does require splitting the secmark field and all that goes along with it
> > > (see above).  If the secmark field were not split then the solution is to
> > > continue
> > >
> > > to develop the peer labeling mechanisms to support loopback labeling. 
> > > Joy Latten from IBM has been working on better support for IPsec over
> > > loopback (although I'm not sure of it's current status) and I am steadily
> > > working towards a more full featured NetLabel which would be able to
> > > convey a full SELinux context over the wire/loopback.
> >
> > So how big is a "full" context?
> 
> See my comments above.  In the case of SELinux I would probably simply just 
> pass the SID directly over loopback for performance reasons.

Yup.

> 
> > >  * Fallback labels
> > >
> > > ...
> > >
> > > label on the packet.  Further, work will be done to ensure that when both
> > > a XFRM and NetLabel/CIPSO label are present on an incoming packet that
> > > the labels are the same, otherwise the packet will be dropped/rejected.
> >
> > It makes me uncomfortable to hear you say that XFRM is SELinux specific
> > and that it needs to be integrated with NetLabel, which currently isn't.
> 
> Relax, I plan on making the integration/cooperation within SELinux.  I'm
> still 
> working on the patches (just started thinking/coding yesterday) but as it 
> stands the only real change to NetLabel will be the addition of label source 
> information in the netlbl_lsm_secattr struct, i.e. is this a CIPSO label, a 
> unlabeled/fallback label, etc.

Ok. I've relaxed.
 
> > I know that Smack isn't upstream yet.
> 
> Slacker :)

Sometimes the Rock Star Lifestyle gets in the way.

> > Nonetheless, I would hate to see 
> > underlying mechanisms that currently provide useful facilities become
> > SELinux specific.
> 
> As long as the LSM is in place, so would I.

Carefully worded.

Thank you.


Casey Schaufler
casey@schaufler-ca.com

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Friday, August 24 2007 4:42:16 pm Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > > Hmm. In one case the name reflects the purpose (label of peer) and
> > > in the other the name reflects the mechanism (label used in SECMARK).
> > > I like the clarification of the former as it tells an LSM writer
> > > what to use the label for, while I dislike the latter because it
> > > does nothing to help me understand the intent of the mechanism.
> >
> > Feel free to suggest something better, I don't think anyone was ever
> > really in
> > love with the term "secmark label".  I believe at one point Stephen
> > suggested "iptables label", does that sound any better?
>
> It does because it describes the intended use.

Actually, after reading Josh's mail I'm now thinking "netfilter label" is 
probably a better choice.  After all, the bikeshed will need to be repainted 
in a few years ... ;)

> > > > As a reminder, below is a definition of the two types of labels.
> > > >
> > > > Secmark, or internal, labels are essentially a means for integrating
> > > > the traditional firewall rules with SELinux mandatory access
> > > > controls.
> > >
> > > Is it really intended that Secmark is an SELinux specific mechanism?
> >
> > I don't see why it _has_ to be a SELinux specific mechanism.  I
> > understand that some of the netfilter code is SELinux specific (mostly
> > the part dealing with SELinux secctx/secid conversions) but you could
> > either change that to the more generic LSM secctx/secid conversion API or
> > simply augment it for SMACK (I even see some nice case statements already
> > in place to make things easy for you).
>
> I can see where the mechanism is intended for generality and
> where there is strong SELinux influence. I always get nervous
> when what looks like a general mechanism is described in terms
> of a specific use to which it gets put.

Then channel some of that nervous energy into some patches :)  Really, I think 
you could probably "fix" some of this without affecting the user visible 
portion of it ... but then again I haven't thought about it for that long.

> > > I would personally be
> > > disappointed if the mechanism were unavailable to other LSMs, but that
> > > is of course your call.
> >
> > As long as their is an LSM my opinion is that all mechanisms which live
> > outside the LSM and/or provide services to LSM modules should be agnostic
> > of any one particular LSM.  However, this does not mean that the is must
> > deal only with binary/string/secctx labels; if it makes sense to deal
> > strictly with secid tokens then so be it.
>
> Maybe we can fix that in 3.0. That is, I'll accept it for now,
> but someday we really ought to revisit the decision.

Sure, in a perfect world we would have void pointers everywhere, with a well 
defined set of lifecycle management hooks that would enable us to do whatever 
we wanted in terms of labeling objects on the system.  It's a nice idea, 
scratch that, a truly awesome idea, but I just don't see that happening in 
the near future.

> > > >  * Loopback/Localhost peer packet labeling
> > > >
> > > > This has been a long standing requirement which at first glance seems
> > > > like it
> > > >
> > > > would be simple to achieve but in practice it has proven quiet
> > > > difficult to implement.  Current solutions to the problem involve
> > > > using either NetLabel/CIPSO or labeled IPsec over loopback to provide
> > > > peer labels, unfortunately both have drawbacks.  NetLabel/CIPSO is
> > > > currently limited to only conveying the MLS sensitivity label over
> > > > the wire and only then for IPv4
> > > >
> > > > packets.  Labeled IPsec can convey the full SELinux label/context of
> > > > the peer
> > > >
> > > > for both IPv4 and IPv6 but is difficult to configure and introduces
> > > > unnecessary overhead for packets that never leave the machine.
> > >
> > > In the early Smack development I experimented with a scheme that
> > > was very like CIPSO with the exception that it carried the MAC
> > > information directly.
> >
> > I am thinking along the same lines for NetLabel/CIPSO, similar to the old
> > Selopt concept.  I'm also considering adding some additional fields/info
> > to carry additional information that used to passed along via
> > MaxSix/SAMP; more on that when I get to that work item.
> >
> > > That would be a smack_t for me, but it would do u32s just fine.
> >
> > While having to deal only with secids would make life easier, it might be
> > possible to offer alternate option formats for different LSMs (as long as
> > they were in mainline).
>
> Well, you could define the interface to take a pointer and length,
> thereby leaving it up to the LSM.

Yes, that is one of the things I'm considering but one of the drawbacks to 
this approach is that it makes commonality between LSMs very hard.

We can talk more about the exact functionality/API later if you would like, 
right now I think we should stick to the topics in the original email so we 
don't get stuck in a rathole.  My plan is to start looking into this after 
the fallback label issue is resolved.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> On Friday, August 24 2007 4:42:16 pm Casey Schaufler wrote:
> > --- Paul Moore <paul.moore@hp.com> wrote:
> > > > Hmm. In one case the name reflects the purpose (label of peer) and
> > > > in the other the name reflects the mechanism (label used in SECMARK).
> > > > I like the clarification of the former as it tells an LSM writer
> > > > what to use the label for, while I dislike the latter because it
> > > > does nothing to help me understand the intent of the mechanism.
> > >
> > > Feel free to suggest something better, I don't think anyone was ever
> > > really in
> > > love with the term "secmark label".  I believe at one point Stephen
> > > suggested "iptables label", does that sound any better?
> >
> > It does because it describes the intended use.
> 
> Actually, after reading Josh's mail I'm now thinking "netfilter label" is 
> probably a better choice.

I also found his reasoning sound. "netfilter label" has my approval.

> After all, the bikeshed will need to be repainted 
> in a few years ... ;)
> 
> > > > > As a reminder, below is a definition of the two types of labels.
> > > > >
> > > > > Secmark, or internal, labels are essentially a means for integrating
> > > > > the traditional firewall rules with SELinux mandatory access
> > > > > controls.
> > > >
> > > > Is it really intended that Secmark is an SELinux specific mechanism?
> > >
> > > I don't see why it _has_ to be a SELinux specific mechanism.  I
> > > understand that some of the netfilter code is SELinux specific (mostly
> > > the part dealing with SELinux secctx/secid conversions) but you could
> > > either change that to the more generic LSM secctx/secid conversion API or
> > > simply augment it for SMACK (I even see some nice case statements already
> > > in place to make things easy for you).
> >
> > I can see where the mechanism is intended for generality and
> > where there is strong SELinux influence. I always get nervous
> > when what looks like a general mechanism is described in terms
> > of a specific use to which it gets put.
> 
> Then channel some of that nervous energy into some patches :)  Really, I
> think 
> you could probably "fix" some of this without affecting the user visible 
> portion of it ... but then again I haven't thought about it for that long.

Yeah, yeah. It's behind audit on the list. "soon".

> > > > I would personally be
> > > > disappointed if the mechanism were unavailable to other LSMs, but that
> > > > is of course your call.
> > >
> > > As long as their is an LSM my opinion is that all mechanisms which live
> > > outside the LSM and/or provide services to LSM modules should be agnostic
> > > of any one particular LSM.  However, this does not mean that the is must
> > > deal only with binary/string/secctx labels; if it makes sense to deal
> > > strictly with secid tokens then so be it.
> >
> > Maybe we can fix that in 3.0. That is, I'll accept it for now,
> > but someday we really ought to revisit the decision.
> 
> Sure, in a perfect world we would have void pointers everywhere, with a well 
> defined set of lifecycle management hooks that would enable us to do whatever
> 
> we wanted in terms of labeling objects on the system.  It's a nice idea, 
> scratch that, a truly awesome idea, but I just don't see that happening in 
> the near future.

I had a go at it, and there are only a couple gnarly places, but they
are unpleasant enough to I'm deferring it for the time being.

> > > > >  * Loopback/Localhost peer packet labeling
> > > > >
> > > > > This has been a long standing requirement which at first glance seems
> > > > > like it
> > > > >
> > > > > would be simple to achieve but in practice it has proven quiet
> > > > > difficult to implement.  Current solutions to the problem involve
> > > > > using either NetLabel/CIPSO or labeled IPsec over loopback to provide
> > > > > peer labels, unfortunately both have drawbacks.  NetLabel/CIPSO is
> > > > > currently limited to only conveying the MLS sensitivity label over
> > > > > the wire and only then for IPv4
> > > > >
> > > > > packets.  Labeled IPsec can convey the full SELinux label/context of
> > > > > the peer
> > > > >
> > > > > for both IPv4 and IPv6 but is difficult to configure and introduces
> > > > > unnecessary overhead for packets that never leave the machine.
> > > >
> > > > In the early Smack development I experimented with a scheme that
> > > > was very like CIPSO with the exception that it carried the MAC
> > > > information directly.
> > >
> > > I am thinking along the same lines for NetLabel/CIPSO, similar to the old
> > > Selopt concept.  I'm also considering adding some additional fields/info
> > > to carry additional information that used to passed along via
> > > MaxSix/SAMP; more on that when I get to that work item.
> > >
> > > > That would be a smack_t for me, but it would do u32s just fine.
> > >
> > > While having to deal only with secids would make life easier, it might be
> > > possible to offer alternate option formats for different LSMs (as long as
> > > they were in mainline).
> >
> > Well, you could define the interface to take a pointer and length,
> > thereby leaving it up to the LSM.
> 
> Yes, that is one of the things I'm considering but one of the drawbacks to 
> this approach is that it makes commonality between LSMs very hard.
> 
> We can talk more about the exact functionality/API later if you would like, 
> right now I think we should stick to the topics in the original email so we 
> don't get stuck in a rathole.  My plan is to start looking into this after 
> the fallback label issue is resolved.

OK by me. Lots to do.



Casey Schaufler
casey@schaufler-ca.com

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Joshua Brindle]

Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
>   
>> as we start to develop a richer set of functionality the two labeling 
>> mechanisms need to work better together to ensure the consistency of the 
>> network access controls.  If the approach put forward in this patch set is 
>> agreed upon as the right way to solve the peer fallback problem I will be 
>> modifying it to take into account XFRM labels so that the NetLabel provided 
>> fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO
>>
>> label on the packet.  Further, work will be done to ensure that when both a 
>> XFRM and NetLabel/CIPSO label are present on an incoming packet that the 
>> labels are the same, otherwise the packet will be dropped/rejected.
>>     
>
> It makes me uncomfortable to hear you say that XFRM is SELinux specific
> and that it needs to be integrated with NetLabel, which currently isn't.
> I know that Smack isn't upstream yet. Nonetheless, I would hate to see
> underlying mechanisms that currently provide useful facilities become
> SELinux specific.
>   

Joy will know better but I don't think there is anything really SELinux 
specific about XRFM. As far as the racoon support goes it just 
serializes and sends over a string context, algorithm and DOI. The LSM 
would responsible for verifying the context when it is set. One thing 
you'd have to figure out as an LSM writer is how to reconcile multiple 
incoming labels, much like we are trying to do right now. There are 
already function pointers in the security_ops struct for managing xfrm 
security data, it shouldn't be any problem for you to use them.



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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Darrel Goeddel]

Paul Moore wrote:

<snip>

>  * Loopback/Localhost peer packet labeling
> 
> This has been a long standing requirement which at first glance seems like it 
> would be simple to achieve but in practice it has proven quiet difficult to 
> implement.  Current solutions to the problem involve using either 
> NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, 
> unfortunately both have drawbacks.  NetLabel/CIPSO is currently limited to 
> only conveying the MLS sensitivity label over the wire and only then for IPv4 
> packets.  Labeled IPsec can convey the full SELinux label/context of the peer 
> for both IPv4 and IPv6 but is difficult to configure and introduces 
> unnecessary overhead for packets that never leave the machine.
> 
> The solution for this problem is tightly coupled with the decision to 
> split/not-split the secmark field in the sk_buff structure.  If the secmark 
> field were split then the peer label could be set directly in the packet to 
> the originating socket and then preserved across the loopback 
> pseudo-interface for use on the receiving/inbound side.  However, this does 
> require splitting the secmark field and all that goes along with it (see 
> above).  If the secmark field were not split then the solution is to continue 
> to develop the peer labeling mechanisms to support loopback labeling.  Joy 
> Latten from IBM has been working on better support for IPsec over loopback 
> (although I'm not sure of it's current status) and I am steadily working 
> towards a more full featured NetLabel which would be able to convey a full 
> SELinux context over the wire/loopback.

I just want to note that there are a few associated changes that should 
go along with this.  Once we have the concept of the sender's context in 
in/associated with (I prefer in :)) the skb, we should use that when 
applying on-the-wire labels.  For the case fo locally generated packets, 
this end up doing the same thing since the socket's label is in the skb 
as the peer label.  The real difference in behavior is the added 
functionality of putting labels on the wire for forwarded packets (if 
prescribed by the on-the-wire policy).  For instance, a packet which 
receives a fallback label of SECRET (because it came in a interface we 
treat as SECRET) would be given the opportunity to exit a different 
interface with that SECRET label on-the-wire.  This gives us the ability 
to "consolidate" single level networks into a single network that uses 
explicit labeling.  Should work nicely for cipso and labeled ipsec This 
is something we currently employ with a patched kernel.

--

Darrel

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

On Tuesday, August 28 2007 10:03:01 am Darrel Goeddel wrote:
> Paul Moore wrote:
>
> <snip>
>
> >  * Loopback/Localhost peer packet labeling
> >
> > This has been a long standing requirement which at first glance seems
> > like it would be simple to achieve but in practice it has proven quiet
> > difficult to implement.  Current solutions to the problem involve using
> > either NetLabel/CIPSO or labeled IPsec over loopback to provide peer
> > labels, unfortunately both have drawbacks.  NetLabel/CIPSO is currently
> > limited to only conveying the MLS sensitivity label over the wire and
> > only then for IPv4 packets.  Labeled IPsec can convey the full SELinux
> > label/context of the peer for both IPv4 and IPv6 but is difficult to
> > configure and introduces unnecessary overhead for packets that never
> > leave the machine.
> >
> > The solution for this problem is tightly coupled with the decision to
> > split/not-split the secmark field in the sk_buff structure.  If the
> > secmark field were split then the peer label could be set directly in the
> > packet to the originating socket and then preserved across the loopback
> > pseudo-interface for use on the receiving/inbound side.  However, this
> > does require splitting the secmark field and all that goes along with it
> > (see above).  If the secmark field were not split then the solution is to
> > continue to develop the peer labeling mechanisms to support loopback
> > labeling.  Joy Latten from IBM has been working on better support for
> > IPsec over loopback (although I'm not sure of it's current status) and I
> > am steadily working towards a more full featured NetLabel which would be
> > able to convey a full SELinux context over the wire/loopback.
>
> I just want to note that there are a few associated changes that should
> go along with this.  Once we have the concept of the sender's context in
> in/associated with (I prefer in :)) the skb, we should use that when
> applying on-the-wire labels.  For the case fo locally generated packets,
> this end up doing the same thing since the socket's label is in the skb
> as the peer label.  The real difference in behavior is the added
> functionality of putting labels on the wire for forwarded packets (if
> prescribed by the on-the-wire policy).  For instance, a packet which
> receives a fallback label of SECRET (because it came in a interface we
> treat as SECRET) would be given the opportunity to exit a different
> interface with that SECRET label on-the-wire.  This gives us the ability
> to "consolidate" single level networks into a single network that uses
> explicit labeling.  Should work nicely for cipso and labeled ipsec This
> is something we currently employ with a patched kernel.

Yes.  For locally generated packets the peer label of the packet is the label 
of the socket which generated the packet, for forwarded packets the peer 
label is the peer label that was associated with the packet when it arrived 
at the system.  On-the-wire labeling should always be based on the peer label 
of the packet as defined above.

On-the-wire labeling for forwarded packets was discussed just recently in a 
few messages between Venkat and myself on this thread.

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> This patchset adds the static/fallback labeling feature to NetLabel that has
> been requested on the SELinux mailing list more and more recently.  This new
> bit of functionality also matches what can be found on similar
> trusted/labeled
> OSs such as Trusted Solaris, HP-UX CMW, etc.  This patchset it not yet ready
> for "upstreaming" so please do not pull this into any tree bound for the
> mainline kernel; I still need to do more review and testing of the code.
> However, I know there are several of you on this list that have been
> anxiously
> awaiting this patchset so I thought I would make an early release so you
> could
> get a peek and test it out.  I won't be able to work on this patchset much,
> if
> at all, between August 10th and the 20th so don't expect an update from me
> until the end of August.
> 
> The basic idea is that currently there is no method for providing an external
> label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO
> or labeled IPsec is not in use.  This patch adds a mechanism for providing a
> static fallback label, specified per interface/network, which is used when
> a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.

I'm all in favor of the facility. I do however object to the use of
a secid as the mechanism for storing the default label. As I've mentioned
elsewhere, secid's are SELinux specific and add unnecessary overhead to
schemes that don't use them natively. I understand and appreciate that
SELinux is upstream, etc, etc. I understand that a scheme that does not
use secid's is less convenient for SELinux. Please?


Casey Schaufler
casey@schaufler-ca.com

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

Re: [RFC 0/5] Static/fallback external labels for NetLabel

[Paul Moore]

[I'm moving offices today and am a bit behind on this thread right now so I'm 
cherry picking the easy threads]

On Thursday, August 9 2007 11:48:33 am Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > The basic idea is that currently there is no method for providing an
> > external label to fallback on if a labeled networking mechanism such as
> > NetLabel/CIPSO or labeled IPsec is not in use.  This patch adds a
> > mechanism for providing a static fallback label, specified per
> > interface/network, which is used when a NetLabel recognized labeling
> > protocol (at this point CIPSO) is not in use.
>
> I'm all in favor of the facility. I do however object to the use of
> a secid as the mechanism for storing the default label. As I've mentioned
> elsewhere, secid's are SELinux specific and add unnecessary overhead to
> schemes that don't use them natively. I understand and appreciate that
> SELinux is upstream, etc, etc. I understand that a scheme that does not
> use secid's is less convenient for SELinux. Please?

I was waiting for you to say something about this, and I think you'll be happy 
with my take on it ...

The patchset right now takes a binary/string blob label which it converts to a 
token/secid through the LSM secctx_to_secid interface and returns it to the 
LSM when it asks for the packet's security attributes.  If the LSM 
secctx_to_secid interface were to return an error value signifying that the 
running LSM did not implement that functionality it would be very easy to 
store the binary/string blob label and return that to the LSM when asked for 
security attributes.  However, like we talked about regarding the 
NetLabel/LSM domain mapping API work, until SMACK is accepted upstream I 
don't want to add any of these changes.

As long as the LSM hooks exist and the possibility of multiple LSM 
implementation exist I'm going to do my best to keep NetLabel LSM agnostic.  
If LSM were to go away and be replaced with SELinux (or some other LSM for 
that matter) then the NetLabel interface would change a bit to remove some of 
the abstraction.

That said, it may be a moot point as from what I've read so far this patchset 
doesn't appear to have much support.

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