generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

Stephen Smalley wrote:
> On Thu, 2007-05-31 at 10:58 -0500, Joe Nall wrote:
>> I would like to label an ethernet interface so that all of the  
>> inbound connections are labeled with a range.
>>
>> semanage interface -a -t netif_t --range S-S eth1
>>
>> succeeds, but getpeercon fails with "Protocol not available"
>>
>> Is there any way to do this with what is in evaluation?
> 
> getpeercon() only returns a context if a labeled networking mechanism
> was used; we don't implicitly convey the netif label or secmark label to
> it.  So if you want a default labeling behavior, that has to be done in
> your application, e.g. the application would fall back to some default
> if getpeercon() failed.

Stephen,

How do you think necessity for generic fall back behavior in the case when
getpeercon() failed?

I think such a falling-back labeling behavior is worthwhile for appliablity
of SE-PostgreSQL, because RDBMS will be connected from MS-Windows'ed clients
which are impossible to set up network labeling, for example.

The current version of SE-PostgreSQL adopts the simplest way to handle
a connection from a client without any network labeling. Its connection
will be closed soon.

I got a question and a suggestion about SE-PostgreSQL's behavior in those cases
just after my speech in this year's SELinux Symposium.
He suggested me that it is possible to associate a security context and network
interfaces or network address/port.
For example, RDBMS server has two NIC. One is connected to internal network and
connections from there are defined as SystemLow-SystemHigh, the other is connected
to external network and defined as SystemLow, like the following image.

SystemLow-SystemHigh +--------+      SystemLow
            --> eth0 |SE-PgSQL| eth1 <---
---------------------= server =---------------
            INTERNAL +--------+ EXTERNAL

I think his suggestion is fair enough as a fall back of getpeercon(),
but we don't have any consensus.

Is it really necessary?
 - At least, I think the facility is worthwhile.

How is it implemented and described in the policy?
 - Is it possible to use the security context of netif/address/port of inbound
   connection as an entrypoint of domain transition?
   Those may be configurable with SECMARK.

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

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

Re: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

> For example, RDBMS server has two NIC. One is connected to internal network and
> connections from there are defined as SystemLow-SystemHigh, the other is connected
> to external network and defined as SystemLow, like the following image.
> 
> SystemLow-SystemHigh +--------+      SystemLow
>             --> eth0 |SE-PgSQL| eth1 <---
> ---------------------= server =---------------
>             INTERNAL +--------+ EXTERNAL

I drew an illustration to help my explanation.
  http://kaigai.sblo.jp/article/4247935.html

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

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

Re: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Stephen Smalley]

On Sun, 2007-06-03 at 02:46 +0900, KaiGai Kohei wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-05-31 at 10:58 -0500, Joe Nall wrote:
> >> I would like to label an ethernet interface so that all of the  
> >> inbound connections are labeled with a range.
> >>
> >> semanage interface -a -t netif_t --range S-S eth1
> >>
> >> succeeds, but getpeercon fails with "Protocol not available"
> >>
> >> Is there any way to do this with what is in evaluation?
> > 
> > getpeercon() only returns a context if a labeled networking mechanism
> > was used; we don't implicitly convey the netif label or secmark label to
> > it.  So if you want a default labeling behavior, that has to be done in
> > your application, e.g. the application would fall back to some default
> > if getpeercon() failed.
> 
> Stephen,
> 
> How do you think necessity for generic fall back behavior in the case when
> getpeercon() failed?

I think it would be useful.  There was some discussion of it during the
labeled networking discussions, but directly returning the secmark label
or the netif/netmsg labels was viewed as problematic because they aren't
peer/process contexts.

> I think such a falling-back labeling behavior is worthwhile for appliablity
> of SE-PostgreSQL, because RDBMS will be connected from MS-Windows'ed clients
> which are impossible to set up network labeling, for example.
> 
> The current version of SE-PostgreSQL adopts the simplest way to handle
> a connection from a client without any network labeling. Its connection
> will be closed soon.

X has a more graceful fallback, per Eamon - it defines a
nonlocal_context in its own config and uses that as the default if
getpeercon fails.

> I got a question and a suggestion about SE-PostgreSQL's behavior in those cases
> just after my speech in this year's SELinux Symposium.
> He suggested me that it is possible to associate a security context and network
> interfaces or network address/port.
> For example, RDBMS server has two NIC. One is connected to internal network and
> connections from there are defined as SystemLow-SystemHigh, the other is connected
> to external network and defined as SystemLow, like the following image.
> 
> SystemLow-SystemHigh +--------+      SystemLow
>             --> eth0 |SE-PgSQL| eth1 <---
> ---------------------= server =---------------
>             INTERNAL +--------+ EXTERNAL
> 
> I think his suggestion is fair enough as a fall back of getpeercon(),
> but we don't have any consensus.
> 
> Is it really necessary?
>  - At least, I think the facility is worthwhile.

Yes, I think it would be worthwhile.

> How is it implemented and described in the policy?
>  - Is it possible to use the security context of netif/address/port of inbound
>    connection as an entrypoint of domain transition?
>    Those may be configurable with SECMARK.

You can already define a netif (and a netmsg) context in policy and
manipulate them via semanage_iface(3) in userland.  We don't presently
have a way to convey the netif or netmsg context (or secmark label) to
userland from the kernel.  There was some discussion of a separate
getdatacon(3) and equivalent for SCM_SECURITY to convey a "data context"
separate from the "peer context", but that doesn't exist yet and would
take some work in the kernel.

It wouldn't be difficult to modify libselinux getpeercon(3) and/or
introduce a new higher level interface in libselinux that queries policy
in some manner and obtains a default if the underlying kernel interface
cannot provide a context.

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Monday, June 4 2007 10:17:00 am Stephen Smalley wrote:
> On Sun, 2007-06-03 at 02:46 +0900, KaiGai Kohei wrote:
> > Stephen Smalley wrote:
> > > On Thu, 2007-05-31 at 10:58 -0500, Joe Nall wrote:
> > >> I would like to label an ethernet interface so that all of the
> > >> inbound connections are labeled with a range.
> > >>
> > >> semanage interface -a -t netif_t --range S-S eth1
> > >>
> > >> succeeds, but getpeercon fails with "Protocol not available"
> > >>
> > >> Is there any way to do this with what is in evaluation?
> > >
> > > getpeercon() only returns a context if a labeled networking mechanism
> > > was used; we don't implicitly convey the netif label or secmark label
> > > to it.  So if you want a default labeling behavior, that has to be done
> > > in your application, e.g. the application would fall back to some
> > > default if getpeercon() failed.
> >
> > Stephen,
> >
> > How do you think necessity for generic fall back behavior in the case
> > when getpeercon() failed?
>
> I think it would be useful.  There was some discussion of it during the
> labeled networking discussions, but directly returning the secmark label
> or the netif/netmsg labels was viewed as problematic because they aren't
> peer/process contexts.

