Linked by Thom Holwerda on Tue 30th Aug 2011 17:29 UTC, submitted by Dale Smoker
OSNews, Generic OSes "What would an operating system look like it if were redesigned with security in mind? Joanna Rutkowska thinks she has the answer with the development of Qubes OS. We sit down for an interview with Joanna to discuss the way Qubes OS augments security."
Thread beginning with comment 487998
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: What would it look like ...
by bannor99 on Thu 1st Sep 2011 23:35 UTC in reply to "What would it look like ..."
Member since:

I don't think so. OpenBSD is secure mostly because the code is audited, which is tedious, and they try to adhere to best practices of coding for an insecure languages.
IMO, redesigned for security means from the ground up.
It's the difference between a maximum-security prison and a fenced stockade with dogs and frequent prisoner checks.

In short, designed for security means it should be hard for you to accidentally create a security hole while still being completely functional.

Reply Parent Score: 2

Alfman Member since:


"I don't think so. OpenBSD is secure mostly because the code is audited, which is tedious, and they try to adhere to best practices of coding for an insecure languages."

I tend to agree that sometimes this is the best we can do, but security problems also stem from failure to keep a handle on complexity. Complexity is the enemy of security. How does OpenBSD stand next to linux in terms of complexity?

The ideal solution (in terms of security) would be for all components to be isolated and communicate through well defined (and enforced) IPC - essentially a microkernel.

"IMO, redesigned for security means from the ground up."

I put forward some ideas a while back while discussing Neolander's work. Starting with a safe language, we could build components who's isolation is enforced through the compiler instead of through MMU/CPU protection hardware. This would eliminate all the overhead traditionally associated with microkernel IPC. One component would pass around object references as efficiently as calling a local function. The compiler would be responsible for ensuring a buggy component couldn't corrupt another component in the same memory space. Since the references are isolated, variables are type safe, and arrays are bounds checked, even a malicious programmer is unable to mess with other components except through the well defined interfaces. And even those could be secured through policy.

Oh how I wish I could earn a living building it.

Reply Parent Score: 2

bannor99 Member since:

QNX seems to have been able to build a true microkernel OS that performs very well - how did they do it?

Complexity may be the enemy of security but you cannot do away with it completely so you must have safe designs, tools, languages, etc.

I think we chose the wrong path decades ago and we may never fully switch. What i mean was that the monolithic design prevailed because of its performance and we had to live with the bugs, security risks, crashes and system restarts.
The $100 billion question - would we have been better of to go microkernel and try to mitigate the performance deficit ( which would improve quickly over time as hardware sped up by leaps and bounds every few years ) or did we do right by choosing performance and having to live with the downsides of the monolithic design?

Reply Parent Score: 2