* [RFC 1/5] SELinux: add secctx_to_secid() LSM hook
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
@ 2007-08-07 14:14 ` Paul Moore
2007-08-07 14:14 ` [RFC 2/5] NetLabel: Add secid token support to the NetLabel secattr struct Paul Moore
` (6 subsequent siblings)
7 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-07 14:14 UTC (permalink / raw)
To: selinux; +Cc: kaigai, joe
Add a secctx_to_secid() LSM hook to go along with the existing
secid_to_secctx() LSM hook. This patch also includes a SELinux implementation
for this hook.
---
include/linux/security.h | 17 +++++++++++++++++
security/dummy.c | 6 ++++++
security/selinux/hooks.c | 6 ++++++
3 files changed, 29 insertions(+)
Index: linux-2.6_staticlbl/include/linux/security.h
===================================================================
--- linux-2.6_staticlbl.orig/include/linux/security.h
+++ linux-2.6_staticlbl/include/linux/security.h
@@ -1141,6 +1141,10 @@ struct request_sock;
* Convert secid to security context.
* @secid contains the security ID.
* @secdata contains the pointer that stores the converted security context.
+ * @secctx_to_secid:
+ * Convert security context to secid.
+ * @secid contains the pointer to the generated security ID.
+ * @secdata contains the security context.
*
* @release_secctx:
* Release the security context.
@@ -1329,6 +1333,7 @@ struct security_operations {
int (*getprocattr)(struct task_struct *p, char *name, char **value);
int (*setprocattr)(struct task_struct *p, char *name, void *value, size_t size);
int (*secid_to_secctx)(u32 secid, char **secdata, u32 *seclen);
+ int (*secctx_to_secid)(char *secdata, u32 seclen, u32 *secid);
void (*release_secctx)(char *secdata, u32 seclen);
#ifdef CONFIG_SECURITY_NETWORK
@@ -2122,6 +2127,13 @@ static inline int security_secid_to_secc
return security_ops->secid_to_secctx(secid, secdata, seclen);
}
+static inline int security_secctx_to_secid(char *secdata,
+ u32 seclen,
+ u32 *secid)
+{
+ return security_ops->secctx_to_secid(secdata, seclen, secid);
+}
+
static inline void security_release_secctx(char *secdata, u32 seclen)
{
return security_ops->release_secctx(secdata, seclen);
@@ -2800,6 +2812,11 @@ static inline int security_secid_to_secc
return -EOPNOTSUPP;
}
+static inline int secctx_to_secid(char *secdata, u32 seclen, u32 *secid)
+{
+ return -EOPNOTSUPP;
+}
+
static inline void security_release_secctx(char *secdata, u32 seclen)
{
}
Index: linux-2.6_staticlbl/security/dummy.c
===================================================================
--- linux-2.6_staticlbl.orig/security/dummy.c
+++ linux-2.6_staticlbl/security/dummy.c
@@ -926,6 +926,11 @@ static int dummy_secid_to_secctx(u32 sec
return -EOPNOTSUPP;
}
+static int dummy_secctx_to_secid(char *secdata, u32 seclen, u32 *secid)
+{
+ return -EOPNOTSUPP;
+}
+
static void dummy_release_secctx(char *secdata, u32 seclen)
{
}
@@ -1083,6 +1088,7 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, getprocattr);
set_to_dummy_if_null(ops, setprocattr);
set_to_dummy_if_null(ops, secid_to_secctx);
+ set_to_dummy_if_null(ops, secctx_to_secid);
set_to_dummy_if_null(ops, release_secctx);
#ifdef CONFIG_SECURITY_NETWORK
set_to_dummy_if_null(ops, unix_stream_connect);
Index: linux-2.6_staticlbl/security/selinux/hooks.c
===================================================================
--- linux-2.6_staticlbl.orig/security/selinux/hooks.c
+++ linux-2.6_staticlbl/security/selinux/hooks.c
@@ -4656,6 +4656,11 @@ static int selinux_secid_to_secctx(u32 s
return security_sid_to_context(secid, secdata, seclen);
}
+static int selinux_secctx_to_secid(char *secdata, u32 seclen, u32 *secid)
+{
+ return security_context_to_sid(secdata, seclen, secid);
+}
+
static void selinux_release_secctx(char *secdata, u32 seclen)
{
kfree(secdata);
@@ -4842,6 +4847,7 @@ static struct security_operations selinu
.setprocattr = selinux_setprocattr,
.secid_to_secctx = selinux_secid_to_secctx,
+ .secctx_to_secid = selinux_secctx_to_secid,
.release_secctx = selinux_release_secctx,
.unix_stream_connect = selinux_socket_unix_stream_connect,
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC 2/5] NetLabel: Add secid token support to the NetLabel secattr struct
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
2007-08-07 14:14 ` [RFC 1/5] SELinux: add secctx_to_secid() LSM hook Paul Moore
@ 2007-08-07 14:14 ` Paul Moore
2007-08-07 14:14 ` [RFC 3/5] NetLabel: add IP address family information to the netlbl_skbuff_getattr() function Paul Moore
` (5 subsequent siblings)
7 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-07 14:14 UTC (permalink / raw)
To: selinux; +Cc: kaigai, joe
This patch adds support to the NetLabel LSM secattr struct for a secid token,
paving the way for full LSM/SELinux context support. In this patch adds a fair
amount of documentation to the core NetLabel structures used as part of the
NetLabel kernel API.
---
include/net/netlabel.h | 92 +++++++++++++++++++++++++++++++++--------
net/ipv4/cipso_ipv4.c | 56 +++++++++++++++---------
security/selinux/ss/mls.c | 10 ++--
security/selinux/ss/services.c | 5 +-
4 files changed, 118 insertions(+), 45 deletions(-)
Index: linux-2.6_staticlbl/include/net/netlabel.h
===================================================================
--- linux-2.6_staticlbl.orig/include/net/netlabel.h
+++ linux-2.6_staticlbl/include/net/netlabel.h
@@ -105,17 +105,49 @@ struct netlbl_dom_map;
/* Domain mapping operations */
int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-/* LSM security attributes */
+/*
+ * LSM security attributes
+ */
+
+/**
+ * struct netlbl_lsm_cache - NetLabel LSM security attribute cache
+ * @refcount: atomic reference counter
+ * @free: LSM supplied function to free the cache data
+ * @data: LSM supplied cache data
+ *
+ * Description:
+ * This structure is provided for LSMs which wish to make use of the NetLabel
+ * caching mechanism to store LSM specific data/attributes in the NetLabel
+ * cache. If the LSM has to perform a lot of translation from the NetLabel
+ * security attributes into it's own internal representation then the cache
+ * mechanism can provide a way to eliminate some or all of that translation
+ * overhead on a cache hit.
+ *
+ */
struct netlbl_lsm_cache {
atomic_t refcount;
void (*free) (const void *data);
void *data;
};
-/* The catmap bitmap field MUST be a power of two in length and large
+
+/**
+ * struct netlbl_lsm_secattr_catmap - NetLabel LSM secattr category bitmap
+ * @startbit: the value of the lowest order bit in the bitmap
+ * @bitmap: the category bitmap
+ * @next: pointer to the next bitmap "node" or NULL
+ *
+ * Description:
+ * This structure is used to represent category bitmaps. Due to the large
+ * number of categories supported by most labeling protocols it is not
+ * practical to transfer a full bitmap internally so NetLabel adopts a sparse
+ * bitmap structure modeled after SELinux's ebitmap structure.
+ * The catmap bitmap field MUST be a power of two in length and large
* enough to hold at least 240 bits. Special care (i.e. check the code!)
* should be used when changing these values as the LSM implementation
* probably has functions which rely on the sizes of these types to speed
- * processing. */
+ * processing.
+ *
+ */
#define NETLBL_CATMAP_MAPTYPE u64
#define NETLBL_CATMAP_MAPCNT 4
#define NETLBL_CATMAP_MAPSIZE (sizeof(NETLBL_CATMAP_MAPTYPE) * 8)
@@ -127,22 +159,51 @@ struct netlbl_lsm_secattr_catmap {
NETLBL_CATMAP_MAPTYPE bitmap[NETLBL_CATMAP_MAPCNT];
struct netlbl_lsm_secattr_catmap *next;
};
+
+/**
+ * struct netlbl_lsm_secattr - NetLabel LSM security attributes
+ * @flags: indicate which attributes are contained in this structure
+ * @domain: the NetLabel LSM domain
+ * @cache: NetLabel LSM specific cache
+ * @attr.mls: MLS sensitivity label
+ * @attr.mls.cat: MLS category bitmap
+ * @attr.mls.lvl: MLS sensitivity level
+ * @attr.secid: LSM specific secid token
+ *
+ * Description:
+ * This structure is used to pass security attributes between NetLabel and the
+ * LSM modules. The flags field is used to specify which fields within the
+ * struct are valid and valid values can be created by bitwise OR'ing the
+ * NETLBL_SECATTR_* defines. The domain field is typically set by the LSM to
+ * specify domain specific configuration settings and is not usually used by
+ * NetLabel itself when returning security attributes to the LSM.
+ *
+ */
#define NETLBL_SECATTR_NONE 0x00000000
#define NETLBL_SECATTR_DOMAIN 0x00000001
#define NETLBL_SECATTR_CACHE 0x00000002
#define NETLBL_SECATTR_MLS_LVL 0x00000004
#define NETLBL_SECATTR_MLS_CAT 0x00000008
+#define NETLBL_SECATTR_SECID 0x00000010
#define NETLBL_SECATTR_CACHEABLE (NETLBL_SECATTR_MLS_LVL | \
NETLBL_SECATTR_MLS_CAT)
struct netlbl_lsm_secattr {
u32 flags;
-
+ /* there is a 4 byte hole here in 64 bit architectures which we could
+ * solve by moving the 'flags' field elsewhere in this structure but
+ * to do so would move push it out of the first cacheline, which is not
+ * desireable from a performance standpoint as in the case of an
+ * unlabeled packet (most common) the 'flags' field is the only field
+ * the LSM is likely to check */
char *domain;
-
- u32 mls_lvl;
- struct netlbl_lsm_secattr_catmap *mls_cat;
-
struct netlbl_lsm_cache *cache;
+ union {
+ struct {
+ struct netlbl_lsm_secattr_catmap *cat;
+ u32 lvl;
+ } mls;
+ u32 secid;
+ } attr;
};
/*
@@ -231,10 +292,7 @@ static inline void netlbl_secattr_catmap
*/
static inline void netlbl_secattr_init(struct netlbl_lsm_secattr *secattr)
{
- secattr->flags = 0;
- secattr->domain = NULL;
- secattr->mls_cat = NULL;
- secattr->cache = NULL;
+ memset(secattr, 0, sizeof(*secattr));
}
/**
@@ -248,11 +306,11 @@ static inline void netlbl_secattr_init(s
*/
static inline void netlbl_secattr_destroy(struct netlbl_lsm_secattr *secattr)
{
- if (secattr->cache)
- netlbl_secattr_cache_free(secattr->cache);
kfree(secattr->domain);
- if (secattr->mls_cat)
- netlbl_secattr_catmap_free(secattr->mls_cat);
+ if (secattr->flags & NETLBL_SECATTR_CACHE)
+ netlbl_secattr_cache_free(secattr->cache);
+ if (secattr->flags & NETLBL_SECATTR_MLS_CAT)
+ netlbl_secattr_catmap_free(secattr->attr.mls.cat);
}
/**
@@ -300,7 +358,7 @@ int netlbl_secattr_catmap_setrng(struct
gfp_t flags);
/*
- * LSM protocol operations
+ * LSM protocol operations (NetLabel LSM/kernel API)
*/
int netlbl_enabled(void);
int netlbl_sock_setattr(struct sock *sk,
Index: linux-2.6_staticlbl/net/ipv4/cipso_ipv4.c
===================================================================
--- linux-2.6_staticlbl.orig/net/ipv4/cipso_ipv4.c
+++ linux-2.6_staticlbl/net/ipv4/cipso_ipv4.c
@@ -884,7 +884,7 @@ static int cipso_v4_map_cat_rbm_hton(con
}
for (;;) {
- host_spot = netlbl_secattr_catmap_walk(secattr->mls_cat,
+ host_spot = netlbl_secattr_catmap_walk(secattr->attr.mls.cat,
host_spot + 1);
if (host_spot < 0)
break;
@@ -967,7 +967,7 @@ static int cipso_v4_map_cat_rbm_ntoh(con
return -EPERM;
break;
}
- ret_val = netlbl_secattr_catmap_setbit(secattr->mls_cat,
+ ret_val = netlbl_secattr_catmap_setbit(secattr->attr.mls.cat,
host_spot,
GFP_ATOMIC);
if (ret_val != 0)
@@ -1033,7 +1033,8 @@ static int cipso_v4_map_cat_enum_hton(co
u32 cat_iter = 0;
for (;;) {
- cat = netlbl_secattr_catmap_walk(secattr->mls_cat, cat + 1);
+ cat = netlbl_secattr_catmap_walk(secattr->attr.mls.cat,
+ cat + 1);
if (cat < 0)
break;
if ((cat_iter + 2) > net_cat_len)
@@ -1068,7 +1069,7 @@ static int cipso_v4_map_cat_enum_ntoh(co
u32 iter;
for (iter = 0; iter < net_cat_len; iter += 2) {
- ret_val = netlbl_secattr_catmap_setbit(secattr->mls_cat,
+ ret_val = netlbl_secattr_catmap_setbit(secattr->attr.mls.cat,
ntohs(get_unaligned((__be16 *)&net_cat[iter])),
GFP_ATOMIC);
if (ret_val != 0)
@@ -1149,7 +1150,8 @@ static int cipso_v4_map_cat_rng_hton(con
return -ENOSPC;
for (;;) {
- iter = netlbl_secattr_catmap_walk(secattr->mls_cat, iter + 1);
+ iter = netlbl_secattr_catmap_walk(secattr->attr.mls.cat,
+ iter + 1);
if (iter < 0)
break;
cat_size += (iter == 0 ? 0 : sizeof(u16));
@@ -1157,7 +1159,8 @@ static int cipso_v4_map_cat_rng_hton(con
return -ENOSPC;
array[array_cnt++] = iter;
- iter = netlbl_secattr_catmap_walk_rng(secattr->mls_cat, iter);
+ iter = netlbl_secattr_catmap_walk_rng(secattr->attr.mls.cat,
+ iter);
if (iter < 0)
return -EFAULT;
cat_size += sizeof(u16);
@@ -1210,7 +1213,7 @@ static int cipso_v4_map_cat_rng_ntoh(con
else
cat_low = 0;
- ret_val = netlbl_secattr_catmap_setrng(secattr->mls_cat,
+ ret_val = netlbl_secattr_catmap_setrng(secattr->attr.mls.cat,
cat_low,
cat_high,
GFP_ATOMIC);
@@ -1270,7 +1273,9 @@ static int cipso_v4_gentag_rbm(const str
if ((secattr->flags & NETLBL_SECATTR_MLS_LVL) == 0)
return -EPERM;
- ret_val = cipso_v4_map_lvl_hton(doi_def, secattr->mls_lvl, &level);
+ ret_val = cipso_v4_map_lvl_hton(doi_def,
+ secattr->attr.mls.lvl,
+ &level);
if (ret_val != 0)
return ret_val;
@@ -1322,12 +1327,13 @@ static int cipso_v4_parsetag_rbm(const s
ret_val = cipso_v4_map_lvl_ntoh(doi_def, tag[3], &level);
if (ret_val != 0)
return ret_val;
- secattr->mls_lvl = level;
+ secattr->attr.mls.lvl = level;
secattr->flags |= NETLBL_SECATTR_MLS_LVL;
if (tag_len > 4) {
- secattr->mls_cat = netlbl_secattr_catmap_alloc(GFP_ATOMIC);
- if (secattr->mls_cat == NULL)
+ secattr->attr.mls.cat =
+ netlbl_secattr_catmap_alloc(GFP_ATOMIC);
+ if (secattr->attr.mls.cat == NULL)
return -ENOMEM;
ret_val = cipso_v4_map_cat_rbm_ntoh(doi_def,
@@ -1335,7 +1341,7 @@ static int cipso_v4_parsetag_rbm(const s
tag_len - 4,
secattr);
if (ret_val != 0) {
- netlbl_secattr_catmap_free(secattr->mls_cat);
+ netlbl_secattr_catmap_free(secattr->attr.mls.cat);
return ret_val;
}
@@ -1369,7 +1375,9 @@ static int cipso_v4_gentag_enum(const st
if (!(secattr->flags & NETLBL_SECATTR_MLS_LVL))
return -EPERM;
- ret_val = cipso_v4_map_lvl_hton(doi_def, secattr->mls_lvl, &level);
+ ret_val = cipso_v4_map_lvl_hton(doi_def,
+ secattr->attr.mls.lvl,
+ &level);
if (ret_val != 0)
return ret_val;
@@ -1415,12 +1423,13 @@ static int cipso_v4_parsetag_enum(const
ret_val = cipso_v4_map_lvl_ntoh(doi_def, tag[3], &level);
if (ret_val != 0)
return ret_val;
- secattr->mls_lvl = level;
+ secattr->attr.mls.lvl = level;
secattr->flags |= NETLBL_SECATTR_MLS_LVL;
if (tag_len > 4) {
- secattr->mls_cat = netlbl_secattr_catmap_alloc(GFP_ATOMIC);
- if (secattr->mls_cat == NULL)
+ secattr->attr.mls.cat =
+ netlbl_secattr_catmap_alloc(GFP_ATOMIC);
+ if (secattr->attr.mls.cat == NULL)
return -ENOMEM;
ret_val = cipso_v4_map_cat_enum_ntoh(doi_def,
@@ -1428,7 +1437,7 @@ static int cipso_v4_parsetag_enum(const
tag_len - 4,
secattr);
if (ret_val != 0) {
- netlbl_secattr_catmap_free(secattr->mls_cat);
+ netlbl_secattr_catmap_free(secattr->attr.mls.cat);
return ret_val;
}
@@ -1462,7 +1471,9 @@ static int cipso_v4_gentag_rng(const str
if (!(secattr->flags & NETLBL_SECATTR_MLS_LVL))
return -EPERM;
- ret_val = cipso_v4_map_lvl_hton(doi_def, secattr->mls_lvl, &level);
+ ret_val = cipso_v4_map_lvl_hton(doi_def,
+ secattr->attr.mls.lvl,
+ &level);
if (ret_val != 0)
return ret_val;
@@ -1507,12 +1518,13 @@ static int cipso_v4_parsetag_rng(const s
ret_val = cipso_v4_map_lvl_ntoh(doi_def, tag[3], &level);
if (ret_val != 0)
return ret_val;
- secattr->mls_lvl = level;
+ secattr->attr.mls.lvl = level;
secattr->flags |= NETLBL_SECATTR_MLS_LVL;
if (tag_len > 4) {
- secattr->mls_cat = netlbl_secattr_catmap_alloc(GFP_ATOMIC);
- if (secattr->mls_cat == NULL)
+ secattr->attr.mls.cat =
+ netlbl_secattr_catmap_alloc(GFP_ATOMIC);
+ if (secattr->attr.mls.cat == NULL)
return -ENOMEM;
ret_val = cipso_v4_map_cat_rng_ntoh(doi_def,
@@ -1520,7 +1532,7 @@ static int cipso_v4_parsetag_rng(const s
tag_len - 4,
secattr);
if (ret_val != 0) {
- netlbl_secattr_catmap_free(secattr->mls_cat);
+ netlbl_secattr_catmap_free(secattr->attr.mls.cat);
return ret_val;
}
Index: linux-2.6_staticlbl/security/selinux/ss/mls.c
===================================================================
--- linux-2.6_staticlbl.orig/security/selinux/ss/mls.c
+++ linux-2.6_staticlbl/security/selinux/ss/mls.c
@@ -569,7 +569,7 @@ void mls_export_netlbl_lvl(struct contex
if (!selinux_mls_enabled)
return;
- secattr->mls_lvl = context->range.level[0].sens - 1;
+ secattr->attr.mls.lvl = context->range.level[0].sens - 1;
secattr->flags |= NETLBL_SECATTR_MLS_LVL;
}
@@ -589,7 +589,7 @@ void mls_import_netlbl_lvl(struct contex
if (!selinux_mls_enabled)
return;
- context->range.level[0].sens = secattr->mls_lvl + 1;
+ context->range.level[0].sens = secattr->attr.mls.lvl + 1;
context->range.level[1].sens = context->range.level[0].sens;
}
@@ -612,8 +612,8 @@ int mls_export_netlbl_cat(struct context
return 0;
rc = ebitmap_netlbl_export(&context->range.level[0].cat,
- &secattr->mls_cat);
- if (rc == 0 && secattr->mls_cat != NULL)
+ &secattr->attr.mls.cat);
+ if (rc == 0 && secattr->attr.mls.cat != NULL)
secattr->flags |= NETLBL_SECATTR_MLS_CAT;
return rc;
@@ -640,7 +640,7 @@ int mls_import_netlbl_cat(struct context
return 0;
rc = ebitmap_netlbl_import(&context->range.level[0].cat,
- secattr->mls_cat);
+ secattr->attr.mls.cat);
if (rc != 0)
goto import_netlbl_cat_failure;
Index: linux-2.6_staticlbl/security/selinux/ss/services.c
===================================================================
--- linux-2.6_staticlbl.orig/security/selinux/ss/services.c
+++ linux-2.6_staticlbl/security/selinux/ss/services.c
@@ -2498,6 +2498,9 @@ int security_netlbl_secattr_to_sid(struc
default:
goto netlbl_secattr_to_sid_return;
}
+ } else if (secattr->flags & NETLBL_SECATTR_SECID) {
+ *sid = secattr->attr.secid;
+ rc = 0;
} else if (secattr->flags & NETLBL_SECATTR_MLS_LVL) {
ctx = sidtab_search(&sidtab, base_sid);
if (ctx == NULL)
@@ -2509,7 +2512,7 @@ int security_netlbl_secattr_to_sid(struc
mls_import_netlbl_lvl(&ctx_new, secattr);
if (secattr->flags & NETLBL_SECATTR_MLS_CAT) {
if (ebitmap_netlbl_import(&ctx_new.range.level[0].cat,
- secattr->mls_cat) != 0)
+ secattr->attr.mls.cat) != 0)
goto netlbl_secattr_to_sid_return;
ctx_new.range.level[1].cat.highbit =
ctx_new.range.level[0].cat.highbit;
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC 3/5] NetLabel: add IP address family information to the netlbl_skbuff_getattr() function
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
2007-08-07 14:14 ` [RFC 1/5] SELinux: add secctx_to_secid() LSM hook Paul Moore
2007-08-07 14:14 ` [RFC 2/5] NetLabel: Add secid token support to the NetLabel secattr struct Paul Moore
@ 2007-08-07 14:14 ` Paul Moore
2007-08-07 14:14 ` [RFC 4/5] NetLabel: introduce static network labels for unlabeled connections Paul Moore
` (4 subsequent siblings)
7 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-07 14:14 UTC (permalink / raw)
To: selinux; +Cc: kaigai, joe
In order to do any sort of IP header inspection of incoming packets we need to
know which address family, AF_INET/AF_INET6/etc., it belongs to and since the
sk_buff structure does not store this information we need to pass along the
address family separate from the packet itself.
---
include/net/netlabel.h | 2 ++
net/netlabel/netlabel_kapi.c | 2 ++
security/selinux/hooks.c | 24 ++++++++++++++++++------
security/selinux/include/netlabel.h | 8 +++++++-
security/selinux/netlabel.c | 12 +++++++++---
5 files changed, 38 insertions(+), 10 deletions(-)
Index: linux-2.6_staticlbl/include/net/netlabel.h
===================================================================
--- linux-2.6_staticlbl.orig/include/net/netlabel.h
+++ linux-2.6_staticlbl/include/net/netlabel.h
@@ -366,6 +366,7 @@ int netlbl_sock_setattr(struct sock *sk,
int netlbl_sock_getattr(struct sock *sk,
struct netlbl_lsm_secattr *secattr);
int netlbl_skbuff_getattr(const struct sk_buff *skb,
+ u16 family,
struct netlbl_lsm_secattr *secattr);
void netlbl_skbuff_err(struct sk_buff *skb, int error);
@@ -418,6 +419,7 @@ static inline int netlbl_sock_getattr(st
return -ENOSYS;
}
static inline int netlbl_skbuff_getattr(const struct sk_buff *skb,
+ u16 family,
struct netlbl_lsm_secattr *secattr)
{
return -ENOSYS;
Index: linux-2.6_staticlbl/net/netlabel/netlabel_kapi.c
===================================================================
--- linux-2.6_staticlbl.orig/net/netlabel/netlabel_kapi.c
+++ linux-2.6_staticlbl/net/netlabel/netlabel_kapi.c
@@ -331,6 +331,7 @@ int netlbl_sock_getattr(struct sock *sk,
/**
* netlbl_skbuff_getattr - Determine the security attributes of a packet
* @skb: the packet
+ * @family: protocol family
* @secattr: the security attributes
*
* Description:
@@ -341,6 +342,7 @@ int netlbl_sock_getattr(struct sock *sk,
*
*/
int netlbl_skbuff_getattr(const struct sk_buff *skb,
+ u16 family,
struct netlbl_lsm_secattr *secattr)
{
if (CIPSO_V4_OPTEXIST(skb) &&
Index: linux-2.6_staticlbl/security/selinux/hooks.c
===================================================================
--- linux-2.6_staticlbl.orig/security/selinux/hooks.c
+++ linux-2.6_staticlbl/security/selinux/hooks.c
@@ -3129,6 +3129,7 @@ static int selinux_parse_skb(struct sk_b
/**
* selinux_skb_extlbl_sid - Determine the external label of a packet
* @skb: the packet
+ * @family: protocol family
* @sid: the packet's SID
*
* Description:
@@ -3141,13 +3142,16 @@ static int selinux_parse_skb(struct sk_b
* selinux_netlbl_skbuff_getsid().
*
*/
-static void selinux_skb_extlbl_sid(struct sk_buff *skb, u32 *sid)
+static void selinux_skb_extlbl_sid(struct sk_buff *skb,
+ u16 family,
+ u32 *sid)
{
u32 xfrm_sid;
u32 nlbl_sid;
selinux_skb_xfrm_sid(skb, &xfrm_sid);
if (selinux_netlbl_skbuff_getsid(skb,
+ family,
(xfrm_sid == SECSID_NULL ?
SECINITSID_NETMSG : xfrm_sid),
&nlbl_sid) != 0)
@@ -3635,7 +3639,7 @@ static int selinux_socket_sock_rcv_skb(s
if (err)
goto out;
- err = selinux_netlbl_sock_rcv_skb(sksec, skb, &ad);
+ err = selinux_netlbl_sock_rcv_skb(sksec, skb, family, &ad);
if (err)
goto out;
@@ -3692,11 +3696,19 @@ static int selinux_socket_getpeersec_dgr
{
u32 peer_secid = SECSID_NULL;
int err = 0;
+ u16 family;
+
+ if (sock)
+ family = sock->sk->sk_family;
+ else if (skb->sk)
+ family = skb->sk->sk_family;
+ else
+ family = PF_UNSPEC;
- if (sock && sock->sk->sk_family == PF_UNIX)
+ if (sock && family == PF_UNIX)
selinux_get_inode_sid(SOCK_INODE(sock), &peer_secid);
else if (skb)
- selinux_skb_extlbl_sid(skb, &peer_secid);
+ selinux_skb_extlbl_sid(skb, family, &peer_secid);
if (peer_secid == SECSID_NULL)
err = -EINVAL;
@@ -3757,7 +3769,7 @@ static int selinux_inet_conn_request(str
u32 newsid;
u32 peersid;
- selinux_skb_extlbl_sid(skb, &peersid);
+ selinux_skb_extlbl_sid(skb, sk->sk_family, &peersid);
if (peersid == SECSID_NULL) {
req->secid = sksec->sid;
req->peer_secid = SECSID_NULL;
@@ -3795,7 +3807,7 @@ static void selinux_inet_conn_establishe
{
struct sk_security_struct *sksec = sk->sk_security;
- selinux_skb_extlbl_sid(skb, &sksec->peer_sid);
+ selinux_skb_extlbl_sid(skb, sk->sk_family, &sksec->peer_sid);
}
static void selinux_req_classify_flow(const struct request_sock *req,
Index: linux-2.6_staticlbl/security/selinux/include/netlabel.h
===================================================================
--- linux-2.6_staticlbl.orig/security/selinux/include/netlabel.h
+++ linux-2.6_staticlbl/security/selinux/include/netlabel.h
@@ -46,13 +46,17 @@ void selinux_netlbl_sk_security_init(str
void selinux_netlbl_sk_security_clone(struct sk_security_struct *ssec,
struct sk_security_struct *newssec);
-int selinux_netlbl_skbuff_getsid(struct sk_buff *skb, u32 base_sid, u32 *sid);
+int selinux_netlbl_skbuff_getsid(struct sk_buff *skb,
+ u16 family,
+ u32 base_sid,
+ u32 *sid);
void selinux_netlbl_sock_graft(struct sock *sk, struct socket *sock);
int selinux_netlbl_socket_post_create(struct socket *sock);
int selinux_netlbl_inode_permission(struct inode *inode, int mask);
int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec,
struct sk_buff *skb,
+ u16 family,
struct avc_audit_data *ad);
int selinux_netlbl_socket_setsockopt(struct socket *sock,
int level,
@@ -83,6 +87,7 @@ static inline void selinux_netlbl_sk_sec
}
static inline int selinux_netlbl_skbuff_getsid(struct sk_buff *skb,
+ u16 family,
u32 base_sid,
u32 *sid)
{
@@ -106,6 +111,7 @@ static inline int selinux_netlbl_inode_p
}
static inline int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec,
struct sk_buff *skb,
+ u16 family,
struct avc_audit_data *ad)
{
return 0;
Index: linux-2.6_staticlbl/security/selinux/netlabel.c
===================================================================
--- linux-2.6_staticlbl.orig/security/selinux/netlabel.c
+++ linux-2.6_staticlbl/security/selinux/netlabel.c
@@ -141,6 +141,7 @@ void selinux_netlbl_sk_security_clone(st
/**
* selinux_netlbl_skbuff_getsid - Get the sid of a packet using NetLabel
* @skb: the packet
+ * @family: protocol family
* @base_sid: the SELinux SID to use as a context for MLS only attributes
* @sid: the SID
*
@@ -150,7 +151,10 @@ void selinux_netlbl_sk_security_clone(st
* assign to the packet. Returns zero on success, negative values on failure.
*
*/
-int selinux_netlbl_skbuff_getsid(struct sk_buff *skb, u32 base_sid, u32 *sid)
+int selinux_netlbl_skbuff_getsid(struct sk_buff *skb,
+ u16 family,
+ u32 base_sid,
+ u32 *sid)
{
int rc;
struct netlbl_lsm_secattr secattr;
@@ -161,7 +165,7 @@ int selinux_netlbl_skbuff_getsid(struct
}
netlbl_secattr_init(&secattr);
- rc = netlbl_skbuff_getattr(skb, &secattr);
+ rc = netlbl_skbuff_getattr(skb, family, &secattr);
if (rc == 0 && secattr.flags != NETLBL_SECATTR_NONE) {
rc = security_netlbl_secattr_to_sid(&secattr, base_sid, sid);
if (rc == 0 &&
@@ -289,6 +293,7 @@ int selinux_netlbl_inode_permission(stru
* selinux_netlbl_sock_rcv_skb - Do an inbound access check using NetLabel
* @sksec: the sock's sk_security_struct
* @skb: the packet
+ * @family: protocol family
* @ad: the audit data
*
* Description:
@@ -299,6 +304,7 @@ int selinux_netlbl_inode_permission(stru
*/
int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec,
struct sk_buff *skb,
+ u16 family,
struct avc_audit_data *ad)
{
int rc;
@@ -310,7 +316,7 @@ int selinux_netlbl_sock_rcv_skb(struct s
return 0;
netlbl_secattr_init(&secattr);
- rc = netlbl_skbuff_getattr(skb, &secattr);
+ rc = netlbl_skbuff_getattr(skb, family, &secattr);
if (rc == 0 && secattr.flags != NETLBL_SECATTR_NONE) {
rc = security_netlbl_secattr_to_sid(&secattr,
SECINITSID_NETMSG,
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC 4/5] NetLabel: introduce static network labels for unlabeled connections
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
` (2 preceding siblings ...)
2007-08-07 14:14 ` [RFC 3/5] NetLabel: add IP address family information to the netlbl_skbuff_getattr() function Paul Moore
@ 2007-08-07 14:14 ` Paul Moore
2007-08-07 14:14 ` [RFC 5/5] NetLabel: add auditing to the static labeling mechanism Paul Moore
` (3 subsequent siblings)
7 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-07 14:14 UTC (permalink / raw)
To: selinux; +Cc: kaigai, joe
Most trusted OSs, with the exception of Linux, have the ability to specify
static security labels for unlabeled networks. This patch adds this ability to
the NetLabel packet labeling framework.
If the NetLabel subsystem is called to determine the security attributes of an
incoming packet it first checks to see if any recognized NetLabel packet
labeling protocols are in-use on the packet. If none can be found then the
unlabled connection table is queried and based on the packets incoming
interface and address it is matched with a security label as configured by the
administrator using the netlabel_tools package. The matching security label is
returned to the caller just as if the packet was explicitly labeled using a
labeling protocol.
---
include/net/netlabel.h | 6
net/netlabel/netlabel_kapi.c | 16
net/netlabel/netlabel_unlabeled.c | 1168 +++++++++++++++++++++++++++++++++++++-
net/netlabel/netlabel_unlabeled.h | 90 ++
4 files changed, 1262 insertions(+), 18 deletions(-)
Index: linux-2.6_staticlbl/include/net/netlabel.h
===================================================================
--- linux-2.6_staticlbl.orig/include/net/netlabel.h
+++ linux-2.6_staticlbl/include/net/netlabel.h
@@ -67,7 +67,11 @@
* NetLabel NETLINK protocol
*/
-#define NETLBL_PROTO_VERSION 1
+/* NetLabel NETLINK protocol version
+ * 1: initial version
+ * 2: added static labels for unlabeled connections
+ */
+#define NETLBL_PROTO_VERSION 2
/* NetLabel NETLINK types/families */
#define NETLBL_NLTYPE_NONE 0
Index: linux-2.6_staticlbl/net/netlabel/netlabel_kapi.c
===================================================================
--- linux-2.6_staticlbl.orig/net/netlabel/netlabel_kapi.c
+++ linux-2.6_staticlbl/net/netlabel/netlabel_kapi.c
@@ -311,7 +311,7 @@ socket_setattr_return:
* @secattr: the security attributes
*
* Description:
- * Examines the given sock to see any NetLabel style labeling has been
+ * Examines the given sock to see if any NetLabel style labeling has been
* applied to the sock, if so it parses the socket label and returns the
* security attributes in @secattr. Returns zero on success, negative values
* on failure.
@@ -319,13 +319,7 @@ socket_setattr_return:
*/
int netlbl_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr *secattr)
{
- int ret_val;
-
- ret_val = cipso_v4_sock_getattr(sk, secattr);
- if (ret_val == 0)
- return 0;
-
- return netlbl_unlabel_getattr(secattr);
+ return cipso_v4_sock_getattr(sk, secattr);
}
/**
@@ -349,7 +343,7 @@ int netlbl_skbuff_getattr(const struct s
cipso_v4_skbuff_getattr(skb, secattr) == 0)
return 0;
- return netlbl_unlabel_getattr(secattr);
+ return netlbl_unlabel_getattr(skb, family, secattr);
}
/**
@@ -433,6 +427,10 @@ static int __init netlbl_init(void)
if (ret_val != 0)
goto init_failure;
+ ret_val = netlbl_unlabel_init(NETLBL_UNLHSH_BITSIZE);
+ if (ret_val != 0)
+ goto init_failure;
+
ret_val = netlbl_netlink_init();
if (ret_val != 0)
goto init_failure;
Index: linux-2.6_staticlbl/net/netlabel/netlabel_unlabeled.c
===================================================================
--- linux-2.6_staticlbl.orig/net/netlabel/netlabel_unlabeled.c
+++ linux-2.6_staticlbl/net/netlabel/netlabel_unlabeled.c
@@ -36,9 +36,18 @@
#include <linux/string.h>
#include <linux/skbuff.h>
#include <linux/audit.h>
+#include <linux/in.h>
+#include <linux/in6.h>
+#include <linux/ip.h>
+#include <linux/ipv6.h>
+#include <linux/notifier.h>
+#include <linux/netdevice.h>
+#include <linux/security.h>
#include <net/sock.h>
#include <net/netlink.h>
#include <net/genetlink.h>
+#include <net/ip.h>
+#include <net/ipv6.h>
#include <net/netlabel.h>
#include <asm/bug.h>
@@ -46,12 +55,68 @@
#include "netlabel_user.h"
#include "netlabel_domainhash.h"
#include "netlabel_unlabeled.h"
+#include "netlabel_mgmt.h"
+
+/* The unlabeled connection hash table which we use to map network interfaces
+ * and addresses of unlabeled packets to a user specified secid value for the
+ * LSM. The hash table is used to lookup the network interface entry
+ * (struct netlbl_unlhsh_iface) and then the interface entry is used to
+ * lookup an IP address match from an ordered list. If a network interface
+ * match can not be found in the hash table then the default entry
+ * (netlbl_unlhsh_def) is used. The IP address entry list
+ * (struct netlbl_unlhsh_addr) is ordered such that the entries with a
+ * larger netmask come first.
+ */
+struct netlbl_unlhsh_tbl {
+ struct list_head *tbl;
+ u32 size;
+};
+struct netlbl_unlhsh_addr4 {
+ __be32 addr;
+ __be32 mask;
+ u32 secid;
+
+ u32 valid;
+ struct list_head list;
+ struct rcu_head rcu;
+};
+struct netlbl_unlhsh_addr6 {
+ struct in6_addr addr;
+ struct in6_addr mask;
+ u32 secid;
+
+ u32 valid;
+ struct list_head list;
+ struct rcu_head rcu;
+};
+struct netlbl_unlhsh_iface {
+ int ifindex;
+ struct list_head addr4_list;
+ struct list_head addr6_list;
+
+ u32 valid;
+ struct list_head list;
+ struct rcu_head rcu;
+};
+
+/* Argument struct for netlbl_unlhsh_walk() */
+struct netlbl_unlhsh_walk_arg {
+ struct netlink_callback *nl_cb;
+ struct sk_buff *skb;
+ u32 seq;
+};
+
+/* Unlabeled connection hash table */
+/* XXX - updates should be so rare that having one spinlock for the entire
+ * hash table should be okay */
+static DEFINE_SPINLOCK(netlbl_unlhsh_lock);
+static struct netlbl_unlhsh_tbl *netlbl_unlhsh = NULL;
/* Accept unlabeled packets flag */
static DEFINE_SPINLOCK(netlabel_unlabel_acceptflg_lock);
static u8 netlabel_unlabel_acceptflg = 0;
-/* NetLabel Generic NETLINK CIPSOv4 family */
+/* NetLabel Generic NETLINK unlabeled family */
static struct genl_family netlbl_unlabel_gnl_family = {
.id = GENL_ID_GENERATE,
.hdrsize = 0,
@@ -63,10 +128,763 @@ static struct genl_family netlbl_unlabel
/* NetLabel Netlink attribute policy */
static const struct nla_policy netlbl_unlabel_genl_policy[NLBL_UNLABEL_A_MAX + 1] = {
[NLBL_UNLABEL_A_ACPTFLG] = { .type = NLA_U8 },
+ [NLBL_UNLABEL_A_IPV6ADDR] = { .type = NLA_BINARY,
+ .len = sizeof(struct in6_addr) },
+ [NLBL_UNLABEL_A_IPV6MASK] = { .type = NLA_BINARY,
+ .len = sizeof(struct in6_addr) },
+ [NLBL_UNLABEL_A_IPV4ADDR] = { .type = NLA_BINARY,
+ .len = sizeof(struct in_addr) },
+ [NLBL_UNLABEL_A_IPV4MASK] = { .type = NLA_BINARY,
+ .len = sizeof(struct in_addr) },
+ [NLBL_UNLABEL_A_IFACE] = { .type = NLA_NUL_STRING,
+ .len = IFNAMSIZ - 1 },
+ [NLBL_UNLABEL_A_SECCTX] = { .type = NLA_BINARY }
};
/*
- * Helper Functions
+ * Unlabeled Connection Hash Table Functions
+ */
+
+/**
+ * netlbl_unlhsh_free_addr4 - Frees an IPv4 address entry from the hash table
+ * @entry: the entry's RCU field
+ *
+ * Description:
+ * This function is designed to be used as a callback to the call_rcu()
+ * function so that memory allocated to a hash table address entry can be
+ * released safely.
+ *
+ */
+static void netlbl_unlhsh_free_addr4(struct rcu_head *entry)
+{
+ struct netlbl_unlhsh_addr4 *ptr;
+
+ ptr = container_of(entry, struct netlbl_unlhsh_addr4, rcu);
+ kfree(ptr);
+}
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+/**
+ * netlbl_unlhsh_free_addr6 - Frees an IPv6 address entry from the hash table
+ * @entry: the entry's RCU field
+ *
+ * Description:
+ * This function is designed to be used as a callback to the call_rcu()
+ * function so that memory allocated to a hash table address entry can be
+ * released safely.
+ *
+ */
+static void netlbl_unlhsh_free_addr6(struct rcu_head *entry)
+{
+ struct netlbl_unlhsh_addr6 *ptr;
+
+ ptr = container_of(entry, struct netlbl_unlhsh_addr6, rcu);
+ kfree(ptr);
+}
+#endif /* IPv6 */
+
+/**
+ * netlbl_unlhsh_free_iface - Frees an interface entry from the hash table
+ * @entry: the entry's RCU field
+ *
+ * Description:
+ * This function is designed to be used as a callback to the call_rcu()
+ * function so that memory allocated to a hash table interface entry can be
+ * released safely. It is important to note that this function does not free
+ * the IPv4 and IPv6 address lists contained as part of an interface entry. It
+ * is up to the rest of the code to make sure an interface entry is only freed
+ * once it's address lists are empty.
+ *
+ */
+static void netlbl_unlhsh_free_iface(struct rcu_head *entry)
+{
+ struct netlbl_unlhsh_iface *iface;
+
+ iface = container_of(entry, struct netlbl_unlhsh_iface, rcu);
+ kfree(iface);
+}
+
+/**
+ * netlbl_unlhsh_hash - Hashing function for the hash table
+ * @ifindex: the network interface/device to hash
+ *
+ * Description:
+ * This is the hashing function for the unlabeled hash table, it returns the
+ * bucket number for the given device/interface. The caller is responsible for
+ * calling the rcu_read_[un]lock() functions.
+ *
+ */
+static u32 netlbl_unlhsh_hash(int ifindex)
+{
+ /* this is taken _almost_ directly from
+ * security/selinux/netif.c:sel_netif_hasfn() as they do pretty much
+ * the same thing */
+ return ifindex & (rcu_dereference(netlbl_unlhsh)->size - 1);
+}
+
+/**
+ * netlbl_unlhsh_search_addr4 - Search for a matching IPv4 address entry
+ * @addr: IPv4 address
+ * @iface: the network interface entry
+ *
+ * Description:
+ * Searches the IPv4 address list of the network interface specified by @iface.
+ * If a matching address entry is found it is returned, otherwise NULL is
+ * returned. The caller is responsible for calling the rcu_read_[un]lock()
+ * functions.
+ *
+ */
+static struct netlbl_unlhsh_addr4 *netlbl_unlhsh_search_addr4(
+ __be32 addr,
+ const struct netlbl_unlhsh_iface *iface)
+{
+ struct netlbl_unlhsh_addr4 *iter;
+
+ list_for_each_entry_rcu(iter, &iface->addr4_list, list)
+ if (iter->valid && (addr & iter->mask) == iter->addr)
+ return iter;
+
+ return NULL;
+}
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+/**
+ * netlbl_unlhsh_search_addr6 - Search for a matching IPv6 address entry
+ * @addr: IPv6 address
+ * @iface: the network interface entry
+ *
+ * Description:
+ * Searches the IPv6 address list of the network interface specified by @iface.
+ * If a matching address entry is found it is returned, otherwise NULL is
+ * returned. The caller is responsible for calling the rcu_read_[un]lock()
+ * functions.
+ *
+ */
+static struct netlbl_unlhsh_addr6 *netlbl_unlhsh_search_addr6(
+ const struct in6_addr *addr,
+ const struct netlbl_unlhsh_iface *iface)
+{
+ struct netlbl_unlhsh_addr6 *iter;
+
+ /* We could use ipv6_masked_addr_cmp() below, but our way should be a
+ * bit quicker and we want this to be fast. */
+ list_for_each_entry_rcu(iter, &iface->addr6_list, list)
+ if (iter->valid &&
+ ((addr->s6_addr32[0] & iter->mask.s6_addr32[0])
+ == iter->addr.s6_addr32[0]) &&
+ ((addr->s6_addr32[1] & iter->mask.s6_addr32[1])
+ == iter->addr.s6_addr32[1]) &&
+ ((addr->s6_addr32[2] & iter->mask.s6_addr32[2])
+ == iter->addr.s6_addr32[2]) &&
+ ((addr->s6_addr32[3] & iter->mask.s6_addr32[3])
+ == iter->addr.s6_addr32[3]))
+ return iter;
+
+ return NULL;
+}
+#endif /* IPv6 */
+
+/**
+ * netlbl_unlhsh_search_iface - Search for a matching interface entry
+ * @ifindex: the network interface
+ *
+ * Description:
+ * Searches the unlabeled connection hash table and returns a pointer to the
+ * interface entry which matches @ifindex. If no match is found the NULL is
+ * returned. The caller is responsible for calling the rcu_read_[un]lock()
+ * functions.
+ *
+ */
+static struct netlbl_unlhsh_iface *netlbl_unlhsh_search_iface(int ifindex)
+{
+ u32 bkt;
+ struct netlbl_unlhsh_iface *iter;
+
+ bkt = netlbl_unlhsh_hash(ifindex);
+ list_for_each_entry_rcu(iter,
+ &rcu_dereference(netlbl_unlhsh)->tbl[bkt],
+ list)
+ if (iter->valid && iter->ifindex == ifindex)
+ return iter;
+
+ return NULL;
+}
+
+/**
+ * netlbl_unlhsh_search - Search for a matching unlabeled connection entry
+ * @skb: the incoming packet
+ * @family: protocol family
+ *
+ * Description:
+ * Searches through the unlabeled connection hash table to find an entry which
+ * matches the packet specified by @skb. If a matching entry is found the
+ * secid token for that entry is returned, otherwise zero if returned. The
+ * caller is responsible for calling the rcu_read_[un]lock() functions.
+ *
+ */
+static u32 netlbl_unlhsh_search(const struct sk_buff *skb, u16 family)
+{
+ struct iphdr *hdr4;
+ struct ipv6hdr *hdr6;
+ struct netlbl_unlhsh_addr4 *addr4;
+ struct netlbl_unlhsh_addr6 *addr6;
+ struct netlbl_unlhsh_iface *iface;
+
+ iface = netlbl_unlhsh_search_iface(skb->iif);
+ if (iface == NULL)
+ return 0;
+
+ switch (family) {
+ case PF_INET:
+ hdr4 = ip_hdr(skb);
+ addr4 = netlbl_unlhsh_search_addr4(hdr4->saddr, iface);
+ if (addr4 != NULL)
+ return addr4->secid;
+ break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case PF_INET6:
+ hdr6 = ipv6_hdr(skb);
+ addr6 = netlbl_unlhsh_search_addr6(&hdr6->saddr, iface);
+ if (addr6 != NULL)
+ return addr6->secid;
+ break;
+#endif /* IPv6 */
+ }
+
+ return 0;
+}
+
+/**
+ * netlbl_unlhsh_walk - Iterate through the unlabeled connection hash table
+ * @skip_bkt: the number of hash buckets to skip at the start
+ * @skip_chain: the number of interface entries to skip
+ * @skip_addr4: the number of IPv4 entries to skip
+ * @skip_addr6: the number of IPv6 entries to skip
+ * @callback: callback for each entry
+ * @cb_arg: argument for the callback function
+ *
+ * Description:
+ * Iterate ove the unlabeled connection hash table, while first skipping over
+ * a number of entries. For each entry in the table call @callback, if the
+ * callback function return a negative value stop 'walking' through the table
+ * and return. Updates the values in @skip_bkt, @skip_chain, @skip_addr4, and
+ * @skip_addr6 on return. Returns zero on success, negative values on failure.
+ *
+ */
+static int netlbl_unlhsh_walk(u32 *skip_bkt,
+ u32 *skip_chain,
+ u32 *skip_addr4,
+ u32 *skip_addr6,
+ int (*callback)
+ (const struct netlbl_unlhsh_iface *iface,
+ const struct netlbl_unlhsh_addr4 *addr4,
+ const struct netlbl_unlhsh_addr6 *addr6,
+ void *arg),
+ void *cb_arg)
+{
+ int ret_val = -ENOENT;
+ u32 iter_bkt;
+ u32 iter_chain = 0;
+ u32 iter_addr4 = 0;
+ u32 iter_addr6 = 0;
+ struct netlbl_unlhsh_iface *iface;
+ struct netlbl_unlhsh_addr4 *addr4;
+ struct netlbl_unlhsh_addr6 *addr6;
+
+ rcu_read_lock();
+ for (iter_bkt = *skip_bkt;
+ iter_bkt < rcu_dereference(netlbl_unlhsh)->size;
+ iter_bkt++, iter_chain = 0, iter_addr4 = 0, iter_addr6 = 0) {
+ list_for_each_entry_rcu(iface,
+ &rcu_dereference(netlbl_unlhsh)->tbl[iter_bkt],
+ list)
+ if (iface->valid) {
+ if (iter_chain++ < *skip_chain)
+ continue;
+ list_for_each_entry_rcu(addr4,
+ &iface->addr4_list,
+ list)
+ if (addr4->valid) {
+ if (iter_addr4++ < *skip_addr4)
+ continue;
+ ret_val = callback(iface,
+ addr4,
+ NULL,
+ cb_arg);
+ if (ret_val < 0) {
+ iter_addr4--;
+ iter_chain--;
+ goto unlhsh_walk_return;
+ }
+ }
+ list_for_each_entry_rcu(addr6,
+ &iface->addr6_list,
+ list)
+ if (addr6->valid) {
+ if (iter_addr6++ < *skip_addr6)
+ continue;
+ ret_val = callback(iface,
+ NULL,
+ addr6,
+ cb_arg);
+ if (ret_val < 0) {
+ iter_addr6--;
+ iter_chain--;
+ goto unlhsh_walk_return;
+ }
+ }
+ }
+ }
+
+unlhsh_walk_return:
+ rcu_read_unlock();
+ *skip_bkt = iter_bkt;
+ *skip_chain = iter_chain;
+ *skip_addr4 = iter_addr4;
+ *skip_addr6 = iter_addr6;
+ return ret_val;
+
+}
+
+/**
+ * netlbl_unlhsh_add_addr4 - Add a new IPv4 address entry to the hash table
+ * @iface: the associated interface entry
+ * @addr: IPv4 address in network byte order
+ * @mask: IPv4 address mask in network byte order
+ * @secid: LSM secid value for entry
+ *
+ * Description:
+ * Add a new address entry into the unlabeled connection hash table using the
+ * interface entry specified by @iface. On success zero is returned, otherwise
+ * a negative value is returned. The caller is responsible for calling the
+ * rcu_read_[un]lock() functions.
+ *
+ */
+static int netlbl_unlhsh_add_addr4(struct netlbl_unlhsh_iface *iface,
+ const struct in_addr *addr,
+ const struct in_addr *mask,
+ u32 secid)
+{
+ struct netlbl_unlhsh_addr4 *entry;
+ struct netlbl_unlhsh_addr4 *iter;
+
+ entry = kzalloc(sizeof(*entry), GFP_ATOMIC);
+ if (entry == NULL)
+ return -ENOMEM;
+
+ entry->addr = addr->s_addr & mask->s_addr;
+ entry->mask = mask->s_addr;
+ entry->secid = secid;
+ entry->valid = 1;
+ INIT_RCU_HEAD(&entry->rcu);
+
+ spin_lock(&netlbl_unlhsh_lock);
+ if (netlbl_unlhsh_search_addr4(entry->addr, iface) != NULL) {
+ spin_unlock(&netlbl_unlhsh_lock);
+ kfree(entry);
+ return -EEXIST;
+ }
+ /* in order to speed up address searches through the list (the common
+ * case) we need to keep the list in order based on the size of the
+ * address mask such that the entry with the widest mask (smallest
+ * numerical value) appears first in the list */
+ list_for_each_entry_rcu(iter, &iface->addr4_list, list)
+ if (iter->valid &&
+ ntohl(entry->mask) > ntohl(iter->mask)) {
+ __list_add_rcu(&entry->list,
+ iter->list.prev,
+ &iter->list);
+ spin_unlock(&netlbl_unlhsh_lock);
+ return 0;
+ }
+ list_add_tail_rcu(&entry->list, &iface->addr4_list);
+ spin_unlock(&netlbl_unlhsh_lock);
+ return 0;
+}
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+/**
+ * netlbl_unlhsh_add_addr6 - Add a new IPv6 address entry to the hash table
+ * @iface: the associated interface entry
+ * @addr: IPv6 address in network byte order
+ * @mask: IPv6 address mask in network byte order
+ * @secid: LSM secid value for entry
+ *
+ * Description:
+ * Add a new address entry into the unlabeled connection hash table using the
+ * interface entry specified by @iface. On success zero is returned, otherwise
+ * a negative value is returned. The caller is responsible for calling the
+ * rcu_read_[un]lock() functions.
+ *
+ */
+static int netlbl_unlhsh_add_addr6(struct netlbl_unlhsh_iface *iface,
+ const struct in6_addr *addr,
+ const struct in6_addr *mask,
+ u32 secid)
+{
+ struct netlbl_unlhsh_addr6 *entry;
+ struct netlbl_unlhsh_addr6 *iter;
+
+ entry = kzalloc(sizeof(*entry), GFP_ATOMIC);
+ if (entry == NULL)
+ return -ENOMEM;
+
+ ipv6_addr_copy(&entry->addr, addr);
+ entry->addr.s6_addr32[0] &= mask->s6_addr32[0];
+ entry->addr.s6_addr32[1] &= mask->s6_addr32[1];
+ entry->addr.s6_addr32[2] &= mask->s6_addr32[2];
+ entry->addr.s6_addr32[3] &= mask->s6_addr32[3];
+ ipv6_addr_copy(&entry->mask, mask);
+ entry->secid = secid;
+ entry->valid = 1;
+ INIT_RCU_HEAD(&entry->rcu);
+
+ spin_lock(&netlbl_unlhsh_lock);
+ if (netlbl_unlhsh_search_addr6(&entry->addr, iface) != NULL) {
+ spin_unlock(&netlbl_unlhsh_lock);
+ kfree(entry);
+ return -EEXIST;
+ }
+ /* in order to speed up address searches through the list (the common
+ * case) we need to keep the list in order based on the size of the
+ * address mask such that the entry with the widest mask (smallest
+ * numerical value) appears first in the list */
+ list_for_each_entry_rcu(iter, &iface->addr6_list, list)
+ if (iter->valid &&
+ memcmp(&entry->mask.s6_addr,
+ &iter->mask.s6_addr,
+ 16) > 0) {
+ __list_add_rcu(&entry->list,
+ iter->list.prev,
+ &iter->list);
+ spin_unlock(&netlbl_unlhsh_lock);
+ return 0;
+ }
+ list_add_tail_rcu(&entry->list, &iface->addr6_list);
+ spin_unlock(&netlbl_unlhsh_lock);
+ return 0;
+}
+#endif /* IPv6 */
+
+/**
+ * netlbl_unlhsh_add_iface - Adds a new interface entry to the hash table
+ * @ifindex: network interface
+ *
+ * Description:
+ * Add a new, empty, interface entry into the unlabeled connection hash table.
+ * On success a pointer to the new interface entry is returned, on failure NULL
+ * is returned. The caller is responsible for calling the rcu_read_[un]lock()
+ * functions.
+ *
+ */
+static struct netlbl_unlhsh_iface *netlbl_unlhsh_add_iface(int ifindex)
+{
+ u32 bkt;
+ struct netlbl_unlhsh_iface *iface;
+
+ iface = kzalloc(sizeof(*iface), GFP_ATOMIC);
+ if (iface == NULL)
+ return NULL;
+
+ iface->ifindex = ifindex;
+ INIT_LIST_HEAD(&iface->addr4_list);
+ INIT_LIST_HEAD(&iface->addr6_list);
+ iface->valid = 1;
+ INIT_RCU_HEAD(&iface->rcu);
+
+ bkt = netlbl_unlhsh_hash(ifindex);
+ spin_lock(&netlbl_unlhsh_lock);
+ if (netlbl_unlhsh_search_iface(ifindex) != NULL) {
+ spin_unlock(&netlbl_unlhsh_lock);
+ kfree(iface);
+ return NULL;
+ }
+ list_add_tail_rcu(&iface->list,
+ &rcu_dereference(netlbl_unlhsh)->tbl[bkt]);
+ spin_unlock(&netlbl_unlhsh_lock);
+
+ return iface;
+}
+
+/**
+ * netlbl_unlhsh_add - Adds a new entry to the unlabeled connection hash table
+ * @dev_name: interface name
+ * @addr: IP address in network byte order
+ * @mask: address mask in network byte order
+ * @addr_len: length of address/mask (4 for IPv4, 16 for IPv6)
+ * @secid: LSM secid value for the entry
+ *
+ * Description:
+ * Adds a new entry to the unlabeled connection hash table. Returns zero on
+ * success, negative values on failure.
+ *
+ */
+static int netlbl_unlhsh_add(const char *dev_name,
+ const void *addr,
+ const void *mask,
+ u32 addr_len,
+ u32 secid)
+{
+ int ret_val;
+ int ifindex;
+ struct net_device *dev;
+ struct netlbl_unlhsh_iface *iface;
+
+ if (addr_len != sizeof(struct in_addr) &&
+ addr_len != sizeof(struct in6_addr))
+ return -EINVAL;
+
+ dev = dev_get_by_name(dev_name);
+ if (dev == NULL)
+ return -ENODEV;
+ ifindex = dev->ifindex;
+ dev_put(dev);
+
+ rcu_read_lock();
+ iface = netlbl_unlhsh_search_iface(ifindex);
+ if (iface == NULL)
+ iface = netlbl_unlhsh_add_iface(ifindex);
+ if (iface == NULL) {
+ rcu_read_unlock();
+ return -ENOMEM;
+ }
+ switch (addr_len) {
+ case sizeof(struct in_addr):
+ ret_val = netlbl_unlhsh_add_addr4(iface,
+ (struct in_addr *)addr,
+ (struct in_addr *)mask,
+ secid);
+ break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case sizeof(struct in6_addr):
+ ret_val = netlbl_unlhsh_add_addr6(iface,
+ (struct in6_addr *)addr,
+ (struct in6_addr *)mask,
+ secid);
+ break;
+#endif /* IPv6 */
+ default:
+ ret_val = -EINVAL;
+ }
+ rcu_read_unlock();
+
+ if (ret_val == 0)
+ netlbl_mgmt_protocount_inc();
+
+ return ret_val;
+}
+
+/**
+ * netlbl_unlhsh_remove_addr4 - Remove an IPv4 address entry
+ * @iface: interface entry
+ * @addr: IP address
+ * @mask: IP address mask
+ *
+ * Description:
+ * Remove an IP address entry from the unlabeled connection hash table.
+ * Returns zero on success, negative values on failure. The caller is
+ * responsible for calling the rcu_read_[un]lock() functions.
+ *
+ */
+static int netlbl_unlhsh_remove_addr4(struct netlbl_unlhsh_iface *iface,
+ const struct in_addr *addr,
+ const struct in_addr *mask)
+{
+ struct netlbl_unlhsh_addr4 *entry;
+
+ spin_lock(&netlbl_unlhsh_lock);
+ entry = netlbl_unlhsh_search_addr4(addr->s_addr, iface);
+ if (entry == NULL ||
+ (entry->addr != addr->s_addr && entry->mask != mask->s_addr)) {
+ spin_unlock(&netlbl_unlhsh_lock);
+ return -ENOENT;
+ }
+ entry->valid = 0;
+ list_del_rcu(&entry->list);
+ spin_unlock(&netlbl_unlhsh_lock);
+
+ call_rcu(&entry->rcu, netlbl_unlhsh_free_addr4);
+
+ return 0;
+}
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+/**
+ * netlbl_unlhsh_remove_addr6 - Remove an IPv6 address entry
+ * @iface: interface entry
+ * @addr: IP address
+ * @mask: IP address mask
+ *
+ * Description:
+ * Remove an IP address entry from the unlabeled connection hash table.
+ * Returns zero on success, negative values on failure. The caller is
+ * responsible for calling the rcu_read_[un]lock() functions.
+ *
+ */
+static int netlbl_unlhsh_remove_addr6(struct netlbl_unlhsh_iface *iface,
+ const struct in6_addr *addr,
+ const struct in6_addr *mask)
+{
+ struct netlbl_unlhsh_addr6 *entry;
+
+ spin_lock(&netlbl_unlhsh_lock);
+ entry = netlbl_unlhsh_search_addr6(addr, iface);
+ if (entry == NULL ||
+ (ipv6_addr_cmp(&entry->addr, addr) != 0 &&
+ ipv6_addr_cmp(&entry->mask, mask) != 0)) {
+ spin_unlock(&netlbl_unlhsh_lock);
+ return -ENOENT;
+ }
+ entry->valid = 0;
+ list_del_rcu(&entry->list);
+ spin_unlock(&netlbl_unlhsh_lock);
+
+ call_rcu(&entry->rcu, netlbl_unlhsh_free_addr6);
+
+ return 0;
+}
+#endif /* IPv6 */
+
+/**
+ * netlbl_unlhsh_condremove_iface - Remove an interface entry
+ * @ifindex: interface
+ *
+ * Description:
+ * Remove an interface entry from the unlabeled connection hash table if it is
+ * empty. An interface entry is considered to be empty if there are no
+ * address entries assigned to it.
+ *
+ */
+static void netlbl_unlhsh_condremove_iface(int ifindex)
+{
+ struct netlbl_unlhsh_iface *entry;
+ struct netlbl_unlhsh_addr4 *iter4;
+ struct netlbl_unlhsh_addr6 *iter6;
+
+ spin_lock(&netlbl_unlhsh_lock);
+ entry = netlbl_unlhsh_search_iface(ifindex);
+ if (entry == NULL || entry->ifindex != ifindex)
+ goto unlhsh_condremove_failure;
+ list_for_each_entry_rcu(iter4, &entry->addr4_list, list)
+ if (iter4->valid)
+ goto unlhsh_condremove_failure;
+ list_for_each_entry_rcu(iter6, &entry->addr6_list, list)
+ if (iter6->valid)
+ goto unlhsh_condremove_failure;
+ entry->valid = 0;
+ list_del_rcu(&entry->list);
+ spin_unlock(&netlbl_unlhsh_lock);
+
+ call_rcu(&entry->rcu, netlbl_unlhsh_free_iface);
+ return;
+
+unlhsh_condremove_failure:
+ spin_unlock(&netlbl_unlhsh_lock);
+}
+
+/**
+ * netlbl_unlhsh_remove - Remove an entry from the unlabeled hash table
+ * @dev_name: interface name
+ * @addr: IP address in network byte order
+ * @mask: address mask in network byte order
+ * @addr_len: length of address/mask (4 for IPv4, 16 for IPv6)
+ *
+ * Description:
+ * Removes and existing entry from the unlabeled connection hash table.
+ * Returns zero on success, negative values on failure.
+ *
+ */
+static int netlbl_unlhsh_remove(const char *dev_name,
+ const void *addr,
+ const void *mask,
+ u32 addr_len)
+{
+ int ret_val;
+ int ifindex;
+ struct net_device *dev;
+ struct netlbl_unlhsh_iface *iface;
+
+ if (addr_len != sizeof(struct in_addr) &&
+ addr_len != sizeof(struct in6_addr))
+ return -EINVAL;
+
+ dev = dev_get_by_name(dev_name);
+ if (dev == NULL)
+ return -ENODEV;
+ ifindex = dev->ifindex;
+ dev_put(dev);
+
+ rcu_read_lock();
+ iface = netlbl_unlhsh_search_iface(ifindex);
+ if (iface == NULL) {
+ rcu_read_unlock();
+ return -ENOENT;
+ }
+ switch (addr_len) {
+ case sizeof(struct in_addr):
+ ret_val = netlbl_unlhsh_remove_addr4(iface,
+ (struct in_addr *)addr,
+ (struct in_addr *)mask);
+ break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case sizeof(struct in6_addr):
+ ret_val = netlbl_unlhsh_remove_addr6(iface,
+ (struct in6_addr *)addr,
+ (struct in6_addr *)mask);
+ break;
+#endif /* IPv6 */
+ default:
+ ret_val = -EINVAL;
+ }
+ if (ret_val == 0)
+ netlbl_unlhsh_condremove_iface(ifindex);
+ rcu_read_unlock();
+
+ if (ret_val == 0)
+ netlbl_mgmt_protocount_dec();
+
+ return ret_val;
+}
+
+/**
+ * netlbl_unlhsh_netdev_handler - Network device notification handler
+ * @this: notifier block
+ * @event: the event
+ * @ptr: the network device (cast to void)
+ *
+ * Description:
+ * Handle network device events, although at present all we care about is a
+ * network device going away. In the case of a device going away we clear any
+ * related entries from the unlabeled connection hash table.
+ *
+ */
+static int netlbl_unlhsh_netdev_handler(struct notifier_block *this,
+ unsigned long event,
+ void *ptr)
+{
+ struct net_device *dev = ptr;
+ struct netlbl_unlhsh_iface *iface;
+
+ /* XXX - should this be a check for NETDEV_DOWN or _UNREGISTER? */
+ if (event == NETDEV_DOWN) {
+ rcu_read_lock();
+ iface = netlbl_unlhsh_search_iface(dev->ifindex);
+ if (iface != NULL && iface->valid) {
+ spin_lock(&netlbl_unlhsh_lock);
+ iface->valid = 0;
+ list_del_rcu(&iface->list);
+ spin_unlock(&netlbl_unlhsh_lock);
+
+ call_rcu(&iface->rcu, netlbl_unlhsh_free_iface);
+ }
+ rcu_read_unlock();
+ }
+
+ return NOTIFY_DONE;
+}
+
+/*
+ * General Helper Functions
*/
/**
@@ -177,11 +995,276 @@ list_failure:
return ret_val;
}
+/**
+ * netlbl_unlabel_staticadd - Handle a STATICADD message
+ * @skb: the NETLINK buffer
+ * @info: the Generic NETLINK info block
+ *
+ * Description:
+ * Process a user generated STATICADD message and add a new unlabeled
+ * connection entry to the hash table. Returns zero on success, negative
+ * values on failure.
+ *
+ */
+static int netlbl_unlabel_staticadd(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ int ret_val;
+ char *dev_name;
+ void *addr;
+ void *mask;
+ u32 addr_len;
+ u32 secid;
+
+ /* Don't allow users to add both IPv4 and IPv6 addresses for a
+ * single entry. However, allow users to create two entries, one each
+ * for IPv4 and IPv4, with the same LSM security context which should
+ * achieve the same result. */
+ if (!info->attrs[NLBL_UNLABEL_A_SECCTX] ||
+ !info->attrs[NLBL_UNLABEL_A_IFACE] ||
+ !((!info->attrs[NLBL_UNLABEL_A_IPV4ADDR] ||
+ !info->attrs[NLBL_UNLABEL_A_IPV4MASK]) ^
+ (!info->attrs[NLBL_UNLABEL_A_IPV6ADDR] ||
+ !info->attrs[NLBL_UNLABEL_A_IPV6MASK])))
+ return -EINVAL;
+
+ if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR]) {
+ addr_len = nla_len(info->attrs[NLBL_UNLABEL_A_IPV4ADDR]);
+ if (addr_len != sizeof(struct in_addr) &&
+ addr_len != nla_len(info->attrs[NLBL_UNLABEL_A_IPV4MASK]))
+ return -EINVAL;
+ addr = nla_data(info->attrs[NLBL_UNLABEL_A_IPV4ADDR]);
+ mask = nla_data(info->attrs[NLBL_UNLABEL_A_IPV4MASK]);
+ } else {
+ addr_len = nla_len(info->attrs[NLBL_UNLABEL_A_IPV6ADDR]);
+ if (addr_len != sizeof(struct in6_addr) &&
+ addr_len != nla_len(info->attrs[NLBL_UNLABEL_A_IPV6MASK]))
+ return -EINVAL;
+ addr = nla_data(info->attrs[NLBL_UNLABEL_A_IPV6ADDR]);
+ mask = nla_data(info->attrs[NLBL_UNLABEL_A_IPV6MASK]);
+ }
+ dev_name = nla_data(info->attrs[NLBL_UNLABEL_A_IFACE]);
+ ret_val = security_secctx_to_secid(
+ nla_data(info->attrs[NLBL_UNLABEL_A_SECCTX]),
+ nla_len(info->attrs[NLBL_UNLABEL_A_SECCTX]),
+ &secid);
+ if (ret_val != 0)
+ return ret_val;
+
+ return netlbl_unlhsh_add(dev_name, addr, mask, addr_len, secid);
+}
+
+/**
+ * netlbl_unlabel_staticremove - Handle a STATICREMOVE message
+ * @skb: the NETLINK buffer
+ * @info: the Generic NETLINK info block
+ *
+ * Description:
+ * Process a user generated STATICREMOVE message and remove the specified
+ * unlabeled connection entry. Returns zero on success, negative values on
+ * failure.
+ *
+ */
+static int netlbl_unlabel_staticremove(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ char *dev_name;
+ void *addr;
+ void *mask;
+ u32 addr_len;
+
+ /* See the note in netlbl_unlabel_staticadd() about not allowing both
+ * IPv4 and IPv6 in the same entry. */
+ if (!info->attrs[NLBL_UNLABEL_A_IFACE] ||
+ !((!info->attrs[NLBL_UNLABEL_A_IPV4ADDR] ||
+ !info->attrs[NLBL_UNLABEL_A_IPV4MASK]) ^
+ (!info->attrs[NLBL_UNLABEL_A_IPV6ADDR] ||
+ !info->attrs[NLBL_UNLABEL_A_IPV6MASK])))
+ return -EINVAL;
+
+ if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR]) {
+ addr_len = nla_len(info->attrs[NLBL_UNLABEL_A_IPV4ADDR]);
+ if (addr_len != sizeof(struct in_addr) &&
+ addr_len != nla_len(info->attrs[NLBL_UNLABEL_A_IPV4MASK]))
+ return -EINVAL;
+ addr = nla_data(info->attrs[NLBL_UNLABEL_A_IPV4ADDR]);
+ mask = nla_data(info->attrs[NLBL_UNLABEL_A_IPV4MASK]);
+ } else {
+ addr_len = nla_len(info->attrs[NLBL_UNLABEL_A_IPV6ADDR]);
+ if (addr_len != sizeof(struct in6_addr) &&
+ addr_len != nla_len(info->attrs[NLBL_UNLABEL_A_IPV6MASK]))
+ return -EINVAL;
+ addr = nla_data(info->attrs[NLBL_UNLABEL_A_IPV6ADDR]);
+ mask = nla_data(info->attrs[NLBL_UNLABEL_A_IPV6MASK]);
+ }
+ dev_name = nla_data(info->attrs[NLBL_UNLABEL_A_IFACE]);
+
+ return netlbl_unlhsh_remove(dev_name, addr, mask, addr_len);
+}
+
+/**
+ * netlbl_unlabel_list_cb - netlbl_unlhsh_walk() callback for STATICLIST
+ * @iface: the interface entry
+ * @addr4: the IPv4 address entry
+ * @addr6: the IPv6 address entry
+ * @arg: the netlbl_unlhsh_walk_arg structure
+ *
+ * Description:
+ * This function is designed to be used as a callback to the
+ * netlbl_unlhsh_walk() function for use in generating a response for a
+ * STATICLIST message. When called either @addr4 or @addr6 can be specified,
+ * not both, the other unspecified entry should be set to NULL by the caller.
+ * Returns the size of the message on success, negative values on failure.
+ *
+ */
+static int netlbl_unlabel_list_cb(const struct netlbl_unlhsh_iface *iface,
+ const struct netlbl_unlhsh_addr4 *addr4,
+ const struct netlbl_unlhsh_addr6 *addr6,
+ void *arg)
+{
+ int ret_val = -ENOMEM;
+ struct net_device *dev;
+ struct netlbl_unlhsh_walk_arg *cb_arg = arg;
+ void *data;
+ u32 secid;
+ char *secctx;
+ u32 secctx_len;
+
+ data = genlmsg_put(cb_arg->skb, NETLINK_CB(cb_arg->nl_cb->skb).pid,
+ cb_arg->seq, &netlbl_unlabel_gnl_family,
+ NLM_F_MULTI, NLBL_UNLABEL_C_STATICLIST);
+ if (data == NULL)
+ goto list_cb_failure;
+
+ dev = dev_get_by_index(iface->ifindex);
+ ret_val = nla_put_string(cb_arg->skb, NLBL_UNLABEL_A_IFACE, dev->name);
+ dev_put(dev);
+ if (ret_val != 0)
+ goto list_cb_failure;
+
+ if (addr4) {
+ struct in_addr addr_struct;
+
+ addr_struct.s_addr = addr4->addr;
+ ret_val = nla_put(cb_arg->skb,
+ NLBL_UNLABEL_A_IPV4ADDR,
+ sizeof(struct in_addr),
+ &addr_struct);
+ if (ret_val != 0)
+ goto list_cb_failure;
+
+ addr_struct.s_addr = addr4->mask;
+ ret_val = nla_put(cb_arg->skb,
+ NLBL_UNLABEL_A_IPV4MASK,
+ sizeof(struct in_addr),
+ &addr_struct);
+ if (ret_val != 0)
+ goto list_cb_failure;
+
+ secid = addr4->secid;
+ } else {
+ ret_val = nla_put(cb_arg->skb,
+ NLBL_UNLABEL_A_IPV6ADDR,
+ sizeof(struct in6_addr),
+ &addr6->addr);
+ if (ret_val != 0)
+ goto list_cb_failure;
+
+ ret_val = nla_put(cb_arg->skb,
+ NLBL_UNLABEL_A_IPV6MASK,
+ sizeof(struct in6_addr),
+ &addr6->mask);
+ if (ret_val != 0)
+ goto list_cb_failure;
+
+ secid = addr6->secid;
+ }
+
+ ret_val = security_secid_to_secctx(secid, &secctx, &secctx_len);
+ if (ret_val != 0)
+ goto list_cb_failure;
+ ret_val = nla_put(cb_arg->skb,
+ NLBL_UNLABEL_A_SECCTX,
+ secctx_len,
+ secctx);
+ security_release_secctx(secctx, secctx_len);
+ if (ret_val != 0)
+ goto list_cb_failure;
+
+ cb_arg->seq++;
+ return genlmsg_end(cb_arg->skb, data);
+
+list_cb_failure:
+ genlmsg_cancel(cb_arg->skb, data);
+ return ret_val;
+}
+
+/**
+ * netlbl_unlabel_staticlist - Handle a STATICLIST message
+ * @skb: the NETLINK buffer
+ * @cb: the NETLINK callback
+ *
+ * Description:
+ * Process a user generated STATICLIST message and dump the unlabeled
+ * connection hash table in a form suitable for use in a kernel generated
+ * STATICLIST message. Returns the length of @skb.
+ *
+ */
+static int netlbl_unlabel_staticlist(struct sk_buff *skb,
+ struct netlink_callback *cb)
+{
+ struct netlbl_unlhsh_walk_arg cb_arg;
+ u32 skip_bkt = cb->args[0];
+ u32 skip_chain = cb->args[1];
+ u32 skip_addr4 = cb->args[2];
+ u32 skip_addr6 = cb->args[3];
+
+ cb_arg.nl_cb = cb;
+ cb_arg.skb = skb;
+ cb_arg.seq = cb->nlh->nlmsg_seq;
+
+ netlbl_unlhsh_walk(&skip_bkt,
+ &skip_chain,
+ &skip_addr4,
+ &skip_addr6,
+ netlbl_unlabel_list_cb,
+ &cb_arg);
+
+ cb->args[0] = skip_bkt;
+ cb->args[1] = skip_chain;
+ cb->args[2] = skip_addr4;
+ cb->args[3] = skip_addr6;
+ return skb->len;
+}
/*
* NetLabel Generic NETLINK Command Definitions
*/
+static struct genl_ops netlbl_unlabel_genl_c_staticadd = {
+ .cmd = NLBL_UNLABEL_C_STATICADD,
+ .flags = GENL_ADMIN_PERM,
+ .policy = netlbl_unlabel_genl_policy,
+ .doit = netlbl_unlabel_staticadd,
+ .dumpit = NULL,
+};
+
+static struct genl_ops netlbl_unlabel_genl_c_staticremove = {
+ .cmd = NLBL_UNLABEL_C_STATICREMOVE,
+ .flags = GENL_ADMIN_PERM,
+ .policy = netlbl_unlabel_genl_policy,
+ .doit = netlbl_unlabel_staticremove,
+ .dumpit = NULL,
+};
+
+static struct genl_ops netlbl_unlabel_genl_c_staticlist = {
+ .cmd = NLBL_UNLABEL_C_STATICLIST,
+ .flags = 0,
+ .policy = netlbl_unlabel_genl_policy,
+ .doit = NULL,
+ .dumpit = netlbl_unlabel_staticlist,
+};
+
static struct genl_ops netlbl_unlabel_genl_c_accept = {
.cmd = NLBL_UNLABEL_C_ACCEPT,
.flags = GENL_ADMIN_PERM,
@@ -198,7 +1281,6 @@ static struct genl_ops netlbl_unlabel_ge
.dumpit = NULL,
};
-
/*
* NetLabel Generic NETLINK Protocol Functions
*/
@@ -220,6 +1302,21 @@ int netlbl_unlabel_genl_init(void)
return ret_val;
ret_val = genl_register_ops(&netlbl_unlabel_gnl_family,
+ &netlbl_unlabel_genl_c_staticadd);
+ if (ret_val != 0)
+ return ret_val;
+
+ ret_val = genl_register_ops(&netlbl_unlabel_gnl_family,
+ &netlbl_unlabel_genl_c_staticremove);
+ if (ret_val != 0)
+ return ret_val;
+
+ ret_val = genl_register_ops(&netlbl_unlabel_gnl_family,
+ &netlbl_unlabel_genl_c_staticlist);
+ if (ret_val != 0)
+ return ret_val;
+
+ ret_val = genl_register_ops(&netlbl_unlabel_gnl_family,
&netlbl_unlabel_genl_c_accept);
if (ret_val != 0)
return ret_val;
@@ -236,8 +1333,58 @@ int netlbl_unlabel_genl_init(void)
* NetLabel KAPI Hooks
*/
+static struct notifier_block netlbl_unlhsh_netdev_notifier = {
+ .notifier_call = netlbl_unlhsh_netdev_handler,
+};
+
+/**
+ * netlbl_unlabel_init - Initialize the unlabeled connection hash table
+ * @size: the number of bits to use for the hash buckets
+ *
+ * Description:
+ * Initializes the unlabeled connection hash table and registers a network
+ * device notification handler. This function should only be called by the
+ * NetLabel subsystem itself during initialization. Returns zero on success,
+ * non-zero values on error.
+ *
+ */
+int netlbl_unlabel_init(u32 size)
+{
+ u32 iter;
+ struct netlbl_unlhsh_tbl *hsh_tbl;
+
+ if (size == 0)
+ return -EINVAL;
+
+ hsh_tbl = kmalloc(sizeof(*hsh_tbl), GFP_KERNEL);
+ if (hsh_tbl == NULL)
+ return -ENOMEM;
+ hsh_tbl->size = 1 << size;
+ hsh_tbl->tbl = kcalloc(hsh_tbl->size,
+ sizeof(struct list_head),
+ GFP_KERNEL);
+ if (hsh_tbl->tbl == NULL) {
+ kfree(hsh_tbl);
+ return -ENOMEM;
+ }
+ for (iter = 0; iter < hsh_tbl->size; iter++)
+ INIT_LIST_HEAD(&hsh_tbl->tbl[iter]);
+
+ rcu_read_lock();
+ spin_lock(&netlbl_unlhsh_lock);
+ rcu_assign_pointer(netlbl_unlhsh, hsh_tbl);
+ spin_unlock(&netlbl_unlhsh_lock);
+ rcu_read_unlock();
+
+ register_netdevice_notifier(&netlbl_unlhsh_netdev_notifier);
+
+ return 0;
+}
+
/**
* netlbl_unlabel_getattr - Get the security attributes for an unlabled packet
+ * @skb: the packet
+ * @family: protocol family
* @secattr: the security attributes
*
* Description:
@@ -245,15 +1392,22 @@ int netlbl_unlabel_genl_init(void)
* them in @secattr. Returns zero on success and negative values on failure.
*
*/
-int netlbl_unlabel_getattr(struct netlbl_lsm_secattr *secattr)
+int netlbl_unlabel_getattr(const struct sk_buff *skb,
+ u16 family,
+ struct netlbl_lsm_secattr *secattr)
{
int ret_val;
+ u32 secid;
rcu_read_lock();
- if (netlabel_unlabel_acceptflg == 1) {
- netlbl_secattr_init(secattr);
+ secid = netlbl_unlhsh_search(skb, family);
+ if (secid != 0) {
+ secattr->attr.secid = secid;
+ secattr->flags |= NETLBL_SECATTR_SECID;
+ ret_val = 0;
+ } else if (netlabel_unlabel_acceptflg == 1)
ret_val = 0;
- } else
+ else
ret_val = -ENOMSG;
rcu_read_unlock();
Index: linux-2.6_staticlbl/net/netlabel/netlabel_unlabeled.h
===================================================================
--- linux-2.6_staticlbl.orig/net/netlabel/netlabel_unlabeled.h
+++ linux-2.6_staticlbl/net/netlabel/netlabel_unlabeled.h
@@ -36,6 +36,64 @@
/*
* The following NetLabel payloads are supported by the Unlabeled subsystem.
*
+ * o STATICADD
+ * This message is sent from an application to add a new static label for
+ * incoming unlabeled connections.
+ *
+ * Required attributes:
+ *
+ * NLBL_UNLABEL_A_IFACE
+ * NLBL_UNLABEL_A_SECCTX
+ *
+ * If IPv4 is specified the following attributes are required:
+ *
+ * NLBL_UNLABEL_A_IPV4ADDR
+ * NLBL_UNLABEL_A_IPV4MASK
+ *
+ * If IPv6 is specified the following attributes are required:
+ *
+ * NLBL_UNLABEL_A_IPV6ADDR
+ * NLBL_UNLABEL_A_IPV6MASK
+ *
+ * o STATICREMOVE
+ * This message is sent from an application to remove an existing static
+ * label for incoming unlabeled connections.
+ *
+ * Required attributes:
+ *
+ * NLBL_UNLABEL_A_IFACE
+ *
+ * If IPv4 is specified the following attributes are required:
+ *
+ * NLBL_UNLABEL_A_IPV4ADDR
+ * NLBL_UNLABEL_A_IPV4MASK
+ *
+ * If IPv6 is specified the following attributes are required:
+ *
+ * NLBL_UNLABEL_A_IPV6ADDR
+ * NLBL_UNLABEL_A_IPV6MASK
+ *
+ * o STATICLIST
+ * This message can be sent either from an application or by the kernel in
+ * response to an application generated STATICLIST message. When sent by an
+ * application there is no payload and the NLM_F_DUMP flag should be set.
+ * The kernel should response with a series of the following messages.
+ *
+ * Required attributes:
+ *
+ * NLBL_UNLABEL_A_IFACE
+ * NLBL_UNLABEL_A_SECCTX
+ *
+ * If IPv4 is specified the following attributes are required:
+ *
+ * NLBL_UNLABEL_A_IPV4ADDR
+ * NLBL_UNLABEL_A_IPV4MASK
+ *
+ * If IPv6 is specified the following attributes are required:
+ *
+ * NLBL_UNLABEL_A_IPV6ADDR
+ * NLBL_UNLABEL_A_IPV6MASK
+ *
* o ACCEPT
* This message is sent from an application to specify if the kernel should
* allow unlabled packets to pass if they do not match any of the static
@@ -62,6 +120,9 @@ enum {
NLBL_UNLABEL_C_UNSPEC,
NLBL_UNLABEL_C_ACCEPT,
NLBL_UNLABEL_C_LIST,
+ NLBL_UNLABEL_C_STATICADD,
+ NLBL_UNLABEL_C_STATICREMOVE,
+ NLBL_UNLABEL_C_STATICLIST,
__NLBL_UNLABEL_C_MAX,
};
#define NLBL_UNLABEL_C_MAX (__NLBL_UNLABEL_C_MAX - 1)
@@ -73,6 +134,24 @@ enum {
/* (NLA_U8)
* if true then unlabeled packets are allowed to pass, else unlabeled
* packets are rejected */
+ NLBL_UNLABEL_A_IPV6ADDR,
+ /* (NLA_BINARY, struct in6_addr)
+ * an IPv6 address */
+ NLBL_UNLABEL_A_IPV6MASK,
+ /* (NLA_BINARY, struct in6_addr)
+ * an IPv6 address mask */
+ NLBL_UNLABEL_A_IPV4ADDR,
+ /* (NLA_BINARY, struct in_addr)
+ * an IPv4 address */
+ NLBL_UNLABEL_A_IPV4MASK,
+ /* (NLA_BINARY, struct in_addr)
+ * and IPv4 address mask */
+ NLBL_UNLABEL_A_IFACE,
+ /* (NLA_NULL_STRING)
+ * network interface */
+ NLBL_UNLABEL_A_SECCTX,
+ /* (NLA_BINARY)
+ * a LSM specific security context */
__NLBL_UNLABEL_A_MAX,
};
#define NLBL_UNLABEL_A_MAX (__NLBL_UNLABEL_A_MAX - 1)
@@ -80,8 +159,17 @@ enum {
/* NetLabel protocol functions */
int netlbl_unlabel_genl_init(void);
+/* Unlabeled connection hash table size */
+/* XXX - currently this number is an uneducated guess */
+#define NETLBL_UNLHSH_BITSIZE 7
+
+/* General Unlabeled init function */
+int netlbl_unlabel_init(u32 size);
+
/* Process Unlabeled incoming network packets */
-int netlbl_unlabel_getattr(struct netlbl_lsm_secattr *secattr);
+int netlbl_unlabel_getattr(const struct sk_buff *skb,
+ u16 family,
+ struct netlbl_lsm_secattr *secattr);
/* Set the default configuration to allow Unlabeled packets */
int netlbl_unlabel_defconf(void);
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC 5/5] NetLabel: add auditing to the static labeling mechanism
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
` (3 preceding siblings ...)
2007-08-07 14:14 ` [RFC 4/5] NetLabel: introduce static network labels for unlabeled connections Paul Moore
@ 2007-08-07 14:14 ` Paul Moore
2007-08-09 10:57 ` [RFC 0/5] Static/fallback external labels for NetLabel KaiGai Kohei
` (2 subsequent siblings)
7 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-07 14:14 UTC (permalink / raw)
To: selinux; +Cc: kaigai, joe
This patch adds auditing support to the NetLabel static labeling mechanism.
---
include/linux/audit.h | 2
net/netlabel/netlabel_unlabeled.c | 91 ++++++++++++++++++++++++++++++--------
2 files changed, 75 insertions(+), 18 deletions(-)
Index: linux-2.6_staticlbl/include/linux/audit.h
===================================================================
--- linux-2.6_staticlbl.orig/include/linux/audit.h
+++ linux-2.6_staticlbl/include/linux/audit.h
@@ -112,6 +112,8 @@
#define AUDIT_MAC_IPSEC_DELSA 1412 /* Delete a XFRM state */
#define AUDIT_MAC_IPSEC_ADDSPD 1413 /* Add a XFRM policy */
#define AUDIT_MAC_IPSEC_DELSPD 1414 /* Delete a XFRM policy */
+#define AUDIT_MAC_UNLBL_STCADD 1415 /* NetLabel: add a static label */
+#define AUDIT_MAC_UNLBL_STCDEL 1416 /* NetLabel: del a static label */
#define AUDIT_FIRST_KERN_ANOM_MSG 1700
#define AUDIT_LAST_KERN_ANOM_MSG 1799
Index: linux-2.6_staticlbl/net/netlabel/netlabel_unlabeled.c
===================================================================
--- linux-2.6_staticlbl.orig/net/netlabel/netlabel_unlabeled.c
+++ linux-2.6_staticlbl/net/netlabel/netlabel_unlabeled.c
@@ -613,6 +613,7 @@ static struct netlbl_unlhsh_iface *netlb
* @mask: address mask in network byte order
* @addr_len: length of address/mask (4 for IPv4, 16 for IPv6)
* @secid: LSM secid value for the entry
+ * @audit_info: NetLabel audit information
*
* Description:
* Adds a new entry to the unlabeled connection hash table. Returns zero on
@@ -623,12 +624,18 @@ static int netlbl_unlhsh_add(const char
const void *addr,
const void *mask,
u32 addr_len,
- u32 secid)
+ u32 secid,
+ struct netlbl_audit *audit_info)
{
int ret_val;
int ifindex;
struct net_device *dev;
struct netlbl_unlhsh_iface *iface;
+ struct in_addr *addr4, *mask4;
+ struct in6_addr *addr6, *mask6;
+ struct audit_buffer *audit_buf = NULL;
+ char *secctx = NULL;
+ u32 secctx_len;
if (addr_len != sizeof(struct in_addr) &&
addr_len != sizeof(struct in6_addr))
@@ -648,24 +655,40 @@ static int netlbl_unlhsh_add(const char
rcu_read_unlock();
return -ENOMEM;
}
+ audit_buf = netlbl_audit_start_common(AUDIT_MAC_UNLBL_STCADD,
+ audit_info);
switch (addr_len) {
case sizeof(struct in_addr):
- ret_val = netlbl_unlhsh_add_addr4(iface,
- (struct in_addr *)addr,
- (struct in_addr *)mask,
- secid);
+ addr4 = (struct in_addr *)addr;
+ mask4 = (struct in_addr *)mask;
+ ret_val = netlbl_unlhsh_add_addr4(iface, addr4, mask4, secid);
+ if (audit_buf != NULL)
+ audit_log_format(audit_buf, " daddr=" NIPQUAD_FMT,
+ NIPQUAD(addr4->s_addr));
break;
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
case sizeof(struct in6_addr):
- ret_val = netlbl_unlhsh_add_addr6(iface,
- (struct in6_addr *)addr,
- (struct in6_addr *)mask,
- secid);
+ addr6 = (struct in6_addr *)addr;
+ mask6 = (struct in6_addr *)mask;
+ ret_val = netlbl_unlhsh_add_addr6(iface, addr6, mask6, secid);
+ if (audit_buf != NULL)
+ audit_log_format(audit_buf, " daddr= " NIP6_FMT,
+ NIP6(*addr6));
break;
#endif /* IPv6 */
default:
ret_val = -EINVAL;
}
+ if (audit_buf != NULL) {
+ if (security_secid_to_secctx(secid,
+ &secctx,
+ &secctx_len) == 0) {
+ audit_log_format(audit_buf, " sec_obj=%s", secctx);
+ security_release_secctx(secctx, secctx_len);
+ }
+ audit_log_format(audit_buf, " res=%u", ret_val == 0 ? 1 : 0);
+ audit_log_end(audit_buf);
+ }
rcu_read_unlock();
if (ret_val == 0)
@@ -788,6 +811,7 @@ unlhsh_condremove_failure:
* @addr: IP address in network byte order
* @mask: address mask in network byte order
* @addr_len: length of address/mask (4 for IPv4, 16 for IPv6)
+ * @audit_info: NetLabel audit information
*
* Description:
* Removes and existing entry from the unlabeled connection hash table.
@@ -797,12 +821,16 @@ unlhsh_condremove_failure:
static int netlbl_unlhsh_remove(const char *dev_name,
const void *addr,
const void *mask,
- u32 addr_len)
+ u32 addr_len,
+ struct netlbl_audit *audit_info)
{
int ret_val;
int ifindex;
struct net_device *dev;
struct netlbl_unlhsh_iface *iface;
+ struct in_addr *addr4, *mask4;
+ struct in6_addr *addr6, *mask6;
+ struct audit_buffer *audit_buf = NULL;
if (addr_len != sizeof(struct in_addr) &&
addr_len != sizeof(struct in6_addr))
@@ -820,22 +848,34 @@ static int netlbl_unlhsh_remove(const ch
rcu_read_unlock();
return -ENOENT;
}
+ audit_buf = netlbl_audit_start_common(AUDIT_MAC_UNLBL_STCDEL,
+ audit_info);
switch (addr_len) {
case sizeof(struct in_addr):
- ret_val = netlbl_unlhsh_remove_addr4(iface,
- (struct in_addr *)addr,
- (struct in_addr *)mask);
+ addr4 = (struct in_addr *)addr;
+ mask4 = (struct in_addr *)mask;
+ ret_val = netlbl_unlhsh_remove_addr4(iface, addr4, mask4);
+ if (audit_buf != NULL)
+ audit_log_format(audit_buf, " daddr=" NIPQUAD_FMT,
+ NIPQUAD(addr4->s_addr));
break;
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
case sizeof(struct in6_addr):
- ret_val = netlbl_unlhsh_remove_addr6(iface,
- (struct in6_addr *)addr,
- (struct in6_addr *)mask);
+ addr6 = (struct in6_addr *)addr;
+ mask6 = (struct in6_addr *)mask;
+ ret_val = netlbl_unlhsh_remove_addr6(iface, addr6, mask6);
+ if (audit_buf != NULL)
+ audit_log_format(audit_buf, " daddr= " NIP6_FMT,
+ NIP6(*addr6));
break;
#endif /* IPv6 */
default:
ret_val = -EINVAL;
}
+ if (audit_buf != NULL) {
+ audit_log_format(audit_buf, " res=%u", ret_val == 0 ? 1 : 0);
+ audit_log_end(audit_buf);
+ }
if (ret_val == 0)
netlbl_unlhsh_condremove_iface(ifindex);
rcu_read_unlock();
@@ -1015,6 +1055,7 @@ static int netlbl_unlabel_staticadd(stru
void *mask;
u32 addr_len;
u32 secid;
+ struct netlbl_audit audit_info;
/* Don't allow users to add both IPv4 and IPv6 addresses for a
* single entry. However, allow users to create two entries, one each
@@ -1028,6 +1069,8 @@ static int netlbl_unlabel_staticadd(stru
!info->attrs[NLBL_UNLABEL_A_IPV6MASK])))
return -EINVAL;
+ netlbl_netlink_auditinfo(skb, &audit_info);
+
if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR]) {
addr_len = nla_len(info->attrs[NLBL_UNLABEL_A_IPV4ADDR]);
if (addr_len != sizeof(struct in_addr) &&
@@ -1051,7 +1094,12 @@ static int netlbl_unlabel_staticadd(stru
if (ret_val != 0)
return ret_val;
- return netlbl_unlhsh_add(dev_name, addr, mask, addr_len, secid);
+ return netlbl_unlhsh_add(dev_name,
+ addr,
+ mask,
+ addr_len,
+ secid,
+ &audit_info);
}
/**
@@ -1072,6 +1120,7 @@ static int netlbl_unlabel_staticremove(s
void *addr;
void *mask;
u32 addr_len;
+ struct netlbl_audit audit_info;
/* See the note in netlbl_unlabel_staticadd() about not allowing both
* IPv4 and IPv6 in the same entry. */
@@ -1082,6 +1131,8 @@ static int netlbl_unlabel_staticremove(s
!info->attrs[NLBL_UNLABEL_A_IPV6MASK])))
return -EINVAL;
+ netlbl_netlink_auditinfo(skb, &audit_info);
+
if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR]) {
addr_len = nla_len(info->attrs[NLBL_UNLABEL_A_IPV4ADDR]);
if (addr_len != sizeof(struct in_addr) &&
@@ -1099,7 +1150,11 @@ static int netlbl_unlabel_staticremove(s
}
dev_name = nla_data(info->attrs[NLBL_UNLABEL_A_IFACE]);
- return netlbl_unlhsh_remove(dev_name, addr, mask, addr_len);
+ return netlbl_unlhsh_remove(dev_name,
+ addr,
+ mask,
+ addr_len,
+ &audit_info);
}
/**
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
` (4 preceding siblings ...)
2007-08-07 14:14 ` [RFC 5/5] NetLabel: add auditing to the static labeling mechanism Paul Moore
@ 2007-08-09 10:57 ` KaiGai Kohei
2007-08-09 11:48 ` Paul Moore
2007-08-09 12:42 ` Stephen Smalley
2007-08-09 15:48 ` Casey Schaufler
7 siblings, 1 reply; 57+ messages in thread
From: KaiGai Kohei @ 2007-08-09 10:57 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe
Paul,
Thanks so much! I was looking forward to your patch set.
I tried to build kernel with the patch and configure a fallbacked label,
but the netlabelctl returns the following error message:
[root@masu ~]# netlabelctl unlbl add interface:eth0 address:192.168.11.0/24 \
> label:system_u:system_r:unconfined_t:s0
netlabelctl: error, invalid argument or parameter
[root@masu ~]# netlabelctl -p unlbl list
Allow unlabeled packets : on
[root@masu ~]#
The kernel config contains CONFIG_NETLABEL=y, and the netlabelctl command
is built from the latest svn repository.
Are any more configurations necessary?
Thanks,
Paul Moore wrote:
> This patchset adds the static/fallback labeling feature to NetLabel that has
> been requested on the SELinux mailing list more and more recently. This new
> bit of functionality also matches what can be found on similar trusted/labeled
> OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet ready
> for "upstreaming" so please do not pull this into any tree bound for the
> mainline kernel; I still need to do more review and testing of the code.
> However, I know there are several of you on this list that have been anxiously
> awaiting this patchset so I thought I would make an early release so you could
> get a peek and test it out. I won't be able to work on this patchset much, if
> at all, between August 10th and the 20th so don't expect an update from me
> until the end of August.
>
> The basic idea is that currently there is no method for providing an external
> label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO
> or labeled IPsec is not in use. This patch adds a mechanism for providing a
> static fallback label, specified per interface/network, which is used when
> a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.
>
> For those of you wishing to try this patchset, it is backed against Linus'
> linux-2.6 git tree from the afternoon of August 6th, but I don't imagine you'll
> have many problems applying the patchset to later trees at this point in the
> 2.6.23 release cycle. In addition to the kernel patches you will also need a
> modified version of netlabelctl from the netlabel_tools package. A very crude
> version of the modified tools can be found in the netlabel_tools SVN repository
> in the static_label branch. Please check the NetLabel website on SourceForge,
> http://netlabel.sf.net, for information on the SVN repository. The three new
> netlabelctl commands are as follows:
>
> # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>] label:<LABEL>
> # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
> # netlabelctl -p unlbl list
>
> DEV = interface, examples: eth0, lo
> ADDR = IP address, examples: 192.168.0.3, ::1
> MASK = IP address mask length, examples 8, 24, 64
> LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2
>
> For example, if you wanted to label all inbound traffic on eth1 from
> 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you would
> type:
>
> # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
> label:system_u:object_r:staticlabel_t:s7
>
> Both IPv4 and IPv6 addresses can be used and if the address mask is ommitted
> from the command the address is assumed to be a host address, not a network,
> and the maximum mask size for that address family is used. If you do not wish
> to specify an address, simply use a address mask of zero, "/0", which will
> cause all addresses within that address family to match.
>
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 10:57 ` [RFC 0/5] Static/fallback external labels for NetLabel KaiGai Kohei
@ 2007-08-09 11:48 ` Paul Moore
0 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 11:48 UTC (permalink / raw)
To: KaiGai Kohei; +Cc: selinux, kaigai, joe
On Thursday 09 August 2007 6:57:43 am KaiGai Kohei wrote:
> Thanks so much! I was looking forward to your patch set.
>
> I tried to build kernel with the patch and configure a fallbacked label,
> but the netlabelctl returns the following error message:
>
> [root@masu ~]# netlabelctl unlbl add interface:eth0 address:192.168.11.0/24
> label:system_u:system_r:unconfined_t:s0
> netlabelctl: error, invalid argument or parameter
>
> The kernel config contains CONFIG_NETLABEL=y, and the netlabelctl command
> is built from the latest svn repository.
> Are any more configurations necessary?
Thanks for taking the time to try it out, sorry it wasn't more successful :/
It looks like you are using the userspace from sources under the "head/"
directory. In order to get the new features you need to use the sources
under the "branches/static_label" directory.
* http://netlabel.svn.sf.net/viewvc/netlabel/netlabel_tools/branches
I apologize, I probably wasn't as clear about this as I should have been in my
original posting.
Here are the commands, in order, that I used to fetch and build the
static_label branch of the netlabel_tools package:
# svn co https://netlabel.svn.sf.net/svnroot/netlabel netlabel
# cd netlabel/netlabel_tools/branches/static_label
# make
If you run into any more problems, or have any questions let me know.
Thanks again for your help.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
` (5 preceding siblings ...)
2007-08-09 10:57 ` [RFC 0/5] Static/fallback external labels for NetLabel KaiGai Kohei
@ 2007-08-09 12:42 ` Stephen Smalley
2007-08-09 13:29 ` Paul Moore
2007-08-09 14:09 ` Darrel Goeddel
2007-08-09 15:48 ` Casey Schaufler
7 siblings, 2 replies; 57+ messages in thread
From: Stephen Smalley @ 2007-08-09 12:42 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
On Tue, 2007-08-07 at 10:14 -0400, Paul Moore wrote:
> This patchset adds the static/fallback labeling feature to NetLabel that has
> been requested on the SELinux mailing list more and more recently. This new
> bit of functionality also matches what can be found on similar trusted/labeled
> OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet ready
> for "upstreaming" so please do not pull this into any tree bound for the
> mainline kernel; I still need to do more review and testing of the code.
> However, I know there are several of you on this list that have been anxiously
> awaiting this patchset so I thought I would make an early release so you could
> get a peek and test it out. I won't be able to work on this patchset much, if
> at all, between August 10th and the 20th so don't expect an update from me
> until the end of August.
>
> The basic idea is that currently there is no method for providing an external
> label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO
> or labeled IPsec is not in use. This patch adds a mechanism for providing a
> static fallback label, specified per interface/network, which is used when
> a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.
>
> For those of you wishing to try this patchset, it is backed against Linus'
> linux-2.6 git tree from the afternoon of August 6th, but I don't imagine you'll
> have many problems applying the patchset to later trees at this point in the
> 2.6.23 release cycle. In addition to the kernel patches you will also need a
> modified version of netlabelctl from the netlabel_tools package. A very crude
> version of the modified tools can be found in the netlabel_tools SVN repository
> in the static_label branch. Please check the NetLabel website on SourceForge,
> http://netlabel.sf.net, for information on the SVN repository. The three new
> netlabelctl commands are as follows:
>
> # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>] label:<LABEL>
> # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
> # netlabelctl -p unlbl list
>
> DEV = interface, examples: eth0, lo
> ADDR = IP address, examples: 192.168.0.3, ::1
> MASK = IP address mask length, examples 8, 24, 64
> LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2
>
> For example, if you wanted to label all inbound traffic on eth1 from
> 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you would
> type:
>
> # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
> label:system_u:object_r:staticlabel_t:s7
>
> Both IPv4 and IPv6 addresses can be used and if the address mask is ommitted
> from the command the address is assumed to be a host address, not a network,
> and the maximum mask size for that address family is used. If you do not wish
> to specify an address, simply use a address mask of zero, "/0", which will
> cause all addresses within that address family to match.
Hi,
I like the functionality, but I don't like having yet another mechanism
and configuration, and I'm concerned about it being netlabel-centric.
Especially when we already have a more generic and flexible mechanism
for specifying packet labels, i.e. secmark.
The only reason to not use secmark today for a fallback mechanism is the
current separation between 'internal' and 'external' labels. But I
don't believe that separation is necessary or useful, and secmark today
is effectively unused. The original usage scenario for it simply hasn't
materialized.
Meanwhile, getting secmark employed, not only as a mechanism for
assigning default labels (via iptables rules) but also as a seamless way
of propagating labels with socket buffers would solve a lot of our
current limitations. We'd get loopback labeling for free, flexible and
generic fallback labeling, forwarding controls would become
straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
NetLabel would benefit from it as well. There are alternative
implementation approaches, but none as clean and efficient and reliable.
There was a reason we put a sid in the sk_buff in the original SELinux
implementations (prior to Linux 2.6 merge).
I've had some initial discussions with James, and he seemed open to
revisiting this notion, so I think we need to take another look.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 12:42 ` Stephen Smalley
@ 2007-08-09 13:29 ` Paul Moore
2007-08-09 13:54 ` Stephen Smalley
` (3 more replies)
2007-08-09 14:09 ` Darrel Goeddel
1 sibling, 4 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 13:29 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> I like the functionality, but I don't like having yet another mechanism
> and configuration, and I'm concerned about it being netlabel-centric.
NetLabel has always been designed as a framework to support multiple different
types of labeling protocols/mechanisms. Adding this bit of functionality to
NetLabel isn't a major departure from the existing architecture. The only
real substantial changes to the underlying NetLabel framework are the passing
of the IP address family to some of the NetLabel APIs (minor tweak) and the
addition of a secid field to the NetLabel security attributes struct (also a
pretty minor tweak).
I'm also a little confused about your concern over this new feature being
NetLabel-centric? I guess I don't understand how that is a problem, further
explanation might help ...
I understand your concern regarding the additional configuration. While
netlabelctl and netlabel_tools are not new, they may be new to users who want
to make use of this new feature. On an older thread Josh and I had a bit of
a discussion regarding this and while we never really arrived at a magic
solution we did talk about integrating some, or all, of the netlabelctl
functionality into semanage. This wouldn't be that difficult as most of
the "intelligence" in netlabelctl is already in a separate library; adding
that library to semanage should not be that difficult. Would that help ease
your configuration concerns?
> The only reason to not use secmark today for a fallback mechanism is the
> current separation between 'internal' and 'external' labels. But I
> don't believe that separation is necessary or useful, and secmark today
> is effectively unused. The original usage scenario for it simply hasn't
> materialized.
>
> Meanwhile, getting secmark employed, not only as a mechanism for
> assigning default labels (via iptables rules) but also as a seamless way
> of propagating labels with socket buffers would solve a lot of our
> current limitations. We'd get loopback labeling for free, flexible and
> generic fallback labeling, forwarding controls would become
> straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> NetLabel would benefit from it as well. There are alternative
> implementation approaches, but none as clean and efficient and reliable.
> There was a reason we put a sid in the sk_buff in the original SELinux
> implementations (prior to Linux 2.6 merge).
>
> I've had some initial discussions with James, and he seemed open to
> revisiting this notion, so I think we need to take another look.
I still think merging the two types of packet labels, "internal"
and "external" is a mistake; I stated my reasoning a few times before so I
will save people following this thread from reading it again.
However, I agree that packet labeling is in a "weird" state right now and
there is a lot of room for improvement. Bearing in mind your comments that
SECMARK is effectively unused due to lack of demand and that having two types
of packet labels is not helpful I wonder if the following would a worthwhile
effort:
* Do away with internal label concept completely, but leave the SECMARK
secid field in the sk_buff struct. This includes removing the SECMARK
related MAC checks on incoming traffic, whether we bring back compat_net
or not is not important.
* Convert the external labeling protocols to make use of the SECMARK secid
field in the sk_buff struct. The advantage to NetLabel and explicit
labeling protocols is really marginal but this should be a huge win for
labeled IPsec.
As you stated above, there are some obvious advantages here including "free"
loopback labeling, easier implementation of general iptables forwarding
controls in the future, as well as some general implementation cleanups in
the existing code. If we did decide to go this route, I think I would prefer
to keep a fallback/static labeling mechanism similar to what is being done in
this patchset, with the obvious change being made to utilize the new SECMARK
secid value. We've seen all of the issues that come to light when we start
to make use of iptables to set labels on packets and not all of them have
elegant solutions; one could even argue this is one of the reasons SECMARK as
an internal label has failed to achieve much use.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
@ 2007-08-09 13:54 ` Stephen Smalley
2007-08-09 14:48 ` Paul Moore
2007-08-09 13:59 ` James Morris
` (2 subsequent siblings)
3 siblings, 1 reply; 57+ messages in thread
From: Stephen Smalley @ 2007-08-09 13:54 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > I like the functionality, but I don't like having yet another mechanism
> > and configuration, and I'm concerned about it being netlabel-centric.
>
> NetLabel has always been designed as a framework to support multiple different
> types of labeling protocols/mechanisms. Adding this bit of functionality to
> NetLabel isn't a major departure from the existing architecture. The only
> real substantial changes to the underlying NetLabel framework are the passing
> of the IP address family to some of the NetLabel APIs (minor tweak) and the
> addition of a secid field to the NetLabel security attributes struct (also a
> pretty minor tweak).
>
> I'm also a little confused about your concern over this new feature being
> NetLabel-centric? I guess I don't understand how that is a problem, further
> explanation might help ...
We want a fallback mechanism that is agnostic to the labeled networking
mechanism. netlabel may be a "framework" but only for a particular
subset of such mechanisms, i.e. explicit packet labeling. Putting
functionality into it that should also apply to xfrm labeling is wrong.
> I understand your concern regarding the additional configuration. While
> netlabelctl and netlabel_tools are not new, they may be new to users who want
> to make use of this new feature. On an older thread Josh and I had a bit of
> a discussion regarding this and while we never really arrived at a magic
> solution we did talk about integrating some, or all, of the netlabelctl
> functionality into semanage. This wouldn't be that difficult as most of
> the "intelligence" in netlabelctl is already in a separate library; adding
> that library to semanage should not be that difficult. Would that help ease
> your configuration concerns?
I don't care what we call the userland tool; it is still using
netlabel-specific interfaces and infrastructure. And re-inventing the
secmark wheel.
> > The only reason to not use secmark today for a fallback mechanism is the
> > current separation between 'internal' and 'external' labels. But I
> > don't believe that separation is necessary or useful, and secmark today
> > is effectively unused. The original usage scenario for it simply hasn't
> > materialized.
> >
> > Meanwhile, getting secmark employed, not only as a mechanism for
> > assigning default labels (via iptables rules) but also as a seamless way
> > of propagating labels with socket buffers would solve a lot of our
> > current limitations. We'd get loopback labeling for free, flexible and
> > generic fallback labeling, forwarding controls would become
> > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > NetLabel would benefit from it as well. There are alternative
> > implementation approaches, but none as clean and efficient and reliable.
> > There was a reason we put a sid in the sk_buff in the original SELinux
> > implementations (prior to Linux 2.6 merge).
> >
> > I've had some initial discussions with James, and he seemed open to
> > revisiting this notion, so I think we need to take another look.
>
> I still think merging the two types of packet labels, "internal"
> and "external" is a mistake; I stated my reasoning a few times before so I
> will save people following this thread from reading it again.
No one is using the "internal" labels AFAIK, and conceptually, I don't
see a security goal that you would enforce that way that isn't more
cleanly expressed (and more useful) in terms of "external" label.
> However, I agree that packet labeling is in a "weird" state right now and
> there is a lot of room for improvement. Bearing in mind your comments that
> SECMARK is effectively unused due to lack of demand and that having two types
> of packet labels is not helpful I wonder if the following would a worthwhile
> effort:
>
> * Do away with internal label concept completely, but leave the SECMARK
> secid field in the sk_buff struct. This includes removing the SECMARK
> related MAC checks on incoming traffic, whether we bring back compat_net
> or not is not important.
Agree with the first part, but not the second. The secmark packet
checks are actually what we want, with some modification. IOW, we want
a unified set of checks independent of labeled networking mechanism so
that we can have coherent policy. And while we do away with any
separate notion of "internal" vs "external", we'd still use iptables
secmark rules to define and apply the fallback labels - that is more
expressive and generic than your approach.
> * Convert the external labeling protocols to make use of the SECMARK secid
> field in the sk_buff struct. The advantage to NetLabel and explicit
> labeling protocols is really marginal but this should be a huge win for
> labeled IPsec.
I'm not so sure it is so marginal for netlabel - being able to use a
field from the skb (once initially set for the packet) instead of
inspecting the payload should be a win.
> As you stated above, there are some obvious advantages here including "free"
> loopback labeling, easier implementation of general iptables forwarding
> controls in the future, as well as some general implementation cleanups in
> the existing code. If we did decide to go this route, I think I would prefer
> to keep a fallback/static labeling mechanism similar to what is being done in
> this patchset, with the obvious change being made to utilize the new SECMARK
> secid value. We've seen all of the issues that come to light when we start
> to make use of iptables to set labels on packets and not all of them have
> elegant solutions; one could even argue this is one of the reasons SECMARK as
> an internal label has failed to achieve much use.
You'll have to elaborate on that one; defining an iptables rule to apply
a fallback label seems much more general and expressive than the
netlabelctl approach.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:54 ` Stephen Smalley
@ 2007-08-09 14:48 ` Paul Moore
2007-08-09 15:49 ` James Morris
2007-08-09 16:01 ` Stephen Smalley
0 siblings, 2 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 14:48 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
On Thursday 09 August 2007 9:54:23 am Stephen Smalley wrote:
> On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> > On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > I'm also a little confused about your concern over this new feature being
> > NetLabel-centric? I guess I don't understand how that is a problem,
> > further explanation might help ...
>
> We want a fallback mechanism that is agnostic to the labeled networking
> mechanism. netlabel may be a "framework" but only for a particular
> subset of such mechanisms, i.e. explicit packet labeling. Putting
> functionality into it that should also apply to xfrm labeling is wrong.
I guess this is always going to be a bit of a religious argument then, as I
tend to think of this feature as a static external label and implementing
this feature as part of an existing external labeling system/framework makes
the most sense to me. Regardless, it's probably best to focus on the other
issues in this thread, namely what to do with SECMARK, first as that will
have a huge impact on this topic.
> > I understand your concern regarding the additional configuration. While
> > netlabelctl and netlabel_tools are not new, they may be new to users who
> > want to make use of this new feature. On an older thread Josh and I had
> > a bit of a discussion regarding this and while we never really arrived at
> > a magic solution we did talk about integrating some, or all, of the
> > netlabelctl functionality into semanage. This wouldn't be that difficult
> > as most of the "intelligence" in netlabelctl is already in a separate
> > library; adding that library to semanage should not be that difficult.
> > Would that help ease your configuration concerns?
>
> I don't care what we call the userland tool; it is still using
> netlabel-specific interfaces and infrastructure.
> And re-inventing the secmark wheel.
Well, only if you redefine SECMARK to a greater scope that what it is used for
today. Granted, both this new static/fallback label feature use IP header
information to derive a packet label but that's about the only similarity I
see here. If we do decide to redefine SECMARK then you'll be correct, no
need for this patchset.
> > > The only reason to not use secmark today for a fallback mechanism is
> > > the current separation between 'internal' and 'external' labels. But I
> > > don't believe that separation is necessary or useful, and secmark today
> > > is effectively unused. The original usage scenario for it simply
> > > hasn't materialized.
> > >
> > > Meanwhile, getting secmark employed, not only as a mechanism for
> > > assigning default labels (via iptables rules) but also as a seamless
> > > way of propagating labels with socket buffers would solve a lot of our
> > > current limitations. We'd get loopback labeling for free, flexible and
> > > generic fallback labeling, forwarding controls would become
> > > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > > NetLabel would benefit from it as well. There are alternative
> > > implementation approaches, but none as clean and efficient and
> > > reliable. There was a reason we put a sid in the sk_buff in the
> > > original SELinux implementations (prior to Linux 2.6 merge).
> > >
> > > I've had some initial discussions with James, and he seemed open to
> > > revisiting this notion, so I think we need to take another look.
> >
> > I still think merging the two types of packet labels, "internal"
> > and "external" is a mistake; I stated my reasoning a few times before so
> > I will save people following this thread from reading it again.
>
> No one is using the "internal" labels AFAIK, and conceptually, I don't
> see a security goal that you would enforce that way that isn't more
> cleanly expressed (and more useful) in terms of "external" label.
Okay, so let's get rid of the "internal" label.
> > However, I agree that packet labeling is in a "weird" state right now and
> > there is a lot of room for improvement. Bearing in mind your comments
> > that SECMARK is effectively unused due to lack of demand and that having
> > two types of packet labels is not helpful I wonder if the following would
> > a worthwhile effort:
> >
> > * Do away with internal label concept completely, but leave the SECMARK
> > secid field in the sk_buff struct. This includes removing the SECMARK
> > related MAC checks on incoming traffic, whether we bring back
> > compat_net or not is not important.
>
> Agree with the first part, but not the second. The secmark packet
> checks are actually what we want, with some modification. IOW, we want
> a unified set of checks independent of labeled networking mechanism so
> that we can have coherent policy.
Looking again at what I typed, I realized I worded it very poorly. What I
mean was that we should remove the iptables/SECMARK hooks so that the
iptables bits no longer set the label of a packet, i.e. remove the internal
labeling as we know it today.
> And while we do away with any
> separate notion of "internal" vs "external", we'd still use iptables
> secmark rules to define and apply the fallback labels - that is more
> expressive and generic than your approach.
My main concern with this goes back to the failed secid-reconciliation
efforts; the key problem here has to do with the behavior of getpeercon().
As it stands right now, in the case of of a UNIX domain socket we return the
label of the domain on the other end, the same with network sockets. The
current proposed static/fallback mechanism is intentionally coarse grained
with the granularity limit being a single IP address/host. My reasoning
being that if the other host is not able or willing to send labeled traffic
we should treat it as a single label host. This seems to mesh well with what
has been done in the past.
If we adopt the revised SECMARK/iptables method then this is no guaranteed to
be the case. With the added flexibility/granularity of iptables we could
arrive in a situation where a single IP address/host could take on multiple
different labels based on the type of connection. Maybe this is what you
want, but it is a departure from what we do today as well as what I've heard
has been done in the past. Then again, just because we've always done it
this way doesn't mean it's the best solution.
> > * Convert the external labeling protocols to make use of the SECMARK
> > secid field in the sk_buff struct. The advantage to NetLabel and
> > explicit labeling protocols is really marginal but this should be a huge
> > win for labeled IPsec.
>
> I'm not so sure it is so marginal for netlabel - being able to use a
> field from the skb (once initially set for the packet) instead of
> inspecting the payload should be a win.
>From a functionality standpoint it is marginal for explicitly labeled packets
because you already have the label as part of the packet's header/payload;
that is what I was referring to. I agree there are some obvious performance
advantages if you have to look at the label twice.
> > As you stated above, there are some obvious advantages here including
> > "free" loopback labeling, easier implementation of general iptables
> > forwarding controls in the future, as well as some general implementation
> > cleanups in the existing code. If we did decide to go this route, I
> > think I would prefer to keep a fallback/static labeling mechanism similar
> > to what is being done in this patchset, with the obvious change being
> > made to utilize the new SECMARK secid value. We've seen all of the
> > issues that come to light when we start to make use of iptables to set
> > labels on packets and not all of them have elegant solutions; one could
> > even argue this is one of the reasons SECMARK as an internal label has
> > failed to achieve much use.
>
> You'll have to elaborate on that one; defining an iptables rule to apply
> a fallback label seems much more general and expressive than the
> netlabelctl approach.
See my comments above about the difference in getpeercon() behavior. There
are also implementation issues regarding the use of iptables, the "flush all"
case being a good example. Yes, there have been solutions tossed around but
nothing concrete. There is also the ongoing debate about how to properly
generate iptables rules in policy, without a good solution here anything we
do that uses iptables to label packets is going to have a hard time getting
adopted by users.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:48 ` Paul Moore
@ 2007-08-09 15:49 ` James Morris
2007-08-09 16:01 ` Stephen Smalley
1 sibling, 0 replies; 57+ messages in thread
From: James Morris @ 2007-08-09 15:49 UTC (permalink / raw)
To: Paul Moore; +Cc: Stephen Smalley, selinux, kaigai, joe, Eric Paris
On Thu, 9 Aug 2007, Paul Moore wrote:
> See my comments above about the difference in getpeercon() behavior. There
> are also implementation issues regarding the use of iptables, the "flush all"
> case being a good example.
You need cap_net_admin, so it is technically controllable in terms of
MAC.
It may also be possible to create a new table which has finer-grained MAC
controls.
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:48 ` Paul Moore
2007-08-09 15:49 ` James Morris
@ 2007-08-09 16:01 ` Stephen Smalley
2007-08-09 22:35 ` Paul Moore
1 sibling, 1 reply; 57+ messages in thread
From: Stephen Smalley @ 2007-08-09 16:01 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
On Thu, 2007-08-09 at 10:48 -0400, Paul Moore wrote:
> On Thursday 09 August 2007 9:54:23 am Stephen Smalley wrote:
> > On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> > > On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > > I'm also a little confused about your concern over this new feature being
> > > NetLabel-centric? I guess I don't understand how that is a problem,
> > > further explanation might help ...
> >
> > We want a fallback mechanism that is agnostic to the labeled networking
> > mechanism. netlabel may be a "framework" but only for a particular
> > subset of such mechanisms, i.e. explicit packet labeling. Putting
> > functionality into it that should also apply to xfrm labeling is wrong.
>
> I guess this is always going to be a bit of a religious argument then, as I
> tend to think of this feature as a static external label and implementing
> this feature as part of an existing external labeling system/framework makes
> the most sense to me. Regardless, it's probably best to focus on the other
> issues in this thread, namely what to do with SECMARK, first as that will
> have a huge impact on this topic.
I agree with that last sentence ;)
> > > I understand your concern regarding the additional configuration. While
> > > netlabelctl and netlabel_tools are not new, they may be new to users who
> > > want to make use of this new feature. On an older thread Josh and I had
> > > a bit of a discussion regarding this and while we never really arrived at
> > > a magic solution we did talk about integrating some, or all, of the
> > > netlabelctl functionality into semanage. This wouldn't be that difficult
> > > as most of the "intelligence" in netlabelctl is already in a separate
> > > library; adding that library to semanage should not be that difficult.
> > > Would that help ease your configuration concerns?
> >
> > I don't care what we call the userland tool; it is still using
> > netlabel-specific interfaces and infrastructure.
>
> > And re-inventing the secmark wheel.
>
> Well, only if you redefine SECMARK to a greater scope that what it is used for
> today. Granted, both this new static/fallback label feature use IP header
> information to derive a packet label but that's about the only similarity I
> see here. If we do decide to redefine SECMARK then you'll be correct, no
> need for this patchset.
Exactly.
> > > > The only reason to not use secmark today for a fallback mechanism is
> > > > the current separation between 'internal' and 'external' labels. But I
> > > > don't believe that separation is necessary or useful, and secmark today
> > > > is effectively unused. The original usage scenario for it simply
> > > > hasn't materialized.
> > > >
> > > > Meanwhile, getting secmark employed, not only as a mechanism for
> > > > assigning default labels (via iptables rules) but also as a seamless
> > > > way of propagating labels with socket buffers would solve a lot of our
> > > > current limitations. We'd get loopback labeling for free, flexible and
> > > > generic fallback labeling, forwarding controls would become
> > > > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > > > NetLabel would benefit from it as well. There are alternative
> > > > implementation approaches, but none as clean and efficient and
> > > > reliable. There was a reason we put a sid in the sk_buff in the
> > > > original SELinux implementations (prior to Linux 2.6 merge).
> > > >
> > > > I've had some initial discussions with James, and he seemed open to
> > > > revisiting this notion, so I think we need to take another look.
> > >
> > > I still think merging the two types of packet labels, "internal"
> > > and "external" is a mistake; I stated my reasoning a few times before so
> > > I will save people following this thread from reading it again.
> >
> > No one is using the "internal" labels AFAIK, and conceptually, I don't
> > see a security goal that you would enforce that way that isn't more
> > cleanly expressed (and more useful) in terms of "external" label.
>
> Okay, so let's get rid of the "internal" label.
Yep, a packet has a single label at any given time. Period.
That label can get refined over time as we get more information,
starting from e.g. the receiving network device and sending address and
working our way up to an actual label associated with the packet via
netlabel or labeled xfrm.
Any other model is too confusing and yields curious behavior as the
distinct labels can become inconsistent with one another.
> > > However, I agree that packet labeling is in a "weird" state right now and
> > > there is a lot of room for improvement. Bearing in mind your comments
> > > that SECMARK is effectively unused due to lack of demand and that having
> > > two types of packet labels is not helpful I wonder if the following would
> > > a worthwhile effort:
> > >
> > > * Do away with internal label concept completely, but leave the SECMARK
> > > secid field in the sk_buff struct. This includes removing the SECMARK
> > > related MAC checks on incoming traffic, whether we bring back
> > > compat_net or not is not important.
> >
> > Agree with the first part, but not the second. The secmark packet
> > checks are actually what we want, with some modification. IOW, we want
> > a unified set of checks independent of labeled networking mechanism so
> > that we can have coherent policy.
>
> Looking again at what I typed, I realized I worded it very poorly. What I
> mean was that we should remove the iptables/SECMARK hooks so that the
> iptables bits no longer set the label of a packet, i.e. remove the internal
> labeling as we know it today.
Disagree. Letting a label be initially associated with a packet via
iptables is very useful.
> > And while we do away with any
> > separate notion of "internal" vs "external", we'd still use iptables
> > secmark rules to define and apply the fallback labels - that is more
> > expressive and generic than your approach.
>
> My main concern with this goes back to the failed secid-reconciliation
> efforts; the key problem here has to do with the behavior of getpeercon().
> As it stands right now, in the case of of a UNIX domain socket we return the
> label of the domain on the other end, the same with network sockets. The
> current proposed static/fallback mechanism is intentionally coarse grained
> with the granularity limit being a single IP address/host. My reasoning
> being that if the other host is not able or willing to send labeled traffic
> we should treat it as a single label host. This seems to mesh well with what
> has been done in the past.
The selection granularity is up to the person configuring the iptables
rules, so no harm there in providing him with more options but only
using the coarse-grained choices.
> If we adopt the revised SECMARK/iptables method then this is no guaranteed to
> be the case. With the added flexibility/granularity of iptables we could
> arrive in a situation where a single IP address/host could take on multiple
> different labels based on the type of connection. Maybe this is what you
> want, but it is a departure from what we do today as well as what I've heard
> has been done in the past. Then again, just because we've always done it
> this way doesn't mean it's the best solution.
My preference would be to have it assigned a single default/fallback
label based on iptables, and then overridden after a permission check if
labeled networking is in use. No other mutations.
> > > * Convert the external labeling protocols to make use of the SECMARK
> > > secid field in the sk_buff struct. The advantage to NetLabel and
> > > explicit labeling protocols is really marginal but this should be a huge
> > > win for labeled IPsec.
> >
> > I'm not so sure it is so marginal for netlabel - being able to use a
> > field from the skb (once initially set for the packet) instead of
> > inspecting the payload should be a win.
>
> >From a functionality standpoint it is marginal for explicitly labeled packets
> because you already have the label as part of the packet's header/payload;
> that is what I was referring to. I agree there are some obvious performance
> advantages if you have to look at the label twice.
Propagation/preservation of the label throughout also gets simpler and
more reliable, and possibly goes beyond what you can do today. How do
you deal with ICMP replies currently?
> > > As you stated above, there are some obvious advantages here including
> > > "free" loopback labeling, easier implementation of general iptables
> > > forwarding controls in the future, as well as some general implementation
> > > cleanups in the existing code. If we did decide to go this route, I
> > > think I would prefer to keep a fallback/static labeling mechanism similar
> > > to what is being done in this patchset, with the obvious change being
> > > made to utilize the new SECMARK secid value. We've seen all of the
> > > issues that come to light when we start to make use of iptables to set
> > > labels on packets and not all of them have elegant solutions; one could
> > > even argue this is one of the reasons SECMARK as an internal label has
> > > failed to achieve much use.
> >
> > You'll have to elaborate on that one; defining an iptables rule to apply
> > a fallback label seems much more general and expressive than the
> > netlabelctl approach.
>
> See my comments above about the difference in getpeercon() behavior. There
> are also implementation issues regarding the use of iptables, the "flush all"
> case being a good example. Yes, there have been solutions tossed around but
> nothing concrete. There is also the ongoing debate about how to properly
> generate iptables rules in policy, without a good solution here anything we
> do that uses iptables to label packets is going to have a hard time getting
> adopted by users.
We don't generate netlabelctl configuration or ipsec configuration from
policy, so this isn't really different. Ultimately, you'd have some
front-end tool that lets you configure labeled networking, including
selection of mechanism (NetLabel/CIPSO or NetLabel/other or labeled
IPSEC), selection of appropriate settings for that mechanism, and
fallbacks (via secmark).
Separate table would likely be useful.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 16:01 ` Stephen Smalley
@ 2007-08-09 22:35 ` Paul Moore
0 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 22:35 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, kaigai, joe, James Morris, Eric Paris
On Thursday, August 9 2007 12:01:46 pm Stephen Smalley wrote:
> On Thu, 2007-08-09 at 10:48 -0400, Paul Moore wrote:
> > On Thursday 09 August 2007 9:54:23 am Stephen Smalley wrote:
> > > On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:
> > If we adopt the revised SECMARK/iptables method then this is no
> > guaranteed to be the case. With the added flexibility/granularity of
> > iptables we could arrive in a situation where a single IP address/host
> > could take on multiple different labels based on the type of connection.
> > Maybe this is what you want, but it is a departure from what we do today
> > as well as what I've heard has been done in the past. Then again, just
> > because we've always done it this way doesn't mean it's the best
> > solution.
>
> My preference would be to have it assigned a single default/fallback
> label based on iptables, and then overridden after a permission check if
> labeled networking is in use. No other mutations.
>
> > > > * Convert the external labeling protocols to make use of the SECMARK
> > > > secid field in the sk_buff struct. The advantage to NetLabel and
> > > > explicit labeling protocols is really marginal but this should be a
> > > > huge win for labeled IPsec.
> > >
> > > I'm not so sure it is so marginal for netlabel - being able to use a
> > > field from the skb (once initially set for the packet) instead of
> > > inspecting the payload should be a win.
> > >
> > >From a functionality standpoint it is marginal for explicitly labeled
> > > packets
> >
> > because you already have the label as part of the packet's
> > header/payload; that is what I was referring to. I agree there are some
> > obvious performance advantages if you have to look at the label twice.
>
> Propagation/preservation of the label throughout also gets simpler and
> more reliable, and possibly goes beyond what you can do today.
Um, okay ... what are you trying to sell me here ;) I never said this
particular point is good/bad, just that I don't see this single point as
reason enough to go through with the changes you are proposing (from a
NetLabel point of view).
> How do you deal with ICMP replies currently?
For CIPSO they are labeled based on the packet which caused the ICMP message
to be generated as dictated by the draft.
> > > > As you stated above, there are some obvious advantages here including
> > > > "free" loopback labeling, easier implementation of general iptables
> > > > forwarding controls in the future, as well as some general
> > > > implementation cleanups in the existing code. If we did decide to go
> > > > this route, I think I would prefer to keep a fallback/static labeling
> > > > mechanism similar to what is being done in this patchset, with the
> > > > obvious change being made to utilize the new SECMARK secid value.
> > > > We've seen all of the issues that come to light when we start to make
> > > > use of iptables to set labels on packets and not all of them have
> > > > elegant solutions; one could even argue this is one of the reasons
> > > > SECMARK as an internal label has failed to achieve much use.
> > >
> > > You'll have to elaborate on that one; defining an iptables rule to
> > > apply a fallback label seems much more general and expressive than the
> > > netlabelctl approach.
> >
> > See my comments above about the difference in getpeercon() behavior.
> > There are also implementation issues regarding the use of iptables, the
> > "flush all" case being a good example. Yes, there have been solutions
> > tossed around but nothing concrete. There is also the ongoing debate
> > about how to properly generate iptables rules in policy, without a good
> > solution here anything we do that uses iptables to label packets is going
> > to have a hard time getting adopted by users.
>
> We don't generate netlabelctl configuration or ipsec configuration from
> policy, so this isn't really different. Ultimately, you'd have some
> front-end tool that lets you configure labeled networking, including
> selection of mechanism (NetLabel/CIPSO or NetLabel/other or labeled
> IPSEC), selection of appropriate settings for that mechanism, and
> fallbacks (via secmark).
Doesn't this hit at some of the same arguments you had against this patchset
regarding configuration at the start of this thread.
> Separate table would likely be useful.
Yes, probably even a requirement to help preserve the sanity of the admins.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
2007-08-09 13:54 ` Stephen Smalley
@ 2007-08-09 13:59 ` James Morris
2007-08-09 14:50 ` Paul Moore
2007-08-09 14:41 ` Darrel Goeddel
2007-08-09 15:32 ` Casey Schaufler
3 siblings, 1 reply; 57+ messages in thread
From: James Morris @ 2007-08-09 13:59 UTC (permalink / raw)
To: Paul Moore; +Cc: Stephen Smalley, selinux, kaigai, joe, Eric Paris
On Thu, 9 Aug 2007, Paul Moore wrote:
> However, I agree that packet labeling is in a "weird" state right now and
> there is a lot of room for improvement. Bearing in mind your comments that
> SECMARK is effectively unused due to lack of demand and that having two types
> of packet labels is not helpful I wonder if the following would a worthwhile
> effort:
I think a big factor here is that the OS integration work has not been
done, and there's a (general) lack of high-level tools for managing
SELinux. The functionality, in terms of providing complete coverage of
the OS, is required.
>
> * Do away with internal label concept completely, but leave the SECMARK
> secid field in the sk_buff struct. This includes removing the SECMARK
> related MAC checks on incoming traffic, whether we bring back compat_net
> or not is not important.
Removing the secmark checks would leave us without a good way to perform
local network labeling & control.
We should probably schedule compat_net removal per the kernel deprecation
schedule guidelines.
> * Convert the external labeling protocols to make use of the SECMARK secid
> field in the sk_buff struct. The advantage to NetLabel and explicit
> labeling protocols is really marginal but this should be a huge win for
> labeled IPsec.
The way we were discussing this (off-list) was that we'd allow iptables
secmark labeling to set fallback/default labels, which may be overridden
by external labeling (Netlabel, IPsec).
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:59 ` James Morris
@ 2007-08-09 14:50 ` Paul Moore
2007-08-09 15:13 ` Stephen Smalley
0 siblings, 1 reply; 57+ messages in thread
From: Paul Moore @ 2007-08-09 14:50 UTC (permalink / raw)
To: James Morris; +Cc: Stephen Smalley, selinux, kaigai, joe, Eric Paris
On Thursday 09 August 2007 9:59:53 am James Morris wrote:
> On Thu, 9 Aug 2007, Paul Moore wrote:
> > * Convert the external labeling protocols to make use of the SECMARK
> > secid field in the sk_buff struct. The advantage to NetLabel and
> > explicit labeling protocols is really marginal but this should be a huge
> > win for labeled IPsec.
>
> The way we were discussing this (off-list) was that we'd allow iptables
> secmark labeling to set fallback/default labels, which may be overridden
> by external labeling (Netlabel, IPsec).
If I understand you correctly, SECMARK would continue as SECMARK as we know it
today, the only real difference is that if getpeercon() would return failure
because NetLabel or labeled IPsec was not in use we would return the SECMARK
label?
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:50 ` Paul Moore
@ 2007-08-09 15:13 ` Stephen Smalley
0 siblings, 0 replies; 57+ messages in thread
From: Stephen Smalley @ 2007-08-09 15:13 UTC (permalink / raw)
To: Paul Moore; +Cc: James Morris, selinux, kaigai, joe, Eric Paris
On Thu, 2007-08-09 at 10:50 -0400, Paul Moore wrote:
> On Thursday 09 August 2007 9:59:53 am James Morris wrote:
> > On Thu, 9 Aug 2007, Paul Moore wrote:
> > > * Convert the external labeling protocols to make use of the SECMARK
> > > secid field in the sk_buff struct. The advantage to NetLabel and
> > > explicit labeling protocols is really marginal but this should be a huge
> > > win for labeled IPsec.
> >
> > The way we were discussing this (off-list) was that we'd allow iptables
> > secmark labeling to set fallback/default labels, which may be overridden
> > by external labeling (Netlabel, IPsec).
>
> If I understand you correctly, SECMARK would continue as SECMARK as we know it
> today, the only real difference is that if getpeercon() would return failure
> because NetLabel or labeled IPsec was not in use we would return the SECMARK
> label?
Except that secmark would also be used as the means of propagating the
label with the skb throughout the stack, thereby enabling loopback
labeling and flow control. So secmark gets initialized via iptables to
a fallback (or left unlabeled if no iptables match exists), then
replaced (after a consistency check) if labeled networking is in use
with the explicit or implicit label. Then the secmark gets used
everywhere for permission checking - it represents the most accurate
label we know for the packet at any given time.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
2007-08-09 13:54 ` Stephen Smalley
2007-08-09 13:59 ` James Morris
@ 2007-08-09 14:41 ` Darrel Goeddel
2007-08-09 14:57 ` Paul Moore
2007-08-09 15:32 ` Casey Schaufler
3 siblings, 1 reply; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 14:41 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, joe, James Morris, Eric Paris, kaigai
Paul Moore wrote:
> On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
>> I like the functionality, but I don't like having yet another mechanism
>> and configuration, and I'm concerned about it being netlabel-centric.
>
> NetLabel has always been designed as a framework to support multiple
different
> types of labeling protocols/mechanisms. Adding this bit of functionality
to
> NetLabel isn't a major departure from the existing architecture. The only
> real substantial changes to the underlying NetLabel framework are the
passing
> of the IP address family to some of the NetLabel APIs (minor tweak) and
the
> addition of a secid field to the NetLabel security attributes struct (also
a
> pretty minor tweak).
>
> I'm also a little confused about your concern over this new feature being
> NetLabel-centric? I guess I don't understand how that is a problem,
further
> explanation might help ...
I actually have a question regarding this. This all seems to be aimed at
getting
getpeercon to always return our "best knowledge" of what the peer's context
actually
is. This is excellent - we need this functionality. getpeercon will return
the
xfrm label (which is, by mechanism, the context of the peer) if labeled
ipsec is
being used, correct? netlabel will then modify that label with it's own
idea
of the peer, correct? Doesn't that mean a secret peer (using labeled ipsec)
will
now actually look like a top_secret peer if there is a "fallback" that
specifies
this host as top_secret? I think this is currently a problem with
"fighting"
mechanism that attempt to give information regarding the peer. There is no
consistency between them. A true fallback would have to occur *before* any
peer
provided label information would be processed. I also think that there must
be consistency forced between the different peer labeling mechanisms. If I
get
packets that are specified as top_secret via CIPSO over an ipsec association
labeled as user_u:user_r:user_t:secret, that packet should die.
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:41 ` Darrel Goeddel
@ 2007-08-09 14:57 ` Paul Moore
2007-08-09 15:07 ` Darrel Goeddel
0 siblings, 1 reply; 57+ messages in thread
From: Paul Moore @ 2007-08-09 14:57 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Stephen Smalley, selinux, joe, James Morris, Eric Paris, kaigai
On Thursday 09 August 2007 10:41:09 am Darrel Goeddel wrote:
> ... I also think that there must be consistency forced between the different
> peer labeling mechanisms. If I get packets that are specified as top_secret
> via CIPSO over an ipsec association labeled as user_u:user_r:user_t:secret,
> that packet should die.
Yes. This is one of the places in the labeled networking code that has always
bothered me. The current mashup of labels was rather a poor attempt at
compromise by everyone involved and I think everyone will agree that we need
to come up with a better solution.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:57 ` Paul Moore
@ 2007-08-09 15:07 ` Darrel Goeddel
0 siblings, 0 replies; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 15:07 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, joe, James Morris, Eric Paris, kaigai
Paul Moore wrote:
> On Thursday 09 August 2007 10:41:09 am Darrel Goeddel wrote:
>> ... I also think that there must be consistency forced between the
different
>> peer labeling mechanisms. If I get packets that are specified as
top_secret
>> via CIPSO over an ipsec association labeled as
user_u:user_r:user_t:secret,
>> that packet should die.
>
> Yes. This is one of the places in the labeled networking code that has
always
> bothered me. The current mashup of labels was rather a poor attempt at
> compromise by everyone involved and I think everyone will agree that we
need
> to come up with a better solution.
That is what I was afraid of... So we currently have a problem where
getpeercon
can distort the MLS portion of the peer's context in the case of CIPSO and
labeled ipsec being employed. The netlabel fallback mechanism will
exacerbate
this problem by making making it much easier to exploit the problem because
labeled ipsec with fallback is very desirable. I want to treat hosts on a
certain net as secret in general, but I also want to allow some
administrative
connections at systemhigh using labled ipsec. In this case, the fallback
would
be trumping my attempts to provide my real local context to the server I am
trying to connect to. It is real scary in the opposite case - a top_secret
fallback MLS level trumping a lowly user's unclassified ipsec label and
giving
him access to a whole bunch of goodies... I really think using secmark as
a fallback, below the peer provided labeling information, is going to be the
best
solution to this problem.
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 13:29 ` Paul Moore
` (2 preceding siblings ...)
2007-08-09 14:41 ` Darrel Goeddel
@ 2007-08-09 15:32 ` Casey Schaufler
2007-08-09 15:39 ` Stephen Smalley
3 siblings, 1 reply; 57+ messages in thread
From: Casey Schaufler @ 2007-08-09 15:32 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley
Cc: selinux, kaigai, joe, James Morris, Eric Paris
--- Paul Moore <paul.moore@hp.com> wrote:
> On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > I like the functionality, but I don't like having yet another mechanism
> > and configuration, and I'm concerned about it being netlabel-centric.
>
> NetLabel has always been designed as a framework to support multiple
> different
> types of labeling protocols/mechanisms. Adding this bit of functionality to
> NetLabel isn't a major departure from the existing architecture. The only
> real substantial changes to the underlying NetLabel framework are the passing
>
> of the IP address family to some of the NetLabel APIs (minor tweak) and the
> addition of a secid field to the NetLabel security attributes struct (also a
> pretty minor tweak).
>
> I'm also a little confused about your concern over this new feature being
> NetLabel-centric? I guess I don't understand how that is a problem, further
> explanation might help ...
>
> I understand your concern regarding the additional configuration. While
> netlabelctl and netlabel_tools are not new, they may be new to users who want
>
> to make use of this new feature. On an older thread Josh and I had a bit of
> a discussion regarding this and while we never really arrived at a magic
> solution we did talk about integrating some, or all, of the netlabelctl
> functionality into semanage. This wouldn't be that difficult as most of
> the "intelligence" in netlabelctl is already in a separate library; adding
> that library to semanage should not be that difficult. Would that help ease
> your configuration concerns?
>
> > The only reason to not use secmark today for a fallback mechanism is the
> > current separation between 'internal' and 'external' labels. But I
> > don't believe that separation is necessary or useful, and secmark today
> > is effectively unused. The original usage scenario for it simply hasn't
> > materialized.
> >
> > Meanwhile, getting secmark employed, not only as a mechanism for
> > assigning default labels (via iptables rules) but also as a seamless way
> > of propagating labels with socket buffers would solve a lot of our
> > current limitations. We'd get loopback labeling for free, flexible and
> > generic fallback labeling, forwarding controls would become
> > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > NetLabel would benefit from it as well. There are alternative
> > implementation approaches, but none as clean and efficient and reliable.
> > There was a reason we put a sid in the sk_buff in the original SELinux
> > implementations (prior to Linux 2.6 merge).
> >
> > I've had some initial discussions with James, and he seemed open to
> > revisiting this notion, so I think we need to take another look.
>
> I still think merging the two types of packet labels, "internal"
> and "external" is a mistake; I stated my reasoning a few times before so I
> will save people following this thread from reading it again.
>
> However, I agree that packet labeling is in a "weird" state right now and
> there is a lot of room for improvement. Bearing in mind your comments that
> SECMARK is effectively unused due to lack of demand and that having two types
>
> of packet labels is not helpful I wonder if the following would a worthwhile
> effort:
>
> * Do away with internal label concept completely, but leave the SECMARK
> secid field in the sk_buff struct. This includes removing the SECMARK
> related MAC checks on incoming traffic, whether we bring back compat_net
> or not is not important.
> * Convert the external labeling protocols to make use of the SECMARK secid
> field in the sk_buff struct. The advantage to NetLabel and explicit
> labeling protocols is really marginal but this should be a huge win for
> labeled IPsec.
If y'all are going to look at this, please consider that secid's are
SELinux specific and using them in system interfaces is an impediment
to the development of other schemes. One important reason that Smack is
using netlabel in favor of secmark is that secid interface.
> As you stated above, there are some obvious advantages here including "free"
> loopback labeling, easier implementation of general iptables forwarding
> controls in the future, as well as some general implementation cleanups in
> the existing code. If we did decide to go this route, I think I would prefer
>
> to keep a fallback/static labeling mechanism similar to what is being done in
>
> this patchset, with the obvious change being made to utilize the new SECMARK
> secid value. We've seen all of the issues that come to light when we start
> to make use of iptables to set labels on packets and not all of them have
> elegant solutions; one could even argue this is one of the reasons SECMARK as
>
> an internal label has failed to achieve much use.
>
> --
> 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 majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>
>
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 15:32 ` Casey Schaufler
@ 2007-08-09 15:39 ` Stephen Smalley
2007-08-09 16:16 ` Casey Schaufler
0 siblings, 1 reply; 57+ messages in thread
From: Stephen Smalley @ 2007-08-09 15:39 UTC (permalink / raw)
To: casey; +Cc: Paul Moore, selinux, kaigai, joe, James Morris, Eric Paris
On Thu, 2007-08-09 at 08:32 -0700, Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
>
> > On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
> > > I like the functionality, but I don't like having yet another mechanism
> > > and configuration, and I'm concerned about it being netlabel-centric.
> >
> > NetLabel has always been designed as a framework to support multiple
> > different
> > types of labeling protocols/mechanisms. Adding this bit of functionality to
> > NetLabel isn't a major departure from the existing architecture. The only
> > real substantial changes to the underlying NetLabel framework are the passing
> >
> > of the IP address family to some of the NetLabel APIs (minor tweak) and the
> > addition of a secid field to the NetLabel security attributes struct (also a
> > pretty minor tweak).
> >
> > I'm also a little confused about your concern over this new feature being
> > NetLabel-centric? I guess I don't understand how that is a problem, further
> > explanation might help ...
> >
> > I understand your concern regarding the additional configuration. While
> > netlabelctl and netlabel_tools are not new, they may be new to users who want
> >
> > to make use of this new feature. On an older thread Josh and I had a bit of
> > a discussion regarding this and while we never really arrived at a magic
> > solution we did talk about integrating some, or all, of the netlabelctl
> > functionality into semanage. This wouldn't be that difficult as most of
> > the "intelligence" in netlabelctl is already in a separate library; adding
> > that library to semanage should not be that difficult. Would that help ease
> > your configuration concerns?
> >
> > > The only reason to not use secmark today for a fallback mechanism is the
> > > current separation between 'internal' and 'external' labels. But I
> > > don't believe that separation is necessary or useful, and secmark today
> > > is effectively unused. The original usage scenario for it simply hasn't
> > > materialized.
> > >
> > > Meanwhile, getting secmark employed, not only as a mechanism for
> > > assigning default labels (via iptables rules) but also as a seamless way
> > > of propagating labels with socket buffers would solve a lot of our
> > > current limitations. We'd get loopback labeling for free, flexible and
> > > generic fallback labeling, forwarding controls would become
> > > straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> > > NetLabel would benefit from it as well. There are alternative
> > > implementation approaches, but none as clean and efficient and reliable.
> > > There was a reason we put a sid in the sk_buff in the original SELinux
> > > implementations (prior to Linux 2.6 merge).
> > >
> > > I've had some initial discussions with James, and he seemed open to
> > > revisiting this notion, so I think we need to take another look.
> >
> > I still think merging the two types of packet labels, "internal"
> > and "external" is a mistake; I stated my reasoning a few times before so I
> > will save people following this thread from reading it again.
> >
> > However, I agree that packet labeling is in a "weird" state right now and
> > there is a lot of room for improvement. Bearing in mind your comments that
> > SECMARK is effectively unused due to lack of demand and that having two types
> >
> > of packet labels is not helpful I wonder if the following would a worthwhile
> > effort:
> >
> > * Do away with internal label concept completely, but leave the SECMARK
> > secid field in the sk_buff struct. This includes removing the SECMARK
> > related MAC checks on incoming traffic, whether we bring back compat_net
> > or not is not important.
> > * Convert the external labeling protocols to make use of the SECMARK secid
> > field in the sk_buff struct. The advantage to NetLabel and explicit
> > labeling protocols is really marginal but this should be a huge win for
> > labeled IPsec.
>
> If y'all are going to look at this, please consider that secid's are
> SELinux specific and using them in system interfaces is an impediment
> to the development of other schemes. One important reason that Smack is
> using netlabel in favor of secmark is that secid interface.
The secid notion is the only reason we have a field in the sk_buff at
all. The original security blob in the sk_buff was rejected by David
Miller when the LSM networking hooks were put forward by James; it comes
back to lifecycle management and overhead. The secmark (just another
name for a secid) construct in contrast avoids the lifecycle management
requirement and due to its small fixed size avoids significant bloat.
There is considerable doubt that we could even get it expanded to being
a u64, much less turned into a security blob.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 15:39 ` Stephen Smalley
@ 2007-08-09 16:16 ` Casey Schaufler
0 siblings, 0 replies; 57+ messages in thread
From: Casey Schaufler @ 2007-08-09 16:16 UTC (permalink / raw)
To: Stephen Smalley, casey
Cc: Paul Moore, selinux, kaigai, joe, James Morris, Eric Paris
--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > If y'all are going to look at this, please consider that secid's are
> > SELinux specific and using them in system interfaces is an impediment
> > to the development of other schemes. One important reason that Smack is
> > using netlabel in favor of secmark is that secid interface.
>
> The secid notion is the only reason we have a field in the sk_buff at
> all. The original security blob in the sk_buff was rejected by David
> Miller when the LSM networking hooks were put forward by James; it comes
> back to lifecycle management and overhead. The secmark (just another
> name for a secid) construct in contrast avoids the lifecycle management
> requirement and due to its small fixed size avoids significant bloat.
> There is considerable doubt that we could even get it expanded to being
> a u64, much less turned into a security blob.
This is the answer I expected. I did have to raise the question.
I will stick with netlabel/cipso, and "ambient" labels rather than
the suggested secid based default scheme, at least for the time being.
Thank you.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 12:42 ` Stephen Smalley
2007-08-09 13:29 ` Paul Moore
@ 2007-08-09 14:09 ` Darrel Goeddel
2007-08-09 14:24 ` James Morris
2007-08-09 14:53 ` Paul Moore
1 sibling, 2 replies; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 14:09 UTC (permalink / raw)
To: Stephen Smalley
Cc: Paul Moore, selinux, kaigai, joe, James Morris, Eric Paris
Stephen Smalley wrote:
> On Tue, 2007-08-07 at 10:14 -0400, Paul Moore wrote:
>> This patchset adds the static/fallback labeling feature to NetLabel that
has
>> been requested on the SELinux mailing list more and more recently. This
new
>> bit of functionality also matches what can be found on similar
trusted/labeled
>> OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet
ready
>> for "upstreaming" so please do not pull this into any tree bound for the
>> mainline kernel; I still need to do more review and testing of the code.
>> However, I know there are several of you on this list that have been
anxiously
>> awaiting this patchset so I thought I would make an early release so you
could
>> get a peek and test it out. I won't be able to work on this patchset
much, if
>> at all, between August 10th and the 20th so don't expect an update from
me
>> until the end of August.
>>
>> The basic idea is that currently there is no method for providing an
external
>> label to fallback on if a labeled networking mechanism such as
NetLabel/CIPSO
>> or labeled IPsec is not in use. This patch adds a mechanism for
providing a
>> static fallback label, specified per interface/network, which is used
when
>> a NetLabel recognized labeling protocol (at this point CIPSO) is not in
use.
>>
>> For those of you wishing to try this patchset, it is backed against
Linus'
>> linux-2.6 git tree from the afternoon of August 6th, but I don't imagine
you'll
>> have many problems applying the patchset to later trees at this point in
the
>> 2.6.23 release cycle. In addition to the kernel patches you will also
need a
>> modified version of netlabelctl from the netlabel_tools package. A very
crude
>> version of the modified tools can be found in the netlabel_tools SVN
repository
>> in the static_label branch. Please check the NetLabel website on
SourceForge,
>> http://netlabel.sf.net, for information on the SVN repository. The three
new
>> netlabelctl commands are as follows:
>>
>> # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>]
label:<LABEL>
>> # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
>> # netlabelctl -p unlbl list
>>
>> DEV = interface, examples: eth0, lo
>> ADDR = IP address, examples: 192.168.0.3, ::1
>> MASK = IP address mask length, examples 8, 24, 64
>> LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2
>>
>> For example, if you wanted to label all inbound traffic on eth1 from
>> 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you
would
>> type:
>>
>> # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
>> label:system_u:object_r:staticlabel_t:s7
>>
>> Both IPv4 and IPv6 addresses can be used and if the address mask is
ommitted
>> from the command the address is assumed to be a host address, not a
network,
>> and the maximum mask size for that address family is used. If you do not
wish
>> to specify an address, simply use a address mask of zero, "/0", which
will
>> cause all addresses within that address family to match.
>
> Hi,
>
> I like the functionality, but I don't like having yet another mechanism
> and configuration, and I'm concerned about it being netlabel-centric.
> Especially when we already have a more generic and flexible mechanism
> for specifying packet labels, i.e. secmark.
>
> The only reason to not use secmark today for a fallback mechanism is the
> current separation between 'internal' and 'external' labels. But I
> don't believe that separation is necessary or useful, and secmark today
> is effectively unused. The original usage scenario for it simply hasn't
> materialized.
I agree whole-heartedly with the above statements. I actually use the
secmark
mechanism and labeled ipsec, but unfortunately I need a patched kernel to
make
the useful in in regards to the issues of flow control (providing a
mechanism
for a controlled network interface) and loopback labeling. These are
necessary
features for the user base I work with. This user base happens to be the
LSPP
crowd, folks that needed a certified platform, but now they can't use the
certified
platform because it is woefully lacking in the network control department.
> Meanwhile, getting secmark employed, not only as a mechanism for
> assigning default labels (via iptables rules) but also as a seamless way
> of propagating labels with socket buffers would solve a lot of our
> current limitations. We'd get loopback labeling for free, flexible and
> generic fallback labeling, forwarding controls would become
> straightforward, and PEERSEC/SCM_SECURITY becomes much simpler.
> NetLabel would benefit from it as well. There are alternative
> implementation approaches, but none as clean and efficient and reliable.
> There was a reason we put a sid in the sk_buff in the original SELinux
> implementations (prior to Linux 2.6 merge).
>
> I've had some initial discussions with James, and he seemed open to
> revisiting this notion, so I think we need to take another look.
Because of the position I am in (needing to find something workable for
actual
users), I have been trying to get my head aounrd the state of SELinux
networking,
the ideas that have been talked about in the past, and how we can prevent
the
SELinux networking infrastructure from resembling a Rube-Goldberg machine.
I'll
be presenting some of the problems I perceive along with some very high
level
ideas early next week.
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:09 ` Darrel Goeddel
@ 2007-08-09 14:24 ` James Morris
2007-08-09 16:42 ` Darrel Goeddel
2007-08-09 14:53 ` Paul Moore
1 sibling, 1 reply; 57+ messages in thread
From: James Morris @ 2007-08-09 14:24 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Stephen Smalley, Paul Moore, selinux, kaigai, joe, Eric Paris
On Thu, 9 Aug 2007, Darrel Goeddel wrote:
> Because of the position I am in (needing to find something workable for
> actual
> users), I have been trying to get my head aounrd the state of SELinux
> networking,
> the ideas that have been talked about in the past, and how we can prevent
> the
> SELinux networking infrastructure from resembling a Rube-Goldberg machine.
> I'll
> be presenting some of the problems I perceive along with some very high
> level
> ideas early next week.
I think the problem we have faced in this area here is not enough focus on
general usability, and how to make this stuff useful beyond "lspp"
customers. It is essential for SELinux to succeed that it is generally
useful, and capable of addressing general security requirements, otherwise
we _effectively_ end up with a Trusted Solaris style fork, where you have
this odd code in the corner that most people don't and won't use.
The proposal outlined in my last email is:
- Retain existing secmark facilities, allowing them to be used as a way to
provide default/fallback labeling
- Allow external labeling (IPsec, CIPSO) to override the secmark labels
This gives us loopback labeling, the ability to retain the general
usability of only local iptables-based labeling, and a very simple
mechanism for integrating external labeling.
Does this address all of your requirements ?
If not, please explain what's missing.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:24 ` James Morris
@ 2007-08-09 16:42 ` Darrel Goeddel
2007-08-09 19:20 ` Joe Nall
0 siblings, 1 reply; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 16:42 UTC (permalink / raw)
To: James Morris
Cc: Stephen Smalley, Paul Moore, selinux, kaigai, joe, Eric Paris
James Morris wrote:
> On Thu, 9 Aug 2007, Darrel Goeddel wrote:
>
>> Because of the position I am in (needing to find something workable for
>> actual
>> users), I have been trying to get my head aounrd the state of SELinux
>> networking,
>> the ideas that have been talked about in the past, and how we can prevent
>> the
>> SELinux networking infrastructure from resembling a Rube-Goldberg
machine.
>> I'll
>> be presenting some of the problems I perceive along with some very high
>> level
>> ideas early next week.
>
> I think the problem we have faced in this area here is not enough focus on
> general usability, and how to make this stuff useful beyond "lspp"
> customers. It is essential for SELinux to succeed that it is generally
> useful, and capable of addressing general security requirements, otherwise
> we _effectively_ end up with a Trusted Solaris style fork, where you have
> this odd code in the corner that most people don't and won't use.
I am in full agreement. In fact I fear we may have started down that road
and
need to look at the big picture to avoid going further (and possibly back up
a bit...) Part of the problem set that I am looking at include the
complexity
of the network controls in general. It seems that what people really want
is
to think of the peer when deciding on whether or not we can do a little
networking. I'll get into this more when I think I have a good enough
understanding of some of the issues (why couldn't this have all waited a
bit...). I would be interested in hearing if people think that this does
not
make sense because I don't want to waste a bunch of time getting focused on
that (confirmation of the desire is also welcome).
OK, I'll give a quick thought right now:
It seems like "can system_u:system_r:ntpd_t:secret (ntp daemon) talk
to system_u:system_r:ntp_t:secret (peer ntp client)" is a much more sensible
question to address than "can system_u:system_r:ntpd_t:secret receive a
system_u:system_r:ntp_client_pkt_t packet, through a
system_u:system_r:unlabeled_t:systemhigh association (which may not really
exist), through a system_u:system_r:unlabeled_t:systemhigh socket"?
The socket vs secmark check seems to become intuitive and the others are no
longer necessary when everything is seen as the context of the peer (whether
it be from our iptables definition or explicit info from the peer itself).
Yes, I was all in favor of treating the packet as data in the past - that is
still very intuitive to me as there is no process inside of it. However, I
realize the nicety of treating the packet as an extension of the peer
process.
If we pick one and stick with it, things are much easier to understand and
therefore configure properly. I am now choosing the peer domain instead of
the packet data idea for my further thoughts...
> The proposal outlined in my last email is:
>
> - Retain existing secmark facilities, allowing them to be used as a way to
> provide default/fallback labeling
>
> - Allow external labeling (IPsec, CIPSO) to override the secmark labels
>
> This gives us loopback labeling, the ability to retain the general
> usability of only local iptables-based labeling, and a very simple
> mechanism for integrating external labeling.
>
> Does this address all of your requirements ?
Yes. That is the foundation of the labeling process. There are details
such as making sure that multiple sources of peer-provided label information
are in agreement, but the foundation is solid and simple.
> If not, please explain what's missing.
As far as labeling goes, we are good. We'll need to do something
constructive
with those labels as well. I think the above example that gives meaning to
the socket vs. secmark check shows how we could look at things in a simpler,
more intuitive way. We'll also need to address the checks on outbound
(locally
generated and forwarded) traffic. Good news is that getpeercon work for
free,
just return secmark, and it will actually give you *the* label that was used
for the access check :)
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 16:42 ` Darrel Goeddel
@ 2007-08-09 19:20 ` Joe Nall
2007-08-09 19:47 ` Darrel Goeddel
0 siblings, 1 reply; 57+ messages in thread
From: Joe Nall @ 2007-08-09 19:20 UTC (permalink / raw)
To: Darrel Goeddel
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai,
Eric Paris
On Aug 9, 2007, at 11:42 AM, Darrel Goeddel wrote:
> (why couldn't this have all waited a bit...)
Paul is addressing a real need. Like many things that really need
doing and take time, multiple people are simultaneously working on it.
I installed the netlabel patches and have tested them with good
results in MLS/permissive at a few levels (s0, s2:c0.c253,
s2:c0.c253). More testing to follow.
netlabelctl unlbl add interface:eth0 address:10.211.55.8/32
label:user_u:object_r:user_t:s2:c0.c253
/netlabelctl unlbl list
accept:on
interface:eth0,address:
192.168.20.253/32,label:"user_u:object_r:user_t:s0"
interface:eth0,address:
10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"
getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'
for a connection from 10.211.55.8.
This is a big improvement in linux labeled networking functionality.
joe
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 19:20 ` Joe Nall
@ 2007-08-09 19:47 ` Darrel Goeddel
2007-08-09 20:12 ` Joe Nall
2007-08-09 20:17 ` Paul Moore
0 siblings, 2 replies; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 19:47 UTC (permalink / raw)
To: Joe Nall
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai,
Eric Paris
Joe Nall wrote:
> On Aug 9, 2007, at 11:42 AM, Darrel Goeddel wrote:
>
>> (why couldn't this have all waited a bit...)
>
> Paul is addressing a real need. Like many things that really need
> doing and take time, multiple people are simultaneously working on it.
>
> I installed the netlabel patches and have tested them with good
> results in MLS/permissive at a few levels (s0, s2:c0.c253,
> s2:c0.c253). More testing to follow.
>
> netlabelctl unlbl add interface:eth0 address:10.211.55.8/32
> label:user_u:object_r:user_t:s2:c0.c253
>
> /netlabelctl unlbl list
> accept:on
> interface:eth0,address:
> 192.168.20.253/32,label:"user_u:object_r:user_t:s0"
> interface:eth0,address:
> 10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"
>
> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'
>
> for a connection from 10.211.55.8.
>
> This is a big improvement in linux labeled networking functionality.
As described in an earlier email, from my not-yet-full grasp on the patch,
this is a vulnerability waiting to happen in the event of using netlabel
fallback contexts alongside labeled ipsec. That is not an improvement.
If there were consistency checks between the various forms of external
labels, this would not be an issue and the functionality would indeed
be an improvement. Again, I do not have a test case, but Paul's response
to my query about getpeercon returning a netlabel modified version of
the xfrm label seemed to validate my concern.
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 19:47 ` Darrel Goeddel
@ 2007-08-09 20:12 ` Joe Nall
2007-08-09 21:15 ` Stephen Smalley
2007-08-09 21:18 ` Darrel Goeddel
2007-08-09 20:17 ` Paul Moore
1 sibling, 2 replies; 57+ messages in thread
From: Joe Nall @ 2007-08-09 20:12 UTC (permalink / raw)
To: Darrel Goeddel
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai,
Eric Paris
On Aug 9, 2007, at 2:47 PM, Darrel Goeddel wrote:
>> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I
>> A L'
>>
>> for a connection from 10.211.55.8.
>>
>> This is a big improvement in linux labeled networking functionality.
>
> As described in an earlier email, from my not-yet-full grasp on the
> patch,
> this is a vulnerability waiting to happen in the event of using
> netlabel
> fallback contexts alongside labeled ipsec.
Which would be a configuration error. There are lots of dangerous but
useful tools (rm, dd). I have ipsec and netlabel configured. I'll try
crossing the streams and see if we get total protonic reversal.
> That is not an improvement.
We will have to disagree. It is a big improvement in functionality.
It may not be the final approach, but it is the only one I can
evaluate today.
joe
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 20:12 ` Joe Nall
@ 2007-08-09 21:15 ` Stephen Smalley
2007-08-09 21:18 ` Darrel Goeddel
1 sibling, 0 replies; 57+ messages in thread
From: Stephen Smalley @ 2007-08-09 21:15 UTC (permalink / raw)
To: Joe Nall
Cc: Darrel Goeddel, James Morris, Paul Moore, SE Linux, kaigai,
Eric Paris
On Thu, 2007-08-09 at 15:12 -0500, Joe Nall wrote:
> On Aug 9, 2007, at 2:47 PM, Darrel Goeddel wrote:
> >> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I
> >> A L'
> >>
> >> for a connection from 10.211.55.8.
> >>
> >> This is a big improvement in linux labeled networking functionality.
> >
> > As described in an earlier email, from my not-yet-full grasp on the
> > patch,
> > this is a vulnerability waiting to happen in the event of using
> > netlabel
> > fallback contexts alongside labeled ipsec.
>
> Which would be a configuration error. There are lots of dangerous but
> useful tools (rm, dd). I have ipsec and netlabel configured. I'll try
> crossing the streams and see if we get total protonic reversal.
>
> > That is not an improvement.
>
> We will have to disagree. It is a big improvement in functionality.
> It may not be the final approach, but it is the only one I can
> evaluate today.
I think we all agree that it is important functionality to have, it is
just a matter of doing it in a way that works cleanly for all labeled
networking mechanisms (netlabel and labeled IPSEC) and ideally leverages
infrastructure that we already have (secmark).
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 20:12 ` Joe Nall
2007-08-09 21:15 ` Stephen Smalley
@ 2007-08-09 21:18 ` Darrel Goeddel
2007-08-09 22:48 ` Paul Moore
1 sibling, 1 reply; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 21:18 UTC (permalink / raw)
To: Joe Nall
Cc: James Morris, Stephen Smalley, Paul Moore, SE Linux, kaigai,
Eric Paris
Joe Nall wrote:
> On Aug 9, 2007, at 2:47 PM, Darrel Goeddel wrote:
>>> getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I
>>> A L'
>>>
>>> for a connection from 10.211.55.8.
>>>
>>> This is a big improvement in linux labeled networking functionality.
>> As described in an earlier email, from my not-yet-full grasp on the
>> patch,
>> this is a vulnerability waiting to happen in the event of using
>> netlabel
>> fallback contexts alongside labeled ipsec.
>
> Which would be a configuration error. There are lots of dangerous but
> useful tools (rm, dd). I have ipsec and netlabel configured. I'll try
> crossing the streams and see if we get total protonic reversal.
If netlabel and labeled ipsec are mutually exclusive, then the idea of
implementing the fallback contexts in netlabel is only helping one specific
use case and muddying the waters for a comprehensive solution in the future.
I think it is is a novel idea but not suitable for upstream inclusion on
those grounds. If there were no conflicts with other existing labeling
mechanisms, I'd be all for it.
It also seems to be internally defining and external label, which seems to
be against the rules ;)
>> That is not an improvement.
>
> We will have to disagree. It is a big improvement in functionality.
> It may not be the final approach, but it is the only one I can
> evaluate today.
Agreed. If the "fallback" context wouldn't actually replace a real peer
context supplied by the peer itself, this would be useful. I'm sure it
can be made to operate this way if this patch set would be deemed the
way-to-go in the end.
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 21:18 ` Darrel Goeddel
@ 2007-08-09 22:48 ` Paul Moore
0 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 22:48 UTC (permalink / raw)
To: Darrel Goeddel, Joe Nall, James Morris, Stephen Smalley
Cc: SE Linux, kaigai, Eric Paris
On Thursday, August 9 2007 5:18:28 pm Darrel Goeddel wrote:
> Agreed. If the "fallback" context wouldn't actually replace a real peer
> context supplied by the peer itself, this would be useful. I'm sure it
> can be made to operate this way if this patch set would be deemed the
> way-to-go in the end.
Darrel is right, I believe we can fix up the issues he presented today without
too much fuss, however, at this point it's not clear to me this patchset
would be accepted. I'm happy to keep working on these patches, but I suspect
it will get an explicit NACK from either James or Stephen; if one or both of
you could clarify this I would appreciate it.
For better or worse I'm leaving tommorrow, August 10th, on vacation and I
won't be back in front of a computer until the 20th. I realized it's a bit
of a "party-foul" to push a patch out for comments like this then disappear
for a week, but up until today no one really had much to say about this idea
so I wasn't quite expecting the discussion we had today ;)
That said, I'm sure you guys will keep talking about this (I hope you do
anyway), just don't think I'm ignoring you - I'll do that when I get back ;)
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 19:47 ` Darrel Goeddel
2007-08-09 20:12 ` Joe Nall
@ 2007-08-09 20:17 ` Paul Moore
1 sibling, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 20:17 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Joe Nall, James Morris, Stephen Smalley, SE Linux, kaigai,
Eric Paris
On Thursday, August 9 2007 3:47:43 pm Darrel Goeddel wrote:
> Joe Nall wrote:
> > On Aug 9, 2007, at 11:42 AM, Darrel Goeddel wrote:
> >> (why couldn't this have all waited a bit...)
> >
> > Paul is addressing a real need. Like many things that really need
> > doing and take time, multiple people are simultaneously working on it.
> >
> > I installed the netlabel patches and have tested them with good
> > results in MLS/permissive at a few levels (s0, s2:c0.c253,
> > s2:c0.c253). More testing to follow.
> >
> > netlabelctl unlbl add interface:eth0 address:10.211.55.8/32
> > label:user_u:object_r:user_t:s2:c0.c253
> >
> > /netlabelctl unlbl list
> > accept:on
> > interface:eth0,address:
> > 192.168.20.253/32,label:"user_u:object_r:user_t:s0"
> > interface:eth0,address:
> > 10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"
> >
> > getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'
> >
> > for a connection from 10.211.55.8.
> >
> > This is a big improvement in linux labeled networking functionality.
>
> As described in an earlier email, from my not-yet-full grasp on the patch,
> this is a vulnerability waiting to happen in the event of using netlabel
> fallback contexts alongside labeled ipsec. That is not an improvement.
> If there were consistency checks between the various forms of external
> labels, this would not be an issue and the functionality would indeed
> be an improvement. Again, I do not have a test case, but Paul's response
> to my query about getpeercon returning a netlabel modified version of
> the xfrm label seemed to validate my concern.
This is more of a general issue between NetLabel and labeled IPsec, it is not
specific to the fallback approach. For better or worse, this particular
problem is not new.
If the powers that be decide to redefine SECMARK and move forward with that
approach then we can fix the issue with the new design. If we want to fix it
in the status quo we could probably do something like this ... (simple patch
to describe a basic fix to the problem, not necessarily complete or even
compile tested).
Index: linux-2.6_extlbl-fix/security/selinux/hooks.c
===================================================================
--- linux-2.6_extlbl-fix.orig/security/selinux/hooks.c
+++ linux-2.6_extlbl-fix/security/selinux/hooks.c
@@ -3152,7 +3152,14 @@ static void selinux_skb_extlbl_sid(struc
SECINITSID_NETMSG : xfrm_sid),
&nlbl_sid) != 0)
nlbl_sid = SECSID_NULL;
- *sid = (nlbl_sid == SECSID_NULL ? xfrm_sid : nlbl_sid);
+
+ if (nlbl_sid != SECSID_NULL && xfrm_sid != SECSID_NULL &&
+ nlbl_sid != xfrm_sid)
+ *sid = SECSID_NULL;
+ else if (nlbl_sid != SECSID_NULL)
+ *sid = nlbl_sid;
+ else
+ *sid = xfrm_sid;
}
It's likely we would want/need a bit more, but I don't believe it's a
difficult problem to fix with the current approach. In fact, regardless of
what we chose to do in the future, unless we can do it probably is a good
idea to fix in in the current design as well.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:09 ` Darrel Goeddel
2007-08-09 14:24 ` James Morris
@ 2007-08-09 14:53 ` Paul Moore
2007-08-09 16:08 ` Darrel Goeddel
2007-08-09 22:55 ` Darrel Goeddel
1 sibling, 2 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 14:53 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Stephen Smalley, selinux, kaigai, joe, James Morris, Eric Paris
On Thursday 09 August 2007 10:09:14 am Darrel Goeddel wrote:
> Because of the position I am in (needing to find something workable for
> actual
> users), I have been trying to get my head aounrd the state of SELinux
> networking,
> the ideas that have been talked about in the past, and how we can prevent
> the
> SELinux networking infrastructure from resembling a Rube-Goldberg machine.
> I'll
> be presenting some of the problems I perceive along with some very high
> level
> ideas early next week.
Such a tease! ;)
I assume from other, previous discussions you are currently using the
secid-reconciliation patches?
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:53 ` Paul Moore
@ 2007-08-09 16:08 ` Darrel Goeddel
2007-08-09 22:55 ` Darrel Goeddel
1 sibling, 0 replies; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 16:08 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, kaigai, joe, James Morris, Eric Paris
Paul Moore wrote:
> On Thursday 09 August 2007 10:09:14 am Darrel Goeddel wrote:
>> Because of the position I am in (needing to find something workable for
>> actual
>> users), I have been trying to get my head around the state of SELinux
>> networking,
>> the ideas that have been talked about in the past, and how we can prevent
>> the
>> SELinux networking infrastructure from resembling a Rube-Goldberg
machine.
>> I'll
>> be presenting some of the problems I perceive along with some very high
>> level
>> ideas early next week.
>
> Such a tease! ;)
Sorry, I'm getting slow as I age, and I'm going out of town tomorrow.
> I assume from other, previous discussions you are currently using the
> secid-reconciliation patches?
Yes and no - we've evolved a bit from them. We implemented a completely
orthogonal peer context mechanism - basically the "reconciled" sid and we
have that in an *cough*expanded*cough* skb. We kept the idea of external
and internal labels (which, BTW, I find to be really unwieldy and confusing
in
practice - anyone else actually use this stuff?). We have a hodgepodge that
keeps the standard RHEL5 idea in place and adds loopback labeling and flow
control. It works but it is a bear to figure out and I wouldn't suggest it
for an upstream implementation. Our constraint (self-imposed) for this
was "meet our needs without modifying already-in-place controls". We need
to look at the big picture to get something sensible from the ground up
and not just tack more stuff on. Our current implementation is not the
desired end goal - the community needs to come up with that somehow.
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 14:53 ` Paul Moore
2007-08-09 16:08 ` Darrel Goeddel
@ 2007-08-09 22:55 ` Darrel Goeddel
2007-08-10 16:49 ` James Morris
1 sibling, 1 reply; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-09 22:55 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, selinux, kaigai, joe, James Morris, Eric Paris
Paul Moore wrote:
> On Thursday 09 August 2007 10:09:14 am Darrel Goeddel wrote:
>> Because of the position I am in (needing to find something workable for
>> actual
>> users), I have been trying to get my head aounrd the state of SELinux
>> networking,
>> the ideas that have been talked about in the past, and how we can prevent
>> the
>> SELinux networking infrastructure from resembling a Rube-Goldberg
machine.
>> I'll
>> be presenting some of the problems I perceive along with some very high
>> level
>> ideas early next week.
>
> Such a tease! ;)
Here's a general high-level idea. Remember that this is in no way a
proposal
(yet) because I'm not even sure if it makes sense. It is a very simple
idea,
but it should prove to be flexible enough to handle everything. I make no
claims as to its workability, or it implementability given the fact that we
should offer some kind of backwards compatibility. I think this would be
something that one might come up with if they were starting from scratch (I
seriously doubt that the current mechanisms would ever come out of an
intentional up-front design). It is just a vision of my perfect scenario
(perfect until I figure out that it doesn't do what I need it to do)...
Please try to look at this from a clean slate as well as a retrofit
point-of-view.
picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
(when commenting, please refrain from belittling my artistic skills)
The high level ideas are (I'll be using sid and context interchangeably,
but I think we can all figure that one out):
- The secmark (lowercase, denoting the secmark field in the skb) will
always contain the peer's context. The secmark will begin life as the
unlabeled sid - we don't know who we are dealing with yet. If the
SECMARK (uppercase denoting the SECMARK iptables module) facility find
a match for the skb, we will replace the secmark with the context
specified by the matching rule - this is the fallback label, our best
guess as to who we are dealing with. In the event of the peer supplying
context information (complete context via ipsec, mls level via cipso,
or type information via carrier pigeon), the peer supplied context
information will be evaluated and verified for some sort of consistency
if there is more than one source of information. If the context created
with consideration of all peer supplied info checks out, that will then
replace the current secmark value. That's it for secmark - we now have
the best idea of who the peer really is in there.
- OK, one more bit about what is in secmark. For locally generated
traffic, it is the domain of the process, err... socket. Still the
peer context, just from a real reliable source.
- The secmark, and nothing else, will be used for all flow control checks
as well as the access check at consumption (process reading from the
socket). This means that policy represents who we can talk to, not
what association we can use, or what socket we can recvfrom, or what
internal label we can read from. Yes, secmark does it all - yeah :)
- A new SECFILTER iptables module is in place to perform flow control
checks. Just as we have used the expressiveness (either fine grained
or coarse grained - your choice) of iptables to define fallback labels
for packets based on their attributes, we want to be able to define
access check based on those attributes. It is here where we can say
that only http_client_t can get to port 80 on this machine, or that
only a secret packet can leave the machine through the eth1 device.
The SECFILTER mechanism will be able to distinguish controls for
incoming, outgoing, and forwarded traffic. In the absence of a
matching "target context" from SECFILTER, the secmark will be checked
against the unlabeled context (no SECFILTER - no label).
- Since the secmark for locally generated traffic is the context of
the sender and that is preserved as the packet gets bounced back up
to the local peer, we have labeled localhost. We can even put flow
control checks on that to boot!
- getpeeron() will return the value of secmark. This will be the same
context that was actually used by the access check and it is the same
context that considered locally defined fallbacks as well as peer
supplied information.
so, I think these ideas would:
- provide flow control
- enable loopback labeling
- provide one label instead of three possibly conflicting labels for an
skb
- streamline, simplify, make sense of access checks regarding skbs
- simplify understanding of what the skb context is - the peer's context
- enable a more reliable, safe, and informative getpeercon result
I'm not sure that any of these ideas are particularly new, but I'm
hoping that this particular combination of previously presented ideas
makes a bit of sense. I'm sure that I will get tons of useful commentary
to incorporate, and I thank you in advance :) That's why I wanted to
toss something out there now.
I'm off for a weekend trip, so please don't feel that I am ignoring all
of the scathing criticisms that will be coming tomorrow... I'll ignore
all of that next week when I return ;)
We'll be working through some prototypes to make sure that the ideas
that we present are at least somewhat feasible - unlike the blue sky
idea presented here (although that'll get prototyped to see if it is
workable - I hope it is).
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 22:55 ` Darrel Goeddel
@ 2007-08-10 16:49 ` James Morris
2007-08-14 14:47 ` Darrel Goeddel
0 siblings, 1 reply; 57+ messages in thread
From: James Morris @ 2007-08-10 16:49 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
On Thu, 9 Aug 2007, Darrel Goeddel wrote:
> picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
> (when commenting, please refrain from belittling my artistic skills)
I think this looks good in terms of labeling via secmark, although it
hides external labeling.
> - A new SECFILTER iptables module is in place to perform flow control
> checks. Just as we have used the expressiveness (either fine grained
> or coarse grained - your choice) of iptables to define fallback labels
> for packets based on their attributes, we want to be able to define
> access check based on those attributes. It is here where we can say
> that only http_client_t can get to port 80 on this machine, or that
> only a secret packet can leave the machine through the eth1 device.
> The SECFILTER mechanism will be able to distinguish controls for
> incoming, outgoing, and forwarded traffic. In the absence of a
> matching "target context" from SECFILTER, the secmark will be checked
> against the unlabeled context (no SECFILTER - no label).
This seems problematic. The secmark model is currently based upon
iptables rules being used to classify and label traffic, with access
control performed within SELinux based upon those labels and permission
types. So, the access control decisions are performed via the AVC and
according to SELinux policy.
In the case of local labeling, the packet is labeled based upon the port
(and any other iptables selector), so you don't need to have a separate
mechanism i.e. the packet will only be labled as http_client_t if it's
leaving via port 80 and also part of a validated connection.
Not sure what the answer is for applying controls to externally labeled
packets. It seems like a special case, though, and that typically, the
network interface is the only thing you really want to check here. If so,
perhaps we implement a secmark (packet label) vs. netif check once
external labeling has been applied.
So, the packet control permissions using secmark would be something like:
socket layer : send, recv
network layer : flow_in, flow_forward, flow_out
link layer : netif_in, netif_out
I think this will make sense to users due to the layering, and separation
of labeling and access control.
The order of mediation is:
Inbound to local:
netif_in -> flow_in -> recv
Forward:
netif_in -> flow_forward -> netif_out
Outbound from local:
send -> flow_out -> netif_out
Now, labeling is not so simple :-)
We have local labeling via secmark, which needs to be applied first and
then potentially overridden.
Then we have two differnt forms of external labeling, with differing
mechanisms and policy constructs.
For general and non-legacy users, we need to be focused on IPsec labeling.
I'm not sure what the answer is for making it more usable at this stage,
although if we don't make significant improvements, people will never use
it. Any bright ideas? :-)
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-10 16:49 ` James Morris
@ 2007-08-14 14:47 ` Darrel Goeddel
2007-08-15 4:24 ` James Morris
0 siblings, 1 reply; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-14 14:47 UTC (permalink / raw)
To: James Morris
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
James Morris wrote:
> On Thu, 9 Aug 2007, Darrel Goeddel wrote:
>
>> picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
>> (when commenting, please refrain from belittling my artistic skills)
>
> I think this looks good in terms of labeling via secmark, although it
> hides external labeling.
The external labeling was left (rather intentionally at this point) as a
black box. The reason for this is that there can only be one label so just
wanted to show that the secmark field will be overidden with the
"peer provided" (external) label if it exists. That could either be an xfrm
label, a netlbl label, or an *agreement* of the two. In the case of CIPSO
over an labeled xfrm, I'd say that the xfrm context and the netlbl modified
context must be equal or the packet is dropped on the grounds that it is
invalid (can't be secret and top_secret all at once). Once the peer
information has been taken into account, the idea of "external labeling"
goes away because we are now just dealing with the one and only label.
>> - A new SECFILTER iptables module is in place to perform flow control
>> checks. Just as we have used the expressiveness (either fine grained
>> or coarse grained - your choice) of iptables to define fallback labels
>> for packets based on their attributes, we want to be able to define
>> access check based on those attributes. It is here where we can say
>> that only http_client_t can get to port 80 on this machine, or that
>> only a secret packet can leave the machine through the eth1 device.
>> The SECFILTER mechanism will be able to distinguish controls for
>> incoming, outgoing, and forwarded traffic. In the absence of a
>> matching "target context" from SECFILTER, the secmark will be checked
>> against the unlabeled context (no SECFILTER - no label).
>
> This seems problematic. The secmark model is currently based upon
> iptables rules being used to classify and label traffic, with access
> control performed within SELinux based upon those labels and permission
> types. So, the access control decisions are performed via the AVC and
> according to SELinux policy.
SECFILTER would be obtaining an access decision from the security server.
The subject of that access would be the secmark on the packet (peer domain)
and the object would be the context of the matching SECFILTER rule. So
SECMARK provides the fallback for the subject label in the absense of a
peer-provided label and SECFILTER provides the object label.
An important aspect that is that there needs to be a check against the
unlabeled context if the SECFILTER mechanism did not provide a match to
ensure that the security server was consulted for every packet. This
would catch the case where the modules was not active or the SECFILTER
ruleset was not able to match the traffic.
> In the case of local labeling, the packet is labeled based upon the port
> (and any other iptables selector), so you don't need to have a separate
> mechanism i.e. the packet will only be labled as http_client_t if it's
> leaving via port 80 and also part of a validated connection.
>
> Not sure what the answer is for applying controls to externally labeled
> packets.
There is no distinction here because the secmark is the only label, whether
or not the label came from a SECMARK rule like:
iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK \
--selctx system_u:object_r:http_client_t:s0
or from a labeled xfrm, it is treated the same.
Since the SECMARK facility is just providing the fallback labels, the
actual flow controls are provided by the SECFILTER rules. These rules
specify the "gates" that the skb is going to traverse. Let's say we want
to make eth0 an "internal" only network and eth1 and external network -
we would have SECFILTER rules like:
iptables -t filter -A INPUT -i eth0 -j SECFILTER \
--selctx system_u:object_r:internal_t:s0
iptables -t filter -A INPUT -i eth1 -j SECFILTER \
--selctx system_u:object_r:external_t:s0
iptables -t filter -A OUTPUT -o eth0 -j SECFILTER \
--selctx system_u:object_r:internal_t:s0
iptables -t filter -A OPTPUT -o eth1 -j SECFILTER \
--selctx system_u:object_r:external_t:s0
iptables -t filter -A FORWARD -i eth0 -o eth1 -j SECFILTER \
--selctx system_u:object_r:cross_the_line_t:s0
iptables -t filter -A FORWARD -i eth1 -o eth0 -j SECFILTER \
--selctx system_u:object_r:cross_the_line_t:s0
The flow control policy arbitration would be defined as:
allow http_client_t packet:internal_t { flow_in flow_out };
allow httpd_t packet:internal_t { flow_in flow_out };
Maybe we want to allow external access from an ssl connection. A
SECMARK rule like:
iptables -t mangle -A INPUT -p tcp --dport 443 -j SECMARK \
--selctx system_u:object_r:https_client_t:s0
and policy like:
allow https_client_t packet:external_t { flow_in flow_out };
allow httpd_t packet:external_t { flow_in flow_out };
take care of that. Note that httpd_t is the domain of the webserver
in the above examples.
> It seems like a special case, though, and that typically, the
> network interface is the only thing you really want to check here. If so,
> perhaps we implement a secmark (packet label) vs. netif check once
> external labeling has been applied.
>
> So, the packet control permissions using secmark would be something like:
>
> socket layer : send, recv
The recv check at the socket layer becomes socket (proxy for local process)
receiving information from the secmark (peer process). This process vs.
process style check didn't seem to have a natural fit with sending the
information because the peer isn't as well known as it could be in the
receive case. For this reason, send is actually absent in this idea right
now.
If there were a process vs. process check on send the peer process could
only
be identified through the SECMARK fallback labels.
> network layer : flow_in, flow_forward, flow_out
> link layer : netif_in, netif_out
The flexibility of the SECFILTER mechanism should make it adequate for
these two. My example above shows SECFILTER being used for the link layer
checks. The thought had crossed my mind to include another layer earlier,
but then I realized that I was adding another check that probably wasn't
necessary.
> I think this will make sense to users due to the layering, and separation
> of labeling and access control.
>
> The order of mediation is:
>
> Inbound to local:
>
> netif_in -> flow_in -> recv
>
> Forward:
>
> netif_in -> flow_forward -> netif_out
>
> Outbound from local:
>
> send -> flow_out -> netif_out
There's that darn send again... The flow_out check from SECFILTER is really
performing the duties of the current send operation. It would be providing
a way to say "can information from this process (with it's context conveyed
through the secmark on the skb) flow through this security gate?". It is
here that one could say only httpd_t could flow_out to port 80, just like
SECMARK currently allows. Note that this is a more granular approach to
constructing SECFILTER rules than I presented above.
The above layering makes perfect sense to me and I can live with that if it
is
deemed necessary. Do you think the extra check will help with usability?
Usually
I would think that an extra thing to think about would make it harder, but I
am
not sure in this case.
> Now, labeling is not so simple :-)
Maybe that answers my question ;)
> We have local labeling via secmark, which needs to be applied first and
> then potentially overridden.
Yep, this is our fallback in the absence of peer-provided information.
> Then we have two differnt forms of external labeling, with differing
> mechanisms and policy constructs.
>
> For general and non-legacy users, we need to be focused on IPsec labeling.
Yep, but they all convey the same information in this scheme - the label of
the peer process. So the label is treated the same way no matter where it
comes from (as I mentioned above, I think simultaneous use of netlbl and
labeled xfrm should require and agreement on context). IMHO, this
unification
of the label to one abstraction simplifies things greatly. Now we can
always
perform the same check - "Can process A (local) receive info from process B
(peer)?".
> I'm not sure what the answer is for making it more usable at this stage,
> although if we don't make significant improvements, people will never use
> it. Any bright ideas? :-)
Does anything I tried to clarify above shed a different light on things in
you eyes? I think the basic tenants are:
- secmark is always the label of the peer, and getpeercon() returns it
- a packet goes though "filter points", the packet is the subject and the
"filter point" is the object it must pass through (these filters happen
at input, output, and forwarding)
- a socket reading a packet must be able to listen to the peer that created
it - a slightly new meaning for current socket vs. secmark access check
This is a drastic simplification of the whole system. I think it is much
easier from a conceptual level and it allows more control that the previous
system. I'm just wondering what hidden problems there are with the
simplification?
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-14 14:47 ` Darrel Goeddel
@ 2007-08-15 4:24 ` James Morris
2007-08-15 22:35 ` Darrel Goeddel
0 siblings, 1 reply; 57+ messages in thread
From: James Morris @ 2007-08-15 4:24 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
On Tue, 14 Aug 2007, Darrel Goeddel wrote:
> The recv check at the socket layer becomes socket (proxy for local
> process)
> receiving information from the secmark (peer process). This process vs.
> process style check didn't seem to have a natural fit with sending the
> information because the peer isn't as well known as it could be in the
> receive case. For this reason, send is actually absent in this idea
> right now.
> If there were a process vs. process check on send the peer process could
> only
> be identified through the SECMARK fallback labels.
Perhaps I'm missing something, but the send check is necessary for e.g.
"can a httpd_server_t socket send an smtp_client_t packet" ?
What you're calling fallback labels will likely be the only labels a
normal user encounters.
> There's that darn send again... The flow_out check from SECFILTER is
> really performing the duties of the current send operation.
I think there's a slight misunderstanding here. I'm proposing not having
SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.
Discussion of security gates and similar I think will really confuse
people, as will the idea of labeling such abstract entities, which is
heading down a similar path to earlier proposals on this topic.
> - a packet goes though "filter points", the packet is the subject and the
> "filter point" is the object it must pass through (these filters happen
> at input, output, and forwarding)
What they really are is the boundary of network layer of the machine,
which is to say, the boundary of machine itself in terms of network
functionality. i.e. once a packet is accepted into the IP stack, it can
be forwarded, delivered etc.
So, allowing flow_in means "the packet can flow into this machine", and
similar for flow_forward and flow_out.
The socket recv/send checks are against the endpoint (at least, as
delegated by an authorized endpoint via the socket).
The netif_in and netif_out allow checking of the packet flowing across
specific physical interfaces.
I don't think we need to add any new abstractions here, and these should
be understandable by people who can configure networking.
> - a socket reading a packet must be able to listen to the peer that
> created it - a slightly new meaning for current socket vs. secmark
> access check
I'm not sure what this means.
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-15 4:24 ` James Morris
@ 2007-08-15 22:35 ` Darrel Goeddel
2007-08-16 15:04 ` James Morris
0 siblings, 1 reply; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-15 22:35 UTC (permalink / raw)
To: James Morris
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
James Morris wrote:
> On Tue, 14 Aug 2007, Darrel Goeddel wrote:
>
>> The recv check at the socket layer becomes socket (proxy for local
>> process)
>> receiving information from the secmark (peer process). This process vs.
>> process style check didn't seem to have a natural fit with sending the
>> information because the peer isn't as well known as it could be in the
>> receive case. For this reason, send is actually absent in this idea
>> right now.
>> If there were a process vs. process check on send the peer process could
>> only
>> be identified through the SECMARK fallback labels.
>
> Perhaps I'm missing something, but the send check is necessary for e.g.
> "can a httpd_server_t socket send an smtp_client_t packet" ?
The send check would be necessary for that particular type of check. In
the proposed scheme, that particular question would never arise. The
skb is merely an extension of the socket, much as the socket is an
extension of the process. The question is now "can httpd_server_t
flow_out of an smtp_t network entity?" I'm having trouble coming up with
nice terminology for that one. How's this for the question - "can an
httpd_server_t packet go to a destination with certain characteristics?"
> What you're calling fallback labels will likely be the only labels a
> normal user encounters.
That is correct. In the absence of labeled network (just about all cases),
the SECMARK facility will provide the label of the peer.
>> There's that darn send again... The flow_out check from SECFILTER is
>> really performing the duties of the current send operation.
>
> I think there's a slight misunderstanding here. I'm proposing not having
> SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.
That would provide flow control only at the interface level. That is
certainly better than the current lack of flow control ability, but it
does not offer the flexibility of the iptables mechanism. It also gives us
different controls over forwarded traffic. Instead of the ability of
the unique forward check that SECFILTER would provide, we are limited
to using the in and out netif checks. We can no longer say that sysadm_t
traffic can come into the machine, sysadm_t traffic can go out of the
machine, but sysadm_t traffic can not pass through the machine.
> Discussion of security gates and similar I think will really confuse
> people, as will the idea of labeling such abstract entities, which is
> heading down a similar path to earlier proposals on this topic.
I think a lot of the previous confusion came from some of the
following points:
- trying to use secmark as BOTH an implicit fallback context AND
a flow control point
- the transitions from secmark to xfrm to NetLabel, etc., that were
thrown in to allow domain->packet->domain
I'm avoiding those issues with these simple rules:
- SECMARK is used only for establishing a fallback context for the peer
- SECFILTER is used only for performing the flow control checks
- the packet always carries the peer's context, not a data context
>> - a packet goes though "filter points", the packet is the subject and the
>> "filter point" is the object it must pass through (these filters happen
>> at input, output, and forwarding)
>
> What they really are is the boundary of network layer of the machine,
> which is to say, the boundary of machine itself in terms of network
> functionality. i.e. once a packet is accepted into the IP stack, it can
> be forwarded, delivered etc.
>
> So, allowing flow_in means "the packet can flow into this machine", and
> similar for flow_forward and flow_out.
>
> The socket recv/send checks are against the endpoint (at least, as
> delegated by an authorized endpoint via the socket).
The recv check makes sense. The socket is getting a packet from peer
peer_domain_t:secret, can the socket read that in? The label of
peer_domain_t:secret came from the SECMARK mechanism which arrived at
that label based on the characteristics of the sender. The
peer_domain_t:secret could have just as easily been explicitly conveyed
by the sender.
Does it make sense to make that check for outgoing traffic? There is
no way to have peer-provided information about the receiver, you only
know where the info is going, not who will actually get it. Yes, I
understand that I double standard here because I somehow believe that
the src characteristics for incoming packets are more useful than the
dst characteristics for outgoing packets. I don't love outgoing
packets any less - I am giving the incoming more credibility because
there _can_ be real information about the context in that case.
Using SECMARK for the target of the outgoing access check means that we
are back to needing another place to store the "target" info in the skb,
or the SECMARK module will be performing the access check (via LSM to
the security server) :( This is the reason SECFILTER came about - to
separate the labeling mechanism from the enforcement mechanism. I
think the separation adds clarity.
SECFILTER really is doing the same job for outgoing traffic as the current
usage of SECMARK, the only difference is that the subject comes from the
skb (same as the socket for locally generated traffic) and the decision
is made in the SECFILTER module, not delayed (which needs storage) until
later.
I'll bang my head around here to see what kind of functionality would be
missing (as opposed to the SECMARK/SECFILTER combo) with what you are
suggesting. I'll try to come up with some diagrams for the different
methods that are being discussed to make sure we are on the same page.
Since you are going for "no SECFILTER", how are you envisioning the
network layer checks you described before being (flow_in, flow_forward,
flow_out) handled? Or are you saying the idea should go, not just the
SECFILTER way of doing it?
> The netif_in and netif_out allow checking of the packet flowing across
> specific physical interfaces.
>
> I don't think we need to add any new abstractions here, and these should
> be understandable by people who can configure networking.
>
>> - a socket reading a packet must be able to listen to the peer that
>> created it - a slightly new meaning for current socket vs. secmark
>> access check
>
> I'm not sure what this means.
The socket vs. secmark check conceptually means "can the local process
read this type of information" right now. By having the secmark field
always convey the context of the peer, the check takes on a slightly
different meaning - "can the local process read information written by
the peer process?".
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-15 22:35 ` Darrel Goeddel
@ 2007-08-16 15:04 ` James Morris
2007-08-24 16:31 ` Paul Moore
0 siblings, 1 reply; 57+ messages in thread
From: James Morris @ 2007-08-16 15:04 UTC (permalink / raw)
To: Darrel Goeddel
Cc: Paul Moore, Stephen Smalley, selinux, kaigai, joe, Eric Paris
On Wed, 15 Aug 2007, Darrel Goeddel wrote:
> >
> > Perhaps I'm missing something, but the send check is necessary for e.g.
> > "can a httpd_server_t socket send an smtp_client_t packet" ?
>
> The send check would be necessary for that particular type of check. In
> the proposed scheme, that particular question would never arise. The
> skb is merely an extension of the socket, much as the socket is an
> extension of the process. The question is now "can httpd_server_t
> flow_out of an smtp_t network entity?" I'm having trouble coming up with
> nice terminology for that one. How's this for the question - "can an
> httpd_server_t packet go to a destination with certain characteristics?"
I don't see the problem. The skb is labeled by SECMARK and optionally
external labeling, and then the check is applied.
There is no need for for new terminology or abstractions, it is simply
"Can socket_t send packet_t" ?
> > What you're calling fallback labels will likely be the only labels a
> > normal user encounters.
>
> That is correct. In the absence of labeled network (just about all cases),
> the SECMARK facility will provide the label of the peer.
Not really. It will be a label describing what we know about the packet,
which in the case of local labeling, is based only on local attributes
(e.g. destination port, derived from existing connection etc.).
Once external labeling is applied, what we know will become more specific,
and ultimately, could be the label of the peer.
> >> There's that darn send again... The flow_out check from SECFILTER is
> >> really performing the duties of the current send operation.
> >
> > I think there's a slight misunderstanding here. I'm proposing not having
> > SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.
>
> That would provide flow control only at the interface level. That is
> certainly better than the current lack of flow control ability, but it
> does not offer the flexibility of the iptables mechanism.
It's not needed here -- the flexibility is provided in the selection and
classification of packets. What you need here is the ability to control
which interfaces a packet can flow across, and this does not call for the
use of a generalized and separate mechanism.
> It also gives us
> different controls over forwarded traffic. Instead of the ability of
> the unique forward check that SECFILTER would provide, we are limited
> to using the in and out netif checks. We can no longer say that sysadm_t
> traffic can come into the machine, sysadm_t traffic can go out of the
> machine, but sysadm_t traffic can not pass through the machine.
The forward check will be performed via the flow_forward hook.
> > Discussion of security gates and similar I think will really confuse
> > people, as will the idea of labeling such abstract entities, which is
> > heading down a similar path to earlier proposals on this topic.
>
> I think a lot of the previous confusion came from some of the
> following points:
>
> - trying to use secmark as BOTH an implicit fallback context AND
> a flow control point
> - the transitions from secmark to xfrm to NetLabel, etc., that were
> thrown in to allow domain->packet->domain
>
> I'm avoiding those issues with these simple rules:
>
> - SECMARK is used only for establishing a fallback context for the peer
Not in the general case, only when external labeling is in use.
> - SECFILTER is used only for performing the flow control checks
Unnecessary and complicated. SELinux hooks can do this within the
existing framework.
> - the packet always carries the peer's context, not a data context
What is a "data context"?
The label always simply has the most specific current information about
the packet. It may be some default for all packets, it may be based upon
local attributes, or it may carry the label of the peer.
> >> - a packet goes though "filter points", the packet is the subject and
> >> the "filter point" is the object it must pass through (these
> >> filters happen
> >> at input, output, and forwarding)
> >
> > What they really are is the boundary of network layer of the machine,
> > which is to say, the boundary of machine itself in terms of network
> > functionality. i.e. once a packet is accepted into the IP stack, it can
> > be forwarded, delivered etc.
> >
> > So, allowing flow_in means "the packet can flow into this machine", and
> > similar for flow_forward and flow_out.
> >
> > The socket recv/send checks are against the endpoint (at least, as
> > delegated by an authorized endpoint via the socket).
>
> The recv check makes sense. The socket is getting a packet from peer
> peer_domain_t:secret, can the socket read that in? The label of
> peer_domain_t:secret came from the SECMARK mechanism which arrived at
> that label based on the characteristics of the sender. The
> peer_domain_t:secret could have just as easily been explicitly conveyed
> by the sender.
>
> Does it make sense to make that check for outgoing traffic? There is
> no way to have peer-provided information about the receiver, you only
> know where the info is going, not who will actually get it. Yes, I
> understand that I double standard here because I somehow believe that
> the src characteristics for incoming packets are more useful than the
> dst characteristics for outgoing packets. I don't love outgoing
> packets any less - I am giving the incoming more credibility because
> there _can_ be real information about the context in that case.
So, you trust the characteristics of a packet arriving from the network
more than those on locally generated packets?
Keep in mind that we are also able to leverage connection tracking, so the
vast majority of packet labeling via secmark will have been validated as
being part of an existing connection.
> Using SECMARK for the target of the outgoing access check means that we
> are back to needing another place to store the "target" info in the skb,
I need a concrete example. What target information? How is it used?
> SECFILTER really is doing the same job for outgoing traffic as the current
> usage of SECMARK, the only difference is that the subject comes from the
> skb (same as the socket for locally generated traffic) and the decision
> is made in the SECFILTER module, not delayed (which needs storage) until
> later.
I don't understand.
> I'll bang my head around here to see what kind of functionality would be
> missing (as opposed to the SECMARK/SECFILTER combo) with what you are
> suggesting. I'll try to come up with some diagrams for the different
> methods that are being discussed to make sure we are on the same page.
> Since you are going for "no SECFILTER", how are you envisioning the
> network layer checks you described before being (flow_in, flow_forward,
> flow_out) handled? Or are you saying the idea should go, not just the
> SECFILTER way of doing it?
Well, we need something for the forwarding case at least. Is it enough to
have just a flow_forward check which matches the packet label against
kernel_t ?
e.g. "Can this machine forward a packet labeled intranet_t" ?
>
> > The netif_in and netif_out allow checking of the packet flowing across
> > specific physical interfaces.
> >
> > I don't think we need to add any new abstractions here, and these should
> > be understandable by people who can configure networking.
> >
> >> - a socket reading a packet must be able to listen to the peer that
> >> created it - a slightly new meaning for current socket vs. secmark
> >> access check
> >
> > I'm not sure what this means.
>
> The socket vs. secmark check conceptually means "can the local process
> read this type of information" right now.
The secmark label can be anything at all, so it means whatever its labeled
with. e.g. someone could label all traffic passing over eth0 as "secret",
or "sysadm_t"
> By having the secmark field
> always convey the context of the peer, the check takes on a slightly
> different meaning - "can the local process read information written by
> the peer process?".
As mentioned, it carries the most specific currently available information
about the packet. What it means in terms of distributed information flow
is thus context-specific.
Without a specific field for e.g. peer_sid, which always only means the
peer, policy development & analysis will need to be "aware" of what the
label represents in a specific situation.
I think this is an acceptable trade-off, as the users of external labeling
where such concepts are also critical also tend to have access to policy
expertise and can tightly control the policy and deployment.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-16 15:04 ` James Morris
@ 2007-08-24 16:31 ` Paul Moore
2007-08-24 18:34 ` James Morris
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-24 16:31 UTC (permalink / raw)
To: selinux
Cc: James Morris, Darrel Goeddel, Stephen Smalley, kaigai, joe,
Eric Paris
For those of you who are still paying attention to this thread you may have
been wondering why it went quiet all of a sudden; well, the thread didn't go
quiet, it went off-list. Needless to say, we'd like to bring the discussion
back on-list so that others can participate, or at the very least get some
cheap entertainment on a Friday afternoon. The discussion was pretty lively
so it's not really practical to replay the entire off-list thread here but
I'll try to hit upon where we are currently at as well as some of the
highlights that brought us to this point.
If anyone who was a part of the discussion has anything to add to these notes,
feel free.
* Packet labels (one or two)
There was quite a bit of debate about the possibility of going from the two
packet labels we have currently, external and internal, to a single packet
label. In order to consolidate the two labels there were two approaches
considered: a form of "reconciliation" similar to what was discussed earlier
this year, and the elimination of internal labels so that only the external
label would be used. After much discussion it was deemed that the two
labels, as currently defined/used, are truly independent labels used for two
different purposes and that "reconciliation" was still a bad idea and should
not be pursued. Further, while SECMARK and internal labeling have been slow
to be adopted in the major distributions it still serves a useful purpose and
should not be eliminated. The end result was the majority, including Stephen
and James, voting to continue with the two packet labels as they currently
exist.
One thing that did arise during the discussion was the slow realization that
the names for the two packet labels are probably not as descriptive as they
should be and that has most likely led to a certain amount of confusion. In
an effort to help make the two different label types more clear it was
decided to start calling the external labels "peer labels" as the external
label always represents the label of the peer who originated the packet and
it's data. It was also decided to start calling the internal labels "secmark
labels", while the compat_net mechanism still exists it is deprecated in
favor of the SECMARK mechanism which is the only way to set/manipulate the
internal label.
As a reminder, below is a definition of the two types of labels.
Secmark, or internal, labels are essentially a means for integrating the
traditional firewall rules with SELinux mandatory access controls. The
secmark labels allow policy writers and security administrators to meet
security goals similar to the following:
"Only allow Apache to accept connections over tcp/80 from
192.168.0.0/24, restricting it to my local network and not
the Big-Bad-Internet."
-- or --
"Only allow a particular instance of Firefox to connect to
1.2.3.4 over tcp/443, restricting it to my online banking
site."
Peer, or external, labels, furnished by NetLabel or labeled IPsec/XFRM,
provide the domain/context/label of the process which generated the
packet/data. The external labels allow policy writers and security
administrators to meet security goals similar to the following:
"This instance of Apache serves sensitive financial data and
I only want specific clients/peers/domains to be able to access
the data from this Apache instance."
-- or --
"I want to ensure that users connecting to the login server over
a Secret connection run in a Secret domain."
* Splitting the SECMARK field
After it was agreed to continue using both the peer and secmark labels the
discussion turned to how best to propagate those labels with the packet. As
you probably know there is a 32 bit field already in the packet/sk_buff
structure which is currently used exclusively by the secmark label. Once
again, there were two approaches considered. The first was the continuation
of the status quo where the secmark label is determined by looking directly
at the secmark field in the sk_buff, "sk_buff.secmark", and the peer label is
determined through a function call with the sk_buff as an
argument, "peer_label(sk_buff)". The second idea was to divide the secmark
field in the sk_buff into two 16 bit sub-fields effectively shortening peer
and secmark SIDs to 16 bits.
While there is still no final agreement on the best way forward, there does
seem to be agreement that the split secmark field offers a good deal of
implementation convenience/cleanliness but it requires either a reduction in
the system's SID space from 32 bits to 16 bits (4.<mumble> billion unique
labels down to 65 thousand unique labels for all subjects/objects on the
system) or some sort of additional internal SID mapping mechanism which has
yet to be defined. Both of which have the potential for introducing
compatibility problems.
* Loopback/Localhost peer packet labeling
This has been a long standing requirement which at first glance seems like it
would be simple to achieve but in practice it has proven quiet difficult to
implement. Current solutions to the problem involve using either
NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to
only conveying the MLS sensitivity label over the wire and only then for IPv4
packets. Labeled IPsec can convey the full SELinux label/context of the peer
for both IPv4 and IPv6 but is difficult to configure and introduces
unnecessary overhead for packets that never leave the machine.
The solution for this problem is tightly coupled with the decision to
split/not-split the secmark field in the sk_buff structure. If the secmark
field were split then the peer label could be set directly in the packet to
the originating socket and then preserved across the loopback
pseudo-interface for use on the receiving/inbound side. However, this does
require splitting the secmark field and all that goes along with it (see
above). If the secmark field were not split then the solution is to continue
to develop the peer labeling mechanisms to support loopback labeling. Joy
Latten from IBM has been working on better support for IPsec over loopback
(although I'm not sure of it's current status) and I am steadily working
towards a more full featured NetLabel which would be able to convey a full
SELinux context over the wire/loopback.
* Packet flow control
Another long standing goal that has not seen much success over the years. The
two approaches currently being considered are: per-interface checks against
the peer label with the possibility of an additional forwarding hook/check if
needed for labeling purposes, as well as an iptables based filtering
mechanism which has already been discussed off and on on the public SELinux
and LSPP mailing lists (SECFILTER/SECPOINT). The idea behind the iptables
based filtering mechanism is that "filter points" could be defined using
iptables/netfilter which would provide very granular access control checks.
The big question that is currently being debated is how much granularity is
needed and how much makes sense?
* Fallback labels
The simple idea that started this whole discussion. The need for a usable
peer label fallback mechanism is understood by everyone but the granularity
with which peer fallback labels are assigned are still a source of debate.
The idea is wether the granularity proposed in this NetLabel patchset which
allows per-host/subnet granularity for each interface is enough, and if not
is a very granular iptables/netfilter peer label assignment of fallback
labels required? This topic did come up briefly some time ago on the public
mailing list between Joshua Brindle and myself and we agreed that the
granularity presented in this patchset is sufficient, however, not everyone
feels this way so we are still discussing the best solution.
As part of the peer fallback label discussion it became apparent to everyone
that better integration/cooperation between the NetLabel and XFRM labeling
mechanisms is needed. The strict separation worked well in the beginning but
as we start to develop a richer set of functionality the two labeling
mechanisms need to work better together to ensure the consistency of the
network access controls. If the approach put forward in this patch set is
agreed upon as the right way to solve the peer fallback problem I will be
modifying it to take into account XFRM labels so that the NetLabel provided
fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO
label on the packet. Further, work will be done to ensure that when both a
XFRM and NetLabel/CIPSO label are present on an incoming packet that the
labels are the same, otherwise the packet will be dropped/rejected.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 16:31 ` Paul Moore
@ 2007-08-24 18:34 ` James Morris
2007-08-24 19:02 ` Casey Schaufler
2007-08-28 14:03 ` Darrel Goeddel
2 siblings, 0 replies; 57+ messages in thread
From: James Morris @ 2007-08-24 18:34 UTC (permalink / raw)
To: Paul Moore
Cc: selinux, Darrel Goeddel, Stephen Smalley, kaigai, joe, Eric Paris
On Fri, 24 Aug 2007, Paul Moore wrote:
> implementation convenience/cleanliness but it requires either a reduction in
> the system's SID space from 32 bits to 16 bits (4.<mumble> billion unique
> labels down to 65 thousand unique labels for all subjects/objects on the
> system) or some sort of additional internal SID mapping mechanism which has
> yet to be defined.
To clarify, with a network SID mapper, it means that we are only limiting
the total number of SIDs being used over the wire at some time, not the
total number of SIDs on the system.
Decoupling network representation of SIDs is likely a good idea anyway,
for this and NFS.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 16:31 ` Paul Moore
2007-08-24 18:34 ` James Morris
@ 2007-08-24 19:02 ` Casey Schaufler
2007-08-24 19:49 ` Paul Moore
2007-08-24 20:29 ` Joshua Brindle
2007-08-28 14:03 ` Darrel Goeddel
2 siblings, 2 replies; 57+ messages in thread
From: Casey Schaufler @ 2007-08-24 19:02 UTC (permalink / raw)
To: Paul Moore, selinux
Cc: James Morris, Darrel Goeddel, Stephen Smalley, kaigai, joe,
Eric Paris
--- Paul Moore <paul.moore@hp.com> wrote:
> For those of you who are still paying attention to this thread you may have
> been wondering why it went quiet all of a sudden; well, the thread didn't go
> quiet, it went off-list.
Boo.
> ...
>
> * Packet labels (one or two)
>
> ... voting to continue with the two packet labels as they currently
> exist.
For SELinux this appears prudent. For those using other schemes
the difference may be less obvious, but I see you discuss that
more below.
> One thing that did arise during the discussion was the slow realization that
> the names for the two packet labels are probably not as descriptive as they
> should be and that has most likely led to a certain amount of confusion. In
> an effort to help make the two different label types more clear it was
> decided to start calling the external labels "peer labels" as the external
> label always represents the label of the peer who originated the packet and
> it's data. It was also decided to start calling the internal labels "secmark
>
> labels", while the compat_net mechanism still exists it is deprecated in
> favor of the SECMARK mechanism which is the only way to set/manipulate the
> internal label.
Hmm. In one case the name reflects the purpose (label of peer) and
in the other the name reflects the mechanism (label used in SECMARK).
I like the clarification of the former as it tells an LSM writer
what to use the label for, while I dislike the latter because it
does nothing to help me understand the intent of the mechanism.
> As a reminder, below is a definition of the two types of labels.
>
> Secmark, or internal, labels are essentially a means for integrating the
> traditional firewall rules with SELinux mandatory access controls.
Is it really intended that Secmark is an SELinux specific mechanism?
Yes, yes, I understand that SELinux is the only upstream LSM and all
that. If it is intended only as a component of SELinux going forward
regardless of alternative LSM availability maybe that should be more
explicit in the related documentation. I would personally be
disappointed if the mechanism were unavailable to other LSMs, but that
is of course your call.
> The
> secmark labels allow policy writers and security administrators to meet
> security goals similar to the following:
> "Only allow Apache to accept connections over tcp/80 from
> 192.168.0.0/24, restricting it to my local network and not
> the Big-Bad-Internet."
> -- or --
> "Only allow a particular instance of Firefox to connect to
> 1.2.3.4 over tcp/443, restricting it to my online banking
> site."
>
> Peer, or external, labels, furnished by NetLabel or labeled IPsec/XFRM,
> provide the domain/context/label of the process which generated the
> packet/data.
As I mentioned earlier, I like this definition because it describes
the intent of the facility and provides guidance to those who would
extend the facility or use it to other ends.
> The external labels allow policy writers and security
> administrators to meet security goals similar to the following:
> "This instance of Apache serves sensitive financial data and
> I only want specific clients/peers/domains to be able to access
> the data from this Apache instance."
> -- or --
> "I want to ensure that users connecting to the login server over
> a Secret connection run in a Secret domain."
>
> * Splitting the SECMARK field
>
> After it was agreed to continue using both the peer and secmark labels the
> discussion turned to how best to propagate those labels with the packet. As
> you probably know there is a 32 bit field already in the packet/sk_buff
> structure which is currently used exclusively by the secmark label. Once
> again, there were two approaches considered. The first was the continuation
> of the status quo where the secmark label is determined by looking directly
> at the secmark field in the sk_buff, "sk_buff.secmark", and the peer label is
>
> determined through a function call with the sk_buff as an
> argument, "peer_label(sk_buff)".
Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff),
or security_peer_label(sk_buff)?
> The second idea was to divide the secmark ... the potential for
> introducing compatibility problems.
Yup.
> * Loopback/Localhost peer packet labeling
>
> This has been a long standing requirement which at first glance seems like it
>
> would be simple to achieve but in practice it has proven quiet difficult to
> implement. Current solutions to the problem involve using either
> NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
> unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to
> only conveying the MLS sensitivity label over the wire and only then for IPv4
>
> packets. Labeled IPsec can convey the full SELinux label/context of the peer
>
> for both IPv4 and IPv6 but is difficult to configure and introduces
> unnecessary overhead for packets that never leave the machine.
In the early Smack development I experimented with a scheme that
was very like CIPSO with the exception that it carried the MAC
information directly. That would be a smack_t for me, but it
would do u32s just fine. I abandoned it in favor of CIPSO to
reduce the changes outside of the LSM, but it would be easy to
resurrect. It has the disadvantage that you have to be careful
to avoid going off the box since there's no RFC supporting it.
I seem to recall there is an "approved" scheme lurking in the
networking header files, but I never persued that.
> The solution for this problem is tightly coupled with the decision to
> split/not-split the secmark field in the sk_buff structure. If the secmark
> field were split then the peer label could be set directly in the packet to
> the originating socket and then preserved across the loopback
> pseudo-interface for use on the receiving/inbound side. However, this does
> require splitting the secmark field and all that goes along with it (see
> above). If the secmark field were not split then the solution is to continue
>
> to develop the peer labeling mechanisms to support loopback labeling. Joy
> Latten from IBM has been working on better support for IPsec over loopback
> (although I'm not sure of it's current status) and I am steadily working
> towards a more full featured NetLabel which would be able to convey a full
> SELinux context over the wire/loopback.
So how big is a "full" context?
> * Packet flow control
>
> ...
>
> * Fallback labels
>
> The simple idea that started this whole discussion. The need for a usable
> peer label fallback mechanism is understood by everyone but the granularity
> with which peer fallback labels are assigned are still a source of debate.
> The idea is wether the granularity proposed in this NetLabel patchset which
> allows per-host/subnet granularity for each interface is enough, and if not
> is a very granular iptables/netfilter peer label assignment of fallback
> labels required? This topic did come up briefly some time ago on the public
> mailing list between Joshua Brindle and myself and we agreed that the
> granularity presented in this patchset is sufficient, however, not everyone
> feels this way so we are still discussing the best solution.
>
> As part of the peer fallback label discussion it became apparent to everyone
> that better integration/cooperation between the NetLabel and XFRM labeling
> mechanisms is needed. The strict separation worked well in the beginning but
>
> as we start to develop a richer set of functionality the two labeling
> mechanisms need to work better together to ensure the consistency of the
> network access controls. If the approach put forward in this patch set is
> agreed upon as the right way to solve the peer fallback problem I will be
> modifying it to take into account XFRM labels so that the NetLabel provided
> fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO
>
> label on the packet. Further, work will be done to ensure that when both a
> XFRM and NetLabel/CIPSO label are present on an incoming packet that the
> labels are the same, otherwise the packet will be dropped/rejected.
It makes me uncomfortable to hear you say that XFRM is SELinux specific
and that it needs to be integrated with NetLabel, which currently isn't.
I know that Smack isn't upstream yet. Nonetheless, I would hate to see
underlying mechanisms that currently provide useful facilities become
SELinux specific.
Thank you.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:02 ` Casey Schaufler
@ 2007-08-24 19:49 ` Paul Moore
2007-08-24 20:17 ` James Morris
2007-08-24 20:42 ` Casey Schaufler
2007-08-24 20:29 ` Joshua Brindle
1 sibling, 2 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-24 19:49 UTC (permalink / raw)
To: casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
On Friday, August 24 2007 3:02:00 pm Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > For those of you who are still paying attention to this thread you may
> > have been wondering why it went quiet all of a sudden; well, the thread
> > didn't go quiet, it went off-list.
>
> Boo.
I know, I know ...
> > One thing that did arise during the discussion was the slow realization
> > that the names for the two packet labels are probably not as descriptive
> > as they should be and that has most likely led to a certain amount of
> > confusion. In an effort to help make the two different label types more
> > clear it was decided to start calling the external labels "peer labels"
> > as the external label always represents the label of the peer who
> > originated the packet and it's data. It was also decided to start
> > calling the internal labels "secmark labels", while the compat_net
> > mechanism still exists it is deprecated in favor of the SECMARK mechanism
> > which is the only way to set/manipulate the internal label.
>
> Hmm. In one case the name reflects the purpose (label of peer) and
> in the other the name reflects the mechanism (label used in SECMARK).
> I like the clarification of the former as it tells an LSM writer
> what to use the label for, while I dislike the latter because it
> does nothing to help me understand the intent of the mechanism.
Feel free to suggest something better, I don't think anyone was ever really in
love with the term "secmark label". I believe at one point Stephen
suggested "iptables label", does that sound any better?
> > As a reminder, below is a definition of the two types of labels.
> >
> > Secmark, or internal, labels are essentially a means for integrating the
> > traditional firewall rules with SELinux mandatory access controls.
>
> Is it really intended that Secmark is an SELinux specific mechanism?
I don't see why it _has_ to be a SELinux specific mechanism. I understand
that some of the netfilter code is SELinux specific (mostly the part dealing
with SELinux secctx/secid conversions) but you could either change that to
the more generic LSM secctx/secid conversion API or simply augment it for
SMACK (I even see some nice case statements already in place to make things
easy for you).
However, all of this assumes that the LSM has a functional
label-to-32bit-token mapping mechanism similar to what SELinux has with the
SID concept. I know, and understand why, you are not a big fan of this for
SMACK but secids/tokens are a reality in several parts of the kernel and I
don't expect that to change anytime soon. You don't have to implement a
label/token mapping mechanism I guess, but you won't be able to make use of
kernel subsystems which require it.
> Yes, yes, I understand that SELinux is the only upstream LSM and all
> that. If it is intended only as a component of SELinux going forward
> regardless of alternative LSM availability maybe that should be more
> explicit in the related documentation.
Documentation? Who has documentation?! ;)
You make a good point, one that became clear to me over the course of the
discussion is that we need better documentation about the SELinux/LSM network
access controls work in the kernel. Josh wrote up a nice blog entry a while
ago about how to make some of it work in userspace (no NetLabel instructions,
though ... tsk tsk <g>!) but we don't have anyting for kernel hack[er]s. One
of the things that made it on to my todo list (but I haven't shared this with
anyone until now) is a document/wiki-entry describing how things work in the
kernel, and I'll be sure to point out which things are SELinux specific
(which is pretty few, if any).
> I would personally be
> disappointed if the mechanism were unavailable to other LSMs, but that
> is of course your call.
As long as their is an LSM my opinion is that all mechanisms which live
outside the LSM and/or provide services to LSM modules should be agnostic of
any one particular LSM. However, this does not mean that the is must deal
only with binary/string/secctx labels; if it makes sense to deal strictly
with secid tokens then so be it.
> > * Splitting the SECMARK field
> >
> > After it was agreed to continue using both the peer and secmark labels
> > the discussion turned to how best to propagate those labels with the
> > packet. As you probably know there is a 32 bit field already in the
> > packet/sk_buff structure which is currently used exclusively by the
> > secmark label. Once again, there were two approaches considered. The
> > first was the continuation of the status quo where the secmark label is
> > determined by looking directly at the secmark field in the sk_buff,
> > "sk_buff.secmark", and the peer label is
> >
> > determined through a function call with the sk_buff as an
> > argument, "peer_label(sk_buff)".
>
> Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff),
> or security_peer_label(sk_buff)?
At this point I'm thinking this would be internal/specific to the LSM; SMACK
and other LSMs cand devise whatever internal mechanism they want. SMACK for
example only has one labeling mechanism that I can see so this is kind of a
moot point for you, just make use of the NetLabel API to get the security
attributes/label of a packet. For SELinux it's not quite so simple as both
NetLabel and XFRM can provide peer label information, in order to make it
easier I was suggesting providing a single wrapper function that would take
into account all peer labeling mechanisms and return the correct peer label.
> > * Loopback/Localhost peer packet labeling
> >
> > This has been a long standing requirement which at first glance seems
> > like it
> >
> > would be simple to achieve but in practice it has proven quiet difficult
> > to implement. Current solutions to the problem involve using either
> > NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
> > unfortunately both have drawbacks. NetLabel/CIPSO is currently limited
> > to only conveying the MLS sensitivity label over the wire and only then
> > for IPv4
> >
> > packets. Labeled IPsec can convey the full SELinux label/context of the
> > peer
> >
> > for both IPv4 and IPv6 but is difficult to configure and introduces
> > unnecessary overhead for packets that never leave the machine.
>
> In the early Smack development I experimented with a scheme that
> was very like CIPSO with the exception that it carried the MAC
> information directly.
I am thinking along the same lines for NetLabel/CIPSO, similar to the old
Selopt concept. I'm also considering adding some additional fields/info to
carry additional information that used to passed along via MaxSix/SAMP; more
on that when I get to that work item.
> That would be a smack_t for me, but it would do u32s just fine.
While having to deal only with secids would make life easier, it might be
possible to offer alternate option formats for different LSMs (as long as
they were in mainline).
> It has the disadvantage that you have to be careful
> to avoid going off the box since there's no RFC supporting it.
Yes, indeed. Although in the case of NetLabel/CIPSO we have the wonderful
(well, not so wonderful if your a router vendor) FIPS defined "freeform" tag
which would allow us to stuff whatever we want so long as it fits in the IP
header length limitations. That said, I'm currently tossing around ways to
leverage the ip_build_options() routine to provide destination specific
NetLabel labeling in conjunction with the existing per-domain labeling.
IPv6 is of course, a different story.
> I seem to recall there is an "approved" scheme lurking in the
> networking header files, but I never persued that.
I have absolutely no idea what you are talking about here.
> > The solution for this problem is tightly coupled with the decision to
> > split/not-split the secmark field in the sk_buff structure. If the
> > secmark field were split then the peer label could be set directly in the
> > packet to the originating socket and then preserved across the loopback
> > pseudo-interface for use on the receiving/inbound side. However, this
> > does require splitting the secmark field and all that goes along with it
> > (see above). If the secmark field were not split then the solution is to
> > continue
> >
> > to develop the peer labeling mechanisms to support loopback labeling.
> > Joy Latten from IBM has been working on better support for IPsec over
> > loopback (although I'm not sure of it's current status) and I am steadily
> > working towards a more full featured NetLabel which would be able to
> > convey a full SELinux context over the wire/loopback.
>
> So how big is a "full" context?
See my comments above. In the case of SELinux I would probably simply just
pass the SID directly over loopback for performance reasons.
> > * Fallback labels
> >
> > The simple idea that started this whole discussion. The need for a
> > usable peer label fallback mechanism is understood by everyone but the
> > granularity with which peer fallback labels are assigned are still a
> > source of debate. The idea is wether the granularity proposed in this
> > NetLabel patchset which allows per-host/subnet granularity for each
> > interface is enough, and if not is a very granular iptables/netfilter
> > peer label assignment of fallback labels required? This topic did come
> > up briefly some time ago on the public mailing list between Joshua
> > Brindle and myself and we agreed that the granularity presented in this
> > patchset is sufficient, however, not everyone feels this way so we are
> > still discussing the best solution.
> >
> > As part of the peer fallback label discussion it became apparent to
> > everyone that better integration/cooperation between the NetLabel and
> > XFRM labeling mechanisms is needed. The strict separation worked well in
> > the beginning but
> >
> > as we start to develop a richer set of functionality the two labeling
> > mechanisms need to work better together to ensure the consistency of the
> > network access controls. If the approach put forward in this patch set
> > is agreed upon as the right way to solve the peer fallback problem I will
> > be modifying it to take into account XFRM labels so that the NetLabel
> > provided fallback peer label will only be used when there is no XFRM or
> > NetLabel/CIPSO
> >
> > label on the packet. Further, work will be done to ensure that when both
> > a XFRM and NetLabel/CIPSO label are present on an incoming packet that
> > the labels are the same, otherwise the packet will be dropped/rejected.
>
> It makes me uncomfortable to hear you say that XFRM is SELinux specific
> and that it needs to be integrated with NetLabel, which currently isn't.
Relax, I plan on making the integration/cooperation within SELinux. I'm still
working on the patches (just started thinking/coding yesterday) but as it
stands the only real change to NetLabel will be the addition of label source
information in the netlbl_lsm_secattr struct, i.e. is this a CIPSO label, a
unlabeled/fallback label, etc.
> I know that Smack isn't upstream yet.
Slacker :)
> Nonetheless, I would hate to see
> underlying mechanisms that currently provide useful facilities become
> SELinux specific.
As long as the LSM is in place, so would I.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:49 ` Paul Moore
@ 2007-08-24 20:17 ` James Morris
2007-08-24 20:24 ` Paul Moore
2007-08-24 20:42 ` Casey Schaufler
1 sibling, 1 reply; 57+ messages in thread
From: James Morris @ 2007-08-24 20:17 UTC (permalink / raw)
To: Paul Moore
Cc: casey, selinux, Darrel Goeddel, Stephen Smalley, kaigai, joe,
Eric Paris
On Fri, 24 Aug 2007, Paul Moore wrote:
> Feel free to suggest something better, I don't think anyone was ever really in
> love with the term "secmark label". I believe at one point Stephen
> suggested "iptables label", does that sound any better?
I like packet label, because it's a label based on the attributes of the
packet.
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 20:17 ` James Morris
@ 2007-08-24 20:24 ` Paul Moore
2007-08-24 20:47 ` Joshua Brindle
0 siblings, 1 reply; 57+ messages in thread
From: Paul Moore @ 2007-08-24 20:24 UTC (permalink / raw)
To: James Morris
Cc: casey, selinux, Darrel Goeddel, Stephen Smalley, kaigai, joe,
Eric Paris
On Friday, August 24 2007 4:17:00 pm James Morris wrote:
> On Fri, 24 Aug 2007, Paul Moore wrote:
> > Feel free to suggest something better, I don't think anyone was ever
> > really in love with the term "secmark label". I believe at one point
> > Stephen suggested "iptables label", does that sound any better?
>
> I like packet label, because it's a label based on the attributes of the
> packet.
[Sorry, I forgot about this suggestion when replying]
I was always a little nervous that just the term "packet label" would get
confusing ... are we talking about the "peer" packet label or the "packet"
packet label ... but I see your point.
What do other people think? I know you've got an opinion Casey ...
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 20:24 ` Paul Moore
@ 2007-08-24 20:47 ` Joshua Brindle
0 siblings, 0 replies; 57+ messages in thread
From: Joshua Brindle @ 2007-08-24 20:47 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, casey, selinux, Darrel Goeddel, Stephen Smalley,
kaigai, joe, Eric Paris
Paul Moore wrote:
> On Friday, August 24 2007 4:17:00 pm James Morris wrote:
>
>> On Fri, 24 Aug 2007, Paul Moore wrote:
>>
>>> Feel free to suggest something better, I don't think anyone was ever
>>> really in love with the term "secmark label". I believe at one point
>>> Stephen suggested "iptables label", does that sound any better?
>>>
>> I like packet label, because it's a label based on the attributes of the
>> packet.
>>
>
> [Sorry, I forgot about this suggestion when replying]
>
> I was always a little nervous that just the term "packet label" would get
> confusing ... are we talking about the "peer" packet label or the "packet"
> packet label ... but I see your point.
>
>
I agree, packet is ambiguous, it could mean the label thats in the
packet in the CIPSO field. netfilter label or iptables label (I prefer
the former since that is the real mechanism that does it, iptables could
be replaced with a new userspace interface anytime...)
> What do other people think? I know you've got an opinion Casey ...
>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:49 ` Paul Moore
2007-08-24 20:17 ` James Morris
@ 2007-08-24 20:42 ` Casey Schaufler
2007-08-24 21:10 ` Paul Moore
1 sibling, 1 reply; 57+ messages in thread
From: Casey Schaufler @ 2007-08-24 20:42 UTC (permalink / raw)
To: Paul Moore, casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
--- Paul Moore <paul.moore@hp.com> wrote:
> > Hmm. In one case the name reflects the purpose (label of peer) and
> > in the other the name reflects the mechanism (label used in SECMARK).
> > I like the clarification of the former as it tells an LSM writer
> > what to use the label for, while I dislike the latter because it
> > does nothing to help me understand the intent of the mechanism.
>
> Feel free to suggest something better, I don't think anyone was ever really
> in
> love with the term "secmark label". I believe at one point Stephen
> suggested "iptables label", does that sound any better?
It does because it describes the intended use.
>
> > > As a reminder, below is a definition of the two types of labels.
> > >
> > > Secmark, or internal, labels are essentially a means for integrating the
> > > traditional firewall rules with SELinux mandatory access controls.
> >
> > Is it really intended that Secmark is an SELinux specific mechanism?
>
> I don't see why it _has_ to be a SELinux specific mechanism. I understand
> that some of the netfilter code is SELinux specific (mostly the part dealing
> with SELinux secctx/secid conversions) but you could either change that to
> the more generic LSM secctx/secid conversion API or simply augment it for
> SMACK (I even see some nice case statements already in place to make things
> easy for you).
I can see where the mechanism is intended for generality and
where there is strong SELinux influence. I always get nervous
when what looks like a general mechanism is described in terms
of a specific use to which it gets put.
> However, all of this assumes that the LSM has a functional
> label-to-32bit-token mapping mechanism similar to what SELinux has with the
> SID concept. I know, and understand why, you are not a big fan of this for
> SMACK but secids/tokens are a reality in several parts of the kernel and I
> don't expect that to change anytime soon. You don't have to implement a
> label/token mapping mechanism I guess, but you won't be able to make use of
> kernel subsystems which require it.
Having come to that realization myself while trying to deal with
the audit code (which would be easily repairable were it not for xfrm)
I've been working on accomodating this particularily.
> > Yes, yes, I understand that SELinux is the only upstream LSM and all
> > that. If it is intended only as a component of SELinux going forward
> > regardless of alternative LSM availability maybe that should be more
> > explicit in the related documentation.
>
> Documentation? Who has documentation?! ;)
>
> You make a good point, one that became clear to me over the course of the
> discussion is that we need better documentation about the SELinux/LSM network
>
> access controls work in the kernel. Josh wrote up a nice blog entry a while
> ago about how to make some of it work in userspace (no NetLabel instructions,
>
> though ... tsk tsk <g>!) but we don't have anyting for kernel hack[er]s. One
>
> of the things that made it on to my todo list (but I haven't shared this with
>
> anyone until now) is a document/wiki-entry describing how things work in the
> kernel, and I'll be sure to point out which things are SELinux specific
> (which is pretty few, if any).
I expect that the actual dependencies are isolated. Where they
exist it would be nice for them to be explicit.
> > I would personally be
> > disappointed if the mechanism were unavailable to other LSMs, but that
> > is of course your call.
>
> As long as their is an LSM my opinion is that all mechanisms which live
> outside the LSM and/or provide services to LSM modules should be agnostic of
> any one particular LSM. However, this does not mean that the is must deal
> only with binary/string/secctx labels; if it makes sense to deal strictly
> with secid tokens then so be it.
Maybe we can fix that in 3.0. That is, I'll accept it for now,
but someday we really ought to revisit the decision.
> > > * Splitting the SECMARK field
> > >
> > > After it was agreed to continue using both the peer and secmark labels
> > > the discussion turned to how best to propagate those labels with the
> > > packet. As you probably know there is a 32 bit field already in the
> > > packet/sk_buff structure which is currently used exclusively by the
> > > secmark label. Once again, there were two approaches considered. The
> > > first was the continuation of the status quo where the secmark label is
> > > determined by looking directly at the secmark field in the sk_buff,
> > > "sk_buff.secmark", and the peer label is
> > >
> > > determined through a function call with the sk_buff as an
> > > argument, "peer_label(sk_buff)".
> >
> > Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff),
> > or security_peer_label(sk_buff)?
>
> At this point I'm thinking this would be internal/specific to the LSM; SMACK
> and other LSMs cand devise whatever internal mechanism they want. SMACK for
> example only has one labeling mechanism that I can see so this is kind of a
> moot point for you, just make use of the NetLabel API to get the security
> attributes/label of a packet. For SELinux it's not quite so simple as both
> NetLabel and XFRM can provide peer label information, in order to make it
> easier I was suggesting providing a single wrapper function that would take
> into account all peer labeling mechanisms and return the correct peer label.
Sound.
> > > * Loopback/Localhost peer packet labeling
> > >
> > > This has been a long standing requirement which at first glance seems
> > > like it
> > >
> > > would be simple to achieve but in practice it has proven quiet difficult
> > > to implement. Current solutions to the problem involve using either
> > > NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
> > > unfortunately both have drawbacks. NetLabel/CIPSO is currently limited
> > > to only conveying the MLS sensitivity label over the wire and only then
> > > for IPv4
> > >
> > > packets. Labeled IPsec can convey the full SELinux label/context of the
> > > peer
> > >
> > > for both IPv4 and IPv6 but is difficult to configure and introduces
> > > unnecessary overhead for packets that never leave the machine.
> >
> > In the early Smack development I experimented with a scheme that
> > was very like CIPSO with the exception that it carried the MAC
> > information directly.
>
> I am thinking along the same lines for NetLabel/CIPSO, similar to the old
> Selopt concept. I'm also considering adding some additional fields/info to
> carry additional information that used to passed along via MaxSix/SAMP; more
> on that when I get to that work item.
>
> > That would be a smack_t for me, but it would do u32s just fine.
>
> While having to deal only with secids would make life easier, it might be
> possible to offer alternate option formats for different LSMs (as long as
> they were in mainline).
Well, you could define the interface to take a pointer and length,
thereby leaving it up to the LSM. Heck, SELinux could use it to
pass two sids instead of one that way.
> > It has the disadvantage that you have to be careful
> > to avoid going off the box since there's no RFC supporting it.
>
> Yes, indeed. Although in the case of NetLabel/CIPSO we have the wonderful
> (well, not so wonderful if your a router vendor) FIPS defined "freeform" tag
> which would allow us to stuff whatever we want so long as it fits in the IP
> header length limitations. That said, I'm currently tossing around ways to
> leverage the ip_build_options() routine to provide destination specific
> NetLabel labeling in conjunction with the existing per-domain labeling.
>
> IPv6 is of course, a different story.
Indeed.
> > I seem to recall there is an "approved" scheme lurking in the
> > networking header files, but I never persued that.
>
> I have absolutely no idea what you are talking about here.
It might even have been selopt.
> > > The solution for this problem is tightly coupled with the decision to
> > > split/not-split the secmark field in the sk_buff structure. If the
> > > secmark field were split then the peer label could be set directly in the
> > > packet to the originating socket and then preserved across the loopback
> > > pseudo-interface for use on the receiving/inbound side. However, this
> > > does require splitting the secmark field and all that goes along with it
> > > (see above). If the secmark field were not split then the solution is to
> > > continue
> > >
> > > to develop the peer labeling mechanisms to support loopback labeling.
> > > Joy Latten from IBM has been working on better support for IPsec over
> > > loopback (although I'm not sure of it's current status) and I am steadily
> > > working towards a more full featured NetLabel which would be able to
> > > convey a full SELinux context over the wire/loopback.
> >
> > So how big is a "full" context?
>
> See my comments above. In the case of SELinux I would probably simply just
> pass the SID directly over loopback for performance reasons.
Yup.
>
> > > * Fallback labels
> > >
> > > ...
> > >
> > > label on the packet. Further, work will be done to ensure that when both
> > > a XFRM and NetLabel/CIPSO label are present on an incoming packet that
> > > the labels are the same, otherwise the packet will be dropped/rejected.
> >
> > It makes me uncomfortable to hear you say that XFRM is SELinux specific
> > and that it needs to be integrated with NetLabel, which currently isn't.
>
> Relax, I plan on making the integration/cooperation within SELinux. I'm
> still
> working on the patches (just started thinking/coding yesterday) but as it
> stands the only real change to NetLabel will be the addition of label source
> information in the netlbl_lsm_secattr struct, i.e. is this a CIPSO label, a
> unlabeled/fallback label, etc.
Ok. I've relaxed.
> > I know that Smack isn't upstream yet.
>
> Slacker :)
Sometimes the Rock Star Lifestyle gets in the way.
> > Nonetheless, I would hate to see
> > underlying mechanisms that currently provide useful facilities become
> > SELinux specific.
>
> As long as the LSM is in place, so would I.
Carefully worded.
Thank you.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 20:42 ` Casey Schaufler
@ 2007-08-24 21:10 ` Paul Moore
2007-08-24 21:37 ` Casey Schaufler
0 siblings, 1 reply; 57+ messages in thread
From: Paul Moore @ 2007-08-24 21:10 UTC (permalink / raw)
To: casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
On Friday, August 24 2007 4:42:16 pm Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > > Hmm. In one case the name reflects the purpose (label of peer) and
> > > in the other the name reflects the mechanism (label used in SECMARK).
> > > I like the clarification of the former as it tells an LSM writer
> > > what to use the label for, while I dislike the latter because it
> > > does nothing to help me understand the intent of the mechanism.
> >
> > Feel free to suggest something better, I don't think anyone was ever
> > really in
> > love with the term "secmark label". I believe at one point Stephen
> > suggested "iptables label", does that sound any better?
>
> It does because it describes the intended use.
Actually, after reading Josh's mail I'm now thinking "netfilter label" is
probably a better choice. After all, the bikeshed will need to be repainted
in a few years ... ;)
> > > > As a reminder, below is a definition of the two types of labels.
> > > >
> > > > Secmark, or internal, labels are essentially a means for integrating
> > > > the traditional firewall rules with SELinux mandatory access
> > > > controls.
> > >
> > > Is it really intended that Secmark is an SELinux specific mechanism?
> >
> > I don't see why it _has_ to be a SELinux specific mechanism. I
> > understand that some of the netfilter code is SELinux specific (mostly
> > the part dealing with SELinux secctx/secid conversions) but you could
> > either change that to the more generic LSM secctx/secid conversion API or
> > simply augment it for SMACK (I even see some nice case statements already
> > in place to make things easy for you).
>
> I can see where the mechanism is intended for generality and
> where there is strong SELinux influence. I always get nervous
> when what looks like a general mechanism is described in terms
> of a specific use to which it gets put.
Then channel some of that nervous energy into some patches :) Really, I think
you could probably "fix" some of this without affecting the user visible
portion of it ... but then again I haven't thought about it for that long.
> > > I would personally be
> > > disappointed if the mechanism were unavailable to other LSMs, but that
> > > is of course your call.
> >
> > As long as their is an LSM my opinion is that all mechanisms which live
> > outside the LSM and/or provide services to LSM modules should be agnostic
> > of any one particular LSM. However, this does not mean that the is must
> > deal only with binary/string/secctx labels; if it makes sense to deal
> > strictly with secid tokens then so be it.
>
> Maybe we can fix that in 3.0. That is, I'll accept it for now,
> but someday we really ought to revisit the decision.
Sure, in a perfect world we would have void pointers everywhere, with a well
defined set of lifecycle management hooks that would enable us to do whatever
we wanted in terms of labeling objects on the system. It's a nice idea,
scratch that, a truly awesome idea, but I just don't see that happening in
the near future.
> > > > * Loopback/Localhost peer packet labeling
> > > >
> > > > This has been a long standing requirement which at first glance seems
> > > > like it
> > > >
> > > > would be simple to achieve but in practice it has proven quiet
> > > > difficult to implement. Current solutions to the problem involve
> > > > using either NetLabel/CIPSO or labeled IPsec over loopback to provide
> > > > peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is
> > > > currently limited to only conveying the MLS sensitivity label over
> > > > the wire and only then for IPv4
> > > >
> > > > packets. Labeled IPsec can convey the full SELinux label/context of
> > > > the peer
> > > >
> > > > for both IPv4 and IPv6 but is difficult to configure and introduces
> > > > unnecessary overhead for packets that never leave the machine.
> > >
> > > In the early Smack development I experimented with a scheme that
> > > was very like CIPSO with the exception that it carried the MAC
> > > information directly.
> >
> > I am thinking along the same lines for NetLabel/CIPSO, similar to the old
> > Selopt concept. I'm also considering adding some additional fields/info
> > to carry additional information that used to passed along via
> > MaxSix/SAMP; more on that when I get to that work item.
> >
> > > That would be a smack_t for me, but it would do u32s just fine.
> >
> > While having to deal only with secids would make life easier, it might be
> > possible to offer alternate option formats for different LSMs (as long as
> > they were in mainline).
>
> Well, you could define the interface to take a pointer and length,
> thereby leaving it up to the LSM.
Yes, that is one of the things I'm considering but one of the drawbacks to
this approach is that it makes commonality between LSMs very hard.
We can talk more about the exact functionality/API later if you would like,
right now I think we should stick to the topics in the original email so we
don't get stuck in a rathole. My plan is to start looking into this after
the fallback label issue is resolved.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 21:10 ` Paul Moore
@ 2007-08-24 21:37 ` Casey Schaufler
0 siblings, 0 replies; 57+ messages in thread
From: Casey Schaufler @ 2007-08-24 21:37 UTC (permalink / raw)
To: Paul Moore, casey
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
--- Paul Moore <paul.moore@hp.com> wrote:
> On Friday, August 24 2007 4:42:16 pm Casey Schaufler wrote:
> > --- Paul Moore <paul.moore@hp.com> wrote:
> > > > Hmm. In one case the name reflects the purpose (label of peer) and
> > > > in the other the name reflects the mechanism (label used in SECMARK).
> > > > I like the clarification of the former as it tells an LSM writer
> > > > what to use the label for, while I dislike the latter because it
> > > > does nothing to help me understand the intent of the mechanism.
> > >
> > > Feel free to suggest something better, I don't think anyone was ever
> > > really in
> > > love with the term "secmark label". I believe at one point Stephen
> > > suggested "iptables label", does that sound any better?
> >
> > It does because it describes the intended use.
>
> Actually, after reading Josh's mail I'm now thinking "netfilter label" is
> probably a better choice.
I also found his reasoning sound. "netfilter label" has my approval.
> After all, the bikeshed will need to be repainted
> in a few years ... ;)
>
> > > > > As a reminder, below is a definition of the two types of labels.
> > > > >
> > > > > Secmark, or internal, labels are essentially a means for integrating
> > > > > the traditional firewall rules with SELinux mandatory access
> > > > > controls.
> > > >
> > > > Is it really intended that Secmark is an SELinux specific mechanism?
> > >
> > > I don't see why it _has_ to be a SELinux specific mechanism. I
> > > understand that some of the netfilter code is SELinux specific (mostly
> > > the part dealing with SELinux secctx/secid conversions) but you could
> > > either change that to the more generic LSM secctx/secid conversion API or
> > > simply augment it for SMACK (I even see some nice case statements already
> > > in place to make things easy for you).
> >
> > I can see where the mechanism is intended for generality and
> > where there is strong SELinux influence. I always get nervous
> > when what looks like a general mechanism is described in terms
> > of a specific use to which it gets put.
>
> Then channel some of that nervous energy into some patches :) Really, I
> think
> you could probably "fix" some of this without affecting the user visible
> portion of it ... but then again I haven't thought about it for that long.
Yeah, yeah. It's behind audit on the list. "soon".
> > > > I would personally be
> > > > disappointed if the mechanism were unavailable to other LSMs, but that
> > > > is of course your call.
> > >
> > > As long as their is an LSM my opinion is that all mechanisms which live
> > > outside the LSM and/or provide services to LSM modules should be agnostic
> > > of any one particular LSM. However, this does not mean that the is must
> > > deal only with binary/string/secctx labels; if it makes sense to deal
> > > strictly with secid tokens then so be it.
> >
> > Maybe we can fix that in 3.0. That is, I'll accept it for now,
> > but someday we really ought to revisit the decision.
>
> Sure, in a perfect world we would have void pointers everywhere, with a well
> defined set of lifecycle management hooks that would enable us to do whatever
>
> we wanted in terms of labeling objects on the system. It's a nice idea,
> scratch that, a truly awesome idea, but I just don't see that happening in
> the near future.
I had a go at it, and there are only a couple gnarly places, but they
are unpleasant enough to I'm deferring it for the time being.
> > > > > * Loopback/Localhost peer packet labeling
> > > > >
> > > > > This has been a long standing requirement which at first glance seems
> > > > > like it
> > > > >
> > > > > would be simple to achieve but in practice it has proven quiet
> > > > > difficult to implement. Current solutions to the problem involve
> > > > > using either NetLabel/CIPSO or labeled IPsec over loopback to provide
> > > > > peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is
> > > > > currently limited to only conveying the MLS sensitivity label over
> > > > > the wire and only then for IPv4
> > > > >
> > > > > packets. Labeled IPsec can convey the full SELinux label/context of
> > > > > the peer
> > > > >
> > > > > for both IPv4 and IPv6 but is difficult to configure and introduces
> > > > > unnecessary overhead for packets that never leave the machine.
> > > >
> > > > In the early Smack development I experimented with a scheme that
> > > > was very like CIPSO with the exception that it carried the MAC
> > > > information directly.
> > >
> > > I am thinking along the same lines for NetLabel/CIPSO, similar to the old
> > > Selopt concept. I'm also considering adding some additional fields/info
> > > to carry additional information that used to passed along via
> > > MaxSix/SAMP; more on that when I get to that work item.
> > >
> > > > That would be a smack_t for me, but it would do u32s just fine.
> > >
> > > While having to deal only with secids would make life easier, it might be
> > > possible to offer alternate option formats for different LSMs (as long as
> > > they were in mainline).
> >
> > Well, you could define the interface to take a pointer and length,
> > thereby leaving it up to the LSM.
>
> Yes, that is one of the things I'm considering but one of the drawbacks to
> this approach is that it makes commonality between LSMs very hard.
>
> We can talk more about the exact functionality/API later if you would like,
> right now I think we should stick to the topics in the original email so we
> don't get stuck in a rathole. My plan is to start looking into this after
> the fallback label issue is resolved.
OK by me. Lots to do.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 19:02 ` Casey Schaufler
2007-08-24 19:49 ` Paul Moore
@ 2007-08-24 20:29 ` Joshua Brindle
1 sibling, 0 replies; 57+ messages in thread
From: Joshua Brindle @ 2007-08-24 20:29 UTC (permalink / raw)
To: casey
Cc: Paul Moore, selinux, James Morris, Darrel Goeddel,
Stephen Smalley, kaigai, joe, Eric Paris
Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
>
>> as we start to develop a richer set of functionality the two labeling
>> mechanisms need to work better together to ensure the consistency of the
>> network access controls. If the approach put forward in this patch set is
>> agreed upon as the right way to solve the peer fallback problem I will be
>> modifying it to take into account XFRM labels so that the NetLabel provided
>> fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO
>>
>> label on the packet. Further, work will be done to ensure that when both a
>> XFRM and NetLabel/CIPSO label are present on an incoming packet that the
>> labels are the same, otherwise the packet will be dropped/rejected.
>>
>
> It makes me uncomfortable to hear you say that XFRM is SELinux specific
> and that it needs to be integrated with NetLabel, which currently isn't.
> I know that Smack isn't upstream yet. Nonetheless, I would hate to see
> underlying mechanisms that currently provide useful facilities become
> SELinux specific.
>
Joy will know better but I don't think there is anything really SELinux
specific about XRFM. As far as the racoon support goes it just
serializes and sends over a string context, algorithm and DOI. The LSM
would responsible for verifying the context when it is set. One thing
you'd have to figure out as an LSM writer is how to reconcile multiple
incoming labels, much like we are trying to do right now. There are
already function pointers in the security_ops struct for managing xfrm
security data, it shouldn't be any problem for you to use them.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-24 16:31 ` Paul Moore
2007-08-24 18:34 ` James Morris
2007-08-24 19:02 ` Casey Schaufler
@ 2007-08-28 14:03 ` Darrel Goeddel
2007-08-28 15:16 ` Paul Moore
2 siblings, 1 reply; 57+ messages in thread
From: Darrel Goeddel @ 2007-08-28 14:03 UTC (permalink / raw)
To: Paul Moore
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
Paul Moore wrote:
<snip>
> * Loopback/Localhost peer packet labeling
>
> This has been a long standing requirement which at first glance seems like it
> would be simple to achieve but in practice it has proven quiet difficult to
> implement. Current solutions to the problem involve using either
> NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels,
> unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to
> only conveying the MLS sensitivity label over the wire and only then for IPv4
> packets. Labeled IPsec can convey the full SELinux label/context of the peer
> for both IPv4 and IPv6 but is difficult to configure and introduces
> unnecessary overhead for packets that never leave the machine.
>
> The solution for this problem is tightly coupled with the decision to
> split/not-split the secmark field in the sk_buff structure. If the secmark
> field were split then the peer label could be set directly in the packet to
> the originating socket and then preserved across the loopback
> pseudo-interface for use on the receiving/inbound side. However, this does
> require splitting the secmark field and all that goes along with it (see
> above). If the secmark field were not split then the solution is to continue
> to develop the peer labeling mechanisms to support loopback labeling. Joy
> Latten from IBM has been working on better support for IPsec over loopback
> (although I'm not sure of it's current status) and I am steadily working
> towards a more full featured NetLabel which would be able to convey a full
> SELinux context over the wire/loopback.
I just want to note that there are a few associated changes that should
go along with this. Once we have the concept of the sender's context in
in/associated with (I prefer in :)) the skb, we should use that when
applying on-the-wire labels. For the case fo locally generated packets,
this end up doing the same thing since the socket's label is in the skb
as the peer label. The real difference in behavior is the added
functionality of putting labels on the wire for forwarded packets (if
prescribed by the on-the-wire policy). For instance, a packet which
receives a fallback label of SECRET (because it came in a interface we
treat as SECRET) would be given the opportunity to exit a different
interface with that SECRET label on-the-wire. This gives us the ability
to "consolidate" single level networks into a single network that uses
explicit labeling. Should work nicely for cipso and labeled ipsec This
is something we currently employ with a patched kernel.
--
Darrel
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-28 14:03 ` Darrel Goeddel
@ 2007-08-28 15:16 ` Paul Moore
0 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-28 15:16 UTC (permalink / raw)
To: Darrel Goeddel
Cc: selinux, James Morris, Darrel Goeddel, Stephen Smalley, kaigai,
joe, Eric Paris
On Tuesday, August 28 2007 10:03:01 am Darrel Goeddel wrote:
> Paul Moore wrote:
>
> <snip>
>
> > * Loopback/Localhost peer packet labeling
> >
> > This has been a long standing requirement which at first glance seems
> > like it would be simple to achieve but in practice it has proven quiet
> > difficult to implement. Current solutions to the problem involve using
> > either NetLabel/CIPSO or labeled IPsec over loopback to provide peer
> > labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently
> > limited to only conveying the MLS sensitivity label over the wire and
> > only then for IPv4 packets. Labeled IPsec can convey the full SELinux
> > label/context of the peer for both IPv4 and IPv6 but is difficult to
> > configure and introduces unnecessary overhead for packets that never
> > leave the machine.
> >
> > The solution for this problem is tightly coupled with the decision to
> > split/not-split the secmark field in the sk_buff structure. If the
> > secmark field were split then the peer label could be set directly in the
> > packet to the originating socket and then preserved across the loopback
> > pseudo-interface for use on the receiving/inbound side. However, this
> > does require splitting the secmark field and all that goes along with it
> > (see above). If the secmark field were not split then the solution is to
> > continue to develop the peer labeling mechanisms to support loopback
> > labeling. Joy Latten from IBM has been working on better support for
> > IPsec over loopback (although I'm not sure of it's current status) and I
> > am steadily working towards a more full featured NetLabel which would be
> > able to convey a full SELinux context over the wire/loopback.
>
> I just want to note that there are a few associated changes that should
> go along with this. Once we have the concept of the sender's context in
> in/associated with (I prefer in :)) the skb, we should use that when
> applying on-the-wire labels. For the case fo locally generated packets,
> this end up doing the same thing since the socket's label is in the skb
> as the peer label. The real difference in behavior is the added
> functionality of putting labels on the wire for forwarded packets (if
> prescribed by the on-the-wire policy). For instance, a packet which
> receives a fallback label of SECRET (because it came in a interface we
> treat as SECRET) would be given the opportunity to exit a different
> interface with that SECRET label on-the-wire. This gives us the ability
> to "consolidate" single level networks into a single network that uses
> explicit labeling. Should work nicely for cipso and labeled ipsec This
> is something we currently employ with a patched kernel.
Yes. For locally generated packets the peer label of the packet is the label
of the socket which generated the packet, for forwarded packets the peer
label is the peer label that was associated with the packet when it arrived
at the system. On-the-wire labeling should always be based on the peer label
of the packet as defined above.
On-the-wire labeling for forwarded packets was discussed just recently in a
few messages between Venkat and myself on this thread.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-07 14:14 [RFC 0/5] Static/fallback external labels for NetLabel Paul Moore
` (6 preceding siblings ...)
2007-08-09 12:42 ` Stephen Smalley
@ 2007-08-09 15:48 ` Casey Schaufler
2007-08-09 19:38 ` Paul Moore
7 siblings, 1 reply; 57+ messages in thread
From: Casey Schaufler @ 2007-08-09 15:48 UTC (permalink / raw)
To: Paul Moore, selinux; +Cc: kaigai, joe
--- Paul Moore <paul.moore@hp.com> wrote:
> This patchset adds the static/fallback labeling feature to NetLabel that has
> been requested on the SELinux mailing list more and more recently. This new
> bit of functionality also matches what can be found on similar
> trusted/labeled
> OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet ready
> for "upstreaming" so please do not pull this into any tree bound for the
> mainline kernel; I still need to do more review and testing of the code.
> However, I know there are several of you on this list that have been
> anxiously
> awaiting this patchset so I thought I would make an early release so you
> could
> get a peek and test it out. I won't be able to work on this patchset much,
> if
> at all, between August 10th and the 20th so don't expect an update from me
> until the end of August.
>
> The basic idea is that currently there is no method for providing an external
> label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO
> or labeled IPsec is not in use. This patch adds a mechanism for providing a
> static fallback label, specified per interface/network, which is used when
> a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.
I'm all in favor of the facility. I do however object to the use of
a secid as the mechanism for storing the default label. As I've mentioned
elsewhere, secid's are SELinux specific and add unnecessary overhead to
schemes that don't use them natively. I understand and appreciate that
SELinux is upstream, etc, etc. I understand that a scheme that does not
use secid's is less convenient for SELinux. Please?
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [RFC 0/5] Static/fallback external labels for NetLabel
2007-08-09 15:48 ` Casey Schaufler
@ 2007-08-09 19:38 ` Paul Moore
0 siblings, 0 replies; 57+ messages in thread
From: Paul Moore @ 2007-08-09 19:38 UTC (permalink / raw)
To: casey; +Cc: selinux, kaigai, joe
[I'm moving offices today and am a bit behind on this thread right now so I'm
cherry picking the easy threads]
On Thursday, August 9 2007 11:48:33 am Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > The basic idea is that currently there is no method for providing an
> > external label to fallback on if a labeled networking mechanism such as
> > NetLabel/CIPSO or labeled IPsec is not in use. This patch adds a
> > mechanism for providing a static fallback label, specified per
> > interface/network, which is used when a NetLabel recognized labeling
> > protocol (at this point CIPSO) is not in use.
>
> I'm all in favor of the facility. I do however object to the use of
> a secid as the mechanism for storing the default label. As I've mentioned
> elsewhere, secid's are SELinux specific and add unnecessary overhead to
> schemes that don't use them natively. I understand and appreciate that
> SELinux is upstream, etc, etc. I understand that a scheme that does not
> use secid's is less convenient for SELinux. Please?
I was waiting for you to say something about this, and I think you'll be happy
with my take on it ...
The patchset right now takes a binary/string blob label which it converts to a
token/secid through the LSM secctx_to_secid interface and returns it to the
LSM when it asks for the packet's security attributes. If the LSM
secctx_to_secid interface were to return an error value signifying that the
running LSM did not implement that functionality it would be very easy to
store the binary/string blob label and return that to the LSM when asked for
security attributes. However, like we talked about regarding the
NetLabel/LSM domain mapping API work, until SMACK is accepted upstream I
don't want to add any of these changes.
As long as the LSM hooks exist and the possibility of multiple LSM
implementation exist I'm going to do my best to keep NetLabel LSM agnostic.
If LSM were to go away and be replaced with SELinux (or some other LSM for
that matter) then the NetLabel interface would change a bit to remove some of
the abstraction.
That said, it may be a moot point as from what I've read so far this patchset
doesn't appear to have much support.
--
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 57+ messages in thread
