RequestOptional and RequestRefuse

re: RequestOptional and RequestRefuse

Stephane Rodriguez — Thu, 01 Jul 2004 18:34:00 GMT

I am having a hard time figuring out what is the true intent of your post. It appears so much like you are saying that non-.NET apps are insecure, dismissing pretty much all applications out there.
I am sorry but the operating system right now grants access by default as a consequence of the inability of MS to engineer an OS which would be useable without admin rights. Whenever you install a third party, the same story again. So what now, will you pretend that all third parties are insecure, and that developers are responsible for that ? What is the true intent of that, even more integration/coupling with the OS?

re: RequestOptional and RequestRefuse

Peter Torr — Thu, 01 Jul 2004 18:42:00 GMT

Stephane, I am sorry but I don't understand your comment. The intent of the post was to point out that yes, requesting *optional* permissions is a more secure way of writing code than refusing permissions, but that it is hard to manage.

This post isn't about 3rd party software being insecure, or about non-.NET apps being insecure, or about running on Windows with non-admin privileges.

If there is something else you would like me to address, please post again.

re: RequestOptional and RequestRefuse

Stephane Rodriguez — Thu, 01 Jul 2004 19:00:00 GMT

Denying access b y default, ie the Java sandbox security model, is fine for a fraction of applications out there, and completely irrelevant for others. If you read between the line, changing yes by default to no by default breaks compatibility. Net net, some completely irrelevant application security model is supposed to take over everyone's app provided it's running on top of the CLR. if this doesn't hurt, particularly for new projects, fine, but that is probably a major limitation of internal Redmond views, they refuse to see the existing software. And not only because new projects are sexier.

re: RequestOptional and RequestRefuse

Eric Wilson — Thu, 01 Jul 2004 22:04:00 GMT

Thanks for the post Peter. This helped me a lot.

re: Maintaining LinkDemands across inheritance boundaries

Office Development, Security, Randomness... — Fri, 02 Jul 2004 01:09:00 GMT

re: RequestOptional and RequestRefuse

Peter Torr — Thu, 01 Jul 2004 22:09:00 GMT

No worries. Glad someone liked it ;-)

re: RequestOptional and RequestRefuse

Dave THomas — Fri, 02 Jul 2004 15:22:00 GMT

A sample of the "best" way to implement this would clear things up for me...

re: RequestOptional and RequestRefuse

Nicole Calinoiu — Sun, 04 Jul 2004 13:35:00 GMT

Thanks for the clarification. It's good to know I haven't been inadvertently pooching all my apps by taking what I perceive as the lazy route. <g>

I'm very curious as to why you consider that the RequestOptional approach might be more work. If the goal is simply to not run with full trust, then I'd agree since all that's necessary is to refuse one permission. However, is anyone who actually cares about security likely to aim for anything quite so trivial? It seems far more desirable to request the minimum necessary permission set. IMO, screening out permissions that aren't required is a far more difficult route to the latter goal, even if one ignores (which one probably shouldn't <g>) the possibility of extension of the available permission set outside the initial development environment.

If one starts the development of any given assembly with execution permissions only, it's a reasonably trivial task to add required permission requests as functionality is added. If one fails to request a required permission before release, then one obviously also failed to test the affected functionality properly, so it's probably for the best that the functionality fails anyway. If one needs to add new functionality for a new release, what's the difference in workload between adding a new RequestMinimum and dropping an old RequestRefuse?

Using the white list approach also makes it much simpler to sort out security exceptions for deployed applications. Since the request list is self-documenting, it becomes reasonably trivial to compare it to the grant list for a deployed assembly in order to discover why security exceptions are occuring in environments that are outside the developer's control.

re: RequestOptional and RequestRefuse

Peter Torr — Mon, 05 Jul 2004 18:42:00 GMT

It's just my opinion ;-). In a well-managed development cycle that has thought about security from the start, it might very well be easier to go with RequestOptional. But for customers trying to ship a product (or just customers who want to "do the right thing" but don't have enough time or resources for a thorough analysis -- remember not all code is shrink-wrapped, sold-to-the-public code; much of it is internal-only LOB code) refusing a few choice permissions that you know you don't need is better than nothing.

Either way, you still have issues though where you need a permission one day, but then you change the design and you don't need it the next day (and who is going to update all the permission requests?). And if you are *really* going for "least privilege" then you have to be very fine grained, down to the exact files / reg keys / database tables / etc. you want to manipulate.

This is where tools come in, such as the permcalc tool in Whidbey. It's just too much work to expect the average developer (even a security-consious developer) to get it right all the time.

Strictly speaking, just saying "I want to read/write the temp directory" is not good enough if you only need to read/write one (or ten or even one hundred) files out of it. And often times you don't know ahead of time what requirements you have (eg, you create a temp file with a random name supplied by the system; there's no way you can add a declarative attribute requesting the right permission in that case).

Also it should be noted that even without any attributes, your code is _unlikely_ to be lured into doing something really bad. The two most likely avenues for attack are LinkDemands that you are silently (and unknowingly) satisfying, or delegates that are being used for nefarious purposes (which is mitigated by not having "normal" methods that match delegate signatures).

I am by no means saying that refusing permissions is a bad idea; just that you aren't automatically insecure because you failed to refuse / opt-in to any permissions.

Basically, as always, it comes down to risk analysis. Cost-benefit trade-offs.