Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
BSD Operating Systems

OpenBSD, Security, and Theo de Raadt 178

AdamK writes "Here's a very interesting article on security and OpenBSD. It also briefly mentions Linux, comparing the two." A quote from the story: "OpenBSD is so secure that it even got the attention of the U.S. Department of Justice, which stores and transmits top-secret data using 260 copies of the OS."
This discussion has been archived. No new comments can be posted.

OpenBSD, Security, and Theo de Raadt

Comments Filter:
  • by Anonymous Coward
    Ok, here's how to make your machine safe from this:
    1) disable floppy-boot in bios-setup.
    2) set bios-password
    3) lock case, and have a case-breach-sensor, which triggers deletion of all HDDs. This prevents the attacker from deleting the bios-password and from taking out the discs
    4) don't have reset or power-switches (not needed if atx-powersupply). ctrl-alt-del deactivated too of course.
    So, this only leaves pulling the plug to turn the machine off, then open it, shorten the bios-password-del-jumper and THEN boot from floppy. And therefore we need to:
    5) have 2 of these boxes which monitor each other and have them sound a big, loud alarm in case one fails. Disc-deletion and sealing of all doors to the server-room is then, of course, a standard feature ;-)))

    Did I forget anything ? ;-)

    rob

  • by Anonymous Coward
    There wasn't a lot of meat in that article (Those of you who find it slashdotted aren't missing a whole lot.) It leaves quite a few questions unasked. Is de Raadt responsible for just the kernel or for applications (sh, grep, etc) as well? Is there anything in there to prevent buffer overflow attacks? Has he implemented any or all of the Orange Book security measures? How extensive was their source code auditing?

    It doesn't matter how tight your kernel and base software are (As de Raadt says in the article) if you go out and install a third party server that's insecure. I do agree with him that Linux dist maintainers such as Redhat are much too lax in the security arena when they assemble their distributions. They've always been much to free with those setuid bits, pretty much guaranteeing that if a user can get a login on your system, it is then trivial to obtain root.

    In my experience, third party source code auditing is the number one way to guarantee that any given piece of software is secure. Back when I was working with Data General to get a B2 certification for DG/UX one of my jobs was to audit functions in the C library. We'd take a function, look at the source, form a test plan, write up the test plan, and feed a test program to an automated test platform that would try the function out with an assortment of values, checking for unwanted side effects or erroneus return values. We did this for every single function in the C library. We did similar testing on all the core utilities of the OS. All our tests were completely documented so that they could be reviewed later. I'd feel a lot more secure with Linux if a distribution would apply this level of scrutiny to any program given a setuid bit and the C library as well (And I'd want to be able to access the test plans and results online.)

  • by Anonymous Coward
    Yes, I do like IBM. I recall, with some fondness, finding and disabling 14 different case sensors, temp sensors, and fan sensors to be able to warm my morning muffin on the heat sink of my RS6000 workstation every morning a few years ago. The CE almost had kittens, then asked how I had done it ...
  • by Anonymous Coward
    Having witnessed the sociopathic Deraadt first-hand when he sabotaged NetBSD's sourcetree, I'm surprised anyone would go near him.

    Want proof?

    http://www.freebsd.org/cgi/getmsg.cgi?fetch=2930 51+297018+/usr/local/www/db/text/1996/free bsd-questions/19961222.freebsd-questions

    http://www.freebsd.org/cgi/getmsg.cgi?fetch=5604 4+0+/usr/local/www/db/text/1996/freebsd-ha ckers/19961020.freebsd-hackers

    http://www.freebsd.org/cgi/getmsg.cgi?fetch=6356 7+65920+/usr/local/www/db/text/1996/freebs d-hackers/19961020.freebsd-hackers

    I wouldn't use OpenBSD if it was the only free operating system on Earth.
  • True, which is why what I said wouldn't stop anyone,
    just probably annoy them a little bit. It's a moot point
    anyway, seeing as I was way off base in describing
    how the password system works...
  • I've only been using OpenBSD for a week or two now, and I think I see a way to configure it so that changing the root password would be a real pain after booting from a floppy disk.

    On OpenBSD, all account information is stored in a non-text format file called (on my system) pwd.db. Editing user information is done by running the new password entries through a program called pwd_mkdb which preforms some checks, then modifies the database.

    I believe, that if the authentication technique for Root is set to One Time Passwords, that you would have to edit pwd.db itself to revert to normal passwords, as I do not think that pwd_mkdb will make that change.
  • yep, it's that easy. physical_access = you_can_do_anything.

    at the lilo prompt, instead of typing 'linux' (or whatever) type 'linux single'. bam, instant root access shell.

    as for the other operating systems, assuming they're not using a cryptographic file system, your worst case scenario is add the drive to an alternate machine which can access the filesystem, mount it as /mnt/serveriwanttohack, and then edit /mnt/serveriwanttohack/etc/passwd.

    I, personally, am not concerned with these kinds of 'vulnerabilities' considering that in almost all cases, if you have something truly secure, they're locked away in a camera'd, card-access only server room anyway.
  • has to be BSD style init. BSD init has the advantage that all configuration parameters are located in one nice easy to find place. SysV style init on the other hand offers an easier method if inserting/deleting services, and runlevels are useful. inittab is great for keeping something running, ttytab from BSD is poor in comparison, the only way I can keep something running from ttytab is if I hack it so that it's a TTY.
  • ...is who heads the project. I wouldn't want someone as (from what I hear) skript-kiddie-ish as Mr. DeRaadt as the front-man for my OS...

    - A.P.
    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • I'd feel a lot more secure with Linux if a distribution would apply this level of scrutiny to any program given a setuid bit and the C library as well (And I'd want to be able to access the test plans and results online.)

    Hrrm. You have experience in performing this task, and you have an itch to scratch. Sounds to me like you just volunteered your services :)

    The source is out there. Use it friend, use it.

  • The password information is stored in /etc/master.passwd. It is then compiled into a db database /etc/spwd.db, for reasons of speed. This is the "shadow" file that you are used to seeing. It also has more records than you are used to seeing, including password expiry and so on. When you use vipw(8) to change the password file, it then translates this into the standard passwd file that programs are used to seeing and plonks it in /etc/passwd. This file is then also put into a database for quicker access.

    Note that the db database is pretty similiar to the way that sendmail handles it's maps.

    For the full lowdown, do "man 5 passwd".

    I'm not sure whether or not the authentication technique would be used in single user mode.

    I think you can make the system ask for a password in single user mode by labelling the console "insecure" in /etc/ttys.
  • Hey - glad to.


    It's actually kinda fun to give my box a little action. And what action... I haven't seen this many hits on my own website... um... ever!

  • And, of course, it can be misleading to speak of a "secure operating system" - security is a property of the system as a whole. A Windows NT mail hub can store and forward a PGP-encrypted message without the contents of the message being any more readable, and an OpenBSD machine can be configured with open "telnet" ports and guessable passwords.

    And if the telnet ports are open, so what? maybe a user account is compromised, but that attacker still isn't going to gain root. Compare that to Redhat Linux, shipping a remote root vulnerable imapd until the release of 6.0!

    No one involved with the OpenBSD project claims that it can be used by clueless people. In fact, quite the contrary. They encourage people to discover facts for themselves, educate themselves thoroughly, rather than providing simple cookbook instructions without understanding. Rather, the emphasis is on providing an operating system that is complete, secure, stable, and instantly usable for the educated user.

  • Anonymous Cowards just don't know humor when they read it, do they?
  • So these storerooms full of Sun equipment... how well inventoried are they? :-)

    Any chance my van could be used for, uh, off-site storage?
  • I've used a few different versions of both for a while. They are about as similar as two versions of Unix-like OSes can be. People who live mostly in the X Windows System will probably never notice which is which.

    When fiddling with init scripts, I prefer BSD. This is a very subjective thing and I think largely the preference is determined based on what you learned first...

    When fiddling with devices, I prefer Linux -- BSD disk labels (somewhat like an alternate method of an extended partition on a PC, not really) are a little daunting for the uninitiated, IMHO.

    When it comes to handling package management, Debian has the only Linux distribution that comes close to FreeBSD in terms of ease of use and power. For people who don't think much of package management (you Slackware guys), you might prefer NetBSD.
  • If I understand the previous poster correctly, the power-on password is resettable, but only if you know the current password. This would be realizable using a EEPROM (the two 'E's stand for Electically Erasable) such a PROM is reprogrammable but non-volatile. Otherwise, you're right, there would be not any point.
    --
  • Say what?! You say "It's a bitch to get configured and installed."

    Friend, OpenBSD is the easiest un*x to install and configure. When you first choose the disk layout i have never seen another system hold your hand and help you so much when giving the size of each partition you want. It has been the easiest un*x to configure for our NIS environment here, including running amd.

    Maybe we have different desires for what our chosen OS gives us, but from my job POV i need a system that integrates into our environment with a minimum of fuss and trickery, and OpenBSD is by far the easiest i have found. For those curious, we run Solaris, SunOS, AIX, HP-UX, Linux, BSDI, Irix, Digital Alpha, OpenBSD; all at many different revs and languages and platforms.

    -j

  • On behalf of all of us, thank you!
  • Of course, you didn't close your HTML tags properly. You should have used /WHINE. Just being picky :-) Oh, and I can't view the site either :-(

  • It's actually kinda fun to give my box a little action. And what action... I haven't seen this many hits on my own website... um... ever!

    I want to join in the thanks... It was nice reading the article on your box. Thank you!
    :)

  • Maybe I'll tinker with FreeBSD 68k, and maybe try it on one of the x86 boxes here at work.

    FreeBSD doesn't do m68k... You want
    NetBSD [netbsd.org] or OpenBSD for that. I'd recommend NetBSD, personally... The NetBSD/mac68k community is extremely active and extremely friendly, and NetBSD/mac68k is remarkably well-documented.

    NetBSD/mac68k was the first Un*x I ran at home, since at the time Linux/mac68k just wasn't there yet and mac68k hardware was all I had. I've been happy ever since.

    I use both NetBSD and GNU/Linux regularly, and I like them both, but I choose NetBSD for my personal systems because it simply feels more streamlined to me. I like the package system a lot. I like being able to easily rebuild userland. I like the way you configure NetBSD. I like the fact that it's the same on every platform. It just has a lot of good things that make it unlikely that I'll supplant it with GNU/Linux any time soon. Give it a try.

  • But only because I have an aging Sun workstation at home ...

    For portablility, NetBSD is the champion of the *BSD's. If you need prepackaged security tools, then OpenBSD is your obvious choice. And if you're running an Intel machine then FreeBSD performs the best of the BSD's on that platform.

    As for NetBSD ... well I've now switched to RedHat 6.0 on my Sparc. It runs faster simply because of the development choices made by the SparcLinux team. The NetBSD guys had to make the decision whether to go for out and out performance on each platform that they support, or opt for sheer portablility convenience. To optimise for each platform would have meant much more work, and much more platform specific code. The SparcLinux team went for performance, and have a kernel that outperforms NetBSD - and seems as stable.

    Chris

    Chris Wareham
  • (you wont get the subject line unless you've seen 'Only Fools and Horses', an occasionally funny British sitcom).

    I've actually had my eye on a rather nice 21" premium Sun monitor (I've only got one of the cheaper 17" ones at home). I honestly don't know what is going to happen to all the hardware, but I doubt they'll offer it for sale to the staff.

    Which reminds me. The Goth/Industrial club I go to (the legendary Slimelight in Islington, London) has converted one of its unused rooms into a warehouse for just about every kind of computer kit. Vax's, Suns and hordes of old PC's. Strange.

    Chris

    Chris Wareham
  • I was fascinated to see that the US DOJ, which must be a hive of petty bureaucrats, uses a free OS like OpenBSD. Here at ... no I better not name them ... I can't get authorisation for a Unix development server. It's bloody ludicrous.

    I'm rewriting two systems that currently run on Solaris. I was expected to do this from an NT workstation running Hummingbird Exceed and connecting to a server in Amsterdam.

    Firstly, the development server no lnoger exists. Secondly, our net connection to Holland is diabolical.

    So I replaced NT with Linux on the sly, and rewrote the system in two weeks. Now I need to test it ...

    The recently appointed IT manager has made one decision since taking up his post:

    Duhhh ... no more Unix development. Everyfing must run on Windows NT - it's the future.

    This has meant two things for me, a recently arrived contractor:

    1) The Unix sysadmins *all* left in disgust at the switch to NT

    2) We have storerooms full of unused Sun equipment, but no one will sanction the setting up of a new Unix server

    Sorry about the pointless griping, but I had to get it off my chest.

    Chris

    Chris Wareham
  • If someone has physical access to the box it is not secure.

    There are two kinds of 'physical access' - access to the keyboard and floppy drive, and full access to the machine, including removing the case.

    In many environments such as schools, users have the first but not the second. You can assume that they won't open the case of the machine or steal it, but they will try booting from floppy, CTRL-ALT-DEL or 'linux single'. In these cases, a BIOS password and LILO boot password, combined with a secure operating system, should suffice.

  • I believe, that if the authentication technique for Root is set to One Time Passwords, that you would have to edit pwd.db itself to revert to normal passwords, as I do not think that pwd_mkdb will make that change.

    So just use your own version of pwd_mkdb that is a little more obliging.

  • How to secure a Linux machine that people will have physical access to:
    1. Disable booting from anything but HD in the BIOS
    2. Set a BIOS password
    3. In /etc/lilo.conf, set a password on all linux images. Use the restricted option so you only need the password if you're modifying LILO parameters (normal boot will work w/o password, but linux init=/bin/sh won't).
    4. Encrypt the filesystem on the hard disk. Store the key on a floppy that you'll need to put in whenever you reboot. Guard this floppy with your life.

    There, now your box should be secure against physical attacks.
  • Okay, I don't claim to hate *BSD or know everything there is to know about *BSD or Linux.

    But, this article was completely full of statements with no numbers or facts to back any of it up. Infact it seems to want to trash Linux pretty bad by claiming to be much better in all the aspects mentioned in the article.

    First, off the comment about *BSD fragmentation and being so aged it's useless? Personally, I've never heard such rumors. And if I did, I wouldn't go taking them for face value. If you think that everything you read on the net is true. You have bigger misconceptions then these.

    And I don't think Linux is slower in any regard or truely fragmented. I do however think that some distrobutions have gotten sloppy though. And in turn performance isn't what it should be. Once again this isn't a problem. Surely with all the distros out there one should be able to suit your needs. Choice is good.

    The author also mentions all the applications out there for *BSD. Well, I'd bet the majority of the *BSD people out after installing *BSD run out for KDE or GNOME or some other major piece of GPL'ed software. So even though I don't think it's wrong of them to use GCC for there needs(isn't that what it's there for). I do think it is wrong of the *BSD communities to complain about the GPL license. By now most people should know this is a personal prefrence and nobody is going to change anyone's mind.

    And here is a quote ment to start a flame war.

    "But many are simply curious about why a new user would choose Linux over FreeBSD, despite FreeBSD's technical superiority."

    Well, that statement should have flushed the last of the credibility this author had left. Obivously, he is bias and this just adds to the rest of the FUD he is spreading. Once again, these are all his personal opinions and not facts. He seems to have made these opinions public to confuse newbies and put down Linux.

    The author also mentions that some scripts he wrote broke when upgrading. And that upgrading the to glibc was a pain. I guess he was expecting progress to be held up because he wrote a few scripts and didn't like upgrading his compiler. Next time I'm sure they will check in with him first. Once again I think that this is a common mistake of expecting everything to be hand feed. Even though it's software that is in *developement*.

    The only problem I have with *BSD? Well, I can tell you that I'm not fond of the licensing. And I'm definately sick of these *BSD vs. Linux wars going on. And that I'm starting to become a little disappointed in Slashdot's choice of articles lately. But, don't think I don't love you anymore Rob. I do appreciate this site, thanks(to everyone at Slashdot and Andover).

    Conclusion:
    Don't give this article a second thought. Don't go flaming this guy. If you feel the need to correct him. *BE POLITE*
  • That was *humor*, as others have pointed out. I prefer using Novell for file/print services and FreeBSD for tcp services. Linux is (apparently) on the WatchGuard firewall.
  • With BSD kernel securelevels:

    -1: Permanently insecure.
    0: Insecure. Anything is possible.
    1: File flags (e.g, schg, sattr, sunlnk, etc) cannot be modified. No direct memory access.
    (if you run xdm, raise the level in Xsession or some such so that it happens AFTER x starts)
    2: Same as 1 + No direct disk access (can't write directly to block devices)
    3: Same as 2 + firewall rules can't be changed.

    Very good things, these levels.
  • Yeah, you did ;)
    In Stephenson's Cryptonomicon the Ordo guys had a metal doorframe to their machine room. Embedded in the doorframe were wire loops. (You can guess it now).
  • I have seen quite a few comments on being able to
    bypass BIOS passwords with shorting the battery or disconnecting it. That's true of most systems, but for my old IBM PC330 (486DX2-66). The power on password came with the following caveat: "If you forget this password, there is no way to change it or reset it and the motherboard must be replaced."

    I never believed this was true until I finally got ahold of the internal Service Manual for this one. The corrective action to take on a unit that had been returned due to a lost Power-on password was to replace the motherboard!

    There was a second level of password that was kept that could be reset if you were too chicken to use the power-on. Man, sometimes IBM stuffs the damndest stuff into their BIOS and board designs.

  • Very interesting. In order to use real security and really strong crypto DOJ has to import crypto. This does not stop them from screaming about export restrictions though...
  • Since all of these OSes have different kernels, and different versions of gcc, your "benchmark" literally means nothing. Even something as simple as the compiler options in the makefile void your results.
  • I gave OpenBSD a go on two systems - the first one it crashed repeatedly while recompiling the kernel, the second it couldn't recognise the ethernet card (couldn't even get up to the stage of recompiling the kernel)
    FreeBSD did the same thing on the second box - couldn't recognise the ethernet card. While comparing the ethernet driver sections of the OpenBSD kernel source and the Linux kernel source, I noted that Linux supported 4 times as many chipsets as the BSD's, including the one for the card in the second machine. I chuckled actually as *BSD advocates are always claiming that they have better networking than Linux. They can feel free to continue thinking that fallacy, there were some other strong points to OpenBSD that I liked a lot and its a shame that I can't run a BSD system due to severe lack of hardware support in their kernels.

    Of course the NetBSD crowd are now going to tell me that its my fault for not using NetBSD - but don't bother, I already checked and the card isn't supported with that either.
  • I agree, I had a lot of fun messing about with OpenBSD (the only one I got to have close to fully installed) and it is a very nice system. I guess I'm mostly disappointed that I couldn't continue due to the problems I experienced.

    One thing that did surprise me was that ssh was not included - I had to grab it from ports. There were buttloads of other security/crypto stuff though.
  • I use both.

    They both do good jobs at the same thing. I personally like OpenBSD's NAT implementation (all you have to do is add -alias to your pppd command line and you have NAT) but at the same time, I like alot of things about Linux too.

    Using the tool that I like for the job at hand.

    Try both! Learning something new never hurts and who knows... the knowledge will probably come in handy some day!
    --
  • As for OpenBSD's security, 2.5 years without a security alert speaks for itself I think.

    That means that for the last 2.5 years, not enough sites have been running OpenBSD for it to be worth trying to crack.

    There is no doubt that the OpenBSD team have done a better job on out-of-the-box security than any other free system out there, but that does not mean that the system is uncrackable. They would be the first to tell you that. As the system's popularity grows and it becomes a richer target, you will start to see OpenBSD security alerts.
  • You need to connect the (obviously metal) doorknobs and the elevator control panels to some hefty 220V relays which are controled by your own network management workstation...

    >clickety click

    ...Time to get back to xtank.

    -Chris
  • Place a good-sized charge of C4 (explosives) inside the case. Connect the detonator to tamper switches on all case junctions, and place cut-lines across the panels.

    If anyone tries to open that computer to bypass OS and BIOS security, it'll blow itself to pieces, taking the data with it. And prolly the one doing the crack, as an added bonus.

    The best place to put the device would be in a empty hard drive case. With the exception of the wiring for the tamper switches (and you could prolly get creative and hide thoses well), it would be indisquishable from a real drive. It would also put the charge right near the data it is designed to destroy.

    If you're brave, use a mercury switch so the thing cannot even be moved.

    If you're *REALLY* brave, connect a relay to the PSU, so the thing cannot even be *turned off*.

    If you ever want access to the system again, replace the keyboard lock with a decent lock, complete with a tamper switch, and still no one will be the wiser.

    This is, of course, supreme overkill, and highly dangerous to boot, but I suppose if you really don't want your data getting compromised...

    DISCLAIMER: If you actually do this, and then blow up something you wanted (data, a body part, whatever), do not blame me. I said it was dangerous.
  • Please correct me if I'm wrong, but isn't there a significant difference between OpenBSD and FreeBSD? OpenBSD is, I believe, the more secure one.
  • Jeez. I guess some people just don't understand the concept of A JOKE! It was obviously suppose to be A JOKE! Why is it that whenever somebody tries to make A JOKE there is somebody like you who replies to it as if it were serious.
  • I use Debian GNU/Linux 2.1
    If you boot into sigle user modem it WILL ask you for password. This has nothing to do with OS Kernel but with INIT scripts!
    The following is from my /etc/inittab file:


    # What to do in single-user mode.
    ~~:S:wait:/sbin/sulogin


    Screw RedHat for not using this!
  • Absolutely!

    Not to mention, the messages used as examples are 3 years old. This is all old water under the bridge, and if you refuse to use an OS because of the person who cares and feeds it, then thats your problem. Its BECAUSE of, not IN SPITE of Theo's single-mindedness that OpenBSD is as secure as it is.
  • What makes you think he's 'script kiddieish'

    I don't even understand what you're implying....that he only fixes bugs when he hears about a script going around? Thats just untrue...99% of the time when a new exploit is released, its already been fixed for months in OpenBSD

    Theo's a real smart guy. Yes, he can be a pain
    and he's not the friendliest guy around, but he's
    real smart, and knows exactly what he's doing.

  • You create an empty password in the shadow password file. After reboot you login as root and you're not asked for a password.

  • such a typical post!
  • And where would you store the key to unencrypt these FS's?

    So you'd have to put the key on a smartcard. Of which there would be copies (can't have the company go down because someone lost a smartcard)
  • I found info on the RAID support. Check their FAQ [openbsd.org] page like I should have. :)

  • by D3 ( 31029 )
    Actually, scroll up to section 12.2 not 12.4 like I linked.
  • there are simple utilities around to crack passwords on just about every bios around
    ^. .^
    ( @ )
  • by aithien ( 32819 )
    The whole thing was someone asked him to change the passwd file for them...

    Duh



  • Why would that be? Bad code in BSD, just like in Linux, get's ripped out. Especially if it's security-oriented.

  • tell that to the guys at phrack magazine who have a neat little openbsd compatible kernel module to subvert your tried and trusted OS. recommend checking back issues of phrack you BSD snob.
  • actually on IBM machines ( i have several ), the password is physically burned into a PROM chip with tamper resistant hardware. you cant remove it , documented or not.
  • if a user account is compromised, root access *will* be obtained one way or another. any admin would be horrified at your clueless statement above claiming that openbsd with a compromised user account would somehow be less vulnerable to attackers. fact is - user accounts is a last ditch attempt at raising the bar for attackers..once the guy logs in, its all over. BTW, those imapd vulnerabilities etc, would also affect openBSD..the kernel may be secure but utilities used could compromise the system. dont tell me that an openbsd systems with vulnerable KDE desktop is any more secure than a linux system with an imapd overflow. both systems are compromisable.
  • very simple solution - whack gnome/E with a winnt lookalike theme on the suns and tell your manager that you have an new kind of windoze running on the suns - an NT "port".
  • join the linux security auditing team..they even have a website to document audited software and a mailing list.
  • remove the spaces. its very enlightening tho..the first msg is posted below :

    Date: Wed, 25 Dec 1996 03:01:53 -0800
    From: "Jordan K. Hubbard"
    To: Aleph One
    Cc: freebsd-core@freebsd.org, freebsd-chat@freebsd.org, freebsd-questions@freebsd.org
    Subject: Re: IP Filtering to www.freebsd.org
    Message-ID:
    In-Reply-To: Your message of "Tue, 24 Dec 1996 23:15:43 CST."


    Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help


    > I have come across some disturbing information. It seem that FreeBSD
    > project is filtering IP packets comming from the OpenBSD project. In
    > particular access from 199.185.137.*, and maybe 199.185.136.*, to
    > www.freebsd.org. If this is true it marks a very low point on the history
    > of FreeBSD.

    This was started well over 3 months ago and is old old news. I fail
    to understand how this could only suddenly "come to light" for anyone
    involved with either project, we being very open indeed about it at
    the time (just search our mailing list archives for freebsd-hackers
    with Theo as the keyword).

    We were forced to filter the OpenBSD project because the same hosts
    and/or IP address range that it uses were also used in repeated
    attacks against the FreeBSD project's mailing lists and development
    machines by Theo Deraadt, who actually owns the network in question.
    These were not covert attacks, they were very open and Theo sent
    personal mail to several core members threatening to escalate them
    with the aid of (quote) "his cracker friends." It was at this stage
    that we added filtering, to try and block (in one small way) such
    attempts.

    When the OpenBSD project decides to have someone less criminally
    inclined as its representative, we'll be happy to discuss this with
    them. Until then, the man has shown himself unable to exercise a
    degree of self-restraint which would be consistent with someone of his
    age and responsibilities, and if he insists on behaving like a 14
    year- old cracker then he will obviously be treated as such.

    It is simply unfortunate in the extreme that he chose to use machines
    on the same network to conduct his attacks (also misusing a machine at
    MIT for that purpose, for which its admins were not amused), and has
    done the OpenBSD project a grave disservice in doing so. We have
    taken, I believe, only the most appropriate steps to defend ourselves
    from Theo's juvenile behavior and will continue to do so.

    > If the project is to succeed its in the basis of its quality, support,
    > and technical merits, and not by means of cheap tricks. Anyone wish to
    > comment?

    This is no "cheap trick", this is self-defense, plain and simple. I
    only regret that such defense against a "leading light" in the
    software community is necessary at all.

    Trust me folks, we have ample documentation for the claims I make
    above and if you'd like a second opinion, just ask the NetBSD project
    why it does precisely the same thing with packets from Theo's network.
    The list of people singularly unimpressed with Theo's behavior in the
    past and with great reason to distrust it in the future is long
    indeed. I can only suggest that the OpenBSD project find a more
    credible representatitive, and if you choose Kevin Mitnick as your
    best man then you probably shouldn't be too surprised if the FBI shows
    up at your wedding.

    Jordan

  • Very true. Even with a case lock on the machine, these are only measures meant to stall someone, prevent mischief, or simply make it not worth breaking into more than anything else. True security in the sense you're talking about means locking a machine in a door-less vault with no connectivity to the outside world. Of course... then you open yourself up to nose-toting talk show hosts. 8)

    Security in real life means making things secure enough that almost anyone tempted to break it will go on to easier prospects when they feel the effort isn't worth the end result.

  • There's an easy way to prevent someone from ever booting to a floppy drive on a server - take out the floppy drive. I've run my main server for years with no floppy drive in it.
  • No, it's perfectly safe as C4 cannot be exploded through heat alone. The mercury switch sounds kinda dicey though.
  • Isn't Hotmail run on FreeBSD?

    Are we talking about the Hotmail with the huge security hole in their cgi programming, which would be a security hole on any OS, even NT?

    If so, they apparently use a mix of FreeBSD, Solaris and NT, and their recent security holes have nothing to do with FreeBSD, or even NT for that matter.

    George
  • here's what you do; go in at night, when you'll be relatively alone. then you take all the Sun hardware out to your car, and drive home. then you send it to me. we can even do it COD. okay?
  • I assume if OpenBSD puts such an emphasis on security, shadowed passwords would be a default setting which would have stopped the method you've outlined here. I'm amazed that the disgruntled system admin didn't use them, but that may go some way to explain why he was let go.

    As for OpenBSD's security, 2.5 years without a security alert speaks for itself I think.
  • Ack, I just finished pressing submit before I hit my forehead with my hand and said "D'oh". Point taken :)
  • Um...that seems really stupid (re: avoiding security by allowing a boot from a floppy). The MUST be an option to NOT boot from a floppy. I can hardly believe that Linux has no way of letting you do this. Just set it in BIOS if all else fails. Probably someone figured that they might have to get into the box at some point later in time so they kept "boot from floppy" in the boot sequence. Anyway, *physical* security is always a prerequisite for electronic security. NSA doesn't keep their boxes on the front lawn you know ;)
  • You couldn't come up with irony this rich even if you were trying to make it up!
  • If you really care, many BIOS's allow you to change the boot order of the drives. This would mean that the machine wouldn't boot from a floppy unless there was no bootable partition on the primary harddrive. I've done this a couple of times for various reasons on my Windows box.

    -konstant
  • got my Mountain Dew, PIL in my CD... I'm ready to rock and roll.

    Thanks for the input!


  • But I do have an old Mac IIci that was "beefed" up (remember when 24mb of RAM was so big your friends would all come over to dig your set up?). Maybe I'll tinker with FreeBSD 68k, and maybe try it on one of the x86 boxes here at work.

    Not to start a debate or flame war, but for anyone who's used *BSD and Linux why do you prefer one over the other? Or the particular distribution of either that you use? I've only had experience with Debian (which I have read is more secure and I use more often)and RH (the first one I tried, mega mega easy to install and configure), and a weeeeeee bit on LinuxPPC.



  • One aspect of better is that BSD encourages
    programers to think through what they are doing while linux is more of a quick hack. That is Linux is more release quickly and often where as BSD is get
    it right, then release. The only advantage is if it is wrong BSD makes it easier to throw away that code as it isn't released.


    Does this also mean that it is harder to remove bad code if it does make it into a release?
  • Rather than rant about the finer points of the differences of the *.BSD family, I'll just congratulate Theo on some well deserved publicity. OpenBSD is by far the most secure OS available. Just ask the folks at DefCon...
    ________________________________________________ _
    $which weed
  • The only file systems which could help guard against this type of attack would be a cryptographic file system [unisa.it] or a steganographic file system [cam.ac.uk].
  • Simple, it is BSD, not SysV.

    There are differences, but you get used to that. I'm already in the habbit of typing "ps -aef;ps -aux;ps -ae;ps -ex;ps -ax;ps -a" of which normally only one returns what I was looking for. (Challange, guess which variant eash is used on - trick question, I may have one made up)

    Other than command line arguements, of which ps is about the worst few people will be able to tell the difference without being told. That is if you replcaed the login screen on any xbsd box with one that said Linux few people would notice the difference.

    I like the way freeBSD is configured, but I've only played with slackware 3.0 for linux, which is not a fair comparition.

    As a programer, I think that *BSD is better programed overall. This is not to say that *BSD is perfect, or that Linux is all bad, there are places where linux is better programed. Overall though from what I've seen the majority of cases leaves *BSD better. One aspect of better is that BSD encourages programers to think through what they are doing while linux is more of a quick hack. That is Linux is more release quickly and often where as BSD is get it right, then release. The only advantage is if it is wrong BSD makes it easier to throw away that code as it isn't released.

    FreeBSD has better networking code, though linux has cought up for the most part. Linux has better SMP, but FreeBSD is catching up. OpenBSD is more secure, netBSD is more portable. (Linux has been ported alot, but netBSD has more useful working ports, while many linux ports belong in the curisoity catagory due to the hardware limits)

    Finially, BSD is not GNU. This is religion for many people, but the fact it I don't like the GNU license. Your welcome to disagree, I don't worship the BSD license, just prefer it given a choice

  • http://24.112.147.221/bsdmirror.htm

    Please be gentle with my box... this may not be wise of me.

  • You missed one:
    7) BSD is all caps, and capslock sucks
  • <WHINE>
    1) BSD Sucks
    2) Linux is best
    3) BSD is too fragmented
    4) BSD is dying
    5) There is no software for BSD
    6) There is no hardware support for BSD.
    <WHINE>
    I said it so all you trolls don't have to.
  • Never used OpenBSD before, but this is from their faq [openbsd.org]:

    8.3 - I forgot my root password, what do I do now?

    A few steps to recovery

    1.Boot into single user mode. For i386 arch type boot -s at the boot prompt.
    2.mount the drives.
    bsd# fsck -p / && mount -u /
    3.If /usr is not the same partition that / is (and it shouldn't be) then you will need to mount it, also
    bsd# fsck -p /usr && mount /usr
    4.run passwd
    5.boot into mulituser mode.. and remember your password!
  • This has nothing to do w/ shadow passwords. The method he described will work even if you have shadow passwords. Even if the passwords were stored on another system and all over the wire data was encrypted w/ 5billion bit encryption you could still boot from a floppy and modify whatever files you needed to in order to disable said protection. Or you could replace /bin/login with /bin/sh. If you have physical access to the machine it is NOT secure.
  • Linux would have no way not to let you boot from a floppy. The BIOS handles booting, not the kernel. LILO does have some security options for not allowing paramaters to be passed to the kernel, but booting from the disk drive bypasses the hdd alltogether so it doesn't matter. Disabling it in the BIOS does nothing either; most mbs these days have a jumper that will clear the BIOS, and if that doesn't work you can just pull the battery. If someone has physical access to the box it is not secure.
  • Bail out of there while the getting is good. Sounds like the new IT manager there is a PHB of the worst variety.

  • There's an easy way to prevent someone from ever booting to a floppy drive on a server - take out the floppy drive. I've run my main server for years with no floppy drive in it.

    But unless you physically lock the machine up, or do something radical like fill the floppy drive connector with epoxy, you really can't prevent someone from opening the box and hooking up a floppy drive and resetting the CMOS memory...

  • Just because it isn't documented doesn't mean that it is impossible. At any rate, it still doesn't prevent moving the hard drive to another machine that can be compromised and then returning it. Also if the case is non-proprietary, motherboards are relatively cheap these days (under $100 for most of them).

  • What an incredibly poor design. Reminds me why I make a point of not buying IBM hardware. :-)

  • Damnit, hit submit at the wrong time.

    Here is a question. Supposing the opposite problem happens... Instead of forgetting the password, what happens if too many people (like a former employee for instance) knows what the password is... If its burned into PROM, how do I change it? Can I? If so, how many times before the PROM is full? This would seem to be a serious enough problem to make this 'feature' unusable even if you don't worry about losing/forgetting passwords.

  • The MUST be an option to NOT boot from a floppy. I can hardly believe that Linux has no way of letting you do this. Just set it in BIOS if all else fails.

    Its a hardware problem. Linux can't do anything to fix that, and neither can anything else. If you have physical access to the machine you can override anything (including BIOS passwords, by resetting the CMOS memory (either a jumper or shorting the battery momentarily)). Even if no floppy is connected, you can open the machine and hook one up. Or you can remove the hard drive the passwd or shadow file is on, hook it up to another machine and change the files.

    Unless you physically lock the machine up, it is not secure.

  • Yes, if the guy was really paranoid, he would have changed the boot
    sequence and password protected the BIOS, but it wouldn't have
    prevented "plan B" - which is to wipe the BIOS by opening the case, or
    to remove the HD and install it in another machine.

    And yes, I'm aware of the need for physical security; (the servers
    were stored in a locked, alarmed room.)

    I was just asking, because (as I said) this BSD shop told them that if
    it was running BSD, then there was no way anyone could break into
    them.

    So which OS's do you use that can prevent you from booting from a
    different volume? (be it floppy, hard drive, or some other medium.)
  • I've set up OpenBSD as a firewall here at my office and I love it. The system is stable, easily secured, and fairly fast. If a script kiddie put all that in motion, then more power to him. It's not about personalities, it's about a good operating system. Period.



  • The server is not pumping out many bits...
  • "...slower than molasass"

    I wonder if it's significant that the URL is in the subdirectory "teasers". ;)
  • "Did I forget anything ? ;-)"

    You might add an internal UPS so that case-breach disk destruction could continue happily even when the power cord is pulled. ;)
  • Slashdot, roasting on an open fire... ;)

    Seriously. back in 1995 I worked for a national ISP that I won't name. We had to build news machines. A lot of news machines. We had quite a few ISP customers, and they all wanted news.

    At the time, I was a Mac user. UNIX was the clunky thing I used to read my email and run traceroute with. I mention this only to show that I had no prior BSD/Linux bias.

    After much pain, we got Linux going (Red Hat 3.2, I believe, but don't quote me). A pentium 200 filled about 20 meg, then leveled out. Not bad.

    The FreeBSD 1.5 machine, with the same hardware, filled a DS3. (Boy, were those T1 customers hanging off that site *pissed*! But that's another story.) The FreeBSD box didn't so much as break a sweat.

    So, we plugged it into an OC3.

    The box finally leveled out at 80 meg. My gut reaction is that it was the cheap 100bT NIC that filled out.

    Of course, we eventually smoked the SCSI arrays (remember back when an 8 gig array was impressive?) But the OS just kept going, and going, and going.

    As a network engineer, FreeBSD earned my trust.

    Now, most people don't need to soak an OC-3. But those of us who do (Best, Yahoo, etc) tend to run FreeBSD.

    Your T-1 ISP? Either will work just fine.

    Your desktop? Linux will support your goofy desktop hardware.
  • Well, nice try, but the only one of your four steps that would actually accomplish the goal of securing a computer to which one has physical access is step 4 - Encrypt the filesystem.

    Steps 1 and 2 - disabling booting from floppies and CDs in BIOS and setting a BIOS password - are laughably easy to get around. Just pop the cover on the box. Most systems either have a jumper that lets you reset the CMOS or you can just unplug the battery that saves the CMOS memory. Bye-bye BIOS password.

    After that step 3 - setting LILO passwords - becomes moot because I will boot off a floppy| CD|second hard disk and just mount your Linux|FreeBSD|OpenBSD|NetBSD|Solaris|whatever partition.

    So only step 4, encrypting provides you with any protection. From the way you stated step 4 I am assuming you mean encrypting the entire file system and unencrypting at boot time (rather than unencrypting individual files on the fly during operation). That is the only practical way to achieve security when physical access cannot be controlled, but you better use a damn-big, randomly-generated key.
  • by Paul Crowley ( 837 ) on Wednesday September 01, 1999 @03:47AM (#1711667) Homepage Journal
    Many, many people use Windows NT to store and transmit top-secret data. Does that mean that NT is secure, or just that the expertise to properly evaluate security is much rarer than the willingness to believe marketing that says what you want to hear?

    And, of course, it can be misleading to speak of a "secure operating system" - security is a property of the system as a whole. A Windows NT mail hub can store and forward a PGP-encrypted message without the contents of the message being any more readable, and an OpenBSD machine can be configured with open "telnet" ports and guessable passwords.

    The care and effort put into OpenBSD's security aspects is of course useful and laudable, but it won't do you the user any good if you don't understand your own role in keeping the system secure.
    --
  • by DaveTerrell ( 923 ) on Wednesday September 01, 1999 @04:00AM (#1711668) Homepage

    I assume if OpenBSD puts such an emphasis on security, shadowed passwords would be a default setting which would have stopped the method you've outlined here. I'm amazed that the disgruntled system admin didn't use them, but that may go some way to explain why he was let go.

    This is not true. You can't directly get to a root shell like you can with single user mode (or, if single user prompts for a password, try lilo: linux rw init=/bin/sh --don't forget to umount /, then just reboot the machine, shutdown won't work) on linux. You can just pop in an install floppy and mount your / filesystem and edit the passwd file though. Physical access = root access. Shadowing the passwords doesn't change that, you can still edit /etc/shadow.

  • by Spectre ( 1685 ) on Wednesday September 01, 1999 @03:50AM (#1711669)
    *chuckle*

    In general, physical access to the machine allows access to everything, typically through a method such as what you employed. BSD is no different from Linux (or DOS, or NT, or about anything else) in this regard.

    Yes, a person could use a cryptographic hack to keep all file systems encrypted, but the performance hit is usually bad enough that most people find it far, far more economical (and effective) to lock the servers in a machine room with restricted access...
  • by D3 ( 31029 ) <daviddhenning&gmail,com> on Wednesday September 01, 1999 @07:35AM (#1711670) Journal
    Here we use OpenBSD as part of our IDS solution. It has a couple of qualities that make it a great choice. First, it is very secure as a default installation. Second, BSD in general has some of the fastest network sniffing capabilities of any OS. Third, some OS's like Linux and Solaris don't know how many packets they've really dropped so you can't tell for certain how good they are doing. Fourth, it is FREE. The DOJ has contractors just as any agency (even NSA has contractors for some things I'm told). If you get people that understand what they need and what works best for the situation it isn't surprising to see it used by Gov't.

    As for limitations, it comes with X and Netscape. Also, there are some new programs that are supposed to allow you to compile Linux binaries and run them. I haven't used this but it sounds cool. So, basically it isn't much more limited than Linux for software. Last I saw it doesn't support dual CPUs and I'm not sure about RAID so it gives up quite a lot to Linux there. Maybe once Linux becomes too mainstream and Linus too much of an icon, all the 'real' computer hacks will turn to OpenBSD for the next revolution? Just kidding.

    Lastly, I know that people have been donating hardware (like gigabit ether) that will help keep it a viable, quality OS.

  • by schon ( 31600 ) on Wednesday September 01, 1999 @03:45AM (#1711671)
    This reminds me...

    A couple of weeks ago, I got a call from a company that was letting
    their sysadmin go (and not on good terms, either), and needed someone
    to hack their (linux) servers, as nobody else knew root passwords; I
    got called in; downtime was not an issue, so (with the aid of a
    rescue disk) it was just a matter of rebooting the boxes and editing
    the passwd file...

    After seeing how simple it was to get into the boxes, they immediately
    asked if I could switch the boxes over to BSD, as the previous people
    they had called (a BSD shop) had told them that if they had used
    BSD, then there was no way anyone could get into the boxes, as BSD is
    "uncrackable."

    Now, I don't have any experience with BSD (I tried installing it, but
    there are no drivers for my home machine, which I use as a testbed,)
    so I didn't have any firm comeback; but I would like to know (from
    the BSD people who will be reading this) if the same technique I used
    would be possible on a BSD machine. (I'm hard pressed to think of how
    this could be done, short of encrypting the root FS, or something
    similar.)

    Can anyone shed some light on this? Is BSD really "uncrackable", or
    are these other guys just blowing smoke?

Let's organize this thing and take all the fun out of it.

Working...