ohm2013_trojans_slid.. - Defeating Trojans @ OHM2013

celerymoldwarpSecurity

Dec 3, 2013 (4 years and 28 days ago)

110 views



Defeating Trojans
Retrofitting shared mutable state for file-systems
Rob Meijer (
ohm2013@capibara.com

)


Lets get some facts straight


Lets get some facts straight

The
user
is
NOT
the weakest link
!


Lets get some facts straight

The
user
is
NOT
the weakest link
!

Sharing
security tokens is
NOT
stupid

!


Lets get some facts straight

The
user
is
NOT
the weakest link
!

Sharing
security tokens is
NOT
stupid

!

Security and
usability
are
NOT
mutually
exclusive.


Lets get some facts straight

The
user
is
NOT
the weakest link
!

Sharing
security tokens is
NOT
stupid

!


Security and
usability
are
NOT
mutually
exclusive.

MOST
software vulnerabilities are
irrelevant.


Delegation

Users are 'programmed' to handle delegation.

Delegation != Abdication

Delegate 'authority' NOT 'identity'

Authority
must
be decomposable.

Authority
should
be attenuable.

Authority
could
be revocable.


Weak links

The user


Weak links

The user

Disregard for socio-genetic security-awareness


Conditioning


Conditioning


Passwords suck

Identity

Delegatable

Non decomposable

Non attenuable

Authority:

Delegatable

Non-decomposable

Non-attenuable


Passwords suck
We
could
do with better user authentication.
But ...


Passwords suck
Identity is
massively
overused !


Passwords suck
We need better
authorization
more desperately
than we need better
authentication
.
>


Weak links

The user

Disregard for socio-genetic security-awareness


Weak links

The user

Disregard for socio-genetic security-awareness

Identity centric security models


Weak links

The user

Disregard for socio-genetic security-awareness

Identity centric security models

Single-granularity abstractions


Mutable state
Public
vs
private


Public/global mutable state

Makes composite systems hard to analyze or
review.

Makes composite systems hard to test.

High potential for violating the Principle of Least
Authority.

Giant hurdle for reducing trusted code-base size.


The file-system as global mutable state


The file-system as global mutable state


The file-system as global mutable state

Why does Sokoban
need access to
$HOME?


The file-system as global mutable state

Why does Sokoban
need access to
$HOME?


The file-system as global mutable state

Why does Sokoban
need access to
$HOME?

Why does Bitcoin
need
to store
sensitive data in
$HOME?


The file-system as global mutable state

Why does Sokoban
need access to
$HOME?

Why does Bitcoin
need
to store
sensitive data in
$HOME?

Why is Sokoban
part
of
Bitcoin's trusted
code-base?


The file-system as global mutable state

Why does Sokoban
need access to
$HOME?

Why does Bitcoin
need
to store
sensitive data in
$HOME?

Why is Sokoban
part
of
Bitcoin's trusted
code-base?

Programs need
privacy too!


Weak links

The user

Disregard for socio-genetic security-awareness

Identity centric security models

Single-granularity abstractions


Weak links

The user

Disregard for socio-genetic security-awareness

Identity centric security models

Single-granularity abstractions

Public/global mutable state


Weak links

The user

Disregard for socio-genetic security-awareness

Identity centric security models

Single-granularity abstractions

Public/global mutable state

Massive size of trusted code-base


Weakest link?

The user

Disregard for socio-genetic security-awareness

Identity centric security models

Single-granularity abstractions

Public/global mutable state

Massive size of trusted code-base


Weakest link?

The user

Disregard for socio-genetic security-awareness

Identity centric security models

Single-granularity abstractions

Public/global mutable state

Massive size of trusted code-base


Basic guidelines

Use
homo-sapiens friendly
security abstractions

Use
cross-granular
abstractions

Don't overuse
identity

Limit
public/global mutable
state

Share
authority tokens

Decompose
and/or
attenuate
authority

Use the
Principle Of Least Authority
.

Minimize the
trusted
code-base


Capabilities

Authority-only security tokens (no identity)

Capabilities both designate and authorize

In fact: designation IS authorization

Cap patterns ∩ Social patterns = significant

Dynamic least authority.


Sparse capabilities

Capability 'as data'.

Basically a strong password
without
an identity

Some well known examples

Rumpelstiltskin

https://docs.google.com/file/d/
0B_sqxoHXGz5ZcEhCOMJWRzRjbmM
/edit

CapFS:

/minorfs/cap/
rw-5BA7FFDP4HM1L887BZAK7G857GKJHAUEAK992HCH5DGH59GHWB1S

Non human-memorable 'authority' token


Object capabilities

More secure than sparse capabilities

Basically object-reference as capability

Ambient-authority and static-mutable-state free
subset of Object Oriented Design principles.


Process-Persistence

Transparent serialization for conceptually
persistent processes.

Delegated authority survives reboots.

E-Language

Combines Persistent VATs with object capabilities.

Ken

Crash-restart resilience for distributed applications.

Where do we securely store process
serialization?


Security Policy


MAC & (extreme) DAC

Classic UNIX DAC and MAC are a bad fit.

SELinux MAC and sparse-cap DAC are a bad fit.

AppArmor: Permissive-privileges MAC model.

AppArmor MAC and sparse-cap DAC are
complementary.


