Haiku Insecurity

I shouldn’t have wasted my time responding to one of the true believers at OSNews. My previous remarks about BeOS, Zeta, and Haiku aren’t personal — they’re specifically aimed at a handful of issues I think are relevant to the present and future of computing:

  • user adoption
  • application availability
  • technological relevance

Novelty may appeal to a certain breed of user, but it won’t work for the masses. No mass appeal, no application development; no applications, no mass appeal. Vicious circle. But the true believers just can’t see that so they blissfully work on their own little word processor wasting GSoC resources (waste = really bad priorities: your OS doesn’t have a functional network stack yet!).

I’ve also touched on a few issues with respect to technological relevance. One of them is scalability: Haiku OS is 16MB uncompressed. Cool. Linux is 6MB compressed. Linux is scalable, Haiku (thus far) isn’t. The future isn’t the desktop, the future is mobile. Linux is mobile, Haiku isn’t. Etc. Thus, Linux is relevant, Haiku isn’t.

Another issue of technological relevance is security. Sadly, Team Haiku’s goal for R1 doesn’t include much in the way of security. It will be single user — just like BeOS, just like Win95. It will have nil security from levels of permissions to affect system-wide changes, just like Win95 (but something MS dealt with in NT server and workstation editions and carried over to ME, XP, and Vista). So Haiku’s early adopters will be computing in circa 1995 environment where a local or remote exploit can result in full control of the computer on which it’s running. That isn’t going to increase the rate of immigration from other OSes — that’s a barrier to adoption. Why on earth would anyone go from one vulnerable OS (e.g., any flavor of Windows from ME on) that has regular security maintenance to one that has none? Or worse, why would they change to an OS that has a security level about 12 years behind what’s needed now?

Worse, I found this on haiku-security.com:

One I can definitely state as a major security risk is that you can call delete_area() with the ID of *any* area, even of the kernel, and delete it from any process.
When you do that with a kernel area, chances are you’ll quickly find out how quickly your system reboots.

Fortunately, Haiku boots in just a few seconds. That may not be of much use, though, when a Baltic nation grade-schooler has control of your Haiku computer.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: