RE: Labeled networking packets

RE: Labeled networking packets

[Venkat Yekkirala]

[CC'ing selinux]

> -----Original Message-----
> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> Sent: Thursday, September 21, 2006 9:38 AM
> To: Joshua Brindle
> Cc: Venkat Yekkirala; Paul Moore; latten@austin.ibm.com; sds;
> jmorris@redhat.com; dwalsh@redhat.com; Darrel Goeddel; Chad Hanson
> Subject: RE: Labeled networking packets
> 
> 
> On Thu, 2006-09-21 at 07:18 -0400, Joshua Brindle wrote:
> > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > 
> > > > We really need this in if we expect useful network labeling 
> > > in rhel5 
> > > > but I'm still skeptical about reconciling cipso + ipsec 
> > > together with 
> > > > secmark.
> > > > From what I can tell cipso is taking priority and is 
> > > getting the type 
> > > > transition calculated and ipsec isn't.
> > > 
> > > It would actually be the other way around. A transition is 
> > > computed only in the labeled IPSec case. In the cipso case, 
> > > only a "flow in" check happens (this would obviously change 
> > > when whole SELinux contexts are transmitted using options, as 
> > > Paul is understood to be looking into, in the future).
> > > 
> > 
> > Eh, I knew that, sorry, I don't know what I was thinking..
> > 
> > > > I'm not sure
> > > > if this is
> > > > the desirable behavior.
> > > 
> > > Could you lay out an example; perhaps there's a 
> > > misunderstanding somewhere?
> > > 
> > 
> > In one of my first emails I pointed out that an app doing 
> getpeercon()
> > is really expecting the context of the domain on the other side of a
> > connection (peer?). With unix domain sockets that would still happen
> > (unless they were relabeled) but with ipsec connections you 
> are getting
> > a strange combination of the secmark label and the ipsec 
> label. It seems
> > strange to me that getpeercon() would care at all about the secmark
> > label, that's just for enforcement. I guess what I'm 
> getting to is why
> > is it so hard to just get the context of the domain on the 
> other side
> > (like the developer probably expects). Secmark and ipsec should be
> > entirely orthogonal it seems, maybe I haven't thought about 
> this hard
> > enough...
> 
> This discussion should be on the public list I think.
> 
> I agree about what getpeercon should return, even to the point of
> returning nothing or error if only secmark is being used.

And why should that be the case? Everything has a label on a MAC system
and why should apps care about the configuration (explicit IPSec label
Vs. implicit via secmark)?

> 
> In general, the packet label needs to represent only 1 thing 
> and here it
> is being overloaded to represent either the packet label or the remote
> domain. Note that the transition rules don't help - you still end up
> with the packet object controls referring to the incorrect type or
> getpeercon returning the wrong thing. There is simply no way 
> to satisfy
> both of these needs with 1 label.

You will want to deal with only 1 label at the app level, and it should be
the label that was used in determining whether the socket could read
the skb or not.

Can you give any examples on where differentiation is needed?

> 
> More fundamental I think is that the ipsec labeling in the 
> current form
> is useful only for selinux aware applications, which I think 
> is a major
> shortcoming. I want the policy on the remote machine (and perhaps
> trusted apps) to be able to label the _packet_ in addition to passing
> the domain for the sending process. A single domain should be able to
> send multiple packet labels (e.g., a bind process might want to send
> dns_packet_t and zone_transfer_packet_t or a multi-level trusted app).
> Passing both the packet context and the domain context allows 
> the local
> machine to make decisions based on the packet type, the 
> domain type, and
> the combination (e.g., do I trust the remote domain to send 
> the packet).

Isn't this trust enforceable in the network layout, perhaps in conjunction
with IPSec? If you aren't trusting one label from the other machine, why
would you trust 2?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Thu, 2006-09-21 at 11:01 -0400, Venkat Yekkirala wrote:
> > I agree about what getpeercon should return, even to the point of
> > returning nothing or error if only secmark is being used.
> 
> And why should that be the case? Everything has a label on a MAC system
> and why should apps care about the configuration (explicit IPSec label
> Vs. implicit via secmark)?
<snip>
> You will want to deal with only 1 label at the app level, and it should be
> the label that was used in determining whether the socket could read
> the skb or not.
> 
> Can you give any examples on where differentiation is needed?

Callers of getpeercon() expect it to return a subject label that they
can use in a call to e.g. avc_has_perm() as the source/subject context
or setexeccon() or (shudder) setcon().  If it returns
httpd_client_packet_lo_t, then the caller is going to run into trouble
upon trying to use the context as a subject label.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> On Thu, 2006-09-21 at 11:01 -0400, Venkat Yekkirala wrote:
> > > I agree about what getpeercon should return, even to the point of
> > > returning nothing or error if only secmark is being used.
> > 
> > And why should that be the case? Everything has a label on 
> a MAC system
> > and why should apps care about the configuration (explicit 
> IPSec label
> > Vs. implicit via secmark)?
> <snip>
> > You will want to deal with only 1 label at the app level, 
> and it should be
> > the label that was used in determining whether the socket could read
> > the skb or not.
> > 
> > Can you give any examples on where differentiation is needed?
> 
> Callers of getpeercon() expect it to return a subject label that they
> can use in a call to e.g. avc_has_perm() as the source/subject context
> or setexeccon() or (shudder) setcon().  If it returns
> httpd_client_packet_lo_t, then the caller is going to run into trouble
> upon trying to use the context as a subject label.

Yes, the caller is going to run into trouble here, but only because your
policy
is wanting it, is it not? i.e., a trusted app can always work in conjunction
with policy (via transitions and whatnot if need be) in servicing the
request
at the appropriate label.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Thu, 2006-09-21 at 12:27 -0400, Venkat Yekkirala wrote:
> > On Thu, 2006-09-21 at 11:01 -0400, Venkat Yekkirala wrote:
> > > > I agree about what getpeercon should return, even to the point of
> > > > returning nothing or error if only secmark is being used.
> > > 
> > > And why should that be the case? Everything has a label on 
> > a MAC system
> > > and why should apps care about the configuration (explicit 
> > IPSec label
> > > Vs. implicit via secmark)?
> > <snip>
> > > You will want to deal with only 1 label at the app level, 
> > and it should be
> > > the label that was used in determining whether the socket could read
> > > the skb or not.
> > > 
> > > Can you give any examples on where differentiation is needed?
> > 
> > Callers of getpeercon() expect it to return a subject label that they
> > can use in a call to e.g. avc_has_perm() as the source/subject context
> > or setexeccon() or (shudder) setcon().  If it returns
> > httpd_client_packet_lo_t, then the caller is going to run into trouble
> > upon trying to use the context as a subject label.
> 
> Yes, the caller is going to run into trouble here, but only because your
> policy
> is wanting it, is it not? i.e., a trusted app can always work in conjunction
> with policy (via transitions and whatnot if need be) in servicing the
> request
> at the appropriate label.

I doubt it will work in all cases. And returning a label when in fact we
don't have the information (e.g., when only using secmark) changes the
semantics of this call. The call should indicate what information it has
by returning an error without ipsec or netlabel.

I also think this change is confusing which object class we are dealing
with. Packets are a separate object from a process. Yes packets may
inherit the context of the process in some circumstances, but they
remain distinct objects. Making getpeercon return the packet label is
returning the label of the wrong object.

I started to write a long post on scenarios where the distinction would
be important, but honestly I think it comes down to what I said above.
We have two objects and each object should be labeled independently. It
might be possible to use transition rules to combine the information
from the two labels into a third (which is essentially what would be
happening), but it mis-represents the underlying system and is going to
be difficult to manage. It would require an explosion of types to not
lose information (i.e., one type for every possible process / packet
type pair).

The reconciliation scheme currently changes the semantics of both
getpeercon and the new packet object classes in what I see as
non-intuitive ways. Apps and policy will have to take into account which
labeling mechanism is in use (e.g., the packet object class checks will
sometimes get packet types and sometimes get process types - same for
getpeercon). It seems like this will require additional policy and code.

The simplest solution is to keep the labels separate as Josh suggested.
However, I think that it would be better to pass packet and process
labels over ipsec but that would likely be a fundamental change to the
ipsec labeling model.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> > > Callers of getpeercon() expect it to return a subject 
> label that they
> > > can use in a call to e.g. avc_has_perm() as the 
> source/subject context
> > > or setexeccon() or (shudder) setcon().  If it returns
> > > httpd_client_packet_lo_t, then the caller is going to run 
> into trouble
> > > upon trying to use the context as a subject label.
> > 
> > Yes, the caller is going to run into trouble here, but only 
> because your
> > policy
> > is wanting it, is it not? i.e., a trusted app can always 
> work in conjunction
> > with policy (via transitions and whatnot if need be) in 
> servicing the
> > request
> > at the appropriate label.
> 
> I doubt it will work in all cases. And returning a label when 
> in fact we
> don't have the information (e.g., when only using secmark)

The reality is that you DO have the information. The source of the info
has entirely to do with the network layout/configuration, resulting
in the use of externally labeled packets Vs. internal. E.g. All the data
coming thru a Secret interface is Secret. It doesn't matter whether the
data was labeled as such prior to entering which it may not for reasons
of performance, trust in the underlying network hardware, etc.

> changes the
> semantics of this call. The call should indicate what 
> information it has
> by returning an error without ipsec or netlabel.

You could simulate the error by letting httpd_client_packet_lo_t
run into trouble for example; or smartly handle it via policy
transitions, etc.

> 
> I also think this change is confusing which object class we 
> are dealing
> with. Packets are a separate object from a process. Yes packets may
> inherit the context of the process in some circumstances, but they
> remain distinct objects.

Agreed and I don't see where we are changing this.

> Making getpeercon return the packet label is
> returning the label of the wrong object.

If a packet arrived at the sock as Secret (the details of how it came
to assume that label is again to do with considerations of network
layout, trust, and such as mentioned earlier), it OUGHT to be treated
as having come from a Secret peer.

> 
> I started to write a long post on scenarios where the 
> distinction would
> be important, but honestly I think it comes down to what I said above.

I would like to look at a couple.

> We have two objects and each object should be labeled 
> independently. It
> might be possible to use transition rules to combine the information
> from the two labels into a third (which is essentially what would be
> happening), but it mis-represents the underlying system and 
> is going to
> be difficult to manage. It would require an explosion of types to not
> lose information (i.e., one type for every possible process / packet
> type pair).

Not necessarily, you would do the extra rules only when you ARE
using labeled IPSec and that too when you aren't interested in
your trusted app seeing the IPSec Type. That's the only time you
would do transitions. The reconciliation logic is about progressively
refining the label of the packet all the while making sure, secmark
and such have a say in it.

> 
> The reconciliation scheme currently changes the semantics of both
> getpeercon and the new packet object classes in what I see as
> non-intuitive ways. Apps and policy will have to take into 
> account which
> labeling mechanism is in use (e.g., the packet object class 
> checks will
> sometimes get packet types and sometimes get process types

Where are they getting the process types?

> - same for
> getpeercon). It seems like this will require additional 
> policy and code.

I would appreciate an example.
> 
> The simplest solution is to keep the labels separate as Josh 
> suggested.

The thing I am trying to understand is, why would an app want
to know the entry/exit point context? This context is now for
flow control checks. I believe a lot of the confusion here
might have to do with naming.

> However, I think that it would be better to pass packet and process
> labels over ipsec but that would likely be a fundamental change to the
> ipsec labeling model.

More info and checks are always good, but from a complexity and performance
standpoint
why couldn't we have the source machine worry about resolving the two
labels? 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Thu, 2006-09-21 at 13:14 -0400, Venkat Yekkirala wrote:
> > > > Callers of getpeercon() expect it to return a subject 
> > label that they
> > > > can use in a call to e.g. avc_has_perm() as the 
> > source/subject context
> > > > or setexeccon() or (shudder) setcon().  If it returns
> > > > httpd_client_packet_lo_t, then the caller is going to run 
> > into trouble
> > > > upon trying to use the context as a subject label.
> > > 
> > > Yes, the caller is going to run into trouble here, but only 
> > because your
> > > policy
> > > is wanting it, is it not? i.e., a trusted app can always 
> > work in conjunction
> > > with policy (via transitions and whatnot if need be) in 
> > servicing the
> > > request
> > > at the appropriate label.
> > 
> > I doubt it will work in all cases. And returning a label when 
> > in fact we
> > don't have the information (e.g., when only using secmark)
> 
> The reality is that you DO have the information.

No you don't - with secmark you have information about the packet, but
not the sending process. You can potentially infer information, but that
is all.

>  The source of the info
> has entirely to do with the network layout/configuration, resulting
> in the use of externally labeled packets Vs. internal. E.g. All the data
> coming thru a Secret interface is Secret.

That is the distinction I'm trying to make - network layout or
configuration effects the label of the packet. The process that sent
that object is different. This becomes - I think - more important when
you begin to use this information for more than MLS style
confidentiality.

>  It doesn't matter whether the
> data was labeled as such prior to entering which it may not for reasons
> of performance, trust in the underlying network hardware, etc.
> 

I agree that it doesn't matter whether the packet was labeled on the
current or sending machine - but it still says nothing about the context
of the originating process.

Actually, let me modify that a bit. With the current ipsec labeling you
could set up things so that packets are labeled with a context that
implies something about the packet itself (e.g., http_packet_t). The
current proposal does _not_ do this.

Currently ipsec transfers information about the sending process. In the
MLS world these are the same - a secret process sends secret packets -
but with type enforcement things can and usually are different.
Maintaining this differentiation is important.

Policy that deals with the packet object class is enforcing access based
on the security attributes of the packet (usually implied by network
layout, etc.). Applications that use getpeercon are enforcing access
based on the security context of the sending application. Different
concepts, different objects, and, therefore, different labels. I think
mixing these two things is not a good idea.

> > changes the
> > semantics of this call. The call should indicate what 
> > information it has
> > by returning an error without ipsec or netlabel.
> 
> You could simulate the error by letting httpd_client_packet_lo_t
> run into trouble for example; or smartly handle it via policy
> transitions, etc.
> 

This obscures the fact that there is no _explicit_ data about the
sending process.

> > 
> > I also think this change is confusing which object class we 
> > are dealing
> > with. Packets are a separate object from a process. Yes packets may
> > inherit the context of the process in some circumstances, but they
> > remain distinct objects.
> 
> Agreed and I don't see where we are changing this.
> 

Of course this is a change - see above.

> > Making getpeercon return the packet label is
> > returning the label of the wrong object.
> 
> If a packet arrived at the sock as Secret (the details of how it came
> to assume that label is again to do with considerations of network
> layout, trust, and such as mentioned earlier), it OUGHT to be treated
> as having come from a Secret peer.
> 

Again, this implied relationship only makes sense for MLS. With type
enforcement there is no sane way to infer the process type from the
packet type.

For example, firefox_t, wget_t, rss_aggregator_t might be types for
applications that all generate packets of type http_packet_t.
Differentiating these makes it possible to assign the _correct_
equivalence type to the packets that is distinct from the application
that generated it. This is what most policy would want to deal with.

A security aware application, however, might want to enforce
finer-grained access control over urls based on the context of the
application (e.g., rss_aggregator_t can only access urls that return rss
data).

> > 
> > I started to write a long post on scenarios where the 
> > distinction would
> > be important, but honestly I think it comes down to what I said above.
> 
> I would like to look at a couple.
> 

There is one above, though somewhat contrived. In general, though, we
might want to:

1) Have 1 process context generated multiple packet types. bind_t might
generate packets of type dns_packet_t and zone_transfer_t. Or a
multi-level trusted app might generate both secret and top-secret packet
types while its label is top-secret.

2) Have 2 processes generate the same packet types - see above.

3) Have 1 process generate 1 packet context that is different from the
process context (e.g., httpd_t generates http_packet_t).

The reciever of these packets might want to enforce security based on
any of the above attributes (packet or process). By collapsing these
into a single type you lose information.

> > We have two objects and each object should be labeled 
> > independently. It
> > might be possible to use transition rules to combine the information
> > from the two labels into a third (which is essentially what would be
> > happening), but it mis-represents the underlying system and 
> > is going to
> > be difficult to manage. It would require an explosion of types to not
> > lose information (i.e., one type for every possible process / packet
> > type pair).
> 
> Not necessarily, you would do the extra rules only when you ARE
> using labeled IPSec and that too when you aren't interested in
> your trusted app seeing the IPSec Type. That's the only time you
> would do transitions. The reconciliation logic is about progressively
> refining the label of the packet all the while making sure, secmark
> and such have a say in it.
> 
> > 
> > The reconciliation scheme currently changes the semantics of both
> > getpeercon and the new packet object classes in what I see as
> > non-intuitive ways. Apps and policy will have to take into 
> > account which
> > labeling mechanism is in use (e.g., the packet object class 
> > checks will
> > sometimes get packet types and sometimes get process types
> 
> Where are they getting the process types?
> 

The current ipsec proposals labels the packet with the process context
by default, correct? (yes, I know that you can set up different mappings
manually - I'm trying to talk about what will be the most widely used
config) This is in keeping with the spirit of CIPSO I think, where you
are transferring the process labels. In this case the packet rules would
see something like httpd_t instead of what you would see with secmark
currently - http_packet_t (well, http_server_packet_t.

> > - same for
> > getpeercon). It seems like this will require additional 
> > policy and code.
> 
> I would appreciate an example.

This is assuming that we are trying to deploy a single policy to cover
both secmark alone and secmark plus ipsec (which is what we and probably
the other distros want to ship). Currently you need to:

1) For non-selinux aware apps: generate additional allow rules to allow
both receipt of addition types for packet objects (e.g, http_packet_t
and httpd_t) _or_ create type transition rules that generate
http_packet_t or a 3rd type when secmark and ipsec are both used (which
would need more allow rules if a 3rd type is generated).

2) For selinux-aware apps: manually make calls to resolve type_change
rules or be prepared to handle multiple types (again with more policy to
allow the additional types). This is essentially a work-around for the
fact that you aren't getting back the process type.

> > 
> > The simplest solution is to keep the labels separate as Josh 
> > suggested.
> 
> The thing I am trying to understand is, why would an app want
> to know the entry/exit point context?

I don't agree with your model that secmark is an entry/exit point.

My assertion is that there is a packet type and a process type - secmark
sets the packet type and, currently, ipsec stores the process type in
the SA for the packet (implies, whatever). Keeping those separate allows
you to see either the label of the packet of the label of the process.

>  This context is now for
> flow control checks. I believe a lot of the confusion here
> might have to do with naming.
> 

No, it is that I don't agree with the proposed model. I think that it
confuses several concepts and obscures the underlying architecture.

> > However, I think that it would be better to pass packet and process
> > labels over ipsec but that would likely be a fundamental change to the
> > ipsec labeling model.
> 
> More info and checks are always good, but from a complexity and performance
> standpoint
> why couldn't we have the source machine worry about resolving the two
> labels? 

Because they are logically distinct.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

[Sorry, this is long but couldn't pare it down much to keep context]

> > > I doubt it will work in all cases. And returning a label when 
> > > in fact we
> > > don't have the information (e.g., when only using secmark)
> > 
> > The reality is that you DO have the information.
> 
> No you don't - with secmark you have information about the packet, but
> not the sending process. You can potentially infer 
> information, but that
> is all.

As you note later, with labeled-ipsec, you have the label on the
sending process as well.

> 
> >  The source of the info
> > has entirely to do with the network layout/configuration, resulting
> > in the use of externally labeled packets Vs. internal. E.g. 
> All the data
> > coming thru a Secret interface is Secret.
> 
> That is the distinction I'm trying to make - network layout or
> configuration effects

I know you meant to say "affects" here, and I was arguing that it
actually "effects" (or conveys) the label of the packet. :)

> the label of the packet. The process that sent
> that object is different.

True. And where you do infact need to differentiate based on the process
(rss_aggregator_t), you use labeled-ipsec and convey BOTH the packet Type
and the Process Type as rss_aggregator_http_packet_t (using a transition) to
the
app. Voila, your app is now able to make decisions based on BOTH the attribs
using a single sid.

> This becomes - I think - more important when
> you begin to use this information for more than MLS style
> confidentiality.
> 
> >  It doesn't matter whether the
> > data was labeled as such prior to entering which it may not 
> for reasons
> > of performance, trust in the underlying network hardware, etc.
> > 
> 
> I agree that it doesn't matter whether the packet was labeled on the
> current or sending machine - but it still says nothing about 
> the context
> of the originating process.

It does when you use labeled-ipsec and when you convey BOTH the packet
Type and the process Type to the app in a single sid. And we could
change the name of getpeercon() to be more meaningful/accurate to,
say getdatacon(), if need be.

> 
> Actually, let me modify that a bit. With the current ipsec 
> labeling you
> could set up things so that packets are labeled with a context that
> implies something about the packet itself (e.g., http_packet_t). The
> current proposal does _not_ do this.

It actually does, via the transition logic, as mentioned in the previous
comment.

> 
> Currently ipsec transfers information about the sending 
> process. In the
> MLS world these are the same - a secret process sends secret packets -
> but with type enforcement things can and usually are different.
> Maintaining this differentiation is important.
> 
> Policy that deals with the packet object class is enforcing 
> access based
> on the security attributes of the packet (usually implied by network
> layout, etc.). Applications that use getpeercon are enforcing access
> based on the security context of the sending application. Different
> concepts, different objects, and, therefore, different labels. I think
> mixing these two things is not a good idea.

As opposed to mixing the two, we are actually resolving/reconciling
the two for proper access control (in assuring rss_aggregator_http_t
can only access the rss stuff, in your example).

> 
> > > changes the
> > > semantics of this call. The call should indicate what 
> > > information it has
> > > by returning an error without ipsec or netlabel.
> > 
> > You could simulate the error by letting httpd_client_packet_lo_t
> > run into trouble for example; or smartly handle it via policy
> > transitions, etc.
> > 
> 
> This obscures the fact that there is no _explicit_ data about the
> sending process.

As determined/enforced by policy, correct.

I see 3 scenarios here:

1. You use the iptables rule to tell you the packet Type in conjunction
   with a labeled-ipsec SA that tells you the process type. You are
   then conveying BOTH to the app, using transition rules, in a single
   context (perhaps better regarded as a "data" context as opposed to a
   pure peer context).

2. You aren't using labeled-ipsec, you are on a (usually a trusted) network
and you
   have chosen to convey the data (thru explicit/deliberate network
   layout/config) about the sending process, where you have setup your
   iptables rule with the sending proc's context.

3. You aren't using labeled-ipsec, you are on the Internet, and you have
   the packet Type initially, and your policy would then treat it
accordingly.

> 
> > > 
> > > I also think this change is confusing which object class we 
> > > are dealing
> > > with. Packets are a separate object from a process. Yes 
> packets may
> > > inherit the context of the process in some circumstances, but they
> > > remain distinct objects.
> > 
> > Agreed and I don't see where we are changing this.
> > 
> 
> Of course this is a change - see above.
> 
> > > Making getpeercon return the packet label is
> > > returning the label of the wrong object.
> > 
> > If a packet arrived at the sock as Secret (the details of 
> how it came
> > to assume that label is again to do with considerations of network
> > layout, trust, and such as mentioned earlier), it OUGHT to 
> be treated
> > as having come from a Secret peer.
> > 
> 
> Again, this implied relationship only makes sense for MLS. With type
> enforcement there is no sane way to infer the process type from the
> packet type.

There is, per scenario 2 in the precious comment. And where you can't
infer, you acknowledge that in the policy, by optionally transitioning
to unlabeled_http_packet_t and treating it accordingly.

> 
> For example, firefox_t, wget_t, rss_aggregator_t might be types for
> applications that all generate packets of type http_packet_t.
> Differentiating these makes it possible to assign the _correct_
> equivalence type

This is what we are doing using transitions.

> to the packets that is distinct from the application
> that generated it. This is what most policy would want to deal with.
> 
> A security aware application, however, might want to enforce
> finer-grained access control over urls based on the context of the
> application (e.g., rss_aggregator_t can only access urls that 
> return rss
> data).

Yes, this can be done as mentioned earlier.

> 
> > > 
> > > I started to write a long post on scenarios where the 
> > > distinction would
> > > be important, but honestly I think it comes down to what 
> I said above.
> > 
> > I would like to look at a couple.
> > 
> 
> There is one above, though somewhat contrived. In general, though, we
> might want to:
> 
> 1) Have 1 process context generated multiple packet types. 
> bind_t might
> generate packets of type dns_packet_t and zone_transfer_t. Or a
> multi-level trusted app might generate both secret and 
> top-secret packet
> types while its label is top-secret.

It's in fact this packet type that would come across labeled-ipsec
in this scenario. If you also wanted to convey the process Type,
use bind_zone_transfer_t so the ipsec SA will use this context.

> 
> 2) Have 2 processes generate the same packet types - see above.

Again, you could always convey BOTH the packet label and the proc
label, by sort of commingling them.

> 
> 3) Have 1 process generate 1 packet context that is different from the
> process context (e.g., httpd_t generates http_packet_t).

Yes, this is (http_packet_t) is what would normally come across via
labeled-ipsec.

> 
> The reciever of these packets might want to enforce security based on
> any of the above attributes (packet or process). By collapsing these
> into a single type you lose information.

There's no loss of info. You are using transitions to weld, if you will,
the two together. You only "lose" info, when you don't properly weld.

> 
> > > We have two objects and each object should be labeled 
> > > independently. It
> > > might be possible to use transition rules to combine the 
> information
> > > from the two labels into a third (which is essentially 
> what would be
> > > happening), but it mis-represents the underlying system and 