AppArmor

Security module (MAC) for Linux kernel.

No MSc required for profile management.

Simple permissive-privileges

Restricting
'possibly vulnerable'
software.


Global mutable state
/ r,
/bin/ r,
/bin/** mixr,
/usr/ r,
/usr/bin r,
/usr/bin/* mixr,
/usr/local/ r,
/usr/local/* r,
/usr/local/bin/* mixr,
/usr/local/*/bin/* mixr,
/usr/** r,
/etc/ r,
/etc/** r,
/lib/ r,
/lib/** r,
@{HOME}/ r,
@{HOME}/** rw,



AppArmor
Bridging the gap
Capabilities
MinorFs
$HOME


Disable global mutable state
/ r,
/bin/ r,
/bin/** mixr,
/usr/ r,
/usr/bin r,
/usr/bin/* mixr,
/usr/local/ r,
/usr/local/* r,
/usr/local/bin/* mixr,
/usr/local/*/bin/* mixr,
/usr/** r,
/etc/ r,
/etc/** r,
/lib/ r,
/lib/** r,
@{HOME} r,
@{HOME}/**
r,



Public to private
/ r,
/bin/ r,
/bin/** mixr,
/usr/ r,
/usr/bin r,
/usr/bin/* mixr,
/usr/local/ r,
/usr/local/* r,
/usr/local/bin/* mixr,
/usr/local/*/bin/* mixr,
/usr/** r,
/etc/ r,
/etc/** r,
/lib/ r,
/lib/** r,
@{HOME} r,
@{HOME}/** r,
/minorfs/** r,
/minorfs/cap
rw,



MinorFS & E

MinorFS+AppArmor:

Pseudo-persistent-process private $HOME

Reduces trusted code-base for private persistent
mutable state.

E-Language:

Uses protected private process serialization

Further reduces the trusted code-base


MinorFS and native code

C++

No memory safety


No trusted-code-base reduction


Reduced memory integrity

Native →
Easy PP-PID calculation for MinorFS

RAII →
Non-memory resource management integrity

Templates →
Generics as code-base reduction tool.

Multi-process programs

Use processes as overweight object

Delegate attenuated sub-trees between processes


'..' considered evil

Special '..' directory normally designates parent

Capabilities: designation implies authorization

The '..' brakes delegation of sub-trees.


CapFs and '..'

/minorfs/cap/

Dead-end stub '..' for any CapFS node

Listing returns an empty directory.


MinorFS (1) shortcommings

Poor fit for desktop/console applications.

Poor fit for most retrofitting purposes.

No read-only attenuation

Poor scalability and performance

Tricky installation dependencies


MinorFS
2
: goals and use-cases

Defeating Trojans: retrofitting tamed mutable state

Standard dependencies (Ubuntu/Suse)

Confidentiality on shared network storage

Scalability and performance

Read-only attenuation

Convenient GranFS/CapFS APIs

NodeKen like server platforms

Multi-process browsers

Bitcoin like systems


MinorFS2: performance & scalability

AES256 encrypted overlay

Yet : sparse == sparse

Sqlite based lookups → digest-only lookups

Client side attenuation.

Perl → C++


CapFS2: Rumpelstiltskin tree-graph

HMAC/SHA256 operation based

Client
or
server side read-only attenuation:

ROcap
= H(“#ro”,
RWcap
)

Server side decomposition:

childRWcap
= H(
childname
+ H(“#ro”,
parentRWcap
),
secret
)

ChildROcap
= H(“#ro”,H(
childname
+
parentROcap
,
secret
))

ROcap doubles as file encryption key:

FEK = ROcap

Path on underlying file-system derived from FEK:

Path = H(“#store”,FEK)



MinorFs-2: retrofitting

Other programs need
privacy too:

Non privsep

Non ocap

Non MinorFs-aware

Cross-platform


The '.program' convention

Convention to create a '.program' file or directory
in the users $HOME directory.

Base assumption:

'.' prefixed content in $HOME assumed user+program
private

Other $HOME content assumed user-global.

HomeFS2:

/minorfs/home shows merge-transform of multiple
granularity levels

Default use of the '.' prefix split

Config may define different mappings.


MinorFs2: layered design

CapFs2:

Encrypting sparse-friendly sparse-capability file-system.

TmpFs2:

Delegates process-lifetime CapFs dir to non-persistent process.

GranFs:

Multi-level process property registration.

Delegates different persistent CapFs dirs using process properties.

HomeFs2

Creates home like view with links to GranFs delegations and $HOME


LibMinorFs2 (C/C++)

Allowing simpler MinorFs awareness.

Stub implementations non AppArmor systems.

Query available privacy process property sets.

Multi-level process-property registration.

Process property set → CapFs object.

Directory traversal/decomposition/attenuation
abstractions.


Roadmap

Complete MinorFs 2.0 before the spring 2014
AppArmor feature-freeze

Any help here is extremely welcome !

Get MinorFs 2.0 accepted in AppArmor

Complete MinorFS 2.1:

More process properties for GranFS

LibMinorFS

Get projects to include LibMinorFs usage:

The Dr-SES stack

BitCoin

Chrome/chromium


Embrace delegation
http://ohm2013.capibara.com/
ohm2013@capibara.com