Trusted Debian v1.0 Released

Peter Busser writes "The Trusted Debian project releases its first official release, v1.0. Its main focus is solving most (but unlikely all) buffer overflow problems. It features PaX, a kernel patch which does several things. It tries to keep code and data apart, it randomizes stack, code, heap and shared libraries, it does strict mprotect() checking and it also protects the kernel. Trusted Debian also uses the stack protector patch for GCC developed by Hiroaki Etoh at IBM, which adds overflow checks to C/C++ code. It also features FreeS/WAN and RSBAC, an extensive access control framework. More information is available from the website. There is also a demonstration available for the special capabilities of this release."

Comments

AHA!

[FortKnox]

which adds overflow checks to C/C++ code

Overflow check? But I thought C/C++'ers like the amount of CONTROL that comes from being able to shoot themselves in the foot!

At least, that's what they tell me when I tell them I program in Java now.
Guess you'll need to figure a way around these checks, eh? ;-)

trusted for what?

[192939495969798999]

Where is it implemented that a trustworthy operating system is required? there should be a standard for printing the word "trusted" on a software program, so that everyone knows what everyone else is talking about. Companies shouldn't just be able to print "trusted", just like i can't print "low fat" on a hamburger if it's not up to some standard of "low fat".

Re:Eh?

[ZenShadow]

Two words: marketing buzzword.

Re:No Remote...

[Jason1729]

Secure Debian sounds like a good name for it. The first thing I thought of when I read Trusted Debian was that it will be like palladium.

Jason
ProfQuotes

A trusted 1.0...

[japhar81]

I'll call an OS trusted after its been deployed for at least a year with no intrusions.

How do you call 1.0 of something 'trusted'? Regression testing and looking good on paper is great, but until you can prove that the damn thing works (i.e. make me trust it) it ain't trusted.

That said, I'm going to grab my copy and play around. We need more security-focused distros. BSD has it right (no remote exploits with a base install), linux needs to do a little catching up in the access control area.

Other distros?

[Anonymous Coward]

Shouldn't we be pushing to get this integrated into other linux distros?

If Redhat, for example integrated in into RH 10 or Mandrake into 9.2.

Trite bullshit

[I Am The Owl]

I can't believe somebody modded you up for that. This doesn't even begin to approach the level of security that the likes of Trusted Solaris and high end IBM software is at. It's just a collection of security fixes and patches. It's not even introduction of an ACL system like TrustedBSD has. It's just a half-assed attempt at a security audit to remove the existing bugs.

Real security comes by design, not by sticking your thumb in the dike again and again and again.

Re:Trite bullshit

[Panoramix]

I can't believe somebody modded you up for that. This doesn't even begin to approach the level of security that the likes of Trusted Solaris and high end IBM software is at.

Well, I think it's better to see someone starting to walk that path, rather that just sitting there complaining that Linux doesn't even begin to approach the level of security of some other OS.

It's just a collection of security fixes and patches. It's not even introduction of an ACL system like TrustedBSD [trustedbsd.org] has. It's just a half-assed attempt at a security audit to remove the existing bugs.

From what I saw, after a cursory look at their page, they are using the RSBAC patch, which allows for quite a lot of security models (it is even extensible, like PAM on steroids, it seems). ACLs are just one of the supported models. The capabilities and resource models look quite useful, and I am very interested in learning more about their "functional control", "privacy" and "role compatibility" models. Also note the "malware scan" model, which scans for viruses and the likes on execution. Also, they state that models can be combined, and, furthermore, it seems that this can be applied to network accesses, not just files, which sounds like something I really, really want.

(Read the list of models with brief descriptions at their overview page.)

Note that I'm not familiar with this software (yet), so I can't say if it really is as good as it seems. But it looks very interesting --and a far cry from a "half-assed attempt at a security audit". I intend to try it as soon as I can.

trusted BSD

[bolthole]

I forgot to mention in my original article, that "Trusted BSD" strives to meet the same security standards that Trusted Solaris does.
"Mandatory Access Controls" and all that fun stuff.

[www.trustedbsd.org]

So, "Trusted Debian" is the odd man out.

Trusted Computing.

[mindstrm]

All the stuff about buffer overflows, code audits, stack randomization... those are all attempts at plugging security issues.
None of them really have anything to do with "trusted computing".

Trusted computing is normally about 2 things: Making sure that nothing has access to anything it's not supposed to, and making sure that there is an audit trail for who did what.

Example: Normal linux distributed -vs- NT.

Okay... I hate windows.. but....

Ever been frustrated because, in windows, if someone sets permissions on a directory they own, and says administrator can't access it... when administrator tries to access it, he gets denied?
In unix, of course, root just ignores said permissions.. or changes them.
In NT.. administrator has to first take ownership of the object THEN change the permissions... and administrator can't assign ownership back to the other user (though of course, administrator can grant access to the object).
Why? So there is a trail of events. Your file was changed? You say you didn't do it? IF administrator did it, it will show in the file permissions.

Re:Halfway measures

[ZenShadow]

If you want security, write in Java.

This kind of naive attitude is why we have so much bloody buggy software. While changing programming languages may reduce a certain class of errors, it will never, ever, ever result in security. It can't. The programming language can't prevent a programmer from being stupid.

If you want security, you'll actually have to do the one thing that few programmers actually take the time for in this industry: don't take shortcuts. Plan your software, plan your security model, code it carefully, have it peer reviewed (carefully, two or three times), etc...

Then you'll have a *hope* of security.

That being said, security in software is all a carefully crafted illusion anyway.