The "mis-representation" will depend on how well the policy is written.
No different from having these two labels all the way thru, but not
having the policy done correctly to use them.

> > > is going to
> > > be difficult to manage. It would require an explosion of 
> types to not
> > > lose information (i.e., one type for every possible 
> process / packet
> > > type pair).

You wouldn't do it for all possible process/packet type pairs.
You would define a process-packet Type only where you need to have
BOTH the elements (such as in the httpd/rss_aggregator
scenario like you mentioned earlier). What other scenarios come
to mind here?

> > 
> > Not necessarily, you would do the extra rules only when you ARE
> > using labeled IPSec and that too when you aren't interested in
> > your trusted app seeing the IPSec Type. That's the only time you
> > would do transitions. The reconciliation logic is about 
> progressively
> > refining the label of the packet all the while making sure, secmark
> > and such have a say in it.
> > 
> > > 
> > > The reconciliation scheme currently changes the semantics of both
> > > getpeercon

Perhaps we can rename this to getdatacon or something like that. Or
perhaps just better document getpeercon.

> and the new packet object classes in what I see as
> > > non-intuitive ways. Apps and policy will have to take into 
> > > account which
> > > labeling mechanism is in use (e.g., the packet object class 
> > > checks will
> > > sometimes get packet types and sometimes get process types

As long as the policy just worries about the "data" context, things
should be OK.

> > 
> > Where are they getting the process types?
> > 
> 
> The current ipsec proposals labels the packet with the process context
> by default, correct? (yes, I know that you can set up 
> different mappings
> manually - I'm trying to talk about what will be the most widely used
> config) This is in keeping with the spirit of CIPSO I think, where you
> are transferring the process labels. In this case the packet 
> rules would
> see something like httpd_t instead of what you would see with secmark
> currently - http_packet_t (well, http_server_packet_t.
> 
> > > - same for
> > > getpeercon). It seems like this will require additional 
> > > policy and code.
> > 
> > I would appreciate an example.
> 
> This is assuming that we are trying to deploy a single policy to cover
> both secmark alone and secmark plus ipsec (which is what we 
> and probably
> the other distros want to ship). Currently you need to:
> 
> 1) For non-selinux aware apps: generate additional allow 
> rules to allow
> both receipt of addition types for packet objects (e.g, http_packet_t
> and httpd_t) _or_ create type transition rules that generate
> http_packet_t or a 3rd type when secmark and ipsec are both 
> used (which
> would need more allow rules if a 3rd type is generated).

You don't have to always do everything you mention. For example:

1. Only one allow rule for httpd_t, if your app MUST be using ipsec
   or if IPSec is optional, another allow rule for http_packet_t.
or
2. A transition to http_packet_t and an allow rule for http_packet_t
   (which you should currently have anyway).
or
3. A transition to httpd_http_t and an allow rule for httpd_http_t.

So, you are talking only 1 additional rule.

> 
> 2) For selinux-aware apps: manually make calls to resolve type_change
> rules or be prepared to handle multiple types (again with 
> more policy to
> allow the additional types).

A getpeercon() is happening anyway and SELinux had already done its
magic in "appropriately" "commingling" the two labels. So, you would
have just one transition rule in addition to the others that you would
have anyway; you would just use this "data" context in a setexeccon,
avc_has_perm,
etc.

> This is essentially a work-around for the
> fact that you aren't getting back the process type.

You are, if you defined the transitions and ONLY WHEN YOU
REALLY NEED THEM.

> 
> > > 
> > > The simplest solution is to keep the labels separate as Josh 
> > > suggested.
> > 
> > The thing I am trying to understand is, why would an app want
> > to know the entry/exit point context?
> 
> I don't agree with your model that secmark is an entry/exit point.

As viewed currently (as a marking system for packet Types), it's probably
not.

But why can't it be instead a SECPOINT or a SECGATE, which instead defines
the Type of a security point, with all packets coming thru assuming that
Type, and with additional flow control checks to make sure only certain
process Types (via IPSec) can come thru those points?

> 
> My assertion is that there is a packet type and a process 
> type - secmark
> sets the packet type and, currently, ipsec stores the process type in
> the SA for the packet (implies, whatever). Keeping those 
> separate allows
> you to see either the label of the packet of the label of the process.
> 
> >  This context is now for
> > flow control checks. I believe a lot of the confusion here
> > might have to do with naming.
> > 
> 
> No, it is that I don't agree with the proposed model. I think that it
> confuses several concepts and obscures the underlying architecture.

I would instead argue (as I have) that the model actually makes it possible
to handle various scenarios under the current constraints (only one field
on the skb, only one spi field on an IPSec SA, etc.).

> 
> > > However, I think that it would be better to pass packet 
> and process
> > > labels over ipsec but that would likely be a fundamental 
> change to the
> > > ipsec labeling model.
> > 
> > More info and checks are always good, but from a complexity 
> and performance
> > standpoint
> > why couldn't we have the source machine worry about 
> resolving the two
> > labels? 
> 
> Because they are logically distinct.

We very much recognize that they are disctinct and hence the need for
transitions ans what not to handle them accordingly in the policy.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

> -----Original Message-----
> From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
<snip>
> > I agree that it doesn't matter whether the packet was 
> labeled on the 
> > current or sending machine - but it still says nothing about the 
> > context of the originating process.
> 
> It does when you use labeled-ipsec and when you convey BOTH 
> the packet Type and the process Type to the app in a single 
> sid. And we could change the name of getpeercon() to be more 
> meaningful/accurate to, say getdatacon(), if need be.
> 

I agree with Karl here. To say the least taking one kind of object
(association) and and another kind of object (packet) and using those
contexts to calculate a context for another kind of object (domain? Or
maybe something else?) seems fairly hacky to say the least.

And it also isn't what I (personally) want. I want the domain on the
other end, I don't want to have to have some incredibly complex setup of
associations and secmarks just to get recalculate the context we already
had on the other end, I just want it. That is what getpeercon() should
return. I don't care either way about getdatacon() but getpeercon should
stick around and should get the peer domain.

This is of interest to me for the policy management server. We need the
full context of the client in order to do access control checks on the
policy updates. That means the context I get from getpeercon() will be
the source of access checks. Source should always (in this context
anyway) be a domain. This transition scheme gives me some kind of object
type and I'm not sure it's a domain (or if its anything), just because I
can create crazy labeling to give the same context doesn't mean it's a
domain.

And this doesn't even begin to address what a mess managing all this
labeling is going to be. We haven't even decided how to handle secmark
rules in distros yet and now we are going to need a whole new set of
labels (that also have to interact with local non-selinux
configurations)

That said, I'm thinking that this scheme should be scrapped and instead
we do something like the following: secmark is totally non-relavent to
the peer context, it labels packets and I don't believe there is ever a
need to know the label of a packet (if there is we can add
getpacketcon()). Secmark will be used for enforcement of network flow
only. The security association can have a context, that context will be
used for enforcement of polmatch, just like now. The label won't be used
for getpeercon(), only to create associations and give access to them.
Then the actual domain making the connection can be sent to the remote
side by racoon, this should be the label that getpeercon() returns. Note
that racoon can send the domain context (default) or if necessary do
some sort of translation (eg., system_u:object_r:sysadm_t:s0 ->
system_u:object_r:sysadm_t) or similar, it will be up to the local
configuration to decide how that works though.

This is, IMO, a much cleaner, simpler and more pure implementation that
doesn't try mixing different kinds of objects, each object fits in its
own place and when we call getpeercon() we know we'll be getting a
domain that we can use in rule lookups or setexeccon(). 

If there is no ipsec then getpeercon() returns an error, as it should,
to let the application asking know that the peer context isn't available
(the reconciliation with unlabaled->secmark->somethingelse could be very
dangerous since the application can't know if it can really trust the
label)

Comments? I'm starting to look at Joy's racoon patch to see what we can
do there but I think this is the correct way to handle this problem.


Joshua Brindle


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Thu, 2006-09-21 at 22:04 -0400, Joshua Brindle wrote:
> > -----Original Message-----
> > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> <snip>
> > > I agree that it doesn't matter whether the packet was 
> > labeled on the 
> > > current or sending machine - but it still says nothing about the 
> > > context of the originating process.
> > 
> > It does when you use labeled-ipsec and when you convey BOTH 
> > the packet Type and the process Type to the app in a single 
> > sid. And we could change the name of getpeercon() to be more 
> > meaningful/accurate to, say getdatacon(), if need be.
> > 
> 
> I agree with Karl here. To say the least taking one kind of object
> (association) and and another kind of object (packet) and using those
> contexts to calculate a context for another kind of object (domain? Or
> maybe something else?) seems fairly hacky to say the least.

Yes, that would be like computing a process label from an old process
label and an executable file label.  Or like computing a new file label
from a process label and a parent directory label.  Who could imagine
such a thing?  ;)

Seriously, there isn't anything wrong with the notion of using label
transitions to capture state from multiple labels, and we do that all
the time for _object_ labels.  Where we run into a problem here is the
fact that the user of getpeercon() wants a subject label, not an object
label.  If the label transition function had an inverse, that might be
workable, although I'd hate to require applications to deal with it, but
it doesn't have an inverse (in general; specific policy may permit such
inversion, but the function itself provides no such guarantee).

> And it also isn't what I (personally) want. I want the domain on the
> other end, I don't want to have to have some incredibly complex setup of
> associations and secmarks just to get recalculate the context we already
> had on the other end, I just want it. That is what getpeercon() should
> return. I don't care either way about getdatacon() but getpeercon should
> stick around and should get the peer domain.

Yes, we don't want to change the getpeercon() interface, and we want
consistent semantics between AF_LOCAL and AF_INET.

> That said, I'm thinking that this scheme should be scrapped and instead
> we do something like the following: secmark is totally non-relavent to
> the peer context, it labels packets and I don't believe there is ever a
> need to know the label of a packet (if there is we can add
> getpacketcon()). Secmark will be used for enforcement of network flow
> only.

That may be the right approach given the divergent purposes of secmark
vs. labeled networking, but it doesn't resolve what motivated the secid
reconciliation work in the first place.

>  The security association can have a context, that context will be
> used for enforcement of polmatch, just like now. The label won't be used
> for getpeercon(), only to create associations and give access to them.
> Then the actual domain making the connection can be sent to the remote
> side by racoon, this should be the label that getpeercon() returns.

If you just mean that the SA context would come from the flow's context
rather than the SPD rule, then I think we all agreed to that.  But the
context is still ultimately stored in the SA and obtained from it by
getpeercon().  That doesn't change.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

On Fri, 2006-09-22 at 08:47 -0400, Stephen Smalley wrote:
> On Thu, 2006-09-21 at 22:04 -0400, Joshua Brindle wrote:
> > > -----Original Message-----
> > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com]
> > <snip>
> > > > I agree that it doesn't matter whether the packet was
> > > labeled on the
> > > > current or sending machine - but it still says nothing about the
> > > > context of the originating process.
> > >
> > > It does when you use labeled-ipsec and when you convey BOTH
> > > the packet Type and the process Type to the app in a single
> > > sid. And we could change the name of getpeercon() to be more
> > > meaningful/accurate to, say getdatacon(), if need be.
> > >
> >
> > I agree with Karl here. To say the least taking one kind of object
> > (association) and and another kind of object (packet) and using
> those
> > contexts to calculate a context for another kind of object (domain?
> Or
> > maybe something else?) seems fairly hacky to say the least.
> 
> Yes, that would be like computing a process label from an old process
> label and an executable file label.  Or like computing a new file
> label
> from a process label and a parent directory label.  Who could imagine
> such a thing?  ;)
> 
bah, fair enough :\. I guess the reason I was objecting was because the
objects seem *very* different. standard object and subject transitions
seem pretty intuitive (I'm in a domain, i execute something, I'm in a
new domain or directories containing files guiding transitions. packets
and associations are totally separate and used for totally different
things. And the other problem was that I don't even know if we were
*trying* to derive a subject label or not, some of the examples I've
seen floating around indicate that others don't either.

> Seriously, there isn't anything wrong with the notion of using label
> transitions to capture state from multiple labels, and we do that all
> the time for _object_ labels.  Where we run into a problem here is the
> fact that the user of getpeercon() wants a subject label, not an
> object

This was my main point

> label.  If the label transition function had an inverse, that might be
> workable, although I'd hate to require applications to deal with it,
> but
> it doesn't have an inverse (in general; specific policy may permit
> such
> inversion, but the function itself provides no such guarantee).
> 
> > And it also isn't what I (personally) want. I want the domain on the
> > other end, I don't want to have to have some incredibly complex
> setup of
> > associations and secmarks just to get recalculate the context we
> already
> > had on the other end, I just want it. That is what getpeercon()
> should
> > return. I don't care either way about getdatacon() but getpeercon
> should
> > stick around and should get the peer domain.
> 
> Yes, we don't want to change the getpeercon() interface, and we want
> consistent semantics between AF_LOCAL and AF_INET.
> 
> > That said, I'm thinking that this scheme should be scrapped and
> instead
> > we do something like the following: secmark is totally non-relavent
> to
> > the peer context, it labels packets and I don't believe there is
> ever a
> > need to know the label of a packet (if there is we can add
> > getpacketcon()). Secmark will be used for enforcement of network
> flow
> > only.
> 
> That may be the right approach given the divergent purposes of secmark
> vs. labeled networking, but it doesn't resolve what motivated the
> secid
> reconciliation work in the first place.
> 
> >  The security association can have a context, that context will be
> > used for enforcement of polmatch, just like now. The label won't be
> used
> > for getpeercon(), only to create associations and give access to
> them.
> > Then the actual domain making the connection can be sent to the
> remote
> > side by racoon, this should be the label that getpeercon() returns.
> 
> If you just mean that the SA context would come from the flow's
> context
> rather than the SPD rule, then I think we all agreed to that.  But the
> context is still ultimately stored in the SA and obtained from it by
> getpeercon().  That doesn't change.
> 
This scheme has a new label that is negotiated by racoon and is used as
the subject label returned by getpeercon(), it is different from what we
are already doing. The rest would basically be the same, there would be
no reconciliation. The only thing I'm not sure of here is the
interaction of the label negotiated by racoon and a cipso label. It
almost seems like we need to disallow using them at the same time, I
suspect people might not like this limitation though.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Fri, 2006-09-22 at 08:47 -0400, Stephen Smalley wrote:
> On Thu, 2006-09-21 at 22:04 -0400, Joshua Brindle wrote:
> > > -----Original Message-----
> > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > <snip>
> > > > I agree that it doesn't matter whether the packet was 
> > > labeled on the 
> > > > current or sending machine - but it still says nothing about the 
> > > > context of the originating process.
> > > 
> > > It does when you use labeled-ipsec and when you convey BOTH 
> > > the packet Type and the process Type to the app in a single 
> > > sid. And we could change the name of getpeercon() to be more 
> > > meaningful/accurate to, say getdatacon(), if need be.
> > > 
> > 
> > I agree with Karl here. To say the least taking one kind of object
> > (association) and and another kind of object (packet) and using those
> > contexts to calculate a context for another kind of object (domain? Or
> > maybe something else?) seems fairly hacky to say the least.
> 
> Yes, that would be like computing a process label from an old process
> label and an executable file label.  Or like computing a new file label
> from a process label and a parent directory label.  Who could imagine
> such a thing?  ;)
> 
> Seriously, there isn't anything wrong with the notion of using label
> transitions to capture state from multiple labels, and we do that all
> the time for _object_ labels.

The difference is that we usually do this on a state transition (e.g.,
creating a new process or object) to capture relevant portions of the
previous state moving forward. Here the suggestion is to use transitions
to simply encode multiple states via transition for transmission with
the express purpose of reversing that transition on the other end. A
very different use I think.

>   Where we run into a problem here is the
> fact that the user of getpeercon() wants a subject label, not an object
> label.  If the label transition function had an inverse, that might be
> workable, although I'd hate to require applications to deal with it, but
> it doesn't have an inverse (in general; specific policy may permit such
> inversion, but the function itself provides no such guarantee).
> 
> > And it also isn't what I (personally) want. I want the domain on the
> > other end, I don't want to have to have some incredibly complex setup of
> > associations and secmarks just to get recalculate the context we already
> > had on the other end, I just want it. That is what getpeercon() should
> > return. I don't care either way about getdatacon() but getpeercon should
> > stick around and should get the peer domain.
> 
> Yes, we don't want to change the getpeercon() interface, and we want
> consistent semantics between AF_LOCAL and AF_INET.
> 

We also want consistent policy with different combinations of network
labeling mechanisms - which is going to be very difficult to achieve.

> > That said, I'm thinking that this scheme should be scrapped and instead
> > we do something like the following: secmark is totally non-relavent to
> > the peer context, it labels packets and I don't believe there is ever a
> > need to know the label of a packet (if there is we can add
> > getpacketcon()). Secmark will be used for enforcement of network flow
> > only.
> 
> That may be the right approach given the divergent purposes of secmark
> vs. labeled networking, but it doesn't resolve what motivated the secid
> reconciliation work in the first place.
> 

Which was? It appears to me that we need to resolve the Netlabel and
ipsec labels and store the result separately from the secid (or whatever
the secmark label is). Is that what you are thinking?

Karl

> >  The security association can have a context, that context will be
> > used for enforcement of polmatch, just like now. The label won't be used
> > for getpeercon(), only to create associations and give access to them.
> > Then the actual domain making the connection can be sent to the remote
> > side by racoon, this should be the label that getpeercon() returns.
> 
> If you just mean that the SA context would come from the flow's context
> rather than the SPD rule, then I think we all agreed to that.  But the
> context is still ultimately stored in the SA and obtained from it by
> getpeercon().  That doesn't change.
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

On Fri, 2006-09-22 at 09:26 -0400, Karl MacMillan wrote:
> On Fri, 2006-09-22 at 08:47 -0400, Stephen Smalley wrote:
> > On Thu, 2006-09-21 at 22:04 -0400, Joshua Brindle wrote:
> > > > -----Original Message-----
> > > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com]
> > > <snip>
> > > > > I agree that it doesn't matter whether the packet was
> > > > labeled on the
> > > > > current or sending machine - but it still says nothing about
> the
> > > > > context of the originating process.
> > > >
> > > > It does when you use labeled-ipsec and when you convey BOTH
> > > > the packet Type and the process Type to the app in a single
> > > > sid. And we could change the name of getpeercon() to be more
> > > > meaningful/accurate to, say getdatacon(), if need be.
> > > >
> > >
> > > I agree with Karl here. To say the least taking one kind of object
> > > (association) and and another kind of object (packet) and using
> those
> > > contexts to calculate a context for another kind of object
> (domain? Or
> > > maybe something else?) seems fairly hacky to say the least.
> >
> > Yes, that would be like computing a process label from an old
> process
> > label and an executable file label.  Or like computing a new file
> label
> > from a process label and a parent directory label.  Who could
> imagine
> > such a thing?  ;)
> >
> > Seriously, there isn't anything wrong with the notion of using label
> > transitions to capture state from multiple labels, and we do that
> all
> > the time for _object_ labels.
> 
> The difference is that we usually do this on a state transition (e.g.,
> creating a new process or object) to capture relevant portions of the
> previous state moving forward. Here the suggestion is to use
> transitions
> to simply encode multiple states via transition for transmission with
> the express purpose of reversing that transition on the other end. A
> very different use I think.
> 
Yes, I think this is what I was getting at in other email, I didn't
articulate it well though. We aren't creating an object here we are just
implementing some complex encoding scheme that (as karl already said) is
either lossy or very hard to manage (you'd need sa and secmark pairs for
every single domain that you expect to talk to and get a context for)..
I just can't see this ever being used outside of a very limited use
case.

The argument that the incoming interface should be part of setting the
context because data coming in on a secret interface should be secret is
a strawman I think. If there is a domain talking to you on a secret
interface and the domain on the other side isn't secret you have much
bigger problems. You really want to know *who* you are talking to when
you do getpeercon(), not how they are talking to you.


> >   Where we run into a problem here is the
> > fact that the user of getpeercon() wants a subject label, not an
> object
> > label.  If the label transition function had an inverse, that might
> be
> > workable, although I'd hate to require applications to deal with it,
> but
> > it doesn't have an inverse (in general; specific policy may permit
> such
> > inversion, but the function itself provides no such guarantee).
> >
> > > And it also isn't what I (personally) want. I want the domain on
> the
> > > other end, I don't want to have to have some incredibly complex
> setup of
> > > associations and secmarks just to get recalculate the context we
> already
> > > had on the other end, I just want it. That is what getpeercon()
> should
> > > return. I don't care either way about getdatacon() but getpeercon
> should
> > > stick around and should get the peer domain.
> >
> > Yes, we don't want to change the getpeercon() interface, and we want
> > consistent semantics between AF_LOCAL and AF_INET.
> >
> 
> We also want consistent policy with different combinations of network
> labeling mechanisms - which is going to be very difficult to achieve.
> 
> > > That said, I'm thinking that this scheme should be scrapped and
> instead
> > > we do something like the following: secmark is totally
> non-relavent to
> > > the peer context, it labels packets and I don't believe there is
> ever a
> > > need to know the label of a packet (if there is we can add
> > > getpacketcon()). Secmark will be used for enforcement of network
> flow
> > > only.
> >
> > That may be the right approach given the divergent purposes of
> secmark
> > vs. labeled networking, but it doesn't resolve what motivated the
> secid
> > reconciliation work in the first place.
> >
> 
> Which was? It appears to me that we need to resolve the Netlabel and
> ipsec labels and store the result separately from the secid (or
> whatever
> the secmark label is). Is that what you are thinking?
> 

I don't know about this either. I was under the impression that
reconciliation was for multiple *data* labels (e.g., using ipsec and
cipso at the same time). I don't know how secmark ever got pulled into
this mess, secmark is for labeling packet objects, we never ask (or
probably care) what the label on an individual packet is.

> Karl
> 
> > >  The security association can have a context, that context will be
> > > used for enforcement of polmatch, just like now. The label won't
> be used
> > > for getpeercon(), only to create associations and give access to
> them.
> > > Then the actual domain making the connection can be sent to the
> remote
> > > side by racoon, this should be the label that getpeercon()
> returns.
> >
> > If you just mean that the SA context would come from the flow's
> context
> > rather than the SPD rule, then I think we all agreed to that.  But
> the
> > context is still ultimately stored in the SA and obtained from it by
> > getpeercon().  That doesn't change.
> >
> 
> 
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Joshua Brindle wrote:
> On Fri, 2006-09-22 at 08:47 -0400, Stephen Smalley wrote:
> 
>>On Thu, 2006-09-21 at 22:04 -0400, Joshua Brindle wrote:
>>
>>>>-----Original Message-----
>>>>From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com]
>>>
>>><snip>
>>>
>>>>>I agree that it doesn't matter whether the packet was
>>>>
>>>>labeled on the
>>>>
>>>>>current or sending machine - but it still says nothing about the
>>>>>context of the originating process.
>>>>
>>>>It does when you use labeled-ipsec and when you convey BOTH
>>>>the packet Type and the process Type to the app in a single
>>>>sid. And we could change the name of getpeercon() to be more
>>>>meaningful/accurate to, say getdatacon(), if need be.
>>>>
>>>
>>>I agree with Karl here. To say the least taking one kind of object
>>>(association) and and another kind of object (packet) and using
>>
>>those
>>
>>>contexts to calculate a context for another kind of object (domain?
>>
>>Or
>>
>>>maybe something else?) seems fairly hacky to say the least.
>>
>>Yes, that would be like computing a process label from an old process
>>label and an executable file label.  Or like computing a new file
>>label
>>from a process label and a parent directory label.  Who could imagine
>>such a thing?  ;)
>>
> 
> bah, fair enough :\. I guess the reason I was objecting was because the
> objects seem *very* different. standard object and subject transitions
> seem pretty intuitive (I'm in a domain, i execute something, I'm in a
> new domain or directories containing files guiding transitions. packets
> and associations are totally separate and used for totally different
> things. And the other problem was that I don't even know if we were
> *trying* to derive a subject label or not, some of the examples I've
> seen floating around indicate that others don't either.
> 
> 
>>Seriously, there isn't anything wrong with the notion of using label
>>transitions to capture state from multiple labels, and we do that all
>>the time for _object_ labels.  Where we run into a problem here is the
>>fact that the user of getpeercon() wants a subject label, not an
>>object
> 
> 
> This was my main point
> 
> 
>>label.  If the label transition function had an inverse, that might be
>>workable, although I'd hate to require applications to deal with it,
>>but
>>it doesn't have an inverse (in general; specific policy may permit
>>such
>>inversion, but the function itself provides no such guarantee).
>>
>>
>>>And it also isn't what I (personally) want. I want the domain on the
>>>other end, I don't want to have to have some incredibly complex
>>
>>setup of
>>
>>>associations and secmarks just to get recalculate the context we
>>
>>already
>>
>>>had on the other end, I just want it. That is what getpeercon()
>>
>>should
>>
>>>return. I don't care either way about getdatacon() but getpeercon
>>
>>should
>>
>>>stick around and should get the peer domain.
>>
>>Yes, we don't want to change the getpeercon() interface, and we want
>>consistent semantics between AF_LOCAL and AF_INET.
>>
>>
>>>That said, I'm thinking that this scheme should be scrapped and
>>
>>instead
>>
>>>we do something like the following: secmark is totally non-relavent
>>
>>to
>>
>>>the peer context, it labels packets and I don't believe there is
>>
>>ever a
>>
>>>need to know the label of a packet (if there is we can add
>>>getpacketcon()). Secmark will be used for enforcement of network
>>
>>flow
>>
>>>only.
>>
>>That may be the right approach given the divergent purposes of secmark
>>vs. labeled networking, but it doesn't resolve what motivated the
>>secid
>>reconciliation work in the first place.
>>
>>
>>> The security association can have a context, that context will be
>>>used for enforcement of polmatch, just like now. The label won't be
>>
>>used
>>
>>>for getpeercon(), only to create associations and give access to
>>
>>them.
>>
>>>Then the actual domain making the connection can be sent to the
>>
>>remote
>>
>>>side by racoon, this should be the label that getpeercon() returns.
>>
>>If you just mean that the SA context would come from the flow's
>>context
>>rather than the SPD rule, then I think we all agreed to that.  But the
>>context is still ultimately stored in the SA and obtained from it by
>>getpeercon().  That doesn't change.
>>
> 
> This scheme has a new label that is negotiated by racoon and is used as
> the subject label returned by getpeercon(), it is different from what we
> are already doing. The rest would basically be the same, there would be
> no reconciliation. The only thing I'm not sure of here is the
> interaction of the label negotiated by racoon and a cipso label. It
> almost seems like we need to disallow using them at the same time, I
> suspect people might not like this limitation though.
> 