Just a heads-up, I hope to start working some patches for this in a few weeks 
time.  The basic idea is to assign fallback contexts to interfaces and/or 
network addresses that would be used as the external packet label when one 
was not present.

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

>> How do you think necessity for generic fall back behavior in the case when
>> getpeercon() failed?
> 
> I think it would be useful.  There was some discussion of it during the
> labeled networking discussions, but directly returning the secmark label
> or the netif/netmsg labels was viewed as problematic because they aren't
> peer/process contexts.

I agree the conclusion. Those labels don't represent domain's one.
But I think that using them an entrypoint of domain transition is
a considerable idea, like this:
  type_transition postgresql_t untrusted_network_t : packet sepgsql_client_t;
  type_transition ftpd_t untrusted_network_t : packet ftpd_client_t;

Is it different from Paul's idea, isn't it?
In my understanding, he intends to associate a domain's context directly with
network interfaces and/or network addresses.

If corrent, I have a question.
Is it possible to distinguish the fallback context for each server domain?
For example, when we want to label clients connected from unlabeled network
as 'sepgsql_unlabeled_client_t', how does the other server handle them?

>> The current version of SE-PostgreSQL adopts the simplest way to handle
>> a connection from a client without any network labeling. Its connection
>> will be closed soon.
> 
> X has a more graceful fallback, per Eamon - it defines a
> nonlocal_context in its own config and uses that as the default if
> getpeercon fails.

It is possible to implement similar fallbacks in SE-PostgreSQL, of course.
But we should obtain fallback context sourced from security policy, if possible.

>> How is it implemented and described in the policy?
>>  - Is it possible to use the security context of netif/address/port of inbound
>>    connection as an entrypoint of domain transition?
>>    Those may be configurable with SECMARK.
> 
> You can already define a netif (and a netmsg) context in policy and
> manipulate them via semanage_iface(3) in userland.  We don't presently
> have a way to convey the netif or netmsg context (or secmark label) to
> userland from the kernel.  There was some discussion of a separate
> getdatacon(3) and equivalent for SCM_SECURITY to convey a "data context"
> separate from the "peer context", but that doesn't exist yet and would
> take some work in the kernel.

I believe that secmark label is the easiest to manage.
If we need the facility, I'll post a patch. :)

At first, I like to see the detail of Paul's idea.

Thanks,

> It wouldn't be difficult to modify libselinux getpeercon(3) and/or
> introduce a new higher level interface in libselinux that queries policy
> in some manner and obtains a default if the underlying kernel interface
> cannot provide a 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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Tuesday 05 June 2007 11:12:13 pm KaiGai Kohei wrote:
> >> How do you think necessity for generic fall back behavior in the case
> >> when getpeercon() failed?
> >
> > I think it would be useful.  There was some discussion of it during the
> > labeled networking discussions, but directly returning the secmark label
> > or the netif/netmsg labels was viewed as problematic because they aren't
> > peer/process contexts.
>
> I agree the conclusion. Those labels don't represent domain's one.
> But I think that using them an entrypoint of domain transition is
> a considerable idea, like this:
>   type_transition postgresql_t untrusted_network_t : packet
>     sepgsql_client_t;
>   type_transition ftpd_t untrusted_network_t : packet 
>     ftpd_client_t;

There was a discussion about using packet type transitions before, although it 
was slightly different than what you are proposing here.  The basic idea was 
to reconcile both the "internal" and "external" packet labels into a single 
label using type transitions.  In the end it became to complex to write sane 
policy so the idea was dropped.

Your proposal is slightly different in that I view it more as a per-domain 
renaming scheme where you rename/relabel packets based on the receiving 
domain.  Can you help me understand the advantage of 
renaming "untrusted_network_t" to "sepgsql_client_t" from a policy point of 
view?  For example, how would these two policy rules be different or have any 
advantage over one another:

 allow sepgsql_t untrusted_network_t:<class> <perms>;
 allow sepgsql_t sepgsql_client_t:<class> <perms>:

Also, if it is decided that this idea does have merit and is worth 
implementing I see it as being complimentary, and not mutually exclusive, to 
static labeling of unlabeled hosts/networks.

> Is it different from Paul's idea, isn't it?
> In my understanding, he intends to associate a domain's context directly
> with network interfaces and/or network addresses.

Yes, that is correct.  It is similar to how existing trusted OSs provide 
connection/packet labels for unlabeled hosts/networks.

> If corrent, I have a question.
> Is it possible to distinguish the fallback context for each server domain?

Anything is possible, but that is not how I am currently intending to 
implement the functionality.  Once again, since these are static labels, what 
advantage is there to doing this individually for each receiving domain?

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Venkat Yekkirala]

> Your proposal is slightly different in that I view it more as 
> a per-domain 
> renaming scheme where you rename/relabel packets based on the 
> receiving 
> domain.  Can you help me understand the advantage of 
> renaming "untrusted_network_t" to "sepgsql_client_t" from a 
> policy point of 
> view?  For example, how would these two policy rules be 
> different or have any 
> advantage over one another:
> 
>  allow sepgsql_t untrusted_network_t:<class> <perms>;
>  allow sepgsql_t sepgsql_client_t:<class> <perms>:

I doubt that the intent here is to change the permission checks
to use the transition label. Rather the idea seems to be to
have getpeercon() return the transition label (sepgsql_client_t).

Coincidentally we (Darrel, Chad and myself) were talking about this
and it seems like a good idea.

