Slashdot Mirror

I've just spent the past few minutes trying to (re)find this story. Is it the KeyKOS recovery speed story from 1990?

FYI, both pages are 404s because of the trailing slash. These links work:

http://www.eros-os.org/~shap/NT-EAL4.html
http://www.cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM

"The FedRAMP security assessment process defines a set of controls for low and moderate impact level systems based on NIST SP 800-53 controls." (FedRAMP Website) The key words here are "for LOW AND MODERATE impact level systems." Low and medium robustness are what the government usually accepts. All kinds of stuff that was routinely compromised fits that profile too. The Shapiro [1] paper on the Window's EAL4 evaluation illustrated why it actually meant "certified insecure" and sadly still applies to this one. At least the NIST standard has plenty of useful controls to keep out the riff raff attackers. The EAL7 or Orange Book A1 certification are very rigorous security standards. So few products reached that level that I could fit many of their names in a single tweet (97 characters actually). Cygnacom has a nice breakdown [2] of the assurance levels and extra work that must be done to verify the entire lifecycle to reach something resembling secure. Such solutions look... nothing like Azure. And Azure was neither built on such standards nor evaluated to one. It's not secure. QED. Nick P, Security Engineer, schneier.com contributer 1. http://www.eros-os.org/~shap/NT-EAL4.html/ 2. http://www.cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM/ (Note: I originally posted this comment in the wrong spot. Reposting it here. Rarely use this comment system so my bad.)

"The FedRAMP security assessment process defines a set of controls for low and moderate impact level systems based on NIST SP 800-53 controls." (FedRAMP Website) The key words here are "for LOW AND MODERATE impact level systems." Low and medium robustness are what the government usually accepts. All kinds of stuff that was routinely compromised fits that profile too. The Shapiro [1] paper on the Window's EAL4 evaluation illustrated why it actually meant "certified insecure" and sadly still applies to this one. At least the NIST standard has plenty of useful controls to keep out the riff raff attackers. The EAL7 or Orange Book A1 certification are very rigorous security standards. So few products reached that level that I could fit many of their names in a single tweet (97 characters actually). Cygnacom has a nice breakdown [2] of the assurance levels and extra work that must be done to verify the entire lifecycle to reach something resembling secure. Such solutions look... nothing like Azure. And Azure was neither built on such standards nor evaluated to one. It's not secure. QED. Nick P, Security Engineer, schneier.com contributer 1. http://www.eros-os.org/~shap/NT-EAL4.html/ 2. http://www.cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM/

Before anyone jumps on the band wagon and says that we all have perfectly usable user space desktop apps for 28 years in the UNIX world, let me say that it is actually very important that now even Microsoft starts to understand that modularity is the way to go while designing complex systems. Moving various operating system components to the user space is just a logical conclusion of the research done during the last four decades. Look at the direction of modern OSii development, from MINIX to GNU. Started by GNOSIS, KeyKOS, EROS and Coyotos this trend seems to suggest that it is much more natural and reliable to design a secure capability-based system when all of the services are separated from each other. Now when even Microsoft is going in that direction - and it is not a trivial change for them, trust me - we can expect Apple and other OS vendors to follow which is a Good Thing. After all, even if people like you and me are using secure operating systems we still don't want to get spammed and dossed by all of the legacy machines out there. It turns out that the rumors that Microsoft is starting to take the latest research in operating systems seriously turned out to be true. This is good news for everyone.

Because sometime in the 1980s people decided that user-based ACL was the easiest way to do security. The alternative was capability-based security like KeyKOS and IIRC AS/400. Imagine only using filehandles. You can't write to a file you have no rights to, because you don't have the filehandle and no way to get one. No "permission denied", because there simply is no system or library call to do it. In such a system, there is no "this program can do X, that user can do Y", instead when launching a program you give it capabilities: I launch the flash program, with A% of CPU, r/w filehandle B to some MB of memory, r/w filehandle C to some MB of disk, r/o filehandle D containing a flash file to execute, r/w filehandle E that is an console (X window) for reading keyboard and mouse events and writing screen and sound. For a basic program, that's all. Maybe in the nitty-gritty you also provide a r/o filehandle to access the system library, but nothing in that library will give you any means to influence the computer you're running on. Virus-proof? Maybe there's a hardware bug, like the Pentium F00F, maybe the sound card will react to a specific sequence, but otherwise AV providers are out of business. http://www.eros-os.org/ links to all of that.

