mssf access control overview - selinux...

11Intel / Nokia Confidential © Copyright, 2010

MSSF Access Control Overview

Janne Karhunen, Nokia Mobile Solutions

1


2

Outline

Access Control in Linux

MSSF Access Control Principles & Concepts

MSSF Access Control Components

Manifest file

Secure Software Distribution

Security Policies

Components interaction

Installation

Run-time

Kernel implementation

Conclusions and Q&A


Classical Unix AC Based on multiuser model Discretionary AC POSIX capabilities aren’t really in use (root has all, others none)

Our criteria: Process level mandatory access control needed Minimal changes to the current model (enforcement phase) Good level of flexibility and granularity, easy to understand concept (KISS)

Existing security extensions don't quite match FreeBSD AC, MLS, Biba, SELinux, RBAC, AppArmor, TOMOYO Linux, …

Our approach: Minimally extend Classical Unix AC to meet set criteria Re-use multiuser-model for application-level access control Architecture outlined in the next slides

3

Access control in Linux


Principle of least privileges

Every application should be able to access only limited set of resources

Protected resource

A virtual resource that needs limited access

Cellular functionality, Location information, Calendar, ..

File system

No final list yet – work in progress

Credential

Protect a resource

Traditional Linux set of credentials consist of UIDs, GIDs and POSIX capabilities

MSSF Access Control extends it with resource tokens and application identifier

Application must declare credentials it needs or provides in the Manifest file

4

MSSF Access Control – Principles & Concepts


MSSF Resource tokens

Strings naming protected resources – similar to labels in other security frameworks

Global: UserData, Cellular, Location, etc.

Package specific: my-package::access

MSSF Application ID

Used to derive application specific cryptographic keys

Defined as: AppID = {SourceID, Package, Application Name}

AppID = {ovi.com, CoolTools, AddressBookPlugIn}

Properties: Unforgeable, unique, persistent.

Application name is given in Manifest file (optional)

5

MSSF Access control – New credentials


Manifest file

Included to the package and contains list of executables and their credentials

Additionally device security policy updates, integrity protection related information

Device security policy

Located on the device and defines SW source trust level and credentials that can be granted to packages coming from that repository

Credentials policy

File containing mapping of credentials to executables. Package Manager updates this file when packages are installed, upgraded or removed

Package Manager

Responsible for updating credentials policy database during package installation

Credentials policy loader

Called during boot to read and import credentials policy to the kernel

Credentials Manager (kernel modules)

Provides credential management and assignment to the processes

6

Access Control framework components


An optional xml file inside Debian package

Declares needed and provided credentials

Resource tokens

Application identifier

UIDs, GUIs

POSIX capabilities

Should be generated automatically by SDK based on the source code

D-Bus policy can be generated from Aegis Manifest during installation phase

May contain a package signature

Used for authorized security policy updates

Package manager updates Credentials Policy based on the Manifest File and

constraints from the Device Security Policy

7

Manifest File


Server (comes from server-pkg) defines resource token UserData needed to access the server<aegis>

<provide>

<credential name="UserData" />

</provide>

</aegis>

Client declares that it requires tokens UserData and Cellular<aegis>

<request>

<credential name="server-pkg::UserData" />

<credential name="Cellular" />

<credential name="CAP::net_admin" />

<for path="/usr/bin/userdatamanager"/>

<for path="/usr/bin/userdataclient"/>

</request>

</aegis>

8

Manifest file examples


Secure Software Distribution

Each package has SW source (known or unknown)

SW repository (based on the repository signing)

Any virtual entity (based on the package signing) as single developer, web page and etc.

Each known SW source has a asymmetric key pair

Public key is known to a device

Private key is used to sign the packages

Each SW source is assigned a trust level

Update of SW package is possible only from the same SW source or from a SW source with higher trust level

SW source trust is based on the source Quality Assurance level

9


Contains mapping between SW sources and allowed credentials

Accessible only to Installer

Allows to create different security levels on the devices

The allowed credential set for each SW source is based on the risk level

Can be updated via authorized policy updates

Special domains (content to be defined):

Unknown

Developer

10

Device Security Policy

SW Source name Trust Level Public key info Credentials that the SW Source can grant