--
This message was distributed to subscribers of the selinux mailing list.
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Wednesday, June 6 2007 9:38:10 am Venkat Yekkirala wrote:
> > Your proposal is slightly different in that I view it more as
> > a per-domain
> > renaming scheme where you rename/relabel packets based on the
> > receiving
> > domain.  Can you help me understand the advantage of
> > renaming "untrusted_network_t" to "sepgsql_client_t" from a
> > policy point of
> > view?  For example, how would these two policy rules be
> > different or have any
> > advantage over one another:
> >
> >  allow sepgsql_t untrusted_network_t:<class> <perms>;
> >  allow sepgsql_t sepgsql_client_t:<class> <perms>:
>
> I doubt that the intent here is to change the permission checks
> to use the transition label. Rather the idea seems to be to
> have getpeercon() return the transition label (sepgsql_client_t).

My gut feeling is that getpeercon() should return the same context that we use 
for permission checks.  If getpeercon() returns something different I fear it 
could start to get very confusing from a user's/policy-writer's point of 
view.  Then again, maybe it's just me.

Perhaps Chris, Dan, and Stephen have some thought on this ...

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Stephen Smalley]

On Wed, 2007-06-06 at 09:47 -0400, Paul Moore wrote:
> On Wednesday, June 6 2007 9:38:10 am Venkat Yekkirala wrote:
> > > Your proposal is slightly different in that I view it more as
> > > a per-domain
> > > renaming scheme where you rename/relabel packets based on the
> > > receiving
> > > domain.  Can you help me understand the advantage of
> > > renaming "untrusted_network_t" to "sepgsql_client_t" from a
> > > policy point of
> > > view?  For example, how would these two policy rules be
> > > different or have any
> > > advantage over one another:
> > >
> > >  allow sepgsql_t untrusted_network_t:<class> <perms>;
> > >  allow sepgsql_t sepgsql_client_t:<class> <perms>:
> >
> > I doubt that the intent here is to change the permission checks
> > to use the transition label. Rather the idea seems to be to
> > have getpeercon() return the transition label (sepgsql_client_t).
> 
> My gut feeling is that getpeercon() should return the same context that we use 
> for permission checks.  If getpeercon() returns something different I fear it 
> could start to get very confusing from a user's/policy-writer's point of 
> view.  Then again, maybe it's just me.

Correct - we want to be able to analyze policy based solely on the allow
rules.

> Perhaps Chris, Dan, and Stephen have some thought on this ...


-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

Venkat Yekkirala wrote:
>> Your proposal is slightly different in that I view it more as 
>> a per-domain 
>> renaming scheme where you rename/relabel packets based on the 
>> receiving 
>> domain.  Can you help me understand the advantage of 
>> renaming "untrusted_network_t" to "sepgsql_client_t" from a 
>> policy point of 
>> view?  For example, how would these two policy rules be 
>> different or have any 
>> advantage over one another:
>>
>>  allow sepgsql_t untrusted_network_t:<class> <perms>;
>>  allow sepgsql_t sepgsql_client_t:<class> <perms>:
> 
> I doubt that the intent here is to change the permission checks
> to use the transition label. Rather the idea seems to be to
> have getpeercon() return the transition label (sepgsql_client_t).
> 
> Coincidentally we (Darrel, Chad and myself) were talking about this
> and it seems like a good idea.

As Paul and Stephen said, what getpeercon() returns fallbacked context
is confusable. I think that application should call a function to compute
fallbacked context explicitly when getpeercon() failed, like follows:

security_context_t peer_con;

if (getpeercon(sockfd, &peer_con)) {
     security_context_t serv_con, secmark_con;
     if (getsecmarkcon(sockfd, &secmark_con))
         return NULL;
     if (getcon(&serv_con))
         return NULL;
     if (security_compute_create(serv_con, secmark_con,
                                 SECCLASS_PACKET, &peer_con))
         return NULL;
}
return peer_con;

Or, getpeercon_fallback() may be able to wrap the above code.

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

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

Re: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Stephen Smalley]

On Thu, 2007-06-07 at 02:25 +0900, KaiGai Kohei wrote:
> Venkat Yekkirala wrote:
> >> Your proposal is slightly different in that I view it more as 
> >> a per-domain 
> >> renaming scheme where you rename/relabel packets based on the 
> >> receiving 
> >> domain.  Can you help me understand the advantage of 
> >> renaming "untrusted_network_t" to "sepgsql_client_t" from a 
> >> policy point of 
> >> view?  For example, how would these two policy rules be 
> >> different or have any 
> >> advantage over one another:
> >>
> >>  allow sepgsql_t untrusted_network_t:<class> <perms>;
> >>  allow sepgsql_t sepgsql_client_t:<class> <perms>:
> > 
> > I doubt that the intent here is to change the permission checks
> > to use the transition label. Rather the idea seems to be to
> > have getpeercon() return the transition label (sepgsql_client_t).
> > 
> > Coincidentally we (Darrel, Chad and myself) were talking about this
> > and it seems like a good idea.
> 
> As Paul and Stephen said, what getpeercon() returns fallbacked context
> is confusable. I think that application should call a function to compute
> fallbacked context explicitly when getpeercon() failed, like follows:
> 
> security_context_t peer_con;
> 
> if (getpeercon(sockfd, &peer_con)) {
>      security_context_t serv_con, secmark_con;
>      if (getsecmarkcon(sockfd, &secmark_con))
>          return NULL;
>      if (getcon(&serv_con))
>          return NULL;
>      if (security_compute_create(serv_con, secmark_con,
>                                  SECCLASS_PACKET, &peer_con))

Have you looked at the xinetd logic?

>          return NULL;
> }
> return peer_con;
> 
> Or, getpeercon_fallback() may be able to wrap the above code.
> 
> Thanks,
-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

