Unclassified NSA document on .NET 2.0 Framework Security

[gunnar at arctecgroup.net (Gunnar Peterson)]

maybe the problem with least privilege is that it requires that  
developers:

1. define the entire universe of subjects and objects
2. define all possible access rights
3. define all possible relationships
4. apply all settings
5. figure out how to keep 1-4 in synch all the time

do all of this before you start writing code and oh and there are  
basically no tools that smooth the adoption of the above.

i don't think us software security people are helping anybody out in  
2008 by doing ritual incantations of a paper from the mid 70s that may  
or may not apply to modern computing and anyhow is riddled with ideas  
that have never been implemented in any large scale systems

compare these two statements

Statement 1. Saltzer and Schroeder:
"f) Least privilege: Every program and every user of the system should  
operate using the least set of privileges necessary to complete the  
job. Primarily, this principle limits the damage that can result from  
an accident or error. It also reduces the number of potential  
interactions among privileged programs to the minimum for correct  
operation, so that unintentional, unwanted, or improper uses of  
privilege are less likely to occur. Thus, if a question arises related  
to misuse of a privilege, the number of programs that must be audited  
is minimized. Put another way, if a mechanism can provide "firewalls,"  
the principle of least privilege provides a rationale for where to  
install the firewalls. The military security rule of "need-to-know" is  
an example of this principle."

Statement 2. David Gelernter's Manifesto:
"28. Metaphors have a profound effect on computing: the file-cabinet  
metaphor traps us in a "passive" instead of "active" view of  
information management that is fundamentally wrong for computers.

29. The rigid file and directory system you are stuck with on your Mac  
or PC was designed by programmers for programmers ? and is still a  
good system for programmers. It is no good for non-programmers. It  
never was, and was never intended to be.

30. If you have three pet dogs, give them names. If you have 10,000  
head of cattle, don't bother. Nowadays the idea of giving a name to  
every file on your computer is ridiculous."

Conclusion(gp): Least Privilege is the point where the practical  
matter of applying Saltzer and Schroeder's principles breaks down in  
modern systems. Its a deployment issue, and a matter of insufficient  
models and modes.

http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html

Remember the 1990s when there were all these search engines that  
required you tag up all the content and put it in hierarchical  
directories and so on? Well what happened? Google came along and ate  
their lunch. When the problem is information overload, telling  
everyone to go out and label everything is not gonna work.

-gunnar



On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote:

> Sadly this non-adoption of privileged/managed code (filled with  
> blank stares) has been the case ever since the Java security days a  
> decade ago.  One of the main challenges is that developers have a  
> hard time thinking about the principle of least privilege and its  
> implications regarding the capabilities they should request.  Dinis  
> is brave to set such thinking as a target.  I've settled (after ten  
> years) with getting developers just to utter the word "security."
>
> All together now..."security".
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
> On 11/24/08 12:31 PM, "Mike Lyman" <mlyman-cissp at comcast.net> wrote:
>
> Dinis Cruz wrote:
> > Don't get me wrong, this is a great document if one is interested in
> > writing applications that use CAS (Code Access Security), I would  
> > love
> > for this to be widely used.
>
> When we recommended recommending CAS during a review of the U.S.  
> Defense
> Information System Agency's new Application Security and Development
> Security Technical Implementation Guide earlier this year we were met
> with what amounted to blank stares. (At least it seemed like that  
> since
> it was a phone conference.) Some on the call understood it and agreed
> with the recommendation but those hosting the call and doing the  
> writing
> didn't seem to grasp it. It may be a while before we see too many
> adopting this or requiring it for a while.
> --
>
> Mike Lyman
> mlyman at west-point.org
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
> )
> as a free, non-commercial service to the software security community.
> _______________________________________________
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
> )
> as a free, non-commercial service to the software security community.
> _______________________________________________