p.labushev at gmail
Sep 20, 2009, 9:35 PM
Post #9 of 18
(1868 views)
Permalink
|
|
Re: "How hard" is Linux kernel-side hardening?
[In reply to]
|
|
Marco Venutti пишет:
> It's a fact OpenBSD is a secure OS so,
No OS is secure, unfortunately.
> if we put a OBSD-box online, we have
> good chance it won't compromised, so
> my question is the following:
If the OpenBSD box would host something insecure (like WordPress), then
expect it will be compromised.
> "Is it possible to obtain, approximately,
> a Linux-box secure as an OBSD-box?"
In some cases you could obtain even more security. Approximately. ;)
> My intention is, surely, not to provocate,
> but to understand the actual state-of-art
> of Linux security.
The Linux Kernel project is, in fact, following the Non-Disclosure
policy these days. Quality of the code is poor: the more bugs, the more
vulnerabilities. And it seems like most of the mainline kernel
developers don't care much about security.
> SELinux is included in the vanilla,
> this sounds good, but mastering
> SELinux is a long run
> (a lot of time to invest in it)
Salesmen can sound good - it's a part of their job.
> Since I like increased restriction to /proc /tmp and so on,
> and I appreciate randomisation goodies, this leads me to
> look at RSBAC and GR-Security, in fact both have these features.
Remember that RSBAC does not work with PaX on a recent kernels. If you
really want more security with Linux, PaX is the first and the most
important thing you should consider. It aims to prevent exploits from
working, while MAC/RBAC/RSBAC fights the consequences in userspace and
does little to protect against the kernel exploits.
Another more vulnerability in the kernel disclosed every month - this is
_the_ problem. In the light of that, HIDS and HIPS are secondary.
> If I've understood correctly GR-Security could
> be the best choice for desktop and RSBAC the
> best choice for server...isn't it?
A server without PaX is barely a better choice.
> In the end, after long time tuning
> do, these tools, grant us an high level security?
These tools are only a part of the solution. But they can help very
much, of cource.
You should choose what you use and pay attention to not so obvious
supposed attack vectors and try to understand and accept the risks -
sometimes you can't do more about that.
For example, D-Bus and alike IPC-on-top-of-IPC channels are common for
desktops. So if your policy allows access to D-Bus sockets for some
dbus-enabled application, expect any such application, being
compromised, would use D-Bus to attack another such applications,
including the privileged HAL daemon, your email client, your file
manager and so on. And there's no reliable way to "tune" this kind of
IPC: it's mostly about to block all or to allow all... Or to choose
another tool that does not depend on D-Bus and alike.
Speaking of the "alike" part... Look at the X11 server: it's privileged,
it's complicated (buggy, vulnerable), it provides shared user interface
and "userspace" IPC. So an attacker could try to compromise the X11
server itself, could do keylogging, screenlogging, GUI spoofing, or
could try to attack another X11 clients by forging the user input.
There's nothing you can do about it with MAC/RBAC/RSBAC, and there's no
"Grsecurity and PaX for X11" things out there. But you can understand
the risks and do something to minimize the potential harm.
Often offline backups of important data are good for a start. If your
job relies heavily on security of your box where you watch youtube, read
email and open attachments and so on, then buy another box. :P Don't
install adobe flash and all other crap on it, don't surf irrelevant
websites, don't open email attachments, or even don't read email on that
box at all. :) And so on. Then let your job rely on security of that box. ;)
> I mean:
> Grsecurity had suffered of a return into libc exploit
> that bypassed its protection. Grsecurity had also
> a PaX-disabled bug in the past that expose
> machines to risks.
>
> I heard RSBAC had problem with the jail solidity etc.
Nothing is perfect. And remember that Grsecurity and PaX are orthogonal.
If you are interested, you should read the documentation on PaX and
Grsecurity, or even ask spender and PaX Team directly for the details.
> Recently I've read something about a 2.6.30 bug
> which makes useless, enforcement like SELinux,
> AppArmor and so on...
...and which is non-exploitable on kernels with PaX. :)
> so I'm wondering if it is possible to harden Linux
> the way you can leave it online with, approximately,
> the same (high) probability, it won't be compromised
> as OpenBSD does.
Linux and OpenBSD can't be compared directly.
OpenBSD kernel is less buggy and, if it can be said so, less vulnerable
by quantity (while, of cource, OpenBSD guys would say "It's by quality!"
:). In short: it's harder to find vulnerabilities in OpenBSD.
Linux kernel with PaX and Grsecurity is still more buggy (because of the
Linux part :), but got strong kernel protection that works against the
whole classes of kernel exploits. So it is less vulnerable by quality
(but still is more buggy). In short: it's harder to exploit
vulnerabilities in Linux kernel with Grsecurity and PaX.
OpenBSD got weakier overall userspace protection: less random bits in
ASLR, no mprotect() restrictions, no protection against bruteforcing the
prefork model's ASLR/SSP, no IPC restrictions, no capabilities
revocation, no reliable HIDS and HIPS (don't take abandoned systrace
seriously), no MAC or RBAC. Maybe something else significant - ask
spender and PaX Team, they know better.
Hardened Gentoo with hardened kernels have stronger overall userspace
protection and get security updates more quickly than OpenBSD ports
system... While there are some problems with keeping hardened-sources up
to date in Portage. ;) So you better use kernel patches from here:
http://www.grsecurity.net/~spender/
Also, there's no documentation for all these OpenBSD exploit mitigation
techiques. And there were issues with W^X that OpenBSD developers
prefered to fix with no word about its impact on security:
http://www.cr0.org/misc/obsdretf.asm - PoC exploit by Julien Tinnes
http://marc.info/?l=openbsd-cvs&m=113710599901750 - commit of the fix
Not kind of way one may expect from supposedly well-documented system
that supposedly stands for Full-Disclosure.
Also, you could read this:
http://www.coresecurity.com/content/open-bsd-advisorie
...and see that OpenBSD developers expressed not that much of interest
in digging even obviously security-related bugs in their kernel. Kind of
controversional to what they say about code audit.
> I'm sure there are many skilled people, reading
> this mailing list, so I'll appreciate if someone
> will be patient and will enlighten me, giving some
> impartial inputs on what to study in my spare time.
Well, I'm not the skilled one. The men behind Hardened Gentoo,
Grsecurity and PaX seem to keep silence, so I decided to reply. You may
be interested in contacting them directly and/or search google for
conversations between PaX Team or spender and linux kernel developers -
it's very interesting and informative.
|