Since all of the remote network labeling mechanisms, SA and NetLabel
labeling, are relatively new to Linux I think it's going to be hard to
say for certain how users will end up using them.  While similar in that
both mechanisms allow remote packet labeling, they acomplish very
different goals so I think it is reasonable to expect users who need
remote network labeling to run both SA and NetLabel labels on the same
system.

Ignoring the secmark issue for a moment ...

Resolving a SA label and a NetLabel label right now isn't too difficult.
 Currently we do two separate checks for each labeling mechanism.  If we
wanted to consolidate the checks into one we could do as Stephen
originally suggested and check to make sure that the NetLabel label
falls within the range of the SA label and that the socket was allowed
to receive packets from the resulting combination (TE from the SA
context, MLS label from NetLabel).  This becomes a bit more complicated
once NetLabel starts labeling packets with a full context but the basics
would still apply I believe.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> And it also isn't what I (personally) want. I want the domain on the
> other end, I don't want to have to have some incredibly 
> complex setup of

Which you don't need to. The IPSec SA label will prevail by default (no
rules needed) and this is what you will get from getpeercon.

CURRENT POLICY:

1. Allow socket to receive secmark.

NEW POLICY:

1. Allow ipsec (unlabeled when no ipsec) to come thru secmark (secpoint,
secgate whatever).

2. Allow socket to recieve ipsec.

We could have failed when there's no IPSec. But for MLS, the level on the
secmark is as good as the level of the peer and so we can't let getpeercon
fail.

Yes, in the scenarios we deal with anything coming thru the Secret interface
needs to be serviced at Secret.

EXAMPLE:

On the remote end, you have a pol_cli_t socket setup to use labeled IPSec.

Rules on the pol mgr server:

1. allow pol_cli_t pol_pkt_t:packet { flow_in }

2. allow pol_mgr_t pol_cli_t:packet { recv }

getpeercon will return pol_cli_t. No transition rules needed.

> associations and secmarks just to get recalculate the context 
> we already
> had on the other end, I just want it.

> That is what getpeercon() should
> return. I don't care either way about getdatacon() but 
> getpeercon should
> stick around and should get the peer domain.

As far as a peer "domain", it's first of all NOT guranteed to be
a "domain" in the first place. It's whatever context is associated
with the remote context.

> 
> This is of interest to me for the policy management server. 
> We need the
> full context of the client in order to do access control checks on the
> policy updates. That means the context I get from getpeercon() will be
> the source of access checks. Source should always (in this context
> anyway) be a domain.
> This transition scheme gives me some 
> kind of object
> type and I'm not sure it's a domain (or if its anything), 
> just because I
> can create crazy labeling to give the same context doesn't mean it's a
> domain.

The mechanisms have to be agnostic necessarily. It's how you define your
policy with regard to a domain or not.

> 
> And this doesn't even begin to address what a mess managing all this
> labeling is going to be. We haven't even decided how to handle secmark
> rules in distros yet and now we are going to need a whole new set of
> labels (that also have to interact with local non-selinux
> configurations)
> 
> That said, I'm thinking that this scheme should be scrapped 
> and instead
> we do something like the following: secmark is totally non-relavent to
> the peer context, it labels packets and I don't believe there 
> is ever a
> need to know the label of a packet (if there is we can add
> getpacketcon()). Secmark will be used for enforcement of network flow
> only.

The problem is currently there's no flow control at the entry and
exit points for forwarded traffic and such that don't deal with sockets.

> The security association can have a context, that 
> context will be
> used for enforcement of polmatch, just like now. The label 
> won't be used
> for getpeercon(), only to create associations and give access to them.
> Then the actual domain making the connection can be sent to the remote
> side by racoon, this should be the label that getpeercon() 
> returns. Note
> that racoon can send the domain context (default) or if necessary do
> some sort of translation (eg., system_u:object_r:sysadm_t:s0 ->
> system_u:object_r:sysadm_t) or similar, it will be up to the local
> configuration to decide how that works though.
> 
> This is, IMO, a much cleaner, simpler and more pure 
> implementation that
> doesn't try mixing different kinds of objects, each object fits in its
> own place and when we call getpeercon() we know we'll be getting a
> domain that we can use in rule lookups or setexeccon(). 
> 
> If there is no ipsec then getpeercon() returns an error, as it should,
> to let the application asking know that the peer context 
> isn't available

This won't meet the MLS needs as mentioned above.

> (the reconciliation with unlabaled->secmark->somethingelse 
> could be very
> dangerous since the application can't know if it can really trust the
> label)

This trust, you implement in the policy, is it not?

> 
> Comments? I'm starting to look at Joy's racoon patch to see 
> what we can
> do there but I think this is the correct way to handle this problem.
> 
> 
> Joshua Brindle
> 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Joshua Brindle]

On Fri, 2006-09-22 at 10:47 -0400, Paul Moore wrote:
> <snip>
> > This scheme has a new label that is negotiated by racoon and is used
> as
> > the subject label returned by getpeercon(), it is different from
> what we
> > are already doing. The rest would basically be the same, there would
> be
> > no reconciliation. The only thing I'm not sure of here is the
> > interaction of the label negotiated by racoon and a cipso label. It
> > almost seems like we need to disallow using them at the same time, I
> > suspect people might not like this limitation though.
> >
> 
> Since all of the remote network labeling mechanisms, SA and NetLabel
> labeling, are relatively new to Linux I think it's going to be hard to
> say for certain how users will end up using them.  While similar in
> that
> both mechanisms allow remote packet labeling, they acomplish very
> different goals so I think it is reasonable to expect users who need
> remote network labeling to run both SA and NetLabel labels on the same
> system.
> 
so we need to define the limitations now before people start using them
in unexpected ways.

> Ignoring the secmark issue for a moment ...
> 
there is no secmark issue, secmark isn't for labeling.

> Resolving a SA label and a NetLabel label right now isn't too
> difficult.
>  Currently we do two separate checks for each labeling mechanism.  If
> we
> wanted to consolidate the checks into one we could do as Stephen
> originally suggested and check to make sure that the NetLabel label
> falls within the range of the SA label and that the socket was allowed
> to receive packets from the resulting combination (TE from the SA
> context, MLS label from NetLabel).  This becomes a bit more
> complicated
> once NetLabel starts labeling packets with a full context but the
> basics
> would still apply I believe.
> 
Right, that is all well and good as long as netlabel is MLS only. I
don't think we should be making assumptions like checking that the
netlabel is within the range of the SA label if there is ever an
expectation of doing full contexts in netlabel.

Further, I don't think we've fully understood each other yet. I don't
want the SA label used for anything except permission checks. The SA
label is the 'local socket' label for an association and isn't
interesting at all. The label returned with getpeercon() should be a
domain label that is negotiated by racoon.

I think we've mostly agreed that getpeercon() should be returning
domains, now the question is how. Assuming the racoon thing works we can
get one from ipsec, and netlabel obviously has a labeling scheme. If
both are in use we have an ambiguous label which I think is an error, I
don't think trying to reconcile both labels using a type_transition is
the right way to go (domain_a->domain_b == new_domain?), I'm not even
sure what the ramifications are there. 

Do you have a scenario where one might want both labeling schemes at the
same time? Note that if you need netlabel (legacy os on the other side)
and you also want ipsec for integrity then the isakmp negotiation would
not include a context and netlabel would be used.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Fri, 22 Sep 2006, Joshua Brindle wrote:

> I don't know about this either. I was under the impression that
> reconciliation was for multiple *data* labels (e.g., using ipsec and
> cipso at the same time). I don't know how secmark ever got pulled into
> this mess, secmark is for labeling packet objects, we never ask (or
> probably care) what the label on an individual packet is.

I thought the idea was to allow internal labels to transition to a new 
label based on the external label (simplified version), and to allow both 
ipsec and cipso labeling as external labeling schems to work well with 
this, but not at the same time.



-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> Yes, that would be like computing a process label from an old process
> label and an executable file label.  Or like computing a new 
> file label
> from a process label and a parent directory label.  Who could imagine
> such a thing?  ;)
> 
> Seriously, there isn't anything wrong with the notion of using label
> transitions to capture state from multiple labels, and we do that all
> the time for _object_ labels.  Where we run into a problem here is the
> fact that the user of getpeercon() wants a subject label, not 
> an object
> label.  If the label transition function had an inverse, that might be
> workable,

The "inverse" is the default. The IPSec label is what's returned
by default (in the absence of any transition rules). A transition
can always turn out a "domain" in the non-ipsec case if a domain is
what's needed.

> although I'd hate to require applications to deal 
> with it, but
> it doesn't have an inverse (in general; specific policy may 
> permit such
> inversion, but the function itself provides no such guarantee).
> 
> > And it also isn't what I (personally) want. I want the domain on the
> > other end, I don't want to have to have some incredibly 
> complex setup of
> > associations and secmarks just to get recalculate the 
> context we already
> > had on the other end, I just want it. That is what 
> getpeercon() should
> > return. I don't care either way about getdatacon() but 
> getpeercon should
> > stick around and should get the peer domain.
> 
> Yes, we don't want to change the getpeercon() interface, and we want
> consistent semantics between AF_LOCAL and AF_INET.

Again, a transition can always turn out an appropriate domain, because
we can't have getpeercon() fail in the MLS case.

> 
> > That said, I'm thinking that this scheme should be scrapped 
> and instead
> > we do something like the following: secmark is totally 
> non-relavent to
> > the peer context, it labels packets and I don't believe 
> there is ever a
> > need to know the label of a packet (if there is we can add
> > getpacketcon()). Secmark will be used for enforcement of 
> network flow
> > only.
> 
> That may be the right approach given the divergent purposes of secmark
> vs. labeled networking, but it doesn't resolve what motivated 
> the secid
> reconciliation work in the first place.

The following being the main objectives:

1. Socket-independent flow control at the entry and exit points.
2. Ability to service requests at the lavel of an interface, node, etc.


> 
> >  The security association can have a context, that context will be
> > used for enforcement of polmatch, just like now. The label 
> won't be used
> > for getpeercon(), only to create associations and give 
> access to them.
> > Then the actual domain making the connection can be sent to 
> the remote
> > side by racoon, this should be the label that getpeercon() returns.
> 
> If you just mean that the SA context would come from the 
> flow's context
> rather than the SPD rule, then I think we all agreed to that.  But the
> context is still ultimately stored in the SA and obtained from it by
> getpeercon().  That doesn't change.

That's correct. Whatever is the socket context on the remote end that
will (could) become the SA context.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> bah, fair enough :\. I guess the reason I was objecting was 
> because the
> objects seem *very* different. standard object and subject transitions
> seem pretty intuitive (I'm in a domain, i execute something, I'm in a
> new domain or directories containing files guiding 
> transitions. packets
> and associations are totally separate and used for totally different
> things. And the other problem was that I don't even know if we were
> *trying* to derive a subject label or not, some of the examples I've
> seen floating around indicate that others don't either.

You can always have getpeercon return a "domain" by turning out a
domain (a unlabeled_t one?) in the non labeled-ipsec case.

> 
> > Seriously, there isn't anything wrong with the notion of using label
> > transitions to capture state from multiple labels, and we 
> do that all
> > the time for _object_ labels.  Where we run into a problem 
> here is the
> > fact that the user of getpeercon() wants a subject label, not an
> > object
> 
> This was my main point

See above.

> This scheme has a new label that is negotiated by racoon and 
> is used as
> the subject label returned by getpeercon(), it is different 
> from what we
> are already doing. The rest would basically be the same, 
> there would be
> no reconciliation.

This won't work for MLS.

> The only thing I'm not sure of here is the
> interaction of the label negotiated by racoon and a cipso label. It
> almost seems like we need to disallow using them at the same time, I
> suspect people might not like this limitation though.

I think Paul has addressed this in his follow-on to this.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> The argument that the incoming interface should be part of setting the
> context because data coming in on a secret interface should 
> be secret is
> a strawman I think. If there is a domain talking to you on a secret
> interface and the domain on the other side isn't secret you have much
> bigger problems. You really want to know *who* you are talking to when
> you do getpeercon(), not how they are talking to you.

For MLS, we care about the later (i.e. "how they are talking to you").
Once data is labeled Secret, it doesn't matter to us *who* lebeled it
Secret.

> 
> 
> > >   Where we run into a problem here is the
> > > fact that the user of getpeercon() wants a subject label, not an
> > object
> > > label.  If the label transition function had an inverse, 
> that might
> > be
> > > workable, although I'd hate to require applications to 
> deal with it,
> > but
> > > it doesn't have an inverse (in general; specific policy may permit
> > such
> > > inversion, but the function itself provides no such guarantee).
> > >
> > > > And it also isn't what I (personally) want. I want the domain on
> > the
> > > > other end, I don't want to have to have some incredibly complex
> > setup of
> > > > associations and secmarks just to get recalculate the context we
> > already
> > > > had on the other end, I just want it. That is what getpeercon()
> > should
> > > > return. I don't care either way about getdatacon() but 
> getpeercon
> > should
> > > > stick around and should get the peer domain.
> > >
> > > Yes, we don't want to change the getpeercon() interface, 
> and we want
> > > consistent semantics between AF_LOCAL and AF_INET.
> > >
> > 
> > We also want consistent policy with different combinations 
> of network
> > labeling mechanisms - which is going to be very difficult 
> to achieve.
> > 
> > > > That said, I'm thinking that this scheme should be scrapped and
> > instead
> > > > we do something like the following: secmark is totally
> > non-relavent to
> > > > the peer context, it labels packets and I don't believe there is
> > ever a
> > > > need to know the label of a packet (if there is we can add
> > > > getpacketcon()). Secmark will be used for enforcement of network
> > flow
> > > > only.
> > >
> > > That may be the right approach given the divergent purposes of
> > secmark
> > > vs. labeled networking, but it doesn't resolve what motivated the
> > secid
> > > reconciliation work in the first place.
> > >
> > 
> > Which was? It appears to me that we need to resolve the Netlabel and
> > ipsec labels and store the result separately from the secid (or
> > whatever
> > the secmark label is). Is that what you are thinking?
> > 
> 
> I don't know about this either. I was under the impression that
> reconciliation was for multiple *data* labels (e.g., using ipsec and
> cipso at the same time). I don't know how secmark ever got pulled into
> this mess, secmark is for labeling packet objects, we never ask (or
> probably care) what the label on an individual packet is.

For the sake of asking, why wouldn't you care that you have receieved
a packet of Type sysadm_pkt_t vs. secadm_pkt_t?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Joshua Brindle wrote:
> On Fri, 2006-09-22 at 10:47 -0400, Paul Moore wrote:
> 
>><snip>
>>
>>>This scheme has a new label that is negotiated by racoon and is used
>>
>>as
>>
>>>the subject label returned by getpeercon(), it is different from
>>
>>what we
>>
>>>are already doing. The rest would basically be the same, there would
>>
>>be
>>
>>>no reconciliation. The only thing I'm not sure of here is the
>>>interaction of the label negotiated by racoon and a cipso label. It
>>>almost seems like we need to disallow using them at the same time, I
>>>suspect people might not like this limitation though.
>>>
>>
>>Since all of the remote network labeling mechanisms, SA and NetLabel
>>labeling, are relatively new to Linux I think it's going to be hard to
>>say for certain how users will end up using them.  While similar in
>>that
>>both mechanisms allow remote packet labeling, they acomplish very
>>different goals so I think it is reasonable to expect users who need
>>remote network labeling to run both SA and NetLabel labels on the same
>>system.
> 
> so we need to define the limitations now before people start using them
> in unexpected ways.

No argument here.

>>Ignoring the secmark issue for a moment ...
> 
> there is no secmark issue, secmark isn't for labeling.

That's why I said to ignore it ;)

>>Resolving a SA label and a NetLabel label right now isn't too
>>difficult.
>> Currently we do two separate checks for each labeling mechanism.  If
>>we
>>wanted to consolidate the checks into one we could do as Stephen
>>originally suggested and check to make sure that the NetLabel label
>>falls within the range of the SA label and that the socket was allowed
>>to receive packets from the resulting combination (TE from the SA
>>context, MLS label from NetLabel).  This becomes a bit more
>>complicated
>>once NetLabel starts labeling packets with a full context but the
>>basics
>>would still apply I believe.
> 
> Right, that is all well and good as long as netlabel is MLS only. I
> don't think we should be making assumptions like checking that the
> netlabel is within the range of the SA label if there is ever an
> expectation of doing full contexts in netlabel.

That is reasonable.  I don't want to distract from the discussion going
on right now with a discussion about the pros/cons of NetLabel sending
full contexts, but I think it would be a good idea to stop thinking of
NetLabel just a CIPSO/MLS and instead think of it as a full context like
the IPsec/SA labeling mechanism.  With this in mind, perhaps we just
stick to having two separate access checks, one for SA labeling and one
for NetLabel labeling.  In a way it punts on the problem and pushes into
policy, but that may be the best option as policy is far more flexibile
than code.  After all, isn't this one of the main selling points of
TE/FLASK/SELinux?

> Further, I don't think we've fully understood each other yet. I don't
> want the SA label used for anything except permission checks. The SA
> label is the 'local socket' label for an association and isn't
> interesting at all. The label returned with getpeercon() should be a
> domain label that is negotiated by racoon.

I don't want to speak for the SA labeling, that's Venkat's baby.
However, I can speak for NetLabel and I think so far NetLabel does what
you want, if not perhaps we can agree on a change.

Currently NetLabel labels packets using the context of the socket
sending the packets, there is no transition.  In normal usage the
socket's context is derived from the domain, however, "SELinux aware"
applications using recent kernels have the ability to specify the
context of the socket and as a result the NetLabel context.

On the receive side, when using NetLabel the context returned by
getpeercon() is currently a combination of the receiving socket's
context and the NetLabel's MLS label.  For example:

 * receiving process's context: user_u:role_r:app_t
 * receiving socket's context:  user_u:role_r:app_t
 * NetLabel context:            ??????:??????:?????:s7:c8.c12
 * getpeercon() returns:        user_u:role_r:app_t:s7:c8.c12

This is done so that the returned context is suitable for a call to
setexeccon().  In the future once NetLabel supports full contexts then
getpeercon() will return the NetLabel context.

I believe this is what you are looking for, at least for the
"non-SELinux aware" set of applications.  Yes?

> I think we've mostly agreed that getpeercon() should be returning
> domains, now the question is how. Assuming the racoon thing works we can
> get one from ipsec, and netlabel obviously has a labeling scheme. If
> both are in use we have an ambiguous label which I think is an error, I
> don't think trying to reconcile both labels using a type_transition is
> the right way to go (domain_a->domain_b == new_domain?), I'm not even
> sure what the ramifications are there. 

Good point.  We could always have getpeercon() error out if both SA and
NetLabel labels are present.  It may not be ideal, but it's safe.

> Do you have a scenario where one might want both labeling schemes at the
> same time? Note that if you need netlabel (legacy os on the other side)
> and you also want ipsec for integrity then the isakmp negotiation would
> not include a context and netlabel would be used.

Honestly, I can't think of why you would want to use both SA and
NetLabel labeling on the same connection - that's just stupid :)
However, I can see users wanting to have then active on the same host,
imagine a SELinux box talking to both legacy Trusted OSs and other
SELinux boxes - this is the case I was talking about earlier.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Venkat Yekkirala wrote:
>>bah, fair enough :\. I guess the reason I was objecting was 
>>because the
>>objects seem *very* different. standard object and subject transitions
>>seem pretty intuitive (I'm in a domain, i execute something, I'm in a
>>new domain or directories containing files guiding 
>>transitions. packets
>>and associations are totally separate and used for totally different
>>things. And the other problem was that I don't even know if we were
>>*trying* to derive a subject label or not, some of the examples I've
>>seen floating around indicate that others don't either.
>  
> You can always have getpeercon return a "domain" by turning out a
> domain (a unlabeled_t one?) in the non labeled-ipsec case.

The only thing I don't like about this is that it starts giving
types/domains implicit meaning that is not defined by policy.  I know we
sort of do that already with some of the MLS attributes but I think it's
worth trying to avoid.

Plus, what if the remote domain was honestly running in "unlabeled_t"?
Stupid, yes, but possibile I imagine.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> > Ignoring the secmark issue for a moment ...
> > 
> there is no secmark issue, secmark isn't for labeling.

It IS FOR LABELING as far as MLS is concerned.

> 
> > Resolving a SA label and a NetLabel label right now isn't too
> > difficult.
> >  Currently we do two separate checks for each labeling 
> mechanism.  If
> > we
> > wanted to consolidate the checks into one we could do as Stephen
> > originally suggested and check to make sure that the NetLabel label
> > falls within the range of the SA label and that the socket 
> was allowed
> > to receive packets from the resulting combination (TE from the SA
> > context, MLS label from NetLabel).  This becomes a bit more
> > complicated
> > once NetLabel starts labeling packets with a full context but the
> > basics
> > would still apply I believe.
> > 
> Right, that is all well and good as long as netlabel is MLS only. I
> don't think we should be making assumptions like checking that the
> netlabel is within the range of the SA label

Why not? Wouldn't you want to make sure the Secret cipso packet arrived thru
a "Classified to Secret" SA?

> if there is ever an
> expectation of doing full contexts in netlabel.
> 
> Further, I don't think we've fully understood each other yet. I don't
> want the SA label used for anything except permission checks. The SA
> label is the 'local socket' label for an association and isn't
> interesting at all.

It will be interesting if configuration makes sure the SA label is the
"domain" label when negotiated by racoon.

> The label returned with getpeercon() should be a
> domain label that is negotiated by racoon.


> 
> I think we've mostly agreed that getpeercon() should be returning
> domains, now the question is how. Assuming the racoon thing 
> works we can
> get one from ipsec, and netlabel obviously has a labeling scheme. If
> both are in use we have an ambiguous label which I think is 
> an error, I
> don't think trying to reconcile both labels using a type_transition is

No type transitions needed. Just a check to make sure a Secret packet can
come thru a ranged IPSec SA, and if it can then cipso overrides the SA label
(MLS-wise) assumed by the packet.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

On Fri, 2006-09-22 at 11:21 -0400, Venkat Yekkirala wrote:

> > I don't know about this either. I was under the impression that
> > reconciliation was for multiple *data* labels (e.g., using ipsec and
> > cipso at the same time). I don't know how secmark ever got pulled
> into
> > this mess, secmark is for labeling packet objects, we never ask (or
> > probably care) what the label on an individual packet is.
> 
> For the sake of asking, why wouldn't you care that you have receieved
> a packet of Type sysadm_pkt_t vs. secadm_pkt_t?
> 
> 

For starters I want the domain which would be sysadm_t or secadm_t,
which I can actually use in avc queries without having to do yet another
transformation. Second differentiating them like that requires netfilter
to know the difference, which can't happen, its coming from machine X on
port Y and it'll always be policy_server_packet_t. 

Throwing ipsec associations into the mix just makes a management
nightmare by requiring people to have SA and secmark pairs for every
single possible domain that could talk to every single other machine is
simply absurd. We are trying to make network management of selinux
simpler


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> Good point.  We could always have getpeercon() error out if 
> both SA and
> NetLabel labels are present.  It may not be ideal, but it's safe.

No need to error out since no transitions are needed. The current
expected uses for cipso are a. all by itself, b. in conjunction
with ipsec. In the latter case, we do an additional check to make
sure the cipso label can come thru the ipsec tunnel/transport.

> 
> > Do you have a scenario where one might want both labeling 
> schemes at the
> > same time? Note that if you need netlabel (legacy os on the 
> other side)
> > and you also want ipsec for integrity then the isakmp 
> negotiation would
> > not include a context and netlabel would be used.
> 
> Honestly, I can't think of why you would want to use both SA and
> NetLabel labeling on the same connection - that's just stupid :)

I can think of ALL Secret and its compartments using one SA
for example (a very realistic one).

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> > You can always have getpeercon return a "domain" by turning out a
> > domain (a unlabeled_t one?) in the non labeled-ipsec case.
> 
> The only thing I don't like about this is that it starts giving
> types/domains implicit meaning that is not defined by policy.

I don't know what you are talking about here. I was saying you
could turn out a "true domain" using transitions.
 
>  I know we
> sort of do that already with some of the MLS attributes

Examples?

> but I 
> think it's
> worth trying to avoid.

Not an issue as long as you get your policy right.

> 
> Plus, what if the remote domain was honestly running in "unlabeled_t"?
> Stupid, yes, but possibile I imagine.

unlabeled_t anywhere is unlabeled. It doesn't matter how it came to be
unlabeled_t.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Venkat Yekkirala wrote:
>>>Ignoring the secmark issue for a moment ...
>>
>>there is no secmark issue, secmark isn't for labeling.
>  
> It IS FOR LABELING as far as MLS is concerned.

Perhaps we are just overloading the term "labeling".  It kinda sounds
like the non-MLS folks want to be able to distinguish between "remote
labeling", i.e. SA or NetLabel, and "local labeling", i.e. secmark.  I
realize that there are certain users who don't care to make that
distinction because they can put a certain level of trust in the
physical network configuration.  However, considering the flexibility of
SELinux in general I think any built-in assumption is going to upset
someone.  I think the best idea is to arrive at some sort of policy
abstraction which would allow either of the behaviors listed above.

For handling incoming packets this may mean that we keep all of the
packet labeling mechanisms separate, allowing each to have it's own
permission check.

For dealing with getpeercon() issues perhaps we only allow "remote
labeled" contexts to be reported by default, but if policy allows (yes,
we would need some sort of new allow rule or policy construct) the
"locally labeled" context could be used as a fallback.

