Local Policies

Bruce Schneier is partially correct on his critique of UAC in Vista

Security warnings are often a way for the developer to avoid making a decision.

This is frequently true, but misses the main point which is that all trust is local. 

Let's take mobile platforms, they are not stupid cellphones any more, they are actual platforms, running more apps than say your average 1990s Unix server. What did it take to ACL out one of those puppies? Let's take a specific example, here is what default Security Options are available to Blackberry users;

• Content Compression/Protection
• App permissions (fine grained for each app)
• Certificate Servers
• Certificates
• Firewall
• Key Stores
• Memory Cleaning
• Softwar Token
• TLS
• WTLS

This is just for a Blackberry, never mind something as sophisticated as a modern operating system. Suffice to say even in a "small" mobile device, there are many, many authorization decisions that have to be made locally.

What we lack is a usable way to put users in charge of some portion of their own security policy. More specifically, something other than Root or Nothing.  We cannot do it without either (ideally) implicit or explicit help from the user and we won't be done until we get there.

Comments

[Robert Stratton]

This is right on the mark. The past 2 decades produced no dearth of robust security technologies with abysmal human factors problems.

Mandatory access controls are not, in and of themselves, bad things in systems, but I have yet to see a system deploying them that appears to have had any significant investment in human interface design. For any of us to wonder why deployment has been lackluster is at best naïve and at worst disingenuous.

[Rob Lewis]

@Robert Stratton

You have hit the nail on the head regarding the lack of human interface design being a barrier to practical implementation of mac/mls. The "abysmal human factors problems" is reflected in the disconnect between business operational rules and IT security policies.

We provide an authorization engine with the ability to define and map relationships between users, groups, files, directories, networks and systems. This fundamental design is necessary to provide security settings in human terms. There are other things required to enable manageability since usability is fundamental to delivering strong security, such as a natural language security specification, use of open standards for interoperability, utilities, tools, application interfaces, and integration capabilities, protection profile templates, security visualization library and tools that will eventually provide touch screen interfaces etc..

Ironically, our abysmal human factors problem has simply been trying to convince the security community that we can actually do this, (in the absence of marketing dollars).

FYI Gunnar,

We can provide anywhere from full to none, or anywhere in between as far as root access goes. We can grant some root privileges to regular users, or remove some root privileges from root users, as well as set limits or boundaries as to how many times they may be used, when, how, etc.. Have a use for this?