1. SubDomain: Parsimonious Server Security Presenter: Alptekin Küpçü

2. Overview  Problem Definition  Problematic Examples  Previous Approaches  SubDomain Approach  Related Work  Summing Up  Discussion

3. Problem Definition  Why do we need server security? Easier to attack than SSL Easier to attack than SSL  Why is it hard? Every piece of software must be secure Every piece of software must be secure  What should a solution look like? Small implementation: Likely to be bug-free Small implementation: Likely to be bug-free Simple operation: Less likely to misconfigure Simple operation: Less likely to misconfigure Fine-grained control Fine-grained control High performance and compatibility High performance and compatibility

4. Problematic Examples  Cause: “trusted” programs runs with privilidge runs with privilidge has a bug that attacker can take advantage has a bug that attacker can take advantage  BIND DNS Server & Microsoft IIS Server Gaining administrative privilidges Gaining administrative privilidges  Common bugs Buffer overflows Buffer overflows Race conditions Race conditions Special character processing Special character processing

5. Solution  Safety properties on integrity Not information flow issues Not information flow issues  Principle of least privilidge Minimizes possible damage Minimizes possible damage  Previous approaches Minimizing user/role privilidges Minimizing user/role privilidges setuid with synthetic users setuid with synthetic users Hard to do in practice Hard to do in practice needs too much administrative workneeds too much administrative work

6. SubDomain  Admin specifies “domains” for programs Not for users Not for users Domain is a list of files and operations Domain is a list of files and operations  Restrictive Like Linux Security Modules Like Linux Security Modules Using SubDomain is guaranteed to be safer Using SubDomain is guaranteed to be safer  syscalls Return error if not enough privilidges Return error if not enough privilidges Log attempts to use in intrusion detection Log attempts to use in intrusion detection

7. SubDomain Details  Child process Can inherit parent’s rights Can inherit parent’s rights Possibly with some extra or less rightsPossibly with some extra or less rights Can have completely unrelated rights Can have completely unrelated rights  Finer-grain Plug-ins, loadable modules or scripts Plug-ins, loadable modules or scripts Processes must cooperate with SubDomain Processes must cooperate with SubDomain by using “hat”sby using “hat”s  Hat Must be changed before calling sub-component Must be changed before calling sub-component Must not be changed in the sub-component Must not be changed in the sub-component Use random identifiers for hatsUse random identifiers for hats Sub-component should not be able to read process memorySub-component should not be able to read process memory

8. SubDomain Implementation  Kernel module  No change needed on programs Unless sub-component security is desired Unless sub-component security is desired  SubDomain profile can come with package Always safe to install Always safe to install Easy to understand Easy to understand But profile creation must be manual But profile creation must be manual Start with no privilidgesStart with no privilidges If source code not available, play with the application and populate the profileIf source code not available, play with the application and populate the profile Need to be done for all possible inputs Need to be done for all possible inputs Should be manually rechecked Should be manually rechecked Not too complex in practice Not too complex in practice

9. Differences from Related Work  System-wide program profiles Like Mandatory Access Control Like Mandatory Access Control  Finer-grained Sub-components Sub-components  Compatible Not language based Not language based  Always safe to install Can come pre-packaged Can come pre-packaged  Little performance overhead  Small and simple 4500 lines of kernel patch 4500 lines of kernel patch

10. Some Related Work  Program-based Access Control Lists Dual of SubDomain Dual of SubDomain Each file has a list of programs that are granted accessEach file has a list of programs that are granted access  chroot Escapable Escapable Storage and performance overhead Storage and performance overhead

11. Summing Up  Least privilidge on programs More intuitive for server systems More intuitive for server systems Easy to understand and create a profile Easy to understand and create a profile Apache profile size: 33 linesApache profile size: 33 lines Profile packaged with programs Profile packaged with programs Finer-grained Finer-grained

12. Discussion  Easy to specify and use But still needs non-trivial administration But still needs non-trivial administration  Not enough evaluation 5 to 10 clients for a server? 5 to 10 clients for a server?  Too much “trust” is still there Is using sub-components really secure? 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