Slashdot Mirror

How about the Samba exploit this week?

Samba is not a standard part of any Linux distro that I know of. In fairness, I'm an OpenBSD fan and don't use Linux much so I can't be sure. Anyhow, suggesting that this Samba exploit reflects poorly on any open source OS is really a strawman argument.

Isn't OpenBSD in canada because thats where Theo De Raadt lives?

That might be part of the reason, but this item suggests it's not the only reason:

Why do we ship cryptography?

In three words: because we can.

The OpenBSD project is based in Canada.

The Export Control List of Canada places no significant restriction on the export of cryptographic software, and is even more explicit about the free export of freely-available cryptographic software. Marc Plumb has done some research to test the cryptographic laws.

Hence the OpenBSD project has embedded cryptography into numerous places in the operating system. We require that the cryptographic software we use be freely available and with good licenses. We do not directly use cryptography with nasty patents. We also require that such software is from countries with useful export licenses because we do not wish to break the laws of any country. The cryptographic software components which we use currently were written in Argentina, Australia, Canada, Germany, Greece, Norway, and Sweden.

When we create OpenBSD releases or snapshots we build our release binaries in free countries to assure that the sources and binaries we provide to users are free of tainting. In the past our release binary builds have been done in Canada, Sweden, and Germany.

OpenBSD ships with Kerberos IV and Kerberos V included. The two codebases we use are the exportable KTH-based release from Sweden. Our X11 source has been extended to make use of Kerberos as well.

My uptime is 2 months. It would be 21 months except we had a 5 hour blackout where I live in January.

I'm not rebooting, but I don't think I'll get hax0red

Although S tar is a nice utility, as mentioned by previous posters. You can get pax directly from the OpenBSD people. Debian also packages pax, if you run Linux.

Although S tar is a nice utility, as mentioned by previous posters. You can get pax directly from the OpenBSD people. Debian also packages pax, if you run Linux.

My first choice would really be MS-DOS or PC-DOS or DR-DOS or FreeDOS. There is a huge amount of software. It is much easier to find DOS drivers for old laptops than it is BSD or Linux. If you really want to get fancy, search for Desqview/X and give it a try.

Very good point.

And that's why the swap space of OpenBSD is encrypted. Fortunately some programmers already thought of this =)

The recommended method is creating individual partitions for /, swap, /usr, /home, /tmp, and /var. Deciding the appropriate sizes for each of these partitions when you have no experience is probably the hardest part - but there's plenty of recommendations online. Personally, I'd recommend 80MB for /, 300MB for swap, 500MB for /tmp, 1GB for /var and split the rest between /usr and /home (/home is where most of your personal files will be stored and /usr is where most packages are installed).

All of the comands are well doccumented during the install if you type 'help'. The only other thing that could cause some confusion to somebody new is that by default all drive input sizes are by hd sectors - Not Bytes. The simple way to avoid calculating everything is just append all partition sizes with a 'M'. This lets the system know that your number is in Megs, not sectors.

Hope that helps you out some.

I recently wiped Win98 off an old deskpro 4000 with the idea that I would make a firewall/router/whatever box (for fun and for my own education).

I'm a newcomer to bsd/linux and don't really know anything. I've heard that OpenBSD is really good and wanted to try it. Ok great, I'll go to OpenBSD.org, download, burn and install.

wtf? how to I download the iso?
After searching around I saw the entry in the faq that I have to buy it... or I can try to download it myself and figure out what bits go where on the CD. Oh, and the layout (or something) is copywrited so I can't grab it off the net someplace without breaking the law.

Well, I'm sorry guys. I don't know how to do that and the documentation I've seen doesn't tell me enough. I want to learn... but I'd like to do it incrementally, not all up front. So I'll be giving OpenBSD a pass and using something else.

Yeah, I'm sure I'll get at least one flaming response about how the team doesn't have to provide the iso, how they need money to continue development, how it's only $40 for God's sake.

I know all that already.