Stephen Smalley wrote:
> On Thu, 2007-06-07 at 02:25 +0900, KaiGai Kohei wrote:
>> Venkat Yekkirala wrote:
>>>> Your proposal is slightly different in that I view it more as 
>>>> a per-domain 
>>>> renaming scheme where you rename/relabel packets based on the 
>>>> receiving 
>>>> domain.  Can you help me understand the advantage of 
>>>> renaming "untrusted_network_t" to "sepgsql_client_t" from a 
>>>> policy point of 
>>>> view?  For example, how would these two policy rules be 
>>>> different or have any 
>>>> advantage over one another:
>>>>
>>>>  allow sepgsql_t untrusted_network_t:<class> <perms>;
>>>>  allow sepgsql_t sepgsql_client_t:<class> <perms>:
>>> I doubt that the intent here is to change the permission checks
>>> to use the transition label. Rather the idea seems to be to
>>> have getpeercon() return the transition label (sepgsql_client_t).
>>>
>>> Coincidentally we (Darrel, Chad and myself) were talking about this
>>> and it seems like a good idea.
>> As Paul and Stephen said, what getpeercon() returns fallbacked context
>> is confusable. I think that application should call a function to compute
>> fallbacked context explicitly when getpeercon() failed, like follows:
>>
>> security_context_t peer_con;
>>
>> if (getpeercon(sockfd, &peer_con)) {
>>      security_context_t serv_con, secmark_con;
>>      if (getsecmarkcon(sockfd, &secmark_con))
>>          return NULL;
>>      if (getcon(&serv_con))
>>          return NULL;
>>      if (security_compute_create(serv_con, secmark_con,
>>                                  SECCLASS_PACKET, &peer_con))
> 
> Have you looked at the xinetd logic?

Sorry, I'm not clear what you intend to say.

Just before, I confirmed xinetd-2.3.14-label.patch
in xinetd-2.3.14-11.src.rpm (Fedora 7).

When getpeercon() returns an error, it does not have any
fallback implementation.
----------------------------------------------------
+#ifdef LABELED_NET
+static int set_context_from_socket( int fd )
+{
+   const char *func = "set_context_from_socket" ;
+   security_context_t peer_context;
+
+   if (getpeercon(fd, &peer_context) < 0)
+      return -1;             <-- caller exit soon with an error message.
+
+   int retval = setexeccon(peer_context);
+   freecon( peer_context );
+
+   if (debug.on)
+   {
+      security_context_t current_exec_context;
+      if ( getexeccon( &current_exec_context ) == 0 ) {
+
+         msg( LOG_DEBUG, func,
+          "current security exec context now: %s",
+          current_exec_context ? current_exec_context : "unknown" );
+
+         freecon( current_exec_context );
+      }
+      else
+         msg( LOG_DEBUG, func, "Error calling getexeccon: %m" );
+   }
+
+   return retval;
+}
+#endif
----------------------------------------------------

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

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

Re: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Stephen Smalley]

On Thu, 2007-06-07 at 02:52 +0900, KaiGai Kohei wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-06-07 at 02:25 +0900, KaiGai Kohei wrote:
> >> Venkat Yekkirala wrote:
> >>>> Your proposal is slightly different in that I view it more as 
> >>>> a per-domain 
> >>>> renaming scheme where you rename/relabel packets based on the 
> >>>> receiving 
> >>>> domain.  Can you help me understand the advantage of 
> >>>> renaming "untrusted_network_t" to "sepgsql_client_t" from a 
> >>>> policy point of 
> >>>> view?  For example, how would these two policy rules be 
> >>>> different or have any 
> >>>> advantage over one another:
> >>>>
> >>>>  allow sepgsql_t untrusted_network_t:<class> <perms>;
> >>>>  allow sepgsql_t sepgsql_client_t:<class> <perms>:
> >>> I doubt that the intent here is to change the permission checks
> >>> to use the transition label. Rather the idea seems to be to
> >>> have getpeercon() return the transition label (sepgsql_client_t).
> >>>
> >>> Coincidentally we (Darrel, Chad and myself) were talking about this
> >>> and it seems like a good idea.
> >> As Paul and Stephen said, what getpeercon() returns fallbacked context
> >> is confusable. I think that application should call a function to compute
> >> fallbacked context explicitly when getpeercon() failed, like follows:
> >>
> >> security_context_t peer_con;
> >>
> >> if (getpeercon(sockfd, &peer_con)) {
> >>      security_context_t serv_con, secmark_con;
> >>      if (getsecmarkcon(sockfd, &secmark_con))
> >>          return NULL;
> >>      if (getcon(&serv_con))
> >>          return NULL;
> >>      if (security_compute_create(serv_con, secmark_con,
> >>                                  SECCLASS_PACKET, &peer_con))
> > 
> > Have you looked at the xinetd logic?
> 
> Sorry, I'm not clear what you intend to say.
> 
> Just before, I confirmed xinetd-2.3.14-label.patch
> in xinetd-2.3.14-11.src.rpm (Fedora 7).

Look at xinetd-2.3.14-contextconf.patch.

> When getpeercon() returns an error, it does not have any
> fallback implementation.

Yes, I'm not referring to fallback behavior there but instead to how
they are using security_compute_create() to compute the domain
transition on the child.  While preserving the MLS range from the peer.

BTW, that kind of logic has got to be encapsulated, as discussed at the
selinux developers summit; we can't have MLS specifics leaking into the
applications.

> ----------------------------------------------------
> +#ifdef LABELED_NET
> +static int set_context_from_socket( int fd )
> +{
> +   const char *func = "set_context_from_socket" ;
> +   security_context_t peer_context;
> +
> +   if (getpeercon(fd, &peer_context) < 0)
> +      return -1;             <-- caller exit soon with an error message.
> +
> +   int retval = setexeccon(peer_context);
> +   freecon( peer_context );
> +
> +   if (debug.on)
> +   {
> +      security_context_t current_exec_context;
> +      if ( getexeccon( &current_exec_context ) == 0 ) {
> +
> +         msg( LOG_DEBUG, func,
> +          "current security exec context now: %s",
> +          current_exec_context ? current_exec_context : "unknown" );
> +
> +         freecon( current_exec_context );
> +      }
> +      else
> +         msg( LOG_DEBUG, func, "Error calling getexeccon: %m" );
> +   }
> +
> +   return retval;
> +}
> +#endif
> ----------------------------------------------------
> 
-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Venkat Yekkirala]

> Yes, I'm not referring to fallback behavior there but instead to how
> they are using security_compute_create() to compute the domain
> transition on the child.  While preserving the MLS range from 
> the peer.

Just curious; how does policy analysis based on allow rules you (Stephen)
mentioned earlier play into this in userland?

--
This message was distributed to subscribers of the selinux mailing list.
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Stephen Smalley]

On Wed, 2007-06-06 at 13:37 -0500, Venkat Yekkirala wrote:
> > Yes, I'm not referring to fallback behavior there but instead to how
> > they are using security_compute_create() to compute the domain
> > transition on the child.  While preserving the MLS range from 
> > the peer.
> 
> Just curious; how does policy analysis based on allow rules you (Stephen)
> mentioned earlier play into this in userland?

