* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-29 15:29 Venkat Yekkirala
2007-08-29 15:45 ` Stephen Smalley
0 siblings, 1 reply; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-29 15:29 UTC (permalink / raw)
To: Paul Moore
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
> 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 15:29 [RFC 0/5] Static/fallback external labels for NetLabel Venkat Yekkirala
@ 2007-08-29 15:45 ` Stephen Smalley
0 siblings, 0 replies; 100+ messages in thread
From: Stephen Smalley @ 2007-08-29 15:45 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel, kaigai, joe,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 15:08 ` Joshua Brindle
@ 2007-08-29 16:55 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-29 16:55 UTC (permalink / raw)
To: Joshua Brindle
Cc: Joe Nall, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 16:15 Venkat Yekkirala
@ 2007-08-29 16:41 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-29 16:41 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: Stephen Smalley, selinux, James Morris, Darrel Goeddel, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 15:50 ` Joe Nall
@ 2007-08-29 16:31 ` Joshua Brindle
0 siblings, 0 replies; 100+ messages in thread
From: Joshua Brindle @ 2007-08-29 16:31 UTC (permalink / raw)
To: Joe Nall
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-29 16:15 Venkat Yekkirala
2007-08-29 16:41 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-29 16:15 UTC (permalink / raw)
To: Stephen Smalley, Venkat Yekkirala
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel, kaigai, joe,
Eric Paris
> > 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 14:04 ` Joshua Brindle
@ 2007-08-29 15:50 ` Joe Nall
2007-08-29 16:31 ` Joshua Brindle
0 siblings, 1 reply; 100+ messages in thread
From: Joe Nall @ 2007-08-29 15:50 UTC (permalink / raw)
To: Joshua Brindle
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 14:56 ` Paul Moore
@ 2007-08-29 15:08 ` Joshua Brindle
2007-08-29 16:55 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: Joshua Brindle @ 2007-08-29 15:08 UTC (permalink / raw)
To: Paul Moore
Cc: Joe Nall, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-29 15:07 Venkat Yekkirala
0 siblings, 0 replies; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-29 15:07 UTC (permalink / raw)
To: Paul Moore, Joshua Brindle
Cc: Joe Nall, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 14:26 ` Joshua Brindle
@ 2007-08-29 14:56 ` Paul Moore
2007-08-29 15:08 ` Joshua Brindle
0 siblings, 1 reply; 100+ messages in thread
From: Paul Moore @ 2007-08-29 14:56 UTC (permalink / raw)
To: Joshua Brindle
Cc: Joe Nall, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 12:21 ` Paul Moore
@ 2007-08-29 14:26 ` Joshua Brindle
2007-08-29 14:56 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: Joshua Brindle @ 2007-08-29 14:26 UTC (permalink / raw)
To: Paul Moore
Cc: Joe Nall, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 4:49 ` Joe Nall
@ 2007-08-29 14:04 ` Joshua Brindle
2007-08-29 15:50 ` Joe Nall
0 siblings, 1 reply; 100+ messages in thread
From: Joshua Brindle @ 2007-08-29 14:04 UTC (permalink / raw)
To: Joe Nall
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 4:11 ` Joshua Brindle
2007-08-29 4:49 ` Joe Nall
@ 2007-08-29 12:21 ` Paul Moore
2007-08-29 14:26 ` Joshua Brindle
1 sibling, 1 reply; 100+ messages in thread
From: Paul Moore @ 2007-08-29 12:21 UTC (permalink / raw)
To: Joshua Brindle
Cc: Joe Nall, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 4:11 ` Joshua Brindle
@ 2007-08-29 4:49 ` Joe Nall
2007-08-29 14:04 ` Joshua Brindle
2007-08-29 12:21 ` Paul Moore
1 sibling, 1 reply; 100+ messages in thread
From: Joe Nall @ 2007-08-29 4:49 UTC (permalink / raw)
To: Joshua Brindle
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 3:45 ` Joshua Brindle
@ 2007-08-29 4:11 ` Joshua Brindle
2007-08-29 4:49 ` Joe Nall
2007-08-29 12:21 ` Paul Moore
0 siblings, 2 replies; 100+ messages in thread
From: Joshua Brindle @ 2007-08-29 4:11 UTC (permalink / raw)
To: Joe Nall
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-29 0:16 ` Joshua Brindle
@ 2007-08-29 3:45 ` Joshua Brindle
2007-08-29 4:11 ` Joshua Brindle
0 siblings, 1 reply; 100+ messages in thread
From: Joshua Brindle @ 2007-08-29 3:45 UTC (permalink / raw)
To: Joe Nall
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 22:26 ` Joe Nall
@ 2007-08-29 0:16 ` Joshua Brindle
2007-08-29 3:45 ` Joshua Brindle
0 siblings, 1 reply; 100+ messages in thread
From: Joshua Brindle @ 2007-08-29 0:16 UTC (permalink / raw)
To: Joe Nall
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 19:48 ` Joshua Brindle
@ 2007-08-28 22:26 ` Joe Nall
2007-08-29 0:16 ` Joshua Brindle
0 siblings, 1 reply; 100+ messages in thread
From: Joe Nall @ 2007-08-28 22:26 UTC (permalink / raw)
To: Joshua Brindle
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 19:10 ` Joe Nall
2007-08-28 19:08 ` Stephen Smalley
@ 2007-08-28 19:48 ` Joshua Brindle
2007-08-28 22:26 ` Joe Nall
1 sibling, 1 reply; 100+ messages in thread
From: Joshua Brindle @ 2007-08-28 19:48 UTC (permalink / raw)
To: Joe Nall
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 18:02 Venkat Yekkirala
@ 2007-08-28 19:47 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 19:47 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: Darrel Goeddel, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 17:39 ` Darrel Goeddel
@ 2007-08-28 19:36 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 19:36 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Venkat Yekkirala, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 16:30 Venkat Yekkirala
2007-08-28 17:39 ` Darrel Goeddel
@ 2007-08-28 19:26 ` Paul Moore
1 sibling, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 19:26 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
> > 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 18:51 ` Paul Moore
@ 2007-08-28 19:10 ` Joe Nall
2007-08-28 19:08 ` Stephen Smalley
2007-08-28 19:48 ` Joshua Brindle
0 siblings, 2 replies; 100+ messages in thread
From: Joe Nall @ 2007-08-28 19:10 UTC (permalink / raw)
To: Paul Moore
Cc: Darrel Goeddel, Venkat Yekkirala, selinux, James Morris,
Darrel Goeddel, Stephen Smalley, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 16:13 Venkat Yekkirala
2007-08-28 16:32 ` Joe Nall
@ 2007-08-28 19:08 ` Paul Moore
1 sibling, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 19:08 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: Darrel Goeddel, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 19:10 ` Joe Nall
@ 2007-08-28 19:08 ` Stephen Smalley
2007-08-28 19:48 ` Joshua Brindle
1 sibling, 0 replies; 100+ messages in thread
From: Stephen Smalley @ 2007-08-28 19:08 UTC (permalink / raw)
To: Joe Nall
Cc: Paul Moore, Darrel Goeddel, Venkat Yekkirala, selinux,
James Morris, Darrel Goeddel, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 17:23 ` Darrel Goeddel
@ 2007-08-28 19:07 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 19:07 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Venkat Yekkirala, selinux, James Morris, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 16:18 ` Joe Nall
@ 2007-08-28 18:51 ` Paul Moore
2007-08-28 19:10 ` Joe Nall
0 siblings, 1 reply; 100+ messages in thread
From: Paul Moore @ 2007-08-28 18:51 UTC (permalink / raw)
To: Joe Nall
Cc: Darrel Goeddel, Venkat Yekkirala, selinux, James Morris,
Darrel Goeddel, Stephen Smalley, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-28 18:02 Venkat Yekkirala
2007-08-28 19:47 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-28 18:02 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
> 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 16:30 Venkat Yekkirala
@ 2007-08-28 17:39 ` Darrel Goeddel
2007-08-28 19:36 ` Paul Moore
2007-08-28 19:26 ` Paul Moore
1 sibling, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-28 17:39 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 15:51 ` Paul Moore
2007-08-28 16:18 ` Joe Nall
@ 2007-08-28 17:23 ` Darrel Goeddel
2007-08-28 19:07 ` Paul Moore
1 sibling, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-28 17:23 UTC (permalink / raw)
To: Paul Moore
Cc: Venkat Yekkirala, selinux, James Morris, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 16:13 Venkat Yekkirala
@ 2007-08-28 16:32 ` Joe Nall
2007-08-28 19:08 ` Paul Moore
1 sibling, 0 replies; 100+ messages in thread
From: Joe Nall @ 2007-08-28 16:32 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: Paul Moore, Darrel Goeddel, selinux, James Morris,
Darrel Goeddel, Stephen Smalley, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-28 16:30 Venkat Yekkirala
2007-08-28 17:39 ` Darrel Goeddel
2007-08-28 19:26 ` Paul Moore
0 siblings, 2 replies; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-28 16:30 UTC (permalink / raw)
To: Paul Moore, Venkat Yekkirala
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
> -----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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 15:51 ` Paul Moore
@ 2007-08-28 16:18 ` Joe Nall
2007-08-28 18:51 ` Paul Moore
2007-08-28 17:23 ` Darrel Goeddel
1 sibling, 1 reply; 100+ messages in thread
From: Joe Nall @ 2007-08-28 16:18 UTC (permalink / raw)
To: Paul Moore
Cc: Darrel Goeddel, Venkat Yekkirala, selinux, James Morris,
Darrel Goeddel, Stephen Smalley, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-28 16:13 Venkat Yekkirala
2007-08-28 16:32 ` Joe Nall
2007-08-28 19:08 ` Paul Moore
0 siblings, 2 replies; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-28 16:13 UTC (permalink / raw)
To: Paul Moore, Darrel Goeddel
Cc: Venkat Yekkirala, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
(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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 14:58 ` Darrel Goeddel
2007-08-28 15:12 ` Darrel Goeddel
@ 2007-08-28 15:51 ` Paul Moore
2007-08-28 16:18 ` Joe Nall
2007-08-28 17:23 ` Darrel Goeddel
1 sibling, 2 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 15:51 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Venkat Yekkirala, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 14:03 ` Darrel Goeddel
@ 2007-08-28 15:16 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 15:16 UTC (permalink / raw)
To: Darrel Goeddel
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 14:58 ` Darrel Goeddel
@ 2007-08-28 15:12 ` Darrel Goeddel
2007-08-28 15:51 ` Paul Moore
1 sibling, 0 replies; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-28 15:12 UTC (permalink / raw)
To: Paul Moore
Cc: Venkat Yekkirala, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-27 22:09 Venkat Yekkirala
2007-08-28 14:51 ` Paul Moore
@ 2007-08-28 14:58 ` Darrel Goeddel
2007-08-28 15:12 ` Darrel Goeddel
2007-08-28 15:51 ` Paul Moore
1 sibling, 2 replies; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-28 14:58 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-27 22:09 Venkat Yekkirala
@ 2007-08-28 14:51 ` Paul Moore
2007-08-28 14:58 ` Darrel Goeddel
1 sibling, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-28 14:51 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 16:31 ` Paul Moore
2007-08-24 18:34 ` James Morris
2007-08-24 19:02 ` Casey Schaufler
@ 2007-08-28 14:03 ` Darrel Goeddel
2007-08-28 15:16 ` Paul Moore
2 siblings, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-28 14:03 UTC (permalink / raw)
To: Paul Moore
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-27 22:09 Venkat Yekkirala
2007-08-28 14:51 ` Paul Moore
2007-08-28 14:58 ` Darrel Goeddel
0 siblings, 2 replies; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-27 22:09 UTC (permalink / raw)
To: Paul Moore
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
[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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-27 12:44 Venkat Yekkirala
@ 2007-08-27 14:37 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-27 14:37 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-27 13:02 Venkat Yekkirala
@ 2007-08-27 13:48 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-27 13:48 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: casey, selinux, James Morris, Darrel Goeddel, Stephen Smalley,
kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-27 13:02 Venkat Yekkirala
2007-08-27 13:48 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-27 13:02 UTC (permalink / raw)
To: Paul Moore, casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
>
> 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-27 12:59 Venkat Yekkirala
0 siblings, 0 replies; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-27 12:59 UTC (permalink / raw)
To: Joshua Brindle, Paul Moore
Cc: James Morris, casey, selinux, Darrel Goeddel, Stephen Smalley,
kaigai, joe, Eric Paris
> > 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-27 12:57 Venkat Yekkirala
0 siblings, 0 replies; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-27 12:57 UTC (permalink / raw)
To: Joshua Brindle, casey
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
> > 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-27 12:44 Venkat Yekkirala
2007-08-27 14:37 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-27 12:44 UTC (permalink / raw)
To: Paul Moore, selinux
Cc: James Morris, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
> -----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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 17:37 Venkat Yekkirala
@ 2007-08-25 21:01 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-25 21:01 UTC (permalink / raw)
To: Venkat Yekkirala
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 21:10 ` Paul Moore
@ 2007-08-24 21:37 ` Casey Schaufler
0 siblings, 0 replies; 100+ messages in thread
From: Casey Schaufler @ 2007-08-24 21:37 UTC (permalink / raw)
To: Paul Moore, casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
--- 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 20:42 ` Casey Schaufler
@ 2007-08-24 21:10 ` Paul Moore
2007-08-24 21:37 ` Casey Schaufler
0 siblings, 1 reply; 100+ messages in thread
From: Paul Moore @ 2007-08-24 21:10 UTC (permalink / raw)
To: casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 20:24 ` Paul Moore
@ 2007-08-24 20:47 ` Joshua Brindle
0 siblings, 0 replies; 100+ messages in thread
From: Joshua Brindle @ 2007-08-24 20:47 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, casey, selinux, Darrel Goeddel, Stephen Smalley,
kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:49 ` Paul Moore
2007-08-24 20:17 ` James Morris
@ 2007-08-24 20:42 ` Casey Schaufler
2007-08-24 21:10 ` Paul Moore
1 sibling, 1 reply; 100+ messages in thread
From: Casey Schaufler @ 2007-08-24 20:42 UTC (permalink / raw)
To: Paul Moore, casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
--- 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:02 ` Casey Schaufler
2007-08-24 19:49 ` Paul Moore
@ 2007-08-24 20:29 ` Joshua Brindle
1 sibling, 0 replies; 100+ messages in thread
From: Joshua Brindle @ 2007-08-24 20:29 UTC (permalink / raw)
To: casey
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 20:17 ` James Morris
@ 2007-08-24 20:24 ` Paul Moore
2007-08-24 20:47 ` Joshua Brindle
0 siblings, 1 reply; 100+ messages in thread
From: Paul Moore @ 2007-08-24 20:24 UTC (permalink / raw)
To: James Morris
Cc: casey, selinux, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:49 ` Paul Moore
@ 2007-08-24 20:17 ` James Morris
2007-08-24 20:24 ` Paul Moore
2007-08-24 20:42 ` Casey Schaufler
1 sibling, 1 reply; 100+ messages in thread
From: James Morris @ 2007-08-24 20:17 UTC (permalink / raw)
To: Paul Moore
Cc: casey, selinux, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:02 ` Casey Schaufler
@ 2007-08-24 19:49 ` Paul Moore
2007-08-24 20:17 ` James Morris
2007-08-24 20:42 ` Casey Schaufler
2007-08-24 20:29 ` Joshua Brindle
1 sibling, 2 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-24 19:49 UTC (permalink / raw)
To: casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 16:31 ` Paul Moore
2007-08-24 18:34 ` James Morris
@ 2007-08-24 19:02 ` Casey Schaufler
2007-08-24 19:49 ` Paul Moore
2007-08-24 20:29 ` Joshua Brindle
2007-08-28 14:03 ` Darrel Goeddel
2 siblings, 2 replies; 100+ messages in thread
From: Casey Schaufler @ 2007-08-24 19:02 UTC (permalink / raw)
To: Paul Moore, selinux
Cc: James Morris, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
--- 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 16:31 ` Paul Moore
@ 2007-08-24 18:34 ` James Morris
2007-08-24 19:02 ` Casey Schaufler
2007-08-28 14:03 ` Darrel Goeddel
2 siblings, 0 replies; 100+ messages in thread
From: James Morris @ 2007-08-24 18:34 UTC (permalink / raw)
To: Paul Moore
Cc: selinux, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-24 18:11 Venkat Yekkirala
0 siblings, 0 replies; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-24 18:11 UTC (permalink / raw)
To: Paul Moore, selinux
Cc: James Morris, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
> -----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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-24 17:37 Venkat Yekkirala
2007-08-25 21:01 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: Venkat Yekkirala @ 2007-08-24 17:37 UTC (permalink / raw)
To: Paul Moore, selinux
Cc: James Morris, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-16 15:04 ` James Morris
@ 2007-08-24 16:31 ` Paul Moore
2007-08-24 18:34 ` James Morris
` (2 more replies)
0 siblings, 3 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-24 16:31 UTC (permalink / raw)
To: selinux
Cc: James Morris, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-15 22:35 ` Darrel Goeddel
@ 2007-08-16 15:04 ` James Morris
2007-08-24 16:31 ` Paul Moore
0 siblings, 1 reply; 100+ messages in thread
From: James Morris @ 2007-08-16 15:04 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-15 4:24 ` James Morris
@ 2007-08-15 22:35 ` Darrel Goeddel
2007-08-16 15:04 ` James Morris
0 siblings, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-15 22:35 UTC (permalink / raw)
To: James Morris
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-14 14:47 ` Darrel Goeddel
@ 2007-08-15 4:24 ` James Morris
2007-08-15 22:35 ` Darrel Goeddel
0 siblings, 1 reply; 100+ messages in thread
From: James Morris @ 2007-08-15 4:24 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-10 16:49 ` James Morris
@ 2007-08-14 14:47 ` Darrel Goeddel
2007-08-15 4:24 ` James Morris
0 siblings, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-14 14:47 UTC (permalink / raw)
To: James Morris
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 22:55 ` Darrel Goeddel
@ 2007-08-10 16:49 ` James Morris
2007-08-14 14:47 ` Darrel Goeddel
0 siblings, 1 reply; 100+ messages in thread
From: James Morris @ 2007-08-10 16:49 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:53 ` Paul Moore
2007-08-09 16:08 ` Darrel Goeddel
@ 2007-08-09 22:55 ` Darrel Goeddel
2007-08-10 16:49 ` James Morris
1 sibling, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 22:55 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 21:18 ` Darrel Goeddel
@ 2007-08-09 22:48 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 22:48 UTC (permalink / raw)
To: Darrel Goeddel, Joe Nall, James Morris, Stephen Smalley
Cc: SE Linux, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 16:01 ` Stephen Smalley
@ 2007-08-09 22:35 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 22:35 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 20:12 ` Joe Nall
2007-08-09 21:15 ` Stephen Smalley
@ 2007-08-09 21:18 ` Darrel Goeddel
2007-08-09 22:48 ` Paul Moore
1 sibling, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 21:18 UTC (permalink / raw)
To: Joe Nall
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 20:12 ` Joe Nall
@ 2007-08-09 21:15 ` Stephen Smalley
2007-08-09 21:18 ` Darrel Goeddel
1 sibling, 0 replies; 100+ messages in thread
From: Stephen Smalley @ 2007-08-09 21:15 UTC (permalink / raw)
To: Joe Nall
Cc: Darrel Goeddel, James Morris, Paul Moore, SE Linux, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 19:47 ` Darrel Goeddel
2007-08-09 20:12 ` Joe Nall
@ 2007-08-09 20:17 ` Paul Moore
1 sibling, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 20:17 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Joe Nall, James Morris, Stephen Smalley, SE Linux, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 19:47 ` Darrel Goeddel
@ 2007-08-09 20:12 ` Joe Nall
2007-08-09 21:15 ` Stephen Smalley
2007-08-09 21:18 ` Darrel Goeddel
2007-08-09 20:17 ` Paul Moore
1 sibling, 2 replies; 100+ messages in thread
From: Joe Nall @ 2007-08-09 20:12 UTC (permalink / raw)
To: Darrel Goeddel
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 19:20 ` Joe Nall
@ 2007-08-09 19:47 ` Darrel Goeddel
2007-08-09 20:12 ` Joe Nall
2007-08-09 20:17 ` Paul Moore
0 siblings, 2 replies; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 19:47 UTC (permalink / raw)
To: Joe Nall
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 15:48 ` Casey Schaufler
@ 2007-08-09 19:38 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 19:38 UTC (permalink / raw)
To: casey; +Cc: selinux, kaigai, joe
[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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 16:42 ` Darrel Goeddel
@ 2007-08-09 19:20 ` Joe Nall
2007-08-09 19:47 ` Darrel Goeddel
0 siblings, 1 reply; 100+ messages in thread
From: Joe Nall @ 2007-08-09 19:20 UTC (permalink / raw)
To: Darrel Goeddel
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:24 ` James Morris
@ 2007-08-09 16:42 ` Darrel Goeddel
2007-08-09 19:20 ` Joe Nall
0 siblings, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 16:42 UTC (permalink / raw)
To: James Morris
Cc: Stephen Smalley, Paul Moore, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 15:39 ` Stephen Smalley
@ 2007-08-09 16:16 ` Casey Schaufler
0 siblings, 0 replies; 100+ messages in thread
From: Casey Schaufler @ 2007-08-09 16:16 UTC (permalink / raw)
To: Stephen Smalley, casey
Cc: Paul Moore, selinux, kaigai, joe, James Morris, Eric Paris
--- 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:53 ` Paul Moore
@ 2007-08-09 16:08 ` Darrel Goeddel
2007-08-09 22:55 ` Darrel Goeddel
1 sibling, 0 replies; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 16:08 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:48 ` Paul Moore
2007-08-09 15:49 ` James Morris
@ 2007-08-09 16:01 ` Stephen Smalley
2007-08-09 22:35 ` Paul Moore
1 sibling, 1 reply; 100+ messages in thread
From: Stephen Smalley @ 2007-08-09 16:01 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:48 ` Paul Moore
@ 2007-08-09 15:49 ` James Morris
2007-08-09 16:01 ` Stephen Smalley
1 sibling, 0 replies; 100+ messages in thread
From: James Morris @ 2007-08-09 15:49 UTC (permalink / raw)
To: Paul Moore; +Cc: Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-07 14:14 Paul Moore
2007-08-09 10:57 ` KaiGai Kohei
2007-08-09 12:42 ` Stephen Smalley
@ 2007-08-09 15:48 ` Casey Schaufler
2007-08-09 19:38 ` Paul Moore
2 siblings, 1 reply; 100+ messages in thread
From: Casey Schaufler @ 2007-08-09 15:48 UTC (permalink / raw)
To: Paul Moore, selinux; +Cc: kaigai, joe
--- 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 15:32 ` Casey Schaufler
@ 2007-08-09 15:39 ` Stephen Smalley
2007-08-09 16:16 ` Casey Schaufler
0 siblings, 1 reply; 100+ messages in thread
From: Stephen Smalley @ 2007-08-09 15:39 UTC (permalink / raw)
To: casey; +Cc: Paul Moore, selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
` (2 preceding siblings ...)
2007-08-09 14:41 ` Darrel Goeddel
@ 2007-08-09 15:32 ` Casey Schaufler
2007-08-09 15:39 ` Stephen Smalley
3 siblings, 1 reply; 100+ messages in thread
From: Casey Schaufler @ 2007-08-09 15:32 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley
Cc: selinux, kaigai, joe, James Morris, Eric Paris
--- 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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:50 ` Paul Moore
@ 2007-08-09 15:13 ` Stephen Smalley
0 siblings, 0 replies; 100+ messages in thread
From: Stephen Smalley @ 2007-08-09 15:13 UTC (permalink / raw)
To: Paul Moore; +Cc: James Morris, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:57 ` Paul Moore
@ 2007-08-09 15:07 ` Darrel Goeddel
0 siblings, 0 replies; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 15:07 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, joe, James Morris, Eric Paris, kaigai
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:41 ` Darrel Goeddel
@ 2007-08-09 14:57 ` Paul Moore
2007-08-09 15:07 ` Darrel Goeddel
0 siblings, 1 reply; 100+ messages in thread
From: Paul Moore @ 2007-08-09 14:57 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Stephen Smalley, selinux, joe, James Morris, Eric Paris, kaigai
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:09 ` Darrel Goeddel
2007-08-09 14:24 ` James Morris
@ 2007-08-09 14:53 ` Paul Moore
2007-08-09 16:08 ` Darrel Goeddel
2007-08-09 22:55 ` Darrel Goeddel
1 sibling, 2 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 14:53 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Stephen Smalley, selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:59 ` James Morris
@ 2007-08-09 14:50 ` Paul Moore
2007-08-09 15:13 ` Stephen Smalley
0 siblings, 1 reply; 100+ messages in thread
From: Paul Moore @ 2007-08-09 14:50 UTC (permalink / raw)
To: James Morris; +Cc: Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:54 ` Stephen Smalley
@ 2007-08-09 14:48 ` Paul Moore
2007-08-09 15:49 ` James Morris
2007-08-09 16:01 ` Stephen Smalley
0 siblings, 2 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 14:48 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
2007-08-09 13:54 ` Stephen Smalley
2007-08-09 13:59 ` James Morris
@ 2007-08-09 14:41 ` Darrel Goeddel
2007-08-09 14:57 ` Paul Moore
2007-08-09 15:32 ` Casey Schaufler
3 siblings, 1 reply; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 14:41 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, joe, James Morris, Eric Paris, kaigai
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:09 ` Darrel Goeddel
@ 2007-08-09 14:24 ` James Morris
2007-08-09 16:42 ` Darrel Goeddel
2007-08-09 14:53 ` Paul Moore
1 sibling, 1 reply; 100+ messages in thread
From: James Morris @ 2007-08-09 14:24 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Stephen Smalley, Paul Moore, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 12:42 ` Stephen Smalley
2007-08-09 13:29 ` Paul Moore
@ 2007-08-09 14:09 ` Darrel Goeddel
2007-08-09 14:24 ` James Morris
2007-08-09 14:53 ` Paul Moore
1 sibling, 2 replies; 100+ messages in thread
From: Darrel Goeddel @ 2007-08-09 14:09 UTC (permalink / raw)
To: Stephen Smalley
Cc: Paul Moore, selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
2007-08-09 13:54 ` Stephen Smalley
@ 2007-08-09 13:59 ` James Morris
2007-08-09 14:50 ` Paul Moore
2007-08-09 14:41 ` Darrel Goeddel
2007-08-09 15:32 ` Casey Schaufler
3 siblings, 1 reply; 100+ messages in thread
From: James Morris @ 2007-08-09 13:59 UTC (permalink / raw)
To: Paul Moore; +Cc: Stephen Smalley, selinux, kaigai, joe, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
@ 2007-08-09 13:54 ` Stephen Smalley
2007-08-09 14:48 ` Paul Moore
2007-08-09 13:59 ` James Morris
` (2 subsequent siblings)
3 siblings, 1 reply; 100+ messages in thread
From: Stephen Smalley @ 2007-08-09 13:54 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 12:42 ` Stephen Smalley
@ 2007-08-09 13:29 ` Paul Moore
2007-08-09 13:54 ` Stephen Smalley
` (3 more replies)
2007-08-09 14:09 ` Darrel Goeddel
1 sibling, 4 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 13:29 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-07 14:14 Paul Moore
2007-08-09 10:57 ` KaiGai Kohei
@ 2007-08-09 12:42 ` Stephen Smalley
2007-08-09 13:29 ` Paul Moore
2007-08-09 14:09 ` Darrel Goeddel
2007-08-09 15:48 ` Casey Schaufler
2 siblings, 2 replies; 100+ messages in thread
From: Stephen Smalley @ 2007-08-09 12:42 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 10:57 ` KaiGai Kohei
@ 2007-08-09 11:48 ` Paul Moore
0 siblings, 0 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-09 11:48 UTC (permalink / raw)
To: KaiGai Kohei; +Cc: selinux, kaigai, joe
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-07 14:14 Paul Moore
@ 2007-08-09 10:57 ` KaiGai Kohei
2007-08-09 11:48 ` Paul Moore
2007-08-09 12:42 ` Stephen Smalley
2007-08-09 15:48 ` Casey Schaufler
2 siblings, 1 reply; 100+ messages in thread
From: KaiGai Kohei @ 2007-08-09 10:57 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
* [RFC 0/5] Static/fallback external labels for NetLabel
@ 2007-08-07 14:14 Paul Moore
2007-08-09 10:57 ` KaiGai Kohei
` (2 more replies)
0 siblings, 3 replies; 100+ messages in thread
From: Paul Moore @ 2007-08-07 14:14 UTC (permalink / raw)
To: selinux; +Cc: kaigai, joe
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.
^ permalink raw reply [flat|nested] 100+ messages in thread
end of thread, other threads:[~2007-08-29 16:55 UTC | newest]
Thread overview: 100+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-29 15:29 [RFC 0/5] Static/fallback external labels for NetLabel Venkat Yekkirala
2007-08-29 15:45 ` Stephen Smalley
-- strict thread matches above, loose matches on Subject: below --
2007-08-29 16:15 Venkat Yekkirala
2007-08-29 16:41 ` Paul Moore
2007-08-29 15:07 Venkat Yekkirala
2007-08-28 18:02 Venkat Yekkirala
2007-08-28 19:47 ` Paul Moore
2007-08-28 16:30 Venkat Yekkirala
2007-08-28 17:39 ` Darrel Goeddel
2007-08-28 19:36 ` Paul Moore
2007-08-28 19:26 ` Paul Moore
2007-08-28 16:13 Venkat Yekkirala
2007-08-28 16:32 ` Joe Nall
2007-08-28 19:08 ` Paul Moore
2007-08-27 22:09 Venkat Yekkirala
2007-08-28 14:51 ` Paul Moore
2007-08-28 14:58 ` Darrel Goeddel
2007-08-28 15:12 ` Darrel Goeddel
2007-08-28 15:51 ` Paul Moore
2007-08-28 16:18 ` Joe Nall
2007-08-28 18:51 ` Paul Moore
2007-08-28 19:10 ` Joe Nall
2007-08-28 19:08 ` Stephen Smalley
2007-08-28 19:48 ` Joshua Brindle
2007-08-28 22:26 ` Joe Nall
2007-08-29 0:16 ` Joshua Brindle
2007-08-29 3:45 ` Joshua Brindle
2007-08-29 4:11 ` Joshua Brindle
2007-08-29 4:49 ` Joe Nall
2007-08-29 14:04 ` Joshua Brindle
2007-08-29 15:50 ` Joe Nall
2007-08-29 16:31 ` Joshua Brindle
2007-08-29 12:21 ` Paul Moore
2007-08-29 14:26 ` Joshua Brindle
2007-08-29 14:56 ` Paul Moore
2007-08-29 15:08 ` Joshua Brindle
2007-08-29 16:55 ` Paul Moore
2007-08-28 17:23 ` Darrel Goeddel
2007-08-28 19:07 ` Paul Moore
2007-08-27 13:02 Venkat Yekkirala
2007-08-27 13:48 ` Paul Moore
2007-08-27 12:59 Venkat Yekkirala
2007-08-27 12:57 Venkat Yekkirala
2007-08-27 12:44 Venkat Yekkirala
2007-08-27 14:37 ` Paul Moore
2007-08-24 18:11 Venkat Yekkirala
2007-08-24 17:37 Venkat Yekkirala
2007-08-25 21:01 ` Paul Moore
2007-08-07 14:14 Paul Moore
2007-08-09 10:57 ` KaiGai Kohei
2007-08-09 11:48 ` Paul Moore
2007-08-09 12:42 ` Stephen Smalley
2007-08-09 13:29 ` Paul Moore
2007-08-09 13:54 ` Stephen Smalley
2007-08-09 14:48 ` Paul Moore
2007-08-09 15:49 ` James Morris
2007-08-09 16:01 ` Stephen Smalley
2007-08-09 22:35 ` Paul Moore
2007-08-09 13:59 ` James Morris
2007-08-09 14:50 ` Paul Moore
2007-08-09 15:13 ` Stephen Smalley
2007-08-09 14:41 ` Darrel Goeddel
2007-08-09 14:57 ` Paul Moore
2007-08-09 15:07 ` Darrel Goeddel
2007-08-09 15:32 ` Casey Schaufler
2007-08-09 15:39 ` Stephen Smalley
2007-08-09 16:16 ` Casey Schaufler
2007-08-09 14:09 ` Darrel Goeddel
2007-08-09 14:24 ` James Morris
2007-08-09 16:42 ` Darrel Goeddel
2007-08-09 19:20 ` Joe Nall
2007-08-09 19:47 ` Darrel Goeddel
2007-08-09 20:12 ` Joe Nall
2007-08-09 21:15 ` Stephen Smalley
2007-08-09 21:18 ` Darrel Goeddel
2007-08-09 22:48 ` Paul Moore
2007-08-09 20:17 ` Paul Moore
2007-08-09 14:53 ` Paul Moore
2007-08-09 16:08 ` Darrel Goeddel
2007-08-09 22:55 ` Darrel Goeddel
2007-08-10 16:49 ` James Morris
2007-08-14 14:47 ` Darrel Goeddel
2007-08-15 4:24 ` James Morris
2007-08-15 22:35 ` Darrel Goeddel
2007-08-16 15:04 ` James Morris
2007-08-24 16:31 ` Paul Moore
2007-08-24 18:34 ` James Morris
2007-08-24 19:02 ` Casey Schaufler
2007-08-24 19:49 ` Paul Moore
2007-08-24 20:17 ` James Morris
2007-08-24 20:24 ` Paul Moore
2007-08-24 20:47 ` Joshua Brindle
2007-08-24 20:42 ` Casey Schaufler
2007-08-24 21:10 ` Paul Moore
2007-08-24 21:37 ` Casey Schaufler
2007-08-24 20:29 ` Joshua Brindle
2007-08-28 14:03 ` Darrel Goeddel
2007-08-28 15:16 ` Paul Moore
2007-08-09 15:48 ` Casey Schaufler
2007-08-09 19:38 ` Paul Moore
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.