But I have a choice too. And I'm going to choose a distro I can try before I buy without having to figure out where stuff is supposed to go on the CD and whatever else I have to learn just to install the thing.

It's too bad. I've heard a lot of nice things about OBSD and I want to try it. But I'm going to go with someone else... and if I like FreeBSD, RedHat, or whatever, I'm going to end up sending that company money. And OBSD is going to miss out on that little bit of income.

If I'm not too firmly entrenched in the future, or if I actually learn enough to install OBSD myself then maybe, just maybe I'll give that distro a try.

Too bad :-(

Sukotto
(hmm... that's a little more whiny than I intended)

Contributions to BSD don't really help us as much. . .

Speak for yourself - those of us who run BSD on our production servers find contributions useful.

If you pay a little attention to what the OpenBSD core team says and does, you'd realize that there is little-to-no danger that government funding will take the project in any directions but those stated in the project goals.

Portable OpenSSH ChangeLog

I think you may NOT want this release.
But I want :-)

NetBSD Handbook

OpenBSD FAQ

http://www.benzedrine.cx/ackpri-norm.jpg
http://www.benzedrine.cx/ackpri-priq.jpg

benzedrine.cx - Prioritizing empty TCP ACKs with pf and ALTQ Prioritizing empty TCP ACKs with pf and ALTQ

Introduction ALTQ is a framework to manage queueing disciplines on network interfaces. It manipulates output queues to enforce bandwidth limits and priorize traffic based on classification.

While ALTQ was part of OpenBSD and has been enabled by default since several releases, the next release will merge the ALTQ and pf configuration into a single file and let pf assign packets to queues. This both simplifies the configuration and greatly reduces the cost of queue assignment.

This article presents a simple yet effective example of what the pf/ALTQ combination can be used for. It's meant to illustrate the new configuration syntax and queue assignment. The code used in this example is already available in the -current OpenBSD source branch.

Problem I'm using an asymmetric DSL with 512 kbps downstream and 128 kbps upstream capacity (minus PPPoE overhead). When I download, I get transfer rates of about 50 kB/s. But as soon as I start a concurrent upload, the download rate drops significantly, to about 7 kB/s.

Explanation Even when a TCP connection is used to send data only in one direction (like when downloading a file through ftp), TCP acknowledgements (ACKs) must be sent in the opposite direction, or the peer will assume that its packets got lost and retransmit them. To keep the peer sending data at the maximum rate, it's important to promptly send the ACKs back.

When the uplink is saturated by other connections (like a concurrent upload), all outgoing packets get delayed equally by default. Hence, a concurrent upload saturating the uplink causes the outgoing ACKs for the download to get delayed, which causes the drop in the download throughput.

Solution The outgoing ACKs related to the download are small, as they don't contain any data payload. Even a fast download saturating the 512 kbps downstream does not require more than a fraction of upstream bandwidth for the related outgoing ACKS.

Hence, the idea is to priorize TCP ACKs that have no payload. The following pf.conf fragment illustrates how to set up the queue definitions and assign packets to the defined queues:

ext_if="kue0"

altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)

pass out on $ext_if proto tcp from $ext_if to any flags S/SA \
keep state queue (q_def, q_pri)

pass in on $ext_if proto tcp from any to $ext_if flags S/SA \
keep state queue (q_def, q_pri)
First, a macro is defined for the external interface. This makes it easier to adjust the ruleset when the interface changes.

Next, altq is enabled on the interface using the priq scheduler, and the upstream bandwidth is specified.
I'm using 100 kbps instead of 128 kbps as this is the real maximum I can reach (due to PPPoE encapsulation overhead). Some experimentation might be needed to find the best value. If it's set too high, the priority queue is not effective, and if it's set too low, the available bandwidth is not fully used.
Then, two queues are defined with (arbitrary) names q_pri and q_def. The queue with the lower priority is made the default.

Finally, the rules passing the relevant connections (statefully) are extended to specify what queues to assign the matching packets to. The first queue specified in the parentheses is used for all packets by default, while the second (and optional) queue is used for packets with ToS (type of service) 'lowdelay' (for instance interactive ssh sessions) and TCP ACKs without payload.

