Slashdot Mirror

I think the name Script Kitty is funnier...

It is, but Illiad wasn't the first to think of it. Check out the Script Kittie on the OpenBSD 2.6 cover art. He isn't explicitly called that on the cover, but that's what he's called on the t-shirt page.

I think that the cat is sort of dumb (The UF cat, not the BSD one!). Perhaps Illiad a bit distracted about going to CeBIT? Or maybe his creative juices are running low after the kick-ass "Pitr the Borg vs. Crud Puppy" arc.

Hmmm, what should Pitr's "Borg name" be? I'm wagering on "vi of IX". (Emacs users, just ignore that.) ;-)

Yes, it's official. Jesus uses vi.

I am the Lord.

I think the name Script Kitty is funnier...

It is, but Illiad wasn't the first to think of it. Check out the Script Kittie on the OpenBSD 2.6 cover art. He isn't explicitly called that on the cover, but that's what he's called on the t-shirt page.

I think that the cat is sort of dumb (The UF cat, not the BSD one!). Perhaps Illiad a bit distracted about going to CeBIT? Or maybe his creative juices are running low after the kick-ass "Pitr the Borg vs. Crud Puppy" arc.

Hmmm, what should Pitr's "Borg name" be? I'm wagering on "vi of IX". (Emacs users, just ignore that.) ;-)

Yes, it's official. Jesus uses vi.

I am the Lord.

What weight does your opinion carry in security matters, oh anonymous coward. Prove to us why it should be considered.

I urge anyone reading this thread to go out and look into this yourself. As a five month old newbie of OpenBSD, I am not qualified to discuss the technical merits of security issues surrounding Linux and OpenBSD. However, I have read the opinions of those who are qualified to make the judgement call, and time and again I have read that OpenBSD is the champ. Not once, ever, have I seen a credible security expert state that Linux is as secure as OpenBSD, default install or otherwise. Pound for pound, hour for hour spent administering the firewall, I'd wager that OpenBSD is the best fighter in the world (not to mention faster at dealing with network traffic).

And as far as exploits go, check out the turn around time on security patches to OpenBSD as compared to Linux. When a problem is discovered on OpenBSD it is patched NOW. Here's something Theo de Raadt (OpenBSD head developer) had to say about the timely addressing of security issues by various factions of the open source movement:

"The various failed Linux and FreeBSD "security-auditing" mailing lists are living, er, I mean dead, proof that the distributed nature of `open source' isn't enough of an assist. Speaking about ALL of these lists, they have always just done nothing except chit-chat.

