Slashdot Mirror

But it's not 5-10% is it? It's orders of magnitude for some things. They haven't even fixed the double-halt bug in STABLE that cuts I/O performance in half in some cases.

Gimme a break... hlt hlt was fixed in both OpenBSD 3.7 and 3.6 stable branches.

The guards pages are only practical for larger allocations due to hardware limitations, as you say. Strings are protected by different means such as Propolice; in order to minimise the overhead of Propolice, it "detects" strings (as opposed to byte buffers) and specifically protects them with canaries to try and find overflows that would smash the stack (the local variable re-arrangement tries to put these buffers as close to the canary as it can at compile time). The string detection is a heuristic as gcc doesn't maintain quite enough type information when it reaches the code generation parts which Propolice touches. Also, there is a simple bounds checker built into gcc which looks for incorrect use of statically allocated buffers with some standard functions such as strncpy or sscanf (you'd be amazed how many people specify the buffer size wrong to a bounded function).

None of these are perfect of course, but each of the techniques has found bugs (hundreds in the case of the two mentioned above) in our source and ports trees. It's also great to see projects like CCured being developed at Berkeley; although the overhead is just slightly too high to be used "out of the box" right now, it still works great with select applications such as Apache. The underlying tool, CIL can compile most of the OpenBSD source tree (including the kernel) now, and the result even boots when using a null source-to-source transform.

There is nothing like OpenBSD running pf and carp. Dead easy to set up, works like a charm, and secure by default. One wonders why the editors seem to think OSS == Linux.

http://www.openbsd.org/faq/pf/index.html
http://www.openbsd.org/faq/faq6.html#CARP

There is nothing like OpenBSD running pf and carp. Dead easy to set up, works like a charm, and secure by default. One wonders why the editors seem to think OSS == Linux.

http://www.openbsd.org/faq/pf/index.html
http://www.openbsd.org/faq/faq6.html#CARP

Big apps still work after this change. And we've had native Java for a while now.