The allow rules completely describe what is permitted to happen in the
system, including all possible domain transitions and information flows.
The type transition rules are consulted to determine appropriate labels,
both by the kernel (via direct security_transition_sid calls) and by
various security-aware applications (via security_compute_create(3)),
but if there isn't a corresponding set of allow rules for that type
transition, then it will be denied nonetheless.  Thus, while you will
likely want to look at the type transition rules to understand the
default system behaviors, you can omit them from analysis when you are
checking for all possible flows.

Note that the set of allow rules needed to authorize a given type
transition may vary considerably.
  
-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

Paul Moore wrote:
> On Tuesday 05 June 2007 11:12:13 pm KaiGai Kohei wrote:
>>>> How do you think necessity for generic fall back behavior in the case
>>>> when getpeercon() failed?
>>> I think it would be useful.  There was some discussion of it during the
>>> labeled networking discussions, but directly returning the secmark label
>>> or the netif/netmsg labels was viewed as problematic because they aren't
>>> peer/process contexts.
>> I agree the conclusion. Those labels don't represent domain's one.
>> But I think that using them an entrypoint of domain transition is
>> a considerable idea, like this:
>>   type_transition postgresql_t untrusted_network_t : packet
>>     sepgsql_client_t;
>>   type_transition ftpd_t untrusted_network_t : packet 
>>     ftpd_client_t;
> 
> There was a discussion about using packet type transitions before, although it 
> was slightly different than what you are proposing here.  The basic idea was 
> to reconcile both the "internal" and "external" packet labels into a single 
> label using type transitions.  In the end it became to complex to write sane 
> policy so the idea was dropped.
> 
> Your proposal is slightly different in that I view it more as a per-domain 
> renaming scheme where you rename/relabel packets based on the receiving 
> domain.  Can you help me understand the advantage of 
> renaming "untrusted_network_t" to "sepgsql_client_t" from a policy point of 
> view?  For example, how would these two policy rules be different or have any 
> advantage over one another:
> 
>  allow sepgsql_t untrusted_network_t:<class> <perms>;
>  allow sepgsql_t sepgsql_client_t:<class> <perms>:

Paul,

I didn't intend to rename/relabel contexts of packets. The idea uses the context
of received packet as an entrypoint of domain transition. In other word, the
server process's context is renamed/relabeled based on packet's one.

The key issues in the discussion is how to determine the context of client process
connected via unlabeled network. My idea is generating an alternative client
context based on server process's one and packet's one, using domain transition.

 > Also, if it is decided that this idea does have merit and is worth
 > implementing I see it as being complimentary, and not mutually exclusive, to
 > static labeling of unlabeled hosts/networks.

The reason why I wanted to separate fallbacked client contexts per server domain
is not to give more permissions than necessary.
For example, fallbacked context for SE-PostgreSQL need to access database with
limited permission. It does not require permissions for any other services.

 >> Is it different from Paul's idea, isn't it?
 >> > In my understanding, he intends to associate a domain's context directly
 >> > with network interfaces and/or network addresses.
 >
 > Yes, that is correct.  It is similar to how existing trusted OSs provide
 > connection/packet labels for unlabeled hosts/networks.

Is it possible to apply onto TE label, not only MLS label?

Domain transition via packet class is a bit hard to understand.
It's preferable, if we can configure the fallbacked client context
directly, as follows:
    192.168.1.0/24 --> system_u:system_r:sepgsql_client_t
    192.168.2.0/24 --> system_u:system_r:sepgsql_trusted_client_t:SystemLow-SystemHigh

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

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

Re: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Wednesday, June 6 2007 1:23:34 pm KaiGai Kohei wrote:
> Paul Moore wrote:
> > On Tuesday 05 June 2007 11:12:13 pm KaiGai Kohei wrote:
> >> I agree the conclusion. Those labels don't represent domain's one.
> >> But I think that using them an entrypoint of domain transition is
> >> a considerable idea, like this:
> >>   type_transition postgresql_t untrusted_network_t : packet
> >>     sepgsql_client_t;
> >>   type_transition ftpd_t untrusted_network_t : packet
> >>     ftpd_client_t;
> >
> > There was a discussion about using packet type transitions before,
> > although it was slightly different than what you are proposing here.  The
> > basic idea was to reconcile both the "internal" and "external" packet
> > labels into a single label using type transitions.  In the end it became
> > to complex to write sane policy so the idea was dropped.
> >
> > Your proposal is slightly different in that I view it more as a
> > per-domain renaming scheme where you rename/relabel packets based on the
> > receiving domain.  Can you help me understand the advantage of
> > renaming "untrusted_network_t" to "sepgsql_client_t" from a policy point
> > of view?  For example, how would these two policy rules be different or
> > have any advantage over one another:
> >
> >  allow sepgsql_t untrusted_network_t:<class> <perms>;
> >  allow sepgsql_t sepgsql_client_t:<class> <perms>:
>
> I didn't intend to rename/relabel contexts of packets. The idea uses the
> context of received packet as an entrypoint of domain transition. In other
> word, the server process's context is renamed/relabeled based on packet's
> one.
>
> The key issues in the discussion is how to determine the context of client
> process connected via unlabeled network. My idea is generating an
> alternative client context based on server process's one and packet's one,
> using domain transition.
>
>  > Also, if it is decided that this idea does have merit and is worth
>  > implementing I see it as being complimentary, and not mutually
>  > exclusive, to static labeling of unlabeled hosts/networks.
>
> The reason why I wanted to separate fallbacked client contexts per server
> domain is not to give more permissions than necessary.
> For example, fallbacked context for SE-PostgreSQL need to access database
> with limited permission. It does not require permissions for any other
> services.

Thank you for the explanation.  I think I'm starting to get a better idea of 
what you are trying to do - see below.

