Alp

guideflannelServers

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

92 views

SubDomain: Parsimonious
Server Security


Presenter:

Alptekin Küpçü

Overview


Problem Definition


Problematic Examples


Previous Approaches


SubDomain Approach


Related Work


Summing Up


Discussion

Problem Definition


Why do we need server security?


Easier to attack than SSL


Why is it hard?


Every piece of software must be secure


What should a solution look like?


Small implementation: Likely to be bug
-
free


Simple operation: Less likely to misconfigure


Fine
-
grained control


High performance and compatibility

Problematic Examples


Cause: “trusted” programs


runs with privilidge


has a bug that attacker can take advantage


BIND DNS Server & Microsoft IIS Server


Gaining administrative privilidges


Common bugs


Buffer overflows


Race conditions


Special character processing

Solution


Safety properties on integrity


Not information flow issues


Principle of least privilidge


Minimizes possible damage


Previous approaches


Minimizing user/role privilidges


setuid with synthetic users


Hard to do in practice


needs too much administrative work

SubDomain


Admin specifies “domains” for programs


Not for users


Domain is a list of files and operations


Restrictive


Like Linux Security Modules


Using SubDomain is
guaranteed

to be safer


syscalls


Return error if not enough privilidges


Log attempts to use in intrusion detection

SubDomain Details


Child process


Can inherit parent’s rights


Possibly with some extra or less rights


Can have completely unrelated rights


Finer
-
grain


Plug
-
ins, loadable modules or scripts


Processes must cooperate with SubDomain


by using “hat”s


Hat


Must be changed before calling sub
-
component


Must not be changed in the sub
-
component


Use random identifiers for hats


Sub
-
component should not be able to read process memory

SubDomain Implementation


Kernel module


No change needed on programs


Unless sub
-
component security is desired


SubDomain profile can come with package


Always safe to install


Easy to understand


But profile creation must be manual


Start with no privilidges


If source code not available, play with the application and
populate the profile


Need to be done for all possible inputs


Should be manually rechecked


Not too complex in practice

Differences from Related Work


System
-
wide program profiles


Like Mandatory Access Control


Finer
-
grained


Sub
-
components


Compatible


Not language based


Always safe to install


Can come pre
-
packaged


Little performance overhead


Small and simple


4500 lines of kernel patch

Some Related Work


Program
-
based Access Control Lists


Dual of SubDomain


Each file has a list of programs that are granted
access


chroot


Escapable


Storage and performance overhead

Summing Up


Least privilidge on programs


More intuitive for server systems


Easy to understand and create a profile


Apache profile size:
33

lines


Profile packaged with programs


Finer
-
grained

Discussion


Easy to specify and use


But still needs non
-
trivial administration


Not enough evaluation


5 to 10 clients for a server?


Too much “trust” is still there


Is using sub
-
components really secure?


Is this the level of security we want for our
servers?


Compare and combine with
chroot

or
ld_preload