Re: [RFC] SECMARK 1.1
James Morris wrote: On Mon, 15 May 2006, Patrick McHardy wrote: This will load the conntrack modules even if the track flag is not set. I guess need_conntrack() could be moved to checkentry() and only called if the track flag is set. That won't help, the function itself does nothing, its just a symbol dependency. Not sure what you mean: it will cause ip_conntrack to be loaded, which is needed when you specify the track flag. Yes, but the reason why it is loaded is because the module loader needs to resolve the symbol, not because of anything done at module runtime. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
On Mon, 15 May 2006, Patrick McHardy wrote: Not sure what you mean: it will cause ip_conntrack to be loaded, which is needed when you specify the track flag. Yes, but the reason why it is loaded is because the module loader needs to resolve the symbol, not because of anything done at module runtime. Am I missing something? This is what I want to happen. If you specify SECMARK --track, ip_conntrack is to be loaded. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
James Morris wrote:
On Mon, 15 May 2006, Patrick McHardy wrote:
Not sure what you mean: it will cause ip_conntrack to be loaded, which
is needed when you specify the track flag.
Yes, but the reason why it is loaded is because the module loader needs
to resolve the symbol, not because of anything done at module runtime.
Am I missing something? This is what I want to happen. If you specify
SECMARK --track, ip_conntrack is to be loaded.
But if you don't specify --track, the module loader will still have to
resolve the symbol, so it gets loaded anyway, before your code will
even run. Just look at need_conntrack():
/* Some modules need us, but don't depend directly on any symbol.
They should call this. */
void need_conntrack(void)
{
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
On Mon, 15 May 2006, Patrick McHardy wrote: But if you don't specify --track, the module loader will still have to resolve the symbol, so it gets loaded anyway, before your code will even run. Just look at need_conntrack(): Doh. It should be try_module_get(). Sound ok? - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
On Mon, 15 May 2006, James Morris wrote: Doh. It should be try_module_get(). Sound ok? Of course, I mean request_module(). -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
James Morris wrote: On Mon, 15 May 2006, Patrick McHardy wrote: But if you don't specify --track, the module loader will still have to resolve the symbol, so it gets loaded anyway, before your code will even run. Just look at need_conntrack(): Doh. It should be try_module_get(). Sound ok? try_module_get already needs a module reference, so this won't work either. As far as I can tell the only thing you can do besides putting it in a seperate module is to manually call request_module(). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
On Sun, 2006-05-14 at 02:03 -0400, James Morris wrote:
Included below is an incremental patch against the initial secmark posting
last week: http://thread.gmane.org/gmane.linux.network/34927/focus=34927
This posting to gather feedback on changes made since then primarily to
address concerns raised by Karl MacMillan on providing fine-grained
assurances for network applications which pass connections (e.g. xinetd).
If all looks ok, I'll rebase the entire patchset (also merging elements
from the patch below back into other patches), and submit it for inclusion
in 2.6.18. As it touches a bunch of networking code, it may be best to
aim for Dave's tree, although it could also go into -mm.
Anyway, the way the issue has been addressed is to implement something
similar to CONNMARK, but specific to this useage scenario and dealing with
security markings instead of network markings.
In a nutshell:
1. A --track option was added to the SECMARK target, which causes the
security mark being applied to the packet to also be applied to a new
secmark field on the conntrack (only if it is unmarked).
2. A new CONNSECMARK target was added which copies the secmark value to
packets.
This allows all packets on a connection (or related to it) to be marked
with the same security label, so that they can be explicitly
differentiated.
This also turns out to simplify the SELinux policy, while the xtables
implementation has been designed to remain as simple as possible (e.g. it
only copies lables to packets, and has no options).
So, here's an example of per-packet network policy for vsftpd with the new
code:
allow ftpd_t ftpd_packet_t:packet { recv send };
Assuming it doesn't do DNS lookups, that's it in terms of access control
rules for packets. This covers all established and related packets,
including ICMP and the FTP data connetion.
James,
This seems to address my concerns - thanks.
Karl
--
Karl MacMillan
Tresys Technology
www.tresys.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] SECMARK 1.1
Included below is an incremental patch against the initial secmark posting
last week: http://thread.gmane.org/gmane.linux.network/34927/focus=34927
This posting to gather feedback on changes made since then primarily to
address concerns raised by Karl MacMillan on providing fine-grained
assurances for network applications which pass connections (e.g. xinetd).
If all looks ok, I'll rebase the entire patchset (also merging elements
from the patch below back into other patches), and submit it for inclusion
in 2.6.18. As it touches a bunch of networking code, it may be best to
aim for Dave's tree, although it could also go into -mm.
Anyway, the way the issue has been addressed is to implement something
similar to CONNMARK, but specific to this useage scenario and dealing with
security markings instead of network markings.
In a nutshell:
1. A --track option was added to the SECMARK target, which causes the
security mark being applied to the packet to also be applied to a new
secmark field on the conntrack (only if it is unmarked).
2. A new CONNSECMARK target was added which copies the secmark value to
packets.
This allows all packets on a connection (or related to it) to be marked
with the same security label, so that they can be explicitly
differentiated.
This also turns out to simplify the SELinux policy, while the xtables
implementation has been designed to remain as simple as possible (e.g. it
only copies lables to packets, and has no options).
So, here's an example of per-packet network policy for vsftpd with the new
code:
allow ftpd_t ftpd_packet_t:packet { recv send };
Assuming it doesn't do DNS lookups, that's it in terms of access control
rules for packets. This covers all established and related packets,
including ICMP and the FTP data connetion.
(see the full policy at
http://people.redhat.com/jmorris/selinux/secmark/policy/ftpd_tracked/ftpd_tracked.te)
In terms of iptables rules, the only real change is that we need to add
CONNSECMARK rules for all incoming and outgoing packets (assuming you want
this for all services, otherwise, use iptables selectors to apply
CONNSECMARK on a per-service basis). Here's an example for the above:
#
# Accept incoming connections, label SYN packets, and copy
# labels to connections.
#
$IPT -A SEL_INPUT -p tcp --dport 21 -m state --state NEW -j SEL_FTPD
$IPT -A SEL_FTPD -j SECMARK --selctx system_u:object_r:ftpd_packet_t:s0 --track
$IPT -A SEL_FTPD -j ACCEPT
#
# Copy connection labels to established and related packets.
#
$IPT -A SEL_INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK
$IPT -A SEL_OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK
It should be easy to modularize the iptables rules and distribute them
with policy modules, and I'd recommend always generating them with some
script or macro.
Everything needed to get this running (including iptables patches) is at:
http://people.redhat.com/jmorris/selinux/secmark/
I've also added a patch at the site which adds a kernel boot param to
determine whether to use the old or new packet controls, although I'm
still not sure whether it's justified adding this stuff to the kernel when
it can be set at runtime during early boot.
Please review and let me know if there any further issues.
Signed-off-by: James Morris [EMAIL PROTECTED]
---
include/linux/netfilter/xt_SECMARK.h |7 +-
include/linux/netfilter_ipv4/ip_conntrack.h |4 +
include/net/netfilter/nf_conntrack.h |4 +
include/net/netfilter/nf_conntrack_compat.h | 26 +++
net/ipv4/netfilter/Kconfig | 10 ++
net/ipv4/netfilter/ip_conntrack_core.c |3
net/ipv4/netfilter/ip_conntrack_standalone.c |5 +
net/netfilter/Kconfig| 20 +
net/netfilter/Makefile |1
net/netfilter/nf_conntrack_core.c|3
net/netfilter/nf_conntrack_standalone.c |5 +
net/netfilter/xt_CONNSECMARK.c | 93 +++
net/netfilter/xt_SECMARK.c | 45 -
13 files changed, 224 insertions(+), 2 deletions(-)
diff -purN -X dontdiff
linux-2.6.17-rc3-git7.p/include/linux/netfilter/xt_SECMARK.h
linux-2.6.17-rc3-git7.w/include/linux/netfilter/xt_SECMARK.h
--- linux-2.6.17-rc3-git7.p/include/linux/netfilter/xt_SECMARK.h
2006-05-13 15:15:29.0 -0400
+++ linux-2.6.17-rc3-git7.w/include/linux/netfilter/xt_SECMARK.h
2006-05-10 18:20:50.0 -0400
@@ -7,6 +7,10 @@
*
* 'mode' refers to the specific security subsystem which the
* packets are being marked for.
+ *
+ * The 'track' flag is used to request that the security marking also be
+ * applied to the associated conntrack, if the conntrack is not labeled
+ * already.
*/
#define SECMARK_MODE_SEL 0x01/* SELinux */
#define SECMARK_SELCTX_MAX 256
@@ -17,7 +21,8 @@ struct xt_secmark_target_selinux_info {
};
Re: [RFC] SECMARK 1.1
James Morris wrote:
@@ -135,6 +175,9 @@ static int __init xt_secmark_init(void)
{
int err;
+ if (tracking_enabled())
+ need_conntrack();
+
This will load the conntrack modules even if the track flag is not set.
Wouldn't it be better to put everything related to connection marking
in the CONNSECMARK target?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
On Sun, 14 May 2006, Patrick McHardy wrote:
James Morris wrote:
@@ -135,6 +175,9 @@ static int __init xt_secmark_init(void)
{
int err;
+ if (tracking_enabled())
+ need_conntrack();
+
This will load the conntrack modules even if the track flag is not set.
I guess need_conntrack() could be moved to checkentry() and only called
if the track flag is set.
Wouldn't it be better to put everything related to connection marking
in the CONNSECMARK target?
It's more efficient this way, and simpler to manage.
Currently, after security marking, the chain should normally terminate
with a -j ACCEPT. Requiring the use of CONNSECMARK to label connections
means inserting another rule before terminating the chain.
Also, security marking for connections only occurs in the context of
copying the security mark from packets, so there's no reason to build a
general feature to do this into CONNSECMARK.
Another possibility would be to get rid of CONNSECMARK completely and have
SECMARK copy security marks from connections to packets via the use of a
different flag (perhaps change --track into --save-state and then have
--restore-state, or similar).
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
James Morris wrote:
On Sun, 14 May 2006, Patrick McHardy wrote:
James Morris wrote:
@@ -135,6 +175,9 @@ static int __init xt_secmark_init(void)
{
int err;
+if (tracking_enabled())
+need_conntrack();
+
This will load the conntrack modules even if the track flag is not set.
I guess need_conntrack() could be moved to checkentry() and only called
if the track flag is set.
That won't help, the function itself does nothing, its just a symbol
dependency.
Wouldn't it be better to put everything related to connection marking
in the CONNSECMARK target?
It's more efficient this way, and simpler to manage.
Currently, after security marking, the chain should normally terminate
with a -j ACCEPT. Requiring the use of CONNSECMARK to label connections
means inserting another rule before terminating the chain.
Also, security marking for connections only occurs in the context of
copying the security mark from packets, so there's no reason to build a
general feature to do this into CONNSECMARK.
Another possibility would be to get rid of CONNSECMARK completely and have
SECMARK copy security marks from connections to packets via the use of a
different flag (perhaps change --track into --save-state and then have
--restore-state, or similar).
The reason why I'm asking is because my understanding is that SECMARK
would also be useful without conntrack, but automatically pulling in
the module leaves no option not to use conntrack except not to compile
this part in.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.1
On Mon, 15 May 2006, Patrick McHardy wrote: This will load the conntrack modules even if the track flag is not set. I guess need_conntrack() could be moved to checkentry() and only called if the track flag is set. That won't help, the function itself does nothing, its just a symbol dependency. Not sure what you mean: it will cause ip_conntrack to be loaded, which is needed when you specify the track flag. Another possibility would be to get rid of CONNSECMARK completely and have SECMARK copy security marks from connections to packets via the use of a different flag (perhaps change --track into --save-state and then have --restore-state, or similar). The reason why I'm asking is because my understanding is that SECMARK would also be useful without conntrack, Yes. but automatically pulling in the module leaves no option not to use conntrack except not to compile this part in. Conntrack will only be loaded if someone uses SECMARK --track, which is exactly what is desired. Without --track, conntrack will not be loaded by SECMARK. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
