Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software

Coyotos, A New Security-focused OS & Language 296

Posted by Hemos from the locking-things-down dept.
wap writes "For those who haven't been following the EROS project, it has now migrated to the Coyotos project. EROS, the Extremely Reliable Operating System, was a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root. Capabilities allow a rigorous verification of the security of a system, something which is not possible in Unix-style and MS Windows systems. Coyotos is to be a real-world usable implementation of the ideas from EROS, complete with a Linux emulator layer. It also specifies a new language, called BitC which allows the programmer to prove that the code implements certain semantics, thus providing another layer of verifiable security. Could this be the most leet OS and language of 2005?" Another submittor asks how this stacks up against using Systems Management and "standard" OSes.
This discussion has been archived. No new comments can be posted.

Coyotos, A New Security-focused OS & Language More

Coyotos, A New Security-focused OS & Language

Comments Filter:

  • Need for a superuser? (Score:4, Interesting)

    by PornMaster ( 749461 ) on Tuesday January 25, 2005 @01:42PM (#11470334) Homepage
    One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

    How is this resolved without a superuser?
    • One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

      Exhaustive password search, of course.

    • Simple.

      You rip the drive out and stick into another computer. If there is encryption, superuser won't solve it anyway.

    • That's not the right question (Score:5, Insightful)

      by Anonymous Coward on Tuesday January 25, 2005 @01:46PM (#11470398)
      Any user could encrypt data, leaving it locked forever if the key is lost. That's just the nature of electronic keys. When someone loses a physical key there is always some way to spend enough money to open the safe or whatever. That's not true in the world of encryption. The solution to that problem lies outside of the scope of the OS. Or rather, the Unix/Linux/MS Windows designers decided to put it in the scope of the OS by making certain types of protection non-existant. But that's not a solution to the problem; that's just omitting features which should be there, like giving users good encryption tools for stored files.
      • Would it be possible to design an enryption system such that if semi-trusted party X spent Y CPU-cycles brute-forcing, it could be broken, but for all other parties no?
        • Yes, that is possible, and I'll tell you how to do it. Though beware, IANACE (I am not a crypto engineer)

          Encryption systems with multiple keys can be made by encrypting the text with a secret key K, and then placing K itself at the beginning but encrypted with various keys X, Y, and Z. So if you have any of the keys X, Y, or Z, you can decrypt K and then you can decrypt the text.

          Hypothetically it would not be so hard to take our key K, encrypt it with some insecure algorithm, then encrypt *that* with s
        • If the data is encrypted with an N-bit symmetric key, you could escrow N-56 bits of the key with your trusted party and they could brute-force the remaining 56 bits in a few days.

          Alternately, you could use secret splitting to divide the escrowed data among M trusted parties such that K of them must cooperate to recover the data.
        • It would probably be simpler to encrypt person A's encryption key with trusted person B's public key and escrow it. Then, if something happens to A, B can retrieve the key from escrow and decrypt it. You could cascade this to produce a "chain-of-command"-style process, whereby the key must be sequentially decrypted by a string of people before the original is recovered.
      • The File Vault feature of Mac OS X is an example of what the Anonymous Coward said is missing from Unix/Linux/MS Windows, if I understand his comment correctly. File Vault deals with the possibility of a lost person/key by having a master password, separate from root. It's also a stronger encryption than what is used for authentication as root to the OS.

        This is like the behavior where you typo your login password after the eighth character. You get into your account because the OS, like other BSD based

    • Re:Need for a superuser? (Score:5, Interesting)

      by Coryoth ( 254751 ) on Tuesday January 25, 2005 @01:50PM (#11470450) Homepage Journal
      One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

      In SELinux, which I am more familiar with, and which also gets rid of the "superuser" account, everything is handled by context or role. That means you can isolate a process that wants "root" access to certain files by restricting its role to one that has access to only those files. Thus there is no "root" account that has access to everything. At the same time, it's possible to create a role that allows suitable access to make changes and/or recover lost data if necessary.

      I presume Coyotos, with its "capabilities" will work similarly - ie. there is no "root" account that has access to everything, but instead various capabilities that bound access to various resources.

      Jedidiah

      • Re:Need for a superuser? (Score:4, Interesting)

        by GeckoX ( 259575 ) on Tuesday January 25, 2005 @02:01PM (#11470601)
        And who has the rights to create that new user that has sufficient rights to get at all of that critical data that the guy who just died left behind?

        I see a bit of a chicken or an egg thing here.

        There will always have to be either the concept of a superuser, or there must be a way to create an account with any rights possible, otherwise it would be a very easy system to lose data to.

        So, no superuser. This means there must be some way to create an account with sufficient rights to recover lost data, which kinda undermines the security in the first place.

        Hope I'm missing something ;)
        • The point is that one can have "account creation" priviledges, or even "priviledge granting" privildedges, without having "ability to deliver signals to any process in the system" priviledges.

          In unix, "root" has all the permissions. There is no way to grant someone permission to do one extraordinary thing without giving that user permission to do a whole host of extraordinary things.
        • I'm sure there is, but unlike on a Unix system where the "super-user" account would be used to run everything under the sun from the daily cron jobs to the mail server, this account would never be used except to replace the "user-control-account" account. Its password would probably be an md5 hash of some very long string that would be memorized by all the VPs of the company so that any one of them could use it. (Or however the company deals with the root passwords now... sealed in a vault?)
        • Yes, you are, so relax. If you separate the roles of creating an account (and defining the priveledges that it has) and setting/resetting/enabling the password on an account, then it takes at least two people to gain access against the wishes of the owner of the system. Most large organizations have a standard that a single role cannot do this, and they usually have the roles working in different groups within the organization.

        • Re:Need for a superuser? (Score:3, Interesting)

          by m50d ( 797211 )
          So a determined malicious insider can do everything they can do under traditional unix, yes. But there's defense in depth here. For example, you can probably eliminate all your setuid binaries, just give them the capabilities they need. Cdrecord gets the "set own niceness very high" capability, but a cdrecord vulnerability doesn't make a local root one. Mplayer gets the "direct access to video card" capability. People who just need to be able to mount iso images don't need the root password. It's not a pana

        • Re:Need for a superuser? (Score:3, Informative)

          by viktor ( 11866 )

          I see a bit of a chicken or an egg thing here. There will always have to be either the concept of a superuser, or there must be a way to create an account with any rights possible, otherwise it would be a very easy system to lose data to.

          Somewhere on the system, individuals or people working together must somehow be able to create users with all possible privileges, that is correct. So individually or collectively they can do anything. That is not the difference.

          The difference is that just because a pr

      • It helps separate responsibility.

        I'm thinking out loud here, but let's assume there is an account or role (lets call it Auditor) that is used to create admin accounts and can recover password/encryption keys. Ideally, this account would be separate from the admin accounts used to manage the system and be the only one with access to certain audit logs/resources/encryption keys.

        This way, the Auditor account cannot manage the system or have root access to the file system, but it can recover encrypted data
    • I'd pull the stuff from backups. No critical business is without them, and if you're encrypting those I'd hope you're using DSA with multiple keying to a second administrator and an escrow key that sits in the CEO's safe for precisely this situation.
    • Jack the Ripper password cracker I suppose.
    • Believe it or not, I saw a Mac OS X box that didn't have an administrator (read: as close as you can get to superuser for OS X) account. No one knew how all of the users ended up being non-admins, but the only solution we could come up with was a reinstall of the operating system. I think having a superuser account is probably a good idea, however I think someone developing a new operating system would be wise to make a type of account that allows the user to maintenence without becoming a superuser. I r
    • Just because there is no super-user, doesn't mean that there is no way to access a person's data. Anyone with a capability to a particular resource can access that resource regardless of who they are; there is no concept of "ownership" except in that the creator of an object is the only entity holding a capability to it until he gives it to someone else.

      Suppose an administrator creates a block of space he wishes to dedicate to a particular user. The act of creation returns a capability(unforgeable referenc
    • I think the problem is that what you see as "superuser", capability-based systems see as "user with all capabilities".

      In this case, theres a capability that says "create or modify accounts" and some user(s) will be given that capability, and those users will be responsible for creating or resetting passwords on accounts, and hopefully they won't all take the same airplane together, or at least that they have a password to an account saved in some vault somewhere.

    • One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

      How is this resolved without a superuser?

      The "missing password" problem is orthogonal to having root vs not having one. After all, unix admins die too, although one might find it hard to believe.

      There are interesting cryptographic methods that solve this problem in a tricky way. An algorithm

  • Comparison with Multics? (Score:5, Insightful)

    by CodeArt ( 540731 ) on Tuesday January 25, 2005 @01:43PM (#11470345)
    How Coyotos compares with Multics? Multics was most secured OS ever created with his multi-ring security architecture and security supported directly in HW.
    • http://csrc.nist.gov/publications/history/karg74. p df

      Firstly, there's that. Secondly, it _was_ the most secure OS ever created, because it was one of the first to be designed with multiple users/networked use in mind. However, keep in mind that it was built with 1960s computer science, 1960s ciphertech, without the lessons learned over the next 40 some odd years, for use on machines with _very_ limited computing power. In other words, it doesn't hold a candle to modern secure operating systems, except for

    • Re:Comparison with Multics? (Score:5, Interesting)

      by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Tuesday January 25, 2005 @02:32PM (#11471009) Journal
      Dunno about this Coyotos thing, but a major point of EROS was its checkpointing system & memory architecture. In my completely uninformed understanding, the idea was that there was no filesystem, and the persistent disk was only used to provide virtual memory and checkpoint the memory state.

      So if you turn off the computer, and turn it back on again, it loads the last checkpoint, and your processes are all running and in the same state. That's what they mean by "Extremely reliable". There are supposedly processes running in KeyKOS, a similar OS, that have been running since before the computer's current hardware had been built. If that makes sense.

      Dunno if Multics did that.
      • Ah, but I am full of crap:
        Coyotos picks up where EROS left off. From an application builder's perspective, the major change is that Coyotos removes persistence from the architecture. This leads to many simplifications in the implementation, and it has a bunch of consequences for the system utilities, but an application designer probably doesn't care that much -- if anything, it makes the system ``feel'' much more conventional.
        So nevermind about that persistence crap.
    • Multics was also a huge commercial failure, because security tends to get in the way of people using computers to get real work done.

      I'm not suggesting that all security is worthless, and some systems need to be really, really secure, I'm just noting that there's a lot of people (developers and sys/network admins) who are enamored with the theoretical underpinnings of security to the point where they implement security measures that do more harm (in terms of reducing or eliminating productivity) than good.

  • Looks exciting (Score:2, Insightful)

    by RatRagout ( 756522 )
    Maybe we will finally get an operating system with a thorough security model....hopefully not so thorough that it can't be used...

  • BitC looks nasty (Score:3, Insightful)

    by Panaflex ( 13191 ) <{moc.oohay} {ta} {ognidlaivivnoc}> on Tuesday January 25, 2005 @01:44PM (#11470371)
    ((At least (to me).))

    (pan)

  • Capabilities (Score:5, Interesting)

    by Tet ( 2721 ) <slashdot AT astradyne DOT co DOT uk> on Tuesday January 25, 2005 @01:49PM (#11470442) Homepage Journal
    a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root.

    This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS? But mechanism alone won't solve your problems. You need to have suitable policies that make use of those mechanisms. And as the Fedora guys have found out with their SELinux adventures, getting the policies right for any non-trivial system is a bitch.

    • Re:Capabilities (Score:3, Insightful)

      by Greyfox ( 87712 )
      Yah. Your average home user will likely end up setting up an account with all capabilities turned on, thus putting you right back at square one with a "root" user. Every once in a while we see some bozo who wants to ignore 30 years of sysadmin experience and give his regular account root permissions. They usually say exactly the same thing too, "Oh, it's OK, I know what I'm doing," and "I'm not running anything important on my system, so no one will bother attacking it." You know who you are heh heh heh.

      S

      • For an OS to be a hit, it needs to be marketable. Windows has games, gui, buggy or not... it squeeze in noticible new features. Linux wasn't marketable until KDE and new features came in. Security is just a boring selling point.

      • Re:Capabilities (Score:3, Insightful)

        by plcurechax ( 247883 )
        Your average home user will likely end up setting up an account with all capabilities turned on,

        This is a research OS being worked on at an university (John Hopkins) by several graduate students. It is not intended to being part of Fedora Core 4.

        Just like Trusted Computing platforms like Trusted Solaris and Trusted HP/UX (I forget the name for the Trusted version of VMS, and several others) this is not intended for mainstream replacement of "mainstream" OSes. For that look at PaX, exec-shield, NX support
      • ... Every once in a while we see some bozo who wants to ignore 30 years of sysadmin experience and give his regular account root permissions. ...

        I pray for the day that every computer user neither needs to be a sysasmin with 30 years of experience nor needs the perpetual support of sysadmins (IT departments, sysadmin friends, etc).

        Just because it's the status quo doesn't mean it's the way it should be.

    • EROS has other advanced features aside from capability based security:

      What is Persistence?

      Different systems use the word ``persistence'' to mean very different things.

      In EROS, persistence means that the system periodically saves a copy of everything you are doing. If your dog trips and knocks the plug out of the wall (don't laugh - my dog actually did this to me), EROS will restart wherever it last saved your work, complete with windows, applications, and everything you typed.

      Typical configurations of ER

    • This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS?

      You wouldn't need a separate OS... if it weren't for the fact that Posix/Linux "capabilities" are not real capabilities. Furthermore, EROS/Coyotos has much finer-grained access control, ie. a capability to a memory page, or a disk sector, rather than "capabilities" only to coarse-grained objects such as terminals as in Posix.

  • Coyotos (Score:4, Funny)

    by Deathlizard ( 115856 ) on Tuesday January 25, 2005 @01:51PM (#11470467) Homepage Journal
    Hmm. does it work with Roadrunner? :)

    • Re:Coyotos (Score:3, Funny)

      by B3ryllium ( 571199 )
      In order to get it to work with Roadrunner, you need to buy some Acme-brand ADSL rocket shoes.

      Guaranteed to singe hair off of nether regions.

  • so... (Score:5, Funny)

    by mogrify ( 828588 ) on Tuesday January 25, 2005 @01:54PM (#11470517) Homepage
    #include <BitC.h>
  • Does anyone have any idea what license it uses? I hunted around their site but couldn't find any info. The fact that they plan to release the source and releases suggests some sort of OSS license though.

  • forgotten lessons of Ada 83 or too young to know? (Score:4, Insightful)

    by museumpeace ( 735109 ) on Tuesday January 25, 2005 @02:01PM (#11470604) Journal
    "...It also specifies a new language, called BitC which allows the programmer to prove that the code implements certain semantics, thus providing another layer of verifiable security...."
    Developers, promoters and users of this language should consider the fate of Ada83 language before they invest a ton of effort or money. Yes, it may be strong as Fort Knox but writing software costs money and the language supports provability but does NOT eliminate the need to do up front design and heavy integration testing at the end of a project...Only the proprietors of Fort Knox would consider the cost benefit ratio of such software worthwhile. The rest of us would have to weigh it more carefully. C-derived languages got a lot of code written quickly mostly because they did not encumber the engineer with many considerations beyond the function or behavior and representation of data...the "I'm not going to give you a chance to screw up" approach to programming embodied in Ada does not map well to typical [if somewhat shoddy] coding practices and creates a much steeper learning curve for would-be programmers. I admit I have yet to RTFA but I already have this "here we go again" feeling.
    • Since Jonathan S. Shapiro is a professor at John Hopkins University, and has been involved in EROS since 1991, I suspect he has had the chance to met Ada 83.

    • To elaborate a bit on what happened to Ada 83:
      That version supported provability of correctness, a feature that was easy to sell to a security conscious customer [not customers as there was really only one]. But that provability meant that many dynamic coding practices, in particular the method dispatching needed for object oriented programming, were not tolerable: for a compiler to prove code was right, it had to be immutable and look at run time exactly as it did at compile time. This restriction proved
      • That version supported provability of correctness,

        There's only steps of provability. Ada 83 was more provable than most languages, but there's a lot more to it. And its failure in many cases seems to have been high-price, low-quality compilers designed for sale only to the DoD, which fought Ada internally in a lot of places.

        he next version, Ada 95, added features in a vain attempt to achieve OOness

        In a vain attempt? Do you care to explain why Ada 95 is not an OO language?

        explicitly abandonded provab
    • Go ahead and RTFA. I'm only marginally familiar with Ada83. However, I'm a fan of functional programming languages. I can't tell you how many times I've wished for type inference and pattern matching.

      The problem is that, like Haskell, I will probably never work for a company who adopts BitC.
      • its a lot to read..skimming

        ....skimming

        ....yumm, nice parens! tastes a bit like Lisp...hurray for econmomical parsing.
        ....skimming...
        monomorphic variables ? what happens to procedure with two variables not bound as to type? infer all you want but how to mix/promote types?
        ....no module idea, charset limited to 7bit unicode: thats gotta get fixed.

        (fixint size align signed)

        OMG! Shades of Ada "MOD" types in wolves clothing!..breaks all attempts at straightforward mapping to C/C++/Java short of intro

    • Only the proprietors of Fort Knox would consider the cost benefit ratio of such software worthwhile.

      I think this is a great analogy for Coyotos. Developing and verifying the kernel will cost tens of millions of dollars, but once it's done it can be used by a lot of people for a long time without much change.
    • Developers, promoters and users of this language should consider the fate of Ada83 language before they invest a ton of effort or money.

      Yes -- Ada83 died on the vine not because it couldn't get programmers, but because it couldn't get reasonable compilers. The hurdles were just far too high.

      Now there is a reliable, cheap, well supported Ada compiler, and in spite of the lack of programmers many projects are able to use Ada appropriately.

      BTW, Ada didn't support provability; it encouraged software enginee
    • the "I'm not going to give you a chance to screw up" approach to programming embodied in Ada does not map well to typical [if somewhat shoddy] coding practices and creates a much steeper learning curve for would-be programmers.

      And for that we all pay on a daily basis as boxes get rooted and used as zombies and spam servers. It is so easy to stop buffer overflows, at such a little cost, that it's a crying shame C is still being written for anything that connects to the network. (C++ might be better, if peo
  • I'm sure it'll be super-secure since there will be no buggy software for it (actually no software). There won't be an worms or virus either!
    Just one problem - it can't do anything useful either.

  • rigorous = unpopular (Score:3, Funny)

    by PMuse ( 320639 ) on Tuesday January 25, 2005 @02:14PM (#11470773)
    It sounds wonderful, doesn't it?

    Come, raise a toast to all those restrictive languages that are so wildly popular with programmers today. Let us all thank Wirth that none of their free-wheeling, permissive contemporaries are still in use.
    • Restrictive languages are far older than I am. And since they've been around all my life, I can handle them. I know C, I'm pretty good at it - after all, you have to be - but although there's a few very cool things you can do with it for fun, I'd honestly prefer something with bounds-checking for real coding. Not that I make mistakes, of course, and I even wrote one program that depended rather heavily on accessing just outside an array. But it's simply easier to write a good program if your language can st

  • I tried BitC once... (Score:3, Funny)

    by goldspider ( 445116 ) on Tuesday January 25, 2005 @02:16PM (#11470800) Homepage
    But it was a real BitCh to learn.

  • Liyotux (Score:3, Insightful)

    by Doc Ruby ( 173196 ) on Tuesday January 25, 2005 @02:17PM (#11470820) Homepage Journal
    I think those problems can be solved better by relying only on memory-access objects with bounds checking, and signature/ACLs for every method call, and a stripped microkernel that's privileged only for HW and IPC access. Linux itself could be refactored along these lines, applying lessons learned by experimenting with Coyotos.
  • Doesn't matter too much what extra security layers are in your OS if your users are just haphazardly clickety-clicketying everything in front of their noses.

  • Hmmm... (Score:4, Interesting)

    by noblesse oblige ( 840634 ) on Tuesday January 25, 2005 @02:19PM (#11470843)
    While that was nice, my favorite feature of EROS (besides the name) was the idea that instead of a filesystem a disk was simply non-volitile memory cache. That facilitated my next favorite idea, orthogonal persistance, the somewhat like a persistant software suspend. I'd be interested in finding out (while the home page does not say) if these were the shortcomings of EROS it was alluding to.

  • Coyotos? (Score:2, Funny)

    by ee96090 ( 56165 )
    Am I the only one who read it as Coitus?

  • Naming (Score:3, Funny)

    by kallisti ( 20737 ) <rmidthun@yahoo.com> on Tuesday January 25, 2005 @02:30PM (#11470984) Homepage
    So, instead of using the name of a God of Love, they changed to the name of a prostitute's rights [bayswan.org] organization. Do they ever want to be found in a search?
    • Ummm, a coyote is a canine (hence the logo of the linked group). Who the hell do you expect to find your random reference?
  • Which one will it be the first to procure the secured operating system?

    IEEE BOSS [bosswg.org]

    or

    Coyote OS [coyotos.org]

    My money is on Coyote.

  • SELinux, capabilities (Score:3, Informative)

    by ceswiedler ( 165311 ) * <chris@swiedler.org> on Tuesday January 25, 2005 @02:57PM (#11471313)
    And this will suffer from the same problem: capabilities and ACLs are very difficult to get right, and require extremely good tools as well as informed administrators.

    For quite a while (as the OP points out) the Linux kernel hasn't checked for "uid=0". Instead it checks for one of many capabilities, like CAP_SET_SYSTEM_TIME or whatever. You can give these fine-grained capabilities to other users. SELinux does something similar for applications, letting you restrict in extremely fine-grained detail what a process can do.

    The key word is fine grained. It's pretty difficult to build a sand castle if you have to move individual grains. If you can manage it, it's one hell of a sand castle, but you need tools, patterns, and layers to do it.

    Implementing capabilties, roles, contexts, etc. doesn't solve anything by itself, any more than a compiler solves problems by itself. It gives us the ability to solve the problem, but we're still left with the hard work.

    The most interesting work going on in this area IMO is (believe it or not) Fedora. They're trying really hard to integrate SELinux into a usable operating system. It's much harder than it looks; at the moment they only have certain services running under SELinux restrictions, but eventually they'll get to a complete model where it really will be difficult to comprimise the system.

    It's not hard to secure a system; just turn it off. It's very hard to secure a system so that it allows "approved" actions and disallows everything else.
    • VMS/OpenVMS admins have been doing that for a long, long time...
    • The things the Linux kernel calls "capabilities" aren't the type of capabilities that EROS and Coyotos talks about. Making them finer-grained, as you say, would only increase the security problem and slow the system down. Read up on "object capabilities" to see what is meant, and why they can make system administration much easier and safer.

      -Billy

  • Color Me Paranoid (Score:3, Insightful)

    by ewhac ( 5844 ) on Tuesday January 25, 2005 @03:07PM (#11471437) Homepage Journal

    While I can see a role for EROS and other capability-based systems in places where security is not just important, it's the product (banks, the military, intelligence agencies), I become deeply suspicious when someone suggests placing such systems in the consumer marketplace (desktop computers, media servers, etc.).

    The reason I become suspicious is because capability-based systems are designed to distrust the person using them, including the machine's owner. Again, in environments where security is paramount, this is a reasonable thing to do -- you don't want personal or sensitive information getting in the hands of an unauthorized person, even if they own the machine it's stored on. But in all other environments, the machine should treat the owner as God and obey all commands and yield up any and all data He/She demands.

    I fear that capability-based systems will be one of the prongs media companies will use to attack Fair Use and other rights. I worry that "content providers" will demand PCs that distrust their owners and obey their commands, not mine. Capability-based systems are an excellent way to bring this about. Yes, I know capability-based systems can be hacked into obeisance, but it's a lot more trouble. Frankly, I would prefer it didn't happen at all.

    Schwab

  • I love what EROS did and have very high hopes for this project, but why the new language? Some Java people (maybe that's why...) already inspired by EROS created (or just 'E'), a capability secure Java based laguage.

    Either way, things I like:
    *Provable security
    *Extremely fine grain, almost fractally self-similar, security
    *No need for 'root'

    Things I'm not so sure about:
    *No filesystem (at least with EROS)
    *Not having 'root' is such a change, it's hard for me to understand how someone would take car
  • The purpose behind the EROS or Coyotos kernels is to provide a *fast* capability-based system. You can build a capability system on top of Linux using sockets and other mechanisms; it'll just be slower. It's easier to build in some ways, but the total complexity (including Linux's complexity) is higher, so you have a bit less confidence about how secure the whole thing is.

    An example of this is Plash http://freshmeat.net/projects/plash/ [freshmeat.net]. Plash runs processes under Linux with access to nothing by default

  • Persistence (Score:3, Informative)

    by mknewman ( 557587 ) * on Tuesday January 25, 2005 @03:27PM (#11471770)
    It appears that Persistence was removed from Coyotos. Not sure why, as it appeared to be one of the key features in EROS that differentiated it from 'conventional' OS's. Now what I'm reading is you are simply building a capability based kernel and will run Linux on top. Yeach. Marc
    • No, that was an improvement.

      First, if you put "persistence" in the OS, the OS has to know about disks, which, otherwise, a microkernel does not.

      More significantly, "persistence" means keeping your mistakes around. Memory leaks are forever. Software upgrades are very tough.

      OS design needs to go in the other direction, that of efficient transaction processing, where execution environments are created, used, and quickly flushed. That's better from a security and reliability standpoint.

  • They have one for each state, like this:

    http://www.eros-minn.com/eros.htm [eros-minn.com]

    They even have escorts for you if you need help installing.

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close