Both incoming and outgoing TCP connections will pass by those two rules, create state, and all packets related to the connections will be assigned to either the q_def or q_pri queues. Packets assigned to the q_pri queue will have priority and will get sent before any pending packets in the q_def queue.

Result The following test was performed first without and then with the ALTQ rules explained above:

• -10 to -8 minutes: idle
  
• -8 to -6 minutes: download only
  
• -6 to -4 minutes: concurrent download and upload
  
• -4 to -2 minutes: upload only
  
• -2 to 0 minutes: idle

The first graphs shows the results of the test without ALTQ, and the second one with ALTQ:

Image 1, ACK PRI Normal

Image 2, ACK PRI PRIq

The improvement is quite significant, the saturated uplink no longer delays the outgoing empty ACKs, and the download rate doesn't drop anymore.

This effect is not limited to asymmetric links, it occurs whenever one direction of the link is saturated. With an asymmetric link this occurs more often, obviously.

Related links

• The OpenBSD project
  
• The OpenBSD packet filter (pf)
  
• pf mailing list archive
  
• pf.conf(5) man page
  

http://www.benzedrine.cx/ackpri-norm.jpg
http://www.benzedrine.cx/ackpri-priq.jpg

benzedrine.cx - Prioritizing empty TCP ACKs with pf and ALTQ Prioritizing empty TCP ACKs with pf and ALTQ

Introduction ALTQ is a framework to manage queueing disciplines on network interfaces. It manipulates output queues to enforce bandwidth limits and priorize traffic based on classification.

While ALTQ was part of OpenBSD and has been enabled by default since several releases, the next release will merge the ALTQ and pf configuration into a single file and let pf assign packets to queues. This both simplifies the configuration and greatly reduces the cost of queue assignment.

This article presents a simple yet effective example of what the pf/ALTQ combination can be used for. It's meant to illustrate the new configuration syntax and queue assignment. The code used in this example is already available in the -current OpenBSD source branch.

Problem I'm using an asymmetric DSL with 512 kbps downstream and 128 kbps upstream capacity (minus PPPoE overhead). When I download, I get transfer rates of about 50 kB/s. But as soon as I start a concurrent upload, the download rate drops significantly, to about 7 kB/s.

Explanation Even when a TCP connection is used to send data only in one direction (like when downloading a file through ftp), TCP acknowledgements (ACKs) must be sent in the opposite direction, or the peer will assume that its packets got lost and retransmit them. To keep the peer sending data at the maximum rate, it's important to promptly send the ACKs back.

When the uplink is saturated by other connections (like a concurrent upload), all outgoing packets get delayed equally by default. Hence, a concurrent upload saturating the uplink causes the outgoing ACKs for the download to get delayed, which causes the drop in the download throughput.

Solution The outgoing ACKs related to the download are small, as they don't contain any data payload. Even a fast download saturating the 512 kbps downstream does not require more than a fraction of upstream bandwidth for the related outgoing ACKS.

Hence, the idea is to priorize TCP ACKs that have no payload. The following pf.conf fragment illustrates how to set up the queue definitions and assign packets to the defined queues:

ext_if="kue0"

altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)

pass out on $ext_if proto tcp from $ext_if to any flags S/SA \
keep state queue (q_def, q_pri)

pass in on $ext_if proto tcp from any to $ext_if flags S/SA \
keep state queue (q_def, q_pri)
First, a macro is defined for the external interface. This makes it easier to adjust the ruleset when the interface changes.

Next, altq is enabled on the interface using the priq scheduler, and the upstream bandwidth is specified.
I'm using 100 kbps instead of 128 kbps as this is the real maximum I can reach (due to PPPoE encapsulation overhead). Some experimentation might be needed to find the best value. If it's set too high, the priority queue is not effective, and if it's set too low, the available bandwidth is not fully used.
Then, two queues are defined with (arbitrary) names q_pri and q_def. The queue with the lower priority is made the default.

