[RFC 1/3] secid reconciliation on inbound

[RFC 1/3] secid reconciliation on inbound

[Venkat Yekkirala]

Currently a packet accumulates multiple security identifiers, each of a
different class, as it enters the system. This patch set reconciles these
identifiers into a single identifier while also allowing LSM (SELinux is
addressed in this patch set) to impose flow control checks based on the
identifiers.

The reconciliation steps for SELinux are explained in the Labeled Networking
document at:
http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2

The following are the identifiers handled here:

1. secmark on the skb
2. xfrm security identifier associated with the skb if it used any xfrms,
   a zero secid otherwise.

This patch: Add new flask definitions to SELinux

Adds a new avperm "come_thru" to arbitrate among the identifiers on the
inbound (input/forward). Also adds a new avperm "go_thru" to enable flow
control checks on the outbound (output/forward), addressed in a later
patch.

Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>
---
 av_perm_to_string.h |    2 ++
 av_permissions.h    |    2 ++
 2 files changed, 4 insertions(+)

--- linux-2.6.17.child_sock/security/selinux/include/av_permissions.h	2006-07-31 09:36:24.000000000 -0500
+++ linux-2.6.17/security/selinux/include/av_permissions.h	2006-07-31 10:20:16.000000000 -0500
@@ -962,6 +962,8 @@
 #define PACKET__SEND                              0x00000001UL
 #define PACKET__RECV                              0x00000002UL
 #define PACKET__RELABELTO                         0x00000004UL
+#define PACKET__COME_THRU                         0x00000008UL
+#define PACKET__GO_THRU                           0x00000010UL
 
 #define KEY__VIEW                                 0x00000001UL
 #define KEY__READ                                 0x00000002UL
--- linux-2.6.17.child_sock/security/selinux/include/av_perm_to_string.h	2006-07-31 09:36:24.000000000 -0500
+++ linux-2.6.17/security/selinux/include/av_perm_to_string.h	2006-07-31 10:20:16.000000000 -0500
@@ -245,6 +245,8 @@
    S_(SECCLASS_PACKET, PACKET__SEND, "send")
    S_(SECCLASS_PACKET, PACKET__RECV, "recv")
    S_(SECCLASS_PACKET, PACKET__RELABELTO, "relabelto")
+   S_(SECCLASS_PACKET, PACKET__COME_THRU, "come_thru")
+   S_(SECCLASS_PACKET, PACKET__GO_THRU, "go_thru")
    S_(SECCLASS_KEY, KEY__VIEW, "view")
    S_(SECCLASS_KEY, KEY__READ, "read")
    S_(SECCLASS_KEY, KEY__WRITE, "write")

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

[RFC 1/3] secid reconciliation on inbound

[Venkat Yekkirala]

Currently a packet accumulates multiple security identifiers, each of a
different class, as it enters the system. This patch set reconciles these
identifiers into a single identifier while also allowing LSM (SELinux is
addressed in this patch set) to impose flow control checks based on the
identifiers.

The reconciliation steps for SELinux are explained in the Labeled Networking
document at:
http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2

The following are the identifiers handled here:

1. secmark on the skb
2. xfrm security identifier associated with the skb if it used any xfrms,
   a zero secid otherwise.

This patch: Add new flask definitions to SELinux

Adds a new avperm "come_thru" to arbitrate among the identifiers on the
inbound (input/forward). Also adds a new avperm "go_thru" to enable flow
control checks on the outbound (output/forward), addressed in a later
patch.

Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>
---
 av_perm_to_string.h |    2 ++
 av_permissions.h    |    2 ++
 2 files changed, 4 insertions(+)

--- linux-2.6.17.child_sock/security/selinux/include/av_permissions.h	2006-07-31 09:36:24.000000000 -0500
+++ linux-2.6.17/security/selinux/include/av_permissions.h	2006-07-31 10:20:16.000000000 -0500
@@ -962,6 +962,8 @@
 #define PACKET__SEND                              0x00000001UL
 #define PACKET__RECV                              0x00000002UL
 #define PACKET__RELABELTO                         0x00000004UL
+#define PACKET__COME_THRU                         0x00000008UL
+#define PACKET__GO_THRU                           0x00000010UL
 
 #define KEY__VIEW                                 0x00000001UL
 #define KEY__READ                                 0x00000002UL