I know it's not ideal for any one scenario, but I think it may be
flexibile enough to deal with all of them.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Venkat Yekkirala wrote:
>>Good point.  We could always have getpeercon() error out if 
>>both SA and
>>NetLabel labels are present.  It may not be ideal, but it's safe.
>  
> No need to error out since no transitions are needed. The current
> expected uses for cipso are a. all by itself, b. in conjunction
> with ipsec. In the latter case, we do an additional check to make
> sure the cipso label can come thru the ipsec tunnel/transport.

The comments below apply here as well.

>>>Do you have a scenario where one might want both labeling 
>>
>>schemes at the
>>
>>>same time? Note that if you need netlabel (legacy os on the 
>>
>>other side)
>>
>>>and you also want ipsec for integrity then the isakmp 
>>
>>negotiation would
>>
>>>not include a context and netlabel would be used.
>>
>>Honestly, I can't think of why you would want to use both SA and
>>NetLabel labeling on the same connection - that's just stupid :)
> 
> I can think of ALL Secret and its compartments using one SA
> for example (a very realistic one).

If you have NetLabel carrying the MLS label why would you want to make
your life complicated by using SA labeling as well?  I just don't
understand why the duplication is necessary.  Since this example is only
dealing with MLS, why not just use NetLabel and if you can't trust the
physical link layer, i.e. you need IPsec protection, just run unlabeled
IPsec.  This will allow you to talk to both SELinux and legacy Trusted
OSs without problem, and it allows you the flexibility of offloading the
IPsec processing to some sort of bump-in-the-wire solution which could
yield significant performance advantages.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> > It IS FOR LABELING as far as MLS is concerned.
> 
> Perhaps we are just overloading the term "labeling".  It kinda sounds
> like the non-MLS folks want to be able to distinguish between "remote
> labeling", i.e. SA or NetLabel, and "local labeling", i.e. secmark.  I
> realize that there are certain users who don't care to make that
> distinction because they can put a certain level of trust in the
> physical network configuration.  However, considering the 
> flexibility of
> SELinux in general I think any built-in assumption is going to upset
> someone.  I think the best idea is to arrive at some sort of policy
> abstraction which would allow either of the behaviors listed above.

This we have attempted to do via transitions.

> 
> For handling incoming packets this may mean that we keep all of the
> packet labeling mechanisms separate, allowing each to have it's own
> permission check.

But how would you then make sure a secret cipso didn't arrive thru a
TopSecret SA?

> 
> For dealing with getpeercon() issues perhaps we only allow "remote
> labeled" contexts to be reported by default, but if policy 
> allows (yes,
> we would need some sort of new allow rule or policy construct) the
> "locally labeled" context could be used as a fallback.
> 
> I know it's not ideal for any one scenario, but I think it may be
> flexibile enough to deal with all of them.

That would mean you would have separate policies.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> Venkat Yekkirala wrote:
> >>Good point.  We could always have getpeercon() error out if 
> >>both SA and
> >>NetLabel labels are present.  It may not be ideal, but it's safe.
> >  
> > No need to error out since no transitions are needed. The current
> > expected uses for cipso are a. all by itself, b. in conjunction
> > with ipsec. In the latter case, we do an additional check to make
> > sure the cipso label can come thru the ipsec tunnel/transport.
> 
> The comments below apply here as well.
> 
> >>>Do you have a scenario where one might want both labeling 
> >>
> >>schemes at the
> >>
> >>>same time? Note that if you need netlabel (legacy os on the 
> >>
> >>other side)
> >>
> >>>and you also want ipsec for integrity then the isakmp 
> >>
> >>negotiation would
> >>
> >>>not include a context and netlabel would be used.
> >>
> >>Honestly, I can't think of why you would want to use both SA and
> >>NetLabel labeling on the same connection - that's just stupid :)
> > 
> > I can think of ALL Secret and its compartments using one SA
> > for example (a very realistic one).
> 
> If you have NetLabel carrying the MLS label why would you want to make
> your life complicated by using SA labeling as well?

It's not a matter of complicated or not. Unless you make sure both
are NOT used at the same time, you *must* make you they work like
they are supposed to (cipso falling in the rage of the SA) if/when
they are used together.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Venkat Yekkirala wrote:
>>>You can always have getpeercon return a "domain" by turning out a
>>>domain (a unlabeled_t one?) in the non labeled-ipsec case.
>>
>>The only thing I don't like about this is that it starts giving
>>types/domains implicit meaning that is not defined by policy.
> 
> I don't know what you are talking about here. I was saying you
> could turn out a "true domain" using transitions.

Well, as I understand it right now types/domains have no inherent
meaning; they are given defined through their use in the policy.  Having
the kernel return "unlabeled_t" to signify a special case starts giving
"unlabeled_t" inherent meaning.  Maybe it's not a big deal as I guess
"unlabeled_t" will always have a certain conotation about it but I still
think sending an error is much cleaner.

Applications that depend on getpeercon() could check for the error and
substitute "unlabeled_t".

>> I know we
>>sort of do that already with some of the MLS attributes
> 
> Examples?

Look at all of the "mls*" attributes defined in mls.te and how they are
used in the MLS constraints file.

>>Plus, what if the remote domain was honestly running in "unlabeled_t"?
>>Stupid, yes, but possibile I imagine.
>  
> unlabeled_t anywhere is unlabeled. It doesn't matter how it came to be
> unlabeled_t.

No, not always, see the comments above.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> On Fri, 2006-09-22 at 11:21 -0400, Venkat Yekkirala wrote:
> 
> > > I don't know about this either. I was under the impression that
> > > reconciliation was for multiple *data* labels (e.g., 
> using ipsec and
> > > cipso at the same time). I don't know how secmark ever got pulled
> > into
> > > this mess, secmark is for labeling packet objects, we 
> never ask (or
> > > probably care) what the label on an individual packet is.
> > 
> > For the sake of asking, why wouldn't you care that you have 
> receieved
> > a packet of Type sysadm_pkt_t vs. secadm_pkt_t?
> > 
> > 
> 
> For starters I want the domain which would be sysadm_t or secadm_t,
> which I can actually use in avc queries without having to do 
> yet another
> transformation. Second differentiating them like that 
> requires netfilter
> to know the difference, which can't happen, its coming from 
> machine X on
> port Y and it'll always be policy_server_packet_t. 

You could also say its sysadm_polsvr_packet_t, transitioning to
sysadm_t, can't you?

> 
> Throwing ipsec associations into the mix just makes a management
> nightmare by requiring people to have SA and secmark pairs for every
> single possible domain

I am not getting this. Why would it be for every SA, secmark pair?
It would only be per need. And what is so sacrosant about domain
vs. Type any way? Your avc check will work either way wouldn't it?

> that could talk to every single other 
> machine is
> simply absurd. We are trying to make network management of selinux
> simpler
> 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Venkat Yekkirala wrote:
>>>It IS FOR LABELING as far as MLS is concerned.
>>
>>Perhaps we are just overloading the term "labeling".  It kinda sounds
>>like the non-MLS folks want to be able to distinguish between "remote
>>labeling", i.e. SA or NetLabel, and "local labeling", i.e. secmark.  I
>>realize that there are certain users who don't care to make that
>>distinction because they can put a certain level of trust in the
>>physical network configuration.  However, considering the 
>>flexibility of
>>SELinux in general I think any built-in assumption is going to upset
>>someone.  I think the best idea is to arrive at some sort of policy
>>abstraction which would allow either of the behaviors listed above.
> 
> This we have attempted to do via transitions.

Yep, I got that, I think everybody got that.  However, I think this
discussion has demonstrated that not everyone believes the transitions
as they are implemented in the current secid reconciliation patches is
the right approach.  Maybe it's an issue of not understanding, maybe I'm
just confused ... (maybe I need to stop responding to email and do some
some real work <g>).

Personally, I don't have any strong feelings for any particular
implementation.  My main concern is that we arrive at a solution that
works for both the generic SELinux TE users as well as the legacy MLS users.

>>For handling incoming packets this may mean that we keep all of the
>>packet labeling mechanisms separate, allowing each to have it's own
>>permission check.
> 
> But how would you then make sure a secret cipso didn't arrive thru a
> TopSecret SA?

First, I think this is what I would call a "smack the user" problem.
However, if somebody really wanted to use both SA and NetLabel labeling
on the same connection I think the important thing is that we control
the flow of data to the socket, not the SA, as the socket is the
endpoint of the communcation channel from a users point of view.  With
this in mind, having access checks against the SA/socket and the
NetLabel/socket would ensure that the user doesn't receive any data they
shouldn't - even if the remote labels don't reconcile with each other.

>>For dealing with getpeercon() issues perhaps we only allow "remote
>>labeled" contexts to be reported by default, but if policy 
>>allows (yes,
>>we would need some sort of new allow rule or policy construct) the
>>"locally labeled" context could be used as a fallback.
>>
>>I know it's not ideal for any one scenario, but I think it may be
>>flexibile enough to deal with all of them.
> 
> That would mean you would have separate policies.

What's wrong with that?  We have that already and I suspect we will for
the foreseeable future.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Venkat Yekkirala wrote:
>>Venkat Yekkirala wrote:
>>>>>Do you have a scenario where one might want both labeling 
>>>>
>>>>schemes at the
>>>>
>>>>
>>>>>same time? Note that if you need netlabel (legacy os on the 
>>>>
>>>>other side)
>>>>
>>>>
>>>>>and you also want ipsec for integrity then the isakmp 
>>>>
>>>>negotiation would
>>>>
>>>>
>>>>>not include a context and netlabel would be used.
>>>>
>>>>Honestly, I can't think of why you would want to use both SA and
>>>>NetLabel labeling on the same connection - that's just stupid :)
>>>
>>>I can think of ALL Secret and its compartments using one SA
>>>for example (a very realistic one).
>>
>>If you have NetLabel carrying the MLS label why would you want to make
>>your life complicated by using SA labeling as well?
>  
> It's not a matter of complicated or not. Unless you make sure both
> are NOT used at the same time, you *must* make you they work like
> they are supposed to (cipso falling in the rage of the SA) if/when
> they are used together.

See my comments in my other mail about treating the socket as the
communication endpoint, not the SA.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

OK, here's what we will do:

1. We will have getpeercon() fail if there's no labeled-SA.

2. We will do a getdatacon() or something similar to retrieve the
   secmark (as reconciled in the proposed reconciliation logic, of course).

Comments?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Venkat Yekkirala wrote:
> OK, here's what we will do:
> 
> 1. We will have getpeercon() fail if there's no labeled-SA.

... or NetLabel :)  What do you propose we do if there is both a SA and
NetLabel label, bearing in mind that NetLabel may be a full context?

> 2. We will do a getdatacon() or something similar to retrieve the
>    secmark (as reconciled in the proposed reconciliation logic, of course).

Since the getdatacon *could* change from one packet to the next, I
wonder if it might make more sense to handle the "data context" as an
ancillary messags similar to IP_PASSSEC.

Also, didn't Karl have an objection to the proposed reconciliation logic?

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

On Fri, 2006-09-22 at 13:23 -0400, Venkat Yekkirala wrote:
> OK, here's what we will do:
> 
> 1. We will have getpeercon() fail if there's no labeled-SA.
> 
Also, I still think the getpeercon() answer should be coming from the
remote machine. The context can be negotiated by racoon and the SA label
will continue to be the local socket context.

If there is ever a reason to get the local socket context (as opposed to
the remote domain) that could be added but at least I wouldn't care for
it.

> 2. We will do a getdatacon() or something similar to retrieve the
>    secmark (as reconciled in the proposed reconciliation logic, of
> course).
> 
I still don't know how you are handling the management of this. Consider
2 machines. One machine has clients (eg., sysadm_mozilla_t,
sysadm_mysql_client_t, sysadm_ldap_client_t .... and the same for staff
and user). The server has the corresponding services running.

For apache to be able to get the appropriate remote context
(sysadm_mozilla_t, staff_mozilla_t, user_mozilla_t) in order to do some
sort of access control. There would be a secmark rule for port 80 on the
server (apache_server_packet_t) and on the client
(apache_client_packet_t). There would also be 3 SA's on both the server
side and the client side. The SA's would be labeled sysadm_mozilla_sa_t
and so on. 

So after setting up all that labeling (which I doubt is feasible
anywhere outside of static MLS setups) you'd have to have type
transition rules for each pair. That comes up to 18 type trans rules for
3 services and 3 users and 6 SA's and 2 secmark rules. Start adding in
more machines and services and this gets ridiculous very fast.

And after all that it still doesn't seem very useful. If you used
getpeercon() from 1 racoon could negotiate the correct context (and
level) and there would be no ambiguity. 

Once again, I don't think the "ts data coming into a secret SA" makes
sense. If that happens your policy is broken, this data shouldn't be
allowed in at all let alone having magic level changes to let it happen.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Fri, 2006-09-22 at 09:02 -0400, Joshua Brindle wrote:
> On Fri, 2006-09-22 at 08:47 -0400, Stephen Smalley wrote:
> > If you just mean that the SA context would come from the flow's
> > context
> > rather than the SPD rule, then I think we all agreed to that.  But the
> > context is still ultimately stored in the SA and obtained from it by
> > getpeercon().  That doesn't change.
> > 
> This scheme has a new label that is negotiated by racoon and is used as
> the subject label returned by getpeercon(), it is different from what we
> are already doing.

AFAICT, that is no different than what has already been agreed to.
Understand that the this new label / subject label is still the label of
the SA; the only difference is how the SA label is computed.  getpeercon
_has_ to get the label from the SA when using IPSEC-based labeling.  At
most, one might introduce multiple labels stored in the SA, with one
indicating the "peer" and one indicating the "data", but that goes
beyond what we have even in the AF_LOCAL case.

>  The rest would basically be the same, there would be
> no reconciliation. The only thing I'm not sure of here is the
> interaction of the label negotiated by racoon and a cipso label. It
> almost seems like we need to disallow using them at the same time, I
> suspect people might not like this limitation though.

No, that would be an unwise and unnecessary limitation; fine-grained
labeling via CIPSO within an authorized range for an IPSEC SA would be
quite useful.  The fact that TE doesn't yet understand a notion of
"ranges" is just a limitation of the present TE implementation ;)

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Fri, 2006-09-22 at 09:26 -0400, Karl MacMillan wrote:
> On Fri, 2006-09-22 at 08:47 -0400, Stephen Smalley wrote:
> > That may be the right approach given the divergent purposes of secmark
> > vs. labeled networking, but it doesn't resolve what motivated the secid
> > reconciliation work in the first place.
> > 
> 
> Which was? It appears to me that we need to resolve the Netlabel and
> ipsec labels and store the result separately from the secid (or whatever
> the secmark label is). Is that what you are thinking?

That is one possibility, but requires a way to propagate that
information everywhere it is required.  In the absence of a generic skb
security field (ala the old LSM patches and old SELinux), we don't have
that ability other than via the secmark, and the secmark has no
lifecycle management so it can only store a scalar.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Fri, 2006-09-22 at 09:50 -0400, Joshua Brindle wrote:
> I don't know about this either. I was under the impression that
> reconciliation was for multiple *data* labels (e.g., using ipsec and
> cipso at the same time). I don't know how secmark ever got pulled into
> this mess, secmark is for labeling packet objects, we never ask (or
> probably care) what the label on an individual packet is.

secmark is the only available means at present to propagate security
state with the skb.  Thus it was viewed as a way to recapture paradise
lost when the generic skb security field was rejected.

Also, when secmark is used to label packets based on their origin (e.g.
receiving NIC or source address), it can be viewed as a data label,
similar to the no-longer-used default message context defined by
netifcon statements.  Part of the confusion here is that the sample
usage of secmark in refpolicy and netfilter_contexts is labeling packets
based on their destination (e.g. destined for httpd) rather than their
source.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[James Morris]

On Fri, 22 Sep 2006, Paul Moore wrote:

> Honestly, I can't think of why you would want to use both SA and
> NetLabel labeling on the same connection - that's just stupid :)
> However, I can see users wanting to have then active on the same host,
> imagine a SELinux box talking to both legacy Trusted OSs and other
> SELinux boxes - this is the case I was talking about earlier.

Agreed.


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Stephen Smalley]

On Fri, 2006-09-22 at 10:58 -0400, Joshua Brindle wrote:
> Right, that is all well and good as long as netlabel is MLS only. I
> don't think we should be making assumptions like checking that the
> netlabel is within the range of the SA label if there is ever an
> expectation of doing full contexts in netlabel.

As far as core SELinux is concerned, it is just a permission check
between the labels; the MLS logic remains encapsulated in a
mlsconstraint on that permission.  As far as the types are concerned,
various options are possible, from requiring strict equality (i.e. type
in the netlabel context must equal the type in the SA label) to allowing
more complex relationships, which isn't inconceivable.

> Further, I don't think we've fully understood each other yet. I don't
> want the SA label used for anything except permission checks. The SA
> label is the 'local socket' label for an association and isn't
> interesting at all. The label returned with getpeercon() should be a
> domain label that is negotiated by racoon.

I think there is a basic misunderstanding here of how IPSEC labeling
works.  The context information always comes from the SA; the only
question is how the SA context is computed in the first place by the
sender.  There is no other source of context information for received
packets.  racoon just handles the out-of-band exchange with the peer
racoon to set up the SA before the IPSEC-protected traffic can begin to
flow.  When a packet is received, the SPI in the IPSEC header can be
looked up to find the SA, and the SA then contains the context to use
for the packet (whether you interpret that context as the peer context
or data context or whatever).

> I think we've mostly agreed that getpeercon() should be returning
> domains, now the question is how. Assuming the racoon thing works we can
> get one from ipsec, and netlabel obviously has a labeling scheme. If
> both are in use we have an ambiguous label which I think is an error, I
> don't think trying to reconcile both labels using a type_transition is
> the right way to go (domain_a->domain_b == new_domain?), I'm not even
> sure what the ramifications are there. 
> 
> Do you have a scenario where one might want both labeling schemes at the
> same time? Note that if you need netlabel (legacy os on the other side)
> and you also want ipsec for integrity then the isakmp negotiation would
> not include a context and netlabel would be used.

Fine-grained per-packet labeling on a shared SA.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> -----Original Message-----
> From: Joshua Brindle [mailto:jbrindle@tresys.com]
> Sent: Friday, September 22, 2006 1:52 PM
> To: Venkat Yekkirala
> Cc: Karl MacMillan; Stephen Smalley; Paul Moore; 
> latten@austin.ibm.com;
> jmorris@redhat.com; dwalsh@redhat.com; Darrel Goeddel; Chad Hanson;
> selinux@tycho.nsa.gov
> Subject: RE: Labeled networking packets
> 
> 
> On Fri, 2006-09-22 at 13:23 -0400, Venkat Yekkirala wrote:
> > OK, here's what we will do:
> > 
> > 1. We will have getpeercon() fail if there's no labeled-SA.
> > 
> Also, I still think the getpeercon() answer should be coming from the
> remote machine.

As has been pointed out by Stephen this goes beyond what's available
in the AF_LOCAL case. I believe the name getpeercon() might be throwing
us off here, whether it was consciously named that way or not I don't
know.

> The context can be negotiated by racoon and 
> the SA label
> will continue to be the local socket context.
> 
> If there is ever a reason to get the local socket context (as 
> opposed to
> the remote domain) that could be added but at least I 
> wouldn't care for
> it.
> 
> > 2. We will do a getdatacon() or something similar to retrieve the
> >    secmark (as reconciled in the proposed reconciliation logic, of
> > course).
> > 
> I still don't know how you are handling the management of 
> this. Consider
> 2 machines. One machine has clients (eg., sysadm_mozilla_t,
> sysadm_mysql_client_t, sysadm_ldap_client_t .... and the same 
> for staff
> and user). The server has the corresponding services running.
> 
> For apache to be able to get the appropriate remote context
> (sysadm_mozilla_t, staff_mozilla_t, user_mozilla_t) in order 
> to do some
> sort of access control. There would be a secmark rule for 
> port 80 on the
> server (apache_server_packet_t) and on the client
> (apache_client_packet_t).

The SAs on the server and client can be auto-negotiated by racoon
to be at the respective socket contexts, which I presume in this
case to be the same as the proc contexts?

> There would also be 3 SA's on both 
> the server
> side and the client side. The SA's would be labeled 
> sysadm_mozilla_sa_t
> and so on. 
> 
> So after setting up all that labeling (which I doubt is feasible
> anywhere outside of static MLS setups)

Remember, you haven't done any special rules for the proposed
reconciliation so far uptill this point.

> you'd have to have type
> transition rules for each pair. That comes up to 18 type 
> trans rules for

No transition rules required since you would want getpeercon
to return the peercon which in this case would be coming from the
SA's (which in turn were derived from sockets on the remote end).

If you are NOT using labeled-ipsec, you still wouldn't need to
do any transitions since getpeercon will now fail in the absence
of labeled-SAs.

> 3 services and 3 users and 6 SA's and 2 secmark rules. Start adding in
> more machines and services and this gets ridiculous very fast.
> 
> And after all that it still doesn't seem very useful. If you used
> getpeercon() from 1 racoon could negotiate the correct context (and
> level) and there would be no ambiguity. 
> 
> Once again, I don't think the "ts data coming into a secret SA" makes
> sense.

This won't happen, but having flow control at the entry/exit point
contributes to added assurance.

> If that happens your policy is broken, this data shouldn't be
> allowed in at all let alone having magic level changes to let 
> it happen.

I am not getting it. Where are we letting these level changes happen?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[James Morris]

On Fri, 22 Sep 2006, Paul Moore wrote:

> Venkat Yekkirala wrote:
> > OK, here's what we will do:
> > 
> > 1. We will have getpeercon() fail if there's no labeled-SA.
> 
> ... or NetLabel :)  What do you propose we do if there is both a SA and
> NetLabel label, bearing in mind that NetLabel may be a full context?

I don't think we should have both of these possible for the same packet.  
It's too complicated. 

Remember: CIPSO is just a legacy technology which is useful for talking to 
existing CIPSO systems.  We should not be making the rest of the code jump 
through hoops to accomodate things it was never intended for, such as 
integrated IPsec protection.

The preferred & recommended means to implement labeled networking is via 
the new xfrm labeling.  If you want to talk to legacy CIPSO systems the 
way they already talk to each other, fine, but don't expect anything more 
than that.


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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Fri, 22 Sep 2006, Joshua Brindle wrote:

> Once again, I don't think the "ts data coming into a secret SA" makes
> sense. If that happens your policy is broken, this data shouldn't be
> allowed in at all let alone having magic level changes to let it happen.

Exactly.  Stop making things so complicated.



-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Fri, 2006-09-22 at 13:23 -0400, Venkat Yekkirala wrote:
> OK, here's what we will do:
> 
> 1. We will have getpeercon() fail if there's no labeled-SA.
> 
> 2. We will do a getdatacon() or something similar to retrieve the
>    secmark (as reconciled in the proposed reconciliation logic, of course).
> 
> Comments?

I think that just moves the problem.  The question is still whether we
can have a coherent policy using that reconciliation logic for both
users of secmark.  At present, we have refpolicy (trying to) use secmark
to mark packets based on their direction and destination (e.g.
http_client_packet_t for all traffic on an outbound connection to port
80, http_server_packet_t for all traffic on an inbound connection to
port 80) and then using packet send/recv to control flow between
applications (e.g. httpd_t can send/recv http_server_packet_t, and
xxx_mozilla_t can send/recv http_client_packet_t).  If labeled
networking is enabled for a given communication and secid reconciliation
happens, the packet labels are now reconciled to the sender's label, so
httpd_t now sends httpd_t packets and receives xxx_mozilla_t packets,
and vice versa.  So we now have multiple rules on packet class to
achieve the same goal via different mechanisms, and getdatacon() can
potentially return any of these types.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

James Morris wrote:
> On Fri, 22 Sep 2006, Paul Moore wrote:
>>Venkat Yekkirala wrote:
>>
>>>OK, here's what we will do:
>>>
>>>1. We will have getpeercon() fail if there's no labeled-SA.
>>
>>... or NetLabel :)  What do you propose we do if there is both a SA and
>>NetLabel label, bearing in mind that NetLabel may be a full context?
> 
> I don't think we should have both of these possible for the same packet.  
> It's too complicated. 

That makes sense, what should we do in the case that we receive a packet
 on a labeled SA with a CIPSO option - drop it and send an ICMP error?
That seems like the logical solution, but I'm not sure that is one that
everyone will like.

> Remember: CIPSO is just a legacy technology which is useful for talking to 
> existing CIPSO systems.  We should not be making the rest of the code jump 
> through hoops to accomodate things it was never intended for, such as 
> integrated IPsec protection.
>
> The preferred & recommended means to implement labeled networking is via 
> the new xfrm labeling.  If you want to talk to legacy CIPSO systems the 
> way they already talk to each other, fine, but don't expect anything more 
> than that.

I stil think there may be some advantages to decoupling the labeling
from IPsec/XFRM, but following this idea right now starts getting away
from the current subject which I don't is right.  Also, since NetLabel
carrying more than a MLS label is all conjecture at this point I don't
think it's worth discussing any more than what has already been said.

The point I have been trying to make with all of this is that I think we
can find a solution where it doesn't matter if it is a full context or a
MLS-only context.  However, if we can't accomplish that, then we need to
find something that at least allows the different systems to exist on
the same machine, not necessarily the same connection.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> On Fri, 22 Sep 2006, Joshua Brindle wrote:
> 
> > Once again, I don't think the "ts data coming into a secret 
> SA" makes
> > sense.

Where did I suggest this? All that we are trying to enforce are
flow control checks to *prevent* this from happening, for added
assurance.

> If that happens your policy is broken,

Not necessarily. Consider the forwarding scenario where data is
coming in thru a Top Secret interface and leaving thru a
 Secret interface. Currenlty you have *nothing* to prvent that.

> this data shouldn't be
> > allowed in at all
> let alone having magic level changes to 
> let it happen.

Nice combination of words :), but "magic level changes to let it happen"
isn't happening at all. In fact the whole effort here is to prevent this
among others.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> On Fri, 2006-09-22 at 13:23 -0400, Venkat Yekkirala wrote:
> > OK, here's what we will do:
> > 
> > 1. We will have getpeercon() fail if there's no labeled-SA.
> > 
> > 2. We will do a getdatacon() or something similar to retrieve the
> >    secmark (as reconciled in the proposed reconciliation 
> logic, of course).
> > 
> > Comments?
> 
> I think that just moves the problem.

We put a design doc out 3 months or so back (alerting selinux list
at least 2 times 
http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2),
thought got the buy in, and went ahead and implemented
it.

What baffles me is that people even had problems using secmark as it
currently exists, just a few days back. It tells me people look at what
has come along, and THEN find (lack of) uses for it.

Let's go back to the drawing board, first of all define the problems
we are trying to solve, and come up with a design.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Joy Latten]

>If you have NetLabel carrying the MLS label why would you want to make
>your life complicated by using SA labeling as well?  I just don't
>understand why the duplication is necessary.  Since this example is only
>dealing with MLS, why not just use NetLabel and if you can't trust the
>physical link layer, i.e. you need IPsec protection, just run unlabeled
>IPsec.  This will allow you to talk to both SELinux and legacy Trusted
>OSs without problem, and it allows you the flexibility of offloading the
>IPsec processing to some sort of bump-in-the-wire solution which could
>yield significant performance advantages.

I agree with this.

Actually, I have been wondering why you would want to use both
netlabel and labeled ipsec on the same traffic stream.
In the same network environment, yes, but I am not sure I
understand why on the same traffic stream.

I think it was said, " but how would you then make sure a secret
cipso didn't arrive thru a TopSecret SA?" 
My question is why configure an ipsec policy with context (which
will result in a labeled SA, for example TopSecret SA) for that 
traffic stream if you know that traffic stream contains an OS 
that will use cipso?  I may be misunderstanding or missing something...
but I am not sure I understand why you would want that traffic 
stream to use both schemes?

I agree, if using cipso and you want to secure your traffic stream,
plain, non-labeled ipsec would do the job. 

Regards,
Joy

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joy Latten]

>> For handling incoming packets this may mean that we keep all of the
>> packet labeling mechanisms separate, allowing each to have it's own
>> permission check.
>
>But how would you then make sure a secret cipso didn't arrive thru a
>TopSecret SA?

But why would you want to configure an ipsec policy containing a
security context that will generate a TopSecret SA, over a traffic
stream that you know will use cipso? If the answer is customers
might do this... but I still don't get why?  Couldn't it be usage?
I may be misunderstanding...

Joy


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> 
<snip>
> We put a design doc out 3 months or so back (alerting selinux 
> list at least 2 times 
> http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2),
> thought got the buy in, and went ahead and implemented it.
> 

I never had an indication of the type trans calculation of the incoming
socket, from the list above:
1.	Set the packet's secmark to the iptables context (R1a).
2.	If it is an ipsec packet,
...
		Yes: Set the secmark to ipsec label (replacing iptables
context
		     set in step 1) (R1b).

However (at least for me) the ramifications of using the secmark (I
think there is a vocabulary issue above) label from iptables in labeling
the socket weren't immediately obvious, this all took a while to sink
in...

> What baffles me is that people even had problems using 
> secmark as it currently exists, just a few days back. It 
> tells me people look at what has come along, and THEN find 
> (lack of) uses for it.
> 

Seems like that is a fact of development.. How many times do you design
an API for a library and then find that it is inadequate when you write
a user for it.. Sometimes you get lucky, sometimes not. There were also
quite a few misconceptions (on my part and on others) about how labeled
networking was expected to work so it took a little while to catch up.

> Let's go back to the drawing board, first of all define the 
> problems we are trying to solve, and come up with a design.
> 

My single requirement is that getpeercon() returns the full context of
the remote process (or some translation negotiated by racoon). 

For clarity sake, what are your own requirements? I can't follow the top
secret coming in a secret interface thing. If the interface is secret
the ipsec sa will be secret, the secmark labels will be secret and the
enforcement won't let it in (which is desirable right?) Why is a type
transition necessary for this situation?

Also, Stephen mentioned a couple times that using netlabel and ipsec is
ok basically to allow course grained ranged ipsec associations and finer
grained netlabel labels for the actual level. Assuming that we are sure
we can deal with it when (if) netlabel handles full contexts I guess I
don't have a problem with this anymore. It wouldn't be any kind of
transition though (I think). It would just be that the contexts were
compared and if netlabel is within the range it takes priority, if it is
outside the range it should be an error and the packet should be
rejected.

If we use racoon to negotiate the label of the SA, and racoon is made to
be flexible (eg., if you want the domain it can use that, if you want
the data label you could use that) then I don't see any reason why you
(or anyone) would want to use the secmark label anymore, right? 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Fri, 2006-09-22 at 16:57 -0400, Stephen Smalley wrote:
> On Fri, 2006-09-22 at 13:23 -0400, Venkat Yekkirala wrote:
> > OK, here's what we will do:
> > 
> > 1. We will have getpeercon() fail if there's no labeled-SA.
> > 
> > 2. We will do a getdatacon() or something similar to retrieve the
> >    secmark (as reconciled in the proposed reconciliation logic, of course).
> > 
> > Comments?
> 
> I think that just moves the problem.  The question is still whether we
> can have a coherent policy using that reconciliation logic for both
> users of secmark.

This is one of my primary concerns as we are one of the groups that will
attempt to package all of this up, present it to users in a coherent
way, and explain to customers why what they thought is happening is not
happening.

<snip>

>  So we now have multiple rules on packet class to
> achieve the same goal via different mechanisms, and getdatacon() can
> potentially return any of these types.
> 

Exactly. We need _one_ policy regardless of the labeling mechanism that
is used.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Chad Hanson]

The driving requirements for this work is to have the kernel enforce
security policy on transient packets, i.e. forwarded traffic, which has been
lacking since the original networking hooks were rejected. Secondly, the
forwarded traffic enters the system as labeled traffic, say labeled IPSEC,
and the label attached to this traffic (packet) should be enforced when it
leaves the system. Note, the packet leaving the system is no longer
encapsulated via IPSEC and is being transmitted to an single level host.

A simple statement of this would be a secret ipsec packet coming in on a
ranged interface (systemlow-systemhigh) is forwarded as a regular packet out
a single level secret interface. Note, if the packet was unclassified, the
forwarding would fail to go through the secret interface. This is the
desired behavior.

Also, this implementation is fielded today as part of solutions in real
use....

-Chad  

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Fri, 2006-09-22 at 17:55 -0400, Venkat Yekkirala wrote: 
> > On Fri, 2006-09-22 at 13:23 -0400, Venkat Yekkirala wrote:
> > > OK, here's what we will do:
> > > 
> > > 1. We will have getpeercon() fail if there's no labeled-SA.
> > > 
> > > 2. We will do a getdatacon() or something similar to retrieve the
> > >    secmark (as reconciled in the proposed reconciliation 
> > logic, of course).
> > > 
> > > Comments?
> > 
> > I think that just moves the problem.
> 
> We put a design doc out 3 months or so back (alerting selinux list
> at least 2 times 
> http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2),
> thought got the buy in, and went ahead and implemented
> it.
> 

I've been loosely following this, but had not looked closely until two
weeks ago when we tried to sit down and figure out how we were going to
use all of this new stuff to accomplish our goals.

I know it is frustrating to get delayed feedback, but I hope that it
will ultimately result in something better.

> What baffles me is that people even had problems using secmark as it
> currently exists, just a few days back. It tells me people look at what
> has come along, and THEN find (lack of) uses for it.
> 
> Let's go back to the drawing board, first of all define the problems
> we are trying to solve, and come up with a design.

Thinking about this over the weekend, it seems to me that we are still
talking around the problem a bit. We essentially have 2 goals:

    1) Packet labeling - assigning labels to the _data_ transferred
       over the network. Secmark does only this and - from what I can 
       tell - this has been the primary motivation for Netlabel and 
       ipsec.

    2) Domain (process) context transmission - essentially, making 
       getpeercon work for non-local sockets. The important thing here 
       is that this is separate and distinct from the label of the 
       packet. getpeercon (which is not just a poorly named function - 
       the semantic is intentional and useful) should return the full 
       context of the process on the other end of the network 
       connection.

There have been various suggestions about how to reconcile these two
goals, essentially via encoding additional data via range and type
transitions. I believe that this _will never work_. It is not possible
to recover the domain context fully from the packet label - if nothing
else the user and role will be lost (e.g., a data label would likely use
object_r), which is unacceptable for the imagined uses of getpeercon.

The choices I see are:

    1) Leave netlabel and ipsec as packet labeling _only_. Somehow 
       reconcile / prioritize the various packet labels.

    2) Make netlabel and ipsec transmit the sending domain context 
       _only_. Somehow reconcile the various domain labels.

    3) Allow ipsec to transmit 2 contexts or designate that Netlabel 
       passes 1 kind of remote label and ipsec transmits the other 
       (e.g., netlabel labels the packet while ipsec transmits the 
       sending domain context).

The primary drawbacks I see to 1 are that getpeercon will not work for
remote sockets and the current reconciliation schemes require divergent
policies depending upon the labeling mechanisms employed.

The problem with 2 is that it doesn't allow the sending machine to pass
information that it has about the label of the packet - this is probably
a large loss for MLS, but is also problematic for TE (e.g., my bind
example - only bind knows whether a packet is part of a zone transfer or
not).

3 is the most flexible but is probably the most complicated. It also
probably requires the most rewriting.

Just a general note - I think that multiple packet labeling mechanisms
cooperating is going to be difficult for users to understand and debug -
if we get users used to writing secmark rules with iptables it will be
surprising if those simply stop working for hosts that use labeled ipsec
(which is the current default). The notion that we need to have multiple
policies is going to make things difficult for distributors and users
(and is an unacceptable solution in my view). I think we need to focus
more on what the resulting policies will look like and what the
writing / debugging /setup process will look like for users.

Thanks,

Karl




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Chad Hanson]

> 
>     2) Domain (process) context transmission - essentially, making 
>        getpeercon work for non-local sockets. The important thing here 
>        is that this is separate and distinct from the label of the 
>        packet. getpeercon (which is not just a poorly named function - 
>        the semantic is intentional and useful) should return the full 
>        context of the process on the other end of the network 
>        connection.
> 

This is why we just introduced the getdatacon() notion. Regardless of
whether a packet arrived from a trusted or non-trusted host, we may have the
desire to utilize the label of the packet. An example of this would be a
trusted app, such as xinetd or a guard, which wants to use the label of the
traffic to launch a service or make a security decision.

-Chad

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > Let's go back to the drawing board, first of all define the 
> > problems we are trying to solve, and come up with a design.
> > 
> 
> My single requirement is that getpeercon() returns the full context of
> the remote process (or some translation negotiated by racoon). 

That single requirement is bogus - you'll never get it.  At most, you'll
get the full context of the remote socket endpoint.  Which might be the
same as the process, but not necessarily.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Casey Schaufler]

--- Chad Hanson <chanson@TrustedCS.com> wrote:

> 
> The driving requirements for this work is to have
> the kernel enforce
> security policy on transient packets, i.e. forwarded
> traffic, which has been
> lacking since the original networking hooks were
> rejected. Secondly, the
> forwarded traffic enters the system as labeled
> traffic, say labeled IPSEC,
> and the label attached to this traffic (packet)
> should be enforced when it
> leaves the system. Note, the packet leaving the
> system is no longer
> encapsulated via IPSEC and is being transmitted to
> an single level host.
> 
> A simple statement of this would be a secret ipsec
> packet coming in on a
> ranged interface (systemlow-systemhigh) is forwarded
> as a regular packet out
> a single level secret interface. Note, if the packet
> was unclassified, the
> forwarding would fail to go through the secret
> interface. This is the
> desired behavior.
> 
> Also, this implementation is fielded today as part
> of solutions in real
> use....
> 
> -Chad  

Although no one is asking how it's been done
in the past, I'll toss the information into
the pot in the hope that it might be useful
in some way.

In the early days of CIPSO it became clear
that it was not sufficient to look at the
label passed in the IP header by CIPSO.
At the very least, something had to be done
about packets that arrived without CIPSO
data. There were also systems that would
crash (not Unix!) if they received packets
with IP options, so it had to be possible
to eschew labeling packets. You had to know
how to communicate with a particular host.
This became even clearer with the
introduction of CIPSO tag types and eventually
TSIX and SAMP.

Two technics were used to determine what
communication scheme to use when talking to
another system. Per-host identification
requires that each host be identified as
to what scheme should be used. Per-interface
defined how packets would go out on a
particular wire.

In either case, the scheme identifies what
is to be sent and what is to be expected
of any packet. If you're looking for an
unlabled packet, and you get CIPSO, it's
bad. If you're using a higher level protocol
and you get CIPSO you may just chuck the
CIPSO and use the higher level, or use
the CIPSO for range checking, based on what
you expect from that host/wire.

Of course, there's overhead to creating a
security communication specification for
each peer. Wildcards are necessary for
internet deployments.



Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > Let's go back to the drawing board, first of all define the 
> > > problems we are trying to solve, and come up with a design.
> > > 
> > 
> > My single requirement is that getpeercon() returns the full context of
> > the remote process (or some translation negotiated by racoon). 
> 
> That single requirement is bogus - you'll never get it.  At most, you'll
> get the full context of the remote socket endpoint.  Which might be the
> same as the process, but not necessarily.
> 

That's fine, it matches the semantics of getpeercon() locally. Policy
can dictate that the socket endpoint is necessarily the domain context.
Nonetheless, if I can't get something that represents the exact domain
(not an SA that can be used by lots of domains) I can't do access
control on network clients (at least not with getpeercon().. there would
have to be oob transfer of the context which is additional complication
and infrastructure). 

Additionally, though this is farther in the future, getpeercon() might
need to return something that represents the remote domain but in a way
that the local machine can understand. For example, if one machine is
running targeted and one is running strict, there will have to be a
translation from a local context to a remote context that is negotiated.
(that is the "or some translation negotiated by racoon" in my original
response) 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > Let's go back to the drawing board, first of all define the 
> > > problems we are trying to solve, and come up with a design.
> > > 
> > 
> > My single requirement is that getpeercon() returns the full context of
> > the remote process (or some translation negotiated by racoon). 
> 
> That single requirement is bogus - you'll never get it.  At most, you'll
> get the full context of the remote socket endpoint.  Which might be the
> same as the process, but not necessarily.
> 

Just because it will be hard or impossible to get this data doesn't mean
the requirement is bogus. It seems to me that getting the process
context is helpful whenever the data stream is really some form of
remote procedure call. So, are you really objecting to the requirement
conceptually or just pointing out that it won't happen?

The remote socket is probably good enough, though, and as Josh points
out policy can enforce that the socket type matches the current process
domain type (or at least a domain type).

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Mon, 2006-09-25 at 11:28 -0400, Chad Hanson wrote: 
> > 
> >     2) Domain (process) context transmission - essentially, making 
> >        getpeercon work for non-local sockets. The important thing here 
> >        is that this is separate and distinct from the label of the 
> >        packet. getpeercon (which is not just a poorly named function - 
> >        the semantic is intentional and useful) should return the full 
> >        context of the process on the other end of the network 
> >        connection.
> > 
> 
> This is why we just introduced the getdatacon() notion. Regardless of
> whether a packet arrived from a trusted or non-trusted host, we may have the
> desire to utilize the label of the packet. An example of this would be a
> trusted app, such as xinetd or a guard, which wants to use the label of the
> traffic to launch a service or make a security decision.
> 

I think that getting the label of packets is a good idea, but this is
separate from getpeercon. Venkat suggested in the past that getpeercon
should be replaced by getdatacon - "And we could change the name of
getpeercon() to be more meaningful/accurate to, say getdatacon(), if
need be."

Is the suggestion now for parallel interfaces not replacing getpeercon?

Also, how would this work for non-connection oriented protocols? I
haven't seen a proposed syntax, but a getpeercon style interface would
not seem to work for udp, etc., correct?

Karl

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Darrel Goeddel]

Joshua Brindle wrote:
> On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> 
>>On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
>>
>>>>From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
>>>>Let's go back to the drawing board, first of all define the 
>>>>problems we are trying to solve, and come up with a design.
>>>>
>>>
>>>My single requirement is that getpeercon() returns the full context of
>>>the remote process (or some translation negotiated by racoon). 
>>
>>That single requirement is bogus - you'll never get it.  At most, you'll
>>get the full context of the remote socket endpoint.  Which might be the
>>same as the process, but not necessarily.
>>
> 
> 
> That's fine, it matches the semantics of getpeercon() locally. Policy
> can dictate that the socket endpoint is necessarily the domain context.

True.  But we must remember to differentiate your usage on the client
end (policy dictating socket = process) with what the mechanism allows
(just about anything) when placing limitations on the mechanism for the
server end.

This comment is kinda going back to the complaint of mixing "process
types" with "object types" in the secid reconciliation approach...  The
idea of using the best available information for packet labeling really
seems like a good idea to me.  Treating the iptables label as the most
accurate label we can come up with locally given the information, and
sticking that into the secmark field of the buffer is good.  Then, if
something says it has better information about the packets label, like
ipsec, we should listen to that.  We make sure that the label ipsec
presents up with matches up in some way with what we thought we would be
getting (the flow_in) check, then we replace the secmark field with this
label (I think this is where we also introduced a transition to allow
for more flexibility via policy) because we consider this a higher
authority when it comes to labeling.  Now we have the best information
represented via the secmark field on the buffer.  Now... if that buffer
goes to userland or is getting forwarded, the correct (at least in my
world) label would be available for use in access checks.  Locally
generated packets also get their secmark field populated with the label
of the socket at creation so they also have properly labeling wherever
they go.  Now that the secmark field is always up-to-date, we just check
that against the iptables context on the way out.  Back to the complaint
- the mixing of "process types" and "object types" is really a product
of your configuration.  I think the mechanism supports you adapting to
your own constraints via the ipsec/iptables transition.  Now, it is
still true that the label in secmark may have come from different
sources (so your the idea behind the mixing argument still has some
validity), but it does always reflect the best information we have
available at the time for labeling.  That is what we really need to
manage the routing case and it is also something I would like to see
available to applications, they need to know labeling information about
the data no matter where it comes from - everything must have a label.
Wether that is getdatacon() or getpeercon() or
getthebestconthatwehaveavailabe() really make no difference to me.

> Nonetheless, if I can't get something that represents the exact domain
> (not an SA that can be used by lots of domains) I can't do access
> control on network clients (at least not with getpeercon().. there would
> have to be oob transfer of the context which is additional complication
> and infrastructure). 
> 
> Additionally, though this is farther in the future, getpeercon() might
> need to return something that represents the remote domain but in a way
> that the local machine can understand. For example, if one machine is
> running targeted and one is running strict, there will have to be a
> translation from a local context to a remote context that is negotiated.
> (that is the "or some translation negotiated by racoon" in my original
> response)

I'm sure that someone on this list has something interesting to say about
implementations that handle the issue mentioned above...

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 11:55 -0400, Joshua Brindle wrote:
> On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> > On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > > Let's go back to the drawing board, first of all define the 
> > > > problems we are trying to solve, and come up with a design.
> > > > 
> > > 
> > > My single requirement is that getpeercon() returns the full context of
> > > the remote process (or some translation negotiated by racoon). 
> > 
> > That single requirement is bogus - you'll never get it.  At most, you'll
> > get the full context of the remote socket endpoint.  Which might be the
> > same as the process, but not necessarily.
> > 
> 
> That's fine, it matches the semantics of getpeercon() locally. Policy
> can dictate that the socket endpoint is necessarily the domain context.

If we always wanted that, why would we have
added /proc/self/attr/sockcreate?

> Nonetheless, if I can't get something that represents the exact domain
> (not an SA that can be used by lots of domains) I can't do access
> control on network clients (at least not with getpeercon()..

s/SA/socket/ above and think about what you just said.  It is no
different.  Socket or SA - they are levels of indirection that are
necessarily present because the relationship is indirect.  And as long
as you have control over the relationships, you can establish the higher
level security goal.

>  there would
> have to be oob transfer of the context which is additional complication
> and infrastructure). 

No, there wouldn't.  

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 10:59 -0400, Karl MacMillan wrote:
> Thinking about this over the weekend, it seems to me that we are still
> talking around the problem a bit. We essentially have 2 goals:
> 
>     1) Packet labeling - assigning labels to the _data_ transferred
>        over the network. Secmark does only this and - from what I can 
>        tell - this has been the primary motivation for Netlabel and 
>        ipsec.

I think that you need to draw a distinction between secmark (internal
marking of packets within the local network stack for access control
purposes to replace and generalize the old netif/node/port labels and
checks) and labeled networking (preserving the actual security label of
the data as it propagates through the network stack and across the
wire).  In the original secmark scheme, the secmark does not reflect the
security properties of the sender (data originator) at all in many
instances (e.g. all packets on an inbound connection to apache get
http_server_packet_t, regardless of which side sent them, and packets on
an outbound connection to apache get http_client_packet_t which tells us
about their destination not their sender).  The secmark also encodes
contextual information like the connection direction
(http_server_packet_t for an inbound connection vs. http_client_packet_t
for an outbound connection), whereas labeled networking does not encode
such information in the label and would require separate checks to
provide such a distinction, as the send/recv checks themselves do not
provide that distinction.

>     2) Domain (process) context transmission - essentially, making 
>        getpeercon work for non-local sockets. The important thing here 
>        is that this is separate and distinct from the label of the 
>        packet. getpeercon (which is not just a poorly named function - 
>        the semantic is intentional and useful) should return the full 
>        context of the process on the other end of the network 
>        connection.

getpeercon was always to get the context of the peer socket, as that is
the endpoint and serves logically as a proxy for the remote process or
processes that are allowed to access the socket.  But this isn't
necessarily distinct from a packet/data label in the labeled networking
sense, because it does reflect the security properties of the sender of
the data, which is the logical default for the packet/data label in the
absence of any explicitly specified value (for which no kernel interface
presently exists for either AF_LOCAL or AF_INET, ever since we lost the
extended socket calls of the old SELinux).

> There have been various suggestions about how to reconcile these two
> goals, essentially via encoding additional data via range and type
> transitions. I believe that this _will never work_. It is not possible
> to recover the domain context fully from the packet label - if nothing
> else the user and role will be lost (e.g., a data label would likely use
> object_r), which is unacceptable for the imagined uses of getpeercon.

Actually, it _could_ work, with suitable definition of the transition
function, but it may be unwieldy in the resulting policy.  And there is
still the issue of how to sanely write a single policy that allows
everything to work correctly, which I was trying to delve into in my
earlier email.

> The choices I see are:
> 
>     1) Leave netlabel and ipsec as packet labeling _only_. Somehow 
>        reconcile / prioritize the various packet labels.
>
>     2) Make netlabel and ipsec transmit the sending domain context 
>        _only_. Somehow reconcile the various domain labels.
>
>     3) Allow ipsec to transmit 2 contexts or designate that Netlabel 
>        passes 1 kind of remote label and ipsec transmits the other 
>        (e.g., netlabel labels the packet while ipsec transmits the 
>        sending domain context).

I thin the only real choices are:
1) Add a separate field to the sk_buff for use by labeled networking so
that we don't have to overload secmark in this manner, or
2) Deal with the secid reconciliation, but work out the policy
implications.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 11:28 -0400, Chad Hanson wrote:
> > 
> >     2) Domain (process) context transmission - essentially, making 
> >        getpeercon work for non-local sockets. The important thing here 
> >        is that this is separate and distinct from the label of the 
> >        packet. getpeercon (which is not just a poorly named function - 
> >        the semantic is intentional and useful) should return the full 
> >        context of the process on the other end of the network 
> >        connection.
> > 
> 
> This is why we just introduced the getdatacon() notion. Regardless of
> whether a packet arrived from a trusted or non-trusted host, we may have the
> desire to utilize the label of the packet. An example of this would be a
> trusted app, such as xinetd or a guard, which wants to use the label of the
> traffic to launch a service or make a security decision.

