Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Trusted Debian v1.0 Released

Posted by timothy on Mon Apr 21, 2003 02:45 PM
from the trusty-too dept.
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by strateego (598207) on Monday April 21 2003, @02:49PM (#5775367)
    No remote holes in three minutes will be the new slogan of the Secure Debian project.

    This must be a new linux record. :P
  • AHA! (Score:4, Insightful)

    by FortKnox (169099) on Monday April 21 2003, @02:50PM (#5775379) Homepage Journal
    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? ;-)
    • Oh, come ON (Score:5, Informative)

      by Cthefuture (665326) on Monday April 21 2003, @02:58PM (#5775440)
      This is added as a GCC option. (-fstack-protector or similar) All the CONTROL and power of C/C++ is still there. It's an optional feature for when you need it. I don't usually use C and/or C++ for the control though. It's all about performance.
  • by bolthole (122186) on Monday April 21 2003, @02:52PM (#5775394) Journal
    The naming of this subproject is either poorly thought out, or just downright underhanded.

    "Trusted Debian" is clearly targetted to compete with "Trusted Solaris" and "Trusted(?name right?) BSD". However, "Trusted Solaris" has been CERTIFIED to meet B2 level security criteria. There is no mention of any such certification, either performed, or in progress, on the project's home page. It is just a collection of security enhancements and tweaks that is "hoped" will merit the system being trusted, but I see no formal proof or audit of that.
    • Eh? (Score:4, Interesting)

      by Cthefuture (665326) on Monday April 21 2003, @03:01PM (#5775457)
      Is the "Trusted ***" namespace only given to operating systems that meet B2 security levels?

      I assume a commity or something gives you the stamp and that then allows you to use "Trusted" in the name of your project?
      • Re:Eh? (Score:5, Insightful)

        by ZenShadow (101870) on Monday April 21 2003, @03:04PM (#5775482) Homepage
        Two words: marketing buzzword.
        • Two words: marketing buzzword.

          1. Create more secure operating system.
          2. Give it away for free.
          3. ????
          4. PROFIT!

          Ok, I give, wtf _IS_ the third step that would require a marketing buzzword? I guess you can market for bragging rights, but I am guessing it was more of an afterthought than a business plan.

          I bet I can name everyone that has gotten rich on Debian on one hand.............and still have 5 fingers left.
    • trusted BSD (Score:4, Insightful)

      by bolthole (122186) on Monday April 21 2003, @03:27PM (#5775664) Journal
      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.

      • From Sun's Trusted Solaris site:

        Assurance

        In a trusted systems evaluation, product features must meet a specified set of criteria. Over the years, Sun products have successfully passed many government-sponsored evaluation programs. Trusted Solaris 8 software is currently in evaluation against the Common Criteria at the EAL4 level with the Labeled Security Protection Profile (LSPP - equivalent to the Orange Book - TCSEC - B1 class).

        So, it's equivelent to the B1 level. Don't have an Orange Book hand

  • speed? (Score:3, Interesting)

    Don't all these "overflow checkers" kill the speed of C(++) apps? I'd like to see some comparisons between the two distributions.

    Are the packages the same or unique? If the latter, why not merge w/ the original code and help us all out?

    Is this better or worse than the NSA's secure kernel? Why is a new distribution required if a kernel is all that's changed?
    • If you want security, write in Java. You will never get overflow attacks, will be able to restict access of potentially buggy code to files, network and so on and will greatly reduce the chance that your server will crash because of memory corruption. If you want top performance, write raw C code. If you want both, use JNI for tasks other than processing network data or a C++ class library with bound checking.

      The overflow checker only makes a difference when compiling buggy code. And in this case it leaves
      • 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 m
    • Re:speed? (Score:5, Interesting)

      by evilviper (135110) on Monday April 21 2003, @03:58PM (#5775864) Journal
      Don't all these "overflow checkers" kill the speed of C(++) apps?

      No. OpenBSD 3.3 has 4 different forms of buffer/memory/stack protection, and Theo says that, not only is there NOT a slowdown, but on a couple architectures, it actually speeds things up! [theaimsgroup.com]

      It seems that the Debian organization's main purpose is to emulate OpenBSD... They are dedicated to maintaining older, stable versions of software, they use NetBSD as the core of their Debian BSD distro, and now they almost directly copy OpenBSD's recent security efforts. [deadly.org]

      Not that there is anything wrong with that. I just find it very interesting.
      • Re:speed? (Score:3, Informative)


        In Theo's post on theaimsgroup.com web site, I don't see anything supporting your assertion that OpenBSD's new memory protection "actually speeds things up".
        • Re:speed? (Score:5, Informative)

          by evilviper (135110) on Monday April 21 2003, @05:10PM (#5776367) Journal
          I don't see anything supporting your assertion that OpenBSD's new memory protection "actually speeds things up".

          My mistake... I've read about all this stuff a while ago, so I didn't correctly remember which post talked about which aspects of it.

          It can be found in this magicpoint presentation. It's several pages into the presenatiton. it's plain text with some markup, so you can just grep through it (look for "sped") if you don't want to install magicpoint: http://www.openbsd.org/papers/csw03.mgp

          I've read it other places before I saw the presentation, but google isn't working very well to find them, I don't have links to everything (I'd have millions of links if I make a link of everything, and kept them for this long), and I'm not going to spend a lot of time tracking down where I read this stuff. Check out deadly.org, or the OpenBSD misc/tech mailing list archives if you want additional confirmation, and discussion on the subject of the speed-up...

  • SE Linux (Score:5, Interesting)

    by Erwos (553607) on Monday April 21 2003, @02:54PM (#5775408)
    Does it use NSA's SE Linux kernel patches? Ordinarily, I don't see much use for them, but it seems exactly the sort of thing that you would want for a trusted system.

    -Erwos
  • by Anonymous Coward on Monday April 21 2003, @02:54PM (#5775409)
    It's available on BudgetLinuxCDs.com as an upgrade to woody (recommended installation method)
  • by pyros (61399) on Monday April 21 2003, @02:56PM (#5775418) Journal
    I'd like to know how many other UNIX sysems implement these kinds of technologies, except OpenBSD. How well do they compare? Again, I'd like to know how many other UNIX systems implement these safegaurds, except OpenBSD.

    hint - read the article before responding/modding

  • 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:trusted for what? (Score:5, Informative)

      by nemaispuke (624303) on Monday April 21 2003, @03:09PM (#5775531)
      If you work for the Government on classified systems they prefer "Trusted" versions of operating systems (Trusted Solaris, AIX, IRIX, etc.) These operating systems are approved for TCSEC B level security (Common Criteria EAL4 and higher). All parts of the OS are tested for Mandatory Access Control, extended auditing and logging, and data protection. installing any of these on a home system is overkill (and in the case of the ones I just mentioned, expensive). But if you are processing Top Secret information and want full audit trails and complete trust, these are the operating systems that will deliver it. The only thing I do not see with Trusted Debian is the extended auditing and logging. The secure code base is nice, but if they intend to get into the Government with this, I think they have a long way to go.
  • by ih8apple (607271) on Monday April 21 2003, @02:58PM (#5775441)
    Now that Debian is "Trusted" (like everyone else in the freaking industry picking up the same buzzword), it's time to remember Anti-Trustworthy Computing [salon.com].
  • by Anonymous Coward on Monday April 21 2003, @03:01PM (#5775458)
    Now it is more secure than Debain Stable and more out-of-date.
  • Trusted Gentoo (Score:5, Informative)

    by chrysalis (50680) on Monday April 21 2003, @03:01PM (#5775459) Homepage
    Please note that Gentoo Linux also comes with a propolice enabled GCC and a PaX-enabled kernel.

    It's up to you to use them or not.
  • by flacco (324089) on Monday April 21 2003, @03:05PM (#5775495)
    ...that i never trust any product that has the word "trust" in it?
  • Why not OpenBSD? (Score:5, Interesting)

    by unixbob (523657) on Monday April 21 2003, @03:06PM (#5775503)
    I'm not trolling here, but I can't see the benefit of this over OpenBSD.

    Admittedly there are apps that run under Linux that don't run under OpenBSD (namely commercial apps) but in this case, I would expect that running those apps on this system would lose the "Trusted" lack of buffer overflow possiblities etc., which defeats the object of the distribution. And the lack of commerical certification for this product would bely using it for such a reason anyway.

    A cursory glance over their website doesn't show me anything which would me want to choose this over OpenBSD. In fact given the maturity of the OpenBSD project, and the man hours that have gone in to that piece of work, that is likely to be my first port of call anyway.

    I'm not trying to put down the trusted debian guys, I just fail to see the point of their work (apart from the old - "why not" reason). So, if not for the licensing issue which debian has always held close to, why would anyone pick this over OpenBSD?
      • Re:Why not OpenBSD? (Score:4, Informative)

        by evilviper (135110) on Monday April 21 2003, @04:30PM (#5776057) Journal
        When I heard of both the introduction of Systrace and the memory protections in OpenBSD, I instantly remembered this article. What is so incredibly funny about this, is that practically none of the points made are true any longer.

        From the Article:
        and again while OpenBSD has audited it's code and removed most of the /tmp vulnerabilities there are no guarantees about software in the ports package or binary only software. Once this software is installed you do not need to do anything more, there is no configuration required or additional setup when you install new software, removing any chance of accidentally forgetting to protect software/etc.
        A non-executable user stack area prevents various buffer overflows, and while it can be circumvented it definitely raises the bar for attackers.

        Hmm, well that sounds exactly like the memory protection that has already been implimented in OpenBSD 3.3. Interestingly enough, all this software was available long before this article was written, it just wasn't put into the base system at the time.

        It's rather hypocritical if you ask me. He ran down all the protection mechanisms available for Linux (none of which come together in a single distro), but completely and entirely neglected similar software that WAS available for OpenBSD.

        Restricting access to port 80 for example, while easily achieved in Linux with NSA SELinux or PitBull LX is basically impossible in OpenBSD.

        TCP port ACLs are still not in OpenBSD, BUT there is a patch that is available to do this, it's just not in the OpenBSD base as of yet. Of course, TCP port ACLs don't come with the base Linux kernel either.

        Also worth a footnote is that Systrace can be used to enforce TCP/UDP port ACLs on any software run under systrace. In other words, you run bind under systrace, and there is no way for it to open any ports other than 53, which you specify. It's not what people typically think of when they consider TCP/UDP port ACLs, but it does the same job. Systrace is in the OpenBSD base system.

        for Linux that allows an administrator to control access to files, various process actions, system calls and more.
        Protecting binary software can be done in Linux with a variety of tools, doing so in OpenBSD is very difficult (there is little you can do). Even with some of the most secure source code in the world OpenBSD will not be capable of providing the same levels of security

        Well Systrace easilly accomplishes the above. You can impose arbitrary restrictions on binary programs, wether they are native OpenBSD binaries, or Linux binaries under emulation.
  • A trusted 1.0... (Score:5, Insightful)

    by japhar81 (640163) on Monday April 21 2003, @03:11PM (#5775550)
    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? (Score:3, Insightful)

    by Anonymous Coward on Monday April 21 2003, @03:18PM (#5775595)
    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.
  • Firewall anyone? (Score:3, Interesting)

    by Lumpy (12016) on Monday April 21 2003, @03:18PM (#5775596) Homepage
    I can see this as a use for a firewall or in the wild pc.

    If you own a PC and you dont have a firewall between it and the internet, you are pretty damned dumb.

    This really is of no use to the average user.

    I'd love to see a floppy distro for floppy firewall set up from it though. (upgrade the kernel to 2.4 so we can use modern firewall rules.)
    • Re:Firewall anyone? (Score:3, Interesting)

      by Anonymous Coward
      If you own a PC and you dont have a firewall between it and the internet, you are pretty damned dumb.

      Everyone always says this, but nobody seems to think about it. Why, exactly do I need a firewall between my PC and the internet at large? I keep up with my patches, I don't execute email attachments (I don't even use Outlook), I'm not "pretty damned dumb" in general... What is a firewall protecting me from, if I'm already being good about security? Anyone want to explain that to me?
  • Whats in it for me? (Score:5, Interesting)

    by jasno (124830) <jasno@s[ ]rr.com ['an.' in gap]> on Monday April 21 2003, @03:22PM (#5775631) Homepage Journal
    I run a home gateway box with SSH, IMAP, and Apache on open ports. I check for updates daily, and no one else has an account on my box.

    Is there any compelling reason for someone like me(and most /. users) to use something like this? Can someone sum up the benefits?

    I'm not downplaying the importance of this kind of project. I can see its usefulness in a corporate environment. I'm just wondering if there's anything I'm forgetting on my current machine, and if this is a good way to address those problems.
  • Trusted Computing. (Score:4, Insightful)

    by mindstrm (20013) on Monday April 21 2003, @03:28PM (#5775678)
    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.

  • Trusted? (Score:4, Funny)

    by Anonymous Coward on Monday April 21 2003, @03:34PM (#5775720)
    Trusted sounds past tense. Almost like Debian was trusted at one point, but not anymore; that doesn't do much to instill confidence does it?. I propose a name change to "Trusting" Debian, as it sounds much nicer. Better still, we should drop the word Debian (how many people know what a Debian is anyhow?) and just go with the generic word "Computer". Now it's "Trusting Computer". See how that works?

    Everyone likes a trusting computer.
  • by linuxbaby (124641) on Monday April 21 2003, @03:50PM (#5775807)

    On a normal Linux system running Slashdot, we see this:

    • Article #3 Posted again
    • Article #4 Posted
    • Article #2 Posted again
    • Article #1 Posted again
    • Article #3 Posted
    • Article #2 Posted
    • Article #1 Posted

    On a Slashdot running one of the Trusted Debian kernels, you will see something like this:

    • Article #4 Posted
    • Article #3 Posted
    • Article #2 Posted
    • Article #1 Posted

    As you can see every value is different.

  • by FattMattP (86246) on Monday April 21 2003, @04:13PM (#5775956) Homepage
    If all of this stuff is so good and improves security, why isn't it rolled into the main Debian distribution?
    • Well I don't think this project is trying to push a tightly controlled hardware platform to get better security.

    • by feed_me_cereal (452042) on Monday April 21 2003, @03:18PM (#5775593)
      ...nothing but snickers here, especially from Slashdot themselves, never mind the Zealots. But when it's Linux, oh man, don't say anything bad about it, despite the buffer overflows and everything.

      uh... apperantly you haven't been reading the comments on this thread. I read through about 20 comments so far and not one praise, a few informational posts, and several critisisms.

      What I'm sick of hearing on slashdot are people who think they'll sound smart by making immediate and unsubstantiated remarks against what is percieved by them to be the consensus. By acting this way, you might seem like you're noticing what everyone else is too dumb/blind to see, but it doesn't make you insightful, just contrary, which is equally as closed minded as being zealotous.
    • by Malcontent (40834) on Monday April 21 2003, @03:24PM (#5775639)
      When MS talks about trusted computing you can pretty much assume it's mostly marketing.

      When the people at debian talk about trusted computing you can pretty much assume they are serious about putting together a solid and secure system.

      It has the do with the character of the people making the annoucement.
    • at least when the developers name it "trusted"-whatever it is- they mean that the user can trust it, not only the developer.

      when m$ talks about trusted, it is a truly Orwellian example of doublespeak.

    • by frodo from middle ea (602941) on Monday April 21 2003, @03:18PM (#5775594) Homepage
      Here you go, you "too lazy to read the article" newbie
      it randomizes stack, code, heap and shared libraries
      PaX randomizes the place a program is loaded into memory. Buffer overflow attacks depend on the exact location of memory locations. Attacks are much harder when that location varies every time a program is executed. Thus making it much harder for attackers to locate the exact locations they need for a succesful attack. Again, PaX is the first to implement this kind of protection. No other UNIX system uses this kind of protection against buffer overflows, except OpenBSD. But their implementation is more restricted. It will randomize only one aspect of the memory (which technical people call the stack) where PaX randomizes four aspects (stack, heap, libraries and the main executable) and their implementation uses 10 bits against 24 bits for PaX
      it does strict mprotect() checking
      it adds proper checking to how memory is being used, to prevent badly written programs from accidentally opening up certain kinds of security holes
      it also protects the kernel.
      Third, PaX tries to do its best to keep code and data separate. Many buffer overflow attacks try to write some data and then try to execute it, as if it were code. PaX tries to prevent this. Fourth, PaX enforces the same kind of protection to the core of the system, the Linux kernel itself. Again, this is unique to PaX, there is no other UNIX system which offers the same kind of protection of its 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.
      The second product used by Trusted Debian to solve the buffer overflow problem is called the stack protector, formerly known as propolice. It is a modified GCC compiler written by Hiroaki Etoh at IBM and it adds a kind of ``booby-traps'' inside programs which are triggered when a buffer overflow occurs. The program is then terminated before the overflow can do any damage.
      It also features FreeS/WAN and RSBAC, an extensive access control framework. Trusted Debian adds more than just these buffer overflow protection technology. Version v1.0 also ships with RSBAC, an extensive access control framework which will play an important role in future releases. And FreeS/WAN, which is able to encrypt all TCP/IP communication between two machines and can therefore be used for setting up VPNs or securing wireless LAN communication, among other things.
    • Trite bullshit (Score:5, Insightful)

      by I Am The Owl (531076) on Monday April 21 2003, @03:18PM (#5775599) Homepage Journal
      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 [trustedbsd.org] 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 (Score:4, Insightful)

        by Panoramix (31263) <cesar@mengambrea.org> on Monday April 21 2003, @04:35PM (#5776082) Homepage
        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 [rsbac.org].)

        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.

    • by Anonymous Coward on Monday April 21 2003, @03:27PM (#5775662)
      I know this is not an answer to many problems, but I wonder, why there is no biger efford put into binary sandboxing. I would LOVE to limit rights of sub-processes. Possible solution would be a user (group) submask. To explain what I mean:

      Suppose you are an ordinary user with 32 bit UID
      00 00 00 A7 and mask FF 00 00 00, given by the administrator. This mean you can acces all files (and resources) to which you can "chameleonise" UID to xx 00 00 A7

      You can also run a subproces, say, x1 00 00 A7 with rights further restricted. This mean that the parent process will have the acces to all result of the child, but not vice-versa. Now you can run a network browser, email program, downloaded binary-only spyware etc. in their own sandboxes with access to particular resources only (say a directory with ownership 01 00 00 A7). They would not mess-up anything else... You would be able to limit network access etc.

      Roman Kantor

      PS: The beauty of this hack is that it can work with standard POSIX filesystems, you need to add masks only to processes. I am not sure how difficult would be to hack the linux kernel, but it should be relatively straightforward.
      • I do think we should rewrite the legacy net applications. They are old, bloated, and full of security holes. Cyclone is a cool language that no low-level security nut can ignore, but I also don't think it's necessary to write network apps in low-level languages. That's really tedious.

        For instance, I rewrote ftpd in SML because I got sick of buffer overflows. It only took me a few days and the result was much leaner (wu_ftpd is 30,000 lines, mine was about 800) and definitely has fewer buffer overflows / he