I just read about EROS last week . . . don't know how well it works, and it's probably old news to a lot of people. But the concept seemed interesting. EROS OS

Dropping C... for what exactly? We're not talking application level security. We're talking kernel level. That means talking to the bare metal. Even if you implement a microkernel with userspace modules for everything, and with those modules written in something more robust than C, that last crucial bit of code that is the microkernel itself is probably going to end up being written in C with ASM snippets, simply because at some point you need to explicitly state what the hardware is doing.

There's no reason why the kernel has to be written in an "unsafe" language such as C. It has to be written in a low-level language to be usable, sure, but it is quite possible to design a "safe" low-level language. One example of such project was BitC. Don't mind the Lispish syntax - they've used it because they didn't want to waste time on designing a proper syntax, and parsing it. Aside from syntax, this thing is nothing like Lisp at all.

The sad part of it that the project has stalled now because the main guy behind it was hired by Microsoft to work on the prototype of their own next gen OS, which seems to also be built on the same principles, from what little that we know about it.

There's little or nothing original that's being presented here. The Phantom people claim originality to the idea of orthogonal persistence, but they are flat-out wrong:

Q: File system?

A: Nope. Sorry. Nobody needs files in Phantom. All the operating system state is saved across shutdowns. Phantom is the only global persistent OS in the world, AFAIK. All the state of all the objects is saved. Even power failure is not a problem, because of the unique Phantom's ability to store frequently its complete state on the disk.

To illustrate the utility and awesomeness of persistence, there's a famous story about KeyKOS, an earlier OS that embraced this notion:

At the 1990 uniforum vendor exhibition, key logic, inc. found that their booth was next to the novell booth. Novell, it seems, had been bragging in their advertisements about their recovery speed. Being basically neighborly folks, the key logic team suggested the following friendly challenge to the novell exhibitionists: let's both pull the plugs, and see who is up and running first.

Now one thing Novell is not is stupid. They refused.

Somehow, the story of the challenge got around the exhibition floor, and a crowd assembled. Perhaps it was gremlins. Never eager to pass up an opportunity, the keykos staff happily spent the next hour kicking their plug out of the wall. Each time, the system would come back within 30 seconds (15 of which were spent in the bios prom, which was embarassing, but not really key logic's fault). Each time key logic did this, more of the audience would give novell a dubious look.

Eventually, the novell folks couldn't take it anymore, and gritting their teeth they carefully turned the power off on their machine, hoping that nothing would go wrong. As you might expect, the machine successfully stopped running. Very reliable.

Having successfully stopped their machine, novell crossed their fingers and turned the machine back on. 40 minutes later, they were still checking their file systems. Not a single useful program had been started.

Figuring they probably had made their point, and not wanting to cause undeserved embarassment, the keykos folks stopped pulling the plug after five or six recoveries.

The notion of a language-based OS exploiting the semantics of pointerless/"safe" programming languages in order to isolate processes, rather than the norm of executing untrusted native machine code in different address spaces, is nothing new either.

If these ideas shift your bits, take a look at some real, interesting work done by real people that have more clue than fashion:

• Coyotos, an OS whose orthogonal persistence falls out of the capability model of security that they embrace. Coyotos is written in BitC, a purpose-built high-level programming language with special focus on formal semantics and reasoning.
• Singularity, a language-based OS in development by none other than Microsoft Research. (Certainly the most interesting Microsoft project that I am aware of.) Singularity exploits language semantics to isolate processes.
• TUNES, a collective wet-dream of what the OS, programming language, and generally computing system of tomorrow should look like. With all due respect towards the insurmountable difficulty and endless complexity of a task like this, it must be said that TUNES is just vaporware.

Linux is, indeed, based on what is now a very old paradigm - approaching half a century. Concepts have advanced since

No, actually, concepts have not advanced. The hardware is larger and faster, but from the perspective of software the design of any modern OS, from PDA to supercomputer, is entirely familiar to anyone that wrote system software for an IBM 360-67 (virtual memory and 32 bit addressing) as early as 1966. With the possible exception of extraordinarily high real concurrency (and some of its consequences such as STM) everything we see today was present and fully exploited by software in those systems.

The fact that it didn't take very long to produce software designs sufficient to fully exploit the hardware doesn't mean the software is designed incorrectly. It just means the problem space isn't that complex. There are many research operating systems for the same reason; they're not hard to make.

A prime example is the notion of "restarting" a computer. Why, these days...

Damage accumulates. Resource leaks, fragmentation, failed subsystems that aren't designed to restart without power cycle, cosmic rays, etc. All of these "concepts" are ancient and unchanged. They won't be changing for the foreseeable future.

Solutions to these problems exist but remain expensive and imply limitations on the resulting product that confines their application to highly vertical and/or costly systems. The general purpose, inexpensive systems on which you expect to run practically any trash you might throw at it do not meet that standard. They could be made to at the cost of becoming unaffordable. You would also find the inflexibility of a rigorously reliable system intolerable for a personal, general purpose use.

You're the reason, in other words.

Is it possible that some new OS design can reduce the costs? I don't know. What I do know is that the ideas behind Phantom OS have been tried before, and you and I are still running 30-40 year old designs to read about the many attempts.

The concept of "files" is archaic

The concept of a named persistent sequence of data is not going away no matter what you call it or how many abstractions you pile on top. If the word "file" is too prosaic feel free to employ the "document" euphemism.

Multicore machines could solve a big problem with microkernel architectures -- high context switch costs. If you lock down the microkernel to one of 8 cores -- let it monopolize the core -- then there is no context switch cost! You could then use a microkernel to implement Capability security architectures, which can provide mathematically provable security!

http://video.google.com/videoplay?docid=1762847950860111011

A recent email thread on the cap-talk maling list (set up by Jonathan Shapiro, the author of the linked article) recently discussed Singularity as a capability system . Summary: it is a capability system but does not take advantage of the fact very well.

As others have pointed out, "managed" code refers to the use of automatically managed memory allocation rather than manual use of malloc/free. By combining that with type safety and array bounds checking, many classes of C/C++ bugs are eliminated or reduced. The penalty of course is that you need to run a garbage collector.

You should never be forced to trust any program to do what it's told. The OS should make sure it stays within the boundaries you set for it... or better yet... only gets to use the capabilities you offer it.

Hopefully they'll get over the fixation in time, before a random mix of computer virii and malware "mate" and produce a sentient rootkit that takes over the internet. (I'd estimate we've got 10 more years before this is going to happen)

A leap in security technology will take a requisite leap in human intelligence.

Not at all. A leap in security will take a requisite change in our development tools, from identity-centric abstractions, to authorization-centric abstractions so we can achieve the Principle of Least Authority (POLA) for all software. Ultimately, it's not about adding security, it's about removing insecurity; most languages have insecure abstractions baked into them, and when those are removed, the resulting software is significantly more secure, and yet, poses no significant burden on the developer; quite the opposite in fact: the software becomes more modular and maintainable. See the discussions on capabilities, and the E, and Emily capability-secure programming languages for examples. There have been numerous case-studies on the vulnerabilities of identity-centric services, and how they were rectified by refactoring the service to use authorization-centric models.

Whitelisting an entire app is too coarse-grained. We need to be able to whitelist the actions that a specific app can take. For example... by default, microsoft word should only have read-only access to its own files and library files needed to run. It should have no net access whatsoever. It should have no access to any of my personal data files. It should have no access to my keyboard when I'm typing in another app. It should have no access to drawing on any portion of my screen outside its own window. It should have no way to spoof another app's name in the window titlebar. It should only have read/write access to the single file that I click "open" on to edit.

Since I have to choose the files I want to work with in a file open dialog anyway, we force microsoft word to use a system-wide, trusted file open dialog which is the only way to grant it access to more files.

See http://plash.beasts.org/ and http://www.eros-os.org/essays/capintro.html

The existence of vigilante software like this is, in my mind, one of the strongest arguments for capabilities-based security. In traditional systems with ACL-based security (i.e., every popular PC operating system today), we really don't have a way to say "I trust this program to record video from my screen, but not to delete all of my documents." A properly-implemented capabilities system, on the other hand, could give us just that.

See http://www.eros-os.org/essays/capintro.html for a better introduction to capability systems than I could possibly provide here.

No. X is still broken. However I understand there is a seperate project Nitpicker (part of TUD-OS)to solve that.

But it doesn't seem like it's on as deep a level as I'd like. It's better, but it still means that once I send a document to Firefox, I have no idea what Firefox will do with it. Still, that is a lot better.

I am not sure what you mean. It was the goal of the EROS-OS project to break software into tiny chunks and apply least priviledge to each. One could get even finer grain protection if writing with a safe language. Even so, if Firefox as a whole is malicious there is no way of stoping it misusing whatever rights you give it.

Now is there anyplace where a program would open some standard file all the time without having to ask the user to find it? hmmm. There will probably be a separate call for "please open a scratch file".

Yes, I believe so. Each application should be allowed to open temporary files.

How abouit opening spell check dictionaries?

I think read access to harmless, shared stuff like spelling dictionaries, fonts, etc. would be allowed automatically. Of course, eventually a program will want to do something it has no authority to do, and the user will have to decide. The important thing is that a lot of the time no questions need to be asked, and if some malware wants to do something inappropriate it should be obvious.

I'm not an expert, though. If you have further questions you're best off asking them at cap-talk.

By design it was impossible for KeyKOS to support variable-sized inodes or disk blocks, partition resizing, etc.

KeyKOS had no notion of inodes or diskblocks, it had a single-level store. Files and filesystems were implemented by processes that operated on red-black trees. There is nothing in the design the precludes the features you mention. Unless of course, you are discussing how to manage storage add/remove disks, etc. when using a single-level store. This is a completely separate issue from microkernels and the KeyKOS architecture.

Even removable media (floppy disks) were a horrible kludge that often threw the object store into an inconsistent state.

Once again removable media are sometimes a problem for single-level stores, not for microkernels or KeyKOS/EROS in particular. I also highly doubt your claim of inconsistency, as the developers were very careful to avoid those ends, so please provide a pointer to validate this claim.

The checkpoint/transaction manager was a performance nightmare once you had to scale to multiple concurrent processes; single process (which were all KeyKOS generally published benchmarks for, aside from a well-known carefully constructed transaction benchmark explicitly designed to make sure that only completely independent data was ever written to the system) were pretty efficient, but tangled references quickly forced the set of objects that needed to be committed to the ENTIRE SYSTEM once you had a fair number of processes running at once. Disk usage was incredibly inefficient.

This paragraph leads me to believe that you have little idea about how KeyKOS operated. KeyKOS and its successors are built on transparent orthogonal persistence, which means a snapshot of the entire system is always written to disk as an atomic transaction. Contrary to your assertion, disk usage has been shown to be incredibly efficient.

Unless by "transaction manager" you're talking about the ATM software which ran on KeyKOS, which would be a completely different matter and unrelated to KeyKOS as a viable OS.

Moreover, the checkpoint system wasn't ACID compliant so you didn't get anything useful for all that complexity; in crash recovery situations, a transaction that had already been committed could be replayed multiple times (causing data inconsistencies or worse).

Checkpointing is and was ACID. If you believe it was not, then please explain.

I could go on, but the major point is that all of these problems stemmed directly from the design of the KeyKOS microkernel, and the barriers to solutions were ones that would not have existed in a monolithic kernel.

Completely untrue. I suggest you read some KeyKOS kernel and architecture papers to learn the true limits of KeyKOS.

None of those problems were easily soluable, and the attempt to improve the system in EROS wound up in a development rathole that was eventually abandoned because of systemic complexity and severe performance problems.

Only partly true. The EROS founder abandoned it in favour of Coyotos because the reliability guarantees achievable via C-based development were too low, and the message passing primitives which defined the architecture made "certain" high-performance designs challenging. This is not "severe" performance problems, any more than Linux had "severe" performance problems before epoll. By high-performance, we're talking saturating Gigabit ethernet here (EROS achieved 90% saturation), which is above and beyond the bandwidth needed for most uses.

Attempts to follow it up (notably CaprOS with the EROS code, and Coyotos recoding the design from scratch) also have achieved little to date.

It's been a year. CapROS has been ported to the ARM, the Coyotos group has developed the BitC language, and the

1. CapROS (successor to EROS)
2. L4Ka and Fiasco implementations of the L4 microkernel architecture

More importantly, the security models currently used in the kernel are broken, and we can formally prove that they are inadequate. Academic research in this area has been extremely productive, but there are major barriers to entry in the commercial world for the obvious reasons.

At the moment it looks like micrkernel architectures (real ones, none of this hybrid stuff) coupled with capability based security systems, should be able to provide real, formally verifiable security. As with most things there are a handful of practical barriers to overcome (primarily performance related), but another 5-10 years and those problems should be sorted out.

For a more in-depth discussion of capability systems, see the wiki page, and this essay by Dr. Jonathan Shapiro. (And to be perfectly honest, he's a professor of mine and my views are colored as such.)

• Unification of all spaces: No more silly separation of persistent file space and non-persistent memory space! Just have one orthogonally persistent space that is fast. This is very possible to implement, even on ordinary x86 hardware.
  This also results in another simplification: A program is either installed and "running" or it is not there. A lot of wasted effort writing "installers" that worry about the persistent representation of the program would become unnecessary!
• As an extension of the previous bullet: Databases, the Windows "Registry" and File Systems all serve the same purpose, and all do it poorly. There is no reason why they cannot be unified to a single object lookup engine (Database?) which is a superset of the functionalities of each
• Generalization of the GUI. Who ever thought that an "application" should manage a window? This is a bad idea, that results in tons and tons of useless uninteresting code that connects GUI widgets to library logic.
  Instead, software should be written as simple functions or "components" (much like Unix commands in a command line pipe) which are easily and even automatically attached to the correct GUI widgets by the GUI. The GUI then becomes completely disconnected from the software logic, which makes it more customizable by the user, and lets the user build his own interesting "windows" that interface him to multiple components. "winamp" and other music players would become mere configurations of widgets that any user can build up. I would guess 90% of the code in the world being written is all about this and would become unnecessary.

Some interesting consequences of the above unifications:

• Excel and other spreadsheets, and build systems become one! Excel applies functions to input data nodes when those are modified and connects their output to various GUI elements (specifi

Check it out... a decentralized trust scheme that overlays on SSL: http://www.waterken.com/dev/YURL/ There's a mailing list devoted to these topics too: http://www.eros-os.org/mailman/listinfo/cap-talk

OTOH existing "Trusted code" initiatives are the equivalent of delcaring a root-only system secure, because you only let a few hundred "trusted" users log into that machine.

IMHO, Operating systems should move towards the "Principle of Least Authority", that each software module should have the least authority required to function. The ideal way of doing this is for the system to enforce ObjectOriented/Functional/Procedural constraints that all OO, functional and procedural programs define implicitly. For example, if you run "uncompress(const File A,File B)" then obviously "uncompress" does should not be able to access File C because File C is outside its scope. Likewise, if you click on "bunnies.doc" in Konqueror and Konqueror runs "OpenOffice(UI ui, FileSystem::open("~/bunnies.doc")), then OpenOffice should not be able to open "~/.bashrc" because OpenOffice was not passed FileSystem. OpenOffice would only be able to access "~/.bashrc" if it is passed the file by an object which has rights to "~/.bashrc", for example ui::FileOpenDialog. The EROS Operating system is built around this principle.

PLASH is an attempt to retrofit this principle into Linux, and Looks really promising. A program constrained by Plash can only open a file if it is passed it on the command-line or by a GTK fileopen dialogbox.

Check out Polaris. It's a way of giving each process on XP it's own ACL. Have a look at the rest of erights too if you want to get an idea of what people who put security *first* are thinking.

http://www.erights.org/new.html

Funnily enough, if you start from a good place, security often follows on naturally without getting in the way, unlike most mainstream operating systems.

Also have a look at EROS - a pure capability operating system which allows such fine grained access control that the closest you can get to the Priniciple of Least Privilege with the most locked down system in windows is a joke when compared to it.

http://www.eros-os.org/

I know we need DNS today -- links, bookmarks, advertising, all that.

Bookmarks and links are a technology which actually eliminate the need for DNS[1]. If you could pass bookmarks and links around in a user-friendly manner, why would you need a global namespace like DNS? The links could simply be IP addresses, or preferably, a cryptographic identifier [2],[6]. Finding an entity with an introduction occurs via a e-mail, links on the web, etc. Search engines are used for finding an entity without an introduction (like the Yellow pages) [3],[4].

All the technologies to replace DNS exist today. They aren't quite as easy to use as DNS, given that software hasn't been designed to use them in this fashion, but the DNS is an unnecessary, vulnerable, centralized system, even today.

The technologies I've pointed out further solve the phishing problem, enable secure introduction, and decentralized secure computation.

[1] http://www.skyhunter.com/marcs/petnames/IntroPetNa mes.html (Petnames are a sort-of local DNS directory)
[2] http://yurl.net/ (a YURL redirectory is pretty much like DNS, except that anyone can set one up)
[3] http://www.eros-os.org/pipermail/cap-talk/2005-Feb ruary/002891.html
[4] http://www.eros-os.org/pipermail/cap-talk/2005-Feb ruary/003079.html
[5] http://petname.mozdev.org/

I know we need DNS today -- links, bookmarks, advertising, all that.

Bookmarks and links are a technology which actually eliminate the need for DNS[1]. If you could pass bookmarks and links around in a user-friendly manner, why would you need a global namespace like DNS? The links could simply be IP addresses, or preferably, a cryptographic identifier [2],[6]. Finding an entity with an introduction occurs via a e-mail, links on the web, etc. Search engines are used for finding an entity without an introduction (like the Yellow pages) [3],[4].

All the technologies to replace DNS exist today. They aren't quite as easy to use as DNS, given that software hasn't been designed to use them in this fashion, but the DNS is an unnecessary, vulnerable, centralized system, even today.

The technologies I've pointed out further solve the phishing problem, enable secure introduction, and decentralized secure computation.

[1] http://www.skyhunter.com/marcs/petnames/IntroPetNa mes.html (Petnames are a sort-of local DNS directory)
[2] http://yurl.net/ (a YURL redirectory is pretty much like DNS, except that anyone can set one up)
[3] http://www.eros-os.org/pipermail/cap-talk/2005-Feb ruary/002891.html
[4] http://www.eros-os.org/pipermail/cap-talk/2005-Feb ruary/003079.html
[5] http://petname.mozdev.org/

...unless you add a label like "Grand Theft Auto" to all of the objects comprising it, then search for "Grand Theft Auto" to see all of them. Of course, I just re-invented directories, so that seems kind of pointless. Possible, still, nonetheless.

How often are you going to write the file to the disk? Every 10 minutes? Every 1 minute? Every keystroke?

I mentioned Eros in another post. You should read its whitepapers. Basically, that OS doesn't save files - it saves state. The state of the whole OS is written to nonvolatile storage at regular intervals, and editing an object is basically same as opening a window that renders the contents of that object and allows it to be manipulated.

A more common example is PalmOS. You don't edit your addressbook file in any tangible sense. Instead, you switch to the addressbook application and edit data inside it. You never actually "save" your "file"; you just switch to another application.

There are other paradigms than "everything is a file". Some make sense. Some don't. Some were successful. Some weren't. All of them are interesting, though.

It will be interesting to see how long it will take the free software world to come up with something similar

As in "same design" or "reliable Operating System"? The later problem has been tackled already. As mentioned CoyotOS is currently considered the research OS for secure & reliable Operating Systems.

Better question: when's the last time anybody wrote an OS from scratch?

Let's see.. There's EROS and Coyotos, just to name two within the last decade.

-jcr

Check out EROS for an implementation that exists now. Granted, EROS itself is no longer being developed, it was definitely around before this OS, and EROS has spawned some new projects (look on the link for links).

I agree with that definition of microkernel, but "Salamander" apparently does not.

I'm sure he agrees with that definition, but he's disagreeing with your assertions that the kernel as a managed virtual machine of some sort would be more practical and useful. While potentially an interesting direction for research, it does not at all seem feasible with current hardware. Well, current consumer hardware; high-end architectures have more exotic features which may make it possible.

Like it or not, hardware page-level protection is the best we have, and microkernels are thus far the best way of exploiting this widely deployed architecture. Fortunately, page-level protection really is good enough for every purpose we need. In particular see CapROS and Coyotos for pure object-oriented operating systems (Actors message-passing syle with true capability security). I think you'll learn a lot from the papers written on EROS/CapROS.

Tanenbaum is unscientific: he focuses on a single variable and ignores all the others; he fails to even state his claims properly, let alone support them with data; and he fails to justify a novel approach with a detailed empirical analysis of prior work.

Even if what you say is true, there are plenty of others making very detailed analyses of microkernel architectures, and they have reached many of the same conclusions: that microkernels are feasible, useful, and practical, if done correctly. The real problem is that microkernels have a stigma attached to them, and because they are hard to properly design and implement. As such, only researchers have traditionally worked on them, and we all know researchers are not going to develop a full-featured system like Linux. Hopefully, that will change with CapROS.

See my other posts in this thread:
Performance
Examples of microkernel sytems

But such fine-grained controls are incredibly tedious

Hogwash. The grsecurity patches to the Linux kernel provide one approach to fine-grained access control that greatly eases the tedium of managing fine-grained rulesets. In short, grsecurity's approach is based on automatic learning -- let the system run in a permissive mode doing the things it's supposed to do, then generate a ruleset based on that activity. The system then runs with the generated permissions ruleset. The admin may need to tweak the ruleset for various reasons, but the tools provide a huge leg-up over any manual attempt to lock down a system that wasn't designed for it. And there's the rub... design.

With an OS that provides robust fine-grained access control, new software patterns and system tools emerge to manage the complexity. We didn't go from teletypes to OpenGL in one leap... For example, what if the only entity in the system that could even know the password database existed, much less access it, was the password service? Shadow passwords pale compared to that kind of isolation. What if the default permissions for an application effectively sandbox that app in a jail that makes Java in a chroot look like a toy? You'd then have to build additional infrastructure to allow the apps (and thus the user) do their work.

It's all quite possible, and folks are working on it now. This is the shift in mindset from allow-all by default to allow-nothing by default, and the work necessary to make that approach practical at the level of an OS. Take a look at http://www.coyotos.org/ and its predecessor http://www.eros-os.org/ for examples of current work on a OS (kernel and support infrastructure) designed for security (and performance) from base principles.

It's a daunting task, but damn well worth the effort IMO.

I guess inserting a few words that sound like your're a real genius, like "immunological system" will promote their anti-virus software, won't it? Even though it doesn't resemble it in the least.

Who are these guys kidding? They're part of the problem. They make obscene ammounts of money on a diseased platform (now there's a good biological metaphor).

If they were really up to it, they'd be working on cutting-edge stuff like capabilities. Even relatively simple measures like those taken by some UNIXes have succeeded more than that Windows PR BS. Of course, that would mean ditching Windows, and that's a real stupid choice for the money-makers/user-pimps.

Coyotos does away with Persistence, though, which is what gives the "restart where I left off" capabilities. BTW, there's a paper on the design of EROS's storage mechanism here (sorry, PDF).

Both of these OS's were designed in a deep academic environment to be able to do really interesting things, and they're fundamentally different from just building Yet Another Unix-like thing with a window system on it (ok, Plan 9 did evolve from Unix, and does have an aggressively different window system, but it's not just random me-too-ism.)

Sounds like you want this: http://www.eros-os.org/

Well, actually I think the people working on this stopped working on it and are working on something else now. But it's called a "capability system" and it's an alternate idea for how to do an operating system that has been around for a long time but never become popular.

Without attacks and threats we wouldn't bother developing a resilient software ecology. Heck, we're still not there despite mounting attacks. We would only have the illusion of privacy at best.

Security and software is an ecology, and we have to evolve appropriate measure to combat attacks. The techniques are here [1][2][3][4], we just have to deploy them.

[1] EROS
[2] CapROS (EROS development moving to the community)
[3] Coyotos (EROS successor in the research communits)
[4] E: secure, distributed programming language

This isn't a very good idea for a host of practical reasons, mostly centering around the fact it is too simplistic.

IMHO, you are reaching for a capabilities-based model, which works out at least somewhat better in practice, though it is an open question of whether it works well enough to use. (Link leads to a group trying to build an OS on the idea, and I know it hasn't been completely smooth sailing, but I am not intimately familiar with the project.)

That should give you a springboard for further investigation into the topic, if you like. (Way too big to cover in a Slashdot post, and I am only passingly familiar with it anyhow.)

Linux is somewhat ahead in this in that protected memory is part of its "DNA", unlike Windows which ultimately comes from the culture of DOS, which has no protected memory and is not multi-user.

But still, Linux is only just a little bit better. We need to move to real secure designs such as:

• Coyotos
• Jnode
• SE Linux (already incorporated in Fedora)
• EROS - has now become Coyotos, above

Lose power, and when you boot up next, you've lost at most a few seconds of work.

You might be interested in this article -- very interesting story about an operating system which did just that.

From The Checkpoint Mechanism in KeyKOS by Charles R. Landau:

Key Logic developed a prototype UNIX-compatible system implemented on top of KeyKOS. At UNIFORUM '90, we demonstrated this system by literally pulling the plug on the computer at random. Within 30 seconds of power restoration, the system had resumed processing, complete with all windows and state that had been on the display. We are aware of no other UNIX implementation with this feature today.

At the 1990 uniforum vendor exhibition, key logic, inc. found that their booth was next to the novell booth. Novell, it seems, had been bragging in their advertisements about their recovery speed. Being basically neighborly folks, the key logic team suggested the following friendly challenge to the novell exhibitionists: let's both pull the plugs, and see who is up and running first.

Now one thing Novell is not is stupid. They refused.

Somehow, the story of the challenge got around the exhibition floor, and a crowd assembled. Perhaps it was gremlins. Never eager to pass up an opportunity, the keykos staff happily spent the next hour kicking their plug out of the wall. Each time, the system would come back within 30 seconds (15 of which were spent in the bios prom, which was embarassing, but not really key logic's fault). Each time key logic did this, more of the audience would give novell a dubious look.

Eventually, the novell folks couldn't take it anymore, and gritting their teeth they carefully turned the power off on their machine, hoping that nothing would go wrong. As you might expect, the machine successfully stopped running. Very reliable.

Having successfully stopped their machine, novell crossed their fingers and turned the machine back on. 40 minutes later, they were still checking their file systems. Not a single useful program had been started.

Figuring they probably had made their point, and not wanting to cause undeserved embarassment, the keykos folks stopped pulling the plug after five or six recoveries.

In the end, the issue comes down to this.

Suppose you had perfect software and hardware (if you find some, be sure to let us know). Even so, your computer will fail four to five times a year due to random background radiation.

So when your computer fails, do you want to be told that all your files are intact and you can now resume your painstaking work (having lost your latest session), or would you rather have all of your windows, (complete with word processor, web browser, and solitaire) reappear with a few minutes lost work. Take your pick.

If I so desired, I could limit the login / password for my MySQL account to only allow row INSERTs and SELECTs, but no DELETEs or DROPs

This is a bit of a kludge, no?

Have a look at capability systems like EROS. Capabilities are like file descriptors in Unix: only processes holding the file descriptors may access the corresponding files, and there is a specific function (the open system call) to obtain file descriptors.

Now suppose that only the initial shell may open files and that all other processes receive the content of files by redirection (established by the shell). A compromised process cannot access just any file but only those files given to it.

Improving the redirection mechanism along the lines of Plan 9 or, similarly, MSH produces a very powerful and secure system.

Unix permissions _do suck, they're too simplistic and ACLs solve a lot of the problems inherent to it.

The UNIX® permissions model has had access control lists pretty much forever. Every user can belong to one or more lists of users called "groups", and each file designates a set of permissions ("Access Control") for a group ("List"). Some file systems allow for more sophisticated ACL behavior by specifying more than (access control, group) tuple.

But ACLs are broken anyway; the next wave of permissions architecture is capabilities, as seen in EROS and other research operating systems.

You should check out EROS, which is an open source OS based on KeyKOS (but updated a bit).

Take a look at: http://www.eros-os.org/ which is a modern (re)implementation of many of KeyKOS's ideas. Fantastic ideas.

Take a look at: http://www.eros-os.org/ which is a modern (re)implementation of many of KeyKOS's ideas. Fantastic ideas.

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe