All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC 1/3] secid reconciliation on inbound
@ 2006-08-01 22:08 ` Venkat Yekkirala
  0 siblings, 0 replies; 10+ messages in thread
From: Venkat Yekkirala @ 2006-08-01 22:08 UTC (permalink / raw)
  To: netdev, selinux; +Cc: jmorris, sds, chanson

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [RFC 1/3] secid reconciliation on inbound
@ 2006-08-02 12:57 ` Venkat Yekkirala
  0 siblings, 0 replies; 10+ messages in thread
From: Venkat Yekkirala @ 2006-08-02 12:57 UTC (permalink / raw)
  To: James Morris; +Cc: netdev, selinux, sds, Chad Hanson

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [RFC 1/3] secid reconciliation on inbound
@ 2006-08-02 15:55 Venkat Yekkirala
  0 siblings, 0 replies; 10+ messages in thread
From: Venkat Yekkirala @ 2006-08-02 15:55 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Christopher J. PeBenito, Karl MacMillan, selinux, jmorris,
	Chad Hanson

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-08-02 15:55 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-01 22:08 [RFC 1/3] secid reconciliation on inbound Venkat Yekkirala
2006-08-01 22:08 ` Venkat Yekkirala
2006-08-01 23:19 ` James Morris
2006-08-01 23:19   ` James Morris
2006-08-02  4:19   ` James Morris
2006-08-02  4:19     ` James Morris
2006-08-02 13:49 ` Stephen Smalley
  -- strict thread matches above, loose matches on Subject: below --
2006-08-02 12:57 Venkat Yekkirala
2006-08-02 12:57 ` Venkat Yekkirala
2006-08-02 15:55 Venkat Yekkirala

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.