1 |
Marco Venutti пишет: |
2 |
|
3 |
> It's a fact OpenBSD is a secure OS so, |
4 |
|
5 |
No OS is secure, unfortunately. |
6 |
|
7 |
> if we put a OBSD-box online, we have |
8 |
> good chance it won't compromised, so |
9 |
> my question is the following: |
10 |
|
11 |
If the OpenBSD box would host something insecure (like WordPress), then |
12 |
expect it will be compromised. |
13 |
|
14 |
> "Is it possible to obtain, approximately, |
15 |
> a Linux-box secure as an OBSD-box?" |
16 |
|
17 |
In some cases you could obtain even more security. Approximately. ;) |
18 |
|
19 |
> My intention is, surely, not to provocate, |
20 |
> but to understand the actual state-of-art |
21 |
> of Linux security. |
22 |
|
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. |
27 |
|
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) |
32 |
|
33 |
Salesmen can sound good - it's a part of their job. |
34 |
|
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. |
38 |
|
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. |
44 |
|
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. |
47 |
|
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? |
51 |
|
52 |
A server without PaX is barely a better choice. |
53 |
|
54 |
> In the end, after long time tuning |
55 |
> do, these tools, grant us an high level security? |
56 |
|
57 |
These tools are only a part of the solution. But they can help very |
58 |
much, of cource. |
59 |
|
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. |
63 |
|
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. |
72 |
|
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. |
81 |
|
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. ;) |
88 |
|
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. |
96 |
|
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. |
100 |
|
101 |
> Recently I've read something about a 2.6.30 bug |
102 |
> which makes useless, enforcement like SELinux, |
103 |
> AppArmor and so on... |
104 |
|
105 |
...and which is non-exploitable on kernels with PaX. :) |
106 |
|
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. |
111 |
|
112 |
Linux and OpenBSD can't be compared directly. |
113 |
|
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. |
117 |
|
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. |
123 |
|
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. |
130 |
|
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: |
135 |
http://www.grsecurity.net/~spender/ |
136 |
|
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: |
140 |
|
141 |
http://www.cr0.org/misc/obsdretf.asm - PoC exploit by Julien Tinnes |
142 |
http://marc.info/?l=openbsd-cvs&m=113710599901750 - commit of the fix |
143 |
|
144 |
Not kind of way one may expect from supposedly well-documented system |
145 |
that supposedly stands for Full-Disclosure. |
146 |
|
147 |
Also, you could read this: |
148 |
|
149 |
http://www.coresecurity.com/content/open-bsd-advisorie |
150 |
|
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. |
154 |
|
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. |
159 |
|
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. |