|From:||Pavel Labushev <p.labushev@×××××.com>|
|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
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.
|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>|