MeeGo.com 100 ABCDEF… Cellular, UserData

Developer.org 20 ACDEFR… UserData

Unknown 10 --------- UserData


A file containing mapping of credentials to executables.

Produced from Manifest file and Device Security policy (intersection rule)

Package Manager updates this file when packages are installed, upgraded or removed

Example:Package: bluez

Source: com.nokia.maemo

Request:

CAP::net_bind_service

CAP::net_admin

CAP::net_raw

CAP::ipc_lock

Cellular

GRP::phonet

Object: /usr/sbin/hciconfig

Object: /usr/bin/hcitool

Object: /usr/bin/sdptool

11

Credentials policy


1. Application packaged with Manifest file

2. Package manager checks the Device Security policy information

3. Package manager modifies the Credentials policy according to the “Intersection rule”

4. Package manager possibly modifies D-Bus policy

5. Package manager updates the run-time credentials policy in kernel

12

Components Interaction – Installation time

Package Manager

Device security policy

Run-time credentials

policy

1.

2.

UserSpace

Kernel

Credentials manager

3.4.5a.

Package

Manifest

D-Bus policy

Credentials policy

5b.


Allows the server to read the credentials of the client process and to perform

desired credential checks.

Policy enforcement is done at application side

Example:int foo()

{

creds_value_t value;

creds_type_t type;

require_type = creds_str2creds("UserData", &require_value);

fd = accept(sockfd, &cli_addr, &clilen);

ccreds = creds_getpeer(fd);

allow = creds_have_p(ccreds, require_type, require_value);

if (allow)

write(fd, MESSAGE("GRANTED\n"));

else

write(fd, MESSAGE("DENIED\n"));

}

13

Credentials API – libcreds


1. Process 1 sends a message to Process 2 through daemon

2. Daemon retrieves the credential required to access Process 2 from the D-Bus configuration policy

3. Daemon checks if process 1 possesses the required credential

4. The D-Bus daemon decides whether Process 1 may send the message to Process 2

14

Runtime Example 1: D-Bus Access Control

D-Bus Configuration

Policy

Process 1

D-Bus Daemon

Credential to Access Process 2

Process 1 Credentials

MSSF component

Standard Linux component

Process 2

1

2 3

4

Libcreds Library


1. Client request service

2. Server checks if interface called requires a credential

3. Server uses libcreds to resolve client credentials

4. Server makes an access control decision on the interface

15

Runtime Example 2: Access Control done by the application

Application Server

Process 1 Credentials

13

Libcreds Library

Application 1 Client

MSSF component

Standard Linux component


Three kernel modules

Restok

Provides mapping between resource token string and corresponding supplementary group id

Gets input from 'aegis-loader' during boot

Three main functions

restok_locate – string to id

restok_string – id to string

restok_define – adds new token string, returns assigned value

Assignments are permanent for given boot and cannot be modified

Token manipulation is guarded by token assigned in module init, RESTOK_RESOURCE_MANAGER ("tcb"). Rest of the tokens are user assignable.

Exports /sys/kernel/security/restok/tokens for listing current token assignment

Userspace API via librestok

16



Credp

Stores the mapping between software source or binary and its given credential set

Input from 'aegis-loader' during boot

Evaluates currently assignable credential set for given task

Performs credential assignment during exec

Creds

Provides interface for fetching process credentials based on pid or full path

creds_khave_p for checking currently owned credential set

Userspace API via libcreds

17



MSSF Access Control

Our advantages here

Public project “MeeGo Platform Security” http://meego.gitorious.org/

Open wiki in the project http://meego.gitorious.org/meego-platform-security/pages/Home

Your questions, feedback and reports are welcomed! http://wiki.maemo.org/MaemoSecurity http://talk.maemo.org/forumdisplay.php?f=45 https://bugs.maemo.org/

18

Conclusions and Q&A

[email protected]

http://meego.gitorious.org/

http://meego.gitorious.org/meego-platform-security/pages/Home





http://wiki.maemo.org/MaemoSecurity

http://talk.maemo.org/forumdisplay.php?f=45

https://bugs.maemo.org/

mssf access control overview - selinux...

Documents