This presentation (by Theo de Raadt) gives a good overview of the security features in OpenBSD (beyond what's already outlined on the OpenBSD security page). It covers W^X, random stack displacements, random canaries to detect stack smashing, random library base addresses, random addresses for mmap and malloc operations, guard pages, privilege revocation, and privilege separation. One thing it doesn't cover is systrace.

This presentation (by Theo de Raadt) gives a good overview of the security features in OpenBSD (beyond what's already outlined on the OpenBSD security page). It covers W^X, random stack displacements, random canaries to detect stack smashing, random library base addresses, random addresses for mmap and malloc operations, guard pages, privilege revocation, and privilege separation. One thing it doesn't cover is systrace.

openbsd.org runs on Solaris and it hasn't hurt their image.

http://www.openbsd.org/faq/faq8.html#wwwsolaris

Yes, but it's not actually their site. This link should sum it up fairly well. Basically they're taking advantage of the University of Alberta's available bandwidth and as such the main OpenBSD ftp is at the mercy of whatever OS the U of A decides to use. If I remember correctly, that same FTP hosted a ton of other OS ISOs. I distinctly remember getting a Slackware ISO from that site back in the day, and there are/were others, I'm sure.

Ironically, www.openbsd.org runs Solaris, as evidenced by their own FAQ.

They could just run OpenBSD.

Well, no. If you read the OpenSSH project history here and the original SSH license here, it is clear that OpenSSH is not infringing anything.

The licence used for the version on which OpenSSH was based states that it can be freely used for any purpose, that derived works must be clearly identified as derived works (OpenSSH is so identified), and that if they are incompatible with the RFC protocol, they may not be called SSH or Secure Shell. By implication, the OpenSSH team could have just called it "SSH" and they would still not be infringing, under the terms of the original license, which allows derivative works to be called simply "SSH" or "Secure Shell," as I read it.

Since those days, SSH has become a commercial, proprietary, and monetized product, and they may not like the fact that it was once under a free license that allowed projects like OpenSSH to happen, but instead of whining about "They did just what they were allowed to do, boohoohoo!" they should just get out there and compete on merits like everyone else. Price, too, is a merit, and if the higher cost and proprietary license of SSH is not, in the eye of the purchaser, justified by any superior technical merits it may have, that's tough.

I like how Stallman and Theo De Raadt both have incrmental approaches. Continually chipping away.

E.g. here's some of the latest on OpenBSD and RAID:

"Take Adaptec for instance. Before the 3.7 release we disabled support for the aac(4) Adaptec RAID driver because negotiations with the Adaptec had failed. They refused to give us documentation."

and

"But having been ignored for so long by these vendors, it is not clear when (if ever) we will get around to writing that support for Adaptec RAID controllers now. And Adaptec has gone and bought ICP Vortex, which may mean we can never get documentation for the gdt(4) controllers. The "Open Source Friendly liar" IBM owns Mylex, and Mylex has told us we would not get documentation, either. 3Ware has lied to us and our users so many times they make politicians look saintly.

"Until other vendors give us documentation, if you want reliable RAID in OpenBSD, please buy LSI/AMI RAID cards. And everything will just work."

Ideas...
Ahh, well, they're already one step ahead of you on these things :-)

1. How bout a hardware based SSH accelerator for fast SFTP/SCP transfers?

http://www.openbsd.org/cgi-bin/man.cgi?query=ubsec &sektion=4 (as far as I know, hardware crypto accelerators are automatically taken advantage of for OpenSSH/OpenSSL applications)

2. GUI configuration in X/QT/GTK...ect...
http://www.webmin.com/standard.html webmin - has all the pretty check-boxes and drop-down combo lists you need. There are probably other solutions besides webmin that you can use.

3. Performance monitoring tools
Erm... top? I don't know what performance parameter you need to monitor. The OpenSSH scp client already gives you a transfer rate.

Moral of the story: Like many other unix things that are Good (tm), OpenSSH doesn't have to be all things to all people... one app that does one thing and does something well is the "unix" way. It's quite trivial in most cases to expand functionality by taking advantage of the modularity of these things.

Having said that, OpenSSH really does quite a lot of stuff.

Look here for the kernel level changes that OpenBSD has done.

You may want to familarize yourself with the current status of the OpenBSD system before commenting on its supposed "downfalls".

Gentlemen, behold! A troll being marked Insightful on Slashdot! OpenBSD are the ones with KNF, that's Kernel Normal Form, the style that all code in the base operating system (which includes OpenSSH) must conform to.

I believe that the OpenBSD/OpenSSH teams are beginning to do similar things (e.g. OpenSSH privilege separation), but I don't think they've taken the leap to providing more sophisticated access controls in the kernel.


See systrace (provide fine grained control over syscalls for any application):
http://www.openbsd.org/cgi-bin/man.cgi?query=systr ace&apropos=0&sektion=0&manpath=OpenBSD+Current&ar ch=i386&format=html

It looks to me like a security oriented access control tool, far beyond the two case exposed above, right ?
And easy to setup by the way...

What happens when you write a stoopid CGI and forget to escape a parameter, allowing a blackhat to execute a shell?

Nothing really harmfull: the Apache provided with OpenBSD is chrooted by default ;)

How do you prevent common mistakes from screwing you?

Well, it's pretty unfair to say that it isn't a preocupation on OpenBSD: they did a very hard work to have, for instance, a system that isn't sensible to buffers overflows anymore (google for W^X and propolice, among others). And they do many others things to mitigate the effect of potential vulnerability (like strong randomisation everywhere: pid, sources tcp ports, ...), lib adresses randomisations, etc.: this is all about preventing exploitation of yet unknown flaws.

And for a fine grained system policy control on OpenBSD, I really recomend the use of systrace (http://www.openbsd.org/cgi-bin/man.cgi?query=syst race&apropos=0&sektion=0&manpath=OpenBSD+Current&a rch=i386&format=html)
it's like a firewall for syscalls. Say, you're shell or perl interpreter runs on systrace: it can be enforced to only open file within $HOME, or to not write on certain directories, to not setgid() or to never chown() etc.
IMHO far more easy to setup and more "security oriented" than RHEL SELinux (by design, MAC is great, but more about fine grained users and file access management than about controling programs behaviour).

To understand better what systrace is about, just throw an eye on the provided bind (named) protection setup, it talks by itself i think:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/etc/systrace/usr_sbin_named?rev=1.5&content-typ e=text/plain

What happens when you write a stoopid CGI and forget to escape a parameter, allowing a blackhat to execute a shell?

Nothing really harmfull: the Apache provided with OpenBSD is chrooted by default ;)

How do you prevent common mistakes from screwing you?

Well, it's pretty unfair to say that it isn't a preocupation on OpenBSD: they did a very hard work to have, for instance, a system that isn't sensible to buffers overflows anymore (google for W^X and propolice, among others). And they do many others things to mitigate the effect of potential vulnerability (like strong randomisation everywhere: pid, sources tcp ports, ...), lib adresses randomisations, etc.: this is all about preventing exploitation of yet unknown flaws.

And for a fine grained system policy control on OpenBSD, I really recomend the use of systrace (http://www.openbsd.org/cgi-bin/man.cgi?query=syst race&apropos=0&sektion=0&manpath=OpenBSD+Current&a rch=i386&format=html)
it's like a firewall for syscalls. Say, you're shell or perl interpreter runs on systrace: it can be enforced to only open file within $HOME, or to not write on certain directories, to not setgid() or to never chown() etc.
IMHO far more easy to setup and more "security oriented" than RHEL SELinux (by design, MAC is great, but more about fine grained users and file access management than about controling programs behaviour).

To understand better what systrace is about, just throw an eye on the provided bind (named) protection setup, it talks by itself i think:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/etc/systrace/usr_sbin_named?rev=1.5&content-typ e=text/plain

You are misinformed, trolling or both. Most of OpenBSD's efforts in recent years have been directed at proactive security. OpenBSD was the first operating system to add ProPolice to its compiler, the first to implement address space randomisation, the first to add privilege separation to every daemon that needs privilege.

The result of this is that a security hole is either a) not exploitable to begin with, b) incredibly difficult to exploit, or c) not very productive even if it is exploited. All your caps-lock-on ranting misses this entirely.

I doubt that you want to educate yourself rather than ranting, but other people might be interested in Theo's paper on all this.

In addition to good, audited code and these proactive measures, OpenBSD includes systrace, which can enforce mandatory policy on application basis. It doesn't do everything that SELinux does, but it is far, far easier to use.

You zealots never seem to realize your conception of the system you disdain is necessarily going to be incorrect, because you aren't going to spend the time required to really understand it. Concentrate on cheerleading you chosen religion's good points and stop trying to point out the other guy's bad points, that way you can show some real insight.

Dude, cool down, and read my post again. I was not talking about software RAID, but software to manage RAID cards . RAID card manufacturers, with LSI as an exception, does not give documention unless it's under NDA or similar. If they have some application to control the RAID card it's typically a Windows and/or Linux binary.

Read the commentary to the OpenbSD 3.8 song.

So taken.

1. why are you running KDE on a server?

I never mentioned anything about servers. The poster favored using OpenBSD instead of RedHat, and since RedHat is a popular desktop distro, I was using KDE to highlight the main reason why I thought OpenBSD is unsuitable in that role.

what specific application has been updated that is not included in OpenBSD?

Its server applications seem somewhat more up-to-date. That's probably due to the way it's used most often, as well as the fact that point releases of server software don't tend to be dramatically different than previous versions. That is, Apache 1.3.28 isn't radically different from 1.3.29, and staying current isn't quite as big a deal. On the other hand, do you really want to be using Firefox 1.0.1 (the version available in 3.7) these days?

Even on a desktop system, I can't imagine that I'd want something that just came out yesterday.

I understand about yesterday, but shipping with a version of KDE that was old two months before release seems a little behind the times.

I hope I don't sound like I'm chanting KDE! KDE! KDE!. That just happened to be the biggest thing I installed when I was experimenting with OpenBSD as a desktop, and the first package to make me start noticing how old a lot of the 3rd-party software really was when the release came out.

That said, I'm not an OpenBSD evangelist. I just didn't think that you made a very good point there.

Fair enough. By the same token, I'm not an OpenBSD hater at all. However, people who advocate replacing RedHat with OpenBSD really need to be aware of what they're asking for. Swapping out a DNS, Postfix, or Apache server would probably be an upgrade. Switching it in for a desktop probably would not be.

But OpenBSD ships with it's own, patched version of Apache which has numerous security enhancements.

You forgot about this. See the New Technologies section.

OpenBSD has systrace, which is easier to understand than SELinux.
http://www.openbsd.org/cgi-bin/man.cgi?query=systr ace&apropos=0&sektion=0&manpath=OpenBSD+Current&ar ch=i386&format=html
Here is a tutorial:
http://www.onlamp.com/pub/a/bsd/2003/01/30/Big_Sca ry_Daemons.html

In the past, OpenBSD was entirely about fixing bugs in the code, and in turn eliminate exploits.
However, things have changed. Besides doing that, they now added some additional checks & balances in the OS, since they realized that no matter how well they audit the codebase, there will always be at least one bug somewhere.
These days OpenBSD ships with W^X (memory pages are marked write or execute, but not both), propolice-patched gcc, privilege-separation in most daemons, and other such methods to "raise the bar" for the potential attacker. This is all in the default OpenBSD install, the user doesn't have to do anything at all to benefit from these protections. Just install and go, it's that simple. That's why I switched to OpenBSD after 9 years of having to secure my own Linux boxes, doing kernel patches with GRSec, etc. and still risking getting pwned through a kernel exploit (they seem to be getting common lately!)
BTW, for ACL in OpenBSD, there is systrace:
http://www.openbsd.org/cgi-bin/man.cgi?query=systr ace

Red Hat Enterprise Linux will join an exclusive community of trusted operating systems that have achieved this level of security

Why don't the security conscious just use OpenBSD?

Why don't you just install OpenBSD? Works very fine as a desktop, unless you require hardware accellerated 3D.

Newsflash - Linux is *not* "impenetrable". If you want a really secure OS, try OpenVMS or my favourite, OpenBSD.

You didn't auto-link the URL (hint:instructions below the Post Comment window) And its Foresight is at 0.9 release stage, not yet 1.0.
There are PPC Linuxes you could've recommended, but you didn't have the Foresight!

If you really want security, try http://openbsd.org/ for powermacs:
http://openbsd.secsup.org/3.7/macppc/ or for serious stability and security http://openvms.org/
Clam Anti-Virus is available for Mac OSX
http://www.markallan.co.uk/clamXav/

Have a look at the OpenBSD Project Goals. Do you see any goal about "intended for business"? Here is the gist of it if you search the mailinglists: The OpenBSD developers develops for themselves, and that it incidentally is usefull for other is a nice bonus. They are not very interested in "markets" or "market share".

At the moment it seems that FF is a bit more secure than IE. FF might however not be as secure as it possibly could be. Maybe FF developers should do security audits just like OpenBSD team does. I think audits and emphasis on overall code correctness would be a great competitive advantage against IE.

Couple this with the fact that 99% of all of the world's software is written for x86 and you have a very large inertia to overcome in order to change the ISA.

Really? Better tell the Debian guys then. They ship their distro for 10 platforms. Then there's the BSD's: NetBSD takes the cake with 49 platforms listed as stable. OpenBSD has 16 platforms and FreeBSD has 9 platforms.

I think you'll find that most software nowadays is written in a high-level language and not for a specific processor. If you have access to that source code and a compiler for your processor, then it doesn't really matter what it is. The big issue in porting is the operating system and GUI (and other) toolkits, not the CPU architecture.

That's not funny.

I think the folks who suffer with Windows are used to rebooting for all sorts of reasons. E.g. IE runs too slow, my app just crashed, I need to install a new program, something is not working, ...

Due to their inability to admin their own machine, some resort to throwing it out and trying again, with new hardware.

I think it is the Unix admins who have the fetish for the no-reboot. Or perhaps a single, precisely done reboot, to remotely bring up a machine with an entirely new OS.

Similary, folks who use windows think they need anti-spyware, anti-virus, extra-special firewall crap --- because they think there's no way a computer can withstand the tide of crap without extra-special help. It is just impossible to imagine that an OS could withstand it all.

Lately it seems that hardware companies are in the game -- e.g. Intel processors with features designed to make up for the deficiencies of Ballmer's bunch in Redmond.

If I drank a strong tea brewed from Theo de Raadt's toenail clippings I could glean knowledge from perhaps a couple of days in the future, but beyond that you're getting into the realm of Xenu.

There's lots of reasons why a Windows site might be hosted on Linux, the least of which is, who cares, web hosting is web hosting.

- Vista Secure Edition
http://www.openbsd.org/
- Vista Compact Edition
http://www.damnsmalllinux.org/
- Vista Instant Edition
http://www.knoppix.org/
- Vista Grandmother Edition
http://www.apple.com/
- Vista Open Edition
http://www.debian.org/

You would be incorrect, friend. While NetBSD is a very secure operating system, OpenBSD believes in proactive security, that is, fixing problems before they become problems. They regularly undergo code audits and otherwise focus on clean, secure code. More information is available here: http://openbsd.org/security.html

You should only use free software and avoid unfree software.

I think that they already did.

Tsk, you added an "existing" where there shouldn't have been one.

There are various levels of paranoia you can aim for when performing a code sweep, depending on your gcc compiler options (-Wall -Wsign-compare -Wshadow). So we tend to do it in stages so that we can look at chunks of code rather than huge unparsable diffs that will let bugs sneak through (there were a number of integer warnings slowly fixed in earlier releases, but Damien went through and cleaned up all the remaining ones for this release).

The atomicio change is definitely proactive, as we updated its API to be safe with respect to signed/unsigned comparisons. The old atomicio would return a -1 on error (ssize_t), as it was designed to provide a close match to the normal read/write calls. However, if there is no error, then the result has to be cast to an unsigned int (size_t), as the size of the buffer passed could possibly be larger than the value that a signed integer could hold. You can see the potential for confusion there...

Now, the new atomicio is much simpler. It always returns a size_t, and 0 is used to indicate an error. Because 0 is also used to show EOF, we simply use the errno variable to detect that (by setting it to EPIPE).

A typical use is now:


if (atomicio(read, ..., len) != len) err(1,"read");


which is nice and easy to read. These integer bugs are tedious and hard to spot; a very dangerous combination in open source software as it means only the bad guys tend to look for them :)

try these :

Free Linux

Open Linux

Net Linux

Would you be willing to post your deny file? Im interested in adding one myself and dont know where to begin!

spamd.conf

Why not also mention what a con-artist company it is?
http://www.morphos.net/

or what OpenBSD thinks of Genesi?
http://www.openbsd.org/pegasos.html

http://openbsd.org/zaurus.html

Nuff Said.

OpenBSD has 100% free reverse engineered Atheros. Theo et al would not have it any other way. Have you not heard of their recent crusade for free wireless drivers?

ath(4) manpage:

HISTORY
          The ath device driver first appeared in FreeBSD 5.2 using a binary-only
          HAL module which was ported to NetBSD 2.0. The driver using a free HAL-
          replacement first appeared in OpenBSD 3.7. (emphasis added)

here - they brag about having just one in 8 years. It IS possible to be fairly tight, but Msft has a long history of exploiting the right of not having any legal responsibility for whatever they slop out to customers. Why? They don't have to - it's the default os automatically bundled in with most computers whether the customer wants it or not.

Maybe an operating system such as OpenBSD which the reviewer has his written his own book about.

Sure. Everything that is part of the base OS, besides the kernel. Linux distros don't have a base OS, everything is just a package, and no distinction is made between packages you install because you feel like it, and packages that are required as part of the system. But on BSDs, the base OS is everything the developers maintain, and it is not installed using the package management tools.

For openbsd, everything in here:
http://www.openbsd.org/cgi-bin/cvsweb/src/
besides the sys directory (that's the kernel) is the openbsd userland.

No, noone is going to convince you. This isn't a sales pitch. (Why was that moded interesting? Its not).

Also, BSD is NOT linux. Read for yourself what they do. Here they are.

http://www.freebsd.org/
http://www.openbsd.org/
http://www.netbsd.org/