SMACK netfilter smacklabel socket match

SMACK netfilter smacklabel socket match

[Tilman Baumann]

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]

Hi all,

i made some SMACK related patches. I hope this list is the right place 
to post them.

The intention behind this patch is that i needed a way to (firewall) 
match for packets originating from specific processes.
The existing owner match did not work well enough, especially since the 
cmd-owner part is removed.
Then i thought about a way to tag processes and somehow match this tag 
in the firewall.
I recalled that SELinux can do this (SECMARK) but SELinux would have 
been way to complex for what i want. But the idea was born, i just 
needed something more simple.

SMACK seemed to be the right way. So i made a little primitive netfilter 
match to match against the security context of sockets.
SMACK does CIPSO labels, but this was not what i wanted, i wanted to 
label the socket not the packet (on the wire).
This of course only works for packets with a local socket, but this was 
my intention anyway.

This way i can label a process and all it's sockets carry the same label 
which i then can use to match against in the firewall.

The code is pretty much based on cargo cult coding from other netfilter 
matches, especially the owner match (which turned out to be a bad 
reference since it is crapped with tons of compat interfaces).

I have no kernel coding experience whatsoever and little C coding 
history. So i would really like you guys to look over it a bit.

Originally i intended to put this mask in the xtables_match structure.
.hooks = (1 << NF_INET_LOCAL_OUT) | (1 << NF_INET_LOCAL_IN)
But it turned out that i then could not longer put the rule in a chain 
which is called by the OUTPUT chain but only in OUTPUT directly.
I did not investigate much more since i did not really understand this 
part. Allowing the user to add this match wherever he wants to does not 
hurt, if there is no local socket there is no matching.
But maybe this is something that should be changed.

About the Files:
SMACK-netfilter-socket-label-match.patch
is a git patch for the current kernel.

iptables-smacklabel.patch
contains the iptables userspace part (applies to iptables-1.4.1.1)


Regards
  Tilman Baumann
-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

[-- Attachment #2: SMACK-netfilter-socket-label-match.patch --]
[-- Type: text/x-patch, Size: 5430 bytes --]

>From 1c79c7c413dd3ebd72dbe12e1133037c6ea223af Mon Sep 17 00:00:00 2001
From: Tilman Baumann <tilman.baumann@collax.com>
Date: Thu, 25 Sep 2008 19:07:37 +0200
Subject: [PATCH] SMACK netfilter socket label match


Signed-off-by: Tilman Baumann <tilman.baumann@collax.com>
---
 include/linux/netfilter/Kbuild     |    1 +
 include/linux/netfilter/xt_smack.h |   21 +++++++++
 net/netfilter/Kconfig              |   10 +++++
 net/netfilter/Makefile             |    1 +
 net/netfilter/xt_smack.c           |   79 ++++++++++++++++++++++++++++++++++++
 5 files changed, 112 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/netfilter/xt_smack.h
 create mode 100644 net/netfilter/xt_smack.c

diff --git a/include/linux/netfilter/Kbuild b/include/linux/netfilter/Kbuild
index 3aff513..9c8fffd 100644
--- a/include/linux/netfilter/Kbuild
+++ b/include/linux/netfilter/Kbuild
@@ -29,6 +29,7 @@ header-y += xt_mac.h
 header-y += xt_mark.h
 header-y += xt_multiport.h
 header-y += xt_owner.h
+header-y += xt_smack.h
 header-y += xt_pkttype.h
 header-y += xt_rateest.h
 header-y += xt_realm.h
diff --git a/include/linux/netfilter/xt_smack.h b/include/linux/netfilter/xt_smack.h
new file mode 100644
index 0000000..a3a4471
--- /dev/null
+++ b/include/linux/netfilter/xt_smack.h
@@ -0,0 +1,21 @@
+#ifndef _XT_SMACK_MATCH_H
+#define _XT_SMACK_MATCH_H
+
+#define SMK_MAXLEN      23
+#define SMK_LABELLEN    (SMK_MAXLEN+1)
+
+enum {
+	XT_SMACK_IN   = 1 << 0,
+	XT_SMACK_OUT  = 1 << 1,
+	XT_SMACK_PEER = 1 << 2,
+};
+
+struct xt_smack_match_info {
+	u_int8_t	mask, invert;
+	char    	match_in[SMK_LABELLEN];
+	char    	match_out[SMK_LABELLEN];
+	char    	match_peer_packet[SMK_LABELLEN];
+
+};
+
+#endif /* _XT_SMACK_MATCH_H */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index ee898e7..e03ff69 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -650,6 +650,16 @@ config NETFILTER_XT_MATCH_OWNER
 	based on who created the socket: the user or group. It is also
 	possible to check whether a socket actually exists.
 
+config NETFILTER_XT_MATCH_SMACK
+	tristate '"smack" socket label match support'
+	depends on NETFILTER_XTABLES
+	depends on NETFILTER_ADVANCED
+	depends on SECURITY_SMACK
+	help
+	  SMACK label matching allows you to match locally generated packets
+	  based on the smack labels of the socket which is inherited from the
+	  associated process and allows matching on the TCP peers CIPSO label.
+
 config NETFILTER_XT_MATCH_POLICY
 	tristate 'IPsec "policy" match support'
 	depends on NETFILTER_XTABLES && XFRM
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 3bd2cc5..dc2efe5 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -83,3 +83,4 @@ obj-$(CONFIG_NETFILTER_XT_MATCH_STRING) += xt_string.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_TCPMSS) += xt_tcpmss.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_TIME) += xt_time.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_U32) += xt_u32.o
+obj-$(CONFIG_NETFILTER_XT_MATCH_SMACK) += xt_smack.o
diff --git a/net/netfilter/xt_smack.c b/net/netfilter/xt_smack.c
new file mode 100644
index 0000000..b41a559
--- /dev/null
+++ b/net/netfilter/xt_smack.c
@@ -0,0 +1,79 @@
+/*
+ * Kernel module to match against SMACK labels
+ *
+ * (C) 2008 Tilman Baumann <tilman.baumann@collax.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/file.h>
+#include <net/sock.h>
+#include <linux/netfilter/x_tables.h>
+#include <linux/netfilter/xt_smack.h>
+#include <../security/smack/smack.h>
+
+
+static bool
+smack_mt(const struct sk_buff *skb, const struct net_device *in,
+         const struct net_device *out, const struct xt_match *match,
+         const void *matchinfo, int offset, unsigned int protoff,
+         bool *hotdrop)
+{
+	const struct xt_smack_match_info *info = matchinfo;
+	struct socket_smack *smacks;
+
+	if (skb->sk == NULL || skb->sk->sk_socket == NULL)
+		return (info->mask ^ info->invert) == 0;
+	smacks = skb->sk->sk_security;
+	if (smacks == NULL){
+		 return (info->mask ^ info->invert);
+	}
+
+	if(info->mask & XT_SMACK_IN){
+		return ! ((!strncmp(smacks->smk_in, info->match_in, SMK_LABELLEN)) ^
+			(info->invert & XT_SMACK_IN));
+	}
+	
+	if(info->mask & XT_SMACK_OUT){
+		return ! ((!strncmp(smacks->smk_in, info->match_out, SMK_LABELLEN)) ^
+			(info->invert & XT_SMACK_OUT));
+	}
+
+	if(info->mask & XT_SMACK_PEER){
+		return ! ((!strncmp(smacks->smk_packet, info->match_peer_packet, SMK_LABELLEN)) ^
+			(info->invert & XT_SMACK_IN));
+	}
+	return true;
+}
+
+
+static struct xt_match smack_mt_reg[] __read_mostly = {
+	{
+		.name       = "smack",
+		.match      = smack_mt,
+		.matchsize  = sizeof(struct xt_smack_match_info),
+		.family     = AF_INET,
+		.me         = THIS_MODULE,
+	},
+};
+
+static int __init smack_mt_init(void)
+{
+	return xt_register_matches(smack_mt_reg, ARRAY_SIZE(smack_mt_reg));
+}
+
+static void __exit smack_mt_exit(void)
+{
+	xt_unregister_matches(smack_mt_reg, ARRAY_SIZE(smack_mt_reg));
+}
+
+module_init(smack_mt_init);
+module_exit(smack_mt_exit);
+MODULE_AUTHOR("Tilman Baumann <tilman@baumann.name>");
+MODULE_DESCRIPTION("Xtables: socket SMACK label matching");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("ipt_smack");
+MODULE_ALIAS("ip6t_smack");
-- 
1.5.6.3


[-- Attachment #3: iptables-smacklabel.patch --]
[-- Type: text/x-patch, Size: 4461 bytes --]

diff -Nur iptables-1.4.1.1/extensions/libxt_smack.c iptables-1.4.1.1-new/extensions/libxt_smack.c
--- iptables-1.4.1.1/extensions/libxt_smack.c	1970-01-01 01:00:00.000000000 +0100
+++ iptables-1.4.1.1-new/extensions/libxt_smack.c	2008-09-11 18:15:23.000000000 +0200
@@ -0,0 +1,129 @@
+#include <stdbool.h>
+#include <stdio.h>
+#include <netdb.h>
+#include <string.h>
+#include <stdlib.h>
+#include <getopt.h>
+
+#include <xtables.h>
+#include <linux/netfilter/xt_smack.h>
+
+/* Function which prints out usage message. */
+static void smack_help(void)
+{
+	printf(
+"smack match options:\n"
+"[!] --in       label      Match socket in label\n"
+"[!] --out      label      Match socket out label\n"
+"[!] --tcp-peer label      Match TCP peer label (CIPSO)\n");
+}
+
+
+static const struct option smack_opts[] = {
+	{.name = "in",       .has_arg = true, .val = 'i'},
+	{.name = "out",      .has_arg = true, .val = 'o'},
+	{.name = "tcp-peer", .has_arg = true, .val = 'p'},
+	{ .name = NULL }
+};
+
+static void parse_label(const char *s, char *d)
+{	
+	int slen = strlen(s);
+
+	if (slen >= SMK_LABELLEN) {
+		exit_error(PARAMETER_PROBLEM,
+			"SMACK label must be shorter than %i characters", SMK_LABELLEN);
+	}
+	strcpy(d, s);
+}
+
+static int smack_parse(int c, char **argv, int invert, unsigned int *flags,
+                          const void *entry, struct xt_entry_match **match)
+{
+	struct xt_smack_match_info *info = (void *)(*match)->data;
+
+	switch (c) {
+	case 'i':
+		param_act(P_ONLY_ONCE, "smack", "--in", *flags & XT_SMACK_IN);
+		
+		if (invert)
+			info->invert |= XT_SMACK_IN;
+		info->mask  |= XT_SMACK_IN;
+		parse_label(optarg, info->match_in);
+		*flags       |= XT_SMACK_IN;
+		return true;
+
+	case 'o':
+		param_act(P_ONLY_ONCE, "smack", "--out", *flags & XT_SMACK_OUT);
+		
+		if (invert)
+			info->invert |= XT_SMACK_OUT;
+		info->mask  |= XT_SMACK_OUT;
+		parse_label(optarg, info->match_out);
+		*flags       |= XT_SMACK_OUT;
+		return true;
+
+	case 'p':
+		param_act(P_ONLY_ONCE, "smack", "--tcp-peer", *flags & XT_SMACK_PEER);
+		
+		if (invert)
+			info->invert |= XT_SMACK_PEER;
+		info->mask  |= XT_SMACK_PEER;
+		parse_label(optarg, info->match_peer_packet);
+		*flags       |= XT_SMACK_PEER;
+		return true;
+	}
+	return false;
+}
+
+static void smack_check(unsigned int flags)
+{
+	if (!flags)
+		exit_error(PARAMETER_PROBLEM,
+			   "SMACK match: You must at least specify one match");
+}
+
+static void smack_save_item(const char *param, const char *label, u_int8_t invert){
+	if (invert)
+		printf("! ");
+	printf("--%s \"%s\" ", param, label);
+}
+
+static void smack_save(const void *ip, const struct xt_entry_match *match)
+{
+	struct xt_smack_match_info *info = (struct xt_smack_match_info *)match->data;
+
+	if(info->mask & XT_SMACK_IN)
+		smack_save_item("in", info->match_in, info->invert & XT_SMACK_IN);
+	if(info->mask & XT_SMACK_OUT)
+		smack_save_item("out", info->match_out, info->invert & XT_SMACK_OUT);
+	if(info->mask & XT_SMACK_PEER)
+		smack_save_item("tcp-peer", info->match_peer_packet, info->invert & XT_SMACK_PEER);
+
+}
+
+static void smack_print(const void *ip, const struct xt_entry_match *match, int numeric)
+{
+	printf("SMACK label match ");
+	smack_save(ip, match);
+	
+}
+
+static struct xtables_match smack_match = {
+	.family		= AF_UNSPEC,
+	.name		= "smack",
+	.version	= XTABLES_VERSION,
+	.size		= XT_ALIGN(sizeof(struct xt_smack_match_info)),
+	.userspacesize	= XT_ALIGN(sizeof(struct xt_smack_match_info)),
+	.help		= smack_help,
+	.parse		= smack_parse,
+	.final_check	= smack_check,
+	.print		= smack_print,
+	.save		= smack_save,
+	.extra_opts	= smack_opts,
+};
+
+void _init(void)
+{
+	xtables_register_match(&smack_match);
+}
diff -Nur iptables-1.4.1.1/include/linux/netfilter/xt_smack.h iptables-1.4.1.1-new/include/linux/netfilter/xt_smack.h
--- iptables-1.4.1.1/include/linux/netfilter/xt_smack.h	1970-01-01 01:00:00.000000000 +0100
+++ iptables-1.4.1.1-new/include/linux/netfilter/xt_smack.h	2008-09-11 17:36:25.000000000 +0200
@@ -0,0 +1,21 @@
+#ifndef _XT_SMACK_MATCH_H
+#define _XT_SMACK_MATCH_H
+
+#define SMK_MAXLEN      23
+#define SMK_LABELLEN    (SMK_MAXLEN+1)
+
+enum {
+	XT_SMACK_IN   = 1 << 0,
+	XT_SMACK_OUT  = 1 << 1,
+	XT_SMACK_PEER = 1 << 2,
+};
+
+struct xt_smack_match_info {
+	u_int8_t	mask, invert;
+	char    	match_in[SMK_LABELLEN];
+	char    	match_out[SMK_LABELLEN];
+	char    	match_peer_packet[SMK_LABELLEN];
+
+};
+
+#endif /* _XT_SMACK_MATCH_H */

Re: SMACK netfilter smacklabel socket match

[Paul Moore]

On Thursday 25 September 2008 1:25:53 pm Tilman Baumann wrote:
> Hi all,

Hello.

> i made some SMACK related patches. I hope this list is the right
> place to post them.

Most Smack development has taken place on the LSM mailing list.  At the 
very least I would recommend you CC the LSM list when sending Smack 
patches.  I've taken the liberty of CC'ing both the LSM list and Casey 
on this email.

> The intention behind this patch is that i needed a way to (firewall)
> match for packets originating from specific processes.
> The existing owner match did not work well enough, especially since
> the cmd-owner part is removed.
> Then i thought about a way to tag processes and somehow match this
> tag in the firewall.
> I recalled that SELinux can do this (SECMARK) but SELinux would have
> been way to complex for what i want. But the idea was born, i just
> needed something more simple.

It appears the simplest option would be to provide the necessary SECMARK 
support in Smack.  SECMARK has provisions for supporting different 
types of LSMs and adding Smack support should be relatively trivial.  
In fact, it is possible for SECMARK to be made entirely LSM agnostic 
and have it deal strictly with secctx/label and secid/token values.  We 
would need to retain the SELinux specific interface for 
legacy/compatibility reasons but I would encourage new patches to take 
this more general approach rather than LSM specific extension.

> SMACK seemed to be the right way. So i made a little primitive
> netfilter match to match against the security context of sockets.
> SMACK does CIPSO labels, but this was not what i wanted, i wanted to
> label the socket not the packet (on the wire).

I would encourage you to look at selinux_ip_postroute() since it does 
exactly what you describe above using the SECMARK mechanism (in 
addition to other work).  In particular look at the following code 
snippet:

        sk = skb->sk;
        if (sk) {
                struct sk_security_struct *sksec = sk->sk_security;
                peer_sid = sksec->sid;
                secmark_perm = PACKET__SEND;
        } else {
                if (selinux_skb_peerlbl_sid(skb, family, &peer_sid))
                                return NF_DROP;
                secmark_perm = PACKET__FORWARD_OUT;
        }

        if (secmark_active)
                if (avc_has_perm(peer_sid, skb->secmark,
                                 SECCLASS_PACKET, secmark_perm, &ad))
                        return NF_DROP;

In the first if block you see that we are actually getting the security 
label from the socket, _not_ the packet, and then using that to perform 
the access control decision with avc_has_perm().  It should be easy to 
do the same with Smack and SECMARK.

[NOTE: you may notice the above code changing slightly in future 
kernels, it turns out that skb->sk == NULL is not a true indicator of a 
non-local sender, see my labeled networking patches for 2.6.28 or 
linux-next for the revised approach]

> This of course only works for packets with a local socket, but this
> was my intention anyway.

You could also expand it to handle non-local senders.  However, from my 
discussions with Casey about Smack and network access controls, 
enforcing policy against forwarded traffic is not something he is 
interested in at this point.

> I have no kernel coding experience whatsoever and little C coding
> history. So i would really like you guys to look over it a bit.

[NOTE: you will want to post your patches inline in the future, sending 
patches as attachments are frowned upon]

Okay, I'll make a few comments on the kernel patch, you would probably 
want to ask the netfilter folks for comments on both patches.  However, 
please keep in mind that I do not currently see a reason why you 
couldn't achieve your needs with the existing SECMARK code (with some 
modification/extension), please pursue that option before continuing 
with a dedicated SMACK target for netfilter.

A few comments on your patch:

> From 1c79c7c413dd3ebd72dbe12e1133037c6ea223af Mon Sep 17 00:00:00
> 2001 From: Tilman Baumann <tilman.baumann@collax.com>
> Date: Thu, 25 Sep 2008 19:07:37 +0200
> Subject: [PATCH] SMACK netfilter socket label match
>
>
> Signed-off-by: Tilman Baumann <tilman.baumann@collax.com>
> ---
>  include/linux/netfilter/Kbuild     |    1 +
>  include/linux/netfilter/xt_smack.h |   21 +++++++++
>  net/netfilter/Kconfig              |   10 +++++
>  net/netfilter/Makefile             |    1 +
>  net/netfilter/xt_smack.c           |   79
> ++++++++++++++++++++++++++++++++++++ 5 files changed, 112
> insertions(+), 0 deletions(-)
>  create mode 100644 include/linux/netfilter/xt_smack.h
>  create mode 100644 net/netfilter/xt_smack.c

...

> --- /dev/null
> +++ b/net/netfilter/xt_smack.c
> @@ -0,0 +1,79 @@
> +/*
> + * Kernel module to match against SMACK labels
> + *
> + * (C) 2008 Tilman Baumann <tilman.baumann@collax.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify + * it under the terms of the GNU General Public License
> version 2 as + * published by the Free Software Foundation.
> + */
> +#include <linux/module.h>
> +#include <linux/skbuff.h>
> +#include <linux/file.h>
> +#include <net/sock.h>
> +#include <linux/netfilter/x_tables.h>
> +#include <linux/netfilter/xt_smack.h>
> +#include <../security/smack/smack.h>

If you need a Smack specific interface you shouldn't include a file from 
security/smack, instead you should use/create an interface in 
include/linux/smack.h.  In this particular case this would mean 
creating the file.

> +static bool
> +smack_mt(const struct sk_buff *skb, const struct net_device *in,
> +         const struct net_device *out, const struct xt_match *match,
> +         const void *matchinfo, int offset, unsigned int protoff,
> +         bool *hotdrop)
> +{
> +	const struct xt_smack_match_info *info = matchinfo;
> +	struct socket_smack *smacks;
> +
> +	if (skb->sk == NULL || skb->sk->sk_socket == NULL)
> +		return (info->mask ^ info->invert) == 0;
> +	smacks = skb->sk->sk_security;
> +	if (smacks == NULL){
> +		 return (info->mask ^ info->invert);
> +	}
> +
> +	if(info->mask & XT_SMACK_IN){
> +		return ! ((!strncmp(smacks->smk_in, info->match_in, SMK_LABELLEN))
> ^ +			(info->invert & XT_SMACK_IN));
> +	}
> +
> +	if(info->mask & XT_SMACK_OUT){
> +		return ! ((!strncmp(smacks->smk_in, info->match_out,
> SMK_LABELLEN)) ^ +			(info->invert & XT_SMACK_OUT));
> +	}
> +
> +	if(info->mask & XT_SMACK_PEER){
> +		return ! ((!strncmp(smacks->smk_packet, info->match_peer_packet,
> SMK_LABELLEN)) ^ +			(info->invert & XT_SMACK_IN));
> +	}

I don't like how the access control is being done outside of the Smack 
LSM; once again I would encourage you to further investigate the 
approach taken by SECMARK.  If you must do access control outside of 
the LSM then please at least abstract the actual access control 
decision, in this case strncmp(), to a LSM interface.

-- 
paul moore
linux @ hp

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Am 25.09.2008 um 20:26 schrieb Paul Moore:

> On Thursday 25 September 2008 1:25:53 pm Tilman Baumann wrote:

>
>> The intention behind this patch is that i needed a way to (firewall)
>> match for packets originating from specific processes.
>> The existing owner match did not work well enough, especially since
>> the cmd-owner part is removed.
>> Then i thought about a way to tag processes and somehow match this
>> tag in the firewall.
>> I recalled that SELinux can do this (SECMARK) but SELinux would have
>> been way to complex for what i want. But the idea was born, i just
>> needed something more simple.
>
> It appears the simplest option would be to provide the necessary  
> SECMARK
> support in Smack.  SECMARK has provisions for supporting different
> types of LSMs and adding Smack support should be relatively trivial.
> In fact, it is possible for SECMARK to be made entirely LSM agnostic
> and have it deal strictly with secctx/label and secid/token values.   
> We
> would need to retain the SELinux specific interface for
> legacy/compatibility reasons but I would encourage new patches to take
> this more general approach rather than LSM specific extension.

Sounds like a good idea. When i looked at the SECMARK code i could not  
get my
head around the SELinux specific stuff, so i discarded the idea as to  
complex.

For this to be complete i guess the CIPSO labels for SMACK would need
to be taken into account.
Far more than my quick and dirty approach, and probably more than i'm  
the
right person to do it.
Il try to understand the inner workings of the SECMARK stuff tough.

I will come back to your other comments tomorrow.

> [NOTE: you may notice the above code changing slightly in future
> kernels, it turns out that skb->sk == NULL is not a true indicator  
> of a
> non-local sender, see my labeled networking patches for 2.6.28 or
> linux-next for the revised approach]
Good to know.

>> This of course only works for packets with a local socket, but this
>> was my intention anyway.
>
> You could also expand it to handle non-local senders.  However, from  
> my
> discussions with Casey about Smack and network access controls,
> enforcing policy against forwarded traffic is not something he is
> interested in at this point.

I have not investigated further into that, but if there is some way to
match on CIPSO labels, there would be at least a vehicle to base this  
on.

>> I have no kernel coding experience whatsoever and little C coding
>> history. So i would really like you guys to look over it a bit.
>
> [NOTE: you will want to post your patches inline in the future,  
> sending
> patches as attachments are frowned upon]
ok

> I don't like how the access control is being done outside of the Smack
> LSM; once again I would encourage you to further investigate the
> approach taken by SECMARK.  If you must do access control outside of
> the LSM then please at least abstract the actual access control
> decision, in this case strncmp(), to a LSM interface.

Access control was actually not what i needed in this case.
This would in this case as far as i know actually be done in the SMACK  
LSM.
I'm not sure how much it would make sense to base firewall decisions on
capability checks (i guess this is what you referring to).
Like decisions in the form of who/what may access a process in which  
way.
Please correct me if i understood you wrong.

What i do with this match is just setting some CONNMARK and respectively
FWMARKS to make crazy routing rules for different kinds (marked  
processes)
of my outgoing traffic based on them.


Regards
  Tilman

Re: SMACK netfilter smacklabel socket match

[Paul Moore]

On Thursday 25 September 2008 3:26:40 pm Tilman Baumann wrote:
> Am 25.09.2008 um 20:26 schrieb Paul Moore:
> > On Thursday 25 September 2008 1:25:53 pm Tilman Baumann wrote:
> >> The intention behind this patch is that i needed a way to
> >> (firewall) match for packets originating from specific processes.
> >> The existing owner match did not work well enough, especially
> >> since the cmd-owner part is removed.
> >> Then i thought about a way to tag processes and somehow match this
> >> tag in the firewall.
> >> I recalled that SELinux can do this (SECMARK) but SELinux would
> >> have been way to complex for what i want. But the idea was born, i
> >> just needed something more simple.
> >
> > It appears the simplest option would be to provide the necessary
> > SECMARK
> > support in Smack.  SECMARK has provisions for supporting different
> > types of LSMs and adding Smack support should be relatively
> > trivial. In fact, it is possible for SECMARK to be made entirely
> > LSM agnostic and have it deal strictly with secctx/label and
> > secid/token values. We
> > would need to retain the SELinux specific interface for
> > legacy/compatibility reasons but I would encourage new patches to
> > take this more general approach rather than LSM specific extension.
>
> Sounds like a good idea. When i looked at the SECMARK code i could
> not get my
> head around the SELinux specific stuff, so i discarded the idea as to
> complex.
>
> For this to be complete i guess the CIPSO labels for SMACK would need
> to be taken into account.
> Far more than my quick and dirty approach, and probably more than i'm
> the right person to do it.
> Il try to understand the inner workings of the SECMARK stuff tough.

With SELinux the packet's CIPSO label (called the packet's peer label) 
is different from the SECMARK label.  Assuming you take a similar 
approach in Smack, you should be able to implement SECMARK without 
having to every concern yourself with the CIPSO label.

> >> This of course only works for packets with a local socket, but
> >> this was my intention anyway.
> >
> > You could also expand it to handle non-local senders.  However,
> > from my
> > discussions with Casey about Smack and network access controls,
> > enforcing policy against forwarded traffic is not something he is
> > interested in at this point.
>
> I have not investigated further into that, but if there is some way
> to match on CIPSO labels, there would be at least a vehicle to base
> this on.

Yes, in the absence of the sending socket to obtain the packet's peer 
label you need to examine the packet itself and any labeling 
information present on the packet; in the case of Smack this is CIPSO.

> > I don't like how the access control is being done outside of the
> > Smack LSM; once again I would encourage you to further investigate
> > the approach taken by SECMARK.  If you must do access control
> > outside of the LSM then please at least abstract the actual access
> > control decision, in this case strncmp(), to a LSM interface.
>
> Access control was actually not what i needed in this case.
> This would in this case as far as i know actually be done in the
> SMACK LSM.

Well, if you are accepting or dropping packets you are applying some 
form of access control.  I thought that was the point of your patch?  
If not perhaps I misunderstood or assumed too much.

> I'm not sure how much it would make sense to base firewall decisions
> on capability checks (i guess this is what you referring to).
> Like decisions in the form of who/what may access a process in which
> way.
> Please correct me if i understood you wrong.

Hmmm, the term "capability" is probably not the best term to use, but 
there are valid reasons to use the netfilter mechanism, i.e. SECMARK, 
to apply a network label to both incoming and outgoing packets.  The 
idea is that this allows the LSM to make network access control 
decisions based on the network attributes of a packet (address, 
protocol, port, etc.) and the powerful packet/connection matching 
mechanisms in netfilter.

> What i do with this match is just setting some CONNMARK and
> respectively FWMARKS to make crazy routing rules for different kinds
> (marked processes)
> of my outgoing traffic based on them.

I think I understand you goal now, essentially you want to route traffic 
based on the security label of the sender, yes?  There was some brief 
talk about this at the SELinux Developer's Summit this year at OLS.  
Unfortunately, it was just a casual conversation and I haven't seen any 
patches since then implementing security label based routing.

