Debian Hardened Aims For Security
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."
Cant wait to use it with my Lexar JumpDrive loaded with security sofware against hackers.
Doesn't provide as many choices or the technological /security understanding of Hardened Gentoo
(not to mention the very similar name)
http://hardened.gentoo.org
If its a second project, where are the links to that? I don't feel like poring through your sourceforge site to find it... not that I have a ton of hope that it'll be in there.
sourceforge is designed so that authors of software can find resources easily. I've never been able to figure out their interface without getting a migraine, however...
Hardened debain is meh to me. However, TRNG hacking is something I'd love to see! Where's the linkage at???
I am disrespectful to dirt! Can you see that I am serious?!
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?
why would you need a distro for securing your machine? you should just secure your favorite distro yourself :)
Why not just get Windows XP; I mean, didn't you guys hear MS when they said they were focusing on security now???
I farted
Hard3n y0ur Debian/w0ody t0day!
I know, cheap joke, if it can even be called "joke", but it was already modded redundant which I just don't understand. But, as you point out wishing for an unfunny mod, there are flaws in the system.....
Being a slackware guy myself, I still would very much like to inspect this branch when released....
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...
Sometimes the majority just means all the morons are on the same side.
is now getting the attention of the security team. What are the possibilities of getting this release with Sarge, instead of Woody (actually, in addition to Woody, not instead of)?
If this release becomes available for Sarge, and I can use KDE as a graphical front end while setting up the installation, I'd give it a shot, and if I found it usable, I'd donate to keep the project going.
I've had some trouble with the Debian installer, so I used Mepis to install Debian, and commented out all the unstable servers in the sources list, so it is slowly becoming a testing-only install. It's going to be a web/mail/dns server, so locking it down is what I'm trying to learn right now (ran apache for a couple of years on an rpm distro without problems).
If the distro covers Sarge, and I can use it with kde for setup, then I'll find it useful for myself (yeah, I know, not supposed to run X on a server, but I'm only going to use it for setting up and getting used to it, X will be removed from the system before it faces the internet, unless I can get the hang of a front end for iptables, and only leave port 80, the dns and mail ports open, then I might leave X installed).
Security-enhanced Debian sounds good to me!
Debian's team can implement it a certain way and whatever amazing thing they cook-up can be re-used by the Gentoo team!
The goal is not a religious war, the goal is for you and I to get ahead.
I don't know the meaning of the word 'don't' - J
IF it results in many of the security features that make Debian (and GNU/Linux in general) hard to use being moved over to a specially oriented project, and removed from the main one.
For example, if you are setting up a single user box to access the internet with a modem (something that GNU/Linux should shine at) you often run into problems related to pppd requiring all sorts of obnoxious nonsense to get it to run as a regular user.
Policies such as new accounts having their own group by default, and not being readable by all other accounts, make sense in the ISP, server, and in business settings in general. But tipping point is being reached, to where soon most people setting up Debian are setting it up to use it at home, not to run a business or train themselves to get business related job skills. Things like pam have to go to where they belong, and not get in the way of the rest of us.
I would've used Overrated. 2 is too nice for that joke ;)
But redundant... come on, do you really believe that someone else has already made that joke? With maybe only 5 non-troll posts?
I am disrespectful to dirt! Can you see that I am serious?!
Has anyone ever,ever,ever compromised a computer or encrypted document by predicting the output of a random number generator?
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.
Wanna mount my hardened woody?
The government which is strong enough to protect you from everything is strong enough to take everything from you.
A professor of mine mentioned how they tried TRNG back in the day using vacuum tubes however due to the output not having a set distribution (fluctuations caused some numbers to come up more often than others and they couldn't predict which) it wasn't all that useful. I guess that in non-statistical applications this flaw isn't really that damaging, sounds interesting.
Is a hardened version more or less stable?
I have no first-hand experience, so... Anyone?
I don't know the meaning of the word 'don't' - J
Debian could use that as a spam headline!:
Hard3n y0ur Debian/w0ody t0day!
That was funny. C'mon, laugh.
"What do you think?" "I think 'What, do you think?!'"
how-come no one has made any sexual jokes with "hardened" ?
I don't know the meaning of the word 'don't' - J
Is the grSecurity patch the same thing as SE Linux?
GETPKG - Package Management for Slackware
I liked this back when Gentoo did it, and I think this is a great trend; having a completely security minded Linux OS (since BSD has been there forever ;))
personally I'm really interested in the Security-Enhanced Linux that the NSA is working on. To have something that complete is really intriquing. Now if they don't have something like apt to keep it steady I dunno...but you have to admit it's got 'wow' factor written all over it!
BCDFY^&D&S^F
free ipod and free gmail!
I'm a Hardened Gentoo user; although, I only use a subset of all the hardened herd's efforts :) I actually do understand what I'm doing, though, and am trying to spread that understanding myself. I am in no way affiliated with [Hardened] Gentoo or Debian.
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.
Support my political activism on Patreon.
Okay, deriving Linux from Linus + UNIX, I can see. Who knew Adam Ant would get into free OS hacking though?
http://www.linuxsecurity.com/docs/harden-doc/html/ securing-debian-howto/
Are Javier Fernández-Sanguino Peña and/or Alexander Reelsen involved in Debian Hardened?
>Because people disagree what is the right way of doing it. [...] linux makes some things more complicated than on a windows machine.
That's what makes growth. And more people every day are choosing Linux over Windows. Face it, Windows is NO picnic either, especially when you consider the quality of Microsoft's software!
>[...] it just generate more competition, [...] it's the consumers who are getting shafted.
Consumers do not get shafted by having choice, that is illogical. Choice is to the consumer's advantage.
I don't know the meaning of the word 'don't' - J
Take for example the fact that I can remotely shutdown a debiaTake for example the fact that I can remotely shutdown a debian machine over ssh with the "halt" command. A RedHat distro had that little feature blocked
Why exactly is this a bad thing? Have you never had to shutdown or reboot a remote server? I know I've had to do both at least a few times... Although rebooting would be much more common, and it would probably be safer as well :p.
On my Debian machines you seem to need to be root to do it. If someone I don't know is logged in over ssh as root on one of my boxes the last thing I am worried about is his ability to shut it down :p.
Updated link: http://www.debian.org/doc/manuals/securing-debian- howto/
First off, who are these guys?
Debian already has a security project, a few of them actually.
I looked at google for either of these guys names and unless I am mistaken, this is what I got: developer one and developer two.
Interesting that anyone else that they haven't ever used those names to contribute to say at least a single debian security mailing list, or say ANY debian lists?
Even more interesting is that they don't seem to have much but a slashdot plug and they are accepting donations.
I am not impressed. Working with the debian security team is the way to go.
Steve Kemp is one of the main guys heading up the debian audit project, these guys should be working with him. Not for some other project.
The official debian project for this is the debian audit project.
Hell advertising that they use SSP enabled GCC! Steve makes those packages for use with debian already!
"Not my manner of thinking but the manner of thinking of others has been the source of my unhappiness." - M
The crap about Geiger counters seems to indicate the author seems more interested in studly buzzwords than actually developing practical solutions. A soundcard with nothing plugged in is a perfectly acceptable source of entropy, the problem is just in accurately estimating the rate. Also, many chipsets and an increasing number of CPUs include hardware random number generators which can be used too.
relatively easy. They can contain all the packages and kernel upgrades via apt/dpkg, thus, limiting the software as well as the upgradability of the machine. Similar to Microsoft....
gShares.net
-------
artlu.net
Ssh should be able to do anything you can do at the console.
If you are afraid ssh will be compromised, then don't use ssh.
"Piter, too, is dead."
Really really hardened Sarge!
I'm curious as to why they chose the particular tools they did. I don't know too much about these issues, but from what I understand the NSA's selinux patches are a very robust and powerful set of tools. IIRC Redhat has been integrating it into their systems. It may be that this isn't the best choice, but I'd be curious if someone who knows them well could give us a rundown of why some solutions might be better/worse.
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.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
how is Hardened Debian going to be different from installing the harden* packages?
congradulations to hese folks. even if most of the work they do is ripping open packages and setting up more secure settings.
... exim4.41+eximscan+clam+spamassasin ... out of the box
such as providing a
a openswan package that works directly from a dialog script.
not to mention a basic iptables front end like redhat has, where is the 'low, medium, high' trusted interface prompt upon install for debian?
members are seeing something, your seeing an ad
Can you help stable my Sarge and bring it to full attention?
At the risk of the post sounding like a discussion at a head-lice convention, everyone has their own personal itch to scratch.
h tml
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)
If chaos theory tells us anything it's that true random numbers are impossible. Everything is determined by something.
Of random number generation? Sure some CPUs and chipsets have a thermal noise TRNG, but how much is still an ugly LCG seeded by the time?
-I am an elective eunuch.
Does anyone have evidence where a system was cracked due to the lack of entropy from things like interrupt timing?
I would think that there exists a limited number of people in the world who could exploit a diffie-helman exchange between systems using the usual sources of randomness on an x86 machine.
I can imagine the newest spams: get your Woody hardened now...
Does this count?
That's ok, Jesus likes me anyway.
Being able to remotely shutdown or halt a machine is a godsend. The trick is to restrict SSH access-in from certain 'secure' IP addresses, and firewall the rest of them out. Secondly, I guess only allow root access from a non-root account (ie: no ssh'ing in as root).
:)
But I guess to each their own
"That is not dead which can eternal lie...."
Nimheil
Oh dear lord, where is the (-1, Unfunny) moderation at?
;)
Is (-1, Unfunny) eqaul to (+1, Funny)???
PS- I would have modded you (+1,funny, wears crash helmet on short bus).
The government which is strong enough to protect you from everything is strong enough to take everything from you.
but seriously... as a debian user, i fully condone harder, faster, and stronger debians.
No, in that case they did not use any random data (or "salt" as cryptographers call it) in the encoding at all.
The problem was not the quality of the random number generation.
Talk about an SCO conspiracy...
So Debian made harder is news
So many the installer abused
It's hard enough as it is
Much like taking a quiz
I wish I could apt-get "ease of use."
Definitely. There was a gambling agency that people ripped alot of money off from other people cause they seeded the generator with the amount of milliseconds since midnight and used a public lookup table to generate the random number. Not only is this a stupid way of doing it - it's only security through obscurity cause you only need a few queries to syncronise your clock with the agency's clock, but the idiots actually published their code!!!
Now consider this example - random number generators are anything but secure.
Security is like an erection: it can always be harder and longer lasting. That doesn't necessarily imply impotence (unless it comes from the aptly named Microsoft, haha).
If someone I don't know is logged in over ssh as root on one of my boxes the last thing I am worried about is his ability to shut it down
Actually, if someone I don't know is logged into my system as root, I'd prefer they simply shut the machine down. Then they can't do any (more) damage...
An open source program I distribute uses a Just-In-Time compiler which modifies its own .data section in memory. grsecurity/pax don't like this and cause it to bail out. It's rather annoying as people then come to me that our software is broken.
I guess my point is that people should know the effects of the security enhancements they choose before blindly saying "hey, this is a secure system, so I'll just install it." Or at the least they should how to administrate around it.
Security doesn't mean anything if you're not qualified for it.
If you say "here goes my karma" I will bite you!!!
Because in that case, it must have a kick-ass budget.
It might surprise some linux fanbois, but other OSs are better suited than their beloved linux for certain tasks.
http://catlin.casinocitytimes.com/articles/1243.ht ml
Someone once beat Keno 3 times in a row and won $620,000 by figuring out a weakness in the 'randomly' generated numbers.
- Doestn't repeat itself for a very long time
- Doesn't have a distinct distribution if you plot them in an N-dimensional space relative to their rank-number (plot number x with value y on axis x modulo N for instance).
There are however several disadvantages: You can easily recreate the sequence when you know the seed, there is always a maximum N whereafter there will be a distinct distribution, and these algorithms often are slow. Now a fast hardware-random number generator could solve all these problems: Your numbers are REALLY ALWAYS random. And this cannot be too difficult to make I guess, since a lot of quantummechanical effects you can observe in electronics are inherently random.
int main(void) {while(1) fork(); return 0;}
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?
1.) Shouldn't the normal Debian distribution be hardened?
2.) Why does the "true" random number generator combine two sources of entropy? If one source delivers true unpredictable random numbers you don't need a second source. On the other hand if you combine two sources that are predictable the result will be predictable as well. Right?! So why two sources??
Apparently, not only had you made the joke before, but we've had this conversation about you having made that extremely unfunny joke before... cause we both got modded down as redundant.
I'm thinking you must have a vindictive mod or some such. You didn't piss off the anti-slash folks did ya?
I am disrespectful to dirt! Can you see that I am serious?!
...which uses thermal noise and also the atomic decay from a Geiger counter, making true unpredictable random numbers.
unpredictable my ass...
people should let go of this "chaos" fad and move on
Have Guard Dog installed, it's default on Mepis. Problem is, Guard Dog is more complicated than it should be. It actually works opposite of what it says, depending on what services you want to run, vs. what you want to work on the outside. Instead, or as alternate tabs, it should work simply as, allow port 80 incoming and outgoing, both tcp and udp, allow port 53 tcp, block all other ports, except from this subnet, etc.
Guard Dog isn't laid out this simply, it's more complicated, and the way that it is explained, to what it actually does, are opposites, therefore it takes trial and error to determine if you are really blocking services you want to block, while allowing other services through that you really want through.
Also, from what I see, Guard Dog doesn't work in runlevel 3, but I may be wrong on this. I also installed firehol, but I haven't tried configuring it yet. While I'll be running X to administer the box, when I'm not administering it, the box will be running in runlevel 3, not 5. If Guard Dog doesn't run in runlevel 3, it is of no use to me (not saying anything disparaging for those that find it useful, just not useful or intuitive for me).
Also, if you search, you can find a few sites that will create config files for iptables, where you just input the ports you want open, subnets, etc. As to where to put the file after you download it after it is created...
Maybe they are moderators from an alternate reality in the quantum internet where I did make that joke, many, many times.
Debian Hardened, the RMS porn movie.
As for SNARE in Debian, the only reason there are no available SNARE packages in Debian (version 0.9.1 in experimental) is just because of my lack of time in order to produce those. On top of that, there has been few interest and demand, if any, for SNARE packages in Debian by Debian users. For an example check the bugs reported in the BTS, and, yes, I've been also slow in fixing bugs there.
If you would be willing to help co-maintain a set of packages for Debian we could probably review your packages and have them available in the unstable and, eventually, in the stable distribution.