Slashdot Mirror
Coyotos, A New Security-focused OS & Language
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.
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?
500GB of disk, 5TB of transfer, $5.95/mo
How Coyotos compares with Multics? Multics was most secured OS ever created with his multi-ring security architecture and security supported directly in HW.
Maybe we will finally get an operating system with a thorough security model....hopefully not so thorough that it can't be used...
((At least (to me).))
(pan)
I said no... but I missed and it came out yes.
Unless it's implemented on a RISCy processor
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.
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Hmm. does it work with Roadrunner? :)
In Soviet Russia, Trojan exploits YOU!
Imagine what happens when Microsoft tries to compete by making a buggier implementation of BitC. It'll give us yet another reason to BitC# at Microsoft.
#include <BitC.h>
perl -e 'foreach(values %SIG){$_="IGNORE";}while(){}'
That's like saying "cars are safe enough, it's the drivers that are the problem." Actually, there are a whole bunch of things that have been done to make cars safer: seatbelts, better brake lights, ABS brakes, etc. Saying "it's the users' fault" is just an excuse for doing nothing, when there are plenty of things that could be done. I'm tired of hearing it.
"...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.
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
EROS was distributed under GPL (eventually). One can hope that it will be the same here.
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.
"We reject as false the choice between our safety and our ideals." --The American President (20.1.2009)
But it was a real BitCh to learn.
"Ask not what your country can do for you." --John F. Kennedy
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.
--
make install -not war
This is a horribly, horribly naive thing to say.
The unix model of security is extremely simplistic -- though it could be argued that this is preferable to a more comprehensive system that happens to have gaping holes made in it, ie Windows. I suppose you could argue that the unix model is effective considering it's extreme simplicity -- but it remains a system not designed with security as a primary goal, and not granular enough for security to be easily retrofitted.
You would be well advised to at least learn about Windows, not because it is particularly secure, but because it's easy and lots of security concepts from outside the Unix world are found in it, such as ACLs and fine-grained (only compared to Unix) privileges.
Of course, Windows then goes and does exactly what Unix does, and gives all the privileges to one user and requires that user's token to be used all over the place. But to be honest, usability is what propagates a system, not security.
Whence? Hence. Whither? Thither.
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.
Some will always be above others. Destroy the equality today, and it will appear again tomorrow. --Ralph Waldo Emerson
If you browse the Eros archives, you can see that Mr. Shapiro (the creator of Eros) makes frequent references to Multics as the inspiration for Eros (and therefore Coyotos). I'm not able to answer that question myself but clearly there is a close connection between Coyotos and Multics.
Am I the only one who read it as Coitus?
Gustavo J.A.M. Carneiro
So, instead of using the name of a God of Love, they changed to the name of a prostitute's rights organization. Do they ever want to be found in a search?
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.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
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.
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
Editor, A1-AAA AmeriCaptions
He's a very smart guy and a gifted programmer, but he has restricted himself to a niche, implementing UNIX compatible operating systems on Intel architecture computers.
Mea navis aericumbens anguillis abundat
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/. Plash runs processes under Linux with access to nothing by default (by putting them in a chroot() jail, etc.), except that it can make requests to objects via a socket using an object-capability protocol. Plash also provides a modified GNU libc so that normal Linux executables make their filesystem requests as object invocations, basically virtualising the filesystem.
Plash shows how unmodified Unix programs would work under EROS/Coyotos: it provides a shell (similar to Bash) that lets you run Linux programs with access to a limited set of files, in a convenient way.
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
More info at http://erights.org.
The ACL model (based on the notion of principal) is limited because it doesn't scale (your access matrix grows fast as you need finer level access control) and still allows compromised applications to use their permissions for the wrong purpose (confused deputy problem).
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 provability
Not really. Again, there are steps of provability, and Ada is still easier to prove correct than C. It's also possible to produce an Ada subset (SPARK) that is strongly provable; the company that did that has looked at a C++ subset on the request of customers and dismissed it as impossible.
what got proved was that Ada proved to be a language even its mother didn't love.
There's a lot of people out there that love Ada. Personally I got tired of beating my head against C++. (No, this is not an excuse for a flamewar; it's a personal choice.)
[I mean the BNF has 277 production rules...it is seriously ugly to map to other languages.]
C++ is a complete pain to map to other languages, and nobody seems to care. I don't know where you came up with that number, but I strongly suspect that C++ would be more. In any case, if everyone liked simple syntax, we'd all be using Lisp; most grammar complexities are added on the excuse of making things easier for the programmer at the cost of making it harder for the compiler.
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 people would give up their arrays and use bounds checked classes instead.)