-- 
paul moore
linux @ hp

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Am 25.09.2008 um 21:57 schrieb Paul Moore:
>>
>> What i do with this match is just setting some CONNMARK and
>> respectively FWMARKS to make crazy routing rules for different kinds
>> (marked processes)
>> of my outgoing traffic based on them.
>
> I think I understand you goal now, essentially you want to route  
> traffic
> based on the security label of the sender, yes?  There was some brief
> talk about this at the SELinux Developer's Summit this year at OLS.
> Unfortunately, it was just a casual conversation and I haven't seen  
> any
> patches since then implementing security label based routing.

Wow, now it strikes me that i was running around blind all the time.
SECMARK is a target not a match.
I always thought i would implementing much the same thing.

I guess there would be in fact currently not way to set a MARK or  
CONNMAK
based on a SECMARK. Most of the *MARK targets have a --restore-mark  
option
to restore a mark into the packet mark.
But since the SECMARK is not numeric/bitmask there is nothing to  
restore.
They however can do the same in regard do CONNSECMARK and SECMARK
but which would not help in this case.
A secmark netfilter _match_ could do the trick here.

Well here is how i did this, maybe something like this is the way to  
go for
SELinux (or LSM in general) too.

I'm surprised that i have not realized this little detail before. :-/

Regards
  Tilman

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
> Hi all,
>
> i made some SMACK related patches. I hope this list is the right place 
> to post them.

Here and, probably more importantly 
linux-security-module@vger.kernel.org as that's
my primary hang out.

> The intention behind this patch is that i needed a way to (firewall) 
> match for packets originating from specific processes.
> The existing owner match did not work well enough, especially since 
> the cmd-owner part is removed.
> Then i thought about a way to tag processes and somehow match this tag 
> in the firewall.
> I recalled that SELinux can do this (SECMARK) but SELinux would have 
> been way to complex for what i want. But the idea was born, i just 
> needed something more simple.
>
> SMACK seemed to be the right way. So i made a little primitive 
> netfilter match to match against the security context of sockets.
> SMACK does CIPSO labels, but this was not what i wanted, i wanted to 
> label the socket not the packet (on the wire).
> This of course only works for packets with a local socket, but this 
> was my intention anyway.
>
> This way i can label a process and all it's sockets carry the same 
> label which i then can use to match against in the firewall.
>

Hmm. It looks as if your code will do what you're asking it to do.
Are you going to be happy with the access restrictions that will be
imposed by Smack?

> The code is pretty much based on cargo cult coding from other 
> netfilter matches, especially the owner match (which turned out to be 
> a bad reference since it is crapped with tons of compat interfaces).
>
> I have no kernel coding experience whatsoever and little C coding 
> history. So i would really like you guys to look over it a bit.
>
> Originally i intended to put this mask in the xtables_match structure.
> .hooks = (1 << NF_INET_LOCAL_OUT) | (1 << NF_INET_LOCAL_IN)
> But it turned out that i then could not longer put the rule in a chain 
> which is called by the OUTPUT chain but only in OUTPUT directly.
> I did not investigate much more since i did not really understand this 
> part. Allowing the user to add this match wherever he wants to does 
> not hurt, if there is no local socket there is no matching.
> But maybe this is something that should be changed.
>
> About the Files:
> SMACK-netfilter-socket-label-match.patch
> is a git patch for the current kernel.
>
> iptables-smacklabel.patch
> contains the iptables userspace part (applies to iptables-1.4.1.1)
>
>
> Regards
>  Tilman Baumann

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Am 26.09.2008 um 05:43 schrieb Casey Schaufler:

> Tilman Baumann wrote:
>> Hi all,
>>
>> i made some SMACK related patches. I hope this list is the right  
>> place to post them.
>
> Here and, probably more importantly linux-security-module@vger.kernel.org 
>  as that's
> my primary hang out.
>
>> The intention behind this patch is that i needed a way to  
>> (firewall) match for packets originating from specific processes.
>> The existing owner match did not work well enough, especially since  
>> the cmd-owner part is removed.
>> Then i thought about a way to tag processes and somehow match this  
>> tag in the firewall.
>> I recalled that SELinux can do this (SECMARK) but SELinux would  
>> have been way to complex for what i want. But the idea was born, i  
>> just needed something more simple.
>>
>> SMACK seemed to be the right way. So i made a little primitive  
>> netfilter match to match against the security context of sockets.
>> SMACK does CIPSO labels, but this was not what i wanted, i wanted  
>> to label the socket not the packet (on the wire).
>> This of course only works for packets with a local socket, but this  
>> was my intention anyway.
>>
>> This way i can label a process and all it's sockets carry the same  
>> label which i then can use to match against in the firewall.
>>
>
> Hmm. It looks as if your code will do what you're asking it to do.
> Are you going to be happy with the access restrictions that will be
> imposed by Smack?

I helped myself with rules like this.
_ foo rwx
But i wanted to add some security stuff like selinux for years,
and SMACK seems to be just great.
So i will spend some time making security rules after i got this routing
stuff to work. :)

Regards
  Tilman

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Paul Moore wrote:

> [NOTE: you may notice the above code changing slightly in future 
> kernels, it turns out that skb->sk == NULL is not a true indicator of a 
> non-local sender, see my labeled networking patches for 2.6.28 or 
> linux-next for the revised approach]

Can you give me a pointer where to look?

Will this mean that skb->sk may be invalid or that it will point to a a 
context based on the network label the packet has?
In the later case, being able to match remote labels in my match would 
just give added benefit. (Though a netlabel (CIPSO) match would probably 
be more sane than a smack specific match.)
One would just have more choices where to put a rule like this. Like in 
the FORWARD chain.
If non local packets are of no interest, one could put the rule in the 
right chain.

But i think i just misunderstood you here. Since having a socket for non 
local packets is probably not what you meant.

Regards
  Tilman
-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Paul Moore]

On Friday 26 September 2008 8:35:12 am Tilman Baumann wrote:
> Paul Moore wrote:
> > [NOTE: you may notice the above code changing slightly in future
> > kernels, it turns out that skb->sk == NULL is not a true indicator
> > of a non-local sender, see my labeled networking patches for 2.6.28
> > or linux-next for the revised approach]
>
> Can you give me a pointer where to look?

Sure.  You want to look at the selinux_ip_postroue() function which is 
located in the security/selinux/hooks.c file in a patched version of 
the kernel.  The particular patch you need can be found here:

 * http://marc.info/?l=linux-security-module&m=122156989812425&w=2

You can grab the patch (and others in the queue for 2.6.28) from the 
labeled networking git tree located here:

 * http://git.infradead.org/users/pcmoore/lblnet-2.6_testing
 * git://git.infradead.org/users/pcmoore/lblnet-2.6_testing

> Will this mean that skb->sk may be invalid or that it will point to a
> a context based on the network label the packet has?

No.  It just means that if the skb->sk pointer is NULL the packet might 
not actually be for another system, i.e. a forwarded packet.  It turns 
out there are a few places in the kernel that send packets without an 
associated socket.  If you look towards the very bottom of the patch I 
referenced at the top of this email you will see the following 
code/patch which should now handle this case correctly for SELinux.  
Smack is unaffected because of it's current network access controls.

You want to pay attention to how the 'peer_sid' value is derived as this 
is the SELinux "security label".

[NOTE: I hacked up the diff below a bit so it is a bit cleaner in this 
email]

@@ -4574,21 +4586,45 @@ static unsigned int selinux_ip_postroute(struct 
        if (!secmark_active && !peerlbl_active)
                return NF_ACCEPT;
 
-       /* if the packet is locally generated (skb->sk != NULL) then use 
-        * socket's label as the peer label, otherwise the packet is 
-        * forwarded through this system and we need to fetch the peer 
-        * directly from the packet */
+       /* if the packet is being forwarded then get the peer label from 
+        * packet itself; otherwise check to see if it is from a local
+        * application or the kernel, if from an application get the 
+        * from the sending socket, otherwise use the kernel's sid */
        sk = skb->sk;
-       if (sk) {
+       if (sk == NULL) {
+               switch (family) {
+               case PF_INET:
+                       if (IPCB(skb)->flags & IPSKB_FORWARDED)
+                               secmark_perm = PACKET__FORWARD_OUT;
+                       else
+                               secmark_perm = PACKET__SEND;
+                       break;
+               case PF_INET6:
+                       if (IP6CB(skb)->flags & IP6SKB_FORWARDED)
+                               secmark_perm = PACKET__FORWARD_OUT;
+                       else
+                               secmark_perm = PACKET__SEND;
+                       break;
+               default:
+                       return NF_DROP;
+               }
+               if (secmark_perm == PACKET__FORWARD_OUT) {
+                       if (selinux_skb_peerlbl_sid(skb,..., &peer_sid);
+                               return NF_DROP;
+               } else
+                       peer_sid = SECINITSID_KERNEL;
+       } else {
                struct sk_security_struct *sksec = sk->sk_security;
                peer_sid = sksec->sid;
                secmark_perm = PACKET__SEND;
-       } else {
-               if (selinux_skb_peerlbl_sid(skb, family, &peer_sid))
-                               return NF_DROP;
-               secmark_perm = PACKET__FORWARD_OUT;
        }

> In the later case, being able to match remote labels in my match
> would just give added benefit. (Though a netlabel (CIPSO) match would
> probably be more sane than a smack specific match.)
> One would just have more choices where to put a rule like this. Like
> in the FORWARD chain.
> If non local packets are of no interest, one could put the rule in
> the right chain.

I've been thinking a little more about the idea of using a packet's peer 
security label as a netfilter match and I have one major concern: if we 
allow netfilter to match on a packet's peer security label[1] then we 
are opening the door for administrators to arbitrarily apply label 
based security policy regardless of the LSM's security policy.  For 
many reasons beyond the scope of this discussion thread this is a Bad 
Idea, which makes me nervous about providing such a general matching 
function.  If you are interested in pursuing this further I would 
definitely need more discussion around this point.

[1] Matching on the packet's SECMARK security label is equally bad, but 
also somewhat pointless since the SECMARK security label is defined by 
netfilter already, why not just have the original netfilter SECMARK 
rule do whatever you wanted in the first place?  In other words, you 
don't need SECMARK for this particular case.

-- 
paul moore
linux @ hp

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
> Am 26.09.2008 um 05:43 schrieb Casey Schaufler:
>
>> Tilman Baumann wrote:
>>> Hi all,
>>>
>>> i made some SMACK related patches. I hope this list is the right 
>>> place to post them.
>>
>> Here and, probably more importantly 
>> linux-security-module@vger.kernel.org as that's
>> my primary hang out.
>>
>>> The intention behind this patch is that i needed a way to (firewall) 
>>> match for packets originating from specific processes.
>>> The existing owner match did not work well enough, especially since 
>>> the cmd-owner part is removed.
>>> Then i thought about a way to tag processes and somehow match this 
>>> tag in the firewall.
>>> I recalled that SELinux can do this (SECMARK) but SELinux would have 
>>> been way to complex for what i want. But the idea was born, i just 
>>> needed something more simple.
>>>
>>> SMACK seemed to be the right way. So i made a little primitive 
>>> netfilter match to match against the security context of sockets.
>>> SMACK does CIPSO labels, but this was not what i wanted, i wanted to 
>>> label the socket not the packet (on the wire).
>>> This of course only works for packets with a local socket, but this 
>>> was my intention anyway.
>>>
>>> This way i can label a process and all it's sockets carry the same 
>>> label which i then can use to match against in the firewall.
>>>
>>
>> Hmm. It looks as if your code will do what you're asking it to do.
>> Are you going to be happy with the access restrictions that will be
>> imposed by Smack?
>
> I helped myself with rules like this.
> _ foo rwx
> But i wanted to add some security stuff like selinux for years,
> and SMACK seems to be just great.
> So i will spend some time making security rules after i got this routing
> stuff to work. :)
>
I confess that I'm still not completely sure what you're up too,
but you might want to look at smackpolyport (it's in the smack-util
tarball) and might make your life easier if you want to have a
single server (running at foo) that deals with connections from
processes with multiple labels.

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Casey Schaufler wrote:
> Tilman Baumann wrote:

>>> Hmm. It looks as if your code will do what you're asking it to do.
>>> Are you going to be happy with the access restrictions that will be
>>> imposed by Smack?
>>
>> I helped myself with rules like this.
>> _ foo rwx
>> But i wanted to add some security stuff like selinux for years,
>> and SMACK seems to be just great.
>> So i will spend some time making security rules after i got this routing
>> stuff to work. :)
>>
> I confess that I'm still not completely sure what you're up too,
> but you might want to look at smackpolyport (it's in the smack-util
> tarball) and might make your life easier if you want to have a
> single server (running at foo) that deals with connections from
> processes with multiple labels.

I'm essentially using this as some kind of iptables owner-match on steroids.
Owner match allows to filter on the processes uid, gid, and some other 
process attributes.
Unfortunately owner match is pretty much useless because of it's limited 
matching capabilities.

I'm really just abusing the way how security contexts of processes are 
transfered to all it's sockets.
This way I can label a process with a specific label which then gets 
transfered to all of it's sockets.
With this match I can look at the label via the socket of any packet in 
  iptables.
I'm pretty much ignoring the Security aspect of SMACK right now  and 
just use it as some label that I can stick to processes.

What I then to is write iptables OUTPUT chain matches which match for 
any of these labels and set some connection marks and firewall marks.
Which I then can use in routing rules to give different routing rules to 
specific processes. (Like all proxy traffic over a second DSL line)

I know, it's totally crazy. But it seems to work. :)
I just hope the security part of this all will not break anything. But 
it does not look like it would right now.

-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
>
>
> Casey Schaufler wrote:
>> Tilman Baumann wrote:
>
>>>> Hmm. It looks as if your code will do what you're asking it to do.
>>>> Are you going to be happy with the access restrictions that will be
>>>> imposed by Smack?
>>>
>>> I helped myself with rules like this.
>>> _ foo rwx
>>> But i wanted to add some security stuff like selinux for years,
>>> and SMACK seems to be just great.
>>> So i will spend some time making security rules after i got this 
>>> routing
>>> stuff to work. :)
>>>
>> I confess that I'm still not completely sure what you're up too,
>> but you might want to look at smackpolyport (it's in the smack-util
>> tarball) and might make your life easier if you want to have a
>> single server (running at foo) that deals with connections from
>> processes with multiple labels.
>
> I'm essentially using this as some kind of iptables owner-match on 
> steroids.
> Owner match allows to filter on the processes uid, gid, and some other 
> process attributes.
> Unfortunately owner match is pretty much useless because of it's 
> limited matching capabilities.
>
> I'm really just abusing the way how security contexts of processes are 
> transfered to all it's sockets.
> This way I can label a process with a specific label which then gets 
> transfered to all of it's sockets.
> With this match I can look at the label via the socket of any packet 
> in  iptables.
> I'm pretty much ignoring the Security aspect of SMACK right now  and 
> just use it as some label that I can stick to processes.
>