>  >> Is it different from Paul's idea, isn't it?
>  >>
>  >> > In my understanding, he intends to associate a domain's context
>  >> > directly with network interfaces and/or network addresses.
>  >
>  > Yes, that is correct.  It is similar to how existing trusted OSs provide
>  > connection/packet labels for unlabeled hosts/networks.
>
> Is it possible to apply onto TE label, not only MLS label?
>
> Domain transition via packet class is a bit hard to understand.
> It's preferable, if we can configure the fallbacked client context
> directly, as follows:
>     192.168.1.0/24 --> system_u:system_r:sepgsql_client_t
>     192.168.2.0/24 -->
> system_u:system_r:sepgsql_trusted_client_t:SystemLow-SystemHigh

That is exactly what I am intending to implement; the system administrator 
would specify a interface/address/netmask that would match to a _full_ 
SELinux context as you have described above.  Now, using a type which is 
obviously specific to sepostgres (sepgsql_client_t) may not be the best 
choice for a system-wide value, but you could set it to a more generic type 
and the individual label-aware applications could transition to a more 
specific type as appropriate (much like you described in your other email).

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Venkat Yekkirala]

> > Is it possible to apply onto TE label, not only MLS label?
> >
> > Domain transition via packet class is a bit hard to understand.

IMHO, this would be true if we were introducing the concept of
domain transitions new into SELinux in this connection. But we aren't.
We are already used todomain transitions elsewhere. If someone has policy
already using secmark, it doesn't seem like much of a leap to utilize
transitions.

> > It's preferable, if we can configure the fallbacked client context
> > directly, as follows:
> >     192.168.1.0/24 --> system_u:system_r:sepgsql_client_t
> >     192.168.2.0/24 -->
> > system_u:system_r:sepgsql_trusted_client_t:SystemLow-SystemHigh
>
> That is exactly what I am intending to implement; the system
> administrator
> would specify a interface/address/netmask that would match to
> a _full_
> SELinux context as you have described above.

I see 2 drawbacks with this approach:

1. We aren't leveraging secmark (and the fine-grained policy that it
   can offer) which was supposed to move us away from individual/stand-alone
   netif/node labels here.

2. Redundant labeling (atleast MLS-wise) and the potential for
inconsistency.
   Imagine the above saying s2 and secmark saying s3.


--
This message was distributed to subscribers of the selinux mailing list.
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Wednesday, June 6 2007 2:32:04 pm Venkat Yekkirala wrote:
> > > It's preferable, if we can configure the fallbacked client context
> > > directly, as follows:
> > >     192.168.1.0/24 --> system_u:system_r:sepgsql_client_t
> > >     192.168.2.0/24 -->
> > > system_u:system_r:sepgsql_trusted_client_t:SystemLow-SystemHigh
> >
> > That is exactly what I am intending to implement; the system
> > administrator
> > would specify a interface/address/netmask that would match to
> > a _full_
> > SELinux context as you have described above.
>
> I see 2 drawbacks with this approach:
>
> 1. We aren't leveraging secmark (and the fine-grained policy that it
>    can offer) which was supposed to move us away from
> individual/stand-alone netif/node labels here.

We decided long ago to keep the two types of labels, internal and external, 
separate because merging the two made the policy to difficult to understand, 
write, and analyze.  I still believe this to be the correct decision.  This 
approach deliberately avoids making use of the SECMARK labels for this 
reason.

I view SECMARK, or any other internal labeling mechanism, as a way to 
introduce SELinux access controls into the Linux netfilter mechanism which 
provides a much more flexible and cleaner alternative to the 
compat_net/netif/node labels we used to have.  NetLabel/CIPSO, labeled IPsec, 
or any other external labeling mechanism is a way for domains to communicate 
their labels across the network.  The two labeling mechanisms, internal and 
external, both provide packet level access controls but for two completely 
different purposes.

The proposal here is to introduce a static external label for single label 
networks where the remote domain is not explicitly labeling it's network 
traffic.  This is a common request from people with existing trusted OS 
installations and would be a nice compliment to the existing labeling 
mechanisms, both internal and external.

> 2. Redundant labeling (atleast MLS-wise) and the potential for
> inconsistency.

You have the possibility for the same "redundancy" between the existing 
external and internal labels.  Simply providing another method of determining 
external labels does not cause any new redundancy that did not exist before.

If there is a disparity between the internal and external labels it is either 
because the policy is incorrect or the connection should not be allowed.

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Joshua Brindle]

Paul Moore wrote:
> On Wednesday, June 6 2007 2:32:04 pm Venkat Yekkirala wrote:
>   
>>>> It's preferable, if we can configure the fallbacked client context
>>>> directly, as follows:
>>>>     192.168.1.0/24 --> system_u:system_r:sepgsql_client_t
>>>>     192.168.2.0/24 -->
>>>> system_u:system_r:sepgsql_trusted_client_t:SystemLow-SystemHigh
>>>>         
>>> That is exactly what I am intending to implement; the system
>>> administrator
>>> would specify a interface/address/netmask that would match to
>>> a _full_
>>> SELinux context as you have described above.
>>>       
>> I see 2 drawbacks with this approach:
>>
>> 1. We aren't leveraging secmark (and the fine-grained policy that it
>>    can offer) which was supposed to move us away from
>> individual/stand-alone netif/node labels here.
>>     
>
> We decided long ago to keep the two types of labels, internal and external, 
> separate because merging the two made the policy to difficult to understand, 
> write, and analyze.  I still believe this to be the correct decision.  This 
> approach deliberately avoids making use of the SECMARK labels for this 
> reason.
>
> I view SECMARK, or any other internal labeling mechanism, as a way to 
> introduce SELinux access controls into the Linux netfilter mechanism which 
> provides a much more flexible and cleaner alternative to the 
> compat_net/netif/node labels we used to have.  NetLabel/CIPSO, labeled IPsec, 
> or any other external labeling mechanism is a way for domains to communicate 
> their labels across the network.  The two labeling mechanisms, internal and 
> external, both provide packet level access controls but for two completely 
> different purposes.
>
>   

I completely agree. I don't think we need or want netfilter style 
controls on connection labels. There is no reason something coming from 
port X on net Y on if Z  needs to be labeled differently than something 
coming from port A on net Y on if Z. These are course grained fallback 
labels for unlabeled networks.

> The proposal here is to introduce a static external label for single label 
> networks where the remote domain is not explicitly labeling it's network 
> traffic.  This is a common request from people with existing trusted OS 
> installations and would be a nice compliment to the existing labeling 
> mechanisms, both internal and external.
>
>   