But your example is precisely how getpeercon() is used, so the
distinction between getdatacon() and getpeercon() seems artificial to
me.  The real problem is figuring out how to reconcile secmark with
labeled networking, not getpeercon vs. getdatacon.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 12:35 -0400, Karl MacMillan wrote:
> On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> > On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > > Let's go back to the drawing board, first of all define the 
> > > > problems we are trying to solve, and come up with a design.
> > > > 
> > > 
> > > My single requirement is that getpeercon() returns the full context of
> > > the remote process (or some translation negotiated by racoon). 
> > 
> > That single requirement is bogus - you'll never get it.  At most, you'll
> > get the full context of the remote socket endpoint.  Which might be the
> > same as the process, but not necessarily.
> > 
> 
> Just because it will be hard or impossible to get this data doesn't mean
> the requirement is bogus. It seems to me that getting the process
> context is helpful whenever the data stream is really some form of
> remote procedure call. So, are you really objecting to the requirement
> conceptually or just pointing out that it won't happen?

Conceptually.  There is always going to be a level of indirection here,
and the higher level security goal always has to be decomposed into
multiple relationships.

> The remote socket is probably good enough, though, and as Josh points
> out policy can enforce that the socket type matches the current process
> domain type (or at least a domain type).

It doesn't need to do that, and setsockcreatecon() wouldn't exist if we
always wanted that relationship to be fixed.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Mon, 2006-09-25 at 13:02 -0400, Stephen Smalley wrote: 
> On Mon, 2006-09-25 at 11:55 -0400, Joshua Brindle wrote:
> > On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> > > On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > > > Let's go back to the drawing board, first of all define the 
> > > > > problems we are trying to solve, and come up with a design.
> > > > > 
> > > > 
> > > > My single requirement is that getpeercon() returns the full context of
> > > > the remote process (or some translation negotiated by racoon). 
> > > 
> > > That single requirement is bogus - you'll never get it.  At most, you'll
> > > get the full context of the remote socket endpoint.  Which might be the
> > > same as the process, but not necessarily.
> > > 
> > 
> > That's fine, it matches the semantics of getpeercon() locally. Policy
> > can dictate that the socket endpoint is necessarily the domain context.
> 
> If we always wanted that, why would we have
> added /proc/self/attr/sockcreate?
> 
> > Nonetheless, if I can't get something that represents the exact domain
> > (not an SA that can be used by lots of domains) I can't do access
> > control on network clients (at least not with getpeercon()..
> 
> s/SA/socket/ above and think about what you just said.  It is no
> different.  Socket or SA - they are levels of indirection that are
> necessarily present because the relationship is indirect.  And as long
> as you have control over the relationships, you can establish the higher
> level security goal.
> 

You know - I have this blind spot in my mental model of how networking
works. Yes - sockets means that there is an additional level of
indirection which will make any attempt to treat these connections as
between two process break.

The ipc model I was using as a strawman sounds nice - I think it would
be more natural for server processes that act as surrogates for remote
processes to enforce access based on the process context (including the
ability to use the role for additional restrictions - e.g., when
exec'ing new processes based on an rpc call). I don't think that this
maps well to the socket model, however. In reality I think that the
current semantics of getpeercon must remain local only.

As to the ability to enforce higher level goals if you can control the
relationships, I don't disagree. I will note, however, that each level
of indirection makes it more difficult for many users to understand.
When I have taught SELinux classes most users have some amount of
difficulty with types (1 level of indirection). Most have more trouble
with attributes (2 levels of indirection) and some never make the leap.

So I am getting very concerned that our model has all of these layers
(process->sockets->SA combined with secmark rules via type_transition).

Karl



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:
> On Mon, 2006-09-25 at 12:35 -0400, Karl MacMillan wrote:
> > On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> > > On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > > > Let's go back to the drawing board, first of all define the 
> > > > > problems we are trying to solve, and come up with a design.
> > > > > 
> > > > 
> > > > My single requirement is that getpeercon() returns the full context of
> > > > the remote process (or some translation negotiated by racoon). 
> > > 
> > > That single requirement is bogus - you'll never get it.  At most, you'll
> > > get the full context of the remote socket endpoint.  Which might be the
> > > same as the process, but not necessarily.
> > > 
> > 
> > Just because it will be hard or impossible to get this data doesn't mean
> > the requirement is bogus. It seems to me that getting the process
> > context is helpful whenever the data stream is really some form of
> > remote procedure call. So, are you really objecting to the requirement
> > conceptually or just pointing out that it won't happen?
> 
> Conceptually.  There is always going to be a level of indirection here,
> and the higher level security goal always has to be decomposed into
> multiple relationships.
> 

Why is it conceptually bogus to want the context of the domain talking
to you? You are saying there is indirection, and there is, but that
doesn't mean there isn't a legitimate need to know the remote domain
rather than the socket, data, packet, whatever. getpeercon() acted this
way for years before the option to label sockets came around (which has
no users afaik). 

I know flask specified impersonation, and that is what the socket
labeling does for us. Is this why you are saying there shouldn't be an
option to get access to the remote domain while ignoring the
intermediate indirection?

> > The remote socket is probably good enough, though, and as Josh points
> > out policy can enforce that the socket type matches the current process
> > domain type (or at least a domain type).
> 
> It doesn't need to do that, and setsockcreatecon() wouldn't exist if we
> always wanted that relationship to be fixed.
> 

what was the use case behind adding setsockcreatecon? For guards its
helpful so that you don't have to alternate ipc mechanisms in the
pipeline but for client server relationships.. not sure. 

Trusted proxies are one use case but I'm not sure how compelling that
is. Another is context translation but at that point setsockcreatecon
won't work anyway since the remote context isn't valid on the local
system.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Mon, 2006-09-25 at 13:58 -0400, Stephen Smalley wrote:
> On Mon, 2006-09-25 at 10:59 -0400, Karl MacMillan wrote:
> > Thinking about this over the weekend, it seems to me that we are still
> > talking around the problem a bit. We essentially have 2 goals:
> > 
> >     1) Packet labeling - assigning labels to the _data_ transferred
> >        over the network. Secmark does only this and - from what I can 
> >        tell - this has been the primary motivation for Netlabel and 
> >        ipsec.
> 
> I think that you need to draw a distinction between secmark (internal
> marking of packets within the local network stack for access control
> purposes to replace and generalize the old netif/node/port labels and
> checks) and labeled networking (preserving the actual security label of
> the data as it propagates through the network stack and across the
> wire).

Sure.

>   In the original secmark scheme, the secmark does not reflect the
> security properties of the sender (data originator) at all in many
> instances (e.g. all packets on an inbound connection to apache get
> http_server_packet_t, regardless of which side sent them, and packets on
> an outbound connection to apache get http_client_packet_t which tells us
> about their destination not their sender).  The secmark also encodes
> contextual information like the connection direction
> (http_server_packet_t for an inbound connection vs. http_client_packet_t
> for an outbound connection), whereas labeled networking does not encode
> such information in the label and would require separate checks to
> provide such a distinction, as the send/recv checks themselves do not
> provide that distinction.
> 

Which is why Venkat keeps pushing for viewing secmark as flow control
only I guess.

What you are pointing out, though, leaves me with less hope for
reconciliation. The models are divergent enough that it is not just a
matter of deciding which parts of differing labels to take for the
packet - the way in which higher level goals will be enforced in policy
is going to be very different.

> >     2) Domain (process) context transmission - essentially, making 
> >        getpeercon work for non-local sockets. The important thing here 
> >        is that this is separate and distinct from the label of the 
> >        packet. getpeercon (which is not just a poorly named function - 
> >        the semantic is intentional and useful) should return the full 
> >        context of the process on the other end of the network 
> >        connection.
> 
> getpeercon was always to get the context of the peer socket, as that is
> the endpoint and serves logically as a proxy for the remote process or
> processes that are allowed to access the socket.

Agreed - see my other email about my broken mental model of networking.

>   But this isn't
> necessarily distinct from a packet/data label in the labeled networking
> sense, because it does reflect the security properties of the sender of
> the data, which is the logical default for the packet/data label in the
> absence of any explicitly specified value (for which no kernel interface
> presently exists for either AF_LOCAL or AF_INET, ever since we lost the
> extended socket calls of the old SELinux).
> 

If we are going to ever allow explicit labeling of the packets then it
seems necessary for getpeercon to return the socket label instead of the
packet label. If you replace all of my previous ranting about process /
packet objects with socket / packet instead it seems to hold true to me.

With secmark it seems that packet and socket labels being different will
be the norm (with the current secid reconciliation suggestions).

> > There have been various suggestions about how to reconcile these two
> > goals, essentially via encoding additional data via range and type
> > transitions. I believe that this _will never work_. It is not possible
> > to recover the domain context fully from the packet label - if nothing
> > else the user and role will be lost (e.g., a data label would likely use
> > object_r), which is unacceptable for the imagined uses of getpeercon.
> 
> Actually, it _could_ work, with suitable definition of the transition
> function, but it may be unwieldy in the resulting policy.

And require new policy constructs.

>   And there is
> still the issue of how to sanely write a single policy that allows
> everything to work correctly, which I was trying to delve into in my
> earlier email.
> 
> > The choices I see are:
> > 
> >     1) Leave netlabel and ipsec as packet labeling _only_. Somehow 
> >        reconcile / prioritize the various packet labels.
> >
> >     2) Make netlabel and ipsec transmit the sending domain context 
> >        _only_. Somehow reconcile the various domain labels.
> >
> >     3) Allow ipsec to transmit 2 contexts or designate that Netlabel 
> >        passes 1 kind of remote label and ipsec transmits the other 
> >        (e.g., netlabel labels the packet while ipsec transmits the 
> >        sending domain context).
> 
> I thin the only real choices are:
> 1) Add a separate field to the sk_buff for use by labeled networking so
> that we don't have to overload secmark in this manner, or

This has the advantage of at least being clear, easy to explain, and
easy to debug for a user. The disadvantage, of course, is that you end
up with more policy.

I would rather see more allow rules that are clear than more transition
rules that are subtle and only take effect in some circumstances,
though.

> 2) Deal with the secid reconciliation, but work out the policy
> implications.
> 

Like I said above, I think you are correctly pointing out that this is a
deeper issue than labels and the policy implications are going to be
hard. The division between what logic is pushed into the labeling
mechanism and what logic is pushed into the object class permissions is
too different.

I think that we should go for 1 and have getpeercon return the label
from the labeled networking.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Karl MacMillan]

On Mon, 2006-09-25 at 14:25 -0400, Joshua Brindle wrote:
> On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:

<snip>

> > > The remote socket is probably good enough, though, and as Josh points
> > > out policy can enforce that the socket type matches the current process
> > > domain type (or at least a domain type).
> > 
> > It doesn't need to do that, and setsockcreatecon() wouldn't exist if we
> > always wanted that relationship to be fixed.
> > 
> 
> what was the use case behind adding setsockcreatecon? For guards its
> helpful so that you don't have to alternate ipc mechanisms in the
> pipeline but for client server relationships.. not sure. 
> 

xinetd was one - it allows the creation of sockets with the "correct"
label (e.g., telnetd_t) so that all processes spawned by xinetd to have
to have permissions on all xinetd sockets.

Any time sockets are going to be created by one process and passed to
another it is useful to have setsockcreatecon.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 14:25 -0400, Joshua Brindle wrote:
> On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:
> > On Mon, 2006-09-25 at 12:35 -0400, Karl MacMillan wrote:
> > > On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> > > > On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > > > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > > > > Let's go back to the drawing board, first of all define the 
> > > > > > problems we are trying to solve, and come up with a design.
> > > > > > 
> > > > > 
> > > > > My single requirement is that getpeercon() returns the full context of
> > > > > the remote process (or some translation negotiated by racoon). 
> > > > 
> > > > That single requirement is bogus - you'll never get it.  At most, you'll
> > > > get the full context of the remote socket endpoint.  Which might be the
> > > > same as the process, but not necessarily.
> > > > 
> > > 
> > > Just because it will be hard or impossible to get this data doesn't mean
> > > the requirement is bogus. It seems to me that getting the process
> > > context is helpful whenever the data stream is really some form of
> > > remote procedure call. So, are you really objecting to the requirement
> > > conceptually or just pointing out that it won't happen?
> > 
> > Conceptually.  There is always going to be a level of indirection here,
> > and the higher level security goal always has to be decomposed into
> > multiple relationships.
> > 
> 
> Why is it conceptually bogus to want the context of the domain talking
> to you? You are saying there is indirection, and there is, but that
> doesn't mean there isn't a legitimate need to know the remote domain
> rather than the socket, data, packet, whatever. getpeercon() acted this
> way for years before the option to label sockets came around (which has
> no users afaik). 

getpeercon and its predecessors have always returned the context of the
peer socket, not the context of a process.  That provides a well-defined
result.  Which process would you choose as the peer?  There could be
zero or many at the time the connection is established.  Data could flow
from any of them.  The socket may get inherited or passed around.  

> I know flask specified impersonation, and that is what the socket
> labeling does for us. Is this why you are saying there shouldn't be an
> option to get access to the remote domain while ignoring the
> intermediate indirection?

It is less about impersonation than the inherent network protocol
implementation's architecture, but yes, if you are going to provide
impersonation, you'd like it to be fully transparent.

> what was the use case behind adding setsockcreatecon? For guards its
> helpful so that you don't have to alternate ipc mechanisms in the
> pipeline but for client server relationships.. not sure. 

xinetd was given as one use case, to label the sockets to reflect the
actual services.  I don't know if anyone has implemented the change to
xinetd.  But in general, being able to label any object with a specified
context at creation time is consistent with SELinux.

> Trusted proxies are one use case but I'm not sure how compelling that
> is. Another is context translation but at that point setsockcreatecon
> won't work anyway since the remote context isn't valid on the local
> system.
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joshua Brindle]

On Mon, 2006-09-25 at 14:41 -0400, Karl MacMillan wrote:
> On Mon, 2006-09-25 at 14:25 -0400, Joshua Brindle wrote:
> > On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:
> 
> <snip>
> 
> > > > The remote socket is probably good enough, though, and as Josh points
> > > > out policy can enforce that the socket type matches the current process
> > > > domain type (or at least a domain type).
> > > 
> > > It doesn't need to do that, and setsockcreatecon() wouldn't exist if we
> > > always wanted that relationship to be fixed.
> > > 
> > 
> > what was the use case behind adding setsockcreatecon? For guards its
> > helpful so that you don't have to alternate ipc mechanisms in the
> > pipeline but for client server relationships.. not sure. 
> > 
> 
> xinetd was one - it allows the creation of sockets with the "correct"
> label (e.g., telnetd_t) so that all processes spawned by xinetd to have
> to have permissions on all xinetd sockets.
> 
> Any time sockets are going to be created by one process and passed to
> another it is useful to have setsockcreatecon.
> 

Fair enough, this was my trusted proxy example below that you removed :)

I admit that trusted proxies should be able to do this and that's fine,
it doesn't change what I want, which is the domain that we'll be doing
access control on. 

If there is a case where a proxy changes the context of the socket
before connecting to the policy server that doesn't violate my goals. I
guess I probably didn't make that clear before. 

Since the policy controls how socket contexts can be changed that isn't
an issue.

What I was adverse to is the transformation with secmark which I believe
should be used for access control on the packets and not network
labeling.

> Karl
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Karl MacMillan wrote:
> On Mon, 2006-09-25 at 13:58 -0400, Stephen Smalley wrote:
>>On Mon, 2006-09-25 at 10:59 -0400, Karl MacMillan wrote:
>>>The choices I see are:
>>>
>>>    1) Leave netlabel and ipsec as packet labeling _only_. Somehow 
>>>       reconcile / prioritize the various packet labels.
>>>
>>>    2) Make netlabel and ipsec transmit the sending domain context 
>>>       _only_. Somehow reconcile the various domain labels.
>>>
>>>    3) Allow ipsec to transmit 2 contexts or designate that Netlabel 
>>>       passes 1 kind of remote label and ipsec transmits the other 
>>>       (e.g., netlabel labels the packet while ipsec transmits the 
>>>       sending domain context).
>>
>>I thin the only real choices are:
>>1) Add a separate field to the sk_buff for use by labeled networking so
>>that we don't have to overload secmark in this manner, or
>  
> This has the advantage of at least being clear, easy to explain, and
> easy to debug for a user. The disadvantage, of course, is that you end
> up with more policy.
> 
> I would rather see more allow rules that are clear than more transition
> rules that are subtle and only take effect in some circumstances,
> though.
> 
>>2) Deal with the secid reconciliation, but work out the policy
>>implications.
> 
> Like I said above, I think you are correctly pointing out that this is a
> deeper issue than labels and the policy implications are going to be
> hard. The division between what logic is pushed into the labeling
> mechanism and what logic is pushed into the object class permissions is
> too different.
> 
> I think that we should go for 1 and have getpeercon return the label
> from the labeled networking.

Unfortunately I don't think the netdev folks will like/accept adding
another field to the sk_buff structure.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Chad Hanson]

Correct, I just wanted to state that we need to have an interface to get the
packet context, no matter if it is from a labeled network connection or just
an implicit context from secmark labeling. If getpeercon() can do this,
there is no need for getdatacon().

-Chad

> 
> But your example is precisely how getpeercon() is used, so the
> distinction between getdatacon() and getpeercon() seems artificial to
> me.  The real problem is figuring out how to reconcile secmark with
> labeled networking, not getpeercon vs. getdatacon.
> 
> -- 
> Stephen Smalley
> National Security Agency
> 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Karl MacMillan wrote:
> On Mon, 2006-09-25 at 14:25 -0400, Joshua Brindle wrote:
> 
>>On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:
> 
> 
> <snip>
> 
>>>>The remote socket is probably good enough, though, and as Josh points
>>>>out policy can enforce that the socket type matches the current process
>>>>domain type (or at least a domain type).
>>>
>>>It doesn't need to do that, and setsockcreatecon() wouldn't exist if we
>>>always wanted that relationship to be fixed.
>>>
>>
>>what was the use case behind adding setsockcreatecon? For guards its
>>helpful so that you don't have to alternate ipc mechanisms in the
>>pipeline but for client server relationships.. not sure. 
> 
> xinetd was one - it allows the creation of sockets with the "correct"
> label (e.g., telnetd_t) so that all processes spawned by xinetd to have
> to have permissions on all xinetd sockets.

I belive that the SELinux/xinetd (at least the initial version, not sure
if it has changed) patch did not use setsockcreatecon() to set the
socket's context.  The kernel was tasked with setting the context of the
accept()'d TCP socket to match the context of the connection.  The idea
being that xinetd would accept() the incoming connection, do a
getpeercon() to fetch a context, call setexeccon() with that context,
and finally spawn the server daemon.

> Any time sockets are going to be created by one process and passed to
> another it is useful to have setsockcreatecon.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 14:49 -0400, Stephen Smalley wrote:
> On Mon, 2006-09-25 at 14:25 -0400, Joshua Brindle wrote:
> > On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:
> > > On Mon, 2006-09-25 at 12:35 -0400, Karl MacMillan wrote:
> > > > On Mon, 2006-09-25 at 11:35 -0400, Stephen Smalley wrote:
> > > > > On Sat, 2006-09-23 at 10:13 -0400, Joshua Brindle wrote:
> > > > > > > From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> > > > > > > Let's go back to the drawing board, first of all define the 
> > > > > > > problems we are trying to solve, and come up with a design.
> > > > > > > 
> > > > > > 
> > > > > > My single requirement is that getpeercon() returns the full context of
> > > > > > the remote process (or some translation negotiated by racoon). 
> > > > > 
> > > > > That single requirement is bogus - you'll never get it.  At most, you'll
> > > > > get the full context of the remote socket endpoint.  Which might be the
> > > > > same as the process, but not necessarily.
> > > > > 
> > > > 
> > > > Just because it will be hard or impossible to get this data doesn't mean
> > > > the requirement is bogus. It seems to me that getting the process
> > > > context is helpful whenever the data stream is really some form of
> > > > remote procedure call. So, are you really objecting to the requirement
> > > > conceptually or just pointing out that it won't happen?
> > > 
> > > Conceptually.  There is always going to be a level of indirection here,
> > > and the higher level security goal always has to be decomposed into
> > > multiple relationships.
> > > 
> > 
> > Why is it conceptually bogus to want the context of the domain talking
> > to you? You are saying there is indirection, and there is, but that
> > doesn't mean there isn't a legitimate need to know the remote domain
> > rather than the socket, data, packet, whatever. getpeercon() acted this
> > way for years before the option to label sockets came around (which has
> > no users afaik). 
> 
> getpeercon and its predecessors have always returned the context of the
> peer socket, not the context of a process.  That provides a well-defined
> result.  Which process would you choose as the peer?  There could be
> zero or many at the time the connection is established.  Data could flow
> from any of them.  The socket may get inherited or passed around.  

Now, in fairness, I think the AF_LOCAL peercred implementation does use
the process credentials, in particular the server gets the credentials
of the connecting process and the client gets the credentials of the
listening process (not the accepting process).  But the reality is still
that the indirection exists and there is no guarantee that those
credentials correspond to any of the actual traffic on the connection.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 14:56 -0400, Chad Hanson wrote:
> Correct, I just wanted to state that we need to have an interface to get the
> packet context, no matter if it is from a labeled network connection or just
> an implicit context from secmark labeling. If getpeercon() can do this,
> there is no need for getdatacon().

The problem is that the secmark labeling is generally not suitable as a
subject label or as a data origin label, so you can't use it in the way
you described.

> 
> -Chad
> 
> > 
> > But your example is precisely how getpeercon() is used, so the
> > distinction between getdatacon() and getpeercon() seems artificial to
> > me.  The real problem is figuring out how to reconcile secmark with
> > labeled networking, not getpeercon vs. getdatacon.
> > 
> > -- 
> > Stephen Smalley
> > National Security Agency
> > 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 15:00 -0400, Paul Moore wrote:
> Karl MacMillan wrote:
> > On Mon, 2006-09-25 at 14:25 -0400, Joshua Brindle wrote:
> > 
> >>On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:
> > 
> > 
> > <snip>
> > 
> >>>>The remote socket is probably good enough, though, and as Josh points
> >>>>out policy can enforce that the socket type matches the current process
> >>>>domain type (or at least a domain type).
> >>>
> >>>It doesn't need to do that, and setsockcreatecon() wouldn't exist if we
> >>>always wanted that relationship to be fixed.
> >>>
> >>
> >>what was the use case behind adding setsockcreatecon? For guards its
> >>helpful so that you don't have to alternate ipc mechanisms in the
> >>pipeline but for client server relationships.. not sure. 
> > 
> > xinetd was one - it allows the creation of sockets with the "correct"
> > label (e.g., telnetd_t) so that all processes spawned by xinetd to have
> > to have permissions on all xinetd sockets.
> 
> I belive that the SELinux/xinetd (at least the initial version, not sure
> if it has changed) patch did not use setsockcreatecon() to set the
> socket's context.  The kernel was tasked with setting the context of the
> accept()'d TCP socket to match the context of the connection.  The idea
> being that xinetd would accept() the incoming connection, do a
> getpeercon() to fetch a context, call setexeccon() with that context,
> and finally spawn the server daemon.

But that doesn't deal with the TE aspect of the socket context, right?
So you end up with the sockets being left in xinetd_t.

> 
> > Any time sockets are going to be created by one process and passed to
> > another it is useful to have setsockcreatecon.
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Paul Moore]

Stephen Smalley wrote:
> On Mon, 2006-09-25 at 15:00 -0400, Paul Moore wrote:
> 
>>Karl MacMillan wrote:
>>
>>>On Mon, 2006-09-25 at 14:25 -0400, Joshua Brindle wrote:
>>>
>>>
>>>>On Mon, 2006-09-25 at 14:04 -0400, Stephen Smalley wrote:
>>>
>>>
>>><snip>
>>>
>>>>>>The remote socket is probably good enough, though, and as Josh points
>>>>>>out policy can enforce that the socket type matches the current process
>>>>>>domain type (or at least a domain type).
>>>>>
>>>>>It doesn't need to do that, and setsockcreatecon() wouldn't exist if we
>>>>>always wanted that relationship to be fixed.
>>>>>
>>>>
>>>>what was the use case behind adding setsockcreatecon? For guards its
>>>>helpful so that you don't have to alternate ipc mechanisms in the
>>>>pipeline but for client server relationships.. not sure. 
>>>
>>>xinetd was one - it allows the creation of sockets with the "correct"
>>>label (e.g., telnetd_t) so that all processes spawned by xinetd to have
>>>to have permissions on all xinetd sockets.
>>
>>I belive that the SELinux/xinetd (at least the initial version, not sure
>>if it has changed) patch did not use setsockcreatecon() to set the
>>socket's context.  The kernel was tasked with setting the context of the
>>accept()'d TCP socket to match the context of the connection.  The idea
>>being that xinetd would accept() the incoming connection, do a
>>getpeercon() to fetch a context, call setexeccon() with that context,
>>and finally spawn the server daemon.
> 
> But that doesn't deal with the TE aspect of the socket context, right?
> So you end up with the sockets being left in xinetd_t.

That depends on the underlying labeling protocol.  Steve Grubb's xinetd
patch simply takes the output of getpeercon() and feeds it back into
setexeccon().  In the case of NetLabel, the context returned by
getpeercon is the concatenation of the parent socket's TE context and
the MLS label of the remote socket.  So for NetLabel, yes, the spawned
server process will run in the xinetd_t domain, or whatever domain
xinetd was running in when the connection was established.  With labeled
IPsec this will obviously be different.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 15:38 -0400, Paul Moore wrote:
> > But that doesn't deal with the TE aspect of the socket context, right?
> > So you end up with the sockets being left in xinetd_t.
> 
> That depends on the underlying labeling protocol.  Steve Grubb's xinetd
> patch simply takes the output of getpeercon() and feeds it back into
> setexeccon().  In the case of NetLabel, the context returned by
> getpeercon is the concatenation of the parent socket's TE context and
> the MLS label of the remote socket.  So for NetLabel, yes, the spawned
> server process will run in the xinetd_t domain, or whatever domain
> xinetd was running in when the connection was established.  With labeled
> IPsec this will obviously be different.

Hmmm...using the peer context in total as the new process context isn't
quite what you want, as you want the domain to reflect the service as
well (e.g. run in.ftpd in ftpd_t, not in the client's domain).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Mon, 25 Sep 2006, Karl MacMillan wrote:

> So I am getting very concerned that our model has all of these layers
> (process->sockets->SA combined with secmark rules via type_transition).

It's fine.  Think of it like a file being created, which may get a label 
based on a number of factors including the creating context and the parent 
directory context.

For networking, we're doing something similar, and just allowing all of 
the important factors to contribute to the labeling, including 
policy-controlled transitions as the labeling requirements become more 
specific.


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Chad Hanson]

In the absence of any other labeling, I would the secmark label would be
equivalent to the old selinux network labels. If I have guard that sits
between two unlabeled networks, I still want to be able to get the label of
a packet. Since these networks are unlabeled and thus don't speak IPSEC or
CIPSO, why wouldn't I use the MLS label that is in the secmark, as it is the
best information I have for the label of the data.

-Chad

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> 
> The problem is that the secmark labeling is generally not suitable as a
> subject label or as a data origin label, so you can't use it in the way
> you described.
> 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Mon, 25 Sep 2006, Stephen Smalley wrote:

> I thin the only real choices are:
> 1) Add a separate field to the sk_buff for use by labeled networking so
> that we don't have to overload secmark in this manner, or

This won't fly upstream.

One possible option here is to partition the 32-bit secmark internally, so 
that it can be encoded with two SELinux SIDs.


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 16:02 -0400, Chad Hanson wrote:
> In the absence of any other labeling, I would the secmark label would be
> equivalent to the old selinux network labels. If I have guard that sits
> between two unlabeled networks, I still want to be able to get the label of
> a packet. Since these networks are unlabeled and thus don't speak IPSEC or
> CIPSO, why wouldn't I use the MLS label that is in the secmark, as it is the
> best information I have for the label of the data.

But the secmark often tells you nothing about the data origin, or even
the way it entered the system, at least as currently employed by
refpolicy / netfilter_contexts.  That's my point.

You can certainly create custom iptables secmark rules that label
packets based on the receiving NIC, and then they would be useful in the
manner you describe.  But in general, they aren't guaranteed to tell you
anything about the origin at all.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Mon, 25 Sep 2006, James Morris wrote:

> On Mon, 25 Sep 2006, Stephen Smalley wrote:
> 
> > I thin the only real choices are:
> > 1) Add a separate field to the sk_buff for use by labeled networking so
> > that we don't have to overload secmark in this manner, or
> 
> This won't fly upstream.
> 
> One possible option here is to partition the 32-bit secmark internally, so 
> that it can be encoded with two SELinux SIDs.

If we're going to do this, we need to establish some kind of constraint on 
SID values passed as network labels, which could limit to only when 
external labeling is active.

e.g.

a) In the normal case, nothing happens.

b) If external labeling is enabled all SIDs used in the secmark field must 
be less than 2^16 in value, and external SIDs are shifted up to the top 
half of the field.  This is done transparently to the user, and if SIDs 
greater than 2^16-1 are present, then the system must also transparently 
remap them for use over the network.  This can be implemented later, but 
we should perhaps also reserve a bit to indicate a mapped SID.



-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> But the secmark often tells you nothing about the data origin, or even
> the way it entered the system, at least as currently employed by
> refpolicy / netfilter_contexts.  That's my point.

This is still a little hazy in my mind; as to why secmark is being
employed this way. What are the kinds of threats this is designed
to handle?

Could we not look at data in transit as sort of an extension of
the remote socket into the local machine?

Could we then not look at the "packet" (as well as any other networking
element) as a "sub-domain" Type a la the socket?

Could we not replace secmark with "security check points" defining
the "domains" that can come/leave thru (unlabeled_t or such in the
unlabeled case), as well as the default domain to be assigned in
the absence of an explicit domain defined for the packet?

What kind of threats can be handled in secmark that can NOT be
handled in the latter?


> 
> You can certainly create custom iptables secmark rules that label
> packets based on the receiving NIC, and then they would be 
> useful in the
> manner you describe.  But in general, they aren't guaranteed 
> to tell you
> anything about the origin at all.

It would, depending on the network layout correct?

For example, you could treat ALL the traffic to port 80 from a certain
node (not running SELinux) to be in the "domain" mozilla_t, if your
network/system layout/configuration is such that ONLY that kind of traffic
(as opposed to rss_aggregator_t) is assured to come thru that "security
point"
correct?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> > I thin the only real choices are:
> > 1) Add a separate field to the sk_buff for use by labeled 
> networking so
> > that we don't have to overload secmark in this manner, or
> 
> This won't fly upstream.

Do you think the life-cycle management associated with a security
pointer will unacceptable even when we do it ONLY in the
SECURITY_NETWORK case?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Mon, 25 Sep 2006, Venkat Yekkirala wrote:

> > > I thin the only real choices are:
> > > 1) Add a separate field to the sk_buff for use by labeled 
> > networking so
> > > that we don't have to overload secmark in this manner, or
> > 
> > This won't fly upstream.
> 
> Do you think the life-cycle management associated with a security
> pointer will unacceptable even when we do it ONLY in the
> SECURITY_NETWORK case?

Yep, it's been rejected before.


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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Mon, 2006-09-25 at 17:46 -0400, Venkat Yekkirala wrote:
> > But the secmark often tells you nothing about the data origin, or even
> > the way it entered the system, at least as currently employed by
> > refpolicy / netfilter_contexts.  That's my point.
> 
> This is still a little hazy in my mind; as to why secmark is being
> employed this way. What are the kinds of threats this is designed
> to handle?

I think James and/or Chris can answer better, since James designed and
implemented secmark (based in part on the summit discussions) and Chris
has sought to leverage it in refpolicy, but I'll make an attempt below.
James and/or Chris, feel free to correct me or elaborate further.

James Morris originally described secmark in:
http://james-morris.livejournal.com/11010.html

The refpolicy policy and iptables/netfilter rules are based on the
examples there, although there are some differences, like the encoding
of the client or server direction into the type labels so that policy
can permit inbound connections while prohibiting outbound ones or vice
versa (which you don't get from simple send/recv checks).

As currently employed, secmark is effectively labeling packets based on
their functional purpose, and then using policy to limit applications to
least privilege.  Hence, all traffic on an inbound connection to port 80
are classified as http_server_packet_t ("traffic on a connection to a
http server") and httpd_t is allowed to send and recv such traffic.
Meanwhile, all traffic on an outbound connection to port 80 is
classified as http_client_packet_t ("traffic on a connection from a http
client"), and httpd_t is not allowed to send/recv such traffic (unless a
boolean is enabled that indicates that it is supposed to function as a
relay), in an attempt to limit e.g. worm propagation from a compromised
httpd to other httpd daemons.  Meanwhile, if httpd needs to initiate and
communicate on an outbound connection to say a postgres server, it would
be allowed to send/recv packets classified as postgres_client_packet_t
("traffic on a connection from a postgres client").

A few observations:
1) A single domain may be sending and receiving multiple packet types
for different purposes.
2) Multiple domains may be sending the same packet type for the same
purpose.
3) A single packet may have different types on the output side and the
input side.
4) Enforcement is done locally based on local information, not in
cooperation with a peer based on peer information.  This is typical for
iptables/firewall-style restrictions, vs. labeled networking.  We can
for example immediately deny an attempt by httpd_t to send
http_client_packet_t on the sending side, versus deferring enforcement
to the receiver based on the receiving socket label.
5) Despite the lack of outbound vs. inbound connection distinctions in
the permission checks (per-packet send/recv), we are able to allow
outbound without allowing inbound or vice versa based on the packet
types.

> Could we not look at data in transit as sort of an extension of
> the remote socket into the local machine?

In the labeled networking sense, yes.  But secmark as currently
envisioned is rather different - it isn't an extension of the data
origin.

> Could we then not look at the "packet" (as well as any other networking
> element) as a "sub-domain" Type a la the socket?

Ditto.

> Could we not replace secmark with "security check points" defining
> the "domains" that can come/leave thru (unlabeled_t or such in the
> unlabeled case), as well as the default domain to be assigned in
> the absence of an explicit domain defined for the packet?
> 
> What kind of threats can be handled in secmark that can NOT be
> handled in the latter?

Can you provide equivalents to the httpd examples given above using your
model?

> For example, you could treat ALL the traffic to port 80 from a certain
> node (not running SELinux) to be in the "domain" mozilla_t, if your
> network/system layout/configuration is such that ONLY that kind of traffic
> (as opposed to rss_aggregator_t) is assured to come thru that "security
> point"
> correct?

You could treat all traffic to port 80 as having that domain, although
in practice, there can be multiple domains that can act as clients of a
given service (and thus connect to that port), which is why we have the
indirection of a separate packet type that is sent by a domain.  But you
also lose the stateful benefits of secmark here, including the ability
to distinguish inbound vs. outbound.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> > This is still a little hazy in my mind; as to why secmark is being
> > employed this way. What are the kinds of threats this is designed
> > to handle?
> 
> I think James and/or Chris can answer better, since James designed and
> implemented secmark (based in part on the summit discussions) 
> and Chris
> has sought to leverage it in refpolicy, but I'll make an 
> attempt below.
> James and/or Chris, feel free to correct me or elaborate further.
> 
> James Morris originally described secmark in:
> http://james-morris.livejournal.com/11010.html
> 
> The refpolicy policy and iptables/netfilter rules are based on the
> examples there, although there are some differences, like the encoding
> of the client or server direction into the type labels so that policy
> can permit inbound connections while prohibiting outbound ones or vice
> versa (which you don't get from simple send/recv checks).
> 
> As currently employed, secmark is effectively labeling 
> packets based on
> their functional purpose, and then using policy to limit 
> applications to
> least privilege.  Hence, all traffic on an inbound connection 
> to port 80
> are classified as http_server_packet_t ("traffic on a connection to a
> http server") and httpd_t is allowed to send and recv such traffic.
> Meanwhile, all traffic on an outbound connection to port 80 is
> classified as http_client_packet_t ("traffic on a connection 
> from a http
> client"), and httpd_t is not allowed to send/recv such 
> traffic (unless a
> boolean is enabled that indicates that it is supposed to function as a
> relay), in an attempt to limit e.g. worm propagation from a 
> compromised
> httpd to other httpd daemons.  Meanwhile, if httpd needs to 
> initiate and
> communicate on an outbound connection to say a postgres 
> server, it would
> be allowed to send/recv packets classified as postgres_client_packet_t
> ("traffic on a connection from a postgres client").

I see the current use of secmark as directly mappable (as exemplified below)
to the security point paradigm, which I see as being more intuitive
since it's more in line with the "filtering" aspect of iptables. And you
will have also gotten rid of an additional packet object as a distinct
Type, thus making things less complex to that extent.

In the example above, you would have "fine-grained security points"
as given below:

All new connections INTO port 80: http_client_t default domain, with
additional explicit "domains" fire_fox_t, rss_aggregator_t, etc.

allow httpd_t http_client_t:peer { sendto recvfrom }
allow httpd_t fire_fox_t:peer { sendto recvfrom }
...

Now, a compromised httpd_t isn't able initiate OUTGOING connections
to port 80 (other than to itself for graceful shutdown in conjunction
with additional policy).

For connections to postgres:

All new OUTGOING connections from port 80 to postgres-port: postgres_t
default

allow httpd_t postgres_t:peer { sendto recvfrom }

> 
> A few observations:
> 1) A single domain may be sending and receiving multiple packet types
> for different purposes.

A single domain may be sending to and receiving from multiple "domains"
as defined by the "fine grained security check points".

> 2) Multiple domains may be sending the same packet type for the same
> purpose.

Mutiple domains will be allowed to send to the same "security check point".

> 3) A single packet may have different types on the output side and the
> input side.

This is very non-intuitive, as opposed to defining security check points
with just the "domains" that can be received from and sent to.

> 4) Enforcement is done locally based on local information,

This holds true in the "secpoint" case well.

> not in
> cooperation with a peer based on peer information.

No such constraints in the secpoint case. Enforcement is based on the
best available info as driven by policy.

>  This is 
> typical for
> iptables/firewall-style restrictions, vs. labeled networking.

While covering for the "local info, local enforcement model", secpoint
also allows you to "filter" domains that can come in or go out, when
such info is available. Any time you are labeling externally, this is
indeed expected and is very intuitive.

>  We can
> for example immediately deny an attempt by httpd_t to send
> http_client_packet_t on the sending side,

Which is covered by secpoint.

> versus deferring enforcement
> to the receiver based on the receiving socket label.

We aren't deferring it; still enforcing on the sender.

> 5) Despite the lack of outbound vs. inbound connection distinctions in
> the permission checks (per-packet send/recv), we are able to allow
> outbound without allowing inbound or vice versa based on the packet
> types.

Directly mappable to secpoint. You define one secpoint for the inbond
and another for the outbound and allow send/recv as appropriate.

> 
> > Could we not look at data in transit as sort of an extension of
> > the remote socket into the local machine?
> 
> In the labeled networking sense, yes.  But secmark as currently
> envisioned is rather different - it isn't an extension of the data
> origin.

The way I understand/see it: additional complexity for no real benefit.

> 
> > Could we then not look at the "packet" (as well as any 
> other networking
> > element) as a "sub-domain" Type a la the socket?
> 
> Ditto.
> 
> > Could we not replace secmark with "security check points" defining
> > the "domains" that can come/leave thru (unlabeled_t or such in the
> > unlabeled case), as well as the default domain to be assigned in
> > the absence of an explicit domain defined for the packet?
> > 
> > What kind of threats can be handled in secmark that can NOT be
> > handled in the latter?
> 
> Can you provide equivalents to the httpd examples given above 
> using your
> model?

Described above.

> 
> > For example, you could treat ALL the traffic to port 80 
> from a certain
> > node (not running SELinux) to be in the "domain" mozilla_t, if your
> > network/system layout/configuration is such that ONLY that 
> kind of traffic
> > (as opposed to rss_aggregator_t) is assured to come thru 
> that "security
> > point"
> > correct?
> 
> You could treat all traffic to port 80 as having that domain, although
> in practice, there can be multiple domains that can act as 
> clients of a
> given service (and thus connect to that port), which is why 
> we have the
> indirection of a separate packet type that is sent by a 
> domain.

I don't see why the "packet Type" indirection is needed at all.

>  But you
> also lose the stateful benefits of secmark here,

Nope, you still are leveraging the stateful benefits of iptables.

> including the ability
> to distinguish inbound vs. outbound.

Done in the secpoint case as well.

Votes? :)

PS: I have had my routine dose of caffiene, so I believe I am being sane
in the above :)

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

Might I also add that secpoint handles transient "domains" well
in the forwarding case (not handled by secmark).

> -----Original Message-----
> From: Venkat Yekkirala 
> Sent: Tuesday, September 26, 2006 10:51 AM
> To: 'sds@tycho.nsa.gov'
> Cc: Christopher J. PeBenito; Chad Hanson; Karl MacMillan;
> selinux@tycho.nsa.gov; Darrel Goeddel; dwalsh@redhat.com;
> jmorris@redhat.com; latten@austin.ibm.com; Paul Moore; Joshua Brindle
> Subject: RE: Labeled networking packets
> 
> 
> > > This is still a little hazy in my mind; as to why secmark is being
> > > employed this way. What are the kinds of threats this is designed
> > > to handle?
> > 
> > I think James and/or Chris can answer better, since James 
> designed and
> > implemented secmark (based in part on the summit discussions) 
> > and Chris
> > has sought to leverage it in refpolicy, but I'll make an 
> > attempt below.
> > James and/or Chris, feel free to correct me or elaborate further.
> > 
> > James Morris originally described secmark in:
> > http://james-morris.livejournal.com/11010.html
> > 
> > The refpolicy policy and iptables/netfilter rules are based on the
> > examples there, although there are some differences, like 
> the encoding
> > of the client or server direction into the type labels so 
> that policy
> > can permit inbound connections while prohibiting outbound 
> ones or vice
> > versa (which you don't get from simple send/recv checks).
> > 
> > As currently employed, secmark is effectively labeling 
> > packets based on
> > their functional purpose, and then using policy to limit 
> > applications to
> > least privilege.  Hence, all traffic on an inbound connection 
> > to port 80
> > are classified as http_server_packet_t ("traffic on a 
> connection to a
> > http server") and httpd_t is allowed to send and recv such traffic.
> > Meanwhile, all traffic on an outbound connection to port 80 is
> > classified as http_client_packet_t ("traffic on a connection 
> > from a http
> > client"), and httpd_t is not allowed to send/recv such 
> > traffic (unless a
> > boolean is enabled that indicates that it is supposed to 
> function as a
> > relay), in an attempt to limit e.g. worm propagation from a 
> > compromised
> > httpd to other httpd daemons.  Meanwhile, if httpd needs to 
> > initiate and
> > communicate on an outbound connection to say a postgres 
> > server, it would
> > be allowed to send/recv packets classified as 
> postgres_client_packet_t
> > ("traffic on a connection from a postgres client").
> 
> I see the current use of secmark as directly mappable (as 
> exemplified below)
> to the security point paradigm, which I see as being more intuitive
> since it's more in line with the "filtering" aspect of 
> iptables. And you
> will have also gotten rid of an additional packet object as a distinct
> Type, thus making things less complex to that extent.
> 
> In the example above, you would have "fine-grained security points"
> as given below:
> 
> All new connections INTO port 80: http_client_t default domain, with
> additional explicit "domains" fire_fox_t, rss_aggregator_t, etc.
> 
> allow httpd_t http_client_t:peer { sendto recvfrom }
> allow httpd_t fire_fox_t:peer { sendto recvfrom }
> ...
> 
> Now, a compromised httpd_t isn't able initiate OUTGOING connections
> to port 80 (other than to itself for graceful shutdown in conjunction
> with additional policy).
> 
> For connections to postgres:
> 
> All new OUTGOING connections from port 80 to postgres-port: 
> postgres_t default
> 
> allow httpd_t postgres_t:peer { sendto recvfrom }
> 
> > 
> > A few observations:
> > 1) A single domain may be sending and receiving multiple 
> packet types
> > for different purposes.
> 
> A single domain may be sending to and receiving from multiple 
> "domains"
> as defined by the "fine grained security check points".
> 
> > 2) Multiple domains may be sending the same packet type for the same
> > purpose.
> 
> Mutiple domains will be allowed to send to the same "security 
> check point".
> 
> > 3) A single packet may have different types on the output 
> side and the
> > input side.
> 
> This is very non-intuitive, as opposed to defining security 
> check points
> with just the "domains" that can be received from and sent to.
> 
> > 4) Enforcement is done locally based on local information,
> 
> This holds true in the "secpoint" case well.
> 
> > not in
> > cooperation with a peer based on peer information.
> 
> No such constraints in the secpoint case. Enforcement is based on the
> best available info as driven by policy.
> 
> >  This is 
> > typical for
> > iptables/firewall-style restrictions, vs. labeled networking.
> 
> While covering for the "local info, local enforcement model", secpoint
> also allows you to "filter" domains that can come in or go out, when
> such info is available. Any time you are labeling externally, this is
> indeed expected and is very intuitive.
> 
> >  We can
> > for example immediately deny an attempt by httpd_t to send
> > http_client_packet_t on the sending side,
> 
> Which is covered by secpoint.
> 
> > versus deferring enforcement
> > to the receiver based on the receiving socket label.
> 
> We aren't deferring it; still enforcing on the sender.
> 
> > 5) Despite the lack of outbound vs. inbound connection 
> distinctions in
> > the permission checks (per-packet send/recv), we are able to allow
> > outbound without allowing inbound or vice versa based on the packet
> > types.
> 
> Directly mappable to secpoint. You define one secpoint for the inbond
> and another for the outbound and allow send/recv as appropriate.
> 
> > 
> > > Could we not look at data in transit as sort of an extension of
> > > the remote socket into the local machine?
> > 
> > In the labeled networking sense, yes.  But secmark as currently
> > envisioned is rather different - it isn't an extension of the data
> > origin.
> 
> The way I understand/see it: additional complexity for no 
> real benefit.
> 
> > 
> > > Could we then not look at the "packet" (as well as any 
> > other networking
> > > element) as a "sub-domain" Type a la the socket?
> > 
> > Ditto.
> > 
> > > Could we not replace secmark with "security check points" defining
> > > the "domains" that can come/leave thru (unlabeled_t or such in the
> > > unlabeled case), as well as the default domain to be assigned in
> > > the absence of an explicit domain defined for the packet?
> > > 
> > > What kind of threats can be handled in secmark that can NOT be
> > > handled in the latter?
> > 
> > Can you provide equivalents to the httpd examples given above 
> > using your
> > model?
> 
> Described above.
> 
> > 
> > > For example, you could treat ALL the traffic to port 80 
> > from a certain
> > > node (not running SELinux) to be in the "domain" 
> mozilla_t, if your
> > > network/system layout/configuration is such that ONLY that 
> > kind of traffic
> > > (as opposed to rss_aggregator_t) is assured to come thru 
> > that "security
> > > point"
> > > correct?
> > 
> > You could treat all traffic to port 80 as having that 
> domain, although
> > in practice, there can be multiple domains that can act as 
> > clients of a
> > given service (and thus connect to that port), which is why 
> > we have the
> > indirection of a separate packet type that is sent by a 
> > domain.
> 
> I don't see why the "packet Type" indirection is needed at all.
> 
> >  But you
> > also lose the stateful benefits of secmark here,
> 
> Nope, you still are leveraging the stateful benefits of iptables.
> 
> > including the ability
> > to distinguish inbound vs. outbound.
> 
> Done in the secpoint case as well.
> 
> Votes? :)
> 
> PS: I have had my routine dose of caffiene, so I believe I am 
> being sane
> in the above :)
> 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Tue, 2006-09-26 at 11:51 -0400, Venkat Yekkirala wrote:
> Done in the secpoint case as well.
> 
> Votes? :)

Ok, objection to the secid reconciliation patches lifted by me.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Tue, 26 Sep 2006, Venkat Yekkirala wrote:

> In the example above, you would have "fine-grained security points"
> as given below:
> 
> All new connections INTO port 80: http_client_t default domain, with
> additional explicit "domains" fire_fox_t, rss_aggregator_t, etc.
> 
> allow httpd_t http_client_t:peer { sendto recvfrom }
> allow httpd_t fire_fox_t:peer { sendto recvfrom }
> ...
> 
> Now, a compromised httpd_t isn't able initiate OUTGOING connections
> to port 80 (other than to itself for graceful shutdown in conjunction
> with additional policy).
> 
> For connections to postgres:
> 
> All new OUTGOING connections from port 80 to postgres-port: postgres_t
> default
> 
> allow httpd_t postgres_t:peer { sendto recvfrom }

What do the iptables rules look like for this?

> > 3) A single packet may have different types on the output side and the
> > input side.
> 
> This is very non-intuitive, as opposed to defining security check points
> with just the "domains" that can be received from and sent to.

What do the policy and labeling rules look like in this case for secpoint?

> >  But you
> > also lose the stateful benefits of secmark here,
> 
> Nope, you still are leveraging the stateful benefits of iptables.

Ditto.


> Votes? :)

It may seem more intuitive to people combining external and internal 
labeling, but I'm concerned that the common case (internal labeling only) 
will be less understandable.  A security point is an abstraction -- a 
labeled packet is more concrete in that it is an actual kernel object with 
a label on it, which can be manipulated based upon the label.



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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> > In the example above, you would have "fine-grained security points"
> > as given below:
> > 
> > All new connections INTO port 80: http_client_t default domain, with
> > additional explicit "domains" fire_fox_t, rss_aggregator_t, etc.
> > 
> > allow httpd_t http_client_t:peer { sendto recvfrom }
> > allow httpd_t fire_fox_t:peer { sendto recvfrom }
> > ...
> > 
> > Now, a compromised httpd_t isn't able initiate OUTGOING connections
> > to port 80 (other than to itself for graceful shutdown in 
> conjunction
> > with additional policy).
> > 
> > For connections to postgres:
> > 
> > All new OUTGOING connections from port 80 to postgres-port: 
> postgres_t
> > default
> > 
> > allow httpd_t postgres_t:peer { sendto recvfrom }
> 
> What do the iptables rules look like for this?

FOR "INCOMING" CONNECTIONS TO HTTPD (define the client peer):

# Create a chain for connection setup and security point labeling
# for http client peers.
iptables -t mangle -N SEL_HTTP

