Slashdot Mirror

This work is extremely promising, in that it represents a well architechted, principle-driven design that can make guarantees about its security model (e.g. it provably enforces the confinement principle). Not only does EROS achieve significant security goals, but it does so while mantaining excellent performance.

Other bells and whistles of interest include transparent persistence. EROS' memory model does not include an explicit disk/filesystem layer. Instead, it uses a single-level store model, wherein the memory model is extended all the way down to disk. Periodically, a consistent system state is checkpointed down to disk. This includes not only conventional end-user data, but processes, IPC state, etc. Everything. Perhaps counter-intuitively, this is actually *more* efficient than conventional designs.

As a parting note, this kernel is still in research phases, and wasn't quite to the point where it's ready for major external application-level software authoring... but it's been making steady and impressive progress both in technology and implementation.

Check out the EROS website. Their security model was proved correct, but the implementation has yet to be proved to correspond to their design. This is perhaps due to the unfortunate decision to use C++ as opposed to more proof-amenible languages. Incidentally, neither the halting problem nor incompleteness have anything to do with the provability of security.

Jonathan Shapiro, developer of Eros is quoted towards the end of the article. I thought that was cool, since I've had my eye on Eros for a long time. I don't know if it will ever go anywhere, but it sure is cool technology.

That's all well and good, but we aren't running symbolic lisp machines. The architecture you are suggesting is what Linux and most other operating systems use, but with a differen flavour: a monolithic kernel implementing whatever services an application may need or find useful. This is a development nightmare when it reaches a certain size. The proper way to build a reliable, maintainable operating system is to have as small a trusted core as possible, then graft functionality onto it via extensions. Not kernel linked modules, but protected memory applications.

See: L4 and EROS for examples. They both componentize the operating system (which you seem to like), but communication is via message which are byte streams. In the end, the fundamental communication is still the byte stream, but using it you can build an object oriented operating system.

Only for poorly designed security models. There are security models out there that have been mathematically proven secure (EROS).

While implementations may not be 100% bug-free, a properly designed system can severely limit the damage of any single compromise. I'm sure the only reason you think it can't be done, is because of the mediocre state of "popular" operating systems.

2. This is more difficult one to implement. I think application should have some levels of access on your system and they should be disabled by default

Yes, a pure capability system is the state-of-the-art in computer security (assuming you have an intelligent way of handing out capabilities -- a problem I have not seen the solution to yet).

But, you should note that if you can run a per-system call check (which Subterfuge seems to let you), you can implement a capability system on top of UNIX! The whole point of Subterfuge is that you can insert your own algorithm for deciding if process P can perform action A. This allows you to implement ACL's, capabilities, or whatever you can think up! The speeed will be underwhelming (though much optimization is possible), but it will work, right now, with all of your existing programs.

Show me a pure capability system that does this, and I will eat my hat (and then run said system). Bonus points if it supports all the hardware Linux runs on.

ps, for a good introduction to capabilities the state of such operating systems research visit the EROS website and visit the "introductory essays" section.

... and not just dev nodes in the filesystem.

EROS claims to checkpoint the memory of the system - its running state - rather than have programs explicitly serialize state to save and so on. By doing this they can make a machine shut down and reboot in a matter of seconds into a consistent state with your programs apparently still running. This is different from hibernation - you can take the machine down at any time by pulling the plug and this will work.

Its a different axis of filesystem from the 'store more metadata' stuff in this thread, but IMHO its a more interesting way to go. EROS's storage is transactional - to the extent that what is on disk always presents a consistent picture of what was in memory; user-level transactions are dealt with in programs. Its unclear from the register article whether the Be filesystem had this level of integrity.

-Baz

It's a security nightmare. Keeping filenames and permissions synced with their contents is hard and bug-prone. For totally different approach, check out the EROS OS.

This is very true. Lately, however, I've been thinking that Microsoft and Unix/Linux/*BSD are all pretty much in the same boat. The update treadmills for both OS families have been spinning faster and faster. I need to run Windows Update half a dozen times in series to attempt to secure a fresh Windows install. The update RPMs since RedHat 7.2 came out are something like 800MB.

For a different perspective, check out the EROS OS website. This is an OS "capabilities" based security model. They claim that in an age of interconnected machines and portable code, the ACL-style security model of NT and Posix is woefully inadequate.

(If resources are like doors, then an ACL is like a security badge reader. You give your badge to your programs, and they are free to try to open any door they find with your badge. In a capability system, OTOH, resources have keyed locks, and no two locks are the same. You hand your programs only the keys they need for the resources they should use. They have no other way to open any other doors. In fact, they can't even see doors they don't have keys for.)

I'm not an expert, I don't know how much I should buy into their arguments, but it's opened my mind to the possibility that there could be better security models out there than what most people have always assumed. Security probably should be built into the system even deeper than it is done on current popular OSes.

Eros

I'm not just some "consumer". I'm a CITIZEN.

The most "revolutionary" OS out there currently, EROS, is GPL.

One of the problems with secure programming is the inertia in the computer industry; most of the operating systems in widespread use today (The *nix clones and DOS derivitives, these days) we developed in a time when security did not matter; *nix has a crude root-or-not security model and MS-DOS has no conception of security at all.

Personally, I think the solution is a model which has a real security model, such as EROS. The "audit the code so that it is perfect code without bugs" approach to security does not always work, even with OpenBSD.

- Sam

Some people use it. For instance i use mosix, which transparently migrates linux processes around.
ive also spent a truly innordinate amount of time thinking about installing amoeba, plan9 and others. the reason i havent is that mosix does alot of what i want in a cluster but i dont have to limit my set of apps to those that come with or i can manage to compile in one of those odd OSes.
But with the OSkit and the growing prevalence of platform independant languages (java, python) i can see a time not too distant when the fireball amoeba distro and the linux single system image projects are competing for the average user.
Or maybe we'll get lucky and a project to put together the best features of plan9, qnx, eros and amoeba will take off with a leader like linus.

Though I must say, the conversations on the cap-talk list have been pretty cool lately -- Eric Raymond, Alan Cox, Mark Miller, John Randolph, and I have been trying to figure out how far we can go to rescue UNIX apps in a fundamentally secure environment. Succeed or fail, the process of thinking things out is turning out to be pretty interesting.

• -shap

Plan9 is just a small step towards Eros. :)

From what I understand, EROS' key feature is not being built of "tiny reliable components" but fine-grained robust security known as the capability model. You can build a distributed system out of tiny reliable components, but it'd be nice if those components weren't burdended with bad security genes, so to speak.

For the purposes of mind expansion you could do much worse :-) than lurking on the EROS and E language mailing lists. Decentralization is another good one, though much less focused.

For the purposes of mind expansion you could do much worse :-) than lurking on the EROS and E language mailing lists. Decentralization is another good one, though much less focused.

IMHO, future operating systems will tend to something like the ErOS operating system . This OS is based on multiple tiny extremely reliable components, within a strong capability model to provide a high level of security.
It's definitely a good approach, although ErOS is still quite experimental yet.

Current status is not very advanced, but...

The main advantage of EROS is that it was designed with provability and reasoning in mind. I was fascinated about SPIN project, where you could put trusted components in the kernel space. For that, they should be written the way compiler could prove their innocency, and Modula 3 type system ensure that. If you look at EROS papers you'll see that authors look at the OS from the OS-as-programming-language point of view, which is very similar with SPIN.

Take a look at EROS, delight (erect, excite) your mind. ;)

EROS' predecessor, KeyKOS, made waves at USENIX when they did a demo of a UNIX system + Xwindows which would instantly restore the running state of all software when rebooted. It was basically a UNIX port to KeyKOS, and since everything in KeyKOS was persistant, so was everything in the UNIX.

One interesting caviat with this type of OS is that you really need to use ECC memory, because bit errors can get saved to disk and propagated forever!

1. Build it into the application. Numerical methods developers have been known to do this.
   Many people in the parallel discrete event simulation community do this, sometimes using
   compiler assisted tools.
   
2. Build it into a middleware layer --- this is the approach typically taken by many database management systems, in parallel discrete event simulation toolkits , and in distributed process migration toolkits such as Condor and BSP
   
3. Build it into the kernel --- this was done by keykos and the eros group. If the kernel has support for persistent objects and the application uses this support, process restart is well defined. I've seen limited forms of suspend and wakeup for mobile devices as well, but this requires an explicit suspend/restart rather than fast crash recovery like eros has.
   

If we really wanted to solve these problems
we probably need to make a new OS...

Enter: Eros OS.

A capability system based OS... then once we get some software, we'll be set. Yay!

Remember.. refactoring is important!

How is your solution preventing the original problem of a malicious user naming a billing filename as an output file?

As long as the compiler 'changes hats' (Setuid/gid), the privelege-checking is quite complex and will probably result in VERY complex ACL's to achieve the goal.