--- linux-2.6.17.child_sock/security/selinux/include/av_perm_to_string.h	2006-07-31 09:36:24.000000000 -0500
+++ linux-2.6.17/security/selinux/include/av_perm_to_string.h	2006-07-31 10:20:16.000000000 -0500
@@ -245,6 +245,8 @@
    S_(SECCLASS_PACKET, PACKET__SEND, "send")
    S_(SECCLASS_PACKET, PACKET__RECV, "recv")
    S_(SECCLASS_PACKET, PACKET__RELABELTO, "relabelto")
+   S_(SECCLASS_PACKET, PACKET__COME_THRU, "come_thru")
+   S_(SECCLASS_PACKET, PACKET__GO_THRU, "go_thru")
    S_(SECCLASS_KEY, KEY__VIEW, "view")
    S_(SECCLASS_KEY, KEY__READ, "read")
    S_(SECCLASS_KEY, KEY__WRITE, "write")

Re: [RFC 1/3] secid reconciliation on inbound

[James Morris]

On Tue, 1 Aug 2006, Venkat Yekkirala wrote:

> +#define PACKET__COME_THRU                         0x00000008UL
> +#define PACKET__GO_THRU                           0x00000010UL

These names seem awkward, and do we really need a separate perm for each 
direction?



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

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

Re: [RFC 1/3] secid reconciliation on inbound

[James Morris]

On Tue, 1 Aug 2006, Venkat Yekkirala wrote:

> +#define PACKET__COME_THRU                         0x00000008UL
> +#define PACKET__GO_THRU                           0x00000010UL

These names seem awkward, and do we really need a separate perm for each 
direction?



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

Re: [RFC 1/3] secid reconciliation on inbound

[James Morris]

On Tue, 1 Aug 2006, James Morris wrote:

> On Tue, 1 Aug 2006, Venkat Yekkirala wrote:
> 
> > +#define PACKET__COME_THRU                         0x00000008UL
> > +#define PACKET__GO_THRU                           0x00000010UL
> 
> These names seem awkward, and do we really need a separate perm for each 
> direction?

Ok, I see we need separate permissions.  The naming, still...


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

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

Re: [RFC 1/3] secid reconciliation on inbound

[James Morris]

On Tue, 1 Aug 2006, James Morris wrote:

> On Tue, 1 Aug 2006, Venkat Yekkirala wrote:
> 
> > +#define PACKET__COME_THRU                         0x00000008UL
> > +#define PACKET__GO_THRU                           0x00000010UL
> 
> These names seem awkward, and do we really need a separate perm for each 
> direction?

Ok, I see we need separate permissions.  The naming, still...


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

RE: [RFC 1/3] secid reconciliation on inbound

[Venkat Yekkirala]

> On Tue, 1 Aug 2006, James Morris wrote:
> 
> > On Tue, 1 Aug 2006, Venkat Yekkirala wrote:
> > 
> > > +#define PACKET__COME_THRU                         0x00000008UL
> > > +#define PACKET__GO_THRU                           0x00000010UL
> > 
> > These names seem awkward, and do we really need a separate 
> perm for each 
> > direction?
> 
> Ok, I see we need separate permissions.  The naming, still...

You are probably seeing something I haven't :), because I did
consider using just one perm such as flow_thru for both directions
but then thought separate perms would make things easier to understand.

As for naming, how about "enter" and "leave"? Or "flow_in" and "flow_out".
Any other suggestions out there?

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

RE: [RFC 1/3] secid reconciliation on inbound

[Venkat Yekkirala]

> On Tue, 1 Aug 2006, James Morris wrote:
> 
> > On Tue, 1 Aug 2006, Venkat Yekkirala wrote:
> > 
> > > +#define PACKET__COME_THRU                         0x00000008UL
> > > +#define PACKET__GO_THRU                           0x00000010UL
> > 
> > These names seem awkward, and do we really need a separate 
> perm for each 
> > direction?
> 
> Ok, I see we need separate permissions.  The naming, still...

You are probably seeing something I haven't :), because I did
consider using just one perm such as flow_thru for both directions
but then thought separate perms would make things easier to understand.

As for naming, how about "enter" and "leave"? Or "flow_in" and "flow_out".
Any other suggestions out there?

Re: [RFC 1/3] secid reconciliation on inbound

[Stephen Smalley]