Is this info going to be stored in the policy ala ocontexts? How are you 
planning to manage it? Adding it to libsemanage and semanage seems like 
the best route to take here.

>> 2. Redundant labeling (atleast MLS-wise) and the potential for
>> inconsistency.
>>     
>
> You have the possibility for the same "redundancy" between the existing 
> external and internal labels.  Simply providing another method of determining 
> external labels does not cause any new redundancy that did not exist before.
>
> If there is a disparity between the internal and external labels it is either 
> because the policy is incorrect or the connection should not be allowed.
>
>   

Correct, the same applies to labeled networks right now, if the internal 
and external labels together cause some denials and the connection can't 
be made either it wasn't suppose to happen to begin with or the policy 
needs some love.

--
This message was distributed to subscribers of the selinux mailing list.
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Wednesday, June 6 2007 4:31:51 pm Joshua Brindle wrote:
> > The proposal here is to introduce a static external label for single
> > label networks where the remote domain is not explicitly labeling it's
> > network traffic.  This is a common request from people with existing
> > trusted OS installations and would be a nice compliment to the existing
> > labeling mechanisms, both internal and external.
>
> Is this info going to be stored in the policy ala ocontexts? How are you
> planning to manage it? Adding it to libsemanage and semanage seems like
> the best route to take here.

As I envision it right now this new static external label would be managed via 
NetLabel (it is a framework after all, not just CIPSO) so we wouldn't need to 
introduce any more per-packet access checks, similar to how 
iptables/netfilter manages the SECMARK labels.  The impact to the SELinux 
kernel code should be quite minimal using this approach.

Policy integration is still open in my mind, although considering the lessons 
learned from integrating the SECMARK iptables commands into policy I wonder 
if we are best off leaving the labeling details out of the policy itself and 
leaving it in the hands of the NetLabel tools and perhaps libsemanage.

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Joshua Brindle]

Paul Moore wrote:
> On Wednesday, June 6 2007 4:31:51 pm Joshua Brindle wrote:
>   
>>> The proposal here is to introduce a static external label for single
>>> label networks where the remote domain is not explicitly labeling it's
>>> network traffic.  This is a common request from people with existing
>>> trusted OS installations and would be a nice compliment to the existing
>>> labeling mechanisms, both internal and external.
>>>       
>> Is this info going to be stored in the policy ala ocontexts? How are you
>> planning to manage it? Adding it to libsemanage and semanage seems like
>> the best route to take here.
>>     
>
> As I envision it right now this new static external label would be managed via 
> NetLabel (it is a framework after all, not just CIPSO) so we wouldn't need to 
> introduce any more per-packet access checks, similar to how 
> iptables/netfilter manages the SECMARK labels.  The impact to the SELinux 
> kernel code should be quite minimal using this approach.
>
> Policy integration is still open in my mind, although considering the lessons 
> learned from integrating the SECMARK iptables commands into policy I wonder 
> if we are best off leaving the labeling details out of the policy itself and 
> leaving it in the hands of the NetLabel tools and perhaps libsemanage.
>   
I'm fine with that, I didn't even think about the netlabel tools 
handling it (possibly because I never used them ;) )

The unfortunate part is that we are going to have all these systems for 
managing different kinds of external labels, it would be nice if there 
was a centralized management system, even if the backends are spread all 
over the place. I don't mean a GUI here either (not that a GUI would be 
bad) but more along the lines of a central management library that can 
handle it all that a GUI could later use. I'm not sure if libsemanage is 
the place for this either, particularly with ipsec where management 
really means updating SPD entries to have contexts, I don't know how 
people currently manage SPD entries so I'm not sure where we can 
interject ourselves without disturbing 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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Wednesday, June 6 2007 5:19:26 pm Joshua Brindle wrote:
> Paul Moore wrote:
> > On Wednesday, June 6 2007 4:31:51 pm Joshua Brindle wrote:
> >> Is this info going to be stored in the policy ala ocontexts? How are you
> >> planning to manage it? Adding it to libsemanage and semanage seems like
> >> the best route to take here.
> >
> > As I envision it right now this new static external label would be
> > managed via NetLabel (it is a framework after all, not just CIPSO) so we
> > wouldn't need to introduce any more per-packet access checks, similar to
> > how
> > iptables/netfilter manages the SECMARK labels.  The impact to the SELinux
> > kernel code should be quite minimal using this approach.
> >
> > Policy integration is still open in my mind, although considering the
> > lessons learned from integrating the SECMARK iptables commands into
> > policy I wonder if we are best off leaving the labeling details out of
> > the policy itself and leaving it in the hands of the NetLabel tools and
> > perhaps libsemanage.
>
> I'm fine with that, I didn't even think about the netlabel tools
> handling it (possibly because I never used them ;) )

Josh, I'm both shocked and hurt! ;)

> The unfortunate part is that we are going to have all these systems for
> managing different kinds of external labels, it would be nice if there
> was a centralized management system, even if the backends are spread all
> over the place.

Yes, I agree, this was another reason why I thought using the NetLabel 
framework was the best choice for this - no new tools/userspace.

> I don't mean a GUI here either (not that a GUI would be 
> bad) but more along the lines of a central management library that can
> handle it all that a GUI could later use. I'm not sure if libsemanage is
> the place for this either, particularly with ipsec where management
> really means updating SPD entries to have contexts, I don't know how
> people currently manage SPD entries so I'm not sure where we can
> interject ourselves without disturbing users..

I agree that consolidation is a good goal to have, I'm just not sure we are 
going to solve that right now.  In the meantime I think the best approach is 
to keep going like we have been with encapsulating most/all of the required 
functionality into libraries which can be utilized by other tools.  There are 
a few people out there who are starting to write some nice SELinux management 
tools and I suspect as we continue to expand the feature set of the network 
access controls in SELinux to meet user requests there will be more incentive 
for the tool developers to incorporate the right "knobs" in their tools.

FYI, the netlabel_tools package consists of libnetlabel, a library which 
implements all of the important NetLabel configuration/management 
functionality.  The CLI application, netlabelctl, is very small and serves 
only as an interface into this library.

http://netlabel.svn.sf.net/viewvc/netlabel/netlabel_tools/head/libnetlabel/ 
http://netlabel.svn.sf.net/viewvc/netlabel/netlabel_tools/head/include/libnetlabel.h?view=markup

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Eamon Walsh]