These stats are used for billing information, and people would thus be VERY willing to mess with them.

All these security settings require root to set up, meaning that only a system administrator is capable of setting up any system involving security checks.

Alternative approach:

The mechanism used to identify (name) objects is that of unforgable, OS-implemented keys called "capabilities". These capabilities are much like *nix file descriptors, but they are never open()'d or close()'d. Having the capability is a necessary and sufficient condition to access the named object, the object does not care who access it.
The above example, is very simply solved by capabilities:
In order to name the billing file to the compiler, the user must have a capability to that billing file. In that case, the user is fully authorized to access this file. Obviously, the user does not have a capability to this file, only the compiler does, and since there is no way to forge a capability (just like file descriptors), the user cannot name the file he must not access, and may not confuse the deputy.

Advantages:

Users (code) can only express requests by access to a capability, meaning that code is only capable of expressing authorized requests. This means that there is no ACL test failure that may give false access to this user, as the mere ability to express a request is an indication of authority to do it.

The only security test required at runtime is that the capability is valid, which is equivalent to the validity test of a file descriptor, nearing 0 time.

Capability systems are in fact simpler systems, and many security properties of such can be mathematically proven, as demonstrated by Shapiro, in his proof of part of his EROS system.

Capabilities have per-process granulity, rather than per-user granulity, and very fine-grained control of which objects every process has access to, thus the principle of least privelege is implemented.

No need for a 'super user' that bypasses ACL's, because that would destroy the principle of least privelege. Every user can create objects and spawn capabilities to use those objects, and distribute them through every channel he has a capability to.
This means any process with some minimal set of capabilities can set up a security system, not requiring any super user to bother, and killing the vast majority of threats involving a superuser.

Alan Cox wrote:

If you want to compartmentalise build a small reasonably verifyable core and run Linux unpriviledged on it - its one of the uses for real microkernels (not Mach but something thats actually -micro-).

I Am Not A Kernel Hacker (IANAKH) but..

Jonathan Shapiro's Ph.D. thesis work impressed me in this regard - a "nanokernel"-based OS that attempts to better support low-level security:

• http://www.cis.upenn.edu/~eros/
• http://www.eros-os.org

It would be nice to implement a linux-like system on top of this, or perhaps use such a system to provide virtual machines on top of the hardware (like IBM mainframes or VMWare GSX Server).

The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.

The real way of doing this is putting the hardware drivers into the kernel (frame buffer devices).
No user process is supposed to access hardware directly, and if that meant we have no graphics, it would also mean no keyboard, text, or sound.

Although these issues can all be addressed, the problem of proper kernel security is at best a "whack a mole" situation in which a new hole will arise shortly after an existing hole is patched. Thus, the HP-LX software probably isn't worth the CD it is pressed onto.

That may be true, but it is only because of the nature of UNIX kernels. Kernels built with the principle of least privelege in mind (such as EROS) are definitely worth the fix, as it is quite unlikely to present new holes (and such a design is quite unlikely to have many holes in the first place)

The Confused Deputy will stay confused, no matter how sophisiticated the ACL's are.

The only real approach to security is a pure capability system, and ofcourse the combination of pure capbility systems with safe languages.

And software security is nothing without physical security.

Besides, a firewall is not a solution, a pure capability system like EROS or Vapour is.

There is no right way to name your string hierarchy (i.e a file system).
Since there is no proper convention of attributing things such as title, content, author, etc. on the file (only type, in the extension), these are conviniently put in the file name.

The problem here is not spaces in file names, but the weakness of a string hierarchy.

File systems are dated technology (EROS Tunes...)

The EROS page has more info on how capability systems work.

Still, I'm not sure people will go for it even if it's implemented well.

This isn't a troll, I'm just trying to get a handle on why exactly the HURD exists.

1) Is it because its all GPL?

2) Is it because its a microkernel?

3) Maybe a new, improved microkernel? Not MACH.

4) Security?

5) Performance? Yea right.

6) Ease of use? Isn't that up to KDE and GNOME?

7) Translators, Namespace unification, RPC? Been there, done that.

So, exactly why does HURD exist? What does it bring to the table that hasn't been seen dozens of times before? (Besides allowing non-root users to mount partitions!)

Well, there's Plan 9, and *Step, though they're more evolutions of Unix than anything else. In theory, the HURD could be more powerful, since it combines Unix syntax and Amigaish concepts like userspace filesystem translators and so on.

EROS also promises to be a much better system than most things we have now.

Oh, and the LISP machines rocked, but cost a small fortune.

