Slashdot Mirror

... there's vnconfig. It's less feature-rich than TrueCrypt, but it works.

There are flavours for OpenBSD, FreeBSD, and NetBSD. Here's a handy introduction.

Would love to be able to run a modern OS on Harvard Architecture hardware - something like OpenBSD on a Data General AViiON with lots and lots of Motorolla 88K CPUs.

More recently, a big honkin hypertransport backplane with a mix of quad-core Opterons and FPGAs.

Bonus points if there's an onboard analog processing unit.

Soundcard would have to be the LynxTWO-C: six input channels of 200K samples per second at 24-bits per sample.

I believe you are wrong. Almost right, but wrong.

You can't copyright an algorithm. That would fall under patent law as it is simply an idea.

You can copyright the code, comments included, as it is an expression of an idea.

http://www.copyright.gov/circs/circ61.html

http://www.openbsd.org/policy.html

So, essentially, if I like what your computer program does, I can certainly write my own that does the same thing. I cannot, however, use your code even if I have access to it.

And no matter how good your spec is, my interpretation in code does not "have to be written" in a certain way.

for(x=0;x9;x++); ...
x=0; while(x9) x++; ...
int count_to_ten(int n) {
    if (n 9)
        n = count_to_ten(n++);
    return n;
} ...
x = new awesome_number_class;
x.count_to_ten(); ...
10 X = 0
20 X = X + 1
30 IF X 9 THEN
40 GOTO 20
50 END IF ...
do
    x = x + 1
loop until x = 9

Firewalls have been around long enough where I simply wouldn't accept this nowadays. I put up with proprietary firewalls for years that were purchased before I was hired here. They were purchased because they had long feature lists and snappy GUIs. But in practice, they were garbage. Their state tables were small, so they often dropped connections. Their VPN implementations were buggy (in fact, a 'factory authorized field consultant' from this one particular company said that no one *really* knew how their IPSec stack worked; I know he was saying this to me in order to give me that "I'm on your side, buddy" kind of feeling, but it made me immediately lose faith in their product). Often the GUIs did not display the proper state of the machine. To add insult to injury, our paid support contract did not include 'premium' features such as access to their tech info library, where you would find out what error IDs actually meant.

After one particularly bad episode with the firewall, where we were required to replace a failing hard drive, we started looking for something new. That hard drive was a standard 2.5 inch Hitachi 40 GB-- but they charged us $500 for the "authorized" part so we wouldn't void our warranty. If they're going to charge you $500 for a part that should cost $100, fuck the warranty, man!

After evaluating our options, we settled on OpenBSD's PF. Several linux firewalls were considered as well, but we went with BSD because we were more familiar with it. We've been extremely pleased with our choice. PF gets better and better with each release, it is highly flexible and customizable, and the rule syntax was easy to learn. We have features that would cost us an arm and a leg in their proprietary counterparts (VPN, dynamic rulesets, firewall failover, and so on), and we can build it on commodity hardware. There's a huge community that has given us technical and moral support, and documentation is freely available. These are full computers, too, so if we need to write a custom monitor or report, piece of cake! And the savings in time and money have been enormous.

And this taught us an extremely valuable lesson-- don't be afraid of the learning curve of applications that don't use a GUI. The fact is, sometimes the problem space is complicated, and a text interface often handles that complexity better than a GUI. Sure, there's a higher nmemonic load, but we work with these machine every day, so we got used to it. You'd have to give me a really good argument at this point to get me to switch over.

So you claim at least 10% of OpenBSD DoS bugs are actually remotely exploitable, offer no proof, then give vague details about a paper you've supposedly submitted on a bug which isn't remotely exploitable under OpenBSD. You don't even say what piece of software this was.

For all we know, it was some external third party stuff, maybe BIND or something, which according to the very goals of the project are imported with minimal changes and do not undergo the same review process that OpenBSD code does. Since you say this affects multiple projects and give zero details, I'm going to assume this is the case.

Yeah, way to go, you really showed the people how much of a myth OpenBSD security is!

Anyway, what is unreasonable about performing your own analysis of a bug, decide that it doesn't seem remotely exploitable to you, then when someone shows proof, acknowledge you were wrong. Isn't that how science works?

The term "cover-up" implies that they did something outside of their usual process of classifying bugs & the attendant patches.

