One thing I like about Cube OS is that every single application is put into a virtual environment, so incase the application got compromised, it can’t do shit to the OS or affect other applications. Plus this is good to protect user’s privacy. Some applications, even though don’t do anything malicious, they can still collect personal information about the individual user such as the user profile’s name. Think about how Android applications collect so many personal information such as the person’s SMS messages etc.
Can we make something similar to Cube OS’s security features?
Haiku is already on OpenBSD’s proven security model. Be so obscure that nobody with malicious intent would bother trying to wreak havoc on the userbase. Then claim no holes in the default install until you piss off that one dev who tells the world about a flaw that you knew existed but nobody else cared to exploit, but now needs to be patched because of someones big mouth.
Our view of security: currently, we don’t provide any. The default user is root, it is impossible to run graphics app as any other user, and there are things in the API that allows escaping chroots (eg. the ability to open files by inode number). These are flaws we can’t fix in R1 because changing these things would break compatibility with BeOS.
There has been no audit of the codebase and it is likely to have many problems. We will fix them as they are found and when it is possible without breaking binary compatibility. Otherwise we will take note and rework the APIs for R2.
If your interest is in security, Haiku is not exactly the worst choice (there are some other OS with still no memory protection at all out there…), but there are certainly a lot of better alternatives, both free and commercial.
Just a little tip: Android apps do not collect user information because android/unix is insecure… they collect user information because users grant them every permission they ask for like reading contacts permission. In Android every application is assigned a unique user-id/group-id when installed. Process A can not access anything it has no rights to (it’s own data in this case). Protected mode does the rest (prevent memory access outside allocated memory pages). This system works… as long as CPU doesn’t try to be “smart branch optimizing”
This seems a bit of a strange attack on an OS that is (1) almost entirely focused on security, (2) has developed several security components used by almost everyone, everywhere (openssh - obscure, really???), (3) developed several other major network infrastructure components in use across many different operating systems (even windows), and (4) is actually used by several manufacturers in devices like firewalls and intrusion detection systems.
Could also mention that their user base is far larger than haiku (so they are less obscure), and that haiku is entirely open about there being (somewhat major) security flaws.
But haha only serious on the security through obscurity. Regardless of how less obscure OpenBSD is than Haiku, it is rather obscure in the grand scheme of things. The ‘n’ remote holes in however heckin’ long were there for years before a disgruntled user finally said looky here, a hole! If that user hadn’t had an axe to grind, that first hole likely would have remained in the land of “feature.” I’m not knockin’ their code review. It’s top notch. But had someone not pissed someone off, OpenBSD would likely still be listed as the virgin mary of unpenetrated systems. Security through obscurity isn’t a bad thing. I actually live my life through it. And it works great!
While OpenBSD is doing great work on security, I agree that their communication strategy and metrics aren’t the wisest. We could also say “look, there is no CVE mentionning Haiku! We are secure!”, but this is obviously the wrong thing to look at.
Opening a program where we give some money to people finding security holes may be a better one, but if we did that in Haiku we would run out of funding pretty quickly. So let’s first take the time to revisit this ourselves and have some confidence before we get into such things.
Yeah, I guess the slogan’s focus on the number of remote holes is just asking for trouble, but it is at least a noble goal (and a challenge).
Perhaps the fastest way to get security problems on haiku fixed would be to put a big statement on the front page stating that it is the most secure OS, with no CVEs at all!
Do you feel like people who download a Haiku nightly understand how insecure the system they’re getting is? Will that change for Haiku R1 Beta 1 or a Haiku R1 finished release?
You can ask the users of every other OS too about this.
Haiku is feature complete, BeOS had no firewall, ACL, security sub-systems, multiuser support: so nope, but you can start to implement them in your branch.