Finally, the rules passing the relevant connections (statefully) are extended to specify what queues to assign the matching packets to. The first queue specified in the parentheses is used for all packets by default, while the second (and optional) queue is used for packets with ToS (type of service) 'lowdelay' (for instance interactive ssh sessions) and TCP ACKs without payload.

Both incoming and outgoing TCP connections will pass by those two rules, create state, and all packets related to the connections will be assigned to either the q_def or q_pri queues. Packets assigned to the q_pri queue will have priority and will get sent before any pending packets in the q_def queue.

Result The following test was performed first without and then with the ALTQ rules explained above:

• -10 to -8 minutes: idle
  
• -8 to -6 minutes: download only
  
• -6 to -4 minutes: concurrent download and upload
  
• -4 to -2 minutes: upload only
  
• -2 to 0 minutes: idle

The first graphs shows the results of the test without ALTQ, and the second one with ALTQ:

Image 1, ACK PRI Normal

Image 2, ACK PRI PRIq

The improvement is quite significant, the saturated uplink no longer delays the outgoing empty ACKs, and the download rate doesn't drop anymore.

This effect is not limited to asymmetric links, it occurs whenever one direction of the link is saturated. With an asymmetric link this occurs more often, obviously.

Related links

• The OpenBSD project
  
• The OpenBSD packet filter (pf)
  
• pf mailing list archive
  
• pf.conf(5) man page
  

"OpenBSD 3.3 beta is now stable enough for daily use, so why not download a snapshot from one of the mirrors and try it out?"

Windows XP is now stable enough for daily use, so why not download a snapshot from one of the mirrors and try it out?"

(intended as a joke)

"OpenBSD 3.3 beta is now stable enough for daily use, so why not download a snapshot from one of the mirrors and try it out?"

Windows XP is now stable enough for daily use, so why not download a snapshot from one of the mirrors and try it out?"

(intended as a joke)

I totally agree. I often go look at other os's man pages to see if maybe they have an example when the linux one doesn't. Freebsd, Netbsd ,Openbsd, and others

Admittedly, this is probably one more good argument for OpenBSD to ship with Postfix, and I am probably merely responding to a poor troll, but on the offchance that I am not . . .

--Ryv

Linux spends almost no money in R&D and Sun spends like 2 billion. Stop ripping their shit off and come up with your own stuff or Unix will die.

Sorry, but ... what the fuck? So free Unix-alikes are "ripping shit off" of Sun, now? I guess the fact that real talent contributes code to Linux doesn't excuse the fact that Linux is based around the "everything is a file" concept. So reading information in public Usenix papers is ripping off of Sun? Please. For example, the anticipatory i/o scheduler seems to be based on information that's been freely published. Not information hidden away under proprietary NDAs. Futexes and the O(1) scheduler are other examples of information that wasn't ripped-off shit. (I could be wrong, but I'm pretty sure about this.)