Except that they didn't; they classified it as a reliability issue (as they have done with many similar issues because they didn't see exploitability as of part of the problem ( Check out the history here: http://openbsd.org/errata40.html ; many kernel panic bugs going back several years are classified as "reliability" patches ). Once the proof-of-exploit was provided, they re-classified the existing patch in short order.

You can argue with their system of classification, but if you're actually administering an openbsd box, are you skipping the reliability patches because you like unreliable, but secure servers? I hope not...

In any case, that timeline leaves out the context of how the openBSD project actually works, which should be taken into consideration before implying accusations of "cover-up". In this case, I think that assessment is entirely unfair.

OpenBSD is the only system I use for IPv6 firewalls. OpenBSD's packet filter is the most advanced IPv6 firewalling implementation out there, and thus it is used to protect all kinds of infrastructure where IPv6 is in production use.

But the machines that OpenBSD+pf are protecting are quite easily compromised, there are so many PHP/MySQL/IIS/etvas exploits out there that give root level access to a machine. I tend a data centre with thousands of poorly administrated machines, several of which get compromised on a daily basis. All the firewalling in the world can't protect a web server whose main function is to serve up pages to the internet at large. Many companies just rent a dedicated machine, or space on a shared machine, and once their website is barely up and running they tend to forget to update or patch the system. So the servers get compromised into botnets, or taken over by children on IRC, or just have a disgruntled ex-admin fucking around. It's a major pain. Even if the server has been configured for IPv4 only (because Apache is broken on v6), a root exploit can still send IPv6 packets out a local interface.

Once there is a compromised machine on the local network, then a script-kiddie tool to compromise an unpatched OpenBSD firewall can be uploaded. A nightmare situation, but kudos to the OpenBSD team for a quick, straightforward response. Time to go pre-order some T-shirts. Since the mailing lists have been quite active as this exploit has been discovered, it has given me time to check all the firewalls I manage for "scrub in" commands. Now I get to go do some kernel patching as well.

the AC

No, IPv6 is enabled in the default install, though it does use only link-local addresses by default. This means that the attacker has to be on the same layer-2 network as the victim, but this is still classified as a remote exploit. Theo agreed, and the homepage has already been updated.

I mean seriously, when my own fully functional version of "echo" is 4116 bytes stripped, how come GNU's is 13880, and all it has mine doesn't is --help and --version? (Both are dynamically linked.

See it for yourself:
OpenBSD `echo': http://www.openbsd.org/cgi-bin/cvsweb/src/bin/echo /echo.c?rev=1.6&content-type=text/x-cvsweb-markup
GNU `echo': http://cvs.sv.gnu.org/viewcvs/coreutils/coreutils/ src/echo.c?view=markup

GNU version supports de-escaping the parameters before printing them while your version probably doesn't.

An OS should be first and foremost both secure and fast. It should have a very small footprint and...
[...]
It should but does one modern OS have this?

OpenBSD

It doesn't look like it has any stateful failover capabilities.

Oh, so THAT's why OpenBSD is relatively secure. If more people started using it, I guess it would suddenly get less secure. Thanks for clearing that up.

Your comment gets at the issue that there are more exploits for more commonly used systems. Still, it may be that more secure systems may be used less because they are more difficult (or expensive or whatever) to use - same is probably true of security's component parts such as passwords, physical security, etc.

okay, i did it. now what?

You can find a solution(s) to your problem at one or more
of the following locations:

http://www.centos.org

http://fedoraproject.org/wiki/

http://en.opensuse.org

http://www.opensolaris.org/

http://www.ecomstation.com/

http://www.redhat.com

http://www.reactos.org/en/index.html

http://www.debian.org/ports/hurd/

http://www.openbsd.org/

http://www.freebsd.org/

http://www.netbsd.org/

http://www.dragonflybsd.org/

http://www.osfree.org/doku/en:start

http://www.skyos.org/

http://www.freeos.com/

http://www.minix3.org/

Added to bypass the stupid slashdot lameness filter which apparently doesn't like a post full of links. WTF is wrong with the
stupid lameness filter? Jeez, what does it want, for us to type paragraphs of meaningless drivel just to get past the lameness filter?
Sheeesh. OK, this is really stupid. Why don't ajfajf al;djal a fa fa lkdf jaa fal ja;ljf af af ajf;lajf alfjalf a fjal;fjafl; jaflakjf af;laj
jalkfaj fjf af af fajjjajal jajfa f afjdlakej2233 2235t2352 dsfalkfjal f 222j2 afdkja f23 2 2 2t2352322 233252352 2323232.

Now how am I supposed to install OpenBSD?!

OpenBSD's greylisting in spamd works wonders.

potential security problems, for one thing. You should not trust 'binary blob' drivers with your kernel-space, right? you can't inspect the source code...

The 'blob' song actually explains it really well, I think:

http://www.openbsd.org/lyrics.html#39

Unfortunately, even the OpenBSD documentation is not always clear and complete. I remember one instance where I wrote a HOWTO describing how to use OpenBSD's ccd for mirroring partitions, and one of the reactions I got was "don't use ccd mirroring; it's broken". Yet, ccd mirroring is is described in the ccd manpage, without any mention of it being broken, and without clear instructions for setting it up.

This came out in OpenBSD 3.3 over three years ago. Nice to see Microsoft keeping up with the times.

Check the OpenBSD hardware compatibility page. Scroll down to Ethernet Adaptors and Wireless Ethernet Adaptors. These are hardware for which there exists source code for the driver. I realize this is effectively the same situation -- a bunch of cards, some outdated, etc. and it still doesn't necessarily help you on whether or not there's a Linux driver. However, lately OpenBSD has been leading the way as far as non-BLOB drivers go and I'd trust any driver written by the OpenBSD team to not be flaky. And if you really want support for a particular one under Linux, it's a lot easier to point a Linux driver programmer to working, solid source code and say "Hey, can you port this to Linux?" rather than having to start from scratch.

Vote with your money, folks.

I'm all for letting cooperative organizations know why I'm purchasing their equipment and not their uncooperative competitors (and notifying their uncooperative competitors to the contrary), but I don't expect it to mean that I'm in any way "voting" or leveraging some kind of democratic control over what is essentially a private tyranny.

However, if you read Theo de Raadt's informative talk slides, you'd see another reason why "voting" with your money isn't what it is made out to be (slides 24 and 25—"The OEM problem"). Maybe if customers in the US were organized to a scale never before seen and all demanding chips with complete and unrestricted documentation, we'd have more control as a group. This is worth pursuing, and if you are calling for this I would gladly join such an effort.

I say this is another reason because the general problem with the concept of voting by spending money means that rich people have more "votes" than poor people, so this saying tries to cast a egalitarian pall on an inequity. de Raadt addresses how much consumer power you have with regard to computer hardware by pointing out how OEMs leverage competition to insulate themselves from customer's wishes for chips we can operate without proprietary software. I mentioned this before but I didn't think it would come up as a repeat so soon.

Vote with your money, folks.

I'm all for letting cooperative organizations know why I'm purchasing their equipment and not their uncooperative competitors (and notifying their uncooperative competitors to the contrary), but I don't expect it to mean that I'm in any way "voting" or leveraging some kind of democratic control over what is essentially a private tyranny.

However, if you read Theo de Raadt's informative talk slides, you'd see another reason why "voting" with your money isn't what it is made out to be (slides 24 and 25—"The OEM problem"). Maybe if customers in the US were organized to a scale never before seen and all demanding chips with complete and unrestricted documentation, we'd have more control as a group. This is worth pursuing, and if you are calling for this I would gladly join such an effort.

I say this is another reason because the general problem with the concept of voting by spending money means that rich people have more "votes" than poor people, so this saying tries to cast a egalitarian pall on an inequity. de Raadt addresses how much consumer power you have with regard to computer hardware by pointing out how OEMs leverage competition to insulate themselves from customer's wishes for chips we can operate without proprietary software. I mentioned this before but I didn't think it would come up as a repeat so soon.

Most 'Windows' exploits are exploits in bundled userland software. If you compare this to the number of exploits in software bundled with, say, Fedora Core, then the numbers don't look nearly so rosy.

Why do you think the project needs to be run by the OpenBSD developers? There are plenty of US companies who specialize in providing secure solutions based on OpenBSD.

On a related note: read Theo de Raadt's slides from his OpenCON 2006 talk "Why hardware documentation matters so much and why it is so hard to get". In this talk he answers these questions and he debunks common arguments presented by vendors who don't want to tell you how the hardware works and sycophantic users who act as intellectual bodyguards for these vendors. You'll also learn another problem with what is often described as "voting with your wallets"—informative counterarguments to what you've read on /. any time this topic comes up.

My experience with Edgy (since late betas) and Feisty have been that it was not required to sudo to burn anything.

Same here. In fact, I was pleased to discover that in Ubuntu 6.10, all I needed to to was right-click on a disc and select "Copy disc" to make an ISO. Cool!

But if you do need to run a program with elevated permissions in GNOME, the right way to do it is with gksudo. You will get a prompt in the GUI to enter your password. If you add the NOPASSWD option to your /etc/sudoers file (remember to use visudo, folks), then gksudo will run without prompting you. A working permissions model is a feature, not a bug! And unless I'm confusing Linuxisms with BSDisms, you should also be able to specify in /etc/fstab which block devices require permissions or not. But, like I said, I didn't need to do any of this with Ubuntu.

My only complaint is that getting wireless going in Linux can be a PITA when things go wrong. The GUI tools lack the verbosity needed when there are problems, but the command-line tools are extremely complex. Windows XPSP2 is much better in this regard (SP1 blows), but even Windows can be a major headache-- ever try to find the right wireless drivers in Windows? IBM often has 3-4 different wireless chipsets for each 'machine type' (what is the f'ing point of having different machine types, then?), and it's up to you to find the right one. OpenBSD's config utility is the best in this regard; drivers are automatically loaded and you can easily configure them with ifconfig, which should be familiar to most Unix users.

That said, we're looking at Ubuntu as a serious alternative to Windows for our next round of desktop upgrades here at work. My impression is that there will be less of a learning curve than with Vista or the Mac OS, and we will get the additional benefit of being able to eek out a couple more years of life from our existing hardware.

http://www.openbsd.org/

For those who aren't familiar with OpenBSD, it's the most secure open source UNIX implementation. It's been engineered from the ground-up over the past decade to maximize security, through the use of continual code audits, OpenSSH, a security-enhanced Apache HTTPD fork, and other safety-first practices.

Off-hand, OpenBSD would have outright prevented items 1, 3, 4, 5, 8, 9, and 10. The other items do not apply to OpenBSD (ie. falling for email-related fraud).

But then, the parent was talking about Gentoo.

A well done rootkit is hard to detect... if you can't find a rootkit on your system then it's probably too late.

Go here now.

Actually, init (and only init) can lower the secure level. Try typing:

$ kill -s TERM 1

as root some time. It will lower securelevel and drop into single user mode. Securelevel will rise again once in multiuser.

• An operating system that runs on an extremely wide variety of hardware
• A stable and mature TCP/IP stack, transparently integrated into the system via Berkeley sockets
• Thousands of programmers who submit patches and/or modify the system to do exactly what they want it to do
• Full POSIX compatibility
• Real separation of mechanism from policy-- tools can be used in a variety of ways, often in ways not foreseen by the original author
• A system that doesn't require specialized tools to customize-- every system comes with a text editor and development tools
• A real, working permissions model-- for some uses, THIS is a dealbreaker, as the GP mentions
• Multiprocessing is easy
• Pipes and powerful shell scripting capabilities
• And so on...

Personally I would prefer a PIX over a linux firewall.

Well, if you can afford it, and don't mind learning IOS, great. Reading the replies thus far, it seems the home-user would prefer something else, although that something else seems to include everything but the kitchen sink.

Maybe it's me, but my idea of firewall is something that I manage over a serial cable that isn't doing anything else but handling traffic, and perhaps logging to an external box. A web server, DNS, DHCP, ClamAV, SquidGuard, etc. etc. etc., might be handy, but those are standard network services and belong elsewhere.

Seems like a good enough book, though. My vote is still with pf on a *BSD system. The pf FAQ is as well-written as any book, and the examples provided should allow even the novice user to be up and running in minutes. Pick up a Soekris box and Bob's yer uncle.

And how to configure an OpenBSD firewall is here.

One thing that can help make spamming less profitable for spammers is tarpitting. I personally think that this should be standard behavior for an MTA-- it would raise the profitability bar considerably.

I dropped spamd in front of my MX pool and watched in amazement as our spam level dropped to next to nothing. I'm not even being very aggressive-- I don't use any DNS-based blacklists. The beauty of this setup is that 1) if a spammer wants to make money, he's gotta drop the connection from me, because I'm sending packets to him slowly and wasting his resources (one per second with a window size of 1 byte), but 2) if he *does* drop that connection and does not retry, he gets blacklisted automatically. This obviously isn't a cure-all, but it's doing wonders for us.

I, too, feel your pain. Spam causes big problems-- one being that it is becoming increasingly difficult to use telnet as a diagnostic tool for SMTP. Sender callbacks mess with that whole thing. Obviously, my tarpit/greylist will as well. But we have to forget about the good old days and move forward, keeping in mind that in the good old days we only had thousands of users to worry about-- now we have billions. There are probably even billions of well-behaved people. SMTP simply doesn't scale when you factor in the bad people.

resist the blob !.

Couldn't agree more... {shameless advertisement: OPENBSD - Only one remote hole in the default install, in more than 10 years! http://www.openbsd.org/}

I think that this is inevitable. Mac OS X is a desktop OS, desktop customers demand shiny new features and Apple needs to compete with Microsoft in adding such features, otherwise it will fall behind in market share. These new features make for a supremely usable OS, but it means that development is always too fast. Security flaws are invariably human logic errors, and when a lot of new code is written really fast, errors are made. Conversely, take OpenBSD, its pace of development is slow and thorough and due to its comprehensive code audit (which slows development) very few security holes are found in the code. As complexity escalates, so will the number of bugs and until Apple's workforce is replaced with androids (Which I'm sure will have a negative impact on its cool reputation) errors will continue to be made. Although inevitable, we need not accept that there should be quite as many flaws as there are - Apple is in a uniquely privilege position over microsoft in using the unix permission system and the mature core that mach and FreeBSD provides, it must not become complacent. Increasingly, it appears that Apple is becoming sloppy - There are reports of Apple not using automated bound checking and the such. Such arrogance is inexcusable from any developer, and as Apple's popularity increases poor security will invariably become more of an issue. Its time for Apple to seriously take stock of this issue.

Damn, I forgot about the lack of a -useful branch. Although I don't know why IPX is marked as a big fat no: IPX on OpenBSD.

http://openbsd.org/lyrics.html

Nope, the string format field width should be at least one byte less than the array to allow for a null. See the description of the 's' format in the scanf(3) manpage.

I meant the red one actually. However, this one might do as well.

If the old T-shirt with the Daemons Head was available I would buy one now.

Do you mean this one?

This shirt was unavailable for a short while, but it's been available again for some time now.

He wants to install on a VAX though. So he is much more limited with his options than i386.

Considering that the OP inquired about the lack of CD boot support for VAX, but was still using a CD, I would guess that they were not actually installing on a VAX using the CD.

BTW, if you are going to burn your own bootable i386 OpenBSD CD, you are better off using the cdrom40.fs as a 2.88MB bootable floppy image.

True, I suppose I should have said "use cdrom40.fs," but I call it a floppy image since the installation notes refer to it as: "The i386 boot and installation 2.88MB floppy image"

You mean checksums like:
ftp://ftp.openbsd.org/pub/OpenBSD/4.0/i386/MD5
ftp://ftp.openbsd.org/pub/OpenBSD/4.0/i386/CKSUM

You mean checksums like:
ftp://ftp.openbsd.org/pub/OpenBSD/4.0/i386/MD5
ftp://ftp.openbsd.org/pub/OpenBSD/4.0/i386/CKSUM