If you really want to be abusive you could replace the smack_access()
function in security/smack/smack_access.c (of all places) with a no-op
returning 0 in all cases.

> What I then to is write iptables OUTPUT chain matches which match for 
> any of these labels and set some connection marks and firewall marks.
> Which I then can use in routing rules to give different routing rules 
> to specific processes. (Like all proxy traffic over a second DSL line)
>
> I know, it's totally crazy. But it seems to work. :)
> I just hope the security part of this all will not break anything. But 
> it does not look like it would right now.

Smack will eventually bite you if you're not careful, but users of
MAC systems wouldn't be surprised by that. I don't think it's crazy,
I think it's a matter of using what's available in novel ways. Don't
hesitate if there's anything I can do to be helpful.

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Casey Schaufler wrote:
>> Casey Schaufler wrote:
> If you really want to be abusive you could replace the smack_access()
> function in security/smack/smack_access.c (of all places) with a no-op
> returning 0 in all cases.

I thought of that too. :)
But i would rather like to use the thing in it's intended function 
sometime in the future.

>> What I then to is write iptables OUTPUT chain matches which match for 
>> any of these labels and set some connection marks and firewall marks.
>> Which I then can use in routing rules to give different routing rules 
>> to specific processes. (Like all proxy traffic over a second DSL line)
>>
>> I know, it's totally crazy. But it seems to work. :)
>> I just hope the security part of this all will not break anything. But 
>> it does not look like it would right now.
> 
> Smack will eventually bite you if you're not careful, but users of
> MAC systems wouldn't be surprised by that.
Speaking of the devil...
This is exactly what happened to me right now. I have problems with 
_some_ https connects. The problem lies somewhere in openssl.
I did not yet find any clue with strace.
Is there some straight forward way to audit/debug LSM interventions?

I have probably missed something that a labeled process could not do as 
a '_' process could. Have no idea right now, but it is probably 
something stupidly simple.

> I don't think it's crazy,
> I think it's a matter of using what's available in novel ways.
I like that attitude. :)

-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
> Casey Schaufler wrote:
>>> Casey Schaufler wrote:
>> If you really want to be abusive you could replace the smack_access()
>> function in security/smack/smack_access.c (of all places) with a no-op
>> returning 0 in all cases.
>
> I thought of that too. :)
> But i would rather like to use the thing in it's intended function 
> sometime in the future.

Even better.


>>> What I then to is write iptables OUTPUT chain matches which match 
>>> for any of these labels and set some connection marks and firewall 
>>> marks.
>>> Which I then can use in routing rules to give different routing 
>>> rules to specific processes. (Like all proxy traffic over a second 
>>> DSL line)
>>>
>>> I know, it's totally crazy. But it seems to work. :)
>>> I just hope the security part of this all will not break anything. 
>>> But it does not look like it would right now.
>>
>> Smack will eventually bite you if you're not careful, but users of
>> MAC systems wouldn't be surprised by that.
> Speaking of the devil...
> This is exactly what happened to me right now. I have problems with 
> _some_ https connects. The problem lies somewhere in openssl.
> I did not yet find any clue with strace.
> Is there some straight forward way to audit/debug LSM interventions?

strace is probably your best bet, as it will tell you what syscalls
fail. Your current situation is most likely a case where your program
running with a label "Foo" is trying to communicate with a service on
a machine that doesn't talk CIPSO and hence Smack is treating all
packets to and from that host with the ambient (%cat /smack/ambient)
label, which is "_" unless you've changed it.

> I have probably missed something that a labeled process could not do 
> as a '_' process could. Have no idea right now, but it is probably 
> something stupidly simple.
>

A labeled system hoping to get services from an unlabeled server is the 
biggest
single pain in dealing with labeled systems. Per-host labeling is in the 
works,
and it will help in some cases. What I really need is a way to designate an
unlabeled host as safe to talk to at any label, but it will take some 
serious
work to come up with a scheme that makes that palatable for a labeled 
environment.
I know that SELinux allows for it, but the purist in me has serious doubts.

>> I don't think it's crazy,
>> I think it's a matter of using what's available in novel ways.
> I like that attitude. :)

It got me where I am today. Hmm, maybe you should be just a little bit 
careful.

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Casey Schaufler wrote:
> Tilman Baumann wrote:
>> Casey Schaufler wrote:
>>> Smack will eventually bite you if you're not careful, but users of
>>> MAC systems wouldn't be surprised by that.
>> Speaking of the devil...
>> This is exactly what happened to me right now. I have problems with 
>> _some_ https connects. The problem lies somewhere in openssl.
>> I did not yet find any clue with strace.
>> Is there some straight forward way to audit/debug LSM interventions?
> 
> strace is probably your best bet, as it will tell you what syscalls
> fail. Your current situation is most likely a case where your program
> running with a label "Foo" is trying to communicate with a service on
> a machine that doesn't talk CIPSO and hence Smack is treating all
> packets to and from that host with the ambient (%cat /smack/ambient)
> label, which is "_" unless you've changed it.

Yea, I just found that out.
I did not expect smack to add netlabels by default. I thought I would 
need to configure something before it will start adding netlabels 'on 
the wire'.
In my case 'security' is something that should only concern the local 
machine.
Unfortunately I never bothered to test this before. :-/

If I set /smack/nltype to 'unlabeled' I have effectively shut off the 
network.
I guess I'm missing some essential point here.
Sorry to bother you with such trivialities.

btw. I find it very hard to find informations on the various files in 
/smack/ and it's respective intention and formating rules. 
security/smack/smackfs.c helps a bit.

This is my current setup:
/smack/ambient (default)
/smack/load = _ foo rwx
Unlabeled process work fine.
Labeled processes produce CIPSO labeled packets (which never get any 
answer anywhere from the internet)

If i set /smack/nltype to 'unlabled' i don't even get SYN packets out. 
(operation not permitted)

-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
> Casey Schaufler wrote:
>> Tilman Baumann wrote:
>>> Casey Schaufler wrote:
>>>> Smack will eventually bite you if you're not careful, but users of
>>>> MAC systems wouldn't be surprised by that.
>>> Speaking of the devil...
>>> This is exactly what happened to me right now. I have problems with 
>>> _some_ https connects. The problem lies somewhere in openssl.
>>> I did not yet find any clue with strace.
>>> Is there some straight forward way to audit/debug LSM interventions?
>>
>> strace is probably your best bet, as it will tell you what syscalls
>> fail. Your current situation is most likely a case where your program
>> running with a label "Foo" is trying to communicate with a service on
>> a machine that doesn't talk CIPSO and hence Smack is treating all
>> packets to and from that host with the ambient (%cat /smack/ambient)
>> label, which is "_" unless you've changed it.
>
> Yea, I just found that out.
> I did not expect smack to add netlabels by default. I thought I would 
> need to configure something before it will start adding netlabels 'on 
> the wire'.

It's pretty important to do it the way it is, because if a "Foo" process
can talk to port/host and a "Bar" process can talk to the same you can
pretty well assume that you have an information channel. I'm starting
to think about how I might go about allowing you to do it anyway.

> In my case 'security' is something that should only concern the local 
> machine.

Unfortunately, any time you talk off the machine you have to consider that
the other machine(s) may not be very careful about information flows.

> Unfortunately I never bothered to test this before. :-/
>
> If I set /smack/nltype to 'unlabeled' I have effectively shut off the 
> network.
> I guess I'm missing some essential point here.
> Sorry to bother you with such trivialities.

Not to worry. The essential point is that with MAC you can't just lock
the doors, you have to lock the windows as well. What I mean by that is
that traditional access controls apply to files, but not network
communications. Network communications became popular in part because
they were allowed to leave any restrictions up to the applications
and their protocols. MAC requirements are pickier than that. The good
news is that with a scheme like CIPSO you can easily enforce the
policy. The bad news is that network services in general assume that
there is no policy being enforced on them.

>
> btw. I find it very hard to find informations on the various files in 
> /smack/ and it's respective intention and formating rules. 
> security/smack/smackfs.c helps a bit.
If you pull down the smack-util-0.1 package from http://schaufler-ca.com
you will find programs that will do that formatting for you.
>
> This is my current setup:
> /smack/ambient (default)
> /smack/load = _ foo rwx
> Unlabeled process work fine.
> Labeled processes produce CIPSO labeled packets (which never get any 
> answer anywhere from the internet)
>
> If i set /smack/nltype to 'unlabled' i don't even get SYN packets out. 
> (operation not permitted)

That's probably a bug, but I think the "fix" is to disable the ability to
set the nltype to anything other than CIPSO at least for the time being.

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Casey Schaufler wrote:
> Tilman Baumann wrote:
>> Casey Schaufler wrote:
>> If I set /smack/nltype to 'unlabeled' I have effectively shut off the 
>> network.
>> I guess I'm missing some essential point here.
>> Sorry to bother you with such trivialities.
> 
> Not to worry. The essential point is that with MAC you can't just lock
> the doors, you have to lock the windows as well. What I mean by that is
> that traditional access controls apply to files, but not network
> communications. Network communications became popular in part because
> they were allowed to leave any restrictions up to the applications
> and their protocols. MAC requirements are pickier than that. The good
> news is that with a scheme like CIPSO you can easily enforce the
> policy. The bad news is that network services in general assume that
> there is no policy being enforced on them.

This might work well in trusted networks.
But Internet is untrusted and needs to work too. At least in the most 
real world scenarios. :)

>> If i set /smack/nltype to 'unlabled' i don't even get SYN packets out. 
>> (operation not permitted)
> 
> That's probably a bug, but I think the "fix" is to disable the ability to
> set the nltype to anything other than CIPSO at least for the time being.

Well, there is a case statement in smack_lsm.c that checks for the 
nltype (smack_net_nltype) and omits net labeling if cipso is not set.
This seems to be a very sensible thing to do. I strongly advice for a 
way to omit netlabel based access control.
As soon as you leave controlled and trusted networks, netlabels seem in 
my eyes like a maybe even critical information leak.

btw. I tried return 0; in smk_access(), but it did not make networking 
work again with nltype set to unlabled. So I guess the problem is not 
some access check.

If you have any idea how i can avoid any cipso labels on the network but 
use smack for local access control?
I don't try to secure information channels. Our system is a general 
purpose server, it would defeat the purpose of our system to lock it up 
since our clients are never going to use cipso.

I'm pretty sure the cipso labels are the problem. Since I can easily 
access resources in the local network. But things break when I access 
over Internet.
And I can not even expect this to work in any network where the system 
will be deployed.

-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Ahmed S. Darwish]

Hi Tilman,

On Mon, Oct 6, 2008 at 2:57 PM, Tilman Baumann
<tilman.baumann@collax.com> wrote:
> If I set /smack/nltype to 'unlabeled' I have effectively shut off the
>  network.
...
> This might work well in trusted networks.
> But Internet is untrusted and needs to work too. At least in the most real
> world scenarios. :)
>
> If i set /smack/nltype to 'unlabled' i don't even get SYN packets out.
> (operation not permitted)
>
> That's probably a bug, but I think the "fix" is to disable the ability to
> set the nltype to anything other than CIPSO at least for the time being.

Check this patch:
http://article.gmane.org/gmane.linux.network/95294/match=

As far as I can remember, it does exactly what you're asking for.
There have been some arguments against it, but at least you can get
the idea and _try_ to discuss/enhance it further.

Regards

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
> Casey Schaufler wrote:
>> Tilman Baumann wrote:
>>> Casey Schaufler wrote:
>>> If I set /smack/nltype to 'unlabeled' I have effectively shut off 
>>> the network.
>>> I guess I'm missing some essential point here.
>>> Sorry to bother you with such trivialities.
>>
>> Not to worry. The essential point is that with MAC you can't just lock
>> the doors, you have to lock the windows as well. What I mean by that is
>> that traditional access controls apply to files, but not network
>> communications. Network communications became popular in part because
>> they were allowed to leave any restrictions up to the applications
>> and their protocols. MAC requirements are pickier than that. The good
>> news is that with a scheme like CIPSO you can easily enforce the
>> policy. The bad news is that network services in general assume that
>> there is no policy being enforced on them.
>
> This might work well in trusted networks.
> But Internet is untrusted and needs to work too. At least in the most 
> real world scenarios. :)

Yes. I'm pretty close to convinced that it needs to be included as
part of the single-label host solution. Not that it can possibly be
excused in any real secure environment mind you.

>>> If i set /smack/nltype to 'unlabled' i don't even get SYN packets 
>>> out. (operation not permitted)
>>
>> That's probably a bug, but I think the "fix" is to disable the 
>> ability to
>> set the nltype to anything other than CIPSO at least for the time being.
>
> Well, there is a case statement in smack_lsm.c that checks for the 
> nltype (smack_net_nltype) and omits net labeling if cipso is not set.
> This seems to be a very sensible thing to do. I strongly advice for a 
> way to omit netlabel based access control.

Yes, I hear you.

