Slashdot Log In
Theo de Raadt Responds
from the no-fear-of-forking-here dept.
A book on code auditing?
by LizardKing
Would you and/or other members of the OpenBSD coders consider writing a book on secure, bug-free coding and auditing? Most programming books feature sample code that is written for pedagogical purposes. Quite often this runs contrary to how secure code should be written, leaving a gap in many a programmers knowledge. A book on audinting and how to avoid security pitfalls when coding would also make your life easier - less code to audit for OpenBSD, and more time top concentrate on nifty new features!!!
Theo:
There is perhaps a split between the two issues you bring up. On the one side is secure coding, as in code written to be secure by the original author(s). On the other side, auditing, which is where an outsider (or an insider) later on goes and tries to clean up the mess which remains. And there is always a mess. Perhaps part of the problem is that a huge gap lies between these two. In the end though, I think that a book on such a topic would probably have to repeat the same thing every second paragraph, throughout the book: Understand the interfaces which you are coding to! Understand the interfaces which you are coding to! Most of the security (or simply bug) issues we audited out of our source tree are just that. The programmer in question was a careless slob, not paying attention to the interface he was using. The repeated nature of the same classes of bugs throughout the source tree, also showed us that most programmers learn to code by (bad) examples. A solid systems's approach should not be based on "but it works". Yet, time and time again, we see that for most people this is the case. They don't care about good software, only about "good enough" software. So the programmers can continue to make such mistakes. Thus, I do not feel all that excited about writing a book which would simply teach people that the devil is in the details. If they haven't figured it out by now, perhaps they should consider another occupation (one where they will cause less damage).
Making the rest secure
by squiggleslash
OpenBSD has a well deserved reputation for security "out of the box" and for the fact the inbuilt tools are as secure as they're ever likely to be. However, the Ports system is, perhaps, an example of where the secure approach currently has limitations - an installation of OpenBSD running popular third-party systems like INN can only be so secure because the auditing of INN, and other such software, is outside the scope of the BSD audit.
My question is, has the OpenBSD team ever proposed looking into how to create a 'secured ports' tree, or some other similar system, that would ensure that many of the applications people specifically want secure platforms like OpenBSD to run could be as trusted as the platforms themselves?
Theo:
We have our hands already pretty full, just researching new ideas in our main source tree, which is roughly 300MB in size. We also lightly involved ourselves in working with the XFree86 people a while back for some components there. Auditing the components outside of this becomes rather unwieldly. The difficulty lies not only in the volume of such code, but also in other issues. Sometimes communication with the maintainers of these other packages is difficult, for various reasons. Sometimes they are immediately turned off because we don't use the word Linux. Some of these portable software packages are by their nature never really going to approach the quality of regular system software, because they are so bulky.
But most importantly, please remember that we are also human beings, trying to live our lives in a pleasant way, and don't ussually get all that excited about suddenly burning 800 hours in some disgusting piece of badly programmer trash which we can just avoid running. I suppose that quite often some of our auditors look at a piece of code and go "oh, wow, this is really bad", and then just avoid using it. I know that doesn't make you guys feel better, but what can we say...
OpenBSD, security, et al.
by jd
With the release of SGI's B1 code, and the attempts by many U*ixen to secure their contents via capabilities, ACL's, etc, ad nausium, how is OpenBSD approaching the issue of resource control?
On a side note, is OpenBSD likely to ever head in the direction of being a distributed kernel? And, if so, how would security and resource management be maintained? (It's hard enough on a central kernel system.)
Theo:
On the first question, I think there is great confusion in the land of Orange Book. Many people think that is about security. It is not. Largely, those standards are about accountability in the face of threat. Which really isn't about making systems secure. It's about knowing when your system's security breaks down. Not quite the same thing. Please count the commercially deployed C, B, or even A systems which are actually being used by real people for real work, before foaming at the mouth about it all being "so great". On the other hand, I think we wil see if some parts of that picture actually start to show up in real systems, over time. By the way, I am surprised to see you list ACLs, which don't really have anything to do with B1 systems.
As to the second issue, I have no idea what a distributed kernel is, nor do I see how anything like that would improve security or quality of a system.
Forks and cooperation
by PapaZit
A lot of people know that OpenBSD forked from NetBSD, and there's still some animosity between the two groups. Personally, I think that the competition has helped both groups (NetBSD now ships with far fewer open services, for example).
Egos are delicate things, but do you see any chance for greater cooperation in the future, or do you see more forking and division as inevitable?
Theo:
Considering that NetBSD has maintained a black-hole route to the OpenBSD project networks for roughly four years, I don't see how any cooperation at higher levels are possible. However, there are developers who work on multiple projects. Some of them used to complain about having troubles from various groups. Nowadays, I think they've got it easier. Politics do not dictate developer relationships these days.
In Linux land, it appears that projects fork for financial reasons. In BSD land, it appears that the forks that have happened were purely political reasons. I don't know what will happen. It's been 5 years since the last fork in the BSD camp. Why are you guys so fork paranoid? Do you want everyone to vote for the same political party, too?
Kernel design
by laertes
I have only been using OpenBSD for a short while now, so forgive me if this question is based upon some incorrect assumtions.
OpenBSD's kernel design seems to be of the monolithic species. OpenVMS (no relation) and NT are two prominent operating systems that use a microkernel archetecture. The microkernel design seems to me to be fundamentally more secure, since there is less priveledged code. Further, if one of the servers is compromised, the damage is minimezed.
My question is this: Is the OpenBSD design fundamentally secure, or is it only a very well done implementation of a basically flawed design?
Theo:
I don't think it makes any difference, whatsoever. I think your computer science teachers are still teaching you from books written in the 80's, when the word "micro-kernel" was associated with a future utopia. We do not think that NT is a microkernel, and are you really so sure that OpenVMS is? A microkernel is not a kernel that does things through loadable modules. As well, I don't think it makes any difference, as long as a system does what it is supposed to do.
Where Did You Learn Your Code Audit Discipline?
by EXTomar
Did the drive to audit code come from the need or the design of BSD? Or was it initially a whim? More imporantly, where did you learn it from? Is their some "mentor" you looked too for ridge design? I have to admire your team's daunting code reviewing...I wonder if I'll ever have that kind of meticulous coding nature.
Theo:
The auditing process developed out of a desire to improve the quality of our operating system. Once we started on it, it becames fascinating, fun, and very nearly fanatical. About ten people worked together on it, basically teaching ourselves as things went along. We searched for basic source-code programmer mistakes and sloppiness, rather than "holes" or "bugs". We just kept recursing through the source tree everytime we found a sloppiness. Everytime we found a mistake a programmer made (such as using mktemp(3) in such a way that a filesystem race occured), we would go throughout the source tree and fix ALL of them. Then when we fix that one, we would find some other basic mistake, and then fix ALL of them. Yes, it's a lot of work. But it has a serious payback. Can you imagine if a Boeing engineer didn't fix ALL of the occurances of a wiring flaw? Why not at least try to engineer software in the same way?
Firewall/NAT box
by yamla
Linux has FreeSco, a product that fits on a 3.5 inch floppy disk and acts as a router and NAT (Network Address Translation). I always thought something like this would be ideal for OpenBSD. After all, I would rather trust OpenBSD than Linux for this.
Are there any plans to produce something like this? Something with a very simple user interface that is quick and easy to get set up? I'd love to play with OpenBSD and do it by hand but I simply do not have the time.
Theo:
I must say that I am not a fan of these floppy-based routers. Essentially, you are taking one of the most unreliable pieces of storage known to man, and trying to build security infrastructure on it. That's madness. Just buy a small disk. Perhaps somethings based on a CD plus some other (non-floppy) persistant storage might be sane. But please. Not floppies. Are you mad?
Code-auditing
by AT
Any advise for code auditers? Can you share any tips or techniques you have found useful in uncovering bugs? What do you first look for in a fresh piece of code? What about a mature piece of code?
Theo:
I suppose the biggest tip would be to become a better programmer. In particular, study what functions that programs are calling, and ensure that the calling code is following the rules of those functions 100%. How many of you understand the complete & correct semantics of every function in libc, or even just the libc functions being called by the program you are looking? (I mean, we went through our entire source tree, and about half the strncat() and strncpy() calls were subtly wrong, even if it only meant they copied a character extra and then zero'd it out -- it is still sloppy).
When you know exactly what the APIs are, you'll spot the bugs very easily. In my mind, it is the same as any other job that requires diligence. Be careful. Humans learn from examples, and yet, in this software programming environment, the tremendous complexity breeds non-obvious mistakes, which we carry along with us, and copy into new chunks of code. We've even found in manual pages where functions were mis-described, and when we found those, lots of programmers had followed the instructions incorrectly...
Dual Processor Support
by dragonfly_blue
Although there has been some indication that people are interested in running OpenBSD on machines with dual or quad processors, it appears that there are not enough resources and volunteers available to make this a reality. Although I use OpenBSD for my web server, I am by no means an expert, at this, but I'm curious nonetheless.
From what I've heard, multiprocessing support is going to be a very tricky thing to implement, because it gives rise to so many possible exploits, particularly with regards to race conditions. I also understand that it would take a remarkable amount of effort and time to rewrite much of the code base for SMP without compromising the OS's integrity.
With that in mind, what kind of resources would you need before you could seriously consider attempting dual or quad processor support? And, if you were given unlimited access to those resources, how long would it take before a -stable release would be ready? I would really like to see this feature get implemented, although I know that at this point your developer team is busy enough as it is.
Theo:
At this time, we are not working on SMP. It's a lot of work, and not considered the most interesting thing to our developers. Sorry.
Time warp
by rho
Thanks for your work, Theo. I use OBSD every day as a workstation and as a firewall, and the Cop-chasing-script-kiddie t-shirt is the best.
If you could time warp back to the beginning of OpenBSD's development (ignoring the scism that brought you to that point), what would you do differently? Would you have chosen a more commercial focus? Pushed SMP development earlier? Run around in circles waving your hands in the air?
On another note, what's your feeling about commercial use of OpenBSD? i.e., do you support it, tolerate it, or what? (better example, I make a set-top box running OpenBSD, and I need the OS to do "X". If I called you and said, "Theo, I need OpenBSD to support 'X'", would I be told to piss up a rope, write it myself, or would the OpenBSD team do it for a price?)
Theo:
The licence on our code is pretty clear. We want vendors to use our code. We want commercial operating systems to ship with OpenSSH. Not shipping with an SSH varient causes great grief, and it is time that ends.
Same goes for OpenBSD. We would prefer if companies building commercial network appliances used OpenBSD, rather than writing their own operating systems. Typically, these companies are very comfortable with solving the problems within their application space. Yet, there is a history of these companies writing their own cruddy operating systems, and at the same time writing worse applications.
It would be better if routers, firewalls, telephone switches, fileservers, and whatever else used reliable components, designed by people who care.
So go ahead, use any parts of OpenBSD as parts of commercial systems.
Full Disclosure And Version Numbering
by Effugas
First of all, I want to thank you for the hard work you've done building OpenBSD. It truly is a wonderful package.
Much of the security in OpenBSD lies under the hood in the work you've done cleansing the source of unsafe library calls. While this work is appreciated, I've become more and more concerned lately about the fact that these changes are not necessarily documented and certainly not reflected in the version number of an application or utility.
Version numbers reflect a snapshot in the life of a codebase. They're used to reference unsafe editions or particularly stable builds. Major number reflect code branches, but minor numbers reflect specific states of the code -- such is the expectation of a user or an administrator when a version number is detected. Without granularity of versioning, I have no reason to trust or distrust a given application by its number; I must personally audit its source -- and end up giving it a number of my own.
You and your team are code auditing masters. Rather than pollute the namespace by making indistinguishable your securely built modified code and the original(and, by extension, your secure code and numerous unnamed distributions' "just get it to compile" modifications), wouldn't it be appropriate for OpenBSD to apply a name extension to any package which it has modified, and in the interests of full disclosure, to provide a reasonable CHANGELOG of the fixes contained therein?
Theo:
Two numbers exist for every component of OpenBSD. One number is the release that the piece came in, ie. 2.8.
The other number exists in each source file that was built. And that number is also in each binary that was built from those files. You can use the what(1) command to determine the revisions of source files which make up each binary.
As to the "original" you talk about, there is no original. OpenBSD uses it's own components. I don't know what packages you are talking about. cat is cat. ftpd is ftpd. tar is tar. It's the one that came with a certain release. In the systems approach, the version numbering that other groups do is sometimes invalid, because pieces (such as libraries) are all part of the picture.
Was the last plane you were on using front wheel version 2.7 or 2.9? You don't care. You do however care greatly that a "systems approach" was used to ensure that it was whole. And in the OpenBSD case, that means pick a version, and install the patches.
Asking for more means that you want us to do less work on the system, and more version numbering.
Where does the money go?
by MrSparkler
I've seen reports of estimated CD sales per release at being as high as 10000. Add in t-shirt/poster sales and donations and a relatively considerable sum of money is flowing around OpenBSD. Combine this with the fact that checks are to be written to Mr. de Raadt and I get curious as to how the finances are handled. Not that I'm suggesting any misappropriation is occurring, I would just like to know who is in charge of the money and whether or not the OpenBSD project is registered as a non-profit organization (and if it is then checks should be made out to - and the CD image should be copyrighted to - that organization). Also, I would like to see a small financial report put out (as would be required if it were a non-profit organization in Alberta) so that users can see where their money is going. Plus, I would also like know exactly how many CDs are sold per release.
I greatly appreciate the work that the OpenBSD project developers have put in, and I plan on continuing to use, purchase, and donate to OpenBSD (and maybe even contribute when I get the technical skills) regardless of the answer to this question: Where exactly does the money go?
Theo:
We've not yet sold 10,000 CDs in a release. Hopefully we will soon. The project ends up with a bit less than 50% of the revenues from CD sales. The tshirt business is doing OK, but you make a lot less selling textiles. With posters we operate just above break-even. Even though some are sold on the web, most turn out to be free handouts at most conferences. That is how I planned the posters to operate.
We have thought about becoming a non-profit organization, but it is not really a good idea. It would not provide any real benefit -- to you -- as the masses. Especially in Canada, there are costs and serious responsibilities associated with doing such a thing. We would be giving up a lot of freedom, and would need to hire someone to do a lot of accounting. Also, since many of our donations come from outside Canada, we still could not really generate taxable benefits to you. (And I must ask, why are people so cheap, that they only give donations when it provides a partial reduction in their taxes, rather than a real donation? I actually find that pretty fake.)
Money from the project goes to various things. First off, it ensures that I can work full time on OpenBSD, and not need another job. I am also hoping to do the same for other developers in the project, who have indicated that they are interested in doing so. Secondly, certain grimey, unenjoyable, and very important development tasks sometimes put a bit of money in developer pockets. Some OpenSSH work was funded by matching OpenBSD money against donations from a Van Dyke. Thirdly, the project buys a fair amount of hardware: In powerpc land alone, 4 machines this year. Fourth, shipping costs to conferences sometimes severely cut into profits from sales. And finally, when developers get together to do hacking, project money sometimes pays for various things, like airplane tickets, accomodation, and sometimes even some beer. And beer results in ideas, which results in new code.
--------------
Before you ask: yes, we'll be doing Slashdot interviews with people from other *BSD projects in the near future - Robin
filtering by FreeBSD/NetBSD (Score:3)
> a black-hole route to the OpenBSD
> project networks for roughly four years,
Those who do not familiar with Mr. Theo de Raadt's usual action about BSDs should know the following history about the mail filtering.
This issue is once raised by a OpenBSD developer in DaemonNews forum [daemonnews.org] which has neutral position between FreeBSD, NetBSD and OpenBSD, and its conclusion is that the forum should never have posted the topic [daemonnews.org]. I don't know why Mr. de Raadt mentioned this filtering again in slashdot. Perhaps He'd like to show that he is still ready to post mail bomb to FreeBSD/NetBSD mailing list?
Re:Theo: Version Number Specifics (Score:3)
Econ 102... (Score:3)
The big "merit" in the "donation" thing is if this allows the organization to receive individual contributions from individuals that wouldn't otherwise be able to "deduct" the payment for tax purposes.
While, when you add this sort of thing up across thousands of churches, it adds up to real money, it's not going to be spectacularly worthwhile for a software project that might get $30K in donations and have to spend a chunk of that on organizational costs.
A reply to his reply to my questions. :) (Score:3)
However, some form of resource control is essential to preventing users authorised for one thing from doing something else.
ACL's are -one- way of doing this, the schemes described in B1 are another. You're again 100% right that they're not the same thing. However, they both attempt to deliniate exactly what a user is and is not able to do.
(As for foaming at the mouth, I'm going to go out on a limb here and guess you've met some pseudo-nerds who're drunk on a mix of power & Agent Orange, and who believe that if it's "Official", it's somehow "better" or mysteriously "all-encompasing". I'm not about to start a cult to the Mighty OB1. :)
Distributed Kernels are kernels which divide low-level tasks between sub-kernels, where each sub-kernel runs on a seperate processor or even a seperate machine.
Distributed Kernels are one way of doing hardware-independent parallel processing. You're not tied to SMP, you're not tied to a single motherboard, you're not even tied to a specific manufacturer.
From a security standpoint, it has two major impacts. On the one hand, breaking one component of the system does NOT necessarily compromise any other component. They run on seperate CPUs, after all. This means that you can have secure intrusion detection at the kernel level, with secure fail-over to a non-compromised system in the event of intrusion.
On the other, you're now ferrying very low-level data across a network of unknown security. The risk of someone compromising the system by compromising the network is obviously much higher than for a stand-alone kernel.
Last, but not least, to anyone who may be critical of him, Theo de Raadt is perhaps the most brilliant guy in the BSD world and I'd place him as one of the top 3 coders in the world.
As for his infamous "moods" - if he's bipolar, HFA or AS, then his moods (and his brilliance) are entirely explicable and nothing to condemn him for.
Re:No plans for SMP... (Score:5)
SMP is plenty interesting to the Linux crowd. They have spent a huge amount of time working on it. The fact that it isn't interesting to Theo and the folks working on OpenBSD simply highlights one of the benefits to the Open Source way of getting things done.
If you start your project on OpenBSD and decide that you need SMP to get the performance you need "porting" to Linux shouldn't be much harder than moving your source to a Linux box and typing "make." If, on the other hand, you develop on Linux and then decide that Linux's security isn't good enough for implementation, you can just as easily port to OpenBSD.
There is never going to be an Uber OS that is specialized for every task (although the generic Unix way of recompiling the kernel does come close). That's why standardized APIs are so important. That way you can change your OS midstream if it isn't giving you what you need. The Open Source community has done a pretty good job of matching up APIs.
Theo: Version Number Specifics (Score:5)
I don't think it's fair to say, as you did, that "ftpd is ftpd" or "tar is tar" for all of OpenBSD. Examples from version lines throughout OpenBSD:
spork# perl -v
This is perl, v5.6.0 built for sparc-openbsd
bash-2.04#
GNU troff version 1.15
bash-2.04# nawk -V
awk version 19990620
bash-2.04# gcc -v
Reading specs from
gcc version 2.95.2 19991024 (release)
bash-2.04#
Concurrent Versions System (CVS) 1.10.7 (client/server)
[vi
Version 1.79 (10/23/96) The CSRG, University of California, Berkeley.
bash-2.04#
tcpdump version 3.4.0
libpcap version 0.5
bash-2.04#
Server version: Apache/1.3.12 (Unix)
Server built: May 5 2000 14:44:59
Look. Some of these you modified. Maybe all of em. Maybe one of em(I *know* you touched Perl.) Lets take the example of tires, why don't we. If I've got Firestone Model X432LFR tires on my car, and I run down to the dealership asking why I'm driving a deathtrap, is he allowed to laugh at me because "Of course *we'd* never put the deadly X432LFR tires on your car, we'd only put the *good* X432LFR tires on! Stupid customer."
That's essentially what happened with Debian a while back, and it was infuriatingly unfair.
I'm not asking you to do more work, Theo--you've *done* the work. I'm asking you to admit it, mark it, brand it in such a way that we know you've been forced to do something to it to make it secure. And then all of us can bitch and moan to the author's of whatever package you've taken and say, "Heh, he changed your stuff, maybe there's something you should look at." Maybe we'll be ignored. But, in the end, *you* did the right thing.
Theo: You and your team rewrote much of an early build of SSH. Technically, you could have said, "Here's SSH1.2.1x, as part of the OpenBSD system." But then nobody would have known what you had pulled off, and people would have had trouble finding your specific improvements. I'm not saying you need to rename every package to show how much you've added. But to keep the original version numbers is to conflate your secure and solid version with whatever bugs you *know* lurk in other people's code. When Foobar 1.2 comes out with a remote root, and OpenBSD ships with Foobar 1.2, do you like--or enjoy--when system administrators frantically upgrade your *already fixed version* of Foobar 1.2 with the original author's possibly broken Foobar 1.3?
Because that's what your version numbers cause.
They're easy to fix, Theo. It's just a tag to let us know you fixed something. It's something for us to differentiate your code with. (Incidentally--what does little on my 2.7 Sparc build.) Consider this: As much as you say you've only dealt with the system, I *know* many of the packages from Ports have had patches that didn't modify version numbers--and I have *no* idea if anything's been modified in your packages section. I just don't know.
This is not a problem specific to you, but I think OpenBSD is in the right place to change what I consider to be a particularly pernicious industry practice. I believe in your systems approach, but a secure system cannot be built from insecure parts. If you've secured your parts--show this, and perhaps let us know where to look to find out how.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
"But it works." (Score:3)
See also: the "HTML" on the supposed "geek web site" called Slashdot. (as well as, to be fair, the rest of the web.)
Hey, where's my question? (Score:3)
Mac OS X & BSD [slashdot.org]
I'm curious about how the BSD folks view the impending couple million new users they've got heading their way when MacOS X is released.
Please, no Mac-rants, they're trite & off-topic. I just wanna know about the question.
No upstream (Score:4)
As a Linux user, one comment Mr de Raadt made surprised me:
In Linuxland, cat is GNU cat, tar is GNU tar, httpd comes from the Apache project, rpm comes from Red Hat, and so on. There is always an upstream maintainer for any particular package and no distributor (AFAIK) tries to maintain its 'own' releases of things. If a bug is found, the fix tries to swim upstream to the breeding ground, where it can add itself to the gene pool for future releases of all distributions. (Alas, I do not have a ten-man team auditing my comments for dodgy metaphors.)
I suppose it makes sense in a way to have your own codebase, especially if you are concentrating more on security than on adding new features. You have control over every line of code that goes in, and you don't mind missing out on new versions of stuff that is released. Also, if your original 'upstream source' is a group of people you split acrimoniously from, you might prefer not to rely on them. (Although I can't help feeling that if the OpenBSD and NetBSD people made more of an effort to commonize code in both directions, the feud wouldn't have lasted as long. This sort of thing going on between two Linux distros - eg Mandrake and RedHat - would be unthinkable.)
But not relying on an upstream maintainer for packages does not mean you can't contribute your fixes back. All the BSDs originate from a common code base, right? There must surely be at least 95% common code in the shell and shell utilities (which change relatively slowly), even if the kernels have diverged. So what effort do they make to avoid reinventing the wheel? And when OpenBSD fixes a set of bugs, do they report them to the maintainers of the original package?
Perhaps the problem would be that they couldn't agree on who should be the original source. Imagine if NetBSD claimed that they were now the 'official' maintainers of BSD make, for example. Would OpenBSD accept that? Perhaps some neutral 'BSD Foundation', with support from all three free BSDs, could take over maintenance of the common or fairly-common BSD code. Or somebody from Berkeley (Bill Joy perhaps?) could make a ceremonial proclamation.
Theo misses a point (Score:3)
system (firewall/router, et.al.) is not to use
the floppy, but, to make it simpler to configure
than "BOOTP/Diskless".
In a floppy-based system like that (firewall), the
floppy would be used to boot the host, that is all. The goal is to have *NO* disks, or any other
moving parts.
Why you should be afraid of forking. (Score:3)
snip
Why are you guys so fork paranoid?
Looks to me like you've already answered your own question, Theo.
-
Before flaming Theo ... (Score:5)
And what's wrong with that?
OK, he's no "Dear Abby", but neither is RMS. I know many here aren't big RMS fans, but are you insecure enough about your own little world that when someone says, "Quit bothering me with stupid details, just write the code" you start flipping out? I attended Supercomputing '99 and went to a talk by Thomas Sterling, one of the original Beowulf pioneers at NASA. A good chunk of his talk was spent complaining about "Linux cruftiness" and "why are you people here when you could be writing code"? I admit I was somewhat pissed coming out of it, but it did have the effect of motivating me to start programming again. I think sometimes we just need a swift kick in the arse from someone (hi Greg!) to get motivated.
Bottom line: ignore the stupid "Are you mad?" comments from someone whose ego is a bit too big to take the time to be polite, and focus on the "learn your APIs, understand your APIs, and stop writing shitty code." Learn the message, ignore the messenger.
-jdm
(I'm ready for my big Mod-down, Mr. Director :)).
Missing the point on floppy-based routers? (Score:5)
Flash RAM would be perferred, but flash disks are hardly ubiquitous and free-for-the-taking x86 systems that work great as routers don't generally have flash-based disks installed. A floppy drive is almost a given in any system.
The hardware advantage of a system without a hard disk is the reduction of heat generation, meaning they're easier to put in heat-hostile environments like telephone closets. System upgrades are a snap, since you just move the disk to another platform.
As far as security goes, other than floppy disks general lack of reliability, what's the problem with them? They're physically write-protecable, which many IDE disks aren't. Sure it's easier to swap a floppy out than a HD, but if your machine doesn't have physical security to begin with you've failed the first checklist item for security.
BAH! (Score:3)
Any advise for code auditers?
Theo:
I suppose the biggest tip would be to become a better programmer.
Bah Humbug! Thats equivalent to
Question:
How do I become a better sprinter??
Theo:
I suppose the biggest tip would be to just to run faster
Re:This is ridiculous. (Score:3)
Maybe being able to use a system as a firewall/gateway that makes me sleep at night because i feel confident that it will not get h4X0red.
I really don't give a fsck if it doens't have SMP support. What's the REAL percentage of online SMP boxes anyway? I'll admit the it is really nice (and usefull) but i'm sure there's a majority of sites that simply don't need it (yet).
---------------------------
"What is the most effective Windows NT remote management tool?
Re:This is ridiculous. (Score:4)
Uh, right. So go ahead and write an entire operating system in a new language then. Don't forget to design the language first though! Remember the C-bashing thread on Bugtraq over the summer? Whatever its limitations, we are stuck with C
2. The proper approach seems to be a very limited operating system, perhaps in C, with a virtual machine over that which is proven secure, thereby giving at least strong security to every application then running ontop of that VM.
Nice theory, much like many of the other 'ground-up' papers I've read. And meanwhile, while you sit posting and postulating on the great designs that will rule the operating systems world, I'll just use OpenBSD, and be happy with the stability and reliability of the system. Perhaps I'll look you up in ten years when you've finished this idea?
What is the point? Why bother if you aren't even going to put in SMP?
I really, really don't care whether or not OpenBSD has SMP. If I need a faster box, I'll just upgrade to a faster processor. The majority of server systems these days are either I/O or connectivity bound these days.
This is ridiculous. (Score:4)
Here's the main point, before we even get started: This project should be scrapped, there are easier and better ways to do what is being done here.
Now the reasons.
1. The fact that you need to go back and hand audit libc calls for "subtle" errors means that the wrong language is being used for the majority of these tasks.
For these types of ultra secure tasks, there should be extremely limited cases, and ideally no class of errors that would be "subtle" when it comes to standard library calls. I would suggest that C is not a good language to write a secure operating system in, because it very obviously requires too much manual labour to weed through the subtleties of it's operation.
2. The proper approach seems to be a very limited operating system, perhaps in C, with a virtual machine over that which is proven secure, thereby giving at least strong security to every application then running ontop of that VM.
Yes you'll need to audit that first limited OS and kernel, and yes it'll probably be in C, but let's limit the scope of that code severely. Plan to take a huge performance hit on running everything on that VM but make sure that it's totally secure, do whatever it takes to make sure that everything running on it is protected from itself and other programs. This is the only possible way to make an extensible operating system that is in any way secure, otherwise any software that is later added to the system will either need to be painstakingly audited or not installed. Performance should be a minor concern at this point as VMs can later be optimized, and security should be of prime importance.
3. After they finish all this auditing, we're left with a non-SMP capable OS with limited software of a similarily secure nature to use it with.
What is the point? Why bother if you aren't even going to put in SMP?
4. Theo is obviously so closed minded that no efficiency ideas are ever going to occur to him.
Witness his response to the question about distributed kernels - (in summary) "I have no idea what they are, but they're not useful to me." Great.
It is my opinion that people of this caliber of programming should be spending their time at doing more useful, or perhaps better thought out work.
Moderate at will.
Re:Forks are Good! (Score:4)
In Linux land, it appears that projects fork for financial reasons. In BSD land, it appears that the forks that have happened were purely political reasons. I don't know what will happen. It's been 5 years since the last fork in the BSD camp. Why are you guys so fork paranoid?
I suspect that the question was rhetorical, but it deserves an answer. I'm putting it here, with the other fork comment, even though it wasn't written as a follow-up to that comment.
Simply put, it's (too) often used as an object lesson in Linux land. Whenever an argument gets too heated, someone jumps in with "if we keep acting like this, we'll end up like the BSDs." Meaning, I suppose, "fighting over a very tiny percentage of mindshare instead of working together to take over the world."
I suspect that Linux is headed toward a fork. Linus and Alan Cox have been leaving things out of the kernel (like a debugger) that a lot of people want. As there's no charter or formal organizational structure, I think that a coup of some sort is inevitable. When it happens, the interest in the Net/Open split will rise to a crescendo.
I have friends who are OpenBSD advocates, and others who are NetBSD advocates. To hear each side talk, the other side writes crappy code between bouts of trying to ruin BSD for everybody. It's depressing, particularly when I think about what could happen if their talents could be combined. Or, if they would just shut up, stop sniping at each other, and code.
I'd love to see some sort of cross-bsd advocacy organization to help users take that middle step. Help with porting of cool shit between the BSDs. Make generic cross-BSD documentation. Help people decide which OS and user/developer community is right for them. etc.
Unfortunately, that requires a friendlier attitude than I often see between the BSDs. Charges of "code theft" particularly frustrate me. That's the whole damned point of open source: Seeing the good stuff, learning from it, and using it.
--
Re:distributed kernel ... (Score:3)
Re:Missing the point on floppy-based routers? (Score:3)
It seems very difficult to obtain the same characteristics from a harddisk (or flash ram); I don't know how to physically prevent writing on a standard IDE hd. And if you use the hd just to load the FW into ram, and "hot-swap" it out, then it won't come back up, after powerfailure (even UPS's have their limits).
Floppy disk reliability is not much of an issue, i think, since the floppy isn't used to as a long term storage medium. Remember your friend dd:
"$ dd if=/dev/fd0H1440 of=floppy-image
2880+0 records in
2880+0 records out
$ dd if=floppy-image of=/dev/fd0H1440
2880+0 records in
2880+0 records out
$ The first dd makes an exact image of the floppy to the file floppy-image, the second one writes the image to the floppy." (SAG v. 0.6.2)
(And of course, one can always mount the dd-image; "mount -t ext2 -o loop")
So you develop, maintain and store, the actual FW information on another box, then write the image to a floppy (and making a backup fd image on the development box). All the floppy has to do, is to survive the initial boot. It may have to survive reboots, caused by powerfailure, but even if it does not (harddisks may fail too), a disaster recovery plan is part of the floppy disk based FW scheme; just write a new image, and boot. How many hd-based FW's has a spare harddisk, with a synced and updated system on it?
If you just have a slight suspecion, that the FW is compromized, then a reboot will flush out any trojans and root kits. The firewall may still contain som sort of security hole, but rebooting may give you time to discover what the hole was, and deploy a new FW.
Floppy based firewall is a very cool thing. It doesn't fit everybodies need, but it may be a viable solution to a great many.
Cdroms may offer similar advantages, but they may be slightly more difficult and expensive to develop and maintain.
In short; Firewalls on write protected media, seems to be a very good idea.
Design vs. Implementation (Score:3)
He then goes on to say that he really doesn't care about kernel design, so long as the kernel design works.
These two issues are completely different.
Lets face it - he's an implementation junkie. Which I would guess was not, and still is not, popular with the NetBSD crowd, as he probably had to step on a few toes...
'You're not using strcat correctly. You've introduced 6 exploitable bugs into the kernel'
'What do you mean I'm not using strcat correctly?? I've been coding since I was twelve years old!'
Cyano
Re:Missing the point on floppy-based routers? (Score:3)
md5sum the whole floppy[*]. On booting, if the floppy image does not have the same checksum, abort. Then it's possible that the router might not boot one day, but it's impossible for the disk to corrupt without you noticing.
[*]ok, md5sum all of the floppy apart from a file containing the md5sums.
Do it right! (Score:5)
Hear, hear! Two of my pet peeves right there:
(1) Why is it that the same bugs keep reappearing? Why is it that we assume bugs only occur in one place? Why is it that we hear, "I fixed the bug," as if a programmer can only screw up in one place?
(2) Every other piece of engineering goes through major scrutiny. Teams are brought in from the outside to look over blueprints. For open source software, we assume that just because anybody can look at the code, that everybody is. Even in OSS, we need to go to outside, objective reviewers and say, "Here's some money, and here's our code [or maybe, here's the URL for our code :-) ]. Please review it and tell us where we screwed up."
Mr. de Raadt knows his stuff; the coders do this themselves, and they take it seriously.
Re:But he doesnt follow his own advice (Score:3)
You wrote
In his first reponse, Theo wrote They don't care about good software, only about "good enough" software. Which I would paraphrase as software that doesn't make security a design goal.
In his other response, Theo wrote As well, I don't think it makes any difference, as long as a system does what it is supposed to do. Which I would paraphrase as software should achieve it's design goals, like security, no matter how it's implemented.
There is no contradiction in those two statements.
Ego based contradictions (Score:3)
As well, I don't think it makes any difference, as long as a system does what it is supposed to do.
This is a fairly asinine thing to say, especially since the second post had a very good point (Micro vs Monolithic kernels). My opinion of Theo is fairly low after this. Instead of responding with a mea culpa (yes a micro kernal is better, of course it's better to keep privledged code to a minimum, but it's also difficult to totally re-engineer a kernel especially when it works) we get mindless thrashing about micro kernals..
(an operating system based on 70's technology dissing ideas from the 80's as obsolete? Kind of ironic..)