If Sun is spending two billion dollars in R&D and the linux people aren't, why hasn't Solaris managed to totally blow Linux out of the water? Oh wait, it does. On big (as in many processors) systems. It doesn't do as well on commodity hardware, but everybody knows Linux just doesn't scale well to 64-node machines these days. (People are working on it, but we're not there yet.) Even in the days of secure, portable, light reimplementations with wide hardware support, propietary Unix still has its niches. Besides, part of the appeal of Sun is a "total-package" deal - kind of like Apple.

Look, I appreciate that you might actually care about this, but if you don't give examples of what you're talking about you're going to look like you're talking out of your ass. Even on Slashdot. :3

Daniel Hartmeier uses OpenBSD and packet filter to waste spammers time.

This is the same thing as OpenBSD's spamd, which Theo de Raadt wrote specifically to cause spam relays pain. spamd uses some new features of pf and blacklists from Spews to create a tarpit for incoming messages from known spam relays. It was even discussed on Slashdot in this article. Also, Daniel Hartmeier, pf developer extraordinaire and all around good guy, wrote a little piece about annoying spammers using pf, spamd, and bmf.

This is now built into OpenBSD (see the spamd(8) man page).

I hate to split hairs, but running a global search and replace (which appears to not have been done, or done on a regular basis as they sucked more OBSD code in) is an intentional action. You have to know you are going to clobber some copyright strings that must remain untouched (to comply with the very terms of the copyright).

Even the OBSD folks keep the old NetBSD CVS tags in the code, and often keep the old comments in the header files, adding their own after them.

The reason for all the furor seems to be that there appears to be some amount of disingenuousness with the changes that were made.

OpenBSD has a very clear copyright policy and do regular license audits. I don't know if the MicroBSD people should be held up to the same standards or not, but the point many people are making is that the OpenBSD source is not in the public domain. Certainly some of it is, but not all.

I get the feeling that perhaps some of the MicroBSD people knew what they were doing all too well, while others didn't really consider the implications.

I mean, there were changes to source that were nothing but changes to the copyright string (the Pentium MTRR code, for example). Perhaps this can be attributed to a mindless global sed command. It's still pretty irresponsible.

Well, what would the OpenBSD project be without regular kerfuffles like this...

My boss asked me the other day if I was a socialist! I said no, but I do use linux. I like it for scp/ssh/co$t is all

Then why not use OpenBSD? After all, it costs the same and they are the ones that wrote the OpenSSH package you find so useful.

For Gods sake, why would someone choose BSD over linux????

I think finally I am gonna try OpenBSD. Does anyone know what hardware requirements it has

Currently supported hardware can be found here. Enjoy, it's a damn fine OS.

During these hostile and trying times and what-not, OpenBSD may your family's only line of defense! Only line of def-def-def...Only line of def-def-de-df-df-df-df!

Be sure to download the openBSD theme songs if you haven't already. :-)

What is done is protecting memory zones created by the linker, mostly memory zone holding constants and static variables, so no there's no executable code in this area.

When you write a JIT you allocate your own memory on the heap and then compile your code there. On order for this code to be executable you have to mprotect(2) the memory zone holding your code with the PROT_EXEC flag, or PROT_EXEC | PROT_WRITE if you want to be able to modify it afterward. Anyway you can change the memory protection at anytime so anything you could do before you still can do.

You just have to explicitly mprotect(2) the memory where it happen with PROT_EXEC|PROT_WRITE. The fact that on some OSes it can work without doing that is actually a bug in these OSes.

What the change is doing is the right thing, using a minimum privilege way to achieve more security. If some static code actually contain data that look like machine code it could be executed this wont be possible anymore.

Non executable stack by itself was far from enough as most program have some way of putting things on the heap or elsewere for an attacker and he could jump there instead of jumping on the stack. Coding an exploit for OpenBSD will get real tough now, even if there's an actual buffer overflow.

Chicks dig OpenBSD.

I figgure that if crackers (not hackers) find a bunch of ways to break linux such that it is no longer trusted (that is the need to patch and update gets in the way of buisness) that everyone will just switch to OpenBSD and be done with it.

As evidence against my claim I present to you the fact that most companys [that went to outlook at one time] still use outLook on windows for their eMail.

Poor you

I asked Theo de Raadt of the OpenBSD project about this. In the interview answers, Mr Richardson of AMI asks "does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?" Given OpenBSD's integrated crypto and more specifically crypto hardware support, I put the question to Theo. Within about a minute he responded. It was short, sweet and to the point. Will Mr. Richardson help follow through on this and get the OpenBSD project leading the way on using AMI's latest security developments at the OS level? From: Theo de Raadt Date: Fri Jan 17, 2003 12:12:47 PM America/New_York To: Anonymous Coward Subject: Re: /. interview regarding new security hardware on x86 If we had hardware docs.

I asked Theo de Raadt of the OpenBSD project about this. In the interview answers, Mr Richardson of AMI asks "does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?" Given OpenBSD's integrated crypto and more specifically crypto hardware support, I put the question to Theo. Within about a minute he responded. It was short, sweet and to the point. Will Mr. Richardson help follow through on this and get the OpenBSD project leading the way on using AMI's latest security developments at the OS level? From: Theo de Raadt Date: Fri Jan 17, 2003 12:12:47 PM America/New_York To: Anonymous Coward Subject: Re: /. interview regarding new security hardware on x86 If we had hardware docs.

I asked Theo de Raadt of the OpenBSD project about this. In the interview answers, Mr Richardson of AMI asks "does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?" Given OpenBSD's integrated crypto and more specifically crypto hardware support, I put the question to Theo. Within about a minute he responded. It was short, sweet and to the point. Will Mr. Richardson help follow through on this and get the OpenBSD project leading the way on using AMI's latest security developments at the OS level? From: Theo de Raadt Date: Fri Jan 17, 2003 12:12:47 PM America/New_York To: Anonymous Coward Subject: Re: /. interview regarding new security hardware on x86 If we had hardware docs.

I asked Theo de Raadt of the OpenBSD project about this. In the interview answers, Mr Richardson of AMI asks "does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?" Given OpenBSD's integrated crypto and more specifically crypto hardware support, I put the question to Theo. Within about a minute he responded. It was short, sweet and to the point. Will Mr. Richardson help follow through on this and get the OpenBSD project leading the way on using AMI's latest security developments at the OS level? From: Theo de Raadt Date: Fri Jan 17, 2003 12:12:47 PM America/New_York To: Anonymous Coward Subject: Re: /. interview regarding new security hardware on x86 If we had hardware docs.

Why does www.openbsd.org run on Solaris?

Redhat is bad example since iirc they have copyrighted images in their distro.

I think as long as the GUIs are just front-ends to modifying text files, it'll be ok. Everytime I have to fiddle around clicking "Next" a hundred times, I wistfully think of something like PF.

It brings up an interesting use for having source though, even if you don't code. Before buying a particular bit of hardware it might be interesting to read the driver comments to see what the programer thought of the thing at the low level.

It brings up an interesting use for having source though, even if you don't code. Before buying a particular bit of hardware it might be interesting to read the driver comments to see what the programer thought of the thing at the low level.

While interesting, the article describes a vulnerability that already has been fixed.

All you Edmontonians can give us is a modded shredder and Space Moose.

Like other posters have noted before, Darwin/Mac OS X is actually based on BSD-licensed software, not GPL-licensed software. If you want Linux on PPC, there are other alternatives.

However, that kind of problems only points at a much greater problem. Namely, the fact that a commercial entity (Apple) is heavily using open source in their latest software offering, even though their behaviour clearly indicates they are not interested in the philosophy of open source.

Finally, honestly, what's the point of Darwin only on x86? If I want BSD-style operating system on Intel x86, I'll use FreeBSD, or one of the other two, not some sort of bastardized version, which does not offer the reliability, security, or portability for which the other versions are well-known.

OpenBSD's mascot is the blowfish. Blowfish is the name of one of the ciphers for ssh and I think the password system. The OpenBSD team wrote that cipher, and at some point someone drew a picture of a blowfish for it. Because the daemon was so strongly associated with FreeBSD, and Theo liked the blowfish so much, it became the mascot for OpenBSD. You can see their various posters, t-shirts, and cd covers featuring blowfish here.

Patches
are
available

If you want to cheat Theo out of his hard earned money you can even ftp it (but that would be cheating).

Take that, Linux Goonies...

Use OpenBSD if security is really that important to you.

Otherwise, you're going to be dealing with holes almost as big as Microsoft's

The funny thing is, OpenBSD is recieving support from DARPA.

Look...

Someone please tell me where it says on the goals page that SMP is a high priority?
When you do security as a priority, fancy features that support threaded (read complex and untrustable from a security perspective) applications just don't quite get a front seat.
I do wish those dudes the best of successes, perhaps it will get merged in after the posix realtime extensions from rtmx, in the best case.
I sympathize with many who think they want SMP, but when the choice is security, stability, SMP, pick two .. there can be no question as to the obvious reality for the official distribution in the forseeable future;-)