> As soon as you leave controlled and trusted networks, netlabels seem 
> in my eyes like a maybe even critical information leak.
>
> btw. I tried return 0; in smk_access(), but it did not make networking 
> work again with nltype set to unlabled. So I guess the problem is not 
> some access check.
>
> If you have any idea how i can avoid any cipso labels on the network 
> but use smack for local access control?
> I don't try to secure information channels. Our system is a general 
> purpose server, it would defeat the purpose of our system to lock it 
> up since our clients are never going to use cipso.
>
> I'm pretty sure the cipso labels are the problem. Since I can easily 
> access resources in the local network. But things break when I access 
> over Internet.
> And I can not even expect this to work in any network where the system 
> will be deployed.
>

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Hi Casey,

the last weeks I tried to come up with some way to circumvent my 
problems by aimlessly poking around in the code. Did not work though. 
Not yet at least. :)
Maybe it makes more sense for me to wait until you have a solution.
My whole project is stalled right now because of this and I'm not sure 
what next.
Do you plan to change something there soon? If so I would stop wasting 
my time with hopeless attempts.

My problem is at the moment that I don't really know what to do. If you 
can give some aim I would be glad if I could do something.

Thanks

Casey Schaufler wrote:
> Tilman Baumann wrote:
>> Casey Schaufler wrote:
>>> Tilman Baumann wrote:
>> This might work well in trusted networks.
>> But Internet is untrusted and needs to work too. At least in the most 
>> real world scenarios. :)
> 
> Yes. I'm pretty close to convinced that it needs to be included as
> part of the single-label host solution. Not that it can possibly be
> excused in any real secure environment mind you.
> 
>>>> If i set /smack/nltype to 'unlabled' i don't even get SYN packets 
>>>> out. (operation not permitted)
>>>
>>> That's probably a bug, but I think the "fix" is to disable the 
>>> ability to
>>> set the nltype to anything other than CIPSO at least for the time being.
>>
>> Well, there is a case statement in smack_lsm.c that checks for the 
>> nltype (smack_net_nltype) and omits net labeling if cipso is not set.
>> This seems to be a very sensible thing to do. I strongly advice for a 
>> way to omit netlabel based access control.
> 
> Yes, I hear you.


-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
> Hi Casey,
>
> the last weeks I tried to come up with some way to circumvent my 
> problems by aimlessly poking around in the code. Did not work though. 
> Not yet at least. :)
> Maybe it makes more sense for me to wait until you have a solution.
> My whole project is stalled right now because of this and I'm not sure 
> what next.
> Do you plan to change something there soon? If so I would stop wasting 
> my time with hopeless attempts.
>
> My problem is at the moment that I don't really know what to do. If 
> you can give some aim I would be glad if I could do something.

Well, the good news is that I have a change under test that will address
your needs, allowing a host or set of hosts to be generally accessible
from the Smack system. The bad news is that it uses a set of netlabel
apis that are not going to get released in favor of a redesigned set of
apis which are not available yet. The good news is that those apis will
handle Smack's needs just fine, but again the bad news is that I don't
have them to use yet.

If you're up to trying out something that you know is going to get
rewhacked before it goes in anywhere let me know.

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Casey Schaufler wrote:
> Tilman Baumann wrote:
>> Hi Casey,
>>
>> the last weeks I tried to come up with some way to circumvent my 
>> problems by aimlessly poking around in the code. Did not work though. 
>> Not yet at least. :)
>> Maybe it makes more sense for me to wait until you have a solution.
>> My whole project is stalled right now because of this and I'm not sure 
>> what next.
>> Do you plan to change something there soon? If so I would stop wasting 
>> my time with hopeless attempts.
>>
>> My problem is at the moment that I don't really know what to do. If 
>> you can give some aim I would be glad if I could do something.
> 
> Well, the good news is that I have a change under test that will address
> your needs, allowing a host or set of hosts to be generally accessible
> from the Smack system. The bad news is that it uses a set of netlabel
> apis that are not going to get released in favor of a redesigned set of
> apis which are not available yet. The good news is that those apis will
> handle Smack's needs just fine, but again the bad news is that I don't
> have them to use yet.
> 
> If you're up to trying out something that you know is going to get
> rewhacked before it goes in anywhere let me know.

Sure. I will be happy to use that.
Just tell me where to find it and how to use it and what I should look 
out for.

-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
>> If you're up to trying out something that you know is going to get
>> rewhacked before it goes in anywhere let me know.
>
> Sure. I will be happy to use that.
> Just tell me where to find it and how to use it and what I should look 
> out for.
>
OK. I'll throw a patch together. It may take a day or two due
to the heap on my plate.

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Tilman Baumann wrote:
>> If you're up to trying out something that you know is going to get
>> rewhacked before it goes in anywhere let me know.
>
> Sure. I will be happy to use that.
> Just tell me where to find it and how to use it and what I should look 
> out for.
>

You'll need to start out with Paul Moore's testing tree:

% git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing

Apply the attached patch (attachments are discouraged for review purposes,
but this is handier for this purpose) and compile.

This is NOT production code. Again, we're hashing out the netlabel api and
we know that they are going to change. This is demo only. The amount of
testing it's gotten is really small.

I have created a new system label "@", pronounced "at" and referred to as
the internet label. Processes cannot be assigned the internet label. A
subject with the internet label (as identified by a packet thus labeled)
can write to any object and any subject can write to an object thus labeled,
thereby explicitly blowing a hole in the Access Control Policy.

Have fun, let me know what you hit next.

Thank you.




[-- Attachment #2: lblnet081021.patch --]
[-- Type: text/plain, Size: 30519 bytes --]

diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/include/net/netlabel.h lblnet-2.6-1011/include/net/netlabel.h
--- lblnet-2.6_testing/include/net/netlabel.h	2008-10-07 10:56:35.000000000 -0700
+++ lblnet-2.6-1011/include/net/netlabel.h	2008-10-11 06:31:40.000000000 -0700
@@ -356,6 +356,19 @@ static inline void netlbl_secattr_free(s
 int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
 int netlbl_cfg_unlbl_add_map(const char *domain,
 			     struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_fallback(struct net *net,
+				  const char *dev_name,
+				  const void *addr,
+				  const void *mask,
+				  u16 family,
+				  u32 secid,
+				  struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_del_fallback(struct net *net,
+				  const char *dev_name,
+				  const void *addr,
+				  const void *mask,
+				  u16 family,
+				  struct netlbl_audit *audit_info);
 int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
 			       const char *domain,
 			       struct netlbl_audit *audit_info);
@@ -412,6 +425,25 @@ static inline int netlbl_cfg_unlbl_add_m
 {
 	return -ENOSYS;
 }
+static inline int netlbl_cfg_unlbl_add_fallback(struct net *net,
+						const char *dev_name,
+						const void *addr,
+						const void *mask,
+						u16 family,
+						u32 secid,
+						struct netlbl_audit *audit_info)
+{
+	return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_del_fallback(struct net *net,
+						const char *dev_name,
+						const void *addr,
+						const void *mask,
+						u16 family,
+						struct netlbl_audit *audit_info)
+{
+	return -ENOSYS;
+}
 static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
 					     const char *domain,
 					     struct netlbl_audit *audit_info)
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/net/netlabel/netlabel_kapi.c lblnet-2.6-1011/net/netlabel/netlabel_kapi.c
--- lblnet-2.6_testing/net/netlabel/netlabel_kapi.c	2008-10-07 10:56:46.000000000 -0700
+++ lblnet-2.6-1011/net/netlabel/netlabel_kapi.c	2008-10-11 06:31:40.000000000 -0700
@@ -103,6 +103,92 @@ cfg_unlbl_add_map_failure:
 	return ret_val;
 }
 
+
+/**
+ * netlbl_cfg_unlbl_add_fallback - Adds a new fallback label
+ * @net: network namespace
+ * @dev_name: interface name
+ * @addr: IP address in network byte order (struct in[6]_addr)
+ * @mask: address mask in network byte order (struct in[6]_addr)
+ * @family: address family
+ * @secid: LSM secid value for the entry
+ * @audit_info: NetLabel audit information
+ *
+ * Description:
+ * Adds a new NetLabel static/fallback label to be used when protocol provided
+ * labels are not present on incoming traffic.  If @dev_name is NULL then the
+ * default interface will be used.  Returns zero on success, negative values on
+ * failure.
+ *
+ */
+int netlbl_cfg_unlbl_add_fallback(struct net *net,
+				  const char *dev_name,
+				  const void *addr,
+				  const void *mask,
+				  u16 family,
+				  u32 secid,
+				  struct netlbl_audit *audit_info)
+{
+	u32 addr_len;
+
+	switch (family) {
+	case AF_INET:
+		addr_len = 4;
+		break;
+	case AF_INET6:
+		addr_len = 16;
+		break;
+	default:
+		return -EPFNOSUPPORT;
+	}
+
+	return netlbl_unlhsh_add(net,
+				 dev_name, addr, mask, addr_len,
+				 secid, audit_info);
+}
+
+/**
+ * netlbl_cfg_unlbl_del_fallback - Removes an existing fallback label
+ * @net: network namespace
+ * @dev_name: interface name
+ * @addr: IP address in network byte order (struct in[6]_addr)
+ * @mask: address mask in network byte order (struct in[6]_addr)
+ * @family: address family
+ * @secid: LSM secid value for the entry
+ * @audit_info: NetLabel audit information
+ *
+ * Description:
+ * Removes an existing NetLabel static/fallback label used when protocol
+ * provided labels are not present on incoming traffic.  If @dev_name is NULL
+ * then the default interface will be used.  Returns zero on success, negative
+ * values on failure.
+ *
+ */
+int netlbl_cfg_unlbl_del_fallback(struct net *net,
+				  const char *dev_name,
+				  const void *addr,
+				  const void *mask,
+				  u16 family,
+				  struct netlbl_audit *audit_info)
+{
+	u32 addr_len;
+
+	switch (family) {
+	case AF_INET:
+		addr_len = 4;
+		break;
+	case AF_INET6:
+		addr_len = 16;
+		break;
+	default:
+		return -EPFNOSUPPORT;
+	}
+
+	return netlbl_unlhsh_remove(net,
+				    dev_name, addr, mask, addr_len,
+				    audit_info);
+}
+
 /**
  * netlbl_cfg_cipsov4_add_map - Add a new CIPSOv4 DOI definition and mapping
  * @doi_def: the DOI definition
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/net/netlabel/netlabel_unlabeled.c lblnet-2.6-1011/net/netlabel/netlabel_unlabeled.c
--- lblnet-2.6_testing/net/netlabel/netlabel_unlabeled.c	2008-10-07 10:56:46.000000000 -0700
+++ lblnet-2.6-1011/net/netlabel/netlabel_unlabeled.c	2008-10-11 06:31:40.000000000 -0700
@@ -450,13 +450,13 @@ add_iface_failure:
  * success, negative values on failure.
  *
  */
-static int netlbl_unlhsh_add(struct net *net,
-			     const char *dev_name,
-			     const void *addr,
-			     const void *mask,
-			     u32 addr_len,
-			     u32 secid,
-			     struct netlbl_audit *audit_info)
+int netlbl_unlhsh_add(struct net *net,
+		      const char *dev_name,
+		      const void *addr,
+		      const void *mask,
+		      u32 addr_len,
+		      u32 secid,
+		      struct netlbl_audit *audit_info)
 {
 	int ret_val;
 	int ifindex;
@@ -716,12 +716,12 @@ unlhsh_condremove_failure:
  * Returns zero on success, negative values on failure.
  *
  */
-static int netlbl_unlhsh_remove(struct net *net,
-				const char *dev_name,
-				const void *addr,
-				const void *mask,
-				u32 addr_len,
-				struct netlbl_audit *audit_info)
+int netlbl_unlhsh_remove(struct net *net,
+			 const char *dev_name,
+			 const void *addr,
+			 const void *mask,
+			 u32 addr_len,
+			 struct netlbl_audit *audit_info)
 {
 	int ret_val;
 	struct net_device *dev;
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/net/netlabel/netlabel_unlabeled.h lblnet-2.6-1011/net/netlabel/netlabel_unlabeled.h
--- lblnet-2.6_testing/net/netlabel/netlabel_unlabeled.h	2008-10-07 10:56:46.000000000 -0700
+++ lblnet-2.6-1011/net/netlabel/netlabel_unlabeled.h	2008-10-11 06:31:40.000000000 -0700
@@ -221,6 +221,21 @@ int netlbl_unlabel_genl_init(void);
 /* General Unlabeled init function */
 int netlbl_unlabel_init(u32 size);
 
+/* Static/Fallback label management functions */
+int netlbl_unlhsh_add(struct net *net,
+		      const char *dev_name,
+		      const void *addr,
+		      const void *mask,
+		      u32 addr_len,
+		      u32 secid,
+		      struct netlbl_audit *audit_info);
+int netlbl_unlhsh_remove(struct net *net,
+			 const char *dev_name,
+			 const void *addr,
+			 const void *mask,
+			 u32 addr_len,
+			 struct netlbl_audit *audit_info);
+
 /* Process Unlabeled incoming network packets */
 int netlbl_unlabel_getattr(const struct sk_buff *skb,
 			   u16 family,
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/security/smack/smack_access.c lblnet-2.6-1011/security/smack/smack_access.c
--- lblnet-2.6_testing/security/smack/smack_access.c	2008-10-07 10:56:47.000000000 -0700
+++ lblnet-2.6-1011/security/smack/smack_access.c	2008-10-11 06:31:40.000000000 -0700
@@ -57,7 +57,14 @@ struct smack_known smack_known_invalid =
 	.smk_cipso	= NULL,
 };
 
-struct smack_known *smack_known = &smack_known_invalid;
+struct smack_known smack_known_internet = {
+	.smk_next	= &smack_known_invalid,
+	.smk_known	= "@",
+	.smk_secid	= 7,
+	.smk_cipso	= NULL,
+};
+
+struct smack_known *smack_known = &smack_known_internet;
 
 /*
  * The initial value needs to be bigger than any of the
@@ -99,6 +106,16 @@ int smk_access(char *subject_label, char
 	    strcmp(subject_label, smack_known_star.smk_known) == 0)
 		return -EACCES;
 	/*
+	 * An internet object can be accessed by any subject.
+	 * Tasks cannot be assigned the internet label.
+	 * An internet subject can access any object.
+	 */
+	if (object_label == smack_known_internet.smk_known ||
+	    subject_label == smack_known_internet.smk_known ||
+	    strcmp(object_label, smack_known_internet.smk_known) == 0 ||
+	    strcmp(subject_label, smack_known_internet.smk_known) == 0)
+		return 0;
+	/*
 	 * A star object can be accessed by any subject.
 	 */
 	if (object_label == smack_known_star.smk_known ||
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/security/smack/smackfs.c lblnet-2.6-1011/security/smack/smackfs.c
--- lblnet-2.6_testing/security/smack/smackfs.c	2008-10-07 10:56:47.000000000 -0700
+++ lblnet-2.6-1011/security/smack/smackfs.c	2008-10-12 12:59:36.000000000 -0700
@@ -20,6 +20,7 @@
 #include <linux/vmalloc.h>
 #include <linux/security.h>
 #include <linux/mutex.h>
+#include <net/net_namespace.h>
 #include <net/netlabel.h>
 #include <net/cipso_ipv4.h>
 #include <linux/seq_file.h>
@@ -39,6 +40,8 @@ enum smk_inos {
 	SMK_DIRECT	= 6,	/* CIPSO level indicating direct label */
 	SMK_AMBIENT	= 7,	/* internet ambient label */
 	SMK_NLTYPE	= 8,	/* label scheme to use by default */
+	SMK_ONLYCAP	= 9,	/* the only "capable" label */
+	SMK_SLHOST	= 10,	/* single label hosts */
 };
 
 /*
@@ -47,6 +50,7 @@ enum smk_inos {
 static DEFINE_MUTEX(smack_list_lock);
 static DEFINE_MUTEX(smack_cipso_lock);
 static DEFINE_MUTEX(smack_ambient_lock);
+static DEFINE_MUTEX(smk_slhost_lock);
 
 /*
  * This is the "ambient" label for network traffic.
@@ -68,6 +72,23 @@ int smack_net_nltype = NETLBL_NLTYPE_CIP
  */
 int smack_cipso_direct = SMACK_CIPSO_DIRECT_DEFAULT;
 
+/*
+ * Unless a process is running with this label even
+ * having CAP_MAC_OVERRIDE isn't enough to grant
+ * privilege to violate MAC policy. If no label is
+ * designated (the NULL case) capabilities apply to
+ * everyone. It is expected that the hat (^) label
+ * will be used if any label is used.
+ */
+char *smack_onlycap;
+
+/*
+ * Certain IP addresses may be designated as single label hosts.
+ * Packets are sent there unlabeled, but only from tasks that
+ * can write to the specified label.
+ */
+struct smk_slhost *smack_slhosts;
+
 static int smk_cipso_doi_value = SMACK_CIPSO_DOI_DEFAULT;
 struct smk_list_entry *smack_list;
 
@@ -93,6 +114,13 @@ struct smk_list_entry *smack_list;
 #define SMK_ACCESSLEN (sizeof(SMK_ACCESS) - 1)
 #define SMK_LOADLEN   (SMK_LABELLEN + SMK_LABELLEN + SMK_ACCESSLEN)
 
+/*
+ * Values for parsing single label host rules
+ * "1.2.3.4 X"
+ * "192.168.138.129 abcdefghijklmnopqrstuvw"
+ */
+#define SMK_SLHOSTMIN	9
+#define SMK_SLHOSTMAX	39
 
 /*
  * Seq_file read operations for /smack/load
@@ -580,6 +608,196 @@ static const struct file_operations smk_
 	.release        = seq_release,
 };
 
+/*
+ * Seq_file read operations for /smack/slhost
+ */
+
+static void *slhost_seq_start(struct seq_file *s, loff_t *pos)
+{
+	if (*pos == SEQ_READ_FINISHED)
+		return NULL;
+
+	return smack_slhosts;
+}
+
+static void *slhost_seq_next(struct seq_file *s, void *v, loff_t *pos)
+{
+	struct smk_slhost *skp = ((struct smk_slhost *) v)->smk_next;
+
+	if (skp == NULL)
+		*pos = SEQ_READ_FINISHED;
+
+	return skp;
+}
+
+/*
+ * Print host/label pairs
+ */
+static int slhost_seq_show(struct seq_file *s, void *v)
+{
+	struct smk_slhost *skp = (struct smk_slhost *) v;
+	unsigned char *hp = (char *) &skp->smk_host.sin_addr.s_addr;
+
+	seq_printf(s, "%u.%u.%u.%u %s\n", hp[0], hp[1], hp[2], hp[3],
+		skp->smk_label);
+
+	return 0;
+}
+
+static void slhost_seq_stop(struct seq_file *s, void *v)
+{
+	/* No-op */
+}
+
+static struct seq_operations slhost_seq_ops = {
+	.start = slhost_seq_start,
+	.stop  = slhost_seq_stop,
+	.next  = slhost_seq_next,
+	.show  = slhost_seq_show,
+};
+
+/**
+ * smk_open_slhost - open() for /smack/slhost
+ * @inode: inode structure representing file
+ * @file: "slhost" file pointer
+ *
+ * Connect our slhost_seq_* operations with /smack/slhost
+ * file_operations
+ */
+static int smk_open_slhost(struct inode *inode, struct file *file)
+{
+	return seq_open(file, &slhost_seq_ops);
+}
+
+/**
+ * smk_write_slhost - write() for /smack/slhost
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Accepts only one slhost per write call.
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_slhost(struct file *file, const char __user *buf,
+				size_t count, loff_t *ppos)
+{
+	struct smk_slhost *skp;
+	struct sockaddr_in newname;
+	char smack[SMK_LABELLEN];
+	char *sp;
+	char data[SMK_SLHOSTMAX];
+	char *host = (char *)&newname.sin_addr.s_addr;
+	int rc;
+	int replace = 1;
+	struct netlbl_audit audit_info;
+	struct in_addr mask;
+	unsigned int m = 32;
+	__be32 bebits = 0x80000000;
+	__be32 nsa;
+
+	/*
+	 * Must have privilege.
+	 * No partial writes.
+	 * Enough data must be present.
+	 * "<addr, as a.b.c.d><space><label>"
+	 */
+	if (!capable(CAP_MAC_ADMIN))
+		return -EPERM;
+	if (*ppos != 0)
+		return -EINVAL;
+	if (count < SMK_SLHOSTMIN || count > SMK_SLHOSTMAX)
+		return -EINVAL;
+	if (copy_from_user(data, buf, count) != 0)
+		return -EFAULT;
+
+	data[count] = '\0';
+
+	rc = sscanf(data, "%hhd.%hhd.%hhd.%hhd/%d %s",
+		&host[0], &host[1], &host[2], &host[3], &m, smack);
+	if (rc != 6) {
+		rc = sscanf(data, "%hhd.%hhd.%hhd.%hhd %s",
+			&host[0], &host[1], &host[2], &host[3], smack);
+		if (rc != 5)
+			return -EINVAL;
+	}
+	if (m > 32)
+		return -EINVAL;
+
+	sp = smk_import(smack, 0);
+	if (sp == NULL)
+		return -EINVAL;
+
+	for (mask.s_addr = 0; m > 0; m--) {
+		mask.s_addr |= bebits;
+		bebits >>= 1;
+	}
+	/*
+	 * Only allow one writer at a time. Writes should be
+	 * quite rare and small in any case.
+	 */
+	mutex_lock(&smk_slhost_lock);
+
+	nsa = newname.sin_addr.s_addr;
+	for (skp = smack_slhosts; skp != NULL; skp = skp->smk_next)
+		if (skp->smk_host.sin_addr.s_addr == nsa &&
+		    skp->smk_mask.s_addr == mask.s_addr)
+			break;
+
+	/*
+	 * The else clause is necessary because the label must
+	 * be set before the entry is added to the list
+	 */
+	if (skp == NULL) {
+		skp = kzalloc(sizeof(*skp), GFP_KERNEL);
+		if (skp == NULL) {
+			rc = -ENOMEM;
+			goto out;
+		}
+		skp->smk_host.sin_addr.s_addr = newname.sin_addr.s_addr;
+		skp->smk_mask.s_addr = mask.s_addr;
+		skp->smk_next = smack_slhosts;
+		skp->smk_label = sp;
+		smack_slhosts = skp;
+		replace = 0;
+	} else
+		skp->smk_label = sp;
+
+	/*
+	 * Now tell netlabel about the single label nature of
+	 * this host so that incoming packets get labeled.
+	 */
+	audit_info.loginuid = audit_get_loginuid(current);
+	audit_info.sessionid = audit_get_sessionid(current);
+	audit_info.secid = smack_to_secid(current->security);
+
+	if (replace) {
+		rc = netlbl_cfg_unlbl_del_fallback(&init_net, NULL,
+			&skp->smk_host.sin_addr, &skp->smk_mask,
+			PF_INET, &audit_info);
+		if (rc != 0)
+			goto out;
+	}
+
+	rc = netlbl_cfg_unlbl_add_fallback(&init_net, NULL,
+		&skp->smk_host.sin_addr, &skp->smk_mask, PF_INET,
+		smack_to_secid(skp->smk_label), &audit_info);
+
+	if (rc == 0)
+		rc = count;
+out:
+	mutex_unlock(&smk_slhost_lock);
+	return rc;
+}
+
+static const struct file_operations smk_slhost_ops = {
+	.open           = smk_open_slhost,
+	.read		= seq_read,
+	.llseek         = seq_lseek,
+	.write		= smk_write_slhost,
+	.release        = seq_release,
+};
+
 /**
  * smk_read_doi - read() for /smack/doi
  * @filp: file pointer, not actually used
@@ -789,6 +1007,85 @@ static const struct file_operations smk_
 	.write		= smk_write_ambient,
 };
 
+/**
+ * smk_read_onlycap - read() for /smack/onlycap
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @cn: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ */
+static ssize_t smk_read_onlycap(struct file *filp, char __user *buf,
+				size_t cn, loff_t *ppos)
+{
+	char *smack = "";
+	ssize_t rc = -EINVAL;
+	int asize;
+
+	if (*ppos != 0)
+		return 0;
+
+	if (smack_onlycap != NULL)
+		smack = smack_onlycap;
+
+	asize = strlen(smack) + 1;
+
+	if (cn >= asize)
+		rc = simple_read_from_buffer(buf, cn, ppos, smack, asize);
+
+	return rc;
+}
+
+/**
+ * smk_write_onlycap - write() for /smack/onlycap
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_onlycap(struct file *file, const char __user *buf,
+				 size_t count, loff_t *ppos)
+{
+	char in[SMK_LABELLEN];
+	char *sp = current->security;
+
+	if (!capable(CAP_MAC_ADMIN))
+		return -EPERM;
+
+	/*
+	 * This can be done using smk_access() but is done
+	 * explicitly for clarity. The smk_access() implementation
+	 * would use smk_access(smack_onlycap, MAY_WRITE)
+	 */
+	if (smack_onlycap != NULL && smack_onlycap != sp)
+		return -EPERM;
+
+	if (count >= SMK_LABELLEN)
+		return -EINVAL;
+
+	if (copy_from_user(in, buf, count) != 0)
+		return -EFAULT;
+
+	/*
+	 * Should the null string be passed in unset the onlycap value.
+	 * This seems like something to be careful with as usually
+	 * smk_import only expects to return NULL for errors. It
+	 * is usually the case that a nullstring or "\n" would be
+	 * bad to pass to smk_import but in fact this is useful here.
+	 */
+	smack_onlycap = smk_import(in, count);
+
+	return count;
+}
+
+static const struct file_operations smk_onlycap_ops = {
+	.read		= smk_read_onlycap,
+	.write		= smk_write_onlycap,
+};
+
 struct option_names {
 	int	o_number;
 	char	*o_name;
@@ -921,6 +1218,10 @@ static int smk_fill_super(struct super_b
 			{"ambient", &smk_ambient_ops, S_IRUGO|S_IWUSR},
 		[SMK_NLTYPE]	=
 			{"nltype", &smk_nltype_ops, S_IRUGO|S_IWUSR},
+		[SMK_ONLYCAP]	=
+			{"onlycap", &smk_onlycap_ops, S_IRUGO|S_IWUSR},
+		[SMK_SLHOST]	=
+			{"slhost", &smk_slhost_ops, S_IRUGO|S_IWUSR},
 		/* last one */ {""}
 	};
 
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/security/smack/smack.h lblnet-2.6-1011/security/smack/smack.h
--- lblnet-2.6_testing/security/smack/smack.h	2008-10-07 10:56:47.000000000 -0700
+++ lblnet-2.6-1011/security/smack/smack.h	2008-10-12 06:17:19.000000000 -0700
@@ -16,6 +16,7 @@
 #include <linux/capability.h>
 #include <linux/spinlock.h>
 #include <linux/security.h>
+#include <linux/in.h>
 #include <net/netlabel.h>
 
 /*
@@ -39,6 +40,7 @@ struct superblock_smack {
 struct socket_smack {
 	char		*smk_out;			/* outbound label */
 	char		*smk_in;			/* inbound label */
+	int		smk_labeled;			/* label scheme */
 	char		smk_packet[SMK_LABELLEN];	/* TCP peer label */
 };
 
@@ -80,6 +82,16 @@ struct smack_cipso {
 };
 
 /*
+ * An entry in the table identifying single label hosts.
+ */
+struct smk_slhost {
+	struct smk_slhost	*smk_next;
+	struct sockaddr_in	smk_host;	/* network address */
+	struct in_addr		smk_mask;	/* network mask */
+	char			*smk_label;	/* label */
+};
+
+/*
  * This is the repository for labels seen so that it is
  * not necessary to keep allocating tiny chuncks of memory
  * and so that they can be shared.
@@ -127,7 +139,20 @@ struct smack_known {
 #define XATTR_NAME_SMACKIPOUT	XATTR_SECURITY_PREFIX XATTR_SMACK_IPOUT
 
 /*
- * smackfs macic number
+ * How communications on this socket are treated.
+ * Usually it's determined by the underlying netlabel code
+ * but there are certain cases, including single label hosts
+ * and potentially single label interfaces for which the
+ * treatment can not be known in advance.
+ *
+ * The possibility of additional labeling schemes being
+ * introduced in the future exists as well.
+ */
+#define SMACK_UNLABELED_SOCKET	0
+#define SMACK_CIPSO_SOCKET	1
+
+/*
+ * smackfs magic number
  */
 #define SMACK_MAGIC	0x43415d53 /* "SMAC" */
 
@@ -178,6 +203,7 @@ u32 smack_to_secid(const char *);
 extern int smack_cipso_direct;
 extern int smack_net_nltype;
 extern char *smack_net_ambient;
+extern char *smack_onlycap;
 
 extern struct smack_known *smack_known;
 extern struct smack_known smack_known_floor;
@@ -186,8 +212,10 @@ extern struct smack_known smack_known_hu
 extern struct smack_known smack_known_invalid;
 extern struct smack_known smack_known_star;
 extern struct smack_known smack_known_unset;
+extern struct smack_known smack_known_internet;
 
 extern struct smk_list_entry *smack_list;
+extern struct smk_slhost *smack_slhosts;
 extern struct security_operations smack_ops;
 
 /*
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/security/smack/smack_lsm.c lblnet-2.6-1011/security/smack/smack_lsm.c
--- lblnet-2.6_testing/security/smack/smack_lsm.c	2008-10-07 10:56:47.000000000 -0700
+++ lblnet-2.6-1011/security/smack/smack_lsm.c	2008-10-11 06:31:40.000000000 -0700
@@ -1232,6 +1232,7 @@ static int smack_sk_alloc_security(struc
 
 	ssp->smk_in = csp;
 	ssp->smk_out = csp;
+	ssp->smk_labeled = SMACK_CIPSO_SOCKET;
 	ssp->smk_packet[0] = '\0';
 
 	sk->sk_security = ssp;
@@ -1318,23 +1319,50 @@ static void smack_to_secattr(char *smack
 /**
  * smack_netlabel - Set the secattr on a socket
  * @sk: the socket
+ * @labeled: socket label scheme
  *
  * Convert the outbound smack value (smk_out) to a
  * secattr and attach it to the socket.
  *
  * Returns 0 on success or an error code
  */
-static int smack_netlabel(struct sock *sk)
+static int smack_netlabel(struct sock *sk, int labeled)
 {
 	struct socket_smack *ssp;
 	struct netlbl_lsm_secattr secattr;
-	int rc;
+	int rc = 0;
 
 	ssp = sk->sk_security;
-	netlbl_secattr_init(&secattr);
-	smack_to_secattr(ssp->smk_out, &secattr);
-	rc = netlbl_sock_setattr(sk, &secattr);
-	netlbl_secattr_destroy(&secattr);
+	/*
+	 * Usually the netlabel code will handle changing the
+	 * packet labeling based on the label.
+	 * The case of a single label host is different, because
+	 * a single label host should never get a labeled packet
+	 * even though the label is usually associated with a packet
+	 * label.
+	 */
+	local_bh_disable();
+	bh_lock_sock_nested(sk);
+
+	if (ssp->smk_out == smack_net_ambient ||
+	    labeled == SMACK_UNLABELED_SOCKET)
+		netlbl_sock_delattr(sk);
+	else {
+		netlbl_secattr_init(&secattr);
+		smack_to_secattr(ssp->smk_out, &secattr);
+		rc = netlbl_sock_setattr(sk, &secattr);
+		netlbl_secattr_destroy(&secattr);
+	}
+
+	bh_unlock_sock(sk);
+	local_bh_enable();
+	/*
+	 * Remember the label scheme used so that it is not
+	 * necessary to do the netlabel setting if it has not
+	 * changed the next time through.
+	 */
+	if (rc == 0)
+		ssp->smk_labeled = labeled;
 
 	return rc;
 }
@@ -1387,7 +1415,7 @@ static int smack_inode_setsecurity(struc
 		ssp->smk_in = sp;
 	else if (strcmp(name, XATTR_SMACK_IPOUT) == 0) {
 		ssp->smk_out = sp;
-		rc = smack_netlabel(sock->sk);
+		rc = smack_netlabel(sock->sk, SMACK_CIPSO_SOCKET);
 		if (rc != 0)
 			printk(KERN_WARNING "Smack: \"%s\" netlbl error %d.\n",
 			       __func__, -rc);
@@ -1417,7 +1445,69 @@ static int smack_socket_post_create(stru
 	/*
 	 * Set the outbound netlbl.
 	 */
-	return smack_netlabel(sock->sk);
+	return smack_netlabel(sock->sk, SMACK_CIPSO_SOCKET);
+}
+
+
+/**
+ * smack_host_label - check host based restrictions
+ * @sip: the object end
+ *
+ * looks for host based access restrictions
+ *
+ * Returns the label of the far end or NULL if it's not special.
+ */
+static char *smack_host_label(struct sockaddr_in *sip)
+{
+	struct smk_slhost *slp;
+
+	if (sip->sin_addr.s_addr == 0)
+		return NULL;
+
+	for (slp = smack_slhosts; slp != NULL; slp = slp->smk_next)
+		if (slp->smk_host.sin_addr.s_addr == sip->sin_addr.s_addr)
+			return slp->smk_label;
+
+	return NULL;
+}
+
+/**
+ * smack_socket_connect - connect access check
+ * @sock: the socket
+ * @sap: the other end
+ * @addrlen: size of sap
+ *
+ * Verifies that a connection may be possible
+ *
+ * Returns 0 on success, and error code otherwise
+ */
+static int smack_socket_connect(struct socket *sock, struct sockaddr *sap,
+				int addrlen)
+{
+	struct socket_smack *ssp = sock->sk->sk_security;
+	char *hostsp;
+	int rc;
+
+	if (sock->sk == NULL || sock->sk->sk_family != PF_INET)
+		return 0;
+
+	if (addrlen < sizeof(struct sockaddr_in))
+		return -EINVAL;
+
+	hostsp = smack_host_label((struct sockaddr_in *)sap);
+	if (hostsp == NULL) {
+		if (ssp->smk_labeled != SMACK_CIPSO_SOCKET)
+			return smack_netlabel(sock->sk, SMACK_CIPSO_SOCKET);
+		return 0;
+	}
+
+	rc = smk_access(ssp->smk_out, hostsp, MAY_WRITE);
+	if (rc != 0)
+		return rc;
+
+	if (ssp->smk_labeled != SMACK_UNLABELED_SOCKET)
+		return smack_netlabel(sock->sk, SMACK_UNLABELED_SOCKET);
+	return 0;
 }
 
 /**
@@ -2055,6 +2145,12 @@ static int smack_setprocattr(struct task
 	if (newsmack == NULL)
 		return -EINVAL;
 
+	/*
+	 * No process is ever allowed the internet ("@") label.
+	 */
+	if (newsmack == smack_known_internet.smk_known)
+		return -EPERM;
+
 	p->security = newsmack;
 	return size;
 }
@@ -2094,6 +2190,49 @@ static int smack_unix_may_send(struct so
 }
 
 /**
+ * smack_socket_sendmsg - Smack check based on destination host
+ * @sock: the socket
+ * @msghdr: the message
+ * @size: the size of the message
+ *
+ * Return 0 if the current subject can write to the destination
+ * host. This is only a question if the destination is a single
+ * label host.
+ */
+static int smack_socket_sendmsg(struct socket *sock, struct msghdr *msg,
+				int size)
+{
+	struct sockaddr_in *sip = (struct sockaddr_in *) msg->msg_name;
+	struct socket_smack *ssp = sock->sk->sk_security;
+	char *hostsp;
+	int rc;
+
+	/*
+	 * Perfectly reasonable for this to be NULL
+	 */
+	if (sip == NULL || sip->sin_family != PF_INET)
+		return 0;
+
+	hostsp = smack_host_label(sip);
+	if (hostsp == NULL) {
+		if (ssp->smk_labeled != SMACK_CIPSO_SOCKET)
+			return smack_netlabel(sock->sk, SMACK_CIPSO_SOCKET);
+		return 0;
+	}
+
+	rc = smk_access(ssp->smk_out, hostsp, MAY_WRITE);
+	if (rc != 0)
+		return rc;
+
+	if (ssp->smk_labeled != SMACK_UNLABELED_SOCKET)
+		return smack_netlabel(sock->sk, SMACK_UNLABELED_SOCKET);
+
+	return 0;
+
+}
+
+
+/**
  * smack_from_secattr - Convert a netlabel attr.mls.lvl/attr.mls.cat
  * 	pair to smack
  * @sap: netlabel secattr
@@ -2104,44 +2243,61 @@ static int smack_unix_may_send(struct so
 static void smack_from_secattr(struct netlbl_lsm_secattr *sap, char *sip)
 {
 	char smack[SMK_LABELLEN];
+	char *sp;
 	int pcat;
 
-	if ((sap->flags & NETLBL_SECATTR_MLS_LVL) == 0) {
+	if ((sap->flags & NETLBL_SECATTR_MLS_LVL) != 0) {
 		/*
-		 * If there are flags but no level netlabel isn't
-		 * behaving the way we expect it to.
+		 * Looks like a CIPSO packet.
 		 *
-		 * Without guidance regarding the smack value
-		 * for the packet fall back on the network
-		 * ambient value.
+		 * Get the categories, if any
 		 */
-		strncpy(sip, smack_net_ambient, SMK_MAXLEN);
+		memset(smack, '\0', SMK_LABELLEN);
+		if ((sap->flags & NETLBL_SECATTR_MLS_CAT) != 0)
+			for (pcat = -1;;) {
+				pcat = netlbl_secattr_catmap_walk(
+					sap->attr.mls.cat, pcat + 1);
+				if (pcat < 0)
+					break;
+				smack_catset_bit(pcat, smack);
+			}
+		/*
+		 * If it is CIPSO using smack direct mapping
+		 * we are already done. WeeHee.
+		 */
+		if (sap->attr.mls.lvl == smack_cipso_direct) {
+			memcpy(sip, smack, SMK_MAXLEN);
+			return;
+		}
+		/*
+		 * Look it up in the supplied table if it is not
+		 * a direct mapping.
+		 */
+		smack_from_cipso(sap->attr.mls.lvl, smack, sip);
 		return;
 	}
-	/*
-	 * Get the categories, if any
-	 */
-	memset(smack, '\0', SMK_LABELLEN);
-	if ((sap->flags & NETLBL_SECATTR_MLS_CAT) != 0)
-		for (pcat = -1;;) {
-			pcat = netlbl_secattr_catmap_walk(sap->attr.mls.cat,
-							  pcat + 1);
-			if (pcat < 0)
-				break;
-			smack_catset_bit(pcat, smack);
-		}
-	/*
-	 * If it is CIPSO using smack direct mapping
-	 * we are already done. WeeHee.
-	 */
-	if (sap->attr.mls.lvl == smack_cipso_direct) {
-		memcpy(sip, smack, SMK_MAXLEN);
+	if ((sap->flags & NETLBL_SECATTR_SECID) != 0) {
+		/*
+		 * Looks like a fallback, which gives us a secid.
+		 */
+		sp = smack_from_secid(sap->attr.secid);
+		/*
+		 * This has got to be a bug because it is
+		 * impossible to specify a fallback without
+		 * specifying the label, which will ensure
+		 * it has a secid, and the only way to get a
+		 * secid is from a fallback.
+		 */
+		BUG_ON(sp == NULL);
+		strncpy(sip, sp, SMK_MAXLEN);
 		return;
 	}
 	/*
-	 * Look it up in the supplied table if it is not a direct mapping.
+	 * Without guidance regarding the smack value
+	 * for the packet fall back on the network
+	 * ambient value.
 	 */
-	smack_from_cipso(sap->attr.mls.lvl, smack, sip);
+	strncpy(sip, smack_net_ambient, SMK_MAXLEN);
 	return;
 }
 
@@ -2157,6 +2313,7 @@ static int smack_socket_sock_rcv_skb(str
 	struct netlbl_lsm_secattr secattr;
 	struct socket_smack *ssp = sk->sk_security;
 	char smack[SMK_LABELLEN];
+	char *csp;
 	int rc;
 
 	if (sk->sk_family != PF_INET && sk->sk_family != PF_INET6)
@@ -2165,21 +2322,25 @@ static int smack_socket_sock_rcv_skb(str
 	/*
 	 * Translate what netlabel gave us.
 	 */
-	memset(smack, '\0', SMK_LABELLEN);
 	netlbl_secattr_init(&secattr);
+
 	rc = netlbl_skbuff_getattr(skb, sk->sk_family, &secattr);
-	if (rc == 0)
+	if (rc == 0) {
+		memset(smack, '\0', SMK_LABELLEN);
 		smack_from_secattr(&secattr, smack);
-	else
-		strncpy(smack, smack_net_ambient, SMK_MAXLEN);
+		csp = smack;
+	} else
+		csp = smack_net_ambient;
+
 	netlbl_secattr_destroy(&secattr);
+
 	/*
 	 * Receiving a packet requires that the other end
 	 * be able to write here. Read access is not required.
 	 * This is the simplist possible security model
 	 * for networking.
 	 */
-	rc = smk_access(smack, ssp->smk_in, MAY_WRITE);
+	rc = smk_access(csp, ssp->smk_in, MAY_WRITE);
 	if (rc != 0)
 		netlbl_skbuff_err(skb, rc, 0);
 	return rc;
@@ -2292,7 +2453,7 @@ static void smack_sock_graft(struct sock
 	ssp->smk_out = current->security;
 	ssp->smk_packet[0] = '\0';
 
-	rc = smack_netlabel(sk);
+	rc = smack_netlabel(sk, SMACK_CIPSO_SOCKET);
 	if (rc != 0)
 		printk(KERN_WARNING "Smack: \"%s\" netlbl error %d.\n",
 		       __func__, -rc);
@@ -2683,6 +2844,8 @@ struct security_operations smack_ops = {
 	.unix_may_send = 		smack_unix_may_send,
 
 	.socket_post_create = 		smack_socket_post_create,
+	.socket_connect =		smack_socket_connect,
+	.socket_sendmsg =		smack_socket_sendmsg,
 	.socket_sock_rcv_skb = 		smack_socket_sock_rcv_skb,
 	.socket_getpeersec_stream =	smack_socket_getpeersec_stream,
 	.socket_getpeersec_dgram =	smack_socket_getpeersec_dgram,

Re: SMACK netfilter smacklabel socket match

[Paul Moore]

On Friday 17 October 2008 1:53:38 pm Casey Schaufler wrote:
> Tilman Baumann wrote:
> > Hi Casey,
> >
> > the last weeks I tried to come up with some way to circumvent my
> > problems by aimlessly poking around in the code. Did not work
> > though. Not yet at least. :)
> > Maybe it makes more sense for me to wait until you have a solution.
> > My whole project is stalled right now because of this and I'm not
> > sure what next.
> > Do you plan to change something there soon? If so I would stop
> > wasting my time with hopeless attempts.
> >
> > My problem is at the moment that I don't really know what to do. If
> > you can give some aim I would be glad if I could do something.
>
> Well, the good news is that I have a change under test that will
> address your needs, allowing a host or set of hosts to be generally
> accessible from the Smack system. The bad news is that it uses a set
> of netlabel apis that are not going to get released in favor of a
> redesigned set of apis which are not available yet. The good news is
> that those apis will handle Smack's needs just fine, but again the
> bad news is that I don't have them to use yet.

Just a quick update.  You can blame me for the delay, I was a bit 
distracted trying to get things ready for the 2.6.28 merge window and 
the NetLabel kernel API changes got pushed aside for a few weeks.  I 
just sent Casey a draft patch of the new API bits to review; with any 
luck I'll have something to post as an RFC patch shortly.

Thanks for your patience.

-- 
paul moore
linux @ hp

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Casey Schaufler wrote:
> Tilman Baumann wrote:
>>> If you're up to trying out something that you know is going to get
>>> rewhacked before it goes in anywhere let me know.
>>
>> Sure. I will be happy to use that.
>> Just tell me where to find it and how to use it and what I should look 
>> out for.
>>
> 
> You'll need to start out with Paul Moore's testing tree:
> 
> % git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing
> 
> Apply the attached patch (attachments are discouraged for review purposes,
> but this is handier for this purpose) and compile.
> 
> This is NOT production code. Again, we're hashing out the netlabel api and
> we know that they are going to change. This is demo only. The amount of
> testing it's gotten is really small.
> 
> I have created a new system label "@", pronounced "at" and referred to as
> the internet label. Processes cannot be assigned the internet label. A
> subject with the internet label (as identified by a packet thus labeled)
> can write to any object and any subject can write to an object thus 
> labeled,
> thereby explicitly blowing a hole in the Access Control Policy.
> 
> Have fun, let me know what you hit next.

Sorry for the long delay. I was annoyingly occupied with other things.

I just tried this out. But one thing makes me wonder if I had understood 
what it should do.
The syntax for /smack/slhost is IP[/MASK] LABEL.
When I give one host (in my case generously 0.0.0.0/0 *g*) a label what 
is the significance of the @ label?
First I used the _ label here which had the effect that everything seems 
  to work but labeled processes still produced labeled packet which got 
slaughtered in different ways and degrees over the internet.
If I gave my slhost the @ label my machine was offline and did not even 
get pings out locally.

I get the feeling I did not understand the concept yet.
Sorry but if you don't mind giving me a hint...

-- 
Tilman Baumann
Software Developer
Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

p: +49 (0) 89-990157-0
f: +49 (0) 89-990157-11

Geschaeftsfuehrer: William K. Hite / Boris Nalbach
AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
>
>
> Casey Schaufler wrote:
>> Tilman Baumann wrote:
>>>> If you're up to trying out something that you know is going to get
>>>> rewhacked before it goes in anywhere let me know.
>>>
>>> Sure. I will be happy to use that.
>>> Just tell me where to find it and how to use it and what I should 
>>> look out for.
>>>
>>
>> You'll need to start out with Paul Moore's testing tree:
>>
>> % git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing
>>
>> Apply the attached patch (attachments are discouraged for review 
>> purposes,
>> but this is handier for this purpose) and compile.
>>
>> This is NOT production code. Again, we're hashing out the netlabel 
>> api and
>> we know that they are going to change. This is demo only. The amount of
>> testing it's gotten is really small.
>>
>> I have created a new system label "@", pronounced "at" and referred 
>> to as
>> the internet label. Processes cannot be assigned the internet label. A
>> subject with the internet label (as identified by a packet thus labeled)
>> can write to any object and any subject can write to an object thus 
>> labeled,
>> thereby explicitly blowing a hole in the Access Control Policy.
>>
>> Have fun, let me know what you hit next.
>
> Sorry for the long delay. I was annoyingly occupied with other things.
>
> I just tried this out. But one thing makes me wonder if I had 
> understood what it should do.
> The syntax for /smack/slhost is IP[/MASK] LABEL.

OK, I made a mistake here. The syntax will allow for a mask soon, but
the code I passed along only supports IP addresses, not ranges. For
your case you'll need to have an entry for each of the three hosts.

> When I give one host (in my case generously 0.0.0.0/0 *g*) a label 
> what is the significance of the @ label?
> First I used the _ label here which had the effect that everything 
> seems  to work but labeled processes still produced labeled packet 
> which got slaughtered in different ways and degrees over the internet.
> If I gave my slhost the @ label my machine was offline and did not 
> even get pings out locally.
>

I don't think that I've passed along the patch that supports "@" yet.
I'm hoping to give it a little bit of test before it goes out. Sorry
that I seem to have given you the impression that it should work
already.

> I get the feeling I did not understand the concept yet.
> Sorry but if you don't mind giving me a hint...

Now where's the fun in giving out hints? (smiley goes here)

The idea behind the "@" label is that there are a class of people who
don't trust the other processes on their machine, but who are willing to
trust anything so long as it comes off the network. Further, anything that
they put on the network is inherently worthy of trust. Somehow this does
not match my personal notions, but it is a common request.

So, a packet labeled "@" will be delivered to any socket. A single-label
host at "@" will accept packets from anyone. It's a wild-card, no holds 
barred,
laze fair approach to networking that makes no sense whatsoever from a
security standpoint but that everyone seems to believe is necessary.

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
>
>
> Casey Schaufler wrote:
>> Tilman Baumann wrote:
>>>> If you're up to trying out something that you know is going to get
>>>> rewhacked before it goes in anywhere let me know.
>>>
>>> Sure. I will be happy to use that.
>>> Just tell me where to find it and how to use it and what I should 
>>> look out for.
>>>
>>
>> You'll need to start out with Paul Moore's testing tree:
>>
>> % git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing
>>
>> Apply the attached patch (attachments are discouraged for review 
>> purposes,
>> but this is handier for this purpose) and compile.
>>
>> This is NOT production code. Again, we're hashing out the netlabel 
>> api and
>> we know that they are going to change. This is demo only. The amount of
>> testing it's gotten is really small.
>>
>> I have created a new system label "@", pronounced "at" and referred 
>> to as
>> the internet label. Processes cannot be assigned the internet label. A
>> subject with the internet label (as identified by a packet thus labeled)
>> can write to any object and any subject can write to an object thus 
>> labeled,
>> thereby explicitly blowing a hole in the Access Control Policy.
>>
>> Have fun, let me know what you hit next.
>
> Sorry for the long delay. I was annoyingly occupied with other things.

My turn!

>
> I just tried this out. But one thing makes me wonder if I had 
> understood what it should do.
> The syntax for /smack/slhost is IP[/MASK] LABEL.
> When I give one host (in my case generously 0.0.0.0/0 *g*) a label 
> what is the significance of the @ label?
> First I used the _ label here which had the effect that everything 
> seems  to work but labeled processes still produced labeled packet 
> which got slaughtered in different ways and degrees over the internet.
> If I gave my slhost the @ label my machine was offline and did not 
> even get pings out locally.
>
> I get the feeling I did not understand the concept yet.
> Sorry but if you don't mind giving me a hint...
>

OK, Paul and I knocked our heads together until we got the behavior and
interfaces ironed out if not to our mutual satisfaction at least to a
workable level. Paul's next tree:

    % git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_next

has the current version. There are a couple interesting things going on.

    - /smack/nltype is gone. It never lived up to its promise and is no
      longer required to determine the labeling scheme.
    - /smack/netlabel replaces the earlier /smack/slhost because it better
      describes what it gets used for.
    - The "@" label (pronounced "web") has been added to the list of special
      labels. A packet with the web label will get delivered anywhere. A
      network address specified to have the web label can be written to by
      any process. Processes can not have the web label.
    - An incoming packet from an address in the netlabel list that has a 
CIPSO
      label attached will still use the label from the CIPSO packet.
    - An unlabeled packet coming from an address in the netlabel list 
will be
      given the label associated with that address.
    - A process that wants to send a packet to an address on the list needs
      write access to the label associated with that address. The packet 
will
      be sent unlabeled if it is allowed.

So, if I want my old Sony to be treated as a single-label host with the
label "Pop" I can say:

    # echo 192.168.1.102/32 Pop > /smack/netlabel

If I want the secondary network for my development machines to be 
single-label

    # echo 192.168.2.0/24 Snap > /smack/netlabel

And if I want everyone to be able to communicate with my spam server

    # echo 207.69.188.187 '@' > /smack/netlabel

Re: SMACK netfilter smacklabel socket match

[Tilman Baumann]

Am 11.12.2008 um 01:03 schrieb Casey Schaufler:

>
>>
>> I just tried this out. But one thing makes me wonder if I had  
>> understood what it should do.
>> The syntax for /smack/slhost is IP[/MASK] LABEL.
>> When I give one host (in my case generously 0.0.0.0/0 *g*) a label  
>> what is the significance of the @ label?
>> First I used the _ label here which had the effect that everything  
>> seems  to work but labeled processes still produced labeled packet  
>> which got slaughtered in different ways and degrees over the  
>> internet.
>> If I gave my slhost the @ label my machine was offline and did not  
>> even get pings out locally.
>>
>> I get the feeling I did not understand the concept yet.
>> Sorry but if you don't mind giving me a hint...
>>
>
> OK, Paul and I knocked our heads together until we got the behavior  
> and
> interfaces ironed out if not to our mutual satisfaction at least to a
> workable level. Paul's next tree:
>
>   % git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_next

Nice, I'm eager to try that out.

>
>
> has the current version. There are a couple interesting things going  
> on.
>
>   - /smack/nltype is gone. It never lived up to its promise and is no
>     longer required to determine the labeling scheme.
>   - /smack/netlabel replaces the earlier /smack/slhost because it  
> better
>     describes what it gets used for.
>   - The "@" label (pronounced "web") has been added to the list of  
> special
>     labels. A packet with the web label will get delivered anywhere. A
>     network address specified to have the web label can be written  
> to by
>     any process. Processes can not have the web label.
>   - An incoming packet from an address in the netlabel list that has  
> a CIPSO
>     label attached will still use the label from the CIPSO packet.
>   - An unlabeled packet coming from an address in the netlabel list  
> will be
>     given the label associated with that address.
>   - A process that wants to send a packet to an address on the list  
> needs
>     write access to the label associated with that address. The  
> packet will
>     be sent unlabeled if it is allowed.
>
>

I guess the question will be, can the /smack/netlabel network also be  
0.0.0.0/0?
I know, that's not how it was meant to be used, but that's what would
solve my problems with outgoing labeled packets.

However, I will try this out...
Thanks

Regards
  Tilman

Re: SMACK netfilter smacklabel socket match

[Casey Schaufler]

Tilman Baumann wrote:
>
> Am 11.12.2008 um 01:03 schrieb Casey Schaufler:
>
>>
>>>
>>> I just tried this out. But one thing makes me wonder if I had 
>>> understood what it should do.
>>> The syntax for /smack/slhost is IP[/MASK] LABEL.
>>> When I give one host (in my case generously 0.0.0.0/0 *g*) a label 
>>> what is the significance of the @ label?
>>> First I used the _ label here which had the effect that everything 
>>> seems  to work but labeled processes still produced labeled packet 
>>> which got slaughtered in different ways and degrees over the internet.
>>> If I gave my slhost the @ label my machine was offline and did not 
>>> even get pings out locally.
>>>
>>> I get the feeling I did not understand the concept yet.
>>> Sorry but if you don't mind giving me a hint...
>>>
>>
>> OK, Paul and I knocked our heads together until we got the behavior and
>> interfaces ironed out if not to our mutual satisfaction at least to a
>> workable level. Paul's next tree:
>>
>>   % git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_next
>
> Nice, I'm eager to try that out.
>
>>
>>
>> has the current version. There are a couple interesting things going on.
>>
>>   - /smack/nltype is gone. It never lived up to its promise and is no
>>     longer required to determine the labeling scheme.
>>   - /smack/netlabel replaces the earlier /smack/slhost because it better
>>     describes what it gets used for.
>>   - The "@" label (pronounced "web") has been added to the list of 
>> special
>>     labels. A packet with the web label will get delivered anywhere. A
>>     network address specified to have the web label can be written to by
>>     any process. Processes can not have the web label.
>>   - An incoming packet from an address in the netlabel list that has 
>> a CIPSO
>>     label attached will still use the label from the CIPSO packet.
>>   - An unlabeled packet coming from an address in the netlabel list 
>> will be
>>     given the label associated with that address.
>>   - A process that wants to send a packet to an address on the list 
>> needs
>>     write access to the label associated with that address. The 
>> packet will
>>     be sent unlabeled if it is allowed.
>>
>>
>
> I guess the question will be, can the /smack/netlabel network also be 
> 0.0.0.0/0?

Yes. If you want all internet domain sockets to be unlabeled and
accessible to all:

    # echo 0.0.0.0/0 '@' > /smack/netlabel

I have tested this some, but not to the extent I've done on what I
expect to be the more normal cases. Please let me know how well the
current behavior fits what you want to accomplish. We aims to please.

> I know, that's not how it was meant to be used, but that's what would
> solve my problems with outgoing labeled packets.
>
> However, I will try this out...
> Thanks

Thank you. I'm eager to hear your next set of questions.