Re: [PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)

2006-06-09 Thread David Miller
From: Xiaolan Zhang [EMAIL PROTECTED]
Date: Tue, 6 Jun 2006 10:55:58 -0400

 Singned-off-by: Catherine Zhang [EMAIL PROTECTED]
 
 James, is this enough or do I need to modify the original patch to add the 
 above line?  The code was taken from various pieces of patches originally 
 from Trent and merged/modified by me.  Let me know what else I need to do.

That's good enough for me, patch applied, thanks a lot.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)

2006-06-09 Thread David Miller
From: David Miller [EMAIL PROTECTED]
Date: Thu, 08 Jun 2006 23:40:03 -0700 (PDT)

 From: Xiaolan Zhang [EMAIL PROTECTED]
 Date: Tue, 6 Jun 2006 10:55:58 -0400
 
  Singned-off-by: Catherine Zhang [EMAIL PROTECTED]
  
  James, is this enough or do I need to modify the original patch to add the 
  above line?  The code was taken from various pieces of patches originally 
  from Trent and merged/modified by me.  Let me know what else I need to do.
 
 That's good enough for me, patch applied, thanks a lot.

BTW, can I ask you SELINUX folks to at least attempt to do
a build with SELINUX disabled when you submit networking
changes to me?  It would save me a lot of time, this one
failed with:

