The 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.
Hmm
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.
I 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?
Where 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.