Re: Microsoft SDL report card

[iarce <iarce () corest com>]

On 5/3/11 11:16 AM, Ben Laurie wrote:
> On 18 April 2011 18:46, Andy Steingruebl <steingra () gmail com> wrote:

> > Try setting the permissions for an application when you install it, or
> > figure out whether it is asking for more permissions than it really
> > needs, etc?
>
> The underlying problem with these questions right now is that
> permissions are expressed in terms of low-level system services (e.g.
> file read/write), but actually we should be making decisions at higher
> levels where the permission correspond to things the user understands
> (e.g. "my account at Google" or "my Flickr photos" or "this album in
> Picasa"). Capabilities seem well suited to this level of permission
> management.
>
> > Thoughts?

Yes, read below a VERY LOOONG REPLY (you've been warned) with both a
summary and an historical account of how those thoughts were evolved.

<TL;DR>

Eduardo Arias and I wrote some of our thoughts about this topic in 2005
[See http://bit.ly/knwV81].
Our views derived from work done at Corelabs - Core's research
groups- during the late 90s and early 2000 on enterprise security
software and later on as part of the Core Force project, a free
standalone endpoint security software for Windows [See
http://force.coresecurity.com].

The main idea behind that project was to explore innovative ways (or so
we thought at the time) to address the security vs. usability dichotomy
in endpoint security software.

Here are some of our guiding principles, I think many of them might
apply to the mobile apps of today's smartphone marketplaces:

1. Effective security *requires* fine grained access control of
low-level system services enforced at the kernel layer. Anything short
of that would be easily circumvented.

2. Configuring low-level access permissions for a typical real-world
endpoint system is error-prone and plagued by usability and operational
challenges. Determining appropriate permissions for a Windows operating
system full of legacy code, deprecated, overlapping APIs and
undocumented features is already cumbersome. Doing so for an endpoint
system with tenths of installed applications that must run unaffected by
the security software yet remain hardened to resits attack is nearly
intractable.

3. To cope with the configuration challenge and usability problems that
arise from #1 and #2 multiple higher-level abstractions should be
defined and used as reusable components throughout the endpoint's
security configuration.  In our case, the top level abstraction was the
"Security Profile", a complete set of "security policies" that dictate
what the entire system or a specific application is allowed to do. The
overall security configuration of an endpoint is then composed of a
"System Profile" plus a number of "Application Profiles", one for each
application that needs to be controlled. Access control permissions
specified in these "Security Profiles" are enforced by the kernel.
In turn, a "Security Profile" is just a set of named "Security Policies"
associated to the entry point executable of the application. Security
policies can be nested thus building a hierarchy with multiple levels of
abstraction. At the lowest level a security policy is a named set of
low-level access control RWX permissions over local file, registry and
network resources.

4. Even with the use of higher level abstractions such as
"capabilities", "traits" (or "profiles" and "policies" as we called
them) an exhaustive definition of permissions for any given Windows
application isn't easy to determine -if you doubt this, try defining the
exhaustive minimal list of permissions that lets notepad.exe run
normally yet prevents overall system abuse if the process is
compromised-. Static or dynamic analysis tools that automatically
collect information about a program and generate the corresponding low
level security configuration are useful or even necessary (but not
sufficient) to deploy endpoint security software in real world
organizations with thousands of endpoints that may eventually run a
small subset of several hundred authorized  and many legitimate but not
explicitly authorized applications.

5. Use of an endpoint security solution that provides MAC through
low-level sandboxing to a large user base for the consumer market or
deployed at thousands of different organizations would require the
development and maintenance of "application profiles" for several
thousands closed-source COTS and proprietary applications. Even with
automated tools this is unfeasible to do for a single vendor or security
team thus the problem should be addressed with additional means. In our
case we decided that a divide&conquer strategy might work: we let
technically savvy end users define, review and share the security
configuration ("application profile") of their application. Less savvy
users could secure their endpoints by picking or automatically receiving
configuration files that were developed by others. This brought in
several interesting thoughts and challenges.

6. One user's "application profile" for, say "Firefox" or "IE", may be
unacceptably lax or too restrictive to another user. Furthermore, due to
customization, extensibility (plugins, themes, etc) and localization a
user's application profile may be unusable or unsuitable for the same
application running on a different endpoint. The "reusability" of an
application's hardening configuration is a measure of its quality and
value. Letting end users develop their own security configuration
profiles (loosely termed here as "security content") is equivalent to
letting them change the value of their endpoint security solution,
letting them share their security content also lets them share the value
and amortize costs. Beyond the technical challenge of how to assess and
maintain the quality and security effectiveness of the endpoint security
solution this scenario also has several business implications. I will
not describe them in detail here but think about how many AV or host IDS
vendors let their users inspect, create and freely share "security
content" (signatures, alarm triggers, etc.)

7. An endpoint security solution that lets users freely create and share
security content and thus modify its value presents some management
challenges. Traditional endpoint solutions (or any security solution for
the matter) rely on centralized security management through servers or
entire data centers from which security content created by a single
entity (security vendor or security office) is either pulled or pushed.
This can be modeled with a graph with a star or, more generally, tree
topology. In a network in which each and every node could potentially
create and share content those topologies may not be optimal for
efficient communications and propagation of changes.
P2P networks, social networking graphs, content markets, reputation
systems and distributed processing, storage and management are all
interesting areas to explore for endpoint security software (including
mobile). Yet the security industry seems refractory to the applicability
of these concepts to their software products while more innovative
segments of the overall software industry have been exploring them
(successfully) for more than a decade...


If you are still reading this and are interested in knowing how these
ideas were developed I provide a summary our past work below.

Around 1998 we faced the challenge of enforcing enterprise-wide security
using RBAC at all the endpoints of a relatively small but
technologically complex financial services organization (a national bank
with 60 branch offices, ~10k endpoints). Endpoints ran a variety of
(mostly) Windows operating system (95, 98, 2000, XP) on top of which
around 300+ closed source business applications acted as the client tier
of a multitude of server-side technologies (an IBM Mainframe, Novell
Netware, AS400, UNIX and Windows NT/2000 servers). Naturally, none of
these applications were originally written to support anything other
than discretionary access control at the endpoint. Most of them were
written by third parties and in many cases there was no source code nor
maintenance contracts.

We decided to tackle the problem by developing a set of kernel drivers
that would mediate RWX access to local resources such as files,
registry, network packet & socket layers and grant/deny permission to
the current (application, user) tuple based on centrally managed policy
settings. We purposely left out kernel objects and in-memory
process-level structures from the access control mechanism, arguably
this left several risks uncovered but it seemed a reasonable compromise
to reduce the complexity and footprint of the solution.

Around that time the same approach was used by AppArmor and SELinux to
implement MAC on Linux, arguably it should have been much easier for
them since they had full access to kernel source code and needed to
support only a handful of kernel versions plus they had the ability to
modify the filesystem and other kernel code to support their solutions.

It should be evident what a configuration nightmare such a endpoint
security solution would be if it was built on top of permissions for
low-level system services only - both SELinux and AppArmor faced the
same challenges.

So we came up with the idea of adding a few abstraction layers to an
application's security configuration. At the lowest level RWX access
permissions could be applied to files, registry keys, folders and IP
addresses could be configured explicitly
(c:\windows\system\iphlpapi.dll ), using regexps
(c:\windows\system\*.dll ) by de-referencing env. variables
(%SystemRoot%\iphlpapi.dll) and recursively ($SystemDrive%\*.dll;R).

A set of these low-level permissions could be grouped in what we called
"security policies" which basically modeled behavioral traits of the
application being sandboxed. For example, an application that
communicates over TCP/IP usually requires a set of network, file and
registry access permissions that is more or less "atomic" (RX to a set
of specific DLLs and registry keys, RW to set of directories and keys,
SND/RCV to a set of IP address blocks). All the needed permissions could
be grouped as a named policy, i.e. "Connect to the Internet".
Security policies could be nested, thus you could have a named security
policy (ie. "Basic runtime environment") built simply as a set of
lower-level security policies {"Read local HTML", "Send and receive
mail","Save to Downloads folder", "Use local printers"}

Sets of this higher-level constructs ("named policies") could then be
assigned to System-wide settings or to per application configuration
settings which we called "Security Profiles". Thus for each application
identified by a cryptohash of the entry point executable there would be
a specific application's "security profile" composed of a series of
friendly-named "security policies" such as {"Run any installed plugin",
"Connect to the Intranet", "Install new plugins", "Enable crash
reporting to vendor"} assigned to up to five security levels (Low,
Medium-Low, Medium, High, Custom).
Thus, an endpoint with the software installed would be running each
application sandboxed at a given "security level" and the kernel drivers
would limit that application's low level behavior based on the
permissions defined for that security level in the application's
security profile. The overall system, OS services and any un-specified
apps would run sandboxed according to permissions of the System profile.

In sum, the endpoint's security configuration would end up being a set
of security profiles for known applications each set at a given security
level plus a system-wide profile set also at a given level. The result
was a very flexible security configuration system that could be used for
the whole spectrum from white to black listing of applications with fine
grained permissions that could be grouped into user-named re-usable
components and shared by multiple application security profiles. To
facilitate deployment we implemented a runtime mode for all drivers in
which all accesses were granted but written to a logfile. Deployment
would start with a small group of users with a similar role in log-only
mode, the resulting logfiles would be collected later and processed to
create access permissions automatically, machine learning and other
techniques could then be used to group access permissions into common
"security policies", etc.

The original enterprise flavor of this project completed deployment
around 2003. All endpoints received their security configuration from a
central management server when the user logged in based on the roles
assigned to that user.

Later in 2006 a standalone version called Core Force Personal, was
released as free software for windows 2000 and XP. We added a few
features that we considered important to tackle the usability/secure
configuration challenges of endpoint security software aimed at the
"consumer" market. We added a UI to let end users define system and
application profiles by themselves (an XML file underneath) and to
upload their profiles to a public webserver for sharing. The software
shipped with a number of pre-built profiles for popular apps (IE,
Firefox, MS Office, Adobe Reader, etc) and upon installation it would
identify installed apps and search for matching security profiles on
the public web site. The end user would be given the option to install
found app profiles automatically or to manually select a suitable
profile from a contributing user, to aid selection we built a basic
reputation system in which end users could rate the quality of a given
security profile using the UI. The project was finally shutdown some
time after the RTM of Windows Vista.

</TL;DR>

If you made it this far, I am sure you have your own thoughts on the
matter and a critical view about what I wrote. I'd love to read your
comments! Send them to the list or directly to me if you deem it far too
off-topic for SC-L

Regards,


-ivan



-- 
Ivan Arce
CTO - Core Security Technologies
_______________________________________________
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________