net/xfrm/xfrm_user.c: In function $,1rx(Bxfrm_del_sa$,1ry(B:
net/xfrm/xfrm_user.c:430: warning: passing argument 1 of 
$,1rx(Bsecurity_xfrm_state_delete$,1ry(B from incompatible pointer type
net/xfrm/xfrm_user.c:430: warning: suggest parentheses around assignment used 
as truth value
net/xfrm/xfrm_user.c: In function $,1rx(Bxfrm_get_policy$,1ry(B:
net/xfrm/xfrm_user.c:1060: warning: suggest parentheses around assignment used 
as truth value

because the nop implementation of security_xfrm_state_delete()
was declared to take an xfrm_policy instead of an xfrm_state.

I've fixed all of this up, but please test this stuff out next
time around.  Thanks a lot.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)

2006-06-06 Thread Xiaolan Zhang
Singned-off-by: Catherine Zhang [EMAIL PROTECTED]

James, is this enough or do I need to modify the original patch to add the 
above line?  The code was taken from various pieces of patches originally 
from Trent and merged/modified by me.  Let me know what else I need to do.

thanks,
Catherine

James Morris [EMAIL PROTECTED] wrote on 06/06/2006 01:37:04 AM:

 On Tue, 6 Jun 2006, Catherine Zhang wrote:
 
  Minor fix per James' comment.
 
 Can you also add a Signed-off-by line?
 
 I can't recall if you were the original author.   If not, we also need a 

 From line (per Documentation/SubmittingPatches).
 
 
 Thanks,
 
 -- 
 James Morris
 [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/1] LSM-IPsec SELinux Authorize

2006-06-05 Thread Catherine Zhang
Hi, 

This is resubmit of the LSM-IPsec fix patch rebased against 
Linux version 2.6.17-rc4-mm3.

As always, comments are welcome!

Catherine

---

This patch contains a fix for the previous patch that adds security
contexts to IPsec policies and security associations.  In the previous
patch, no authorization (besides the check for write permissions to
SAD and SPD) is required to delete IPsec policies and security
assocations with security contexts.  Thus a user authorized to change
SAD and SPD can bypass the IPsec policy authorization by simply
deleteing policies with security contexts.  To fix this security hole,
an additional authorization check is added for removing security
policies and security associations with security contexts.

Note that if no security context is supplied on add or present on
policy to be deleted, the SELinux module allows the change
unconditionally.  The hook is called on deletion when no context is
present, which we may want to change.  At present, I left it up to the
module.

LSM changes:

The patch adds two new LSM hooks: xfrm_policy_delete and
xfrm_state_delete.  The new hooks are necessary to authorize deletion
of IPsec policies that have security contexts.  The existing hooks
xfrm_policy_free and xfrm_state_free lack the context to do the
authorization, so I decided to split authorization of deletion and
memory management of security data, as is typical in the LSM
interface.

Use:

The new delete hooks are checked when xfrm_policy or xfrm_state are
deleted by either the xfrm_user interface (xfrm_get_policy,
xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).

SELinux changes:

The new policy_delete and state_delete functions are added.

Signed-off-by: Trent Jaeger [EMAIL PROTECTED]

---

 include/linux/security.h|   40 +--
 net/key/af_key.c|   17 ++--
 net/xfrm/xfrm_user.c|   19 +++---
 security/dummy.c|   12 +++
 security/selinux/hooks.c|2 +
 security/selinux/include/xfrm.h |2 +
 security/selinux/xfrm.c |   41 
 7 files changed, 110 insertions(+), 23 deletions(-)

diff -puN include/linux/security.h~lsm-secpeer-fix include/linux/security.h
--- linux-2.6.17-rc4-mm3/include/linux/security.h~lsm-secpeer-fix   
2006-05-31 00:01:35.0 -0400
+++ linux-2.6.17-rc4-mm3-cxzhang/include/linux/security.h   2006-05-31 
00:46:13.0 -0400
@@ -805,31 +805,37 @@ struct swap_info_struct;
  * used by the XFRM system.
  * @sec_ctx contains the security context information being provided by
  * the user-level policy update program (e.g., setkey).
- * Allocate a security structure to the xp-selector.security field.
+ * Allocate a security structure to the xp-security field.
  * The security field is initialized to NULL when the xfrm_policy is
  * allocated.
  * Return 0 if operation was successful (memory to allocate, legal context)
  * @xfrm_policy_clone_security:
  * @old contains an existing xfrm_policy in the SPD.
  * @new contains a new xfrm_policy being cloned from old.
- * Allocate a security structure to the new-selector.security field
- * that contains the information from the old-selector.security field.
+ * Allocate a security structure to the new-security field
+ * that contains the information from the old-security field.
  * Return 0 if operation was successful (memory to allocate).
  * @xfrm_policy_free_security:
  * @xp contains the xfrm_policy
- * Deallocate xp-selector.security.
+ * Deallocate xp-security.
+ * @xfrm_policy_delete_security:
+ * @xp contains the xfrm_policy.
+ * Authorize deletion of xp-security.
  * @xfrm_state_alloc_security:
  * @x contains the xfrm_state being added to the Security Association
  * Database by the XFRM system.
  * @sec_ctx contains the security context information being provided by
  * the user-level SA generation program (e.g., setkey or racoon).
- * Allocate a security structure to the x-sel.security field.  The
+ * Allocate a security structure to the x-security field.  The
  * security field is initialized to NULL when the xfrm_state is
  * allocated.
  * Return 0 if operation was successful (memory to allocate, legal 
context).
  * @xfrm_state_free_security:
  * @x contains the xfrm_state.
- * Deallocate xsel.security.
+ * Deallocate x-security.
+ * @xfrm_state_delete_security:
+ * @x contains the xfrm_state.
+ * Authorize deletion of x-security.
  * @xfrm_policy_lookup:
  * @xp contains the xfrm_policy for which the access control is being
  * checked.
@@ -1298,8 +1304,10 @@ struct security_operations {
int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct 
xfrm_user_sec_ctx *sec_ctx);
int (*xfrm_policy_clone_security) (struct xfrm_policy *old, 

Re: [PATCH 1/1] LSM-IPsec SELinux Authorize

2006-06-05 Thread James Morris
On Mon, 5 Jun 2006, Catherine Zhang wrote:


Looks ok to me, except for one minor nit:

 + if (ctx) {
 + rc = avc_has_perm(tsec-sid, ctx-ctx_sid,
 + SECCLASS_ASSOCIATION,
 + ASSOCIATION__SETCONTEXT, NULL);
 + }

you don't need the braces here (similar again further in the patch).


- James
-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)

2006-06-05 Thread Catherine Zhang
Hi,

Minor fix per James' comment.

thanks,
Catherine

--
This patch contains a fix for the previous patch that adds security
contexts to IPsec policies and security associations.  In the previous
patch, no authorization (besides the check for write permissions to
SAD and SPD) is required to delete IPsec policies and security
assocations with security contexts.  Thus a user authorized to change
SAD and SPD can bypass the IPsec policy authorization by simply
deleteing policies with security contexts.  To fix this security hole,
an additional authorization check is added for removing security
policies and security associations with security contexts.

Note that if no security context is supplied on add or present on
policy to be deleted, the SELinux module allows the change
unconditionally.  The hook is called on deletion when no context is
present, which we may want to change.  At present, I left it up to the
module.

LSM changes:

The patch adds two new LSM hooks: xfrm_policy_delete and
xfrm_state_delete.  The new hooks are necessary to authorize deletion
of IPsec policies that have security contexts.  The existing hooks
xfrm_policy_free and xfrm_state_free lack the context to do the
authorization, so I decided to split authorization of deletion and
memory management of security data, as is typical in the LSM
interface.

Use:

The new delete hooks are checked when xfrm_policy or xfrm_state are
deleted by either the xfrm_user interface (xfrm_get_policy,
xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).

SELinux changes:

The new policy_delete and state_delete functions are added.

Signed-off-by: Trent Jaeger [EMAIL PROTECTED]

---

 include/linux/security.h|   40 ++--
 net/key/af_key.c|   17 +++--
 net/xfrm/xfrm_user.c|   19 ---
 security/dummy.c|   12 
 security/selinux/hooks.c|2 ++
 security/selinux/include/xfrm.h |2 ++
 security/selinux/xfrm.c |   39 +++
 7 files changed, 108 insertions(+), 23 deletions(-)

diff -puN include/linux/security.h~lsm-secpeer-fix include/linux/security.h
--- linux-2.6.17-rc4-mm3/include/linux/security.h~lsm-secpeer-fix   
2006-05-31 00:01:35.0 -0400
+++ linux-2.6.17-rc4-mm3-cxzhang/include/linux/security.h   2006-05-31 
00:46:13.0 -0400
@@ -805,31 +805,37 @@ struct swap_info_struct;
  * used by the XFRM system.
  * @sec_ctx contains the security context information being provided by
  * the user-level policy update program (e.g., setkey).
- * Allocate a security structure to the xp-selector.security field.
+ * Allocate a security structure to the xp-security field.
  * The security field is initialized to NULL when the xfrm_policy is
  * allocated.
  * Return 0 if operation was successful (memory to allocate, legal context)
  * @xfrm_policy_clone_security:
  * @old contains an existing xfrm_policy in the SPD.
  * @new contains a new xfrm_policy being cloned from old.
- * Allocate a security structure to the new-selector.security field
- * that contains the information from the old-selector.security field.
+ * Allocate a security structure to the new-security field
+ * that contains the information from the old-security field.
  * Return 0 if operation was successful (memory to allocate).
  * @xfrm_policy_free_security:
  * @xp contains the xfrm_policy
- * Deallocate xp-selector.security.
+ * Deallocate xp-security.
+ * @xfrm_policy_delete_security:
+ * @xp contains the xfrm_policy.
+ * Authorize deletion of xp-security.
  * @xfrm_state_alloc_security:
  * @x contains the xfrm_state being added to the Security Association
  * Database by the XFRM system.
  * @sec_ctx contains the security context information being provided by
  * the user-level SA generation program (e.g., setkey or racoon).
- * Allocate a security structure to the x-sel.security field.  The
+ * Allocate a security structure to the x-security field.  The
  * security field is initialized to NULL when the xfrm_state is
  * allocated.
  * Return 0 if operation was successful (memory to allocate, legal 
context).
  * @xfrm_state_free_security:
  * @x contains the xfrm_state.
- * Deallocate xsel.security.
+ * Deallocate x-security.
+ * @xfrm_state_delete_security:
+ * @x contains the xfrm_state.
+ * Authorize deletion of x-security.
  * @xfrm_policy_lookup:
  * @xp contains the xfrm_policy for which the access control is being
  * checked.
@@ -1298,8 +1304,10 @@ struct security_operations {
int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct 
xfrm_user_sec_ctx *sec_ctx);
int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct 
xfrm_policy *new);
void (*xfrm_policy_free_security) (struct xfrm_policy 

Re: [PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)

2006-06-05 Thread James Morris
On Tue, 6 Jun 2006, Catherine Zhang wrote:

 Minor fix per James' comment.

Acked-by: James Morris [EMAIL PROTECTED]


-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)

2006-06-05 Thread James Morris
On Tue, 6 Jun 2006, Catherine Zhang wrote:

 Minor fix per James' comment.

Can you also add a Signed-off-by line?

I can't recall if you were the original author.   If not, we also need a 
From line (per Documentation/SubmittingPatches).


Thanks,

-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)

2006-06-05 Thread David Miller
From: James Morris [EMAIL PROTECTED]
Date: Tue, 6 Jun 2006 01:37:04 -0400 (EDT)

 On Tue, 6 Jun 2006, Catherine Zhang wrote:
 
  Minor fix per James' comment.
 
 Can you also add a Signed-off-by line?
 
 I can't recall if you were the original author.   If not, we also need a 
 From line (per Documentation/SubmittingPatches).

I'll apply this to my net-2.6.18 tree once this is all sorted
out.  Thanks everyone.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] LSM-IPsec SELinux Authorize

2006-01-17 Thread David S. Miller
From: Trent Jaeger [EMAIL PROTECTED]
Date: Mon, 16 Jan 2006 21:54:13 -0500

 We want to limit the modification of security contexts only to the  
 minimal set of programs (e.g., setkey and racoon).  SELinux generally  
 restricts root programs to least privilege rights, such that a root  
 program that does not modify security policy under any normal  
 circumstances is not given permissions to do so.  As a result, such  
 programs are constrained from modifying security policy if compromised.

What about per-socket IPSEC policy settings installed via
setsockopt()?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/1] LSM-IPsec SELinux Authorize (with fixes)

2006-01-17 Thread cxzhang

Minor fixes, per James' comment.
thanks,
Catherine


This patch contains a fix for the previous patch that adds security
contexts to IPsec policies and security associations.  In the previous
patch, no authorization (besides the check for write permissions to
SAD and SPD) is required to delete IPsec policies and security
assocations with security contexts.  Thus a user authorized to change
SAD and SPD can bypass the IPsec policy authorization by simply
deleteing policies with security contexts.  To fix this security hole,
an additional authorization check is added for removing security
policies and security associations with security contexts.

Note that if no security context is supplied on add or present on
policy to be deleted, the SELinux module allows the change
unconditionally.  The hook is called on deletion when no context is
present, which we may want to change.  At present, I left it up to the
module.

LSM changes:

The patch adds two new LSM hooks: xfrm_policy_delete and
xfrm_state_delete.  The new hooks are necessary to authorize deletion
of IPsec policies that have security contexts.  The existing hooks
xfrm_policy_free and xfrm_state_free lack the context to do the
authorization, so I decided to split authorization of deletion and
memory management of security data, as is typical in the LSM
interface.

Use:

The new delete hooks are checked when xfrm_policy or xfrm_state are
deleted by either the xfrm_user interface (xfrm_get_policy,
xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).

Note that the line that adds a free to xfrm_add_policy addresses a
memory leak.  The security context must be freed when the insertion
fails also.

SELinux changes:

The new policy_delete and state_delete functions are added.

Signed-off-by: Trent Jaeger [EMAIL PROTECTED]

---

include/linux/security.h|   40 
+--

net/key/af_key.c|   18 +++--
net/xfrm/xfrm_user.c|   19 +++---
security/dummy.c|   12 +++
security/selinux/hooks.c|2 +
security/selinux/include/xfrm.h |2 +
security/selinux/xfrm.c |   41 


7 files changed, 111 insertions(+), 23 deletions(-)

diff -puN include/linux/security.h~lsm-labels-nethooks 
include/linux/security.h
--- linux-2.6.15-mm3/include/linux/security.h~lsm-labels-nethooks
2006-01-13 16:00:39.0 -0500
+++ linux-2.6.15-mm3-cxzhang/include/linux/security.h2006-01-13 
18:35:28.0 -0500

@@ -805,31 +805,37 @@ struct swap_info_struct;
 *used by the XFRM system.
 *@sec_ctx contains the security context information being provided by
 *the user-level policy update program (e.g., setkey).
- *Allocate a security structure to the xp-selector.security field.
+ *Allocate a security structure to the xp-security field.
 *The security field is initialized to NULL when the xfrm_policy is
 *allocated.
 *Return 0 if operation was successful (memory to allocate, legal 
context)

 * @xfrm_policy_clone_security:
 *@old contains an existing xfrm_policy in the SPD.
 *@new contains a new xfrm_policy being cloned from old.
- *Allocate a security structure to the new-selector.security field
- *that contains the information from the old-selector.security field.
+ *Allocate a security structure to the new-security field
+ *that contains the information from the old-security field.
 *Return 0 if operation was successful (memory to allocate).
 * @xfrm_policy_free_security:
 *@xp contains the xfrm_policy
- *Deallocate xp-selector.security.
+ *Deallocate xp-security.
+ * @xfrm_policy_delete_security:
+ *@xp contains the xfrm_policy
+ *Authorize deleteion of xp-security.
 * @xfrm_state_alloc_security:
 *@x contains the xfrm_state being added to the Security Association
 *Database by the XFRM system.
 *@sec_ctx contains the security context information being provided by
 *the user-level SA generation program (e.g., setkey or racoon).
- *Allocate a security structure to the x-sel.security field.  The
+ *Allocate a security structure to the x-security field.  The
 *security field is initialized to NULL when the xfrm_state is
 *allocated.
 *Return 0 if operation was successful (memory to allocate, legal 
context).

 * @xfrm_state_free_security:
 *@x contains the xfrm_state.
- *Deallocate xsel.security.
+ *Deallocate x-security.
+ * @xfrm_state_delete_security:
+ *@x contains the xfrm_state.
+ *Authorize deleteion of x-security.
 * @xfrm_policy_lookup:
 *@xp contains the xfrm_policy for which the access control is being
 *checked.
@@ -1303,8 +1309,10 @@ struct security_operations {
int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct 
xfrm_user_sec_ctx *sec_ctx);
int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct 

[PATCH 1/1] LSM-IPsec SELinux Authorize

2006-01-16 Thread cxzhang


This patch contains a fix for the previous patch that adds security
contexts to IPsec policies and security associations.  In the previous
patch, no authorization (besides the check for write permissions to
SAD and SPD) is required to delete IPsec policies and security
assocations with security contexts.  Thus a user authorized to change
SAD and SPD can bypass the IPsec policy authorization by simply
deleteing policies with security contexts.  To fix this security hole,
an additional authorization check is added for removing security
policies and security associations with security contexts.

Note that if no security context is supplied on add or present on
policy to be deleted, the SELinux module allows the change
unconditionally.  The hook is called on deletion when no context is
present, which we may want to change.  At present, I left it up to the
module.

LSM changes:

The patch adds two new LSM hooks: xfrm_policy_delete and
xfrm_state_delete.  The new hooks are necessary to authorize deletion
of IPsec policies that have security contexts.  The existing hooks
xfrm_policy_free and xfrm_state_free lack the context to do the
authorization, so I decided to split authorization of deletion and
memory management of security data, as is typical in the LSM
interface.

Use:

The new delete hooks are checked when xfrm_policy or xfrm_state are
deleted by either the xfrm_user interface (xfrm_get_policy,
xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).

Note that the line that adds a free to xfrm_add_policy addresses a
memory leak.  The security context must be freed when the insertion
fails also.

SELinux changes:

The new policy_delete and state_delete functions are added.

Signed-off-by: Trent Jaeger [EMAIL PROTECTED]

---

include/linux/security.h|   40 
+--

net/key/af_key.c|5 
net/xfrm/xfrm_user.c|6 +
security/dummy.c|   12 +++
security/selinux/hooks.c|2 +
security/selinux/include/xfrm.h |2 +
security/selinux/xfrm.c |   41 


7 files changed, 98 insertions(+), 10 deletions(-)

diff -puN include/linux/security.h~lsm-labels-nethooks 
include/linux/security.h
--- linux-2.6.15-mm3/include/linux/security.h~lsm-labels-nethooks   
2006-01-13 16:00:39.0 -0500
+++ linux-2.6.15-mm3-cxzhang/include/linux/security.h2006-01-13 
18:35:28.0 -0500

@@ -805,31 +805,37 @@ struct swap_info_struct;
 *used by the XFRM system.
 *@sec_ctx contains the security context information being provided by
 *the user-level policy update program (e.g., setkey).
- *Allocate a security structure to the xp-selector.security field.
+ *Allocate a security structure to the xp-security field.
 *The security field is initialized to NULL when the xfrm_policy is
 *allocated.
 *Return 0 if operation was successful (memory to allocate, legal 
context)

 * @xfrm_policy_clone_security:
 *@old contains an existing xfrm_policy in the SPD.
 *@new contains a new xfrm_policy being cloned from old.
- *Allocate a security structure to the new-selector.security field
- *that contains the information from the old-selector.security field.
+ *Allocate a security structure to the new-security field
+ *that contains the information from the old-security field.
 *Return 0 if operation was successful (memory to allocate).
 * @xfrm_policy_free_security:
 *@xp contains the xfrm_policy
- *Deallocate xp-selector.security.
+ *Deallocate xp-security.
+ * @xfrm_policy_delete_security:
+ *@xp contains the xfrm_policy
+ *Authorize deleteion of xp-security.
 * @xfrm_state_alloc_security:
 *@x contains the xfrm_state being added to the Security Association
 *Database by the XFRM system.
 *@sec_ctx contains the security context information being provided by
 *the user-level SA generation program (e.g., setkey or racoon).
- *Allocate a security structure to the x-sel.security field.  The
+ *Allocate a security structure to the x-security field.  The
 *security field is initialized to NULL when the xfrm_state is
 *allocated.
 *Return 0 if operation was successful (memory to allocate, legal 
context).

 * @xfrm_state_free_security:
 *@x contains the xfrm_state.
- *Deallocate xsel.security.
+ *Deallocate x-security.
+ * @xfrm_state_delete_security:
+ *@x contains the xfrm_state.
+ *Authorize deleteion of x-security.
 * @xfrm_policy_lookup:
 *@xp contains the xfrm_policy for which the access control is being
 *checked.
@@ -1303,8 +1309,10 @@ struct security_operations {
int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct 
xfrm_user_sec_ctx *sec_ctx);
int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct 
xfrm_policy *new);

void (*xfrm_policy_free_security) (struct xfrm_policy *xp);
+int 

Re: [PATCH 1/1] LSM-IPsec SELinux Authorize

2006-01-16 Thread Herbert Xu
On Mon, Jan 16, 2006 at 06:10:53PM -0500, cxzhang wrote:
 
 This patch contains a fix for the previous patch that adds security
 contexts to IPsec policies and security associations.  In the previous
 patch, no authorization (besides the check for write permissions to
 SAD and SPD) is required to delete IPsec policies and security
 assocations with security contexts.  Thus a user authorized to change
 SAD and SPD can bypass the IPsec policy authorization by simply
 deleteing policies with security contexts.  To fix this security hole,
 an additional authorization check is added for removing security
 policies and security associations with security contexts.

Perhaps I'm missing something.  But I thought only root can modify
the SAD/SPD?
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] LSM-IPsec SELinux Authorize

2006-01-16 Thread James Morris
On Mon, 16 Jan 2006, cxzhang wrote:

 +++ linux-2.6.15-mm3-cxzhang/net/key/af_key.c2006-01-13 18:41:02.0
 -0500
 @@ -1454,6 +1454,9 @@ static int pfkey_delete(struct sock *sk,
 if (x == NULL)
 return -ESRCH;
 
 +if ((err = security_xfrm_state_delete(x)))
 +return err;
 +

Missing xfrm_state_put().

 @@ -2273,6 +2276,8 @@ static int pfkey_spddelete(struct sock *
 
 err = 0;
 
 +if ((err = security_xfrm_policy_delete(xp)))
 +return err;

Missing xfrm_pol_put().

In these cases, use a goto so you have a single cleanup path.


 +++ linux-2.6.15-mm3-cxzhang/net/xfrm/xfrm_user.c2006-01-13
 18:44:27.0 -0500
 @@ -370,6 +370,9 @@ static int xfrm_del_sa(struct sk_buff *s
 if (x == NULL)
 return -ESRCH;
 
 +if (err = security_xfrm_state_delete(x))
 +return err;
 +

Missing xfrm_state_put().



- James
-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/1] LSM-IPsec SELinux Authorize

2005-12-26 Thread Trent Jaeger
Hi,

After discussion with Stephen Smalley and James Morris, we decided to 
change the SELinux authorization from relabel to testing for a security 
operation (set_ipsec).  That is, a process must have the authority to 
set IPsec security contexts in order to create or delete IPsec policy 
or SA entries with security contexts.

The proposed patch has a couple of minor issues that would need to be
resolved: (1) only pass to LSM when context is set? (2) task_for_security
becomes a non-static?

Patch is made against mm tree.  The point of the post is to discuss patch
changes prior to upstream to Andrew Morton.  

I will be traveling tomorrow and in less than optimal contact until Sun, 
so please bear with that.

Happy holidays to all!

Regards,
Trent.

-


This patch changes the authorization semantics for adding security 
contexts to IPsec policies.  Instead of requiring relabeling permissions
to add a security context to an IPsec policy, we require a security 
management permission (new: set_ipsec) to either add IPsec policies
with security contexts or remove IPsec policies with security contexts.

Note that if no security context is supplied on add or present on policy
to be deleted, the SELinux module allows the change unconditionally.  The 
hook is called on deletion when no context is present, which we may want
to change.  At present, I left it up to the module.

LSM changes:

The patch adds two new LSM hooks: xfrm_policy_delete and xfrm_state_delete.
The new hooks are necessary to authorize deletion of IPsec policies that 
have security contexts.  The existing hooks xfrm_policy_free and 
xfrm_state_free lack the context to do the authorization, so I decided to split
authorization of deletion and memory management of security data, as is typical
in the LSM interface.

Use:

The new delete hooks are checked when xfrm_policy or xfrm_state are
deleted by either the xfrm_user interface (xfrm_get_policy,
xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).

Note that the line that adds a free to xfrm_add_policy addresses a 
memory leak.  The security context must be freed when the insertion
fails also.

SELinux changes:

The sec_ctx_alloc function is changed to authorize the task for set_ipsec.

The new policy_delete and state_delete functions are added. 

The function task_has_security is copied from selinuxfs.c.  Do we have
a problem making this non-static?  If so, I will do that.

Signed-off-by: Trent Jaeger [EMAIL PROTECTED]

---

 include/linux/security.h |   40 +--
 net/key/af_key.c |5 +
 net/xfrm/xfrm_user.c |7 ++
 security/dummy.c |   12 
 security/selinux/hooks.c |2 
 security/selinux/include/av_perm_to_string.h |3 -
 security/selinux/include/av_permissions.h|3 -
 security/selinux/include/xfrm.h  |2 
 security/selinux/xfrm.c  |   68 +++
 9 files changed, 114 insertions(+), 28 deletions(-)

diff -puN include/linux/security.h~lsm-labels-nethooks include/linux/security.h
--- linux-2.6.15-rc5/include/linux/security.h~lsm-labels-nethooks   
2005-12-26 11:27:00.0 -0500
+++ linux-2.6.15-rc5-root/include/linux/security.h  2005-12-26 
11:29:43.0 -0500
@@ -805,31 +805,37 @@ struct swap_info_struct;
  * used by the XFRM system.
  * @sec_ctx contains the security context information being provided by
  * the user-level policy update program (e.g., setkey).
- * Allocate a security structure to the xp-selector.security field.
+ * Allocate a security structure to the xp-security field.
  * The security field is initialized to NULL when the xfrm_policy is
  * allocated.
  * Return 0 if operation was successful (memory to allocate, legal context)
  * @xfrm_policy_clone_security:
  * @old contains an existing xfrm_policy in the SPD.
  * @new contains a new xfrm_policy being cloned from old.
- * Allocate a security structure to the new-selector.security field
- * that contains the information from the old-selector.security field.
+ * Allocate a security structure to the new-security field
+ * that contains the information from the old-security field.
  * Return 0 if operation was successful (memory to allocate).
  * @xfrm_policy_free_security:
  * @xp contains the xfrm_policy
- * Deallocate xp-selector.security.
+ * Deallocate xp-security.
+ * @xfrm_policy_delete_security:
+ * @xp contains the xfrm_policy
+ * Authorize deletion of xp-security.
  * @xfrm_state_alloc_security:
  * @x contains the xfrm_state being added to the Security Association
  * Database by the XFRM system.
  * @sec_ctx contains the security context information being provided by
  * the user-level SA generation program (e.g., setkey or racoon).
- *