For instance, about a month ago, someone on the FreeBSD auditing mailing list reported about 80 programs that were just 'crashing'. The list this happened on had just come to the conclusion (like we had 3 years earlier) that increasing quality in all areas is better, and leads to security improvements, by accident if you like. In my mind, seeing 80 bugs being reported just like that is really nice. So what did they do? They fixed about 7. Three days later, by the time they had fixed about 7, we'd fixed 79 of them. As far as I know, they've still not fixed the other 73. They were er, `distributed'... but we were APPLIED."

Here is a link to the OpenBSD press page. This will lead to some qualified opinions on the subject of OpenBSD security. Perhaps a little one sided, but it should only be considered a start: http://www.openbsd.org/press.html

I'll leave you with three quotes gleaned from Slashdot interviews of people qualified to comment on the security offered by OpenBSD:

"In retrospect, I wish I /had/ chosen OpenBSD ;-)

And I would certainly choose OpenBSD over GNU/Linux if I were building a firewall, or an intrusion detection system (based on say, Marcus Ranum's NFR) where packet capture at wire speed was important. (No - that tells you nothing about CCTA's network architecture....)"

-Mick Morgan, CCTA

"All of those operating systems are (resonably) securable, in theory, but if you want to make the job of securing a box easier, why not run OpenBSD?"

-Tweety Fish, cDc

"I -know- this is a Linux crowd, but I'm tellin' ya, take a look at OpenBSD for PROACTIVE security when it comes to that mission critical firewall box, network monitor, webserver, etc."

-DilDog, cDc

OpenBSD is the most secure OS around today. You can make an excellent firewall with it. If you don't know much about your network security, you need to get working on it. DL the install disk, do an FTP install on an old machine, and get learning how to set it up.

I've been using it for five months and it is awesome. Easy to install (newbies: be sure to read the directions), everything works without a lot of messing around (something I can't say about the other freenixes I've tried), and version 2.6 now has OpenSSH to allow you to securely administer your machine (not like it needs much once you have it up and running). Just check out ipnat (network address translation) and ipf (packet filtering) on the OpenBSD website (the man pages are the place to look) for more information

It is definitely better to run a basic OpenBSD firewall than to have Linux, Windoze, Solaris, or whatever else hooked up directly to the pipe. Run it on as little as a 486 with 8MBs RAM and a 200MB HD (you could probably run it on less, but I have only used it with the above minimum hardware). And if you really wanna get funky, run it as your workstation. Lotsa of programs have been ported to it, and the rest you can run using Linux emulation.

Check it out: http://www.openbsd.org/

Also, for those of you interested in OpenSSH outside of OpenBSD use: http://www.openssh.org/

For those of you with lingering doubts about ease of installation: five months ago when I first put it up, I was virtually clueless about Unix. I had muddled around with several Linux distros (Red Hat, Mandrake, Slackware, Turbo, Suse, Caldera, and Corel to be precise) but none of them worked as flawlessly as many Linux proponents say (two of them crashed on me (Mandrake and Corel), and many times library inconsistencies made my life a living hell when installing software from the Internet). It took me two weeks of spare time to figure out enough about OpenBSD to go ahead and install it with ipnat and ipf enabled. Since then I have learnt more about packet filtering in my spare time and tightened things up further. The machine has been going for 5 months strong and only came down once because I wanted to upgrade it to OpenBSD 2.6. In short, if I could get it running in two weeks, any regular moron should be able to do it in one, and any Unix knowledgable person should be able to get it going in a couple of hours.

I use Linux and OpenBSD. As a matter of fact I just upgraded to OpenBSD 2.6. I don't think there's any need to blast Linux's dev style or what not, though. There's a need for both, and plenty of room for all.

Whats the point of yelling at eachother?
I don't think "The BSD developers have had different motivations" than Linux developers. We all just want software that doesn't suck, right?

http://www.openbsd.org/

Check out this cool OpenBSD T-shirt, a shirt any Linux user would be proud to wear.

I use Linux and OpenBSD. As a matter of fact I just upgraded to OpenBSD 2.6. I don't think there's any need to blast Linux's dev style or what not, though. There's a need for both, and plenty of room for all.

Whats the point of yelling at eachother?
I don't think "The BSD developers have had different motivations" than Linux developers. We all just want software that doesn't suck, right?

http://www.openbsd.org/

Check out this cool OpenBSD T-shirt, a shirt any Linux user would be proud to wear.

Although I hate to step on another BSDs toes, FreeBSD is just a lot of hype. If you really want to use a secure BSD there is only one choice: OpenBSD. OpenBSD is the most secure operating system available. FreeBSD is one of the worst from a security perspective. The biggest flaw in FreeBSD is their "security by obscurity" policy. When a problem is reported, the FreeBSD core team tries to hide it as long as possible hoping no one knows about it. Usually they are busted and caught with their pants down when a CERT advisory is released. The script kiddies know about the flaws. So the disservice is being done to the end users and ISPs who trusted FreeBSD. With OpenBSD you can be sure that we believe "security through obscurity" is the worst possible policy. We never try to hide the flaws. When we find a hole, we tell you about it immeadiately, and then get down to the business of plugging it. That's the OpenBSD way.

FreeBSD is one of the least secure kludges available. If you want security, go with the really secure system OpenBSD. FreeBSD gets all the publicity but this time it is backfiring. All hype and no security makes FreeBSD a dull boy.

Theo has been telling the FreeBSD guys that this was a disaster waiting to happen. The FreeBSD core team laboring under a NIH -- not invented here -- syndrome refused to make the needed security changes. If you want a secure OS, FreeBSD is a bad choice. What do I recommend? OpenBSD.

You CAN however do quite a lot to prevent being a source, or at least an untraceable source - you should take great care that no network traffic leaces your network whith bad (=not your own) source address. If this simple precaution was in more widespread use, tracking this stuff would be much easier

This is only a start. You must also secure your hole bnetwork against intrusion. It's difficult, especially with the lack of quality of Windows. In my mind OpenBSD has gone the farthest with out of the box security. Even then it's possible an exploit may be found.

Using firewalls helps with security, but they still aren't fool proof. Systems behind them can still be compromized, but it's more difficult. My rule I setup systems with is if it must be accessable from the internet, then only those ports that need internet access are routed to it and from it by a seporit firewall system. Any other system must reside behind a NAT or masqurading firewall. This general rule helps alot with securing a site.

Unfortunatly this is only the tip of the iceburg. many other things need to be done. We maby should have an Ask Slashdot on securing systems and networks. Possibly one on each of the major OSes and on networks in general.

the Internet's most central ideology has been promoting a certain kind of freedom.

Many people can't afford it, others don't have the technological skills to use it well.

Computing analysts and legal scholars increasingly believe that despite revolutionary advances like OS, the Net is moving away from its founders' vision.

Not one of them - with the possible partial exception of IBM - has embraced or even flirted seriously with an open source model for doing business.

Thomas Jefferson wrote passionately about a new kind of democratic culture in which ideas moved freely all over the globe.

OpenBSD
And no, I *DON't* mean Open Blue Screen of Death.

OpenBSD has very nice man pages. Check is out here.

OpenBSD has very nice man pages. Check it out here.

Second consider using OpenBSD as the OS on the web server. Use the included IP Filter software that ships with OpenBSD, in addition to the packet filter in step 1.

If you are using Apache for your HTTPd, compile it with as few modules as possible, and no dynamic module support.

To really go whole-hog on security, you could block ALL protocols except HTTP and HTTPS, and have all user uploads and other account management go through cgiwrap on a HTTPSD instance.

Personally what I do for friends who want FTP access is use a One Time Password (S/Key or the like), but the average user probably won't be willing to deal with OTP.

First off.. Do not just "Scrub" the system. Wipe the HD, LLFing if possible. Backup data files first, via the network to a known good server first (via anon FTP so any remaining sniffers, etc, will not read any important password).

Then go and reinstall a recent Linux distro. I recommend Slackware. It may not have the bells & whistles of Red Hat, but its BSD-style init scripts are easy (easy as config.sys and autoexec.bat) to learn, and tends to ship with reasonably secure daemons. Of course, OpenBSD is another possible solution :-)

Now, if you want to just give them FTP access (and nothing else), ProFTPD provides a nice solution. Granted, earlier versions had some interesting security holes (poke), recent versions have been a lot better security wise. Set it up with mod_linuxprivs (which uses the POSIX.1e interface of 2.2.x and later kernels to drop all root privs except for the ability to bind to ports less than 1024). (For the configure impaired, try "./configure --prefix=/usr --with-modules=mod_linuxprivs").. This lets them have ftp access (I'd also recommend you setup ProFTPD to chroot the various users to their homedirs). Disable telnet. Install SSH or OpenSSH and only allow your own login to use it (login.access allows this). Only allow your user to execpt su (perhaps as part of the wheel group), and have your root password as something other than your normal account password. At this point, you will have a secure system, FTP access for normal users, and secure remote access for your own administration. Of course, this doesn't get you out of your duties to monitor Bugtraq for possible advisories. I also recommend (very much so) that you read LASG -- the Linux Administrator's Security Guide. It's very good :-)
---

Lest the Slashdot community get too holier-than-thou when it comes to security, let us remember that GNU/Linux has had its share of security problems over the years.

Now, of course, GNU/Linux developers are generally faster than Microsoft when it comes to fixing security holes and they don't, as a rule, engage in the same coverups and spin control as the Microsoft's PR flaks, but the question remains, why are there so many bugs in the first place?

Other open source operating systems, such as FreeBSD, NetBSD and OpenBSD have had security problems, but not in such numbers as the various GNU/Linux distributions.

Rather than making fun of Microsoft for its own failings in the security realm, GNU/Linux users and developers could better spend their time improving the security of their OS of choice.

It takes dedication and commitment to make a good open product into a quality open product.

... and this coming from someone with 5 Linux boxen (among others)...

OpenBSD notes on the Canadian Export Control List
Here is a link to where Marc Plumb has drawn some general conclusions about exporting crypto from Canada
It appears that crypto that is public domain has absolutely no restriction as far as the Canadian Government is concerned, but if it originated from the USA, then it has to be approved, and if its not public domain (free) then a permit must be acquired. Interesting to see that the US gov has charged people for exporting crypto from Canada. (Canadian and american?)
Oh, and I'm a high tax paying Canadian myself.

The Kerberos system authenticates individual users in a network environment. After authenticating yourself to Kerberos, you can use network utilities such as rlogin, rcp, and rsh without having to present passwords to remote hosts and without having to bother with .rhosts files. Note that these utilities will work without passwords only if the remote machines you deal with support the Kerberos system.

For more, read it online at http://www.openbsd.org/cgi-bi n/man.cgi?query=kerberos.

They've probably already GOT ultra-secure versions of OpenBSD for PC-based, single-processor servers, but Linux isn't just for PC's or just for one processor.

OpenBSD branched from NetBSD and therefore it has been ported to a great number of hardware platforms (and could be ported easily to many more). See http://www.openbsd.org/plat.html for a list.

I'm not sure if OpenBSD (or NetBSD, for that matter) is multiprocessor enabled. But FreeBSD is, and AFAIK it's far more efficient than Linux handling several processors.

It looks like someone in Washington is starting to realize the value of an open-sourced crypto. I wonder what made them think to include special considerations for OSS.

Considering all the recent press being accorded to Linux and friends (there's been some trial in which it's been mentioned as competition to the largest company ever, as I recall, not real firm on the details...) I'm not surprised at all. Not EVERYONE in Washington is clueless.

It's also worth noting that these rules are only in effect for 120 days, and will probably at least slightly revised at that time. If anybody reading this has any say in the matter, perhaps addressing the issue of derivative open source works -- at least in the associated documentation -- would be nice. i.e., what do I have to do if I want to contribute crypto code to my favorite os (OpenBSD, that is...).

All in all, a very positive step. Yay.

"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."

It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!

You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely. :-) I wrote about this in a letter to Dan Gillmor. Essentially, you need to understand a struct tm. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.

If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:

% perl -we 'printf "Year is 19%d\n", (localtime)[5]'
Possible Y2K bug: %d format string following '19' at -e line 1.
Year is 19100

The following information about Perl and the year 2000 is a modified version of the information that can be found in the Frequently Asked Question (FAQ) documents.

Does Perl have a year 2000 problem? Is Perl Y2K compliant?

Short answer: No, Perl does not have a year 2000 problem. Yes, Perl is Y2K compliant (whatever that means). The programmers you've hired to use it, however, probably are not. If you want perl to complain when your programmers create programs with certain types of possible year 2000 problems, a build option allows you to turn on warnings.

Long answer: The question belies a true understanding of the issue. Perl is just as Y2K compliant as your pencil --no more, and no less. Can you use your pencil to write a non-Y2K-compliant memo? Of course you can. Is that the pencil's fault? Of course it isn't.

The date and time functions supplied with perl (gmtime and localtime) supply adequate information to determine the year well beyond 2000 (2038 is when trouble strikes for 32-bit machines). The year returned by these functions when used in an array context is the year minus 1900. For years between 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the year 2000 problem simply do not treat the year as a 2-digit number. It isn't. When gmtime() and localtime() are used in scalar context they return a timestamp string that contains a fully- expanded year. For example, $timestamp = gmtime(1005613200) sets $timestamp to "Tue Nov 13 01:00:00 2001". There's no year 2000 problem here.

That doesn't mean that Perl can't be used to create non- Y2K compliant programs. It can. But so can your pencil. It's the fault of the user, not the language. At the risk of inflaming the NRA: ``Perl doesn't break Y2K, people do.'' See http://language.perl.com/news/y2k.html for a longer exposition.

If you want perl to warn you when it sees a program which catenates a number with the string "19" -- a common indication of a year 2000 problem -- build perl using the Configure option "-Accflags=-DPERL_Y2KWARN". (See the file INSTALL for more information about building perl.)

Ferdinand de Lesseps was the Frenchman in charge of building the Panama Canal. He elected himself to undertake the daunting project because he had recently completed the Suez Canal under budget and ahead of schedule; de Lesseps managed this because of the stroke of an engineer's genius. He counted upon a similar serendipitous event in a pathetic, humanist fashion. After almost forty years and a couple thousand men, the French gave up.

My point is that you shouldn't count on a bug being found. OpenBSD does code audits because it is necessary to be pro-active about bug and hole discovery. It's not enough to say "someone...will probably find the bug, and it'll be gone within a kernel release or two." You can't count on serendipity.

Practical example: the man page for ln says that the syntax is "ln (source) (destination)". Of course, the "source" is actually what the link is POINTING TO, and the "destination" is the name of the link. Most people (including me) thought that it was the other way around, and made a mistake the first few times around. If the man page had an example section that showed "Example: ln -s /usr/src/linux-2.2.0 linux creates a link called linux pointing at the directory /usr/src/linux-2.2.0", then most of us wouldn't have made a mistake the first time around.

% man 1 ln

...
EXAMPLES

Create a symbolic link named /home/www and point it to /var/www: ln -s /var/www /home/www

Hard link /usr/local/bin/fooprog to file /usr/local/bin/fooprog-1.0:

ln /usr/local/bin/fooprog-1.0 /usr/local/bin/fooprog

As an exercise, try the following commands:

$ ls -i /bin/[ 11553 /bin/[
$ ls -i /bin/test 11553 /bin/test

files have the same inode; that is, /bin/[ is essentially an alias for the test(1) command. This hard link exists so test(1) may be invoked from shell scripts, for example, using the if [ ] construct.

Practical example: the man page for ln says that the syntax is "ln (source) (destination)". Of course, the "source" is actually what the link is POINTING TO, and the "destination" is the name of the link. Most people (including me) thought that it was the other way around, and made a mistake the first few times around. If the man page had an example section that showed "Example: ln -s /usr/src/linux-2.2.0 linux creates a link called linux pointing at the directory /usr/src/linux-2.2.0", then most of us wouldn't have made a mistake the first time around.

% man 1 ln

...
EXAMPLES

Create a symbolic link named /home/www and point it to /var/www: ln -s /var/www /home/www

Hard link /usr/local/bin/fooprog to file /usr/local/bin/fooprog-1.0:

ln /usr/local/bin/fooprog-1.0 /usr/local/bin/fooprog

As an exercise, try the following commands:

$ ls -i /bin/[ 11553 /bin/[
$ ls -i /bin/test 11553 /bin/test

files have the same inode; that is, /bin/[ is essentially an alias for the test(1) command. This hard link exists so test(1) may be invoked from shell scripts, for example, using the if [ ] construct.

Practical example: the man page for ln says that the syntax is "ln (source) (destination)". Of course, the "source" is actually what the link is POINTING TO, and the "destination" is the name of the link. Most people (including me) thought that it was the other way around, and made a mistake the first few times around. If the man page had an example section that showed "Example: ln -s /usr/src/linux-2.2.0 linux creates a link called linux pointing at the directory /usr/src/linux-2.2.0", then most of us wouldn't have made a mistake the first time around.

% man 1 ln

...
EXAMPLES

Create a symbolic link named /home/www and point it to /var/www: ln -s /var/www /home/www

Hard link /usr/local/bin/fooprog to file /usr/local/bin/fooprog-1.0:

ln /usr/local/bin/fooprog-1.0 /usr/local/bin/fooprog

As an exercise, try the following commands:

$ ls -i /bin/[ 11553 /bin/[
$ ls -i /bin/test 11553 /bin/test

files have the same inode; that is, /bin/[ is essentially an alias for the test(1) command. This hard link exists so test(1) may be invoked from shell scripts, for example, using the if [ ] construct.

Practical example: the man page for ln says that the syntax is "ln (source) (destination)". Of course, the "source" is actually what the link is POINTING TO, and the "destination" is the name of the link. Most people (including me) thought that it was the other way around, and made a mistake the first few times around. If the man page had an example section that showed "Example: ln -s /usr/src/linux-2.2.0 linux creates a link called linux pointing at the directory /usr/src/linux-2.2.0", then most of us wouldn't have made a mistake the first time around.

% man 1 ln

...
EXAMPLES

Create a symbolic link named /home/www and point it to /var/www: ln -s /var/www /home/www

Hard link /usr/local/bin/fooprog to file /usr/local/bin/fooprog-1.0:

ln /usr/local/bin/fooprog-1.0 /usr/local/bin/fooprog

As an exercise, try the following commands:

$ ls -i /bin/[ 11553 /bin/[
$ ls -i /bin/test 11553 /bin/test

files have the same inode; that is, /bin/[ is essentially an alias for the test(1) command. This hard link exists so test(1) may be invoked from shell scripts, for example, using the if [ ] construct.

Good to see that changed. OpenBSD 2.5 shipped with telnetd, ftpd, rlogin enabled by default. It was changed before the 2.6 release. See the CVS log here: http://www.openbsd.org/cgi -bin/cvsweb/src/etc/inetd.conf

I went through the 4.x to 5.x transitions for SunOS (and use both Linux and OpenBSD for research), so I know what you mean about the idiosyncracies.

I as ked about this on the OpenBSD tech mailing list, and Theo de Raadt as sured me that it didn't.

I as ked about this on the OpenBSD tech mailing list, and Theo de Raadt as sured me that it didn't.

I as ked about this on the OpenBSD tech mailing list, and Theo de Raadt as sured me that it didn't.

Subject: Re: Security Advisory: Buffer overflow in RSAREF2
From: Niels Provos
Date: 1999-12-04 22:45:20

In message , Gerardo Richarte writes:

To make this clear: in combination with the buffer overflow in rsaglue.c this makes possible to get a remote shell on a machine running sshd AND it also makes possible to use a reverse exploit to gain access on clients' machines, using malicious sshd.

I fear that this posting should have been even clearer. To sum the problem up more clearly:

ssh-1.2.27 (if compiled with RSAREF2) is vulnerable. Attackers can obtain a shell on the machine running sshd. The exploit uses buffer overflows in the RSAREF2 implementation AND in the rsaglue.c file in ssh-1.2.27. I am surprised that there wasnt a bigger outrage on the mailing list about this, it is quite serious!!!

On the other hand, OpenSSH is not vulnerable to this remote exploit. Since rsaglue.c was rewritten, OpenSSH does stricter parameter checking than ssh-1.2.27 and these recent problems in ssh-1.2.27 did NOT affect OpenSSH.

Nonetheless, OpenSSH users in the USA that use OpenSSL compiled with RSAREF2 should update their ssl library (since isakmpd or httpd may be affected), see previous postings on Bugtraq, and http://www.openbsd.org/errata.html#sslUSA

Another thing is worth mentioning, RSA could use the buffer overflow in RSAREF2 to scan machines in the USA for RSA license violation. For example, sshds that do not use RSAREF2 do will behave differently than those that do.

Information on OpenSSH can be found at http://www.openssh.com/
Information on OpenSSL can be found at http://www.openssl.org/

You must check what flavor of ssl you've got. If you have sslUSA, you might be affected. check the openbsd advisory on sslUSA for more info. --kelsey

Only users in the USA are affected by the RSAREF situation, which suits both parties poorly, as users get crappy support and RSA wastes uncompensated effort any time they have to fix it

Our good friend, Theo de Radt, said as much. OpenSSH checks the args to the RSAREF package strictly, and so is not vulnerable. SSH1 w/ RSAREF is vulnerable (and there is aparently a working exploit). Any packages that use RSAREF might also have holes (OpenSSL, etc).

Here is a good graphic describing the encryption situation :-) RSAREF, export restrictions, etc, all contribute to it.
---

Here's the OpenSSH advisory on the subject.

Some people think that you can get around stuff like that...

with your own flavor of *nix, you can make snprintf your standard, or use your own custom library...

So is OpenBSD a 20 year improvement? or should we start writing Linux in Java?

You will note that EROS takes the idea of reducing the number of nodes closer to the root of the tree as far as possible. (The introductory essays are particularly valuable to read.) Every program is passed exactly the access it needs to have which means that there are far fewer programs which run as root or something close to root (the pun with the root of the attack tree is unintended) and therefore there are a lot fewer potential ways to try to break the security.

For those who do not want to read the essays in detail, here is an explanation "from 20,000 feet" to give you a sense. Unix is based on the idea of an access control list. You have permissions based on who you are, and every process you run will (by default) have permissions to do on your behalf anything that you can do. EROS is based on the idea of a capability. Capabilities can be thought of as handles through which you can request some action and you can do nothing without explicitly being handed the appropriate capability.

The difference is obvious when you consider trying to cat a file. In Unix you hand a program like cat the names of the files you want it to open and trust it to do nothing other than what you asked. In EROS you have the capability to produce capabilities which we will call file-handles would hand cat the open file-handles from which it could read those files and be guaranteed that it is unable to talk to anything other than you, or read anything other than those files, since it has no other capabilities (not even the ability to produce another file-handle). Note that in Unix you explicitly have to trust that cat won't do anything else while in EROS there is no way that it could.

This ensuring that processes never have any ability that they do not need to have results in far fewer processes with sufficient permission to cause damage, and therefore results in the attack tree by default being substantially pared down from what is possible even in a heavily locked down Unix system. As a result verifying the security of the operating system becomes a far simpler task. While attempting to verify the security of a Unix system is possible, the OpenBSD folks have done an extremely good job of it, the equivalent task for a capability system is far simpler.

Food for thought. :-)

Cheers,
Ben

Btw, anyone who cares you can find a picture of the cover at: http://www.OpenBSD.org/images/openbsd26_cover.gif

However, I got my brother (high school, and *not* a Unix guru) to install it... heh heh. He got it up in one night (although messed up the swap partition setup).
I'm running it on a P100 with a 1.7 GB drive (anyone want to donate old Pentium, Pentium Pro hardware??) on a 100TX internal network.

After I reinstalled it, I started looking at the ports, and installing other programs. I am very impressed! I thought I'd miss the RPM way of installing - but the "make" function automatically updates or gets the latest version -now that rocks.

The docs, man pages are Excellent! They've really paid attention to what's going on. The install and the post-install process is very tightly integrated - check the afterboot man page, for example. I like the layout of the files - it's not a big "mess" like in RH where you go, "What the heck is this for, and this, and this..."

But seriously, I'd like to see more info about OpenBSD!! When I checked for OpenBSD here on /. about a week ago, there were only some 3 posts about it. I'd like to know what other servers out there are running on OpenBSD - I'm really interested in which e-commerce sites run it.

I'm still going to run RH behind my firewall, but OpenBSD has garnered my respect... So cheers Theo and gang!

First off, I want to thank everyone who has taken the time to respond so far. Just when I was despairing of /. as a useful information medium a great set of responses comes along.

So a lot of looking into it and I have definately decided to go with an *BSD for our servers. With the 2.6 OpenBSD release this looks like a good time to plan our move.

Then another issue hit me in private mail from a /. reader....

OpenBSD or FreeBSD ?

This is a question we have been asking ourselves as well.

OpenBSD advantages

• Most strenuous proactive code review
• Integrated cryptography
• Canadian legal advantages

FreeBSD advantages

• Greater ports library
• More populare support for hardware
• More common support options
• The FreeBSD team watches OpenBSD carefully, so security is note ver far behind OpenBSD
• More "linux like" installation software

Anything missing?

It is FREE... So you CAN use it.It is nice if you can support the cause via monetary means; but if you can not I am sure they appreciate your code and your thanks...

ISBN Number is..
ISBN 0-9683637-4-1
which is on the 2.6 Webpage

It's impossible to say since you haven't specified which models they are. There are devices in each of the categories you metioned listed in the release notes for the i386 port, though, at http://www.openbsd.org/i386.html

We are a small Internet development shop, running a few servers and a mixed bag of development stations. Currently, there are three Linux boxen on our network, running the latest RedHat releases. We are looking to put in three more systems, for a total of 5 running some Linux/UNIX like OS.

• A MySQL server box
• A Firewall
• A Mail/Fileserver
• 2 Webservers running Apache / PHP(Zend)

When we perform this upgrade, we are willing to change operating systems if there is a demonstrable benefit. Due to recent slashdot postings we have started looking at OpenBSD as our server OS. Now, we do understand that RedHat is not the only Linux distribution available, but we don't really want to get into a Linux/Linux war here. We don;t mind changing if we should for technical reasons - but the Linux world seems more hip and vibrant, and we really like the penguin T-shirts we have... so if we can stay on Linux then we want to.

So far, we like what we hear about OpenBSD - but we don't know if the things we like are inherent in the relative designs of OpenBSD or if they are results of policy choices by the OpenBSD team. If they are the results of policy decisions, then with any luck a Linux distribution could be found that exhibited the same characteristics?

Features we like about OpenBSD:

• It seems like the release/testing cycle is extremely carefully controlled. While a freewheeling machine with lots of OpenSource code on the desktop is a good thing, for a server it seems that a smaller group exercising testing/release control is a more controlled system.
• The integrated crypto looks great, the one time use passwords look like a big winner here.
• There are a lot of references to OpenBSD's security and stability - but none with any specific examples or technical backing.
• The file layout on OpenBSD seems like a winner, it looks like things live in a well thought out and logical set up - not in a mishmash like RedHat.

Assumptions:

These systems will be running the server software they need, and X11 + (Gnome||KDE) for administration and so on. They will not be running the latest stuff from Linuxberg or a bunch of things that would be on a desktop OS. So we are going to try very hard not to introduce any instabilities. We aren't going to be compiling running games, sound drivers and the like that integrate directly into the kernel.

The questions are:

1. Is OpenBSD more secure in some fundamental way that a well maintained Linux distribution?
2. Is OpenBSD more stable than a well maintained Linux distribution?
3. Will the OpenSource software we normally need (firewall, Apache, PHP4, Perl, Python) and so on probably compile on OpenBSD?
4. Does OpenBSD have something like clustering support (Beowulf) and failover?
5. Is the performance of a well maintained OpenBSD system better than a well maintained Linux distribution?
6. Does Linux have anything like the one time use password system?
7. Does OpenBSD support multiple CPU's better then Linux?

Thanks for taking the time, and hopefully we can keep the flames down to nothing and talk about technical issues this time.

We are a small Internet development shop, running a few servers and a mixed bag of development stations. Currently, there are three Linux boxen on our network, running the latest RedHat releases. We are looking to put in three more systems, for a total of 5 running some Linux/UNIX like OS.

• A MySQL server box
• A Firewall
• A Mail/Fileserver
• 2 Webservers running Apache / PHP(Zend)

When we perform this upgrade, we are willing to change operating systems if there is a demonstrable benefit. Due to recent slashdot postings we have started looking at OpenBSD as our server OS. Now, we do understand that RedHat is not the only Linux distribution available, but we don't really want to get into a Linux/Linux war here. We don;t mind changing if we should for technical reasons - but the Linux world seems more hip and vibrant, and we really like the penguin T-shirts we have... so if we can stay on Linux then we want to.

So far, we like what we hear about OpenBSD - but we don't know if the things we like are inherent in the relative designs of OpenBSD or if they are results of policy choices by the OpenBSD team. If they are the results of policy decisions, then with any luck a Linux distribution could be found that exhibited the same characteristics?

Features we like about OpenBSD:

• It seems like the release/testing cycle is extremely carefully controlled. While a freewheeling machine with lots of OpenSource code on the desktop is a good thing, for a server it seems that a smaller group exercising testing/release control is a more controlled system.
• The integrated crypto looks great, the one time use passwords look like a big winner here.
• There are a lot of references to OpenBSD's security and stability - but none with any specific examples or technical backing.
• The file layout on OpenBSD seems like a winner, it looks like things live in a well thought out and logical set up - not in a mishmash like RedHat.

Assumptions:

These systems will be running the server software they need, and X11 + (Gnome||KDE) for administration and so on. They will not be running the latest stuff from Linuxberg or a bunch of things that would be on a desktop OS. So we are going to try very hard not to introduce any instabilities. We aren't going to be compiling running games, sound drivers and the like that integrate directly into the kernel.

The questions are:

1. Is OpenBSD more secure in some fundamental way that a well maintained Linux distribution?
2. Is OpenBSD more stable than a well maintained Linux distribution?
3. Will the OpenSource software we normally need (firewall, Apache, PHP4, Perl, Python) and so on probably compile on OpenBSD?
4. Does OpenBSD have something like clustering support (Beowulf) and failover?
5. Is the performance of a well maintained OpenBSD system better than a well maintained Linux distribution?
6. Does Linux have anything like the one time use password system?
7. Does OpenBSD support multiple CPU's better then Linux?

Thanks for taking the time, and hopefully we can keep the flames down to nothing and talk about technical issues this time.

We are a small Internet development shop, running a few servers and a mixed bag of development stations. Currently, there are three Linux boxen on our network, running the latest RedHat releases. We are looking to put in three more systems, for a total of 5 running some Linux/UNIX like OS.

• A MySQL server box
• A Firewall
• A Mail/Fileserver
• 2 Webservers running Apache / PHP(Zend)

When we perform this upgrade, we are willing to change operating systems if there is a demonstrable benefit. Due to recent slashdot postings we have started looking at OpenBSD as our server OS. Now, we do understand that RedHat is not the only Linux distribution available, but we don't really want to get into a Linux/Linux war here. We don;t mind changing if we should for technical reasons - but the Linux world seems more hip and vibrant, and we really like the penguin T-shirts we have... so if we can stay on Linux then we want to.

So far, we like what we hear about OpenBSD - but we don't know if the things we like are inherent in the relative designs of OpenBSD or if they are results of policy choices by the OpenBSD team. If they are the results of policy decisions, then with any luck a Linux distribution could be found that exhibited the same characteristics?

Features we like about OpenBSD:

• It seems like the release/testing cycle is extremely carefully controlled. While a freewheeling machine with lots of OpenSource code on the desktop is a good thing, for a server it seems that a smaller group exercising testing/release control is a more controlled system.
• The integrated crypto looks great, the one time use passwords look like a big winner here.
• There are a lot of references to OpenBSD's security and stability - but none with any specific examples or technical backing.
• The file layout on OpenBSD seems like a winner, it looks like things live in a well thought out and logical set up - not in a mishmash like RedHat.

Assumptions:

These systems will be running the server software they need, and X11 + (Gnome||KDE) for administration and so on. They will not be running the latest stuff from Linuxberg or a bunch of things that would be on a desktop OS. So we are going to try very hard not to introduce any instabilities. We aren't going to be compiling running games, sound drivers and the like that integrate directly into the kernel.

The questions are:

1. Is OpenBSD more secure in some fundamental way that a well maintained Linux distribution?
2. Is OpenBSD more stable than a well maintained Linux distribution?
3. Will the OpenSource software we normally need (firewall, Apache, PHP4, Perl, Python) and so on probably compile on OpenBSD?
4. Does OpenBSD have something like clustering support (Beowulf) and failover?
5. Is the performance of a well maintained OpenBSD system better than a well maintained Linux distribution?
6. Does Linux have anything like the one time use password system?
7. Does OpenBSD support multiple CPU's better then Linux?

Thanks for taking the time, and hopefully we can keep the flames down to nothing and talk about technical issues this time.

Yes , PCMCIA cards will work I use 2.6 on my Thinkpad 755CE currently. Make sure and check the README.i386 (assuming you have an i386 of course) for suported NICs and SCSI controllers.

Oh. I just saw their new title graphics on OpenBSD.

Now we have a little war-monger blowfish. wee.