Gentoo Archives: gentoo-hardened

From: Pavel Labushev <p.labushev@×××××.com>
To: gentoo-hardened@l.g.o
Subject: Re: [gentoo-hardened] "How hard" is Linux kernel-side hardening?
Date: Mon, 21 Sep 2009 04:36:56
In Reply to: [gentoo-hardened] "How hard" is Linux kernel-side hardening? by Marco Venutti
1 Marco Venutti пишет:
3 > It's a fact OpenBSD is a secure OS so,
5 No OS is secure, unfortunately.
7 > if we put a OBSD-box online, we have
8 > good chance it won't compromised, so
9 > my question is the following:
11 If the OpenBSD box would host something insecure (like WordPress), then
12 expect it will be compromised.
14 > "Is it possible to obtain, approximately,
15 > a Linux-box secure as an OBSD-box?"
17 In some cases you could obtain even more security. Approximately. ;)
19 > My intention is, surely, not to provocate,
20 > but to understand the actual state-of-art
21 > of Linux security.
23 The Linux Kernel project is, in fact, following the Non-Disclosure
24 policy these days. Quality of the code is poor: the more bugs, the more
25 vulnerabilities. And it seems like most of the mainline kernel
26 developers don't care much about security.
28 > SELinux is included in the vanilla,
29 > this sounds good, but mastering
30 > SELinux is a long run
31 > (a lot of time to invest in it)
33 Salesmen can sound good - it's a part of their job.
35 > Since I like increased restriction to /proc /tmp and so on,
36 > and I appreciate randomisation goodies, this leads me to
37 > look at RSBAC and GR-Security, in fact both have these features.
39 Remember that RSBAC does not work with PaX on a recent kernels. If you
40 really want more security with Linux, PaX is the first and the most
41 important thing you should consider. It aims to prevent exploits from
42 working, while MAC/RBAC/RSBAC fights the consequences in userspace and
43 does little to protect against the kernel exploits.
45 Another more vulnerability in the kernel disclosed every month - this is
46 _the_ problem. In the light of that, HIDS and HIPS are secondary.
48 > If I've understood correctly GR-Security could
49 > be the best choice for desktop and RSBAC the
50 > best choice for server...isn't it?
52 A server without PaX is barely a better choice.
54 > In the end, after long time tuning
55 > do, these tools, grant us an high level security?
57 These tools are only a part of the solution. But they can help very
58 much, of cource.
60 You should choose what you use and pay attention to not so obvious
61 supposed attack vectors and try to understand and accept the risks -
62 sometimes you can't do more about that.
64 For example, D-Bus and alike IPC-on-top-of-IPC channels are common for
65 desktops. So if your policy allows access to D-Bus sockets for some
66 dbus-enabled application, expect any such application, being
67 compromised, would use D-Bus to attack another such applications,
68 including the privileged HAL daemon, your email client, your file
69 manager and so on. And there's no reliable way to "tune" this kind of
70 IPC: it's mostly about to block all or to allow all... Or to choose
71 another tool that does not depend on D-Bus and alike.
73 Speaking of the "alike" part... Look at the X11 server: it's privileged,
74 it's complicated (buggy, vulnerable), it provides shared user interface
75 and "userspace" IPC. So an attacker could try to compromise the X11
76 server itself, could do keylogging, screenlogging, GUI spoofing, or
77 could try to attack another X11 clients by forging the user input.
78 There's nothing you can do about it with MAC/RBAC/RSBAC, and there's no
79 "Grsecurity and PaX for X11" things out there. But you can understand
80 the risks and do something to minimize the potential harm.
82 Often offline backups of important data are good for a start. If your
83 job relies heavily on security of your box where you watch youtube, read
84 email and open attachments and so on, then buy another box. :P Don't
85 install adobe flash and all other crap on it, don't surf irrelevant
86 websites, don't open email attachments, or even don't read email on that
87 box at all. :) And so on. Then let your job rely on security of that box. ;)
89 > I mean:
90 > Grsecurity had suffered of a return into libc exploit
91 > that bypassed its protection. Grsecurity had also
92 > a PaX-disabled bug in the past that expose
93 > machines to risks.
94 >
95 > I heard RSBAC had problem with the jail solidity etc.
97 Nothing is perfect. And remember that Grsecurity and PaX are orthogonal.
98 If you are interested, you should read the documentation on PaX and
99 Grsecurity, or even ask spender and PaX Team directly for the details.
101 > Recently I've read something about a 2.6.30 bug
102 > which makes useless, enforcement like SELinux,
103 > AppArmor and so on...
105 ...and which is non-exploitable on kernels with PaX. :)
107 > so I'm wondering if it is possible to harden Linux
108 > the way you can leave it online with, approximately,
109 > the same (high) probability, it won't be compromised
110 > as OpenBSD does.
112 Linux and OpenBSD can't be compared directly.
114 OpenBSD kernel is less buggy and, if it can be said so, less vulnerable
115 by quantity (while, of cource, OpenBSD guys would say "It's by quality!"
116 :). In short: it's harder to find vulnerabilities in OpenBSD.
118 Linux kernel with PaX and Grsecurity is still more buggy (because of the
119 Linux part :), but got strong kernel protection that works against the
120 whole classes of kernel exploits. So it is less vulnerable by quality
121 (but still is more buggy). In short: it's harder to exploit
122 vulnerabilities in Linux kernel with Grsecurity and PaX.
124 OpenBSD got weakier overall userspace protection: less random bits in
125 ASLR, no mprotect() restrictions, no protection against bruteforcing the
126 prefork model's ASLR/SSP, no IPC restrictions, no capabilities
127 revocation, no reliable HIDS and HIPS (don't take abandoned systrace
128 seriously), no MAC or RBAC. Maybe something else significant - ask
129 spender and PaX Team, they know better.
131 Hardened Gentoo with hardened kernels have stronger overall userspace
132 protection and get security updates more quickly than OpenBSD ports
133 system... While there are some problems with keeping hardened-sources up
134 to date in Portage. ;) So you better use kernel patches from here:
137 Also, there's no documentation for all these OpenBSD exploit mitigation
138 techiques. And there were issues with W^X that OpenBSD developers
139 prefered to fix with no word about its impact on security:
141 - PoC exploit by Julien Tinnes
142 - commit of the fix
144 Not kind of way one may expect from supposedly well-documented system
145 that supposedly stands for Full-Disclosure.
147 Also, you could read this:
151 ...and see that OpenBSD developers expressed not that much of interest
152 in digging even obviously security-related bugs in their kernel. Kind of
153 controversional to what they say about code audit.
155 > I'm sure there are many skilled people, reading
156 > this mailing list, so I'll appreciate if someone
157 > will be patient and will enlighten me, giving some
158 > impartial inputs on what to study in my spare time.
160 Well, I'm not the skilled one. The men behind Hardened Gentoo,
161 Grsecurity and PaX seem to keep silence, so I decided to reply. You may
162 be interested in contacting them directly and/or search google for
163 conversations between PaX Team or spender and linux kernel developers -
164 it's very interesting and informative.


Subject Author
Re: [gentoo-hardened] "How hard" is Linux kernel-side hardening? "Javier J. Martínez Cabezón" <tazok.id0@×××××.com>
Re: [gentoo-hardened] "How hard" is Linux kernel-side hardening? Marco Venutti <veeenrg@×××××.com>