From: Lorenzo Hernández García-Hierro <hidden> Date: 2005-01-28 18:34:58
El vie, 28-01-2005 a las 10:02 -0800, Stephen Hemminger escribió:
quoted
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can be implemented
without a development or maintenance overhead, aka less-invasive
implementations.
It adds support for advanced networking-related randomization, in
concrete it adds support for TCP ISNs randomization, RPC XIDs
randomization, IP IDs randomization and finally a sub-key under the
Cryptographic options menu for Linux PRNG [2] enhancements (useful now
and also for future patch submissions), which currently has an only-one
option for poll sizes increasing (x2).
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
so-called system fingerprinting (which is used most by "kids" to know
how old and insecure could be a target system, many time used as the
first, even only-one, data to decide if attack or not the target host)
among other things.
There's only a missing feature that is present on grSecurity, the
sources ports randomization which seems achieved now by some changes
that can be checked out in the Linux BKBits repository:
http://linux.bkbits.net:8080/linux-2.6/diffs/net/ipv4/tcp_ipv4.c@1.105?nav=index.html|src/|src/net|src/net/ipv4|hist/net/ipv4/tcp_ipv4.c
(net/ipv4/tcp_ipv4.c@1.105)
I'm not sure of the effectiveness of that changes, but I just prefer to
keep it as most simple as possible.If there are thoughts on reverting to
the old schema, and using obsd_rand.c code instead, just drop me a line
and I will modify the patch.
Okay, but:
* Need to give better explanation of why this is required,
existing randomization code in network is compromise between
performance and security. So you need to quantify the performance
impact of this, and the security threat reduction.
Performance impact is none AFAIK.
I've explained them in an early reply to Adrian [1].
* Why are the OpenBSD random functions better? because they have more
security coolness factor?
I'm not an OpenBSD user, and no intention to being a one.
I just recognize that the functions do the same job better, as explained
in the Kconfig diffs.
* It is hard to have two levels of security based on config options.
Think of a distro vendor, do they ship the fast or the secure system??
As always:
* Send networking stuff to netdev@oss.sgi.com
Added to CC list.
* Please split up patches.
If you talk about removing the pool sizes increasing, then i will do it,
but i would like to know if this has any chances to get merged.
[1]: http://lkml.org/lkml/2005/1/28/139
Cheers,
--
Lorenzo Hernández García-Hierro [off-list ref]
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
From: Stephen Hemminger <hidden> Date: 2005-01-28 18:59:28
On Fri, 28 Jan 2005 19:31:50 +0100
L
quoted
Okay, but:
* Need to give better explanation of why this is required,
existing randomization code in network is compromise between
performance and security. So you need to quantify the performance
impact of this, and the security threat reduction.
Performance impact is none AFAIK.
I've explained them in an early reply to Adrian [1].
When I did the port randomization patch the benchmark that was most impacted
was LMBENCH. The biggest change was in the communications latency results.
If you want, you can sign up for a free access to OSDL test machines
and use STP to run lmbench and easily get before/after results.
1. Go to osdl.org and get associate account http://osdl.org/join_form
2. Submit patch to Patch Lifecycle Manager http://osdl.org/plm-cgi/plm
3. Choose test to run Scalable Test Platform (STP)
http://osdl.org/lab_activities/kernel_testing/stp/
--
Stephen Hemminger [off-list ref]
From: Lorenzo Hernández García-Hierro <hidden> Date: 2005-01-28 19:03:44
El vie, 28-01-2005 a las 10:52 -0800, Stephen Hemminger escribió:
On Fri, 28 Jan 2005 19:31:50 +0100
When I did the port randomization patch the benchmark that was most impacted
was LMBENCH. The biggest change was in the communications latency results.
If you want, you can sign up for a free access to OSDL test machines
and use STP to run lmbench and easily get before/after results.
1. Go to osdl.org and get associate account http://osdl.org/join_form
2. Submit patch to Patch Lifecycle Manager http://osdl.org/plm-cgi/plm
3. Choose test to run Scalable Test Platform (STP)
http://osdl.org/lab_activities/kernel_testing/stp/
OK, many thanks.
Haven't noticed that (maybe 'cos I'm new in kernel hacking ;) )
I will submit there the new patch ASAP.
Cheers,
--
Lorenzo Hernández García-Hierro [off-list ref]
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
From: Lorenzo Hernández García-Hierro <hidden> Date: 2005-01-28 20:46:58
Hi,
Attached the new patch following Arjan's recommendations.
I'm sorry about not making it "inlined", but my mail agent messes up the
diffs if I do so.
Still waiting for the OSDL STP tests results, they will take a while to
finish.
Cheers,
--
Lorenzo Hernández García-Hierro [off-list ref]
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
From: Arjan van de Ven <hidden> Date: 2005-01-28 20:56:16
On Fri, 2005-01-28 at 21:34 +0100, Lorenzo Hernández García-Hierro
wrote:
Hi,
Attached the new patch following Arjan's recommendations.
I'm sorry about not making it "inlined", but my mail agent messes up the
diffs if I do so.
Still waiting for the OSDL STP tests results, they will take a while to
finish.
Cheers,
lots better already! Some more comments (now that the patch got a lot
easier to read :)
static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct
sk_buff *skb)
{
- return secure_tcp_sequence_number(skb->nh.iph->daddr,
- skb->nh.iph->saddr,
- skb->h.th->dest,
- skb->h.th->source);
+
+ return ip_randomisn();
}
is there a reason for the weird indentation?
+ if (!tp->write_seq) {
+ tp->write_seq = ip_randomisn();
+ }
spare { } pare that's not needed, also looks like one tab too many
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
I still don't understand why you need a obsd_rand.c and can't use the
normal random.c
static inline u32 xprt_alloc_xid(struct rpc_xprt *xprt)
{
- return xprt->xid++;
+ /* Return randomized xprt->xid instead of prt->xid++ */
+ return (u32) obsd_get_random_long();
+
}
that cast looks quite redundant...
From: Lorenzo Hernández García-Hierro <hidden> Date: 2005-01-28 22:13:44
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribió:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
As seen at
http://www.kernel.org/pub/linux/kernel/people/arjan/execshield/00-randomize-A0 you can suppose that there's no point to use that, we can easily maintain the functions at obsd_rand.c so we wouldn't need to add more maintenance overhead, I hope you can understand why I want it like that and not depending on random.c in more than the function exports (which make it even more independent as we don't need to use our proper header and add each proper include entry in the modified files, as most of them use or have already random.h included).
Attached you can find the new patch with the indentation fixes.
The tests on the patch are the following ones:
http://www.osdl.org/plm-cgi/plm?module=patch_info&patch_id=4136
(above one shows that there are no SMP-related issues)
http://khack.osdl.org/stp/300417http://khack.osdl.org/stp/300420
Cheers and thanks for the information,
--
Lorenzo Hernández García-Hierro [off-list ref]
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
From: Arjan van de Ven <hidden> Date: 2005-01-29 08:04:53
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernández García-Hierro
wrote:
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribió:
quoted
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
From: Arjan van de Ven <hidden> Date: 2005-01-29 08:05:58
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernández García-Hierro
wrote:
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribió:
quoted
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
As seen at
the functions at obsd_rand.c so we wouldn't need to add more maintenance overhead, I hope you can understand why I want it like that
I actually DON'T understand that.
What you say kinda sorta makes sense if you're an external patch. But if
you are inside the kernel (that was the goal of this patch, right?) then
the argument is actually entirely the wrong way around...
From: "David S. Miller" <davem@davemloft.net> Date: 2005-01-28 20:59:14
On Fri, 28 Jan 2005 21:34:52 +0100
Lorenzo Hernández García-Hierro [off-list ref] wrote:
Attached the new patch following Arjan's recommendations.
No SMP protection on the SBOX, better look into that.
The locking you'll likely need to add will make this
routine serialize many networking operations which is
one thing we've been trying to avoid.
From: Stephen Hemminger <hidden> Date: 2005-01-28 21:34:06
On Fri, 28 Jan 2005 12:45:17 -0800
"David S. Miller" [off-list ref] wrote:
On Fri, 28 Jan 2005 21:34:52 +0100
Lorenzo Hernández García-Hierro [off-list ref] wrote:
quoted
Attached the new patch following Arjan's recommendations.
No SMP protection on the SBOX, better look into that.
The locking you'll likely need to add will make this
routine serialize many networking operations which is
one thing we've been trying to avoid.
per-cpu would be the way to go here.
--
Stephen Hemminger [off-list ref]