linux-sg2042/security/selinux/xfrm.c

469 lines
11 KiB
C
Raw Normal View History

[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/*
* NSA Security-Enhanced Linux (SELinux) security module
*
* This file contains the SELinux XFRM hook function implementations.
*
* Authors: Serge Hallyn <sergeh@us.ibm.com>
* Trent Jaeger <jaegert@us.ibm.com>
*
* Updated: Venkat Yekkirala <vyekkirala@TrustedCS.com>
*
* Granular IPSec Associations for use in MLS environments.
*
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
* Copyright (C) 2005 International Business Machines Corporation
* Copyright (C) 2006 Trusted Computer Solutions, Inc.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2,
* as published by the Free Software Foundation.
*/
/*
* USAGE:
* NOTES:
* 1. Make sure to enable the following options in your kernel config:
* CONFIG_SECURITY=y
* CONFIG_SECURITY_NETWORK=y
* CONFIG_SECURITY_NETWORK_XFRM=y
* CONFIG_SECURITY_SELINUX=m/y
* ISSUES:
* 1. Caching packets, so they are not dropped during negotiation
* 2. Emulating a reasonable SO_PEERSEC across machines
* 3. Testing addition of sk_policy's with security context via setsockopt
*/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/security.h>
#include <linux/types.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
#include <linux/slab.h>
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/skbuff.h>
#include <linux/xfrm.h>
#include <net/xfrm.h>
#include <net/checksum.h>
#include <net/udp.h>
#include <linux/atomic.h>
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
#include "avc.h"
#include "objsec.h"
#include "xfrm.h"
/* Labeled XFRM instance counter */
atomic_t selinux_xfrm_refcount = ATOMIC_INIT(0);
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/*
* Returns true if the context is an LSM/SELinux context.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
static inline int selinux_authorizable_ctx(struct xfrm_sec_ctx *ctx)
{
return (ctx &&
(ctx->ctx_doi == XFRM_SC_DOI_LSM) &&
(ctx->ctx_alg == XFRM_SC_ALG_SELINUX));
}
/*
* Returns true if the xfrm contains a security blob for SELinux.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
static inline int selinux_authorizable_xfrm(struct xfrm_state *x)
{
return selinux_authorizable_ctx(x->security);
}
/*
* Allocates a xfrm_sec_state and populates it using the supplied security
* xfrm_user_sec_ctx context.
*/
static int selinux_xfrm_alloc_user(struct xfrm_sec_ctx **ctxp,
selinux: add gfp argument to security_xfrm_policy_alloc and fix callers security_xfrm_policy_alloc can be called in atomic context so the allocation should be done with GFP_ATOMIC. Add an argument to let the callers choose the appropriate way. In order to do so a gfp argument needs to be added to the method xfrm_policy_alloc_security in struct security_operations and to the internal function selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic callers and leave GFP_KERNEL as before for the rest. The path that needed the gfp argument addition is: security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security -> all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -> selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only) Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also add it to security_context_to_sid which is used inside and prior to this patch did only GFP_KERNEL allocation. So add gfp argument to security_context_to_sid and adjust all of its callers as well. CC: Paul Moore <paul@paul-moore.com> CC: Dave Jones <davej@redhat.com> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Fan Du <fan.du@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: LSM list <linux-security-module@vger.kernel.org> CC: SELinux list <selinux@tycho.nsa.gov> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2014-03-07 19:44:19 +08:00
struct xfrm_user_sec_ctx *uctx,
gfp_t gfp)
{
int rc;
const struct task_security_struct *tsec = current_security();
struct xfrm_sec_ctx *ctx = NULL;
u32 str_len;
if (ctxp == NULL || uctx == NULL ||
uctx->ctx_doi != XFRM_SC_DOI_LSM ||
uctx->ctx_alg != XFRM_SC_ALG_SELINUX)
return -EINVAL;
str_len = uctx->ctx_len;
if (str_len >= PAGE_SIZE)
return -ENOMEM;
selinux: add gfp argument to security_xfrm_policy_alloc and fix callers security_xfrm_policy_alloc can be called in atomic context so the allocation should be done with GFP_ATOMIC. Add an argument to let the callers choose the appropriate way. In order to do so a gfp argument needs to be added to the method xfrm_policy_alloc_security in struct security_operations and to the internal function selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic callers and leave GFP_KERNEL as before for the rest. The path that needed the gfp argument addition is: security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security -> all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -> selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only) Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also add it to security_context_to_sid which is used inside and prior to this patch did only GFP_KERNEL allocation. So add gfp argument to security_context_to_sid and adjust all of its callers as well. CC: Paul Moore <paul@paul-moore.com> CC: Dave Jones <davej@redhat.com> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Fan Du <fan.du@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: LSM list <linux-security-module@vger.kernel.org> CC: SELinux list <selinux@tycho.nsa.gov> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2014-03-07 19:44:19 +08:00
ctx = kmalloc(sizeof(*ctx) + str_len + 1, gfp);
if (!ctx)
return -ENOMEM;
ctx->ctx_doi = XFRM_SC_DOI_LSM;
ctx->ctx_alg = XFRM_SC_ALG_SELINUX;
ctx->ctx_len = str_len;
memcpy(ctx->ctx_str, &uctx[1], str_len);
ctx->ctx_str[str_len] = '\0';
selinux: add gfp argument to security_xfrm_policy_alloc and fix callers security_xfrm_policy_alloc can be called in atomic context so the allocation should be done with GFP_ATOMIC. Add an argument to let the callers choose the appropriate way. In order to do so a gfp argument needs to be added to the method xfrm_policy_alloc_security in struct security_operations and to the internal function selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic callers and leave GFP_KERNEL as before for the rest. The path that needed the gfp argument addition is: security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security -> all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -> selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only) Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also add it to security_context_to_sid which is used inside and prior to this patch did only GFP_KERNEL allocation. So add gfp argument to security_context_to_sid and adjust all of its callers as well. CC: Paul Moore <paul@paul-moore.com> CC: Dave Jones <davej@redhat.com> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Fan Du <fan.du@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: LSM list <linux-security-module@vger.kernel.org> CC: SELinux list <selinux@tycho.nsa.gov> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2014-03-07 19:44:19 +08:00
rc = security_context_to_sid(ctx->ctx_str, str_len, &ctx->ctx_sid, gfp);
if (rc)
goto err;
rc = avc_has_perm(tsec->sid, ctx->ctx_sid,
SECCLASS_ASSOCIATION, ASSOCIATION__SETCONTEXT, NULL);
if (rc)
goto err;
*ctxp = ctx;
atomic_inc(&selinux_xfrm_refcount);
return 0;
err:
kfree(ctx);
return rc;
}
/*
* Free the xfrm_sec_ctx structure.
*/
static void selinux_xfrm_free(struct xfrm_sec_ctx *ctx)
{
if (!ctx)
return;
atomic_dec(&selinux_xfrm_refcount);
kfree(ctx);
}
/*
* Authorize the deletion of a labeled SA or policy rule.
*/
static int selinux_xfrm_delete(struct xfrm_sec_ctx *ctx)
{
const struct task_security_struct *tsec = current_security();
if (!ctx)
return 0;
return avc_has_perm(tsec->sid, ctx->ctx_sid,
SECCLASS_ASSOCIATION, ASSOCIATION__SETCONTEXT,
NULL);
}
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/*
* LSM hook implementation that authorizes that a flow can use a xfrm policy
* rule.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
int selinux_xfrm_policy_lookup(struct xfrm_sec_ctx *ctx, u32 fl_secid, u8 dir)
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
{
IPsec: correct semantics for SELinux policy matching Currently when an IPSec policy rule doesn't specify a security context, it is assumed to be "unlabeled" by SELinux, and so the IPSec policy rule fails to match to a flow that it would otherwise match to, unless one has explicitly added an SELinux policy rule allowing the flow to "polmatch" to the "unlabeled" IPSec policy rules. In the absence of such an explicitly added SELinux policy rule, the IPSec policy rule fails to match and so the packet(s) flow in clear text without the otherwise applicable xfrm(s) applied. The above SELinux behavior violates the SELinux security notion of "deny by default" which should actually translate to "encrypt by default" in the above case. This was first reported by Evgeniy Polyakov and the way James Morris was seeing the problem was when connecting via IPsec to a confined service on an SELinux box (vsftpd), which did not have the appropriate SELinux policy permissions to send packets via IPsec. With this patch applied, SELinux "polmatching" of flows Vs. IPSec policy rules will only come into play when there's a explicit context specified for the IPSec policy rule (which also means there's corresponding SELinux policy allowing appropriate domains/flows to polmatch to this context). Secondly, when a security module is loaded (in this case, SELinux), the security_xfrm_policy_lookup() hook can return errors other than access denied, such as -EINVAL. We were not handling that correctly, and in fact inverting the return logic and propagating a false "ok" back up to xfrm_lookup(), which then allowed packets to pass as if they were not associated with an xfrm policy. The solution for this is to first ensure that errno values are correctly propagated all the way back up through the various call chains from security_xfrm_policy_lookup(), and handled correctly. Then, flow_cache_lookup() is modified, so that if the policy resolver fails (typically a permission denied via the security module), the flow cache entry is killed rather than having a null policy assigned (which indicates that the packet can pass freely). This also forces any future lookups for the same flow to consult the security module (e.g. SELinux) for current security policy (rather than, say, caching the error on the flow cache entry). This patch: Fix the selinux side of things. This makes sure SELinux polmatching of flow contexts to IPSec policy rules comes into play only when an explicit context is associated with the IPSec policy rule. Also, this no longer defaults the context of a socket policy to the context of the socket since the "no explicit context" case is now handled properly. Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com> Signed-off-by: James Morris <jmorris@namei.org>
2006-10-06 04:42:18 +08:00
int rc;
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/* All flows should be treated as polmatch'ing an otherwise applicable
* "non-labeled" policy. This would prevent inadvertent "leaks". */
if (!ctx)
IPsec: correct semantics for SELinux policy matching Currently when an IPSec policy rule doesn't specify a security context, it is assumed to be "unlabeled" by SELinux, and so the IPSec policy rule fails to match to a flow that it would otherwise match to, unless one has explicitly added an SELinux policy rule allowing the flow to "polmatch" to the "unlabeled" IPSec policy rules. In the absence of such an explicitly added SELinux policy rule, the IPSec policy rule fails to match and so the packet(s) flow in clear text without the otherwise applicable xfrm(s) applied. The above SELinux behavior violates the SELinux security notion of "deny by default" which should actually translate to "encrypt by default" in the above case. This was first reported by Evgeniy Polyakov and the way James Morris was seeing the problem was when connecting via IPsec to a confined service on an SELinux box (vsftpd), which did not have the appropriate SELinux policy permissions to send packets via IPsec. With this patch applied, SELinux "polmatching" of flows Vs. IPSec policy rules will only come into play when there's a explicit context specified for the IPSec policy rule (which also means there's corresponding SELinux policy allowing appropriate domains/flows to polmatch to this context). Secondly, when a security module is loaded (in this case, SELinux), the security_xfrm_policy_lookup() hook can return errors other than access denied, such as -EINVAL. We were not handling that correctly, and in fact inverting the return logic and propagating a false "ok" back up to xfrm_lookup(), which then allowed packets to pass as if they were not associated with an xfrm policy. The solution for this is to first ensure that errno values are correctly propagated all the way back up through the various call chains from security_xfrm_policy_lookup(), and handled correctly. Then, flow_cache_lookup() is modified, so that if the policy resolver fails (typically a permission denied via the security module), the flow cache entry is killed rather than having a null policy assigned (which indicates that the packet can pass freely). This also forces any future lookups for the same flow to consult the security module (e.g. SELinux) for current security policy (rather than, say, caching the error on the flow cache entry). This patch: Fix the selinux side of things. This makes sure SELinux polmatching of flow contexts to IPSec policy rules comes into play only when an explicit context is associated with the IPSec policy rule. Also, this no longer defaults the context of a socket policy to the context of the socket since the "no explicit context" case is now handled properly. Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com> Signed-off-by: James Morris <jmorris@namei.org>
2006-10-06 04:42:18 +08:00
return 0;
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/* Context sid is either set to label or ANY_ASSOC */
if (!selinux_authorizable_ctx(ctx))
return -EINVAL;
IPsec: correct semantics for SELinux policy matching Currently when an IPSec policy rule doesn't specify a security context, it is assumed to be "unlabeled" by SELinux, and so the IPSec policy rule fails to match to a flow that it would otherwise match to, unless one has explicitly added an SELinux policy rule allowing the flow to "polmatch" to the "unlabeled" IPSec policy rules. In the absence of such an explicitly added SELinux policy rule, the IPSec policy rule fails to match and so the packet(s) flow in clear text without the otherwise applicable xfrm(s) applied. The above SELinux behavior violates the SELinux security notion of "deny by default" which should actually translate to "encrypt by default" in the above case. This was first reported by Evgeniy Polyakov and the way James Morris was seeing the problem was when connecting via IPsec to a confined service on an SELinux box (vsftpd), which did not have the appropriate SELinux policy permissions to send packets via IPsec. With this patch applied, SELinux "polmatching" of flows Vs. IPSec policy rules will only come into play when there's a explicit context specified for the IPSec policy rule (which also means there's corresponding SELinux policy allowing appropriate domains/flows to polmatch to this context). Secondly, when a security module is loaded (in this case, SELinux), the security_xfrm_policy_lookup() hook can return errors other than access denied, such as -EINVAL. We were not handling that correctly, and in fact inverting the return logic and propagating a false "ok" back up to xfrm_lookup(), which then allowed packets to pass as if they were not associated with an xfrm policy. The solution for this is to first ensure that errno values are correctly propagated all the way back up through the various call chains from security_xfrm_policy_lookup(), and handled correctly. Then, flow_cache_lookup() is modified, so that if the policy resolver fails (typically a permission denied via the security module), the flow cache entry is killed rather than having a null policy assigned (which indicates that the packet can pass freely). This also forces any future lookups for the same flow to consult the security module (e.g. SELinux) for current security policy (rather than, say, caching the error on the flow cache entry). This patch: Fix the selinux side of things. This makes sure SELinux polmatching of flow contexts to IPSec policy rules comes into play only when an explicit context is associated with the IPSec policy rule. Also, this no longer defaults the context of a socket policy to the context of the socket since the "no explicit context" case is now handled properly. Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com> Signed-off-by: James Morris <jmorris@namei.org>
2006-10-06 04:42:18 +08:00
rc = avc_has_perm(fl_secid, ctx->ctx_sid,
SECCLASS_ASSOCIATION, ASSOCIATION__POLMATCH, NULL);
return (rc == -EACCES ? -ESRCH : rc);
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}
/*
* LSM hook implementation that authorizes that a state matches
* the given policy, flow combo.
*/
int selinux_xfrm_state_pol_flow_match(struct xfrm_state *x,
struct xfrm_policy *xp,
const struct flowi *fl)
{
u32 state_sid;
if (!xp->security)
IPsec: correct semantics for SELinux policy matching Currently when an IPSec policy rule doesn't specify a security context, it is assumed to be "unlabeled" by SELinux, and so the IPSec policy rule fails to match to a flow that it would otherwise match to, unless one has explicitly added an SELinux policy rule allowing the flow to "polmatch" to the "unlabeled" IPSec policy rules. In the absence of such an explicitly added SELinux policy rule, the IPSec policy rule fails to match and so the packet(s) flow in clear text without the otherwise applicable xfrm(s) applied. The above SELinux behavior violates the SELinux security notion of "deny by default" which should actually translate to "encrypt by default" in the above case. This was first reported by Evgeniy Polyakov and the way James Morris was seeing the problem was when connecting via IPsec to a confined service on an SELinux box (vsftpd), which did not have the appropriate SELinux policy permissions to send packets via IPsec. With this patch applied, SELinux "polmatching" of flows Vs. IPSec policy rules will only come into play when there's a explicit context specified for the IPSec policy rule (which also means there's corresponding SELinux policy allowing appropriate domains/flows to polmatch to this context). Secondly, when a security module is loaded (in this case, SELinux), the security_xfrm_policy_lookup() hook can return errors other than access denied, such as -EINVAL. We were not handling that correctly, and in fact inverting the return logic and propagating a false "ok" back up to xfrm_lookup(), which then allowed packets to pass as if they were not associated with an xfrm policy. The solution for this is to first ensure that errno values are correctly propagated all the way back up through the various call chains from security_xfrm_policy_lookup(), and handled correctly. Then, flow_cache_lookup() is modified, so that if the policy resolver fails (typically a permission denied via the security module), the flow cache entry is killed rather than having a null policy assigned (which indicates that the packet can pass freely). This also forces any future lookups for the same flow to consult the security module (e.g. SELinux) for current security policy (rather than, say, caching the error on the flow cache entry). This patch: Fix the selinux side of things. This makes sure SELinux polmatching of flow contexts to IPSec policy rules comes into play only when an explicit context is associated with the IPSec policy rule. Also, this no longer defaults the context of a socket policy to the context of the socket since the "no explicit context" case is now handled properly. Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com> Signed-off-by: James Morris <jmorris@namei.org>
2006-10-06 04:42:18 +08:00
if (x->security)
/* unlabeled policy and labeled SA can't match */
return 0;
else
/* unlabeled policy and unlabeled SA match all flows */
return 1;
else
if (!x->security)
/* unlabeled SA and labeled policy can't match */
IPsec: correct semantics for SELinux policy matching Currently when an IPSec policy rule doesn't specify a security context, it is assumed to be "unlabeled" by SELinux, and so the IPSec policy rule fails to match to a flow that it would otherwise match to, unless one has explicitly added an SELinux policy rule allowing the flow to "polmatch" to the "unlabeled" IPSec policy rules. In the absence of such an explicitly added SELinux policy rule, the IPSec policy rule fails to match and so the packet(s) flow in clear text without the otherwise applicable xfrm(s) applied. The above SELinux behavior violates the SELinux security notion of "deny by default" which should actually translate to "encrypt by default" in the above case. This was first reported by Evgeniy Polyakov and the way James Morris was seeing the problem was when connecting via IPsec to a confined service on an SELinux box (vsftpd), which did not have the appropriate SELinux policy permissions to send packets via IPsec. With this patch applied, SELinux "polmatching" of flows Vs. IPSec policy rules will only come into play when there's a explicit context specified for the IPSec policy rule (which also means there's corresponding SELinux policy allowing appropriate domains/flows to polmatch to this context). Secondly, when a security module is loaded (in this case, SELinux), the security_xfrm_policy_lookup() hook can return errors other than access denied, such as -EINVAL. We were not handling that correctly, and in fact inverting the return logic and propagating a false "ok" back up to xfrm_lookup(), which then allowed packets to pass as if they were not associated with an xfrm policy. The solution for this is to first ensure that errno values are correctly propagated all the way back up through the various call chains from security_xfrm_policy_lookup(), and handled correctly. Then, flow_cache_lookup() is modified, so that if the policy resolver fails (typically a permission denied via the security module), the flow cache entry is killed rather than having a null policy assigned (which indicates that the packet can pass freely). This also forces any future lookups for the same flow to consult the security module (e.g. SELinux) for current security policy (rather than, say, caching the error on the flow cache entry). This patch: Fix the selinux side of things. This makes sure SELinux polmatching of flow contexts to IPSec policy rules comes into play only when an explicit context is associated with the IPSec policy rule. Also, this no longer defaults the context of a socket policy to the context of the socket since the "no explicit context" case is now handled properly. Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com> Signed-off-by: James Morris <jmorris@namei.org>
2006-10-06 04:42:18 +08:00
return 0;
else
if (!selinux_authorizable_xfrm(x))
/* Not a SELinux-labeled SA */
return 0;
IPsec: correct semantics for SELinux policy matching Currently when an IPSec policy rule doesn't specify a security context, it is assumed to be "unlabeled" by SELinux, and so the IPSec policy rule fails to match to a flow that it would otherwise match to, unless one has explicitly added an SELinux policy rule allowing the flow to "polmatch" to the "unlabeled" IPSec policy rules. In the absence of such an explicitly added SELinux policy rule, the IPSec policy rule fails to match and so the packet(s) flow in clear text without the otherwise applicable xfrm(s) applied. The above SELinux behavior violates the SELinux security notion of "deny by default" which should actually translate to "encrypt by default" in the above case. This was first reported by Evgeniy Polyakov and the way James Morris was seeing the problem was when connecting via IPsec to a confined service on an SELinux box (vsftpd), which did not have the appropriate SELinux policy permissions to send packets via IPsec. With this patch applied, SELinux "polmatching" of flows Vs. IPSec policy rules will only come into play when there's a explicit context specified for the IPSec policy rule (which also means there's corresponding SELinux policy allowing appropriate domains/flows to polmatch to this context). Secondly, when a security module is loaded (in this case, SELinux), the security_xfrm_policy_lookup() hook can return errors other than access denied, such as -EINVAL. We were not handling that correctly, and in fact inverting the return logic and propagating a false "ok" back up to xfrm_lookup(), which then allowed packets to pass as if they were not associated with an xfrm policy. The solution for this is to first ensure that errno values are correctly propagated all the way back up through the various call chains from security_xfrm_policy_lookup(), and handled correctly. Then, flow_cache_lookup() is modified, so that if the policy resolver fails (typically a permission denied via the security module), the flow cache entry is killed rather than having a null policy assigned (which indicates that the packet can pass freely). This also forces any future lookups for the same flow to consult the security module (e.g. SELinux) for current security policy (rather than, say, caching the error on the flow cache entry). This patch: Fix the selinux side of things. This makes sure SELinux polmatching of flow contexts to IPSec policy rules comes into play only when an explicit context is associated with the IPSec policy rule. Also, this no longer defaults the context of a socket policy to the context of the socket since the "no explicit context" case is now handled properly. Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com> Signed-off-by: James Morris <jmorris@namei.org>
2006-10-06 04:42:18 +08:00
state_sid = x->security->ctx_sid;
if (fl->flowi_secid != state_sid)
return 0;
/* We don't need a separate SA Vs. policy polmatch check since the SA
* is now of the same label as the flow and a flow Vs. policy polmatch
* check had already happened in selinux_xfrm_policy_lookup() above. */
return (avc_has_perm(fl->flowi_secid, state_sid,
SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO,
NULL) ? 0 : 1);
}
static u32 selinux_xfrm_skb_sid_egress(struct sk_buff *skb)
{
struct dst_entry *dst = skb_dst(skb);
struct xfrm_state *x;
if (dst == NULL)
return SECSID_NULL;
x = dst->xfrm;
if (x == NULL || !selinux_authorizable_xfrm(x))
return SECSID_NULL;
return x->security->ctx_sid;
}
static int selinux_xfrm_skb_sid_ingress(struct sk_buff *skb,
u32 *sid, int ckall)
{
u32 sid_session = SECSID_NULL;
struct sec_path *sp = skb->sp;
if (sp) {
int i;
for (i = sp->len - 1; i >= 0; i--) {
struct xfrm_state *x = sp->xvec[i];
if (selinux_authorizable_xfrm(x)) {
struct xfrm_sec_ctx *ctx = x->security;
if (sid_session == SECSID_NULL) {
sid_session = ctx->ctx_sid;
if (!ckall)
goto out;
} else if (sid_session != ctx->ctx_sid) {
*sid = SECSID_NULL;
return -EINVAL;
}
}
}
}
out:
*sid = sid_session;
return 0;
}
/*
* LSM hook implementation that checks and/or returns the xfrm sid for the
* incoming packet.
*/
int selinux_xfrm_decode_session(struct sk_buff *skb, u32 *sid, int ckall)
{
if (skb == NULL) {
*sid = SECSID_NULL;
return 0;
}
return selinux_xfrm_skb_sid_ingress(skb, sid, ckall);
}
int selinux_xfrm_skb_sid(struct sk_buff *skb, u32 *sid)
{
int rc;
rc = selinux_xfrm_skb_sid_ingress(skb, sid, 0);
if (rc == 0 && *sid == SECSID_NULL)
*sid = selinux_xfrm_skb_sid_egress(skb);
return rc;
}
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/*
* LSM hook implementation that allocs and transfers uctx spec to xfrm_policy.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
int selinux_xfrm_policy_alloc(struct xfrm_sec_ctx **ctxp,
selinux: add gfp argument to security_xfrm_policy_alloc and fix callers security_xfrm_policy_alloc can be called in atomic context so the allocation should be done with GFP_ATOMIC. Add an argument to let the callers choose the appropriate way. In order to do so a gfp argument needs to be added to the method xfrm_policy_alloc_security in struct security_operations and to the internal function selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic callers and leave GFP_KERNEL as before for the rest. The path that needed the gfp argument addition is: security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security -> all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -> selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only) Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also add it to security_context_to_sid which is used inside and prior to this patch did only GFP_KERNEL allocation. So add gfp argument to security_context_to_sid and adjust all of its callers as well. CC: Paul Moore <paul@paul-moore.com> CC: Dave Jones <davej@redhat.com> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Fan Du <fan.du@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: LSM list <linux-security-module@vger.kernel.org> CC: SELinux list <selinux@tycho.nsa.gov> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2014-03-07 19:44:19 +08:00
struct xfrm_user_sec_ctx *uctx,
gfp_t gfp)
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
{
selinux: add gfp argument to security_xfrm_policy_alloc and fix callers security_xfrm_policy_alloc can be called in atomic context so the allocation should be done with GFP_ATOMIC. Add an argument to let the callers choose the appropriate way. In order to do so a gfp argument needs to be added to the method xfrm_policy_alloc_security in struct security_operations and to the internal function selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic callers and leave GFP_KERNEL as before for the rest. The path that needed the gfp argument addition is: security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security -> all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -> selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only) Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also add it to security_context_to_sid which is used inside and prior to this patch did only GFP_KERNEL allocation. So add gfp argument to security_context_to_sid and adjust all of its callers as well. CC: Paul Moore <paul@paul-moore.com> CC: Dave Jones <davej@redhat.com> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Fan Du <fan.du@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: LSM list <linux-security-module@vger.kernel.org> CC: SELinux list <selinux@tycho.nsa.gov> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2014-03-07 19:44:19 +08:00
return selinux_xfrm_alloc_user(ctxp, uctx, gfp);
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}
/*
* LSM hook implementation that copies security data structure from old to new
* for policy cloning.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
int selinux_xfrm_policy_clone(struct xfrm_sec_ctx *old_ctx,
struct xfrm_sec_ctx **new_ctxp)
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
{
struct xfrm_sec_ctx *new_ctx;
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
if (!old_ctx)
return 0;
new_ctx = kmemdup(old_ctx, sizeof(*old_ctx) + old_ctx->ctx_len,
GFP_ATOMIC);
if (!new_ctx)
return -ENOMEM;
atomic_inc(&selinux_xfrm_refcount);
*new_ctxp = new_ctx;
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
return 0;
}
/*
* LSM hook implementation that frees xfrm_sec_ctx security information.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
void selinux_xfrm_policy_free(struct xfrm_sec_ctx *ctx)
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
{
selinux_xfrm_free(ctx);
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}
[LSM-IPsec]: SELinux Authorize 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: Catherine Zhang <cxzhang@watson.ibm.com> Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-09 14:39:49 +08:00
/*
* LSM hook implementation that authorizes deletion of labeled policies.
*/
int selinux_xfrm_policy_delete(struct xfrm_sec_ctx *ctx)
[LSM-IPsec]: SELinux Authorize 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: Catherine Zhang <cxzhang@watson.ibm.com> Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-09 14:39:49 +08:00
{
return selinux_xfrm_delete(ctx);
[LSM-IPsec]: SELinux Authorize 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: Catherine Zhang <cxzhang@watson.ibm.com> Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-09 14:39:49 +08:00
}
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/*
* LSM hook implementation that allocates a xfrm_sec_state, populates it using
* the supplied security context, and assigns it to the xfrm_state.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
int selinux_xfrm_state_alloc(struct xfrm_state *x,
struct xfrm_user_sec_ctx *uctx)
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
{
selinux: add gfp argument to security_xfrm_policy_alloc and fix callers security_xfrm_policy_alloc can be called in atomic context so the allocation should be done with GFP_ATOMIC. Add an argument to let the callers choose the appropriate way. In order to do so a gfp argument needs to be added to the method xfrm_policy_alloc_security in struct security_operations and to the internal function selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic callers and leave GFP_KERNEL as before for the rest. The path that needed the gfp argument addition is: security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security -> all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -> selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only) Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also add it to security_context_to_sid which is used inside and prior to this patch did only GFP_KERNEL allocation. So add gfp argument to security_context_to_sid and adjust all of its callers as well. CC: Paul Moore <paul@paul-moore.com> CC: Dave Jones <davej@redhat.com> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Fan Du <fan.du@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: LSM list <linux-security-module@vger.kernel.org> CC: SELinux list <selinux@tycho.nsa.gov> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2014-03-07 19:44:19 +08:00
return selinux_xfrm_alloc_user(&x->security, uctx, GFP_KERNEL);
}
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/*
* LSM hook implementation that allocates a xfrm_sec_state and populates based
* on a secid.
*/
int selinux_xfrm_state_alloc_acquire(struct xfrm_state *x,
struct xfrm_sec_ctx *polsec, u32 secid)
{
int rc;
struct xfrm_sec_ctx *ctx;
char *ctx_str = NULL;
int str_len;
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
if (!polsec)
return 0;
if (secid == 0)
return -EINVAL;
rc = security_sid_to_context(secid, &ctx_str, &str_len);
if (rc)
return rc;
ctx = kmalloc(sizeof(*ctx) + str_len, GFP_ATOMIC);
if (!ctx) {
rc = -ENOMEM;
goto out;
}
ctx->ctx_doi = XFRM_SC_DOI_LSM;
ctx->ctx_alg = XFRM_SC_ALG_SELINUX;
ctx->ctx_sid = secid;
ctx->ctx_len = str_len;
memcpy(ctx->ctx_str, ctx_str, str_len);
x->security = ctx;
atomic_inc(&selinux_xfrm_refcount);
out:
kfree(ctx_str);
return rc;
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}
/*
* LSM hook implementation that frees xfrm_state security information.
*/
void selinux_xfrm_state_free(struct xfrm_state *x)
{
selinux_xfrm_free(x->security);
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}
/*
* LSM hook implementation that authorizes deletion of labeled SAs.
*/
[LSM-IPsec]: SELinux Authorize 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: Catherine Zhang <cxzhang@watson.ibm.com> Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-09 14:39:49 +08:00
int selinux_xfrm_state_delete(struct xfrm_state *x)
{
return selinux_xfrm_delete(x->security);
[LSM-IPsec]: SELinux Authorize 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: Catherine Zhang <cxzhang@watson.ibm.com> Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-09 14:39:49 +08:00
}
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
/*
* LSM hook that controls access to unlabelled packets. If
* a xfrm_state is authorizable (defined by macro) then it was
* already authorized by the IPSec process. If not, then
* we need to check for unlabelled access since this may not have
* gone thru the IPSec process.
*/
int selinux_xfrm_sock_rcv_skb(u32 sk_sid, struct sk_buff *skb,
struct common_audit_data *ad)
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
{
int i;
struct sec_path *sp = skb->sp;
u32 peer_sid = SECINITSID_UNLABELED;
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
if (sp) {
for (i = 0; i < sp->len; i++) {
struct xfrm_state *x = sp->xvec[i];
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
if (x && selinux_authorizable_xfrm(x)) {
struct xfrm_sec_ctx *ctx = x->security;
peer_sid = ctx->ctx_sid;
break;
}
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}
}
/* This check even when there's no association involved is intended,
* according to Trent Jaeger, to make sure a process can't engage in
* non-IPsec communication unless explicitly allowed by policy. */
return avc_has_perm(sk_sid, peer_sid,
SECCLASS_ASSOCIATION, ASSOCIATION__RECVFROM, ad);
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}
/*
* POSTROUTE_LAST hook's XFRM processing:
* If we have no security association, then we need to determine
* whether the socket is allowed to send to an unlabelled destination.
* If we do have a authorizable security association, then it has already been
* checked in the selinux_xfrm_state_pol_flow_match hook above.
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
*/
int selinux_xfrm_postroute_last(u32 sk_sid, struct sk_buff *skb,
struct common_audit_data *ad, u8 proto)
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
{
struct dst_entry *dst;
switch (proto) {
case IPPROTO_AH:
case IPPROTO_ESP:
case IPPROTO_COMP:
/* We should have already seen this packet once before it
* underwent xfrm(s). No need to subject it to the unlabeled
* check. */
return 0;
default:
break;
}
dst = skb_dst(skb);
if (dst) {
struct dst_entry *iter;
for (iter = dst; iter != NULL; iter = iter->child) {
struct xfrm_state *x = iter->xfrm;
if (x && selinux_authorizable_xfrm(x))
return 0;
}
}
/* This check even when there's no association involved is intended,
* according to Trent Jaeger, to make sure a process can't engage in
* non-IPsec communication unless explicitly allowed by policy. */
return avc_has_perm(sk_sid, SECINITSID_UNLABELED,
SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO, ad);
[LSM-IPSec]: Per-packet access control. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-14 15:12:40 +08:00
}