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.
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.
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.
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.
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.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
"...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.
Security is a habit, like good hygene. Most people realize that they need to floss and change their underwear more than once a month and stuff like that. We just need to promote good security habits, too.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
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 (processor feature supported in new versions of Windows and Linux), and Microsoft's Pallidium/NGSC and whatever name Intel is using for their trusted (DRM-friendly) hardware (chipsets and motherboards).
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
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.
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 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
And here is why: They have been working on this since 1991. At some point a project needs to "shit or get off the pot". At some point all momentum is lost and people start making jokes about it (cf. Hurd) and then the project will never recover. The way to keep momentum is to not only make promises of what the system will do in the future, but to show them some of what it can do (maybe not perfectly) today. If implementing persistence is going to slow them down from getting something out the door they should leave it out. Also, not having persistence makes it more "conventional" which is going to get more software written for it. And finally, it's not at all clear to me that having persistence magically built-in is the right thing to do. That's not clear at all. Like in Java there are various persistence systems like JDO and Hibernate but they all have to have special query languages. That's the right way to do it. Persisting an object and just having an object in memory really do have different meanings and should not be handled "transparently". I think that if the Eros/Coyotos guys had had some experience with Java and Hibernate/JDO/etc they would come to a different conclusion about this.
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.)