Proposal for RBAC Features for SDD James Falkner Sun Microsystems October 11, 2006

1
Proposal forRBAC Features for SDDJames
FalknerSun MicrosystemsOctober 11, 2006
2
Related Use Cases
- Install customized for different roles.
administrator, end user, developer for example).
So the user does not have to make complex
decisions about what components to select for his
needs. The custom options should aim at reducing
complexity by providing exactly the set of
features a particular role might need
- (Non-Root Install) 1. User installs product
(into a location into which they have "write
access"2. User configures and uses software.
Software makes no use of (or disables certain
features thatrequire) administrator-only
interfaces
- Development needs to specify the privileges
required to install a component. There are
generally cases in which a root or other
administrative level user id is required For
Windows, creations of product registry
information, defining discretionary access
control, or setup of services, drivers, etc.
For UNIX/Linux, update of protected directories
such as /etc
3
Related Requirements
2.2.1.4 The SDD specification MUST must support
the ability for the author to define the
information in order to specify, as requirements
for deployment lifecycle operations, the need for
administrative, user, and system privileges. SDD
specification must must support the ability for
the author to define the system privileges
required for deployment lifecycle operations when
necessary. However, it should be noted, as a
best practice, system privileges SHOULD only be
required when absolutely necessary.
2.1.1.5 The SDD specification must support the
ability for the author to define information
sufficient for a provisioning application or
installation program to determine in advance that
a deployment lifecycle operation is invalid
??? Ability to disable installation or
configuration of components based on pre-defined
roles or privileges
4
Potential Solutions

• Adopt two Roles user, and administrator
• Satisfies only one use case, and does not permit
  future use cases or extensibility
• Define a generic, extensible Role entity
• Associated with installation groups or features,
  and constrained resource requirements
• Better, but does not address flexible policy
  declarations and leaves a lot up to
  implementations
• Adopt existing standard
• ANSI RBAC, XACML, WS-Security

5
Existing Standards

• ANSI RBAC
• Generic model, used as basis for XACML
• Not readily adoptable in XML Standards
• WS-Security
• Not role-based, mainly concentrates on message
  security, confidentiality, and integrity
• Others
• http//www.oasis-open.org/committees/xacml/faq.php

6
Proposal XACML

• XACML is an OASIS standard that describes both a
  policy language and an access control decision
  request/response language (both encoded in XML).
• OASIS Standard
• Generic
• Distributed
• Needed subsets readily imported

7
XACML Concepts

• Policies define rules which are applied to
  individual entities or roles to allow or deny
  access to resources
• Can be very simple or complex
• Resources are any protected entity
• Physical hardware
• Directories (e.g. /usr)
• Metadata (e.g. Features)
• Application state (e.g. allowable configuration)

8
XACML Example Policy
Identifies which resource is protected (the
target)
For any action (install, configure, etc)
Allow If..
User ID
Root (uid0)
9
Application to SDD
Checks can define policy to constrain resource
Becomes addressable resource within Policy via id
10
Application to SDD
Defines Roles in which feature should be selected
or deselected (e.g. EnabledForRole)
11
Application to SDD
SIU install action SCU configure action
Specifies which role is required for this IU
12
Implementation Considerations

• Must map end users to Roles (out of scope for
  SDD)
• Must process XACML Policies according to
  specification
• Initially, all XACML entities (PEP, PDP, etc) can
  be local and private to implementation.
• Can optionally provide true XACML implementation
  (request/response protocol, context creation) for
  interoperability with true XACML systems