Joshua Brindle wrote:
> The unfortunate part is that we are going to have all these systems for 
> managing different kinds of external labels, it would be nice if there 
> was a centralized management system, even if the backends are spread all 
> over the place. I don't mean a GUI here either (not that a GUI would be 
> bad) but more along the lines of a central management library that can 
> handle it all that a GUI could later use. I'm not sure if libsemanage is 
> the place for this either, particularly with ipsec where management 
> really means updating SPD entries to have contexts, I don't know how 
> people currently manage SPD entries so I'm not sure where we can 
> interject ourselves without disturbing users..
> 

Maybe libsemanage wrapper layers could be written on top of all the 
various systems that involve SELinux labels.  This would require that 
they all have relatively stable programmatic interfaces though.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

>>  >> Is it different from Paul's idea, isn't it?
>>  >>
>>  >> > In my understanding, he intends to associate a domain's context
>>  >> > directly with network interfaces and/or network addresses.
>>  >
>>  > Yes, that is correct.  It is similar to how existing trusted OSs provide
>>  > connection/packet labels for unlabeled hosts/networks.
>>
>> Is it possible to apply onto TE label, not only MLS label?
>>
>> Domain transition via packet class is a bit hard to understand.
>> It's preferable, if we can configure the fallbacked client context
>> directly, as follows:
>>     192.168.1.0/24 --> system_u:system_r:sepgsql_client_t
>>     192.168.2.0/24 -->
>> system_u:system_r:sepgsql_trusted_client_t:SystemLow-SystemHigh
> 
> That is exactly what I am intending to implement;  the system administrator
> would specify a interface/address/netmask that would match to a _full_ 
> SELinux context as you have described above.

Good. It will be more straightforward approach than server's domain
transition.
BTW, do you have a plan how to configure the association between them?

> Now, using a type which is 
> obviously specific to sepostgres (sepgsql_client_t) may not be the best 
> choice for a system-wide value, but you could set it to a more generic type 
> and the individual label-aware applications could transition to a more 
> specific type as appropriate (much like you described in your other email).

OK, I agreed.
If a system-wide fallbacked context is defined, we can use it as a source
of domain transition for its necessity.

Thanks,
--
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai@ak.jp.nec.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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

KaiGai Kohei wrote:
>>>  >> Is it different from Paul's idea, isn't it?
>>>  >>
>>>  >> > In my understanding, he intends to associate a domain's context
>>>  >> > directly with network interfaces and/or network addresses.
>>>  >
>>>  > Yes, that is correct.  It is similar to how existing trusted OSs 
>>> provide
>>>  > connection/packet labels for unlabeled hosts/networks.
>>>
>>> Is it possible to apply onto TE label, not only MLS label?
>>>
>>> Domain transition via packet class is a bit hard to understand.
>>> It's preferable, if we can configure the fallbacked client context
>>> directly, as follows:
>>>     192.168.1.0/24 --> system_u:system_r:sepgsql_client_t
>>>     192.168.2.0/24 -->
>>> system_u:system_r:sepgsql_trusted_client_t:SystemLow-SystemHigh
>>
>> That is exactly what I am intending to implement;  the system 
>> administrator
>> would specify a interface/address/netmask that would match to a _full_ 
>> SELinux context as you have described above.
> 
> Good. It will be more straightforward approach than server's domain
> transition.
> BTW, do you have a plan how to configure the association between them?

Sorry, you have already replied in the same question, for Joshua.

| As I envision it right now this new static external label would be managed via
| NetLabel (it is a framework after all, not just CIPSO) so we wouldn't need to
| introduce any more per-packet access checks, similar to how
| iptables/netfilter manages the SECMARK labels.  The impact to the SELinux
| kernel code should be quite minimal using this approach.

In my understanding, the next NetLabel-tools enables to store fallbacked
client's context associated with network addresses/interfaces into the
kernel space, and those definitions are evaluated to attach a valid peer_sid
when a connection come from unlabaled network. Is it correct?

One more point is here.
How should be handled a connection come from unlabeled network, without any
fallbacked context? Two ways are considerable for me. One is that getpeercon()
really returns -ENOPROTOOPT, the other is returning an initial context newly
defined for this purpose.

Thanks,
-- 
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai@ak.jp.nec.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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[Paul Moore]

On Thursday 07 June 2007 3:42:27 am KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> | As I envision it right now this new static external label would be
> | managed via NetLabel (it is a framework after all, not just CIPSO) so we
> | wouldn't need to introduce any more per-packet access checks, similar to
> | how
> | iptables/netfilter manages the SECMARK labels.  The impact to the SELinux
> | kernel code should be quite minimal using this approach.
>
> In my understanding, the next NetLabel-tools enables to store fallbacked
> client's context associated with network addresses/interfaces into the
> kernel space, and those definitions are evaluated to attach a valid
> peer_sid when a connection come from unlabaled network. Is it correct?

Yes, that is correct.

> One more point is here.
> How should be handled a connection come from unlabeled network, without any
> fallbacked context? Two ways are considerable for me. One is that
> getpeercon() really returns -ENOPROTOOPT, the other is returning an initial
> context newly defined for this purpose.

My personal opinion is that the current getpeercon() behavior of 
returning -ENOPROTOOPT when a peer label is not present is probably the best 
solution as it allows per-application handling of this particular case.  
Earlier in the thread Stephen mentioned that Eamon had developed a way to 
handle this for X using a domain specific fallback label and that approach 
seems to make the most sense to me.

-- 
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: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

[KaiGai Kohei]

>> One more point is here.
>> How should be handled a connection come from unlabeled network, without any
>> fallbacked context? Two ways are considerable for me. One is that
>> getpeercon() really returns -ENOPROTOOPT, the other is returning an initial
>> context newly defined for this purpose.
> 
> My personal opinion is that the current getpeercon() behavior of 
> returning -ENOPROTOOPT when a peer label is not present is probably the best 
> solution as it allows per-application handling of this particular case.  
> Earlier in the thread Stephen mentioned that Eamon had developed a way to 
> handle this for X using a domain specific fallback label and that approach 
> seems to make the most sense to me.

OK, I agree your opinion.
SE-PostgreSQL also follows Eamon's solution for the final fallbacked context,
to avoid unnecessary confusion.

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

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