On Tue, 2006-08-01 at 17:08 -0500, Venkat Yekkirala wrote:
> Currently a packet accumulates multiple security identifiers, each of a
> different class, as it enters the system. This patch set reconciles these
> identifiers into a single identifier while also allowing LSM (SELinux is
> addressed in this patch set) to impose flow control checks based on the
> identifiers.
> 
> The reconciliation steps for SELinux are explained in the Labeled Networking
> document at:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2
> 
> The following are the identifiers handled here:
> 
> 1. secmark on the skb
> 2. xfrm security identifier associated with the skb if it used any xfrms,
>    a zero secid otherwise.
> 
> This patch: Add new flask definitions to SELinux
> 
> Adds a new avperm "come_thru" to arbitrate among the identifiers on the
> inbound (input/forward). Also adds a new avperm "go_thru" to enable flow
> control checks on the outbound (output/forward), addressed in a later
> patch.

(altered cc line for discussion of implications for selinux and its use
of secmark)

The recent netfilter integration work is generating secmark labeling
rules to label packets based on their destination port and direction
(client/server), and refpolicy already includes packet types for this
purpose and rules to allow domains to send and recv packets appropriate
for their domain using the existing packet send/recv permissions.

More generally, secmark is intended to serve as a more expressive
replacement for all of the old netif/node/port checks, so one should be
able to use it to enforce policies like "Only processes with label A can
send/recv on netif N1 and only processes with label B can send/recv on
netif N2" or policies like "Processes with label A can only receive
packets from source ports with label P".

With your "secid reconciliation", you replace the secmark label with the
xfrm label (even in the unlabeled case?) after the come_thru/go_thru
checking, and end up using the xfrm label for the packet send/recv
check.  This seems to lose the relationship between the original secmark
label and the sending/receiving socket label.

More generally, the xfrm label tells us something about the peer, while
the secmark label is based on the packet properties, often based on its
destination properties (like receiving netif and destination port)
rather than source properties.

Am I missing something?  Or is such reconciliation not really feasible
without losing the original intended functionality of secmark?

-- 
Stephen Smalley
National Security Agency


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

RE: [RFC 1/3] secid reconciliation on inbound

[Venkat Yekkirala]

> More generally, secmark is intended to serve as a more expressive
> replacement for all of the old netif/node/port checks, so one 
> should be
> able to use it to enforce policies like "Only processes with 
> label A can
> send/recv on netif N1 and only processes with label B can send/recv on
> netif N2" or policies like "Processes with label A can only receive
> packets from source ports with label P".

Let me try to reconcile :) the above with the reconciliation proposed here.

In the new paradigm, the netfilter rules are merely flow control points
with externally unlabeled data coming thru (if flow-allowed by policy)
and acquiring the label of the flow control point by virtue of the data
coming in thru the flow control point.

So in the non-xfrm case, the above example can be re-expressed as:
"Only processes with label A can recv data with label N1 and only processes
with label B can recv data with label N2" or policies like "Processes with
label A can only receive packets from data with label P".

In the xfrm case, the following is how this could be approached:
"Only processes with label A can recv data with label T1 (T1 being a xfrm
type allowed in thru flow control point type N1)...

> 
> With your "secid reconciliation", you replace the secmark 
> label with the
> xfrm label (even in the unlabeled case?)

Will fix this so that the flow control check will still happen
in the unlabeled/no xfrm case, but it (unlabeled) won't override
secmark (as opposed to the labeled xfrm case where it will override
secmark).

> after the come_thru/go_thru
> checking, and end up using the xfrm label for the packet send/recv
> check.  This seems to lose the relationship between the 
> original secmark
> label and the sending/receiving socket label.

The direct relationship is being lost, yes, but the indirect relatioship
is still there. This is where I wonder what examples we can think of that
the indirect relationship won't satisfy.

> 
> More generally, the xfrm label tells us something about the 
> peer, while
> the secmark label is based on the packet properties, often 
> based on its
> destination properties (like receiving netif and destination port)
> rather than source properties.

In theory, I don't see why data couldn't have labels of different
classes (and related controls), but we are still having to answer
the question of what the label of the data is for:

a. servicing the data at the right label
b. outbound flow control
c. xfrm-selection for forwarded traffic.

The answer can again be 2 (or more labels) with a "priority" rather
than reconciliation for item (a), and perhaps ALL labels for item (b).
But then there's added effort involved with retaining these multiple
labels (secmark, sp on the skb and cipso) across all the different
code paths.

So the question boils down to whether there are realistic examples of
policy expression that can't be handled in the new paradigm.

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