Slashdot Mirror

← Back to Stories (view on slashdot.org)

TrustedBSD Interview in Boardwatch

Posted by michael on from the double-plus-hyper-secure dept.

Anonymous Coward writes "The September edition of Boardwatch magazine includes an in-depth interview with Robert Watson, a TrustedBSD developer."

3 of 27 comments (clear)

  1. Re:Wouldn't it be nice if OpenBSD could cooperate? by howardjp · · Score: 4

    TrustedBSD is not a fork in the traditional sense. It is a stream of parallel development and nearly all the patches will eventually be incorporated into FreeBSD when they are proven reliable.

  2. Trusted, systems by cluge · · Score: 4
    Trusted systems are neat, but trusted system users shouldn't forget :
    • 1. Most attacks come from within.
    • 2. Most network connected computers are not usually as secure as the server.
    • 3. The users of any "secure" system MUST be taught security. (anti-social engineering, good data integrity practices, etc.)
    While many companies and institutions concentrate on building more secure "machines", they spend almost no money on training their employees. Call up the help desk of your favorite fortune 500 company, claim your Mr. X use an on-line company directory to get someones name that is HIGH up. A board member is always good. Bitch about not being able to get your mail, while you may not get a passwd, you WILL get the IP address of the POP3 server, what the mail client is used.

    Security can only start after every one is trained to be secure.

    --
    "Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
  3. This is forward progress by Animats · · Score: 4
    It's not that hard to implement mandatory security in an OS kernel. (There's a mandatory security mod for Linux, which nobody uses.) The hard part is making the administrative tools live within its limits. We'll have to see how well this group handles that problem.

    Here's something to think about: How should software installation work in a secure system? The installation process for untrusted applications needs to be untrusted; it shouldn't be possible to break anything or install a security hole when installing an untrusted application. Package management needs to accept more restrictions; running installs as root is out. Fixing this requires a lot of grunt work and some cleverness. In particular, shared component management in a secure environment is a lot more complex. Worth fixing, though; that's one of the giant pains of OS use today.