Debian Hardened Aims For Security 167
larryg writes "Debian Hardened is a new project that wants be an official Debian sub-project. It aims to provide a complete tree of hardened kernel and software packages for a standard Debian distribution, without changing to another like Adamantix and making easy the hardening of any machine running Debian GNU/Linux. The hardened kernels use the grSecurity patch and some of the Adamantix kernel patches; also, its packages are compiled with the ProPolice/SSP gcc extension and some libraries to prevent and trace buffer overflow attacks. Also, and as a second project, we are working on some enhacements against the Linux Entropy Pool engine, using an external TRNG (True Random Numbers Generator) device which uses thermal noise and also the atomic decay from a Geiger counter, making true unpredictable random numbers."
Hardened Gentoo (Score:5, Interesting)
(not to mention the very similar name)
http://hardened.gentoo.org
www.lids.org (Score:4, Interesting)
How is this going to be different than just installing Woody and applying the lids kernel patch to your particular kernel and locking the system down that way?
Interesting....... (Score:3, Interesting)
I still think the less you have the more secure it is.... as long as what you have isnt bloated. Thats why in my opinion slackware is great on security.
So if this thing is more than one iso image ill be rather skeptical since debian tends to be a very large distro...
It's good for both, actually; (Score:5, Interesting)
The goal is not a religious war, the goal is for you and I to get ahead.
Enhacements against the Linux Entropy Pool engine? (Score:5, Interesting)
Would the time not be better spent looking for the next OpenSSH/SSL hole?
I'm not trolling, most security flaws come from everyday apps rather than esoteric problems.
They'd need more drastic changes (Score:5, Interesting)
At any rate, these people don't understand that they'll need more drastic changes. Why not bring attention to http://d-sbd.alioth.debian.org/ while you're at it? This is my project, just a demonstrational effort to bring these things to the attention of the Debian maintainers.
The idea isn't to have a hardened "Enhancement," but rather to incorporate anything you can put in that won't hurt. For example, you can compile glibc, gnome, and bash with SSP/ProPolice, and nothing else will use ProPolice but those. Those programs also won't be hurt by ProPolice. We can extend this to, "Compile any program or library that won't break with it with SSP." The user will never notice; but it'll stop a range of attacks.
My point is that you need to aim low. A hardened system like Hardened Gentoo or Adamantix will supply you with *everything* -- PaX, SSP, ET_DYN binaries, rediculously complicated MAC systems, firewalling maybe, network sniffers, etc. A non-hardened distribution should look at each of these, determine which don't change the end user's experience (administrator included), and implement them. This is "Do what's easy" rather than "Do EVERYTHING we possibly can," but it's still better than just being lame in the area of security.
selinux? (Score:4, Interesting)
One issue with selinux I (think) I understand is that in order for applications to run properly you need to have predefined rules which allow them to do what they need to do (the nature of MAC is they can't do anything except what is explicitly allowed, as I understand it). This is possible for servers, which do only a few jobs repeatedly, but for a desktop machine with hundreds of potential applications to fire up and more being developed such a burden becomes huge. A normal user would end up turning off MAC in order to use the computer the way they want to, unless each application they want or may want to use already has a default ruleset present. I would be really happy to see this happen - various distributions collaborate on default rules for large numbers of applications, so end users could actually use systems that are seriously hardened. I know it's probably overkill, but given what casual Windows users on the network have done over the years (as well as unsecured Linux boxes and other OSes, for that matter) I think if some combination of projects could deliver a usable desktop machine with mandatory access control and any other features which might defend their box while letting it be useful would be a Very Good Thing. One thing is for sure - too little security does more harm to the internet community than having more protection than you need.
http://packages.debian.org/harden (Score:4, Interesting)
how is Hardened Debian going to be different from installing the harden* packages?
Re:good trend (Score:5, Interesting)
If you look at the SElinux download page [nsa.gov] you can read the following tidbit:
In other words, SElinux comes with the kernel.
Itch scratching, and audit (Score:3, Interesting)
Several posts thus far, have questioned the viability of establishing yet another secure-debian project, similar to other existing projects, and have indicated that there would be a better use of available resources if everyone would just get along and work together (or at least, form under a single project). Fair enough.
However, there are a whole range of reasons why diversity and natural selection w.r.t many competing projects can provide benefits over and above a single large project - organisational inertia, effective and efficient communication, and development priority differences, for example.
'Organisational inertia' in particular, whereby the larger a organisation/project gets, the slower it can react to changing requirements, is a good reason why this effort-amalgamation can potentially be a bad thing.
Each of these projects probably has a slightly different 'itch' to 'scratch'. There's no reason why, later on down the track, that the best elements of each of these projects cannot be merged into something cohesive.
A good example is the current situation in Linux Auditing (as in C2/CAPP style auditing and event logging, not code verification) and host-based audit-related intrusion detection. Over time, we've had Snare (http://www.intersectalliance.com), SLES (http://www.suse.com), and Riks Audit Daemon (http://www.redhat.com). Each project had a slightly different focus, and each development team have come up with some great solutions to the problems of auditing / event logging.
The developers of each of these projects are now communicating and collaborating, with a view to bringing a effective audit subsystem to Linux that incorporates the best ideas from each approach.
BTW: How about auditing in this project? Here's a starting point:
http://www.gweep.net/~malk/snare_debian.s
Red. (Snare Developer)
Re:Hardened Gentoo (Score:3, Interesting)
You have to admit that reading the N-thousand-word Gentoo Handbook (heh, I remember when it was just the install guide) teaches you a bit more than the "next, next, next, done!" of Red Hat or Mandrake. I know I certainly didn't know what the hell was going on when I used Mandrake (let alone Corel Linux, my first distro -- Mandrake was my second, and Gentoo my third), but I really did learn a lot just between booting up with the liveCD and making my computer usable.
Re:True random numbers are impossible! (Score:3, Interesting)
It rather reminds me of St. Thomas Aquinas' proof of the existance of God using the logic of the unmoved mover (that as all things have cause, there must exist one seed without cause to begin the chain, and that seed is God). This mostly seems like bunk, today, what with the fact that cause can follow effect, Quantum Mechanics exhibits truly random behaviour, etc, etc.
Re:Hardened Gentoo (Score:3, Interesting)
Re:why need a distro for that? (Score:2, Interesting)
Some things have to be done at compile time, or need extra administrative work. Sometimes though, that work is a one-time cost, and so can be handled by the distribution. These types of things are possible with Hardened Gentoo, and are focused on with D:SbD [debian.org].
You should realize that adding Stack Smash Protection or real PT_PAX_FLAGS (as opposed to utilizing the non-standard abuse of the standard EI_PAX field), or producing ET_DYN executables that can be freely moved around by PaX can't just be done by a user, unless he rebuilds his distribution. In that case, why not just use Gentoo? It's designed around building from source, it's most obviously BETTER for building from source.
There are many non-source based distros. These of course would be better for some users than Gentoo. They'd also likely have issues with being built from source (more difficult, or breaks the package manager); plus the user would need to locate things that break with the protections himself and not use those for those. This is why a distribution should come secure.
These little "Security hardening enhancements" will never ammount to anything. The whole distribution needs a full rebuild to really take advantage of them. PaX for example will do nicely, as long as nothing kills EI_PAX (like strip sometimes likes to) for broken binaries, and as long as you don't mind missing out on randomizing the executable base. SSP and PIE/ET_DYN are just impossible to "drop in" to a live distro.
Re:Hardened Gentoo (Score:3, Interesting)
D:SbD [debian.org] has only been active about as long, and is in beta (almost production) stage. Of course, we're just supplying information about the systems that are out there; what impact they have; why they're good; and how to use them. In essence, D:SbD is just "this is what you do to implement a secure system without pissing the user off with tons of extra crap and breakage."
It's done the way it is because I can't myself implement these things; and I'm not forking Debian. It'd be easy enough to rebuild the whole system, track down the holes, and make sure everything works and is handled so the user sees nothing. Problem is, I'd have to rebuild each and every package to get PIE, SSP, and PT_PAX_FLAGS. Wrong approach.
Forking Debian into a generally usable distribution that is 100% suitable as a drop-in replacement for 100% of the current Debian installations is two things: excess work for me, and pointless. It's pointless because if everyone can safely use it anyway, then it should just BE Debian. This is not me trying to make a name for myself; it's all of us trying to make things better.
Because of the approach these people are taking, I don't honestly see their project escaping alpha. If they do, they'll either have done exactly what I said in the above paragraph; or they'll have a couple of changes that don't really do anything useful. You have to work with them, not against them.
Too much security (Score:3, Interesting)
Sometimes I get a feeling saying that people spend too much time thinking about security in the OSS world. Security is important, but as mentioned earlier, has a system's security for example ever been compromised because of insecure random number generation?
It's just like the VPN softwares around. Take for example IPsec/FreeSWAN and OpenVPN. OpenVPN offers great security using SSL and TLS. Both those protocols are in the present time considered secure and it's fairly simple to setup.
IPsec on the other hand, takes the concept of security to a whole new level. This affects the overall software, turning it into a pain to set up and understand. And in order to make full use of the security you have to understand how it works.
I bet many security issues arises out of misconfiguration due to unnecessary complexity in the software. Keep it simple stupid is the way to go.
My point is: isn't secure security enough? Does it have to be better?