# Accept incoming connections from, and define and save the security point
for
# http client peers.
iptables -t mangle -A INPUT -p tcp --dport 80 -m state --state NEW -j
SEL_HTTP
iptables -t mangle -A SEL_HTTP -j SECPOINT --selctx
system_u:object_r:http_client_t:s0
iptables -t mangle -A SEL_HTTP -j CONNSECPOINT --save
iptables -t mangle -A SEL_HTTP -j ACCEPT

# Common rules which restore security points for established
# and related packets.
iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j
CONNSECPOINT --restore
iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j
CONNSECPOINT --restore

FOR "OUTGOING" CONNECTIONS TO POSTGRES (define the postgres server peer):

iptables -t mangle -N SEL_PGRESD
iptables -t mangle -A OUTPUT -p tcp --dport <postgres-port> -m state --state
NEW -j SEL_POSTGRESD
iptables -t mangle -A SEL_PGRESD -j SECPOINT --selctx
system_u:object_r:postgresd_t:s0
iptables -t mangle -A SEL_PGRESD -j CONNSECPOINT --save
iptables -t mangle -A SEL_PGRESD -j ACCEPT

On the http clients and the postgres server, you would define the
httpd server peer and the postges client peer respectively, if they
are SELinux machines that is.

On the http server, you would additionally have rules to allow other
client labels such as:

allow firefox_t http_client_t:peer { equiv/from/flow_in }
allow rss_aggregator_t http_client_t:peer { equiv/from/flow_in }

> 
> > > 3) A single packet may have different types on the output 
> side and the
> > > input side.
> > 
> > This is very non-intuitive, as opposed to defining security 
> check points
> > with just the "domains" that can be received from and sent to.
> 
> What do the policy and labeling rules look like in this case 
> for secpoint?

See above.

> 
> > >  But you
> > > also lose the stateful benefits of secmark here,
> > 
> > Nope, you still are leveraging the stateful benefits of iptables.
> 
> Ditto.

Ditto :)

> 
> 
> > Votes? :)
> 
> It may seem more intuitive to people combining external and internal 
> labeling, but I'm concerned that the common case (internal 
> labeling only) 
> will be less understandable.

Looking at the actual rules above, does it appear so?

NOTE: If you meant the loopback traffic, it will reflect the "domain" of
the originating socket.
 
> A security point is an abstraction --

Exactly. And as you note above, abstractions go easy on common people.

> a 
> labeled packet is more concrete in that it is an actual 
> kernel object with 
> a label on it, which can be manipulated based upon the label.

Turns out the "object Type" nature of a packet label doesn't jive
well with the "domain Type" nature of the external labeling mechanisms
that are of interest to us here, apart from the shortcoming of not
being able to handle transient traffic in the forwarding case.

And the purpose of secmark (and more) is being served with secpoint
(ANYONE DISAGREE HERE?; IF SO EXAMPLES?). All made possible by the
secmark field on the skb you hard-earned for us :) Thanks!

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Tue, 26 Sep 2006, Venkat Yekkirala wrote:

> FOR "INCOMING" CONNECTIONS TO HTTPD (define the client peer):
> 
> # Create a chain for connection setup and security point labeling
> # for http client peers.
> iptables -t mangle -N SEL_HTTP
> 
> # Accept incoming connections from, and define and save the security point
> for
> # http client peers.
> iptables -t mangle -A INPUT -p tcp --dport 80 -m state --state NEW -j
> SEL_HTTP
> iptables -t mangle -A SEL_HTTP -j SECPOINT --selctx
> system_u:object_r:http_client_t:s0
> iptables -t mangle -A SEL_HTTP -j CONNSECPOINT --save
> iptables -t mangle -A SEL_HTTP -j ACCEPT
> 
> # Common rules which restore security points for established
> # and related packets.
> iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j
> CONNSECPOINT --restore
> iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j
> CONNSECPOINT --restore
> 
> FOR "OUTGOING" CONNECTIONS TO POSTGRES (define the postgres server peer):
> 
> iptables -t mangle -N SEL_PGRESD
> iptables -t mangle -A OUTPUT -p tcp --dport <postgres-port> -m state --state
> NEW -j SEL_POSTGRESD
> iptables -t mangle -A SEL_PGRESD -j SECPOINT --selctx
> system_u:object_r:postgresd_t:s0
> iptables -t mangle -A SEL_PGRESD -j CONNSECPOINT --save
> iptables -t mangle -A SEL_PGRESD -j ACCEPT

This just seems the same as SECMARK and CONNSECMARK but with different 
naming.  What problem is this solving?

> On the http clients and the postgres server, you would define the
> httpd server peer and the postges client peer respectively, if they
> are SELinux machines that is.
> 
> On the http server, you would additionally have rules to allow other
> client labels such as:
> 
> allow firefox_t http_client_t:peer { equiv/from/flow_in }
> allow rss_aggregator_t http_client_t:peer { equiv/from/flow_in }

I don't think this is helping with usability.  I'm not even sure what the 
above means.

> > It may seem more intuitive to people combining external and internal 
> > labeling, but I'm concerned that the common case (internal 
> > labeling only) 
> > will be less understandable.
> 
> Looking at the actual rules above, does it appear so?

Not to me.

> Turns out the "object Type" nature of a packet label doesn't jive
> well with the "domain Type" nature of the external labeling mechanisms
> that are of interest to us here, apart from the shortcoming of not
> being able to handle transient traffic in the forwarding case.

I don't see why the packet can't be thought of as carrying the label of 
the originating process.


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Tue, 2006-09-26 at 18:43 -0400, James Morris wrote:
> On Tue, 26 Sep 2006, Venkat Yekkirala wrote:
> 
> > FOR "INCOMING" CONNECTIONS TO HTTPD (define the client peer):
> > 
> > # Create a chain for connection setup and security point labeling
> > # for http client peers.
> > iptables -t mangle -N SEL_HTTP
> > 
> > # Accept incoming connections from, and define and save the security point
> > for
> > # http client peers.
> > iptables -t mangle -A INPUT -p tcp --dport 80 -m state --state NEW -j
> > SEL_HTTP
> > iptables -t mangle -A SEL_HTTP -j SECPOINT --selctx
> > system_u:object_r:http_client_t:s0
> > iptables -t mangle -A SEL_HTTP -j CONNSECPOINT --save
> > iptables -t mangle -A SEL_HTTP -j ACCEPT
> > 
> > # Common rules which restore security points for established
> > # and related packets.
> > iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j
> > CONNSECPOINT --restore
> > iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j
> > CONNSECPOINT --restore
> > 
> > FOR "OUTGOING" CONNECTIONS TO POSTGRES (define the postgres server peer):
> > 
> > iptables -t mangle -N SEL_PGRESD
> > iptables -t mangle -A OUTPUT -p tcp --dport <postgres-port> -m state --state
> > NEW -j SEL_POSTGRESD
> > iptables -t mangle -A SEL_PGRESD -j SECPOINT --selctx
> > system_u:object_r:postgresd_t:s0
> > iptables -t mangle -A SEL_PGRESD -j CONNSECPOINT --save
> > iptables -t mangle -A SEL_PGRESD -j ACCEPT
> 
> This just seems the same as SECMARK and CONNSECMARK but with different 
> naming.  What problem is this solving?

The name isn't important (Venkat just views the "secpoint" and "peer"
names as more intuitive).  The issue is how we label the packets -
Venkat is assigning labels that correspond to domains (potentially
generic placeholder domains when we don't actually know a specific one),
like http_client_t (or mozilla_t) and httpd_t versus object types like
http_client_packet_t and http_server_packet_t.

We could leave the secmark and packet names alone.

> > On the http clients and the postgres server, you would define the
> > httpd server peer and the postges client peer respectively, if they
> > are SELinux machines that is.
> > 
> > On the http server, you would additionally have rules to allow other
> > client labels such as:
> > 
> > allow firefox_t http_client_t:peer { equiv/from/flow_in }
> > allow rss_aggregator_t http_client_t:peer { equiv/from/flow_in }
> 
> I don't think this is helping with usability.  I'm not even sure what the 
> above means.
> 
> > > It may seem more intuitive to people combining external and internal 
> > > labeling, but I'm concerned that the common case (internal 
> > > labeling only) 
> > > will be less understandable.
> > 
> > Looking at the actual rules above, does it appear so?
> 
> Not to me.
> 
> > Turns out the "object Type" nature of a packet label doesn't jive
> > well with the "domain Type" nature of the external labeling mechanisms
> > that are of interest to us here, apart from the shortcoming of not
> > being able to handle transient traffic in the forwarding case.
> 
> I don't see why the packet can't be thought of as carrying the label of 
> the originating process.


-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Joshua Brindle]

Stephen Smalley wrote:
>
> On Tue, 2006-09-26 at 18:43 -0400, James Morris wrote:
> > On Tue, 26 Sep 2006, Venkat Yekkirala wrote:
> >
> > > FOR "INCOMING" CONNECTIONS TO HTTPD (define the client peer):
> > >
> > > # Create a chain for connection setup and security point labeling
> > > # for http client peers.
> > > iptables -t mangle -N SEL_HTTP
> > >
> > > # Accept incoming connections from, and define and save the 
> security point
> > > for
> > > # http client peers.
> > > iptables -t mangle -A INPUT -p tcp --dport 80 -m state --state NEW -j
> > > SEL_HTTP
> > > iptables -t mangle -A SEL_HTTP -j SECPOINT --selctx
> > > system_u:object_r:http_client_t:s0
> > > iptables -t mangle -A SEL_HTTP -j CONNSECPOINT --save
> > > iptables -t mangle -A SEL_HTTP -j ACCEPT
> > >
> > > # Common rules which restore security points for established
> > > # and related packets.
> > > iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j
> > > CONNSECPOINT --restore
> > > iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j
> > > CONNSECPOINT --restore
> > >
> > > FOR "OUTGOING" CONNECTIONS TO POSTGRES (define the postgres server 
> peer):
> > >
> > > iptables -t mangle -N SEL_PGRESD
> > > iptables -t mangle -A OUTPUT -p tcp --dport <postgres-port> -m 
> state --state
> > > NEW -j SEL_POSTGRESD
> > > iptables -t mangle -A SEL_PGRESD -j SECPOINT --selctx
> > > system_u:object_r:postgresd_t:s0
> > > iptables -t mangle -A SEL_PGRESD -j CONNSECPOINT --save
> > > iptables -t mangle -A SEL_PGRESD -j ACCEPT
> >
> > This just seems the same as SECMARK and CONNSECMARK but with different
> > naming.  What problem is this solving?
>
> The name isn't important (Venkat just views the "secpoint" and "peer"
> names as more intuitive).  The issue is how we label the packets -
> Venkat is assigning labels that correspond to domains (potentially
> generic placeholder domains when we don't actually know a specific one),
> like http_client_t (or mozilla_t) and httpd_t versus object types like
> http_client_packet_t and http_server_packet_t.
>
> We could leave the secmark and packet names alone.
>
I'd rather change the packet name as that could lead to some serious 
confusion when reconciliation happens. "packet" has a connotation of 
being a discrete visible thing so overriding its label with something 
more abstract (eg., an ipsec tunnel) will be confusing. Since "peer" is 
a more abstract object it can, more understandably, represent more than 
1 kind of network labeling.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Stephen Smalley]

On Wed, 2006-09-27 at 08:40 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> >
> > On Tue, 2006-09-26 at 18:43 -0400, James Morris wrote:
> > > On Tue, 26 Sep 2006, Venkat Yekkirala wrote:
> > >
> > > > FOR "INCOMING" CONNECTIONS TO HTTPD (define the client peer):
> > > >
> > > > # Create a chain for connection setup and security point labeling
> > > > # for http client peers.
> > > > iptables -t mangle -N SEL_HTTP
> > > >
> > > > # Accept incoming connections from, and define and save the 
> > security point
> > > > for
> > > > # http client peers.
> > > > iptables -t mangle -A INPUT -p tcp --dport 80 -m state --state NEW -j
> > > > SEL_HTTP
> > > > iptables -t mangle -A SEL_HTTP -j SECPOINT --selctx
> > > > system_u:object_r:http_client_t:s0
> > > > iptables -t mangle -A SEL_HTTP -j CONNSECPOINT --save
> > > > iptables -t mangle -A SEL_HTTP -j ACCEPT
> > > >
> > > > # Common rules which restore security points for established
> > > > # and related packets.
> > > > iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j
> > > > CONNSECPOINT --restore
> > > > iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j
> > > > CONNSECPOINT --restore
> > > >
> > > > FOR "OUTGOING" CONNECTIONS TO POSTGRES (define the postgres server 
> > peer):
> > > >
> > > > iptables -t mangle -N SEL_PGRESD
> > > > iptables -t mangle -A OUTPUT -p tcp --dport <postgres-port> -m 
> > state --state
> > > > NEW -j SEL_POSTGRESD
> > > > iptables -t mangle -A SEL_PGRESD -j SECPOINT --selctx
> > > > system_u:object_r:postgresd_t:s0
> > > > iptables -t mangle -A SEL_PGRESD -j CONNSECPOINT --save
> > > > iptables -t mangle -A SEL_PGRESD -j ACCEPT
> > >
> > > This just seems the same as SECMARK and CONNSECMARK but with different
> > > naming.  What problem is this solving?
> >
> > The name isn't important (Venkat just views the "secpoint" and "peer"
> > names as more intuitive).  The issue is how we label the packets -
> > Venkat is assigning labels that correspond to domains (potentially
> > generic placeholder domains when we don't actually know a specific one),
> > like http_client_t (or mozilla_t) and httpd_t versus object types like
> > http_client_packet_t and http_server_packet_t.
> >
> > We could leave the secmark and packet names alone.
> >
> I'd rather change the packet name as that could lead to some serious 
> confusion when reconciliation happens. "packet" has a connotation of 
> being a discrete visible thing so overriding its label with something 
> more abstract (eg., an ipsec tunnel) will be confusing. Since "peer" is 
> a more abstract object it can, more understandably, represent more than 
> 1 kind of network labeling.

Sorry, I don't see that.  There is a discrete visible object here (the
sk_buff), and it isn't truly a "peer", even if it is propagating the
peer's information.  "packet" is no less applicable to all forms of
network labeling than "peer".  "peer" is also confusing in the datagram
case, as peer usually suggests the remote endpoint of a (stream)
connection.  And changing the names means a lot of useless busy work
when there is plenty of real work to be done.
  
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Wed, 27 Sep 2006, Stephen Smalley wrote:

> > This just seems the same as SECMARK and CONNSECMARK but with different 
> > naming.  What problem is this solving?
> 
> The name isn't important (Venkat just views the "secpoint" and "peer"
> names as more intuitive).  The issue is how we label the packets -
> Venkat is assigning labels that correspond to domains (potentially
> generic placeholder domains when we don't actually know a specific one),
> like http_client_t (or mozilla_t) and httpd_t versus object types like
> http_client_packet_t and http_server_packet_t.
> 
> We could leave the secmark and packet names alone.

Certainly, changing the iptables target names would be highly intrusive.  

And for internal labeling only, it still seems correct to me that packets 
are being labeled.

> > > On the http clients and the postgres server, you would define the
> > > httpd server peer and the postges client peer respectively, if they
> > > are SELinux machines that is.
> > > 
> > > On the http server, you would additionally have rules to allow other
> > > client labels such as:
> > > 
> > > allow firefox_t http_client_t:peer { equiv/from/flow_in }
> > > allow rss_aggregator_t http_client_t:peer { equiv/from/flow_in }
> > 
> > I don't think this is helping with usability.  I'm not even sure what the 
> > above means.

The above still hasn't been addressed.  I understood the earlier flow 
permissions, but what is equiv and from?

Please translate the rules into English.

> > > Turns out the "object Type" nature of a packet label doesn't jive
> > > well with the "domain Type" nature of the external labeling mechanisms
> > > that are of interest to us here, apart from the shortcoming of not
> > > being able to handle transient traffic in the forwarding case.
> > 
> > I don't see why the packet can't be thought of as carrying the label of 
> > the originating process.




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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled networking packets

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2006-09-27 at 08:40 -0400, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Tue, 2006-09-26 at 18:43 -0400, James Morris wrote:
>>>       
>>>> On Tue, 26 Sep 2006, Venkat Yekkirala wrote:
>>>>
>>>>         
>>>>> FOR "INCOMING" CONNECTIONS TO HTTPD (define the client peer):
>>>>>
>>>>> # Create a chain for connection setup and security point labeling
>>>>> # for http client peers.
>>>>> iptables -t mangle -N SEL_HTTP
>>>>>
>>>>> # Accept incoming connections from, and define and save the 
>>>>>           
>>> security point
>>>       
>>>>> for
>>>>> # http client peers.
>>>>> iptables -t mangle -A INPUT -p tcp --dport 80 -m state --state NEW -j
>>>>> SEL_HTTP
>>>>> iptables -t mangle -A SEL_HTTP -j SECPOINT --selctx
>>>>> system_u:object_r:http_client_t:s0
>>>>> iptables -t mangle -A SEL_HTTP -j CONNSECPOINT --save
>>>>> iptables -t mangle -A SEL_HTTP -j ACCEPT
>>>>>
>>>>> # Common rules which restore security points for established
>>>>> # and related packets.
>>>>> iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j
>>>>> CONNSECPOINT --restore
>>>>> iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j
>>>>> CONNSECPOINT --restore
>>>>>
>>>>> FOR "OUTGOING" CONNECTIONS TO POSTGRES (define the postgres server 
>>>>>           
>>> peer):
>>>       
>>>>> iptables -t mangle -N SEL_PGRESD
>>>>> iptables -t mangle -A OUTPUT -p tcp --dport <postgres-port> -m 
>>>>>           
>>> state --state
>>>       
>>>>> NEW -j SEL_POSTGRESD
>>>>> iptables -t mangle -A SEL_PGRESD -j SECPOINT --selctx
>>>>> system_u:object_r:postgresd_t:s0
>>>>> iptables -t mangle -A SEL_PGRESD -j CONNSECPOINT --save
>>>>> iptables -t mangle -A SEL_PGRESD -j ACCEPT
>>>>>           
>>>> This just seems the same as SECMARK and CONNSECMARK but with different
>>>> naming.  What problem is this solving?
>>>>         
>>> The name isn't important (Venkat just views the "secpoint" and "peer"
>>> names as more intuitive).  The issue is how we label the packets -
>>> Venkat is assigning labels that correspond to domains (potentially
>>> generic placeholder domains when we don't actually know a specific one),
>>> like http_client_t (or mozilla_t) and httpd_t versus object types like
>>> http_client_packet_t and http_server_packet_t.
>>>
>>> We could leave the secmark and packet names alone.
>>>
>>>       
>> I'd rather change the packet name as that could lead to some serious 
>> confusion when reconciliation happens. "packet" has a connotation of 
>> being a discrete visible thing so overriding its label with something 
>> more abstract (eg., an ipsec tunnel) will be confusing. Since "peer" is 
>> a more abstract object it can, more understandably, represent more than 
>> 1 kind of network labeling.
>>     
>
> Sorry, I don't see that.  There is a discrete visible object here (the
> sk_buff), and it isn't truly a "peer", even if it is propagating the
> peer's information.  "packet" is no less applicable to all forms of
> network labeling than "peer".  "peer" is also confusing in the datagram
> case, as peer usually suggests the remote endpoint of a (stream)
> connection.  And changing the names means a lot of useless busy work
> when there is plenty of real work to be done.
>   
>   
I'm talking about the users perspective, packet is alot more 'tangible' 
than peer. Doesn't matter much though, as long as there is something to 
explain it to users.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Stephen Smalley]

On Wed, 2006-09-27 at 08:59 -0400, James Morris wrote:
> Certainly, changing the iptables target names would be highly intrusive.  
> 
> And for internal labeling only, it still seems correct to me that packets 
> are being labeled.

Yes, I don't see any real reason to rename them.

> > > > On the http clients and the postgres server, you would define the
> > > > httpd server peer and the postges client peer respectively, if they
> > > > are SELinux machines that is.
> > > > 
> > > > On the http server, you would additionally have rules to allow other
> > > > client labels such as:
> > > > 
> > > > allow firefox_t http_client_t:peer { equiv/from/flow_in }
> > > > allow rss_aggregator_t http_client_t:peer { equiv/from/flow_in }
> > > 
> > > I don't think this is helping with usability.  I'm not even sure what the 
> > > above means.
> 
> The above still hasn't been addressed.  I understood the earlier flow 
> permissions, but what is equiv and from?

My impression was that he was just offering up alternative names for the
flow_in permission.  Which likewise doesn't really need to be renamed.

In short, nothing really changes from the earlier secid reconciliation
patches except for dealing with your earlier comments.  And then we also
need the other patches mentioned in that thread, like labeling the SAs
from the socket rather than the spd so that we no longer need per-domain
spd rules, and setting the peer sid on TCP sockets to the reconciled
secmark.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joy Latten]

>In short, nothing really changes from the earlier secid reconciliation
>patches except for dealing with your earlier comments.  And then we also
>need the other patches mentioned in that thread, like labeling the SAs
>from the socket rather than the spd so that we no longer need per-domain
>spd rules, and setting the peer sid on TCP sockets to the reconciled
>secmark.

I need to clarify a few things to determine whether I need to 
modify racoon's code. 
Since we will label SAs from socket rather than from spd, do 
we still need to check SA's label against spd's label? 
If not, do we still need spd to contain a label?

Also, I am not very clear how the local and remote racoons will
negotiate the labels. Initiator sends over security context from
socket... how does Remote side negotiate or determine it is 
valid or acceptable to him?

Regards,
Joy



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> >In short, nothing really changes from the earlier secid 
> reconciliation
> >patches except for dealing with your earlier comments.  And 
> then we also
> >need the other patches mentioned in that thread, like 
> labeling the SAs
> >from the socket rather than the spd so that we no longer 
> need per-domain
> >spd rules, and setting the peer sid on TCP sockets to the reconciled
> >secmark.
> 
> I need to clarify a few things to determine whether I need to 
> modify racoon's code. 
> Since we will label SAs from socket rather than from spd, do 
> we still need to check SA's label against spd's label? 

Yes. This way we can control what "domains" would use (un)labeled
IPSec. These domains would "polmatch" to the spd label in the policy.

> If not, do we still need spd to contain a label?

Regardless an spd needn't contain a label; e.g.: you don't want to
export the domain with the data; in this case you would use unlabeled
IPSec; the domain would then have to polmatch to "unlabeled_t".

> 
> Also, I am not very clear how the local and remote racoons will
> negotiate the labels. Initiator sends over security context from
> socket... how does Remote side negotiate or determine it is 
> valid or acceptable to him?

racoon on the remote side will make sure the domain sent by the
Initiator polmatches a policy on its (repsonder's) side, before
responding. This should be already happening, so I don't envision
any changes to racoon because of the change in the kernel. racoon
will be just dealing with a different context received from the
kernel, that's all.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Wed, 27 Sep 2006, Stephen Smalley wrote:

> In short, nothing really changes from the earlier secid reconciliation
> patches except for dealing with your earlier comments.  And then we also
> need the other patches mentioned in that thread, like labeling the SAs
> from the socket rather than the spd so that we no longer need per-domain
> spd rules, and setting the peer sid on TCP sockets to the reconciled
> secmark.

In terms of need, it may be useful if someone could distinguish what is 
required for LSPP cert and for a full implementation, given that we are on 
a very short lead for the cert.


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[James Morris]

On Wed, 27 Sep 2006, Stephen Smalley wrote:

> My impression was that he was just offering up alternative names for the
> flow_in permission.  Which likewise doesn't really need to be renamed.

Ok, Venkat, please don't rename the iptables matches or the object classes 
or the permissions.


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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Joy Latten]

>> >In short, nothing really changes from the earlier secid 
>> reconciliation
>> >patches except for dealing with your earlier comments.  And 
>> then we also
>> >need the other patches mentioned in that thread, like 
>> labeling the SAs
>> >from the socket rather than the spd so that we no longer 
>> need per-domain
>> >spd rules, and setting the peer sid on TCP sockets to the reconciled
>> >secmark.
>> 
>> I need to clarify a few things to determine whether I need to 
>> modify racoon's code. 
>> Since we will label SAs from socket rather than from spd, do 
>> we still need to check SA's label against spd's label? 
>
>Yes. This way we can control what "domains" would use (un)labeled
>IPSec. These domains would "polmatch" to the spd label in the policy.
>
>> If not, do we still need spd to contain a label?
>
>Regardless an spd needn't contain a label; e.g.: you don't want to
>export the domain with the data; in this case you would use unlabeled
>IPSec; the domain would then have to polmatch to "unlabeled_t".
>
>> 
>> Also, I am not very clear how the local and remote racoons will
>> negotiate the labels. Initiator sends over security context from
>> socket... how does Remote side negotiate or determine it is 
>> valid or acceptable to him?
>
>racoon on the remote side will make sure the domain sent by the
>Initiator polmatches a policy on its (repsonder's) side, before
>responding. This should be already happening, so I don't envision
>any changes to racoon because of the change in the kernel. racoon
>will be just dealing with a different context received from the
>kernel, that's all.

Ok, thanks. I get it now. 
Venkat, let me know if there is anything I can 
do to help out with this portion, for example
any coding. 

Regards,
Joy

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Labeled networking packets

[Venkat Yekkirala]

> Ok, thanks. I get it now. 
> Venkat, let me know if there is anything I can 
> do to help out with this portion, for example
> any coding. 

nah. The documentation you are working on for this is crucial enough...

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