If the Amiga hadn't been murdered and had continued developing, it would probably be brilliant now.

"Serialization" means you take your object and turn it into a stream of bytes of some sort. Some more introspective languages, like Python, Smalltalk, and Java allow very easy serialization, but in something like C you spend a lot of time figuring out how to do it. Even if it is indirect, most files somehow represent an object that was in memory and can be put back into memory at a later time.

"Orthogonal" means that something is seperate from something else -- or more specifically, that while two aspects of a thing are related, you can work with one without effecting the other. Kind of -- it's a subtle (though very useful) notion.

"Orthogonal Peristence" means that all objects persist indefinitely with no effort from the programmer. "Orthogonal" refers to the fact that the persistence happens without any relation to other aspects of the program -- everything just persists by default. While it may involve serialization, this is hidden from the programmer, as is any other technique that supplies the persistance.

In such a system there wouldn't be any distinction between objects in RAM or on a disk -- often that is then expanded to objects that are also remote (similar to CORBA, but again, the network access is orthogonal and invisible). Anyway, the system moves things to disk as it needs to, and pulls them off as needed.

I brought up the cleanliness issue before, but the other issue is scaling. Particularly something like garbage collection is a bit difficult, because you can't just do a mark-and-sweep every so often, because anything on the entire disk could contain a reference.

EROS has this, Smalltalks have generally had this (you might wish to look at Squeak), and the old Lisp machines also tended to have orthogonal persistence.

As far as something new and different... I think EROS-OS might fit that category. It's certainly not like any OS I've encountered before (although I understand it does derive its design from other "secure" OS's).

it's here:
www.eros-os.org

some text to satisfy the lameness filter gods

EROS. No, it isn't an OS that displays pr0n. It stands for Extremely Reliable Operating System and is used as a test bed for new OS enhancements such as OS persistence and token security. Besides, these guys get a real kick out of showing how they can kick the plug out of the wall and have their machine back up moments after they put the plug back in.

Another OS of interest is JOS, a Java based OS. While I agree with them in principle, they defined too large of a scope initially and ended up drowning in their own specs. Maybe one day we'll see an awesome OS out of them, but not today.

You might be interested in EROS - the Extremely Reliable Operating System, which takes permissions resolution to its logical extreme: the capability system. If something only needs access to one directory and one port, that's all you give it.

Very interesting project.

Linux is interesting because the are so many groups exploring alternative security models: privileges, acls, subdomain, SELinux, etc.
This can't be a serious effort without any exploration of Pure capability systems. To me, that is the obvious security model.
Shapiro has done extensive work documenting it, and even proving related stuff (I'm not into the exact details of his proof, but he proved part of his EROS design mathematically correct). EROS is a pure capability system, and I hope that in the future, people will utilize it as the obvious security solution.

and emphasizes that security is ongoing, not defeating any single problem.

I agree this is true on *nix/Windows-like systems. But what about a system where every piece of code runs with a simple environment allowing it only the minimal privelege it needs? (EROS)
What about a system that extends this idea further, and makes sure that all code is compiled from a safe language? A system with no buffer overflows or pointer errors/overruns? (Vapour)

I believe that a system like EROS would make actual breakins/control of a distant computer practically impossible.
I believe that a system like Vapour would make ANY remote malicious operation practically impossible, if implemented right.

Note that if you break into an EROS system's web server and even if you get some of your code to run on the remote host - the worst you can do is read HTML's and distribute content on port 80 (or whatever ports the server had access to), but nothing else.
You can't really get any mailicious code to remotely run on a Vapour system at all.

True Security IS defeating a single problem - that problem is the *nix fail-open design, and the lack of principle of least privelege. (In terms of security, Windows is a very similar design, both using ACL-type security, of attaching lists of "user"-based access to objects).

You are very right. One of my favorite features is that it doesn't use a "file-system" per-say. I assure you that although I'm not active on the mailing list, I've been monitoring it since 1997.

My comment comes from Jonathan Shapiro's comment about his own OS sometime about when it was GPL'ed. In short he mentioned that hardware had a lot of catching up to do with his OS.

I believe it came in response to a thread on how to deal with the "capabilities" (I'm assuming you know how they use that term) of modems and other peripherals. I remember the quote going something like "It will take years for hardware to see a need and implement it."

As another note, if you look at the v2.0 logs you will notice a long essay on why he is finnaly implementing a malloc. Essentially becuase of, [...drumroll...] braindead hardware design.

I don't know where your comment about EROS comes from. EROS stands for Extremely Reliable Operating System, and has cool stuff like transparent persistence for all programs and a pure capability security system. EROS was built from the ground up to run on commodity Intel boxes. The OS is not ready for prime time because it is being re-written in C (from C++). It is GPL'ed, and it has mucho potential.

EROS is an operating system that doesn't boot. Instead, it just loads a memory image from disk, which can be lightning fast when it's arranged as one contiguious file to eliminate seek times.

Some people blame Microsoft for the world's computer security problems. After all, if Microsoft cared a whit about security, the virus outbreaks wouldn't be so damn nasty. Others say Microsoft isn't the problem; networks are inherently insecure (see the EROS Project for a solution in development). I'm not one to say Microsoft is totally to blame, but I would like to quote Stanley Kubrick's Full Metal Jacket on the issue:

HARTMAN:
If it wasn't for dickheads like you, there
wouldn't be any thievery in this world, would there?

1. Capabilities: A concept that is literally over a decade old in OS design as can be seen by the POSIX 1.E standard that never got drafted (although some people prefer to call what POSIX suggested "privileges" and the fact that many operating systems support "encoding clearance into the filesystem and OS" otherwise known as capailities including Spring, EROS, KeyKOS, and Mungi.
   
   
2. Access Control Lists: Again this is an ancient concept which has been implemented in quite a number of OSEs including some versions of Solaris, *BSD and Win2K.

• Inefficient kernel-user switching (i.e. system calls spend too much unecessary time in the kernel).
  
  
• Inefficient address switching (i.e. the number of cache and TLB misses in the Mach microkernel is also absurdly large).
  
  
• The performance of IPC operations and thread switching is subpar. (this is related to the above points).
  
  
• It isn't optimized for specific hardware and instead has a Hardware Abstraction Layer which slows it down considerably.

• QNX: Everyone's heard of this one. They have a very good u-kernel.
• Opearting Systems Group at Dresden: They do alot of great work with u-kernels. They have code for L3 and L4, the first very promising, high-performance u-kernels(though they may not have designed them). They even have Linux running as a service on top of L4, so you may be able to run it right now! Also see This University and the L4KA page for other implementations of L4(ie. other architectures).
• Eros: EROS is a new operating system based on the architectures of earlier high-security capability systems(KeyKOS). Very promising and has performance comparable to L4. The measurements are in the papers section(usually towards the end of the paper). System is GPL'd.
• VSTa: a cool GPL'd hobby u-kernel system(in that it has no university or company backing). This one has a somewhat complete system, ie. self-hosted with gcc, vi, emacs, etc. Runs on a windows partition and uses GRUB to boot(all of which you'll need to run it). No performance metrics that I'm aware of.
• Fluke: No working system as far as I know. The kernel is complete and some performance measurements have been made. Looks promising and source is available(GPL I think).

The preceeding link is courtesy of Google. They mirror and grep for you.

I agree with the original poster -- for all intents and purposes, Linus is a moron. Before you moderators start handing out (-1, blah) points, hear me out. Sure, he's a great programmer and has made a great contribution in the form of the Linux kernel, but it's fairly clear from listening to him that he doesn't understand any developments in systems research since about 1960, with the possible exception of copy-on-write. Don't get me wrong -- I've used Linux since 1994, and it's better than most desktop operating systems. However, Linus' absolutely hubristic rejection of (barely) modern concepts which he doesn't understand, such as

• threads ("processes are faster", sez he)
• message-passing
• version-control systems

It's time for Linus to get out of the way and let someone else serve as "CVS with taste" for the kernel -- after that, Linux has a chance of becoming a rock-solid, lean, and efficient kernel.

No, BeOS doesn't do that. It does a full boot every time.

However, EROS works just like you've described.

Problem 1:

We can always change the permissions of eth0 to allow it to be put into promiscuous mode by another user if we want.

Letting any user put the NIC into promisc mode isn't a security hazard?

Problem 2:

The statement that there are only two levels of security is completly untrue. You can have as many levels of security as you have users and groups.

This is just wrong. Read up on ACLs, Capabilities, Mandatory Access Control, Auditing.

Traditional UNIX environments have provided extremely limited expressiveness in file system permissions, limited to a single user (owner), a system administrator-defined group, and a set of rights defined for the remainder of users on the system. Access control lists allow for the fine-grained expression of discretionary rights associated with files and other system objects.

(From trustedbsd.org).

Here is a good intro to capabilities.

---
In a hundred-mile march,