Hi folks,
there’s a whole lot of misunderstanding, disinformation and nonsense in this thread. Let me see what I can clear up.
John Nilsson writes:
This sound like it would be trivial to implement through
a simple chroot jail."
It’s not. Go down the list of protection mechanisms offered by Bitfrost, and you’ll find you can recreate very few with chroot() alone.
Rixor writes:
Of course Solitaire doesn’t need access to much of anything.
However, every other non-trivial application will need some
kind of I/O to disk and/or the network to be of use. So once
such an application is compromised, an attacker can do
everything he needs to do to gain further access to the system.
Of course not. Every application is granted the ability to perform disk I/O, but applications can’t access user documents arbitrarily. Furthermore, there’s a big difference between applications needing network access, and applications needing to act as servers. There are comparatively very few of the latter, and it’s only if you exploit one of those that you can create an avenue for re-entry to the system. Bitfrost won’t let a non-server application bind and listen to a port.
Stewie writes:
Bitfrost and CAS are good security models. The problem is not
that they are too hard, it’s that they are not worth the effort.
Having the operating system enforce them would -make- them worth
the effort.
Bitfrost permissions are enforced by the OS.
Tim Binkley-Jones writes:
If developers don’t have the motivation to understand the
security model, what makes us think the average user will?
Bitfrost makes it exceedingly simple for the developer, for one thing. For another, if developers aren’t willing to invest the few minutes of effort to specify the permissions their application requires, the application simply won’t have that functionality available without the user explicitly granting it through the security center; the user will not be prompted to grant missing permissions at runtime.
AC writes:
The problem is the tools. I, being a .net programmer, can’t be
asked to figure out how to modify every single config file for
every app I want to use.
Within its own VM, an application is free to modify whichever configuration file it wants; the system will not get in the way.
Stunningly, AC then proceeds to say:
Wish list:
- Programs should be able to, in a clear way, describe
what they need.
- OS (or runtime framework, whatever) should:
a. easily identify what sorts of things the program says it
can do and will do in a nice GUI with something my mother
can understand.
b. users can allow the program to do more than originally
requested.
c. users can lock down the program to do less.
d. stop and notify the user when the program attempts to do
other than it has been allowed to.
This is almost EXACTLY what Bitfrost is doing! I’m not sure where the disconnect lies; either people aren’t reading the spec and are just commenting for the sake of commenting, or the spec isn’t sufficiently clear, and people should use one of the many avenues (my e-mail address in the spec, the public security@ mailing list at OLPC, or the OLPC wiki) to explain how to make it clearer.
Chris Nahr:
If your application allows the user to create and manage files
– not exactly a rare request – you have to grant global write
permission on the file system.
Of course you don’t. You might wish to read the spec more carefully; this is explained.
Dave Solomon writes:
If we’re shipping responsibility to decide what permissions an
app needs to function off to the user, we’re screwed.
I agree, and the entire point of Bitfrost is to not weasel off any responsibility to the user.
Matt writes:
One thing I’d REALLY like to see in Windows is the ability to
mark a file as accessible ONLY by applications signed with a
specific key.
Bitfrost lets you accomplish the same end goal via the document store protection mechanism.
Garret writes:
The last thing we need is more dialog boxes. I could rant for
hours about the evils of dialog boxes. As programmers, we’re
more apt than most to read a dialog box, but users simply
DON’T read them. A dialog box with a message is worthless.
Well said! For a second, I thought you were quoting the Bitfrost spec, since it similarly derides dialog boxes and puts a lot of work into getting rid of them completely in the security context. Read the spec.
All in all, from what I can tell, this devolved into a bitterfest about CAS, not constructive criticism of Bitfrost. If people would like to offer the latter, they have a number of ways to do so, and I’m more than willing to listen and discuss.
Cheers,
Ivan
Bitfrost lead architect.
