Updated patchset w/James' comments
Subsystems (10)
cover Updated patchset w/James' comments
Some changes in the patchset based on James Morris' comments over the weekend, in addition I rebased the patchset against 2.6.18-rc2. For those who want/need some background and missed my posting last week I have pasted the announcement below.
Once again, please consider this patchset for inclusion into the 2.6.19 kernel.
Thanks.
--
I am posting this patchset for consideration and inclusion into the 2.6.19 kernel, it is against 2.6.18-rc1 [now rebased against 2.6.18-rc2].
This patchset introduces NetLabel, a implementation of explicit packet labeling (i.e. CIPSO), to the Linux kernel. NetLabel has been designed to have as minimal an impact on the base networking stack as possible; this includes both code changes as well as performance. I, as well as many others who have posted to various lists on earlier NetLabel patches, believe that an interoperable form of labeled networking is important for Linux's success in the Trusted OS arena currently being dominated by commercial UNIX systems. DaveM, I know you have previously posted that you feel CIPSO does not belong in the Linux kernel on principle, however, I'm hoping the arguments posted in response have softened your position ...
Earlier versions of this patchset have been posted to the netdev, SELinux, LSM and RH-LSPP mailing lists over the past couple of months. It now contains several rounds of comments and has been tested on a variety of architectures by people on the RH-LSPP mailing list over the course of the last several weeks.
If accepted into the mainline kernel, both HP and myself pledge to maintain this code.
- Notes on Performance
This past week there was a thread on the RH-LSPP list where the performance of the NetLabel patch was measured and discussed using the 2.6.17 kernel. A copy of the discussion can be found here:
* http://www.redhat.com/archives/redhat-lspp/2006-July/msg00063.html
With the conclusion being that performance should not be an issue.
Unfortunately the vanilla 2.6.18-rc1 kernel has problems on the two machines I use for performance testing so I am not currently able to update the NetLabel performance numbers for 2.6.18-rc1.
- Notes on Interoperability Testing
The NetLabel CIPSO implementation has been tested against Trusted Solaris and HP-UX CMW without problems.
- Instructions for Testing
For those of you wishing to test this patchset you will need the latest release of the netlabel_tools tarball found here:
* http://free.linux.hp.com/~pmoore/projects/linux_cipso
You also may want to make use of the "toy policy module" for SELinux which has been posted to the RH-LSPP mailing list, the archived message can be found here:
* http://www.redhat.com/archives/redhat-lspp/2006-June/msg00243.html
Thanks.
--
paul moore
linux security @ hp
PATCH 1/7 NetLabel: documentation
Documentation for the NetLabel system, this includes a basic overview of how NetLabel works, how LSM developers can integrate it into their favorite LSM, as well as documentation on the CIPSO related sysctl variables. Also, due to the difficulty of finding expired IETF drafts, I am including the IETF CIPSO draft that is the basis of the NetLabel CIPSO implementation.
--- CREDITS | 7 Documentation/00-INDEX | 2 Documentation/netlabel/00-INDEX | 10 Documentation/netlabel/cipso_ipv4.txt | 48 Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt | 791 ++++++++++++++ Documentation/netlabel/introduction.txt | 53 Documentation/netlabel/lsm_interface.txt | 47 Documentation/networking/ip-sysctl.txt | 28 8 files changed, 986 insertions(+)
CREDITS +7 -0
@@ -2384,6 +2384,13 @@ N: Thomas Molina E: [email protected] D: bug fixes, documentation, minor hackery +N: Paul Moore +E: [email protected] +D: NetLabel author +S: Hewlett-Packard +S: 110 Spit Brook Road +S: Nashua, NH 03062 + N: James Morris E: [email protected] W: http://namei.org/
Documentation/00-INDEX +2 -0
@@ -184,6 +184,8 @@ mtrr.txt - how to use PPro Memory Type Range Registers to increase performance. nbd.txt - info on a TCP implementation of a network block device. +netlabel/ + - directory with information on the NetLabel subsystem. networking/ - directory with info on various aspects of networking with Linux. nfsroot.txt
Documentation/netlabel/00-INDEX new file +10 -0
@@ -0,0 +1,10 @@ +00-INDEX + - this file. +cipso_ipv4.txt + - documentation on the IPv4 CIPSO protocol engine. +draft-ietf-cipso-ipsecurity-01.txt + - IETF draft of the CIPSO protocol, dated 16 July 1992. +introduction.txt + - NetLabel introduction, READ THIS FIRST. +lsm_interface.txt + - documentation on the NetLabel kernel security module API.
Documentation/netlabel/cipso_ipv4.txt new file +48 -0
48 lines not on this page · raw message
Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt new file +791 -0
791 lines not on this page · raw message
Documentation/netlabel/introduction.txt new file +53 -0
53 lines not on this page · raw message
Documentation/netlabel/lsm_interface.txt new file +47 -0
47 lines not on this page · raw message
Documentation/networking/ip-sysctl.txt +28 -0
@@ -369,6 +369,34 @@ tcp_slow_start_after_idle - BOOLEAN be timed out after an idle period. Default: 1 +CIPSOv4 Variables: + +cipso_cache_enable - BOOLEAN + If set, enable additions to and lookups from the CIPSO label mapping + cache. If unset, additions are ignored and lookups always result in a + miss. However, regardless of the setting the cache is still + invalidated when required when means you can safely toggle this on and + off and the cache will always be "safe". + +cipso_cache_bucket_size - INTEGER + This is the maximum size of a CIPSO label cache bucket, once the limit + is reached the "older" entries inside the bucket are tossed to make + room for the new CIPSO labels. + +cipso_rbm_optfmt - BOOLEAN + Enable the "Optimized Tag 1 Format" as defined in section 3.4.2.6 of + the CIPSO draft specification (see Documentation/netlabel for details). + This means that when set the CIPSO tag will be padded with empty + categories in order to make the packet data 32-bit aligned. + +cipso_rbm_structvalid - BOOLEAN + If set, do a very strict check of the CIPSO option when + ip_options_compile() is called. If unset, relax the checks done during + ip_options_compile(). Either way is "safe" as errors are caught else + where in the CIPSO processing code but setting this to 0 (False) should + result in less work (i.e. it should be faster) but possibile problems + with other implementations that require strict checks. + IP Variables: ip_local_port_range - 2 INTEGERS
--
paul moore
linux security @ hp
PATCH 2/7 NetLabel: core network changes
In reply to [email protected]Changes to the core network stack to support the NetLabel subsystem. This includes changes to the IPv4 option handling to support CIPSO labels, and a new NetLabel hook in inet_accept() to handle NetLabel attributes across accept() calls done by in-kernel daemons.
--- include/linux/ip.h | 1 include/net/cipso_ipv4.h | 264 ++++++++++++++++++++ include/net/inet_sock.h | 2 include/net/netlabel.h | 615 +++++++++++++++++++++++++++++++++++++++++++++++ net/ipv4/af_inet.c | 3 net/ipv4/ah4.c | 2 net/ipv4/ip_options.c | 19 + 7 files changed, 904 insertions(+), 2 deletions(-)
include/linux/ip.h +1 -0
@@ -57,6 +57,7 @@#define IPOPT_SEC (2 |IPOPT_CONTROL|IPOPT_COPY)#define IPOPT_LSRR (3 |IPOPT_CONTROL|IPOPT_COPY)#define IPOPT_TIMESTAMP (4 |IPOPT_MEASUREMENT) +#define IPOPT_CIPSO (6 |IPOPT_CONTROL|IPOPT_COPY)#define IPOPT_RR (7 |IPOPT_CONTROL)#define IPOPT_SID (8 |IPOPT_CONTROL|IPOPT_COPY)#define IPOPT_SSRR (9 |IPOPT_CONTROL|IPOPT_COPY)
include/net/cipso_ipv4.h new file +264 -0
264 lines not on this page · raw message
include/net/inet_sock.h +1 -1
@@ -51,7 +51,7 @@ struct ip_options { ts_needtime:1 , ts_needaddr:1;unsigned char router_alert; -unsigned char __pad1; +unsigned char cipso;unsigned char __pad2;unsigned char __data[0 ]; };
include/net/netlabel.h new file +615 -0
615 lines not on this page · raw message
net/ipv4/af_inet.c +3 -0
@@ -115,6 +115,7 @@#ifdef CONFIG_IP_MROUTE #include <linux/mroute.h> #endif +#include <net/netlabel.h> DEFINE_SNMP_STAT(struct linux_mib, net_statistics) __read_mostly;
@@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, strsock_graft (sk2, newsock); +netlbl_socket_inet_accept (sock, newsock); + newsock->state =SS_CONNECTED ; err =0 ;release_sock (sk2);
net/ipv4/ah4.c +1 -1
@@ -34,7 +34,7 @@ static int ip_clear_mutable_options(struswitch (*optptr) {case IPOPT_SEC :case 0x85 :/* Some "Extended Security" crap. */ -case 0x86 :/* Another "Commercial Security" crap. */ +case IPOPT_CIPSO :case IPOPT_RA :case 0x80 |21 :/* RFC1770 */ break ;
net/ipv4/ip_options.c +19 -0
@@ -24,6 +24,7 @@#include <net/ip.h> #include <net/icmp.h> #include <net/route.h> +#include <net/cipso_ipv4.h> /* * Write options to IP header, record destination address to
@@ -194,6 +195,13 @@ int ip_options_echo(struct ip_options * dopt->is_strictroute = sopt->is_strictroute; } } +if (sopt->cipso) { + optlen = sptr[sopt->cipso+1 ]; + dopt->cipso = dopt->optlen+sizeof (struct iphdr ); +memcpy (dptr, sptr+sopt->cipso, optlen); + dptr += optlen; + dopt->optlen += optlen; + }while (dopt->optlen &3 ) { *dptr++ =IPOPT_END ; dopt->optlen++;
@@ -435,6 +443,17 @@ int ip_options_compile(struct ip_optionsif (optptr[2 ] ==0 && optptr[3 ] ==0 ) opt->router_alert = optptr - iph;break ; +case IPOPT_CIPSO : +if (opt->cipso) { + pp_ptr = optptr; + goto error; + } + opt->cipso = optptr - iph; +if (cipso_v4_validate (&optptr)) { + pp_ptr = optptr; + goto error; + } +break ;case IPOPT_SEC :case IPOPT_SID :default :
--
paul moore
linux security @ hp
PATCH 3/7 NetLabel: CIPSOv4 engine
In reply to [email protected]Add support for the Commercial IP Security Option (CIPSO) to the IPv4 network stack. CIPSO has become a de-facto standard for trusted/labeled networking amongst existing Trusted Operating Systems such as Trusted Solaris, HP-UX CMW, etc. This implementation is designed to be used with the NetLabel subsystem to provide explicit packet labeling to LSM developers.
The CIPSO/IPv4 packet labeling works by the LSM calling a NetLabel API function which attaches a CIPSO label (IPv4 option) to a given socket; this in turn attaches the CIPSO label to every packet leaving the socket without any extra processing on the outbound side. On the inbound side the individual packet's sk_buff is examined through a call to a NetLabel API function to determine if a CIPSO/IPv4 label is present and if so the security attributes of the CIPSO label are returned to the caller of the NetLabel API function.
--- include/linux/sysctl.h | 4 net/ipv4/Makefile | 1 net/ipv4/cipso_ipv4.c | 1650 +++++++++++++++++++++++++++++++++++++++++++++ net/ipv4/sysctl_net_ipv4.c | 35 4 files changed, 1690 insertions(+)
include/linux/sysctl.h +4 -0
@@ -411,6 +411,10 @@ enumNET_IPV4_TCP_WORKAROUND_SIGNED_WINDOWS =115 ,NET_TCP_DMA_COPYBREAK =116 ,NET_TCP_SLOW_START_AFTER_IDLE =117 , +NET_CIPSOV4_CACHE_ENABLE =118 , +NET_CIPSOV4_CACHE_BUCKET_SIZE =119 , +NET_CIPSOV4_RBM_OPTFMT =120 , + NET_CIPSOV4_RBM_STRICTVALID=121, }; enum {
net/ipv4/Makefile +1 -0
@@ -47,6 +47,7 @@ obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vega obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o +obj-$(CONFIG_NETLABEL) += cipso_ipv4.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o
net/ipv4/cipso_ipv4.c new file +1650 -0
1,650 lines not on this page · raw message
net/ipv4/sysctl_net_ipv4.c +35 -0
@@ -17,6 +17,7 @@#include <net/ip.h> #include <net/route.h> #include <net/tcp.h> +#include <net/cipso_ipv4.h> /* From af_inet.c */ extern int sysctl_ip_nonlocal_bind;
@@ -697,6 +698,40 @@ ctl_table ipv4_table[] = { .mode = 0644, .proc_handler = &proc_dointvec }, +#ifdef CONFIG_NETLABEL + { + .ctl_name = NET_CIPSOV4_CACHE_ENABLE, + .procname = "cipso_cache_enable", + .data = &cipso_v4_cache_enabled, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { + .ctl_name = NET_CIPSOV4_CACHE_BUCKET_SIZE, + .procname = "cipso_cache_bucket_size", + .data = &cipso_v4_cache_bucketsize, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { + .ctl_name = NET_CIPSOV4_RBM_OPTFMT, + .procname = "cipso_rbm_optfmt", + .data = &cipso_v4_rbm_optfmt, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { + .ctl_name = NET_CIPSOV4_RBM_STRICTVALID, + .procname = "cipso_rbm_strictvalid", + .data = &cipso_v4_rbm_strictvalid, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, +#endif /* CONFIG_NETLABEL */ { .ctl_name = 0 } };
--
paul moore
linux security @ hp
PATCH 4/7 NetLabel: core NetLabel subsystem
In reply to [email protected]Add a new kernel subsystem, NetLabel, to provide explicit packet labeling services (CIPSO, RIPSO, etc.) to LSM developers. NetLabel is designed to work in conjunction with a LSM to intercept and decode security labels on incoming network packets as well as ensure that outgoing network packets are labeled according to the security mechanism employed by the LSM. The NetLabel subsystem is configured through a Generic NETLINK interface described in the header files included in this patch.
--- net/Makefile | 1 net/netlabel/Kconfig | 14 net/netlabel/Makefile | 16 net/netlabel/netlabel_cipso_v4.h | 217 +++++++++++++ net/netlabel/netlabel_domainhash.c | 504 ++++++++++++++++++++++++++++++ net/netlabel/netlabel_domainhash.h | 63 +++ net/netlabel/netlabel_kapi.c | 299 +++++++++++++++++ net/netlabel/netlabel_mgmt.c | 615 +++++++++++++++++++++++++++++++++++++ net/netlabel/netlabel_mgmt.h | 249 ++++++++++++++ net/netlabel/netlabel_unlabeled.h | 98 +++++ net/netlabel/netlabel_user.c | 160 +++++++++ net/netlabel/netlabel_user.h | 207 ++++++++++++ 12 files changed, 2443 insertions(+)
net/Makefile +1 -0
@@ -46,6 +46,7 @@ obj-$(CONFIG_IP_DCCP) += dccp/ obj-$(CONFIG_IP_SCTP) += sctp/ obj-$(CONFIG_IEEE80211) += ieee80211/ obj-$(CONFIG_TIPC) += tipc/ +obj-$(CONFIG_NETLABEL) += netlabel/ ifeq ($(CONFIG_NET),y) obj-$(CONFIG_SYSCTL) += sysctl_net.o
net/netlabel/Kconfig new file +14 -0
@@ -0,0 +1,14 @@ +# +# NetLabel configuration +# + +config NETLABEL + bool "NetLabel subsystem support" + depends on NET && SECURITY + default n + ---help--- + NetLabel provides support for explicit network packet labeling + protocols such as CIPSO and RIPSO. For more information see + Documentation/netlabel. + + If you are unsure, say N.
net/netlabel/Makefile new file +16 -0
@@ -0,0 +1,16 @@ +# +# Makefile for the NetLabel subsystem. +# +# Feb 9, 2006, Paul Moore <[email protected]> +# + +# base objects +obj-y := netlabel_user.o netlabel_kapi.o netlabel_domainhash.o + +# management objects +obj-y += netlabel_mgmt.o + +# protocol modules +obj-y += netlabel_unlabeled.o +obj-y += netlabel_cipso_v4.o +
net/netlabel/netlabel_cipso_v4.h new file +217 -0
217 lines not on this page · raw message
net/netlabel/netlabel_domainhash.c new file +504 -0
504 lines not on this page · raw message
net/netlabel/netlabel_domainhash.h new file +63 -0
63 lines not on this page · raw message
net/netlabel/netlabel_kapi.c new file +299 -0
299 lines not on this page · raw message
net/netlabel/netlabel_mgmt.c new file +615 -0
615 lines not on this page · raw message
net/netlabel/netlabel_mgmt.h new file +249 -0
249 lines not on this page · raw message
net/netlabel/netlabel_unlabeled.h new file +98 -0
98 lines not on this page · raw message
net/netlabel/netlabel_user.c new file +160 -0
160 lines not on this page · raw message
net/netlabel/netlabel_user.h new file +207 -0
207 lines not on this page · raw message
--
paul moore
linux security @ hp
PATCH 5/7 NetLabel: CIPSOv4 and Unlabeled packet integration
In reply to [email protected]Add CIPSO/IPv4 and unlabeled packet management to the NetLabel subsystem. The CIPSO/IPv4 changes allow the configuration of CIPSO/IPv4 within the overall NetLabel framework. The unlabeled packet changes allows NetLabel to pass unlabeled packets without error.
--- net/netlabel/netlabel_cipso_v4.c | 554 ++++++++++++++++++++++++++++++++++++++ net/netlabel/netlabel_unlabeled.c | 253 +++++++++++++++++ 2 files changed, 807 insertions(+)
net/netlabel/netlabel_cipso_v4.c new file +554 -0
@@ -0,0 +1,554 @@ +/* +* NetLabel CIPSO/IPv4 Support +* +* This file defines the CIPSO/IPv4 functions for the NetLabel system. The +* NetLabel system manages static and dynamic label mappings for network +* protocols such as CIPSO and RIPSO. +* +* Author: Paul Moore <[email protected]> +* +*/ + +/* +* (c) Copyright Hewlett-Packard Development Company, L.P., 2006 +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See +* the GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +* +*/ + +#include <linux/types.h> +#include <linux/socket.h> +#include <linux/string.h> +#include <linux/skbuff.h> +#include <net/sock.h> +#include <net/netlink.h> +#include <net/genetlink.h> +#include <net/netlabel.h> +#include <net/cipso_ipv4.h> + +#include "netlabel_user.h" +#include "netlabel_cipso_v4.h" + +/* NetLabel Generic NETLINK CIPSOv4 family */ +static struct genl_family netlbl_cipsov4_gnl_family = { + .id =GENL_ID_GENERATE , + .hdrsize =0 , + .name =NETLBL_NLTYPE_CIPSOV4_NAME , + .version =NETLBL_PROTO_VERSION , + .maxattr =0 , +}; + + +/* +* Helper Functions +*/ + +/** +* netlbl_cipsov4_doi_free - Frees a CIPSO V4 DOI definition +* @entry: the entry's RCU field +* +* Description: +* This function is designed to be used as a callback to the call_rcu() +* function so that the memory allocated to the DOI definition can be released +* safely. +* +*/ +static void netlbl_cipsov4_doi_free (struct rcu_head *entry) +{ +struct cipso_v4_doi *ptr; + + ptr = container_of(entry, struct cipso_v4_doi, rcu); +switch (ptr->type) { +case CIPSO_V4_MAP_STD : +kfree (ptr->map.std->lvl.cipso); +kfree (ptr->map.std->lvl.local); +kfree (ptr->map.std->cat.cipso); +kfree (ptr->map.std->cat.local); +break ; + } +kfree (ptr); +} + + +/* +* NetLabel Command Handlers +*/ + +/** +* netlbl_cipsov4_add_std - Adds a CIPSO V4 DOI definition +* @doi: the DOI value +* @msg: the ADD message data +* @msg_size: the size of the ADD message buffer +* +* Description: +* Create a new CIPSO_V4_MAP_STD DOI definition based on the given ADD message +* and add it to the CIPSO V4 engine. Return zero on success and non-zero on +* error. +* +*/ +static int netlbl_cipsov4_add_std (u32 doi, +const unsigned char *msg, +size_t msg_size) +{ +int ret_val = -EPERM ; +unsigned char *msg_ptr = (unsigned char *)msg; +ssize_t msg_len = msg_size; +u32 num_tags; +u32 num_lvls; +u32 num_cats; +struct cipso_v4_doi *doi_def =NULL ; +u32 iter; +u32 tmp_val_a; +u32 tmp_val_b; + +if (msg_len <NETLBL_LEN_U32 ) + goto add_std_failure; + num_tags =netlbl_getinc_u32 (&msg_ptr, &msg_len); +if (num_tags ==0 || num_tags >CIPSO_V4_TAG_MAXCNT ) + goto add_std_failure; + + doi_def =kmalloc (sizeof (*doi_def),GFP_KERNEL ); +if (doi_def ==NULL ) { + ret_val = -ENOMEM ; + goto add_std_failure; + } + doi_def->map.std =kzalloc (sizeof (*doi_def->map.std),GFP_KERNEL ); +if (doi_def->map.std ==NULL ) { + ret_val = -ENOMEM ; + goto add_std_failure; + } + doi_def->type =CIPSO_V4_MAP_STD ; + +for (iter =0 ; iter < num_tags; iter++) { +if (msg_len <NETLBL_LEN_U8 ) + goto add_std_failure; + doi_def->tags[iter] =netlbl_getinc_u8 (&msg_ptr, &msg_len); +switch (doi_def->tags[iter]) { +case CIPSO_V4_TAG_RBITMAP : +break ; +default : + goto add_std_failure; + } + } +if (iter <CIPSO_V4_TAG_MAXCNT ) + doi_def->tags[iter] =CIPSO_V4_TAG_INVALID ; + +if (msg_len <6 *NETLBL_LEN_U32 ) + goto add_std_failure; + + num_lvls =netlbl_getinc_u32 (&msg_ptr, &msg_len); +if (num_lvls ==0 ) + goto add_std_failure; + doi_def->map.std->lvl.local_size =netlbl_getinc_u32 (&msg_ptr, + &msg_len); +if (doi_def->map.std->lvl.local_size >CIPSO_V4_MAX_LOC_LVLS ) + goto add_std_failure; + doi_def->map.std->lvl.local =kcalloc (doi_def->map.std->lvl.local_size, +sizeof (u32), +GFP_KERNEL ); +if (doi_def->map.std->lvl.local ==NULL ) { + ret_val = -ENOMEM ; + goto add_std_failure; + } + doi_def->map.std->lvl.cipso_size =netlbl_getinc_u8 (&msg_ptr, + &msg_len); +if (doi_def->map.std->lvl.cipso_size >CIPSO_V4_MAX_REM_LVLS ) + goto add_std_failure; + doi_def->map.std->lvl.cipso =kcalloc (doi_def->map.std->lvl.cipso_size, +sizeof (u32), +GFP_KERNEL ); +if (doi_def->map.std->lvl.cipso ==NULL ) { + ret_val = -ENOMEM ; + goto add_std_failure; + } + + num_cats =netlbl_getinc_u32 (&msg_ptr, &msg_len); + doi_def->map.std->cat.local_size =netlbl_getinc_u32 (&msg_ptr, + &msg_len); +if (doi_def->map.std->cat.local_size >CIPSO_V4_MAX_LOC_CATS ) + goto add_std_failure; + doi_def->map.std->cat.local =kcalloc (doi_def->map.std->cat.local_size, +sizeof (u32), +GFP_KERNEL ); +if (doi_def->map.std->cat.local ==NULL ) { + ret_val = -ENOMEM ; + goto add_std_failure; + } + doi_def->map.std->cat.cipso_size =netlbl_getinc_u16 (&msg_ptr, + &msg_len); +if (doi_def->map.std->cat.cipso_size >CIPSO_V4_MAX_REM_CATS ) + goto add_std_failure; + doi_def->map.std->cat.cipso =kcalloc (doi_def->map.std->cat.cipso_size, +sizeof (u32), +GFP_KERNEL ); +if (doi_def->map.std->cat.cipso ==NULL ) { + ret_val = -ENOMEM ; + goto add_std_failure; + } + +if (msg_len < + num_lvls * (NETLBL_LEN_U32 +NETLBL_LEN_U8 ) + + num_cats * (NETLBL_LEN_U32 +NETLBL_LEN_U16 )) + goto add_std_failure; + +for (iter =0 ; iter < doi_def->map.std->lvl.cipso_size; iter++) + doi_def->map.std->lvl.cipso[iter] =CIPSO_V4_INV_LVL ; +for (iter =0 ; iter < doi_def->map.std->lvl.local_size; iter++) + doi_def->map.std->lvl.local[iter] =CIPSO_V4_INV_LVL ; +for (iter =0 ; iter < doi_def->map.std->cat.cipso_size; iter++) + doi_def->map.std->cat.cipso[iter] =CIPSO_V4_INV_CAT ; +for (iter =0 ; iter < doi_def->map.std->cat.local_size; iter++) + doi_def->map.std->cat.local[iter] =CIPSO_V4_INV_CAT ; + +for (iter =0 ; iter < num_lvls; iter++) { + tmp_val_a =netlbl_getinc_u32 (&msg_ptr, &msg_len); + tmp_val_b =netlbl_getinc_u8 (&msg_ptr, &msg_len); + +if (tmp_val_a >= doi_def->map.std->lvl.local_size || + tmp_val_b >= doi_def->map.std->lvl.cipso_size) + goto add_std_failure; + + doi_def->map.std->lvl.cipso[tmp_val_b] = tmp_val_a; + doi_def->map.std->lvl.local[tmp_val_a] = tmp_val_b; + } + +for (iter =0 ; iter < num_cats; iter++) { + tmp_val_a =netlbl_getinc_u32 (&msg_ptr, &msg_len); + tmp_val_b =netlbl_getinc_u16 (&msg_ptr, &msg_len); + +if (tmp_val_a >= doi_def->map.std->cat.local_size || + tmp_val_b >= doi_def->map.std->cat.cipso_size) + goto add_std_failure; + + doi_def->map.std->cat.cipso[tmp_val_b] = tmp_val_a; + doi_def->map.std->cat.local[tmp_val_a] = tmp_val_b; + } + + doi_def->doi = doi; + ret_val =cipso_v4_doi_add (doi_def); +if (ret_val !=0 ) + goto add_std_failure; +return 0 ; + +add_std_failure: +if (doi_def) +netlbl_cipsov4_doi_free (&doi_def->rcu); +return ret_val; +} + +/** +* netlbl_cipsov4_add_pass - Adds a CIPSO V4 DOI definition +* @doi: the DOI value +* @msg: the ADD message data +* @msg_size: the size of the ADD message buffer +* +* Description: +* Create a new CIPSO_V4_MAP_PASS DOI definition based on the given ADD message +* and add it to the CIPSO V4 engine. Return zero on success and non-zero on +* error. +* +*/ +static int netlbl_cipsov4_add_pass (u32 doi, +const unsigned char *msg, +size_t msg_size) +{ +int ret_val = -EPERM ; +unsigned char *msg_ptr = (unsigned char *)msg; +ssize_t msg_len = msg_size; +u32 num_tags; +struct cipso_v4_doi *doi_def =NULL ; +u32 iter; + +if (msg_len <NETLBL_LEN_U32 ) + goto add_pass_failure; + num_tags =netlbl_getinc_u32 (&msg_ptr, &msg_len); +if (num_tags ==0 || num_tags >CIPSO_V4_TAG_MAXCNT ) + goto add_pass_failure; + + doi_def =kmalloc (sizeof (*doi_def),GFP_KERNEL ); +if (doi_def ==NULL ) { + ret_val = -ENOMEM ; + goto add_pass_failure; + } + doi_def->type =CIPSO_V4_MAP_PASS ; + +for (iter =0 ; iter < num_tags; iter++) { +if (msg_len <NETLBL_LEN_U8 ) + goto add_pass_failure; + doi_def->tags[iter] =netlbl_getinc_u8 (&msg_ptr, &msg_len); +switch (doi_def->tags[iter]) { +case CIPSO_V4_TAG_RBITMAP : +break ; +default : + goto add_pass_failure; + } + } +if (iter <CIPSO_V4_TAG_MAXCNT ) + doi_def->tags[iter] =CIPSO_V4_TAG_INVALID ; + + doi_def->doi = doi; + ret_val =cipso_v4_doi_add (doi_def); +if (ret_val !=0 ) + goto add_pass_failure; +return 0 ; + +add_pass_failure: +if (doi_def) +netlbl_cipsov4_doi_free (&doi_def->rcu); +return ret_val; +} + +/** +* netlbl_cipsov4_add - Handle an ADD message +* @skb: the NETLINK buffer +* @info: the Generic NETLINK info block +* +* Description: +* Create a new DOI definition based on the given ADD message and add it to the +* CIPSO V4 engine. Returns zero on success, negative values on failure. +* +*/ +static int netlbl_cipsov4_add (struct sk_buff *skb,struct genl_info *info) + +{ +int ret_val = -EINVAL ; +u32 doi; +u32 map_type; +ssize_t msg_len =netlbl_netlink_payload_len (skb); +unsigned char *msg =netlbl_netlink_payload_data (skb); + + ret_val =netlbl_netlink_cap_check (skb,CAP_NET_ADMIN ); +if (ret_val !=0 ) + goto add_return; + +if (msg_len <2 *NETLBL_LEN_U32 ) + goto add_return; + + doi =netlbl_getinc_u32 (&msg, &msg_len); + map_type =netlbl_getinc_u32 (&msg, &msg_len); +switch (map_type) { +case CIPSO_V4_MAP_STD : + ret_val =netlbl_cipsov4_add_std (doi, msg, msg_len); +break ; +case CIPSO_V4_MAP_PASS : + ret_val =netlbl_cipsov4_add_pass (doi, msg, msg_len); +break ; + } + +add_return: +netlbl_netlink_send_ack (info, + netlbl_cipsov4_gnl_family.id, +NLBL_CIPSOV4_C_ACK , + -ret_val); +return ret_val; +} + +/** +* netlbl_cipsov4_list - Handle a LIST message +* @skb: the NETLINK buffer +* @info: the Generic NETLINK info block +* +* Description: +* Process a user generated LIST message and respond accordingly. Returns +* zero on success and negative values on error. +* +*/ +static int netlbl_cipsov4_list (struct sk_buff *skb,struct genl_info *info) +{ +int ret_val = -EINVAL ; +u32 doi; +unsigned char *msg =netlbl_netlink_payload_data (skb); +struct sk_buff *ans_skb; + +if (netlbl_netlink_payload_len (skb) !=NETLBL_LEN_U32 ) + goto list_failure; + + doi =netlbl_get_u32 (msg); + ans_skb =cipso_v4_doi_dump (doi,NLMSG_SPACE (GENL_HDRLEN )); +if (ans_skb ==NULL ) { + ret_val = -ENOMEM ; + goto list_failure; + } +netlbl_netlink_hdr_push (ans_skb, + info->snd_pid, +0 , +0 , + netlbl_cipsov4_gnl_family.id, +NLBL_CIPSOV4_C_LIST , + ans_skb->len); + + ret_val =netlbl_netlink_snd (ans_skb, info->snd_pid); +if (ret_val !=0 ) + goto list_failure; + +return 0 ; + +list_failure: +netlbl_netlink_send_ack (info, + netlbl_cipsov4_gnl_family.id, +NLBL_CIPSOV4_C_ACK , + -ret_val); +return ret_val; +} + +/** +* netlbl_cipsov4_listall - Handle a LISTALL message +* @skb: the NETLINK buffer +* @info: the Generic NETLINK info block +* +* Description: +* Process a user generated LISTALL message and respond accordingly. Returns +* zero on success and negative values on error. +* +*/ +static int netlbl_cipsov4_listall (struct sk_buff *skb,struct genl_info *info) +{ +int ret_val = -EINVAL ; +struct sk_buff *ans_skb; + + ans_skb =cipso_v4_doi_dump_all (NLMSG_SPACE (GENL_HDRLEN )); +if (ans_skb ==NULL ) { + ret_val = -ENOMEM ; + goto listall_failure; + } +netlbl_netlink_hdr_push (ans_skb, + info->snd_pid, +0 , +0 , + netlbl_cipsov4_gnl_family.id, +NLBL_CIPSOV4_C_LISTALL , + ans_skb->len); + + ret_val =netlbl_netlink_snd (ans_skb, info->snd_pid); +if (ret_val !=0 ) + goto listall_failure; + +return 0 ; + +listall_failure: +netlbl_netlink_send_ack (info, + netlbl_cipsov4_gnl_family.id, +NLBL_CIPSOV4_C_ACK , + -ret_val); +return ret_val; +} + +/** +* netlbl_cipsov4_remove - Handle a REMOVE message +* @skb: the NETLINK buffer +* @info: the Generic NETLINK info block +* +* Description: +* Process a user generated REMOVE message and respond accordingly. Returns +* zero on success, negative values on failure. +* +*/ +static int netlbl_cipsov4_remove (struct sk_buff *skb,struct genl_info *info) +{ +int ret_val; +u32 doi; +unsigned char *msg =netlbl_netlink_payload_data (skb); + + ret_val =netlbl_netlink_cap_check (skb,CAP_NET_ADMIN ); +if (ret_val !=0 ) + goto remove_return; + +if (netlbl_netlink_payload_len (skb) !=NETLBL_LEN_U32 ) { + ret_val = -EINVAL ; + goto remove_return; + } + + doi =netlbl_get_u32 (msg); + ret_val =cipso_v4_doi_remove (doi, netlbl_cipsov4_doi_free); + +remove_return: +netlbl_netlink_send_ack (info, + netlbl_cipsov4_gnl_family.id, +NLBL_CIPSOV4_C_ACK , + -ret_val); +return ret_val; +} + +/* +* NetLabel Generic NETLINK Command Definitions +*/ + +static struct genl_ops netlbl_cipsov4_genl_c_add = { + .cmd =NLBL_CIPSOV4_C_ADD , + .flags =0 , + .doit = netlbl_cipsov4_add, + .dumpit =NULL , +}; + +static struct genl_ops netlbl_cipsov4_genl_c_remove = { + .cmd =NLBL_CIPSOV4_C_REMOVE , + .flags =0 , + .doit = netlbl_cipsov4_remove, + .dumpit =NULL , +}; + +static struct genl_ops netlbl_cipsov4_genl_c_list = { + .cmd =NLBL_CIPSOV4_C_LIST , + .flags =0 , + .doit = netlbl_cipsov4_list, + .dumpit =NULL , +}; + +static struct genl_ops netlbl_cipsov4_genl_c_listall = { + .cmd =NLBL_CIPSOV4_C_LISTALL , + .flags =0 , + .doit = netlbl_cipsov4_listall, + .dumpit =NULL , +}; + +/* +* NetLabel Generic NETLINK Protocol Functions +*/ + +/** +* netlbl_cipsov4_genl_init - Register the CIPSOv4 NetLabel component +* +* Description: +* Register the CIPSOv4 packet NetLabel component with the Generic NETLINK +* mechanism. Returns zero on success, negative values on failure. +* +*/ +int netlbl_cipsov4_genl_init (void ) +{ +int ret_val; + + ret_val =genl_register_family (&netlbl_cipsov4_gnl_family); +if (ret_val !=0 ) +return ret_val; + + ret_val =genl_register_ops (&netlbl_cipsov4_gnl_family, + &netlbl_cipsov4_genl_c_add); +if (ret_val !=0 ) +return ret_val; + ret_val =genl_register_ops (&netlbl_cipsov4_gnl_family, + &netlbl_cipsov4_genl_c_remove); +if (ret_val !=0 ) +return ret_val; + ret_val =genl_register_ops (&netlbl_cipsov4_gnl_family, + &netlbl_cipsov4_genl_c_list); +if (ret_val !=0 ) +return ret_val; + ret_val =genl_register_ops (&netlbl_cipsov4_gnl_family, + &netlbl_cipsov4_genl_c_listall); +if (ret_val !=0 ) +return ret_val; + +return 0 ; +}
net/netlabel/netlabel_unlabeled.c new file +253 -0
253 lines not on this page · raw message
--
paul moore
linux security @ hp
PATCH 6/7 NetLabel: SELinux support
In reply to [email protected]Add NetLabel support to the SELinux LSM and modify the socket_post_create() LSM hook to return an error code. The most significant part of this patch is the addition of NetLabel hooks into the following SELinux LSM hooks:
* selinux_file_permission()
* selinux_socket_sendmsg()
* selinux_socket_post_create()
* selinux_socket_accept()
* selinux_socket_post_accept() [NEW]
* selinux_socket_sock_rcv_skb()
* selinux_socket_getpeersec_stream()
* selinux_socket_getpeersec_dgram()
The basic reasoning behind this patch is that outgoing packets are "NetLabel'd" by labeling their socket and the NetLabel security attributes are checked via the additional hook in selinux_socket_sock_rcv_skb(). NetLabel itself is only a labeling mechanism, similar to filesystem extended attributes, it is up to the SELinux enforcement mechanism to perform the actual access checks.
In addition to the changes outlined above this patch also includes some changes to the extended bitmap (ebitmap) and multi-level security (mls) code to import and export SELinux TE/MLS attributes into and out of NetLabel.
--- include/linux/security.h | 25 - net/socket.c | 17 security/dummy.c | 6 security/selinux/hooks.c | 53 ++ security/selinux/include/objsec.h | 13 security/selinux/include/selinux_netlabel.h | 100 +++++ security/selinux/ss/ebitmap.c | 152 +++++++ security/selinux/ss/ebitmap.h | 6 security/selinux/ss/mls.c | 152 +++++++ security/selinux/ss/mls.h | 21 + security/selinux/ss/services.c | 555 ++++++++++++++++++++++++++++ 11 files changed, 1070 insertions(+), 30 deletions(-)
include/linux/security.h +13 -12
@@ -1296,8 +1296,8 @@ struct security_operations {int (*unix_may_send) (struct socket * sock,struct socket * other);int (*socket_create) (int family,int type,int protocol,int kern); -void (*socket_post_create) (struct socket * sock,int family, -int type,int protocol,int kern); +int (*socket_post_create) (struct socket * sock,int family, +int type,int protocol,int kern);int (*socket_bind) (struct socket * sock,struct sockaddr * address,int addrlen); int (*socket_connect) (struct socket * sock,
@@ -2748,13 +2748,13 @@ static inline int security_socket_createreturn security_ops->socket_create (family, type, protocol, kern); } -static inline void security_socket_post_create (struct socket * sock, -int family, -int type, -int protocol,int kern) +static inline int security_socket_post_create (struct socket * sock, +int family, +int type, +int protocol,int kern) { - security_ops->socket_post_create (sock, family, type, - protocol, kern); +return security_ops->socket_post_create (sock, family, type, + protocol, kern); } static inline int security_socket_bind(struct socket * sock,
@@ -2880,11 +2880,12 @@ static inline int security_socket_createreturn 0 ; } -static inline void security_socket_post_create (struct socket * sock, -int family, -int type, -int protocol,int kern) +static inline int security_socket_post_create (struct socket * sock, +int family, +int type, +int protocol,int kern) { +return 0 ; } static inline int security_socket_bind(struct socket * sock,
net/socket.c +13 -4
@@ -973,11 +973,18 @@ int sock_create_lite(int family, int typ goto out; } -security_socket_post_create (sock, family, type, protocol,1 ); sock->type = type; + err =security_socket_post_create (sock, family, type, protocol,1 ); +if (err) + goto out_release; + out: *res = sock;return err; +out_release: +sock_release (sock); + sock =NULL ; + goto out; }/* No kernel lock held - perfect */
@@ -1213,7 +1220,9 @@ static int __sock_create(int family, int*/ module_put (net_families[family]->owner); *res = sock; -security_socket_post_create (sock, family, type, protocol, kern); + err =security_socket_post_create (sock, family, type, protocol, kern); +if (err) + goto out_release; out:net_family_read_unlock ();
@@ -1443,13 +1452,13 @@ asmlinkage long sys_accept(int fd, struc goto out_fd; } +security_socket_post_accept (sock, newsock); +/* File flags are not inherited via accept() unlike another OSes. */ fd_install (newfd, newfile); err = newfd; -security_socket_post_accept (sock, newsock); - out_put:fput_light (sock->file, fput_needed); out:
security/dummy.c +3 -3
@@ -709,10 +709,10 @@ static int dummy_socket_create (int famireturn 0 ; } -static void dummy_socket_post_create (struct socket *sock,int family,int type, -int protocol,int kern) +static int dummy_socket_post_create (struct socket *sock,int family,int type, +int protocol,int kern) { -return ; +return 0 ; } static int dummy_socket_bind (struct socket *sock, struct sockaddr *address,
security/selinux/hooks.c +42 -11
124 lines not on this page · raw message
security/selinux/include/objsec.h +13 -0
@@ -37,6 +37,16 @@ struct task_security_struct {u32 ptrace_sid;/* SID of ptrace parent */ }; +struct netlbl_security_struct { +u32 peer_sid;/* SID of the connected peer */ +enum {/* NetLabel state */ +NLBL_UNSET =0 , +NLBL_ACCEPT , +NLBL_REQUIRE , +NLBL_LABELED , + } state; +}; +struct inode_security_struct {struct inode *inode;/* back pointer to inode object */ struct list_head list;/* list of inode_security_struct */
@@ -46,6 +56,9 @@ struct inode_security_struct {unsigned char initialized;/* initialization flag */ struct semaphore sem;unsigned char inherit;/* inherit SID from parent entry */ +#ifdef CONFIG_NETLABEL +struct netlbl_security_struct netlbl; +#endif };struct file_security_struct {
security/selinux/include/selinux_netlabel.h new file +100 -0
100 lines not on this page · raw message
security/selinux/ss/ebitmap.c +152 -0
164 lines not on this page · raw message
security/selinux/ss/ebitmap.h +6 -0
@@ -69,6 +69,12 @@ static inline int ebitmap_node_get_bit(sint ebitmap_cmp (struct ebitmap *e1,struct ebitmap *e2);int ebitmap_cpy (struct ebitmap *dst,struct ebitmap *src); +int ebitmap_export (const struct ebitmap *src, +unsigned char **dst, +size_t *dst_len); +int ebitmap_import (const unsigned char *src, +size_t src_len, +struct ebitmap *dst);int ebitmap_contains (struct ebitmap *e1,struct ebitmap *e2);int ebitmap_get_bit (struct ebitmap *e,unsigned long bit);int ebitmap_set_bit (struct ebitmap *e,unsigned long bit,int value);
security/selinux/ss/mls.c +152 -0
161 lines not on this page · raw message
security/selinux/ss/mls.h +21 -0
@@ -10,6 +10,13 @@* * Copyright (C) 2004-2006 Trusted Computer Solutions, Inc. */ +/* +* Updated: Hewlett-Packard <[email protected]> +* +* Added support to import/export the MLS label +* +* (c) Copyright Hewlett-Packard Development Company, L.P., 2006 +*/ #ifndef _SS_MLS_H_#define _SS_MLS_H_
@@ -42,5 +49,19 @@ int mls_compute_sid(struct context *sconint mls_setup_user_range (struct context *fromcon,struct user_datum *user,struct context *usercon); +void mls_export_lvl (const struct context *context,u32 *low,u32 *high); +void mls_import_lvl (struct context *context,u32 low,u32 high); + +int mls_export_cat (const struct context *context, +unsigned char **low, +size_t *low_len, +unsigned char **high, +size_t *high_len); +int mls_import_cat (struct context *context, +const unsigned char *low, +size_t low_len, +const unsigned char *high, +size_t high_len); +#endif /* _SS_MLS_H */
security/selinux/ss/services.c +555 -0
588 lines not on this page · raw message
--
paul moore
linux security @ hp
PATCH 7/7 NetLabel: tie NetLabel into the Kconfig system
In reply to [email protected]Modify the net/Kconfig file to enable selecting the NetLabel Kconfig options.
--- net/Kconfig | 2 ++ 1 files changed, 2 insertions(+)
net/Kconfig +2 -0
@@ -249,6 +249,8 @@ source "net/ieee80211/Kconfig" config WIRELESS_EXT bool +source "net/netlabel/Kconfig" + endif # if NET endmenu # Networking
--
paul moore
linux security @ hp
Quoted 2 lines · On Mon, 17 Jul 2006 11:52:24 EDT, [email protected] said:
Some changes in the patchset based on James Morris' comments over the weekend, in addition I rebased the patchset against 2.6.18-rc2.
Minor comment - can you start posting these with Subject: lines that say something like:
Subject: [Patch X/Y] NetLabel-VNN:
Where 'NN' gets incremented each time you post? I almost got myself a patch set in my "to look at" queue that was half Friday's and half today's, and no good could have come from that. And yes, it's *ok* if Friday's was -v14 and today is -v15, if we're making progress towards merge-able code.. ;)
(Venkat - I'm cc'ing you as I've seen the same thing with MLSXFRM patchsets)...
Quoted 8 lines · [email protected] wrote:
Quoted 2 lines · On Mon, 17 Jul 2006 11:52:24 EDT, [email protected] said:
Some changes in the patchset based on James Morris' comments over the weekend, in addition I rebased the patchset against 2.6.18-rc2.
Minor comment - can you start posting these with Subject: lines that say something like:
Quoted 9 lines
Subject: [Patch X/Y] NetLabel-VNN:
Where 'NN' gets incremented each time you post? I almost got myself a patch set in my "to look at" queue that was half Friday's and half today's, and no good could have come from that. And yes, it's *ok* if Friday's was -v14 and today is -v15, if we're making progress towards merge-able code.. ;)
(Venkat - I'm cc'ing you as I've seen the same thing with MLSXFRM patchsets)...
Sure. Unless the patchset gets accepted it it's current form (a guy can dream can't he?) I'll mark the next round as "NetLabel-v1".
Signature · 2 lines
paul moore linux security @ hp
David Miller
maintainerRe: [PATCH 1/7] NetLabel: documentation
In reply to [email protected]From: [email protected]
Date: Mon, 17 Jul 2006 11:52:25 -0400
Quoted 3 lines
Documentation/networking/ip-sysctl.txt +3
-0+CIPSOv4 Variables: + +cipso_cache_enable - BOOLEAN
...
Quoted 1 line
+cipso_cache_bucket_size - INTEGER
...
Quoted 1 line
+cipso_rbm_optfmt - BOOLEAN
...
Quoted 1 line
+cipso_rbm_structvalid - BOOLEAN
...
We need some more information for these entries.
First, list the default value these sysctls will have. This is consistent with other entries in this file. If there is a compelling argument to support the default value, please mention it.
Second, cipso_cache_bucket_size is still opaque, there is nothing in the description with describes the units this value is specified in, nor in fact what it really controls. Does it say how deep the hash chains of the hash table are allowed to grow to? Otherwise, what does it control and what are the consequences of using different values?
David Miller
maintainerRe: [PATCH 2/7] NetLabel: core network changes
In reply to [email protected]From: [email protected]
Date: Mon, 17 Jul 2006 11:52:26 -0400
net/ipv4/af_inet.c int inet_accept(struct socket *sock, str · line 625
Quoted 9 lines
net/ipv4/af_inet.c +2
-0@@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, strsock_graft (sk2, newsock); +netlbl_socket_inet_accept (sock, newsock); + newsock->state =SS_CONNECTED ; err =0 ;release_sock (sk2);
This is only true wart I see in the patch set from my perspective.
You have security_post_accept_hook(), which gets the parent and the child socket which is all the information you need, and it seems to be invoked at the correct location.
So can you please hook into this location using the security level hook we already have? Just check sock->sk->sk_family is PF_INET at the top of that hook if you only want to handle ipv4 sockets, or something like that.
Could this work?
When preparing and argument stating why this won't work, please suggest a nicer name for this af_inet.c hook or some way to make it more generic and palatable to us.
Thanks.
net/ipv4/ah4.c static int ip_clear_mutable_options(stru · line 37
Quoted 2 lines
net/ipv4/ah4.c +1
-1-case 0x86 :/* Another "Commercial Security" crap. */ +case IPOPT_CIPSO :
I am sad to see this comment disappear :-)
David Miller
maintainerRe: [PATCH 3/7] NetLabel: CIPSOv4 engine
In reply to [email protected]From: [email protected]
Date: Mon, 17 Jul 2006 11:52:27 -0400
net/ipv4/cipso_ipv4.c line 240
Quoted 1 line
net/ipv4/cipso_ipv4.c new file +1
-0+ cipso_v4_cache[iter].lock =SPIN_LOCK_UNLOCKED ;
Please use: "spin_lock_init(&cipso_v4_cache[iter].lock);"
Re: [PATCH 2/7] NetLabel: core network changes
In reply to [email protected]* [email protected] <[email protected]> 2006-07-17 11:52
Quoted 16 lines
+ * NetLabel makes use of the Generic NETLINK mechanism as a transport layer to
+ * send messages between kernel and user space. The general format of a
+ * NetLabel message is shown below:
+ *+ * +-----------------+-------------------+--------- --- -- - + * | struct nlmsghdr | struct genlmsghdr | payload + * +-----------------+-------------------+--------- --- -- -+ *
+ * The 'nlmsghdr' and 'genlmsghdr' structs should be dealt with like normal.
+ * The payload is dependent on the subsystem specified in the
+ * 'nlmsghdr->nlmsg_type' and should be defined below, supporting functions
+ * should be defined in the corresponding net/netlabel/netlabel_<subsys>.h|c
+ * file. All of the fields in the NetLabel payload should be aligned using
+ * the alignment functions provided.
+ *
+ */
include/net/netlabel.h line 67
Quoted 5 lines
include/net/netlabel.h new file +5
-0+ +/* +* NetLabel NETLINK protocol +*/ +
Is there a reason for not using any of the existing netlink and genetlink interfaces in any of your patches? It's all duplicated code.
Re: [PATCH 2/7] NetLabel: core network changes
Quoted 19 lines · Thomas Graf
* [email protected] <[email protected]> 2006-07-17 11:52
Quoted 17 lines
+ * NetLabel makes use of the Generic NETLINK mechanism as a transport layer to
+ * send messages between kernel and user space. The general format of a
+ * NetLabel message is shown below:
+ *+ * +-----------------+-------------------+--------- --- -- - + * | struct nlmsghdr | struct genlmsghdr | payload + * +-----------------+-------------------+--------- --- -- -+ *
+ * The 'nlmsghdr' and 'genlmsghdr' structs should be dealt with like normal.
+ * The payload is dependent on the subsystem specified in the
+ * 'nlmsghdr->nlmsg_type' and should be defined below, supporting functions
+ * should be defined in the corresponding net/netlabel/netlabel_<subsys>.h|c
+ * file. All of the fields in the NetLabel payload should be aligned using
+ * the alignment functions provided.
+ *
+ */
+
Quoted 8 lines
include/net/netlabel.h line 67
Quoted 4 lines
include/net/netlabel.h new file +4
-0+/* +* NetLabel NETLINK protocol +*/ +Is there a reason for not using any of the existing netlink and genetlink interfaces in any of your patches? It's all duplicated code.
I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :)
I am using the generic netlink interface, in what I believe to be a "correct" fashion - please correct me if I'm wrong.
Signature · 2 lines
paul moore linux security @ hp
Re: [PATCH 2/7] NetLabel: core network changes
* Paul Moore <[email protected]> 2006-07-28 13:58
Quoted 7 lines
I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :)
I am using the generic netlink interface, in what I believe to be a "correct" fashion - please correct me if I'm wrong.
The netlink bits are spread around all patches so I just quoted on this comment. By adding functions like netlbl_align(), netlbl_put_u8(), netlbl_put_hdr() writing a netlink header etc. you are just duplicating the already existing interfaces found in net/netlink.h and net/genetlink.h.
Re: [PATCH 2/7] NetLabel: core network changes
Quoted 7 lines · Thomas Graf
* Paul Moore <[email protected]> 2006-07-28 13:58
Quoted 5 lines
I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :)
Quoted 8 lines
Quoted 2 lines
I am using the generic netlink interface, in what I believe to be a "correct" fashion - please correct me if I'm wrong.
The netlink bits are spread around all patches so I just quoted on this comment. By adding functions like
netlbl_align(),netlbl_put_u8(),netlbl_put_hdr()writing a netlink header etc. you are just duplicating the already existing interfaces found innet/netlink.handnet/genetlink.h.
Thanks for the clarification, I think I understand your point a bit better now.
It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons:
1. They are listed as "optional" in the documents I read
2. They add at least an extra 32 bits to each attribute
3. There seems to be plenty of users in net/ipv4 who do not make use of attributes (a *quick* look again reveals none)
4. Since I'm reading messages from userspace I can't trust the message contents regardless of it's use of attributes
5. Harder to work with in userspace without using a netlink library, which would create an extra dependency for tools which talk to the NetLabel subsystem
Basically, I saw no requirement to use the netlink attributes and no advantage so I didn't. Is this reasonable, or do you feel the use of attributes is a requirement?
Signature · 2 lines
paul moore linux security @ hp
Re: [PATCH 2/7] NetLabel: core network changes
In reply to David MillerQuoted 24 lines · David Miller
From: [email protected]
Date: Mon, 17 Jul 2006 11:52:26 -0400net/ipv4/af_inet.c int inet_accept(struct socket *sock, str · line 625
Quoted 9 lines
net/ipv4/af_inet.c +2
-0@@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, strsock_graft (sk2, newsock); +netlbl_socket_inet_accept (sock, newsock); + newsock->state =SS_CONNECTED ; err =0 ;release_sock (sk2);This is only true wart I see in the patch set from my perspective.
You have
security_post_accept_hook(), which gets the parent and the child socket which is all the information you need, and it seems to be invoked at the correct location.So can you please hook into this location using the security level hook we already have? Just check
sock->sk->sk_familyisPF_INETat the top of that hook if you only want to handle ipv4 sockets, or something like that.
Quoted 5 lines
Could this work?
When preparing and argument stating why this won't work, please suggest a nicer name for this
af_inet.chook or some way to make it more generic and palatable to us.
The only reason for having this new hook in inet_accept() is to catch all the in-kernel "daemons" who do not go through the LSM hooked accept() code path. I debated putting this hook into the patchset and in the end figured it was at least worth a shot.
I'm happy to drop this hook as it *looks* like the MLSXFRM patchset is going to make it which has some of the accept hooks I was hoping to get, but figured I stood a "snowballs chance in hell" trying to get it in solely for use with CIPSO :) I'll drop this on the next release of the NetLabel patchset and assuming both the NetLabel and the MLSXFRM patchset make it into the 2.6.19 release I'll issue another small patchset then to integrate into the new LSM hooks for accept. I'd do it now but I think it would cause too much of a mess with patch dependencies/collisions/etc.
Quoted 4 lines
net/ipv4/ah4.c static int ip_clear_mutable_options(stru · line 37
Quoted 2 lines
net/ipv4/ah4.c +1
-1-case 0x86 :/* Another "Commercial Security" crap. */ +case IPOPT_CIPSO :I am sad to see this comment disappear :-)
... and I was surprised you didn't comment about that change sooner ;)
Signature · 7 lines
paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 1/7] NetLabel: documentation
In reply to David MillerQuoted 29 lines · David Miller
From: [email protected]
Date: Mon, 17 Jul 2006 11:52:25 -0400Quoted 3 lines
Documentation/networking/ip-sysctl.txt +3
-0+CIPSOv4 Variables: + +cipso_cache_enable - BOOLEAN...
Quoted 1 line
+cipso_cache_bucket_size - INTEGER
...
Quoted 1 line
+cipso_rbm_optfmt - BOOLEAN
...
Quoted 1 line
+cipso_rbm_structvalid - BOOLEAN
...
We need some more information for these entries.
First, list the default value these sysctls will have. This is consistent with other entries in this file. If there is a compelling argument to support the default value, please mention it.
Quoted 7 lines
Second,
cipso_cache_bucket_sizeis still opaque, there is nothing in the description with describes the units this value is specified in, nor in fact what it really controls. Does it say how deep the hash chains of the hash table are allowed to grow to? Otherwise, what does it control and what are the consequences of using different values?
Okay, I'll work on the doc so to try and take care of these issues.
Signature · 2 lines
paul moore linux security @ hp
Re: [PATCH 2/7] NetLabel: core network changes
In reply to Paul Moore* Paul Moore <[email protected]> 2006-07-28 14:39
Quoted 14 lines
It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons:
1. They are listed as "optional" in the documents I read
2. They add at least an extra 32 bits to each attribute
3. There seems to be plenty of users in net/ipv4 who do not make use of attributes (a *quick* look again reveals none)
4. Since I'm reading messages from userspace I can't trust the message contents regardless of it's use of attributes
5. Harder to work with in userspace without using a netlink library, which would create an extra dependency for tools which talk to the NetLabel subsystem
Quoted 3 lines
Basically, I saw no requirement to use the netlink attributes and no advantage so I didn't. Is this reasonable, or do you feel the use of attributes is a requirement?
Not a requirement but I would encourage it. Almost all netlink families are using attributes with a few exceptions. We just used to call them rtattr defined in rtnetlink.h before the new api was added. There is one huge advantage in using attributes which is that your protocol is extendable without breaking binary interfaces.
What I'm refering to primarly are the existing functions to write netlink and genetlink headers etc.
Re: [PATCH 2/7] NetLabel: core network changes
Quoted 27 lines · Thomas Graf
* Paul Moore <[email protected]> 2006-07-28 14:39
Quoted 14 lines
It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons:
1. They are listed as "optional" in the documents I read
2. They add at least an extra 32 bits to each attribute
3. There seems to be plenty of users in net/ipv4 who do not make use of attributes (a *quick* look again reveals none)
4. Since I'm reading messages from userspace I can't trust the message contents regardless of it's use of attributes
5. Harder to work with in userspace without using a netlink library, which would create an extra dependency for tools which talk to the NetLabel subsystemQuoted 3 lines
Basically, I saw no requirement to use the netlink attributes and no advantage so I didn't. Is this reasonable, or do you feel the use of attributes is a requirement?
Not a requirement but I would encourage it. Almost all netlink families are using attributes with a few exceptions. We just used to call them rtattr defined in
rtnetlink.hbefore the new api was added. There is one huge advantage in using attributes which is that your protocol is extendable without breaking binary interfaces.
Quoted 2 lines
What I'm refering to primarly are the existing functions to write netlink and genetlink headers etc.
Okay. Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above. I won't argue the fact that attributes may make life easier when extending existing messages/interfaces but I think the existing NetLabel message format as well as the generic netlinks versioning of each message should allow plenty of room for growth in the future (if needed).
Signature · 2 lines
paul moore linux security @ hp
Re: [PATCH 2/7] NetLabel: core network changes
Quoted 10 lines · Paul Moore
Quoted 9 lines
Not a requirement but I would encourage it. Almost all netlink families are using attributes with a few exceptions. We just used to call them rtattr defined in
rtnetlink.hbefore the new api was added. There is one huge advantage in using attributes which is that your protocol is extendable without breaking binary interfaces.What I'm refering to primarly are the existing functions to write netlink and genetlink headers etc.
Quoted 7 lines
Okay. Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above. I won't argue the fact that attributes may make life easier when extending existing messages/interfaces but I think the existing NetLabel message format as well as the generic netlinks versioning of each message should allow plenty of room for growth in the future (if needed).
Attributes are usual for rtnetlink users way.
It complicates code and reading, but allows to have a lot of commands inside your message (if one has not created special field himself), thus do not breaking existing interfaces. IT can be easily avoided by introducing new commands in your protocol, which is essentially the same as new attributes. It is just another way of representing the data. For example connector (idealogical parent of gennetlink) does not have such attributes, but has similar to your structures approach, so it is only the way you like to represent your data.
Quoted 3 lines
Signature · 2 lines
paul moore linux security @ hp
Signature · 1 line
Evgeniy Polyakov
David Miller
maintainerRe: [PATCH 2/7] NetLabel: core network changes
In reply to Paul MooreFrom: Paul Moore <[email protected]>
Date: Fri, 28 Jul 2006 14:45:53 -0400
Quoted 9 lines
I'm happy to drop this hook as it *looks* like the MLSXFRM patchset is going to make it which has some of the accept hooks I was hoping to get, but figured I stood a "snowballs chance in hell" trying to get it in solely for use with CIPSO :) I'll drop this on the next release of the NetLabel patchset and assuming both the NetLabel and the MLSXFRM patchset make it into the 2.6.19 release I'll issue another small patchset then to integrate into the new LSM hooks for accept. I'd do it now but I think it would cause too much of a mess with patch dependencies/collisions/etc.
The MLSXFRM stuff is already queued up in my 2.6.19 tree at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.19.git
so you can make your work relative to that if you wish.
David Miller
maintainerRe: [PATCH 2/7] NetLabel: core network changes
In reply to Paul MooreFrom: Paul Moore <[email protected]>
Date: Fri, 28 Jul 2006 15:08:44 -0400
Quoted 3 lines
Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above.
Please switch over to the scheme which Thomas has suggested.
There are real solid reasons for doing this, even if you think your API is complete today and won't run into some of the issues he mentioned.
Re: [PATCH 2/7] NetLabel: core network changes
Quoted 9 lines · David Miller
From: Paul Moore <[email protected]>
Date: Fri, 28 Jul 2006 15:08:44 -0400Quoted 3 lines
Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above.
Please switch over to the scheme which Thomas has suggested.
Okay. I stated earlier today that I would push a new patchset out to the list this weekend or perhaps today, but in light of this I think I'll wait until I have had a chance to make this change which should be sometime next week.
Signature · 2 lines
paul moore linux security @ hp
David Miller
maintainerRe: [PATCH 2/7] NetLabel: core network changes
From: Paul Moore <[email protected]>
Date: Fri, 28 Jul 2006 16:09:15 -0400
Quoted 4 lines
Okay. I stated earlier today that I would push a new patchset out to the list this weekend or perhaps today, but in light of this I think I'll wait until I have had a chance to make this change which should be sometime next week.
Thanks a lot Paul.
I think once we flesh all of this out we can queue your code into my net-2.6.19 tree.
Thanks again.
Re: [PATCH 2/7] NetLabel: core network changes
Quoted 8 lines · David Miller
From: Paul Moore <[email protected]>
Date: Fri, 28 Jul 2006 16:09:15 -0400Quoted 4 lines
Okay. I stated earlier today that I would push a new patchset out to the list this weekend or perhaps today, but in light of this I think I'll wait until I have had a chance to make this change which should be sometime next week.
Quoted 6 lines
Thanks a lot Paul.
I think once we flesh all of this out we can queue your code into my net-2.6.19 tree.
Thanks again.
No problem, thanks for being open to some more of that "Commercial Security crap" :)
Signature · 2 lines
paul moore linux security @ hp