programming and human factors
by Jeff Atwood
The One Laptop Per Child operating system features a new security model-- Bitfrost. It's an interesting departure from the traditional UNIX and LINUX security model.
The 1971 version of UNIX supported the following security permissions on user files:
- non-owner can change file (write)
- non-owner can read file
- owner can change file (write)
- owner can read file
- file can be executed
- file is set-uid
These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What's deeply troubling -- almost unbelievable -- about these permissions is that they've remained virtually the only real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.
In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?
BitFrost intends to address this problem by adding a new level of permissions that applies to code, not users: code access security.
Consider the Solitaire game shipped with most versions of Microsoft Windows. This program needs:
- no network access whatsoever
- no ability to read the user's documents
- no ability to utilize the built-in camera or microphone
- no ability to look at, or modify, other programs
Yet if somehow compromised by an attacker, Solitaire is free to do whatever the attacker wishes, including:
- read, corrupt or delete the user's documents, spreadsheets, music, photos and any other files
- eavesdrop on the user via the camera or microphone
- replace the user's wallpaper
- access the user's website passwords
- infect other programs on the hard drive with a virus
- download files to the user's machine
- receive or send e-mail on behalf of the user
- play loud or embarassing sounds on the speakers
The critical observation here is not that Solitaire should never have the ability to do any of the above (which it clearly shouldn't), but that its creators know it should never do any of the above. If the system implemented a facility for Solitaire to indicate this at installation time, Solitaire could irreversibly shed various privileges the moment it's installed. This severely limits or destroys its usefulness to an attacker were it taken over.
If I sound skeptical, that's because BitFrost sounds suspiciously similar to .NET framework code access security, as outlined in the System.Security.Permissions namespace. It's an enormous, complex list of explicit permissions you can grant or deny in your application's install manifest, exactly as described in the Solitaire example above. It sounds great in theory: establish a limited set of permissions your application needs up front, and let the .NET runtime worry about enforcing those permissions while your application is running.
But in practice, very few .NET developers make use of code access security. It appears Microsoft noticed that, too:
It seems Microsoft does not understand why nobody uses Code Access Security. In fact, Microsoft has a survey on the Internet. You can go ahead and answer the survey but if you have followed this entry, you should know what I am getting at: Code Access Security is too hard. Don't get me wrong, I think Code Access Security is great. In particular, the stack walk mechanism is terrific. But the policy side is way too hard for most people.
The CAS model was so profoundly unsuccessful in .NET 1.0 and 1.1 that ClickOnce in .NET 2.0 effectively does away with CAS. You're now exactly one click away from running a full trust application that can do whatever it wants to on your machine, with no restrictions of any kind.
Perhaps the OLPC's BitFrost model will fare better than .NET Code Access Security did. But somehow I doubt it. What good is a security model that's so cumbersome to use, nobody ever adopts it?
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.
Most applications can be easily classified in different categories, such as "no network or file I/O", "no network IO, only file I/O to files in its own resource directory" , "network IO on port N only, no file I/O" and so on. A minimal amount of effort by the developers could go a very long way towards increasing security.
The reason developers don't make the effort is because they feel they don't have to, and indeed, they don't. Users are so used to giving programs full access to everything. OLPC has a chance to make its users expect otherwise.
Stewie on March 22, 2007 2:06 AMBravo, Dave!
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.
That's the point. A dialog box isn't going to make the computer safer. It's going to irritate a user and then they'll click on 'yes' please download the porn-spyware-trojan-horse.
Garret on March 22, 2007 2:11 AMCAS can be a bit confusing. When should you add a security demand attribute to your code or what exactly should be put into your assembly info file? How do you explain to your users when they need a custom CAS policy for your application?
Confusing, but not beyond comprehension; at least not for most developers, if they took the time to understand the security framework. But, as stated by Stewie, they don't make the effort because the feel they don't have to. Most users will install the application, and grant the thing full trust, even if it comes with an untrusted certificate.
If developers don't have the motivation to understand the security model, what makes us think the average user will?
Tim Binkley-Jones on March 22, 2007 2:26 AMGarret: Right on. I call Dialog Boxes the Frenemy of the programmer, the lazy man's way of informing the user of trivial information. There are times when a dialog box is of absolute necessity, and I think under those circumstances, the box should pop itself up devoid of dismissal for at least three full seconds, if not as much as ten, so they don't accidentally keyboard it shut or click it shut incidentally.
Message (dialog) boxes are relied on by programmers far too much to deliver information that is either meaningless, trivial or important. With the abuse of the message box, the user never knows when applications truly need their attention, or are just trying to call something to the fore. I especially blame mal-war, spy-ware, annoyingly bad programming habits and idiot web programmers that thing the JavaScript MessageBox function is for everything.
I'll stop ranting, now. But I stick by my message: message boxes are the frenemy of programmers. Useful tool and baneful crutch.
Jae on March 22, 2007 2:38 AMIt seems to me the OLPC project is being misused by someone eager to test out his or her theories on software design. What use is an OLPC laptop if it locks kids into a proprietary software stack knowledge of which will not serve them at all in the rest of the world. Is this the political intention? as in; give 'em laptops but better not make 'em too smart or they'll take our jobs!
Tijs on March 22, 2007 3:10 AMSandboxes. [sarc]Didn't java solve this problem ages ago. Oh then .net solved it. Funny that it's still an issue.[/sarc]
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. It's all so awkward, so my sandbox is a VM instead. If I can't be asked, how is my mother going to know what to do?
Wish list.
1. Programs should be able to, in a clear way, describe what they need.
2. 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. a nice wizard would be good as well that explains that allowing certain things could be harmful.
I also want to say things like
- 'allow this program to communicate once per day to (their website) and limit to no more than 1k upload and 10k download' (I'd also like stats and counters saved by the framework that let me see the activity of said program)
- 'allow this program to access files in their installation folder as well as files of type .log in the folder c:\gpslogs'
'We're sorry, but program "notavirus.exe" is attempting to perform an action that is prohibited in it's manifest. It is attempting to communicate via an http port to "www.downloadtrojans.com" would you like it to continue?
- Yes / No / Just once.
(click here for more detailed information)'
Windows and other OS's are so far from this it's not even funny. So instead I use a VM for testing / isolating programs, try to be careful and reinstall everything yearly.
AC on March 22, 2007 4:04 AMAgree with AC. CAS isn't just extremely poorly explained by the MSDN Library and the standard .NET literature, it's also virtually unsupported by the OS and .NET loader. If your application has a CAS violation the user doesn't get any information to this extent, let alone a chance to change permissions -- instead he gets an incomprehensible error dialog as if the application had crashed!
On top of that, .NET Framework methods might request any sort of wacky unpredictable security permissions which of course aren't documented anywhere. Hit one of them while running under less than full trust, and you get the incomprehensible crash dialog again. With a binary stack trace because that's so helpful to the user!
Also, while the permissions are numerous enough to be confusing, they aren't granular enough to be useful. 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.
Sure, you could restrict permission to "My Documents". But then all users who wish to create a file in their own custom document folder would not be able to do that, and thus hate your application. You CANNOT restrict file manipulation to specific file types, which in Windows are only identified by an easily changed extension anyway.
Bottom line: CAS is a feature that would work well only with comprehensive OS support which Windows does not provide. As it stands it's fairly useless.
Chris Nahr on March 22, 2007 4:25 AMIn the Linux ecosystem, where distribution is largely separated from development, this sort of system could be made to work.
Laurence Hygate on March 22, 2007 4:28 AMYes, the UNIX security model is archaic. Yet, people understand how to program to it, and that's more than you can say for it's competitors. Attempts to bolt on a "better" security model have floundered -- even though both Linux and Solaris have ACL support, I've yet to see a shop that actually uses it. SELinux, as pushed by Red Hat Linux, is the closest to being successful -- it works pretty well if you just use the software RH gives you, but woe to you if you need to make changes to the security model.
This goes for Windows too. In theory, Windows (even before Vista) had a rich security model that could do more than the UNIX model. In practice, few people could figure out how to use it, so the usual answer to file permission problems is to give "full control" of a directory to everybody. The kind of privilege splitting that's routine on UNIX (create a special user for each daemon) is unusual in the Windows world.
Not to rag on Windows, but it shows that security models have a complex ecology, and it can be hard to make something that really works in the real world.
Sailor Moon on March 22, 2007 5:51 AMHazar: The author probably wrote it on March 20 and didn't publish it until March 22.
Billkamm on March 22, 2007 6:53 AMI'll tell you why I never used it, although I have spent, I believe, over ten hours total researching CAS--The fucken documentation SUCKS. Plus, there are extremely few books and other resources on CAS. It took me the longest time just to understand what the hell was going on. Am I asking for permission, or am I just declaring what I want to do. With CAS being so confusing and with the lack of good documentation, using CAS is like jumping off a roof. It doesn't seem like it should be hard from the ground, but when you get up there...
Captcha: orange. Always orange. Never peach.
Will Sullivan on March 22, 2007 6:55 AMHere's my parallel: Why did Canada manage to make everyone move to one and two dollar coins when the US failed to do the same thing?
The answer: because in Canada, we didn't get a choice. They just took the one and two dollar bills out of circulation and shredded them all. In the US no one HAD to switch, so they didn't.
Why haven't MS developers adopted the CAS security model? Because they don't have to. And until they're forced to, they won't.
OLPC has the advantage of forcing people into a more complex model that, while it's complex, will succeed because unlike CAS, it's MANDATORY.
Ethan on March 22, 2007 6:58 AMEthan: "OLPC has the advantage of forcing people into a more complex model that, while it's complex, will succeed because unlike CAS, it's MANDATORY."
It's mandatory on an experimental, obscure system. Being mandatory on that might just force people AWAY from that system instead of forcing them to use the policy.
David A. Lessnau on March 22, 2007 7:12 AMI believe the security should come at the OS level and not at the application level. The application developer should not have to do anything in regards to security. Let me repeat that... the application developer should not have to do anything in regards to security. When an application is installed it should be installed by the OS with a default set of permissions (perhaps defined in the installer for the application) that are displayed on install to the system administrator who can then check or uncheck permissions. If while running the program the application makes a request outside of the program's permissible actions, the OS should prompt the user explaining what the application is trying to do and then allowing the user to enter in the Administrator password and choose to allow the application to perform the requested action once, or every time thereafter (it should also allow the admin to view all permissions and make changes immediately as needed). There are firewalls that do this to some extent for network access, I can't imagine it would be impossible to do for file access as well.
Microsoft always has a tendency to over complicate matters for developers. I give you Passport as a good example... good idea, poor implementation as OpenId is proving.
Phil on March 22, 2007 7:34 AMWell, the first mistake is making it "allow everything except..."
Security works best if you start from "deny everything except...". Would be shorter for the developers as well (you only have to specify what you want your program to do, not everything that you don't want it to do).
(For the Solitaire example - no one is going to add all the code to say
"no, it can't go on the network. No, it can't use the microphone. No, it can't delete your files. No, it can't delete anyone else's files." And so on.. But if you just have to say "yes, I use the mouse, I use the keyboard, I use the monitor, and I use the sound-out, done."?
What works is making things secure out of the box.
It boils down to who secures it. If the application developer is solely responsible for securing it, then Mr. B. Cracker will simply apply the appropriate security to his application to read your bank statements. Ultimately the system administrator has to approve the security settings that the application needs. The best way for this to occur is for the OS to intercept requests and compare the ACLs for the application, if it doesn't have enough permissions then the user/administrator needs to be prompted to grant the permissions... of course there also needs to be an option to say "never prompt me" for a given situation (i.e. don't grant network access and don't prompt me ever again about the application not having network access). Hopefully most of the needed permissions will be granted upon installation.
Phil on March 22, 2007 9:03 AMTotally agree with you Phil. The only thing CAS should be doing, from a development perspective, is preventing code from blowing up because a permission hasn't been set.
I see it really to do things like putting a little orange triangle next to a command (ie menu item) - if you click it, it would tell you that because of administrator-set policies, the following will not function or may prompt you.
AC on March 22, 2007 9:18 AMI agree that it needs to be enforced at the operating system level.
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. This would allow me to easily hide keys and passwords in my own files. How wonderful would it be to be able to create a file that could only be accessed by your own applications?
Matt on March 22, 2007 10:07 AMI think, a pretty simple, but still good approach whould be to describe basic workflows that should happen in such a program. This workflows whould basically be a regex with parallel charakters and the charakters where interrupts the OS has to answer.
Example I: I have a program that reads a number of URLs out of a file in a subdirectory in my home directory, downloads this sites and stores it into another subdirectory in my home directory.
Thus, a workflow whould be:
1 or more times: (
1. Read a file in $home/$subdir1
2. Access internet for 1 HTTP-Request (this can be capped in Size, because we know this is a HTTP-Request and the size won't be infinite
3. Write a file in $home/$subdir2
)
Or, if we have a simple recorder:
1 or more times: (
1: gui-action
2: parralel { Use microphone, write to $homedir ) 1 or more times.
)
This workflows are known at implementation time (or should be), thus stating these workflows should not be that hard (and encourage proper planning first)
Or, with solitair:
1 or more times: (
1: gui action
2: write to a config file of solitair
)
Thus, a takeover should be a lot harder, because if the solitair-program suddenly tries to access a file in the home-directory of the user, the OS can say "Hey, this is not stated in the current workflow, I will kill that program!" or if the program tries to access the network, the OS says again: "Hey, this is not stated in the workflows, lets terminate the thing."
I think a solution like thos should work pretty nice for the developers, because the know those workflows already and it should be pretty easy to implement this in a certain OS, because you can create a DSF which evaluates the interrupts the program does and maybe ends in a "malicious"
MfG
Hk on March 22, 2007 10:18 AMThe fucken documentation SUCKS. Plus, there are extremely
few books and other resources on CAS.
I will note as an aside that if a feature is so hard to explain that both the docs AND third-party discussions are unclear, the fault lies to a great extent with the feature itself. A feature that's extremely hard to explain is a feature that's got some design flaws, including (as noted in the thread) being over-engineered. Stated another way, if you create a feature that you have trouble explaining to users, think about redesigining it so that you CAN explain it. Because if they don't understand it, users won't use it ...
mike on March 22, 2007 10:20 AMI've had an idea for OS-level security in mind for awhile, now, that may or may not reflect what is currently being done. The basic idea bases itself off of the current concept of a root user and the administrators, users and guests. The basic change from this, however, is that there is a central application installation process. This process vets all incoming applications against an approved application database that holds file authentications like md5 checksums.
If the application does not match any known vetted application, or does match a vetted application but does not match the checksums, the installer throws a warning that would disallow any user-level operator to install further, but any administrator or root-level user to continue if they so choose.
I guess I never understood why all the applications get to make up their own directories, their own install paths and run their own installers. Seems pretty insecure to me. You only ever install one thing at a time, so why not have a centralized installation process that already knows all the pertinent information about your system?
Anyhow, I'm sure there are loop-holes and things I'm simply not considering, but on the surface it seems like a good idea.
Jae on March 22, 2007 10:55 AMJae: I think VMS worked like that. Unfortunately we've had some "progress" in the meantime...
Aaron G: "I actually tried to set up all the CAS policy assertions on my application a while back after FxCop whined to me that they didn't exist. But after a while I just gave up. [...]
The only way CAS could ever work is if the permissions were automatically deduced from the source code - but then I guess that defeats the purpose, doesn't it?"
Great post, completely agree. CAS is one of those features that were dreamt up without any thought whatsoever of real-world conditions and consequences. Nice intention, now please go back to the drawing board and design something useful! For example: deduce permissions automatically from the source code at install time -- then check against those permissions at any future execution to protect against virus infection or runaway plug-ins. That might work.
Chris Nahr on March 22, 2007 12:02 PMDespite a few variations with time, 'wrx' permissions have stuck because of their simplicity.
So, why can't it just be something like this in program access?
Just, instead of "user, group, others," try "owner, local, network."
"Owner" for the current user's files, "Local" for other files on the machine, and "network" is fairly obvious.
And, for enforcing this, have it assume "no access" if it isn't specified.
Maybe even give the user the option to override this during installation.
I'm sure it's possible to implement--considering it would probably be a few steps back, in complexity, from the current system. I just don't know how open MS is to accepting an idea with such a strong Unix/Linux base.
why does this have the date of march 20, when it was posted (afaik) today, the 22nd?
I quite like the blog, keep it up :)
Hazar on March 22, 2007 1:12 PMThe example is a bit too simplistic for my taste.
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.
In this security model, there will be dozens of vulnerable applications for each locked-down solitaire.
RiX0R on March 22, 2007 1:40 PMOn the subject of partial trust and sandboxing, especially in .NET, OWASP member and security guy Dinis Cruz has been tilting at windmills about this for quite some time. There's some fascinating (and depressing) reading to be found in the archives of the WEB SECURITY and SECURE CODING mailing lists, where he discusses some of these issues and attempts to get Microsoft to notice.
yipyip on March 23, 2007 2:09 AMI agree completely with Aaron G and Dave.
I think the problem is that we're trying to define "good" behavior as a set of rules. What we really want to say is:
Allow: Good
Deny: Evil
This is what all holy books have tried for the past 6000 or so years, and from what I understand, religious scholars are still debating on whether some actions are permitted or not.
Plus, what all these schemes ignore is the fact that if the user comes to a website that says "See celebrity NUDE!" and decides that yes, I want to see that, then it doesn't matter if a dialog box pops up that says "The application watch_celeb_nude.exe wants full trust". The click on "Allow" will come immediately.
We're stuck with either inflexible rules (don't allow the user to allow or deny permissions) or presenting the user with questions that they can't really answer. ("Permit read access to file \Winnt\config\asdhfjk2.log?" - what will a regular user make of that?)
tcliu on March 23, 2007 4:22 AMHi 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:
1. Programs should be able to, in a clear way, describe
what they need.
2. 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.
Ivan,
thank you for your reply. Wish you best of luck with Bitfrost and future development on the OLPC platform.
tcliu on March 23, 2007 5:58 AMActually, the Symbian capabilities model is sort of along these lines. In order to do stuff, a program (specifically, an EXE or DLL) needs to have the right capabilities. So, for example, a Solitaire equivalent would lack the capability to do network access, or mess with arbitrary files. In order to get capabilities, you need your installation file to be signed (by Symbian). In extreme cases (for capabilities that grant Astounding God-Like Powers) you need the phone manufacturer (Nokia or Sony Ericsson) to do the signing.
Of course, the flip-side of this is that the platform is tightly controlled by the OS hardware vendors, though it's not actually that difficult or costly to get an application signed with reasonable capabilities.
Ben Last on March 23, 2007 7:14 AM"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."
Glad they got that the right way around. I think the biggest issue with .Net CAS is that if you don't bother specifying any permissions you get all permissions by default. This gives the developer very little incentive to specify their permissions.
I wonder if Microsoft were developing .Net now (after their big security push) whether they would still set up CAS to be open by default?
Martin on March 23, 2007 7:15 AMIvan: "Of course you don't. You might wish to read the spec more carefully; this is explained."
What spec? Do you realize that I was talking about .NET security permissions, specifically the FileIOPermission class? The MSDN Library only lists options for setting permissions on specific absolute file directory paths which is useless for applications that allow users to create and manage their own files -- like I said.
"All in all, from what I can tell, this devolved into a bitterfest about CAS, not constructive criticism of Bitfrost."
Surprise -- people were talking about .NET CAS which is much more widely known than Bitfrost. And given the primadonna attitude you're putting on show here, it will probably stay that way.
Chris Nahr on March 23, 2007 7:33 AMChris: I misread your comment, sorry; any prima donna attitude you detect is more fueled by a multi-day lack of sleep than anything else :)
Anyway, I interpreted Jeff's post to be primarily about Bitfrost, with CAS being used as an example of why Jeff expects it to fail. This could be an incorrect interpretation on my part, but addressing your comment in this context, unlike CAS, Bitfrost doesn't require you to give global permissions to applications in any but the rarest of cases. Cheers, Ivan.
Ivan Krsti on March 23, 2007 7:50 AMhow about having the developers framework force them to make choices about what access their application needs. And this would not allow a global access, but force them to choose each and every conceivable access their application will need.
system.security.permissions.AccessRequiresAppPath = True
system.security.permissions.AccessRequiresUserDocuemnts = True
system.security.permissions.AccessRequiresUserRegistry = True
system.security.permissions.AccessRequiresHTTP = True
system.security.permissions.AccessRequiresFTP = True
system.security.permissions.AccessRequiresNone = True
system.security.permissions.AccessRequiresGlobal - doesn't exist
Then during standard application installation wizard process, after you choose what directory to install too, it give list of all access, with the applications requested access checked off. Most users will leave it alone, but it would allow other people to see what the developers planned at the very least.
CAS (and UAC, and other security mechanisms) are complex because fine-grained security is complex. That just seems to be the nature of the beast.
Now you could move to a more coarse-grained security model, which would be easier to understand and implement. But then the trade-offs between security, convenience, and backward compatibility will become even more apparent to both developers and users.
Although I must admit that MS screws itself because the tools for working and interacting with CAS/UAC/etc are truly and completely brain-dead.
Mark Pearce on March 23, 2007 8:23 AMIvan,
thank you for your comment. Good to talk to someone who has spent significantly more time thinking about this than myself.
The only question I have is how the complete security model works: In Bitfrost, the application must declare what permissions it requires, and based on those declared (and enforced) permissions, the user can choose to install / run the application or not. (If I understand this correctly.)
My question is then - how does the user know that the application doesn't do anything naughty with the resources it has access to? For example, suppose a cryptography program requires net access (to download public keys from a keyserver), and file access (to sign and encrypt files). What is to keep the crypto program from not just signing the sensitive files, but upload them to a server where I can get them?
Is this where I just have to trust the program?
tcliu on March 23, 2007 8:38 AMtcliu: You're welcome. Out of the box, Bitfrost will make it so that the program can only sign or encrypt those files you ask it to while running the program; it can't go arbitrarily opening up your documents without your permission. Past that, if the program does request network access, then yes, it can upload the files you explicitly let it open (but no others) to a rogue server.
I should say that developers of this kind of software will be under strong pressure -- from OLPC and the community -- to request finer-grained permissions. For instance, if the extent of your program's desired network access is talking to a PGP keyserver, the developer can easily have Bitfrost enforce communication with only a specific set of servers happening on specific ports (unless the user authorizes some other keyserver). If this pressure works, that's great, everyone will be more secure for it. But I'm not depending on it: even without it, I believe the out of the box experience will be quite a bit more secure than mainstream desktops. Cheers, Ivan.
Ivan Krsti on March 23, 2007 9:11 AMAs long as the user ( owner of the machine ) can do whatever they want the PC will only be as secure as the user is informed. It does not matter what the developer does or the OS does. The user (owner) will always have the ability to override a permission. This is exactly why sooner or later all software applications will be in a secure hosted online environement. Anyone create a spreadsheet's and/or document online using google's web app? This is the future my friends get used to it. The day's of installing programs on your computer are numbered. When user's no longer need to 'install' applications on their computer the current model's will work just fine. And NO I do not use IE.
RA on March 30, 2007 1:39 PMThe concept of an "operating system" that is supposed to "manage" the collected resources and services that most people call "the computer" is getting in the way here. Has it escaped everyone's notice that the most popular devices of the last century all had basically boot loaders with no real OS at all? PDAs, game boxes, Macs up to System 7, PCs up to Windows 98. We're shifting to over-featured phones now and calling what they run an "OS" is really stretching the term. And the assertion that OLPC itself, as an institution, is going to take no responsibility whatsoever for tracking and responding to threats, is mind-boggling considering what could happen to the users involved.
Strict execution control could work if all executions of all programs were logged the first time they happened, and anomalies detected (if a single instance of a program with the same name as another program was doing radically different things like downloading a lot of things that were unfamiliar) in its run after that. What would that take? An automatic upload of all the execution logs once per day from each machine? With a billion users that would cost less to track than any conceivable followup study that relied on watching the kids working or some more complex protocol of getting their permission - if they even know what that means. Privacy issues can be dealt with by obscuring the identities and scrambling them before they leave the country. It's no more intrusive necessarily than anti-virus systems.
In other words, this is a problem for systems administrators, not for programmers. And those systems administrators have the information they need to make decisions only if they have some access to the usage records for that application, as it's executed elsewhere. The information is so useful for other purposes (figuring out which of many programs should get a major upgrade, which should the kids be trained on, figuring out if there are particular patterns of abuse or educationally-inappropriate use developing) it's hard to imagine any objection outweighing that.
As for the OS, well, as Alan Kay said himself, it's a collection of tools and utilities that didn't fit in the programming language. In other words, there shouldn't be one. Having an OS to communicate with on the box adds an additional level of absurd complications.
When there's a problem, remember, the data has already (according to the spec itself) been stored elsewhere. There's no personal data of any kind on the particular OLPC having the problem. And if it's usage profile is known, then, it's relatively easy to know which boot image to restore. How long will it take to swap boot images and get a copy of the user's data to that machine? Not long. And this capability makes it easy to give someone a new OLPC and then give someone else their old one. Tying users to the hardware only makes sense if they really assume they are going to fail and the hardware will not become ubiquitous. If the project succeeded and OLPCs were as common as say pencils and blackboards, it would make far more sense to gather up and redistribute old ones to new users while more sophisticated users got new ones with capabilities they needed. In which case, the data and boot image is what matters, not what particular OLPC you run it on. This also works much better when OLPCs are shared or in library settings, which (whether its founders admit it or not) is more likely as a deployment scenario initially.
While there's nothing wrong in principle with a PKI infrastructure to make sure hardware is in fact equitably distributed to the persons who it was intended for, and nothing wrong with relying on peer to peer interactions to do the vast majority of the software monitoring and administration, I see no evidence that Bitfrost or the access control lists could eventually be passed on to the users themselves to administer. Starting with a centralized model that can easily be decentralized for each country, region or village that wants to learn how to administer and monitor the OLPC network itself, seems wiser to me than assuming that the programmers, children and schoolteachers are fit to handle the many scenarios of failure that could arise.
In other words, there's a role for experts who monitor events from a technologists' perspective, and respond to those events in real time, rather than anticipate them (as a programmer does) or interpret them pedagogically (as a teacher does) or as their own fault (as a kid does). Trying to rule systems administration out of the picture is like letting the Norse gods get fat and slack and forget to guard the bridge, which they did. I suggest a systems administrator interface called Heimdall (the Norse guard of the bridge) needs to be defined.
[http://www.mainlesson.com/display.php?author=kearybook=asgardstory=children]
"Heimdall was a tall, white Van, with golden teeth, and a wonderful horn, called the Giallar Horn, which he generally kept hidden under the tree Yggdrasil; [70] but when he blew it the sound went out into all worlds....[he said]... the son of nine sisters am I. Born in the beginning of time, at the boundaries of the earth, I was fed on the strength of the earth and the cold sea. My training, moreover, was so perfect, that I now need no more sleep than a bird. I can see for a hundred miles around me as well by night as by day; I can hear the grass growing and the wool on the backs of sheep. I can blow mightily my horn Giallar, and I for ever [71] guard the tremulous bridge-head against monsters, giants, iron witches, and dwarfs." (Note no mention of trolls. Evidently this is a social and not a security problem!)
Now THAT sounds like a sysop. Especially the "blow mightily" part!
under Heimdall's bridge on June 9, 2007 4:21 AMThe difference is that Linux distros already have to do some meta-development for each application adding to the repositories. The primary coders don't care about security since they're not trying to write secure code since that's a total distraction from their awesome idea. But later the distro guys can say what the app needs and doesn't need.
saber taylor on August 2, 2008 3:48 AMHmm
This sound like it would be trivial to implement through a simple chroot jail. Having a consistent file based API like Plan 9 the security simply boils down to which files the application can see.
John Nilsson on February 6, 2010 10:03 PMI don't know why the solution to security problems (or perceived security problems) is more dialog boxes. Does UAC's intermittent stream of modal dialogs make me feel any more secure in Vista? No; it makes me feel like I'm fighting an uphill battle against the computer to get anything accomplished. This is not to say that granting userland apps the same sort of "it's OK to read from/write to this directory" dialog as you get from firewalls is a bad idea, it's just that bathing in dialog boxes doesn't make me feel any cleaner.
If Microsoft wants to get serious about integrating security, asking app developers, who are invariably shipping product that's gone late and over budget, to bolt on security is not going to work. What works is making things secure out of the box.
Restrict applications from reading or writing to disk except for methods explicitly flagged as [ReadFromDisk, WriteToDisk] and you're getting there. There's my gloriously imperfect 30 second solution to an endemic problem (code being maliciously subverted) that has and will haunt us to the end of our days.
I actually tried to set up all the CAS policy assertions on my application a while back after FxCop whined to me that they didn't exist. But after a while I just gave up.
It made no sense to me. File I/O was probably the weirdest. I'm supposed to tell the Framework that I need read/write access to specific files or paths... but how does one do that if the paths are arbitrary? Even just the program settings, I have no idea if they'll end up in the normal AppData location or in somebody's roaming profile (which would require access to the network and read/write access to a network drive or UNC path). These things are set by environment variables; as the developer, I don't even get a choice in the matter.
Or, my program wants to consume a web service. Great. Just give some basic network permissions. But wait, the service is protected with an X.509 certificate, which means I need to supply my own and be able to read the private key of another certificate. Suddenly we've moved from minimal trust to very high trust for something that's not even supposed to require any code changes! But do I need to assert this at the application level, or is it enough that the WSE assembly itself has that level of trust? Maybe it's the latter. But what if I want to display a list of certificates so the user can pick one? In that case I don't actually need to read the private key, but it's a different privilege to open the certificate store and yet another privilege to enumerate the certificates and ARGH MY HEAD HURTS!!!
So I just said screw it, this thing will run with full trust, deal with it.
You can't ask programmers to do this. Essentially what you're asking for is full, detailed specifications of exactly what the program will do and when and why. Any agilist knows that these specifications will take maybe a week to be totally invalidated (even I know that). Keeping the policy up to date eventually becomes more work than updating the program.
The only way CAS could ever work is if the permissions were automatically deduced from the source code - but then I guess that defeats the purpose, doesn't it?
Aaron G on February 6, 2010 10:03 PMWhere are the ACLs set and stored? Are we putting them out of reach of hackers somehow? What if this is a non-interactive application (web app/web service/background service)? Prompts don't make sense in these cases. I don't like prompts so much.
If things blow up as early as possible in development and a developer's forced to (painlessly) resolve them by setting attributes on a method (or class) or by making some other changes that eventually get interred in the DLL or executable, that's fine.
If we're shipping responsibility to decide what permissions an app needs to function off to the user, we're screwed.
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |