Sorry I didn't realize "developers" is an offensive ivory tower in other parts of the world, in my world its a compliment.
-gunnar On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: > HI, > > "maybe the problem with least privilege is that it requires that > developers:..." > > IMHO, your US/UK ivory towers don't exist in other parts of the world. > Developers have no say in what they do. Nor, do they care about > software security and why should they care? > > So, at least, change your nomenclature and not say "developers". It > offends me because you are putting the onus of knowing about software > security on the wrong people. > > Cheers, > Stephen > > On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson > <[EMAIL PROTECTED]> wrote: >> 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" <[EMAIL PROTECTED]> 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 >>> [EMAIL PROTECTED] >>> >>> _______________________________________________ >>> Secure Coding mailing list (SC-L) SC-L@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@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@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@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. _______________________________________________