I started using OpenBSD at 3.8 and I have been very pleased with the whole experience in the short time I have been using them. Those of you who have not tried it yet try it out, if not for this project we would not have OpenSSH, OpenNTPD, and many more, if you support no other project then support this one.

OpenBSD

Even since OpenBSD started to "theme" each release I've been disappointed in the merchandise. The artwork is great, but it's just something I wouldn't want to hang on my wall or wear in public.

Thankfully you can still order stuff from old releases. My personal favourite is the poster from 2.9, which is simple and illustrates exactly what OpenBSD is about but professional enough you could hang it your office. I'd buy something every release if they were more like that.

So glad you asked. I'm sure a lot of Slashdotters will chime in with the default Linux answer. It's valid, and I accept that it works well. However, once you've worked with OpenBSD's PF packet filter syntax, you'll never want to look at another iptables ruleset again. Kerio / Sunbelt Personal Firewall is ok for a standalone WinXP machine (I've got it running on my mother's pc). I would not want to trust Microsoft's built in firewall or internet connection sharing tools. I used to use Kerio Winroute on my file server before migrating to OpenBSD, and it worked nicely for a few years. But the newer versions of WinRoute have gotten really expensive, bloated, and encumbered. The day WinRoute phoned home to check it's license was the day I ditched it for OpenBSD.

We need to tell people to get themselves over to http://openbsd.org/ftp.html (or whichever you prefer) and download a real OS, where you can do exactly what you want.

What I want is to play games such as F.E.A.R. and Oblivion, on my PC, along with assorted other things that I simply can't do on a BSD or Linux.

Besides which, since first installing my copy of XP I've completely stripped down my PC and replaced all of the hardware, and (re)activation was as simple as clicking a couple of buttons.