Re: [RFC] security: add iptables "security" table for MAC rules
On Tuesday 29 January 2008 7:43:11 pm James Morris wrote: > On Tue, 29 Jan 2008, Paul Moore wrote: > > That seems reasonable. By the way, this isn't really related, but is it > > possible to change the NF_IP_PRI_SELINUX_* constants to > > NF_IP_PRI_SECURITY_* for the sake of consistency or are those values > > already visible to userspace? > > They are visible to userspace, and included in glibc headers, but I don't > see any userland use of them via google codesearch or know of a possible > valid use. > > > I suppose we could always rename them anyway and just add a #define for > > compatibility ... > > Yep, if you want to. Hey, let's not forget I'm the guy that gets into arguments over names that span months :) I think it's a worthwhile change, but only once we have a reason to do so. In my mind this means either another user (not unlikely considering recent events) or something like you are proposing. I'll keep my eyes peeled and throw a patch out when I see an opportunity. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] security: add iptables "security" table for MAC rules
On Tue, 29 Jan 2008, Paul Moore wrote: > That seems reasonable. By the way, this isn't really related, but is it > possible to change the NF_IP_PRI_SELINUX_* constants to NF_IP_PRI_SECURITY_* > for the sake of consistency or are those values already visible to userspace? > They are visible to userspace, and included in glibc headers, but I don't see any userland use of them via google codesearch or know of a possible valid use. > I suppose we could always rename them anyway and just add a #define for > compatibility ... Yep, if you want to. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] security: add iptables "security" table for MAC rules
On Tuesday 29 January 2008 3:51:55 pm James Morris wrote: > On Tue, 29 Jan 2008, Paul Moore wrote: > > I'm not sure if returning false and failing here is the best thing to do > > in terms of backwards compatibility. I think we need some grace period > > where we print a warning message and still allow the operation; after > > some period of time we can then remove the ability completely and force > > users to use the new "security" table. > > Currently, the patch allows the use of the mangle table, so it is > backwards compatible. Okay, nevermind then, I must have misread your patch. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] security: add iptables "security" table for MAC rules
On Tue, 29 Jan 2008, Paul Moore wrote: > I'm not sure if returning false and failing here is the best thing to do in > terms of backwards compatibility. I think we need some grace period where we > print a warning message and still allow the operation; after some period of > time we can then remove the ability completely and force users to use the > new "security" table. Currently, the patch allows the use of the mangle table, so it is backwards compatible. -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] security: add iptables "security" table for MAC rules
On Tuesday 29 January 2008 6:44:15 am James Morris wrote:
> The following patch implements a new "security" table for iptables, so
> that MAC (SELinux etc.) networking rules can be managed separately to
> standard DAC rules.
>
> This is to help with distro integration of the new secmark-based network
> controls, per various previous discussions.
>
> The need for a separate table arises from the fact that existing tools and
> usage of iptables will likely clash with centralized MAC policy
> management.
We've talked about this before, and the more I think about it, the more I
believe it is a good idea.
> The SECMARK and CONNSECMARK targets will still be valid in the mangle
> table, to prevent breakage of existing users, although I suspect that
> these targets are not in significant use and we could probably make them
> valid only in the security table without major issues. (Comments?)
See my comment below, I'm not sure we can block the use of [CONN]SECMARK in
the mangle table without some grace period. I can't imagine this would cause
any problems, but I'm not really well versed yet in the connection tracking
stuff.
> I've set the table priority to just after NF_IP_FILTER, to allow DAC
> rules to take effect before MAC rules.
That seems reasonable. By the way, this isn't really related, but is it
possible to change the NF_IP_PRI_SELINUX_* constants to NF_IP_PRI_SECURITY_*
for the sake of consistency or are those values already visible to userspace?
I suppose we could always rename them anyway and just add a #define for
compatibility ...
> There is also not (yet) any LSM hooking for modifying the MAC rules, as it
> will be more invasive, and we have coarse coverage via CAP_NET_ADMIN.
> (Comments?)
While LSM hooks for netfilter operations are probably a good thing, I see them
as a separate task and I think they should be discussed separately. We
already have SECMARK labeling without additional netfilter LSM hooks so
implementing a new netfilter table for SECMARK shouldn't be a regression in
this sense.
> diff --git a/net/netfilter/xt_SECMARK.c b/net/netfilter/xt_SECMARK.c
> index 235806e..7c92d87 100644
> --- a/net/netfilter/xt_SECMARK.c
> +++ b/net/netfilter/xt_SECMARK.c
> @@ -5,7 +5,7 @@
> * Based on the nfmark match by:
> * (C) 1999-2001 Marc Boucher <[EMAIL PROTECTED]>
> *
> - * (C) 2006 Red Hat, Inc., James Morris <[EMAIL PROTECTED]>
> + * (C) 2006,2008 Red Hat, Inc., James Morris <[EMAIL PROTECTED]>
> *
> * 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
> @@ -87,6 +87,12 @@ static bool checkentry(const char *tablename, const void
> *entry, {
> struct xt_secmark_target_info *info = targinfo;
>
> + if (strcmp(tablename, "mangle") && strcmp(tablename, "security")) {
> + printk(KERN_INFO PFX "target only valid in the \'mangle\' "
> +"or \'security\' tables, not \'%s\'.\n", tablename);
> + return false;
> + }
> +
I'm not sure if returning false and failing here is the best thing to do in
terms of backwards compatibility. I think we need some grace period where we
print a warning message and still allow the operation; after some period of
time we can then remove the ability completely and force users to use the
new "security" table.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] security: add iptables "security" table for MAC rules
The following patch implements a new "security" table for iptables, so
that MAC (SELinux etc.) networking rules can be managed separately to
standard DAC rules.
This is to help with distro integration of the new secmark-based network
controls, per various previous discussions.
The need for a separate table arises from the fact that existing tools and
usage of iptables will likely clash with centralized MAC policy
management.
The SECMARK and CONNSECMARK targets will still be valid in the mangle
table, to prevent breakage of existing users, although I suspect that
these targets are not in significant use and we could probably make them
valid only in the security table without major issues. (Comments?)
I've set the table priority to just after NF_IP_FILTER, to allow DAC
rules to take effect before MAC rules.
There is also not (yet) any LSM hooking for modifying the MAC rules, as it
will be more invasive, and we have coarse coverage via CAP_NET_ADMIN.
(Comments?)
IPv6 is not done yet as this is just at RFC stage.
Please review and let me know if this looks like a viable approach for
distro integration. If it is, we will then need to run it past the
Netfilter & netdev folk.
---
Add a "security" table to iptables for managing Mandatory Access
Control (MAC) rules. This is intended for use with the SECMARK
and CONNSECMARK targets.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
include/linux/netfilter_ipv4.h|1 +
net/ipv4/netfilter/Kconfig| 10 ++
net/ipv4/netfilter/Makefile |1 +
net/ipv4/netfilter/iptable_security.c | 181 +
net/netfilter/xt_CONNSECMARK.c| 10 ++-
net/netfilter/xt_SECMARK.c| 10 ++-
6 files changed, 207 insertions(+), 6 deletions(-)
create mode 100644 net/ipv4/netfilter/iptable_security.c
diff --git a/include/linux/netfilter_ipv4.h b/include/linux/netfilter_ipv4.h
index 1a63adf..aec8961 100644
--- a/include/linux/netfilter_ipv4.h
+++ b/include/linux/netfilter_ipv4.h
@@ -60,6 +60,7 @@ enum nf_ip_hook_priorities {
NF_IP_PRI_MANGLE = -150,
NF_IP_PRI_NAT_DST = -100,
NF_IP_PRI_FILTER = 0,
+ NF_IP_PRI_SECURITY = 50,
NF_IP_PRI_NAT_SRC = 100,
NF_IP_PRI_SELINUX_LAST = 225,
NF_IP_PRI_CONNTRACK_HELPER = INT_MAX - 2,
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
index 9aca9c5..84d0d31 100644
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -373,6 +373,16 @@ config IP_NF_RAW
If you want to compile it as a module, say M here and read
. If unsure, say `N'.
+# security table for MAC policy
+config IP_NF_SECURITY
+ tristate "Security table"
+ depends on IP_NF_IPTABLES
+ help
+ This option adds a `security' table to iptables, for use
+ with Mandatory Access Control (MAC) policy.
+
+ If unsure, say N.
+
# ARP tables
config IP_NF_ARPTABLES
tristate "ARP tables support"
diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile
index 7456833..90fcdd6 100644
--- a/net/ipv4/netfilter/Makefile
+++ b/net/ipv4/netfilter/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_IP_NF_FILTER) += iptable_filter.o
obj-$(CONFIG_IP_NF_MANGLE) += iptable_mangle.o
obj-$(CONFIG_NF_NAT) += iptable_nat.o
obj-$(CONFIG_IP_NF_RAW) += iptable_raw.o
+obj-$(CONFIG_IP_NF_SECURITY) += iptable_security.o
# matches
obj-$(CONFIG_IP_NF_MATCH_ADDRTYPE) += ipt_addrtype.o
diff --git a/net/ipv4/netfilter/iptable_security.c
b/net/ipv4/netfilter/iptable_security.c
new file mode 100644
index 000..640f200
--- /dev/null
+++ b/net/ipv4/netfilter/iptable_security.c
@@ -0,0 +1,181 @@
+/*
+ * "security" table
+ *
+ * This is for use by Mandatory Access Control (MAC) security models,
+ * which need to be able to manage security policy in separate context
+ * to DAC.
+ *
+ * Based on iptable_mangle.c
+ *
+ * Copyright (C) 1999 Paul `Rusty' Russell & Michael J. Neuling
+ * Copyright (C) 2000-2004 Netfilter Core Team <[EMAIL PROTECTED]>
+ * Copyright (C) 2008 Red Hat, Inc., James Morris <[EMAIL PROTECTED]>
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("James Morris <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("iptables security table, for MAC rules");
+
+#define SECURITY_VALID_HOOKS (1 << NF_IP_LOCAL_IN) | \
+ (1 << NF_IP_FORWARD) | \
+ (1 << NF_IP_LOCAL_OUT)
+
+static struct
+{
+ struct ipt_replace repl;
+ struct ipt_standard entries[3];
+ struct ipt_error term;
+} initial_table __initdata = {
+ .repl = {
+ .name = "security",
+ .valid_hooks = SECURITY_VALID_H
