security in-depth for linux softwareintroduction privileges in linux writing good code sandbox...
Post on 31-May-2020
5 Views
Preview:
TRANSCRIPT
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Security In-Depth for Linux SoftwarePreventing and Mitigating Security Bugs
Julien Tinnes Chris Evans
Google Inc.
October 2009 / HITB Malaysia
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Goals of this Talk
1 How to implement security in depth andthe least privilege principle in your Linux code
2 Explain designs of sandboxing techniques on Linux3 Good code writing and design practices can work
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
What is Security in Depth?
A secure application should have tolerance for mistakesA single failure should not completely break the securitymodel
Today, we will try to address this from a Linux applicationprogrammer perspectiveUsing Chromium and vsftpd as examples
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Steps to Security in Depth
1 Secure code: reduce number of mistakes2 Application-level exploitation mitigation (SSP, relro. . . )3 System-level exploit mitigation (ASLR, NX)4 Privilege dropping (Sandboxing)5 Mandatory access control6 Update strategy
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Steps to Security in Depth
1 Secure code: reduce number of mistakes2 Application-level exploitation mitigation (SSP, relro. . . )3 System-level exploit mitigation (ASLR, NX)4 Privilege dropping (Sandboxing)5 Mandatory access control6 Update strategy
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
The Privilege Model of UnixIn a Nutshell. . .
Each process has its own address spaceMMU enforces separation of address spaces
The kernel is a mandatory interface to the systemThe process is the privilege boundary
root has access to everythingother users are subject to discretionary access control
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Privileges Ordering in the General Case
DefinitionProcess A has more privileges than process Bif A has access to every resource B has access to
Any process running as root is more privilegedthan any other processTwo processes with the same uid and gidmay have the same privilegeOne can generally not compare two processeswith different uids
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Processes and Privilege Separation
ThreadsThere is no possible privilege separation inside a process(in the general case)Exception: NaCl, SECCOMP sandbox
Debugging
If A can ptrace() B, then A is more privileged than B
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Standard Linux Process Privileges
Users and groupsuid, euid, suid, fsuid
gid, egid, sgid, fsgid and supplementary groups
POSIX.1e capabilitiesDesigned as a way to split root privilegesIntroduced in Linux 2.2
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
uid, effective uid, saved uid and filesystem uid
Definition (Confused Deputy)A computer program that is innocently fooled to use its ambientauthority
Partial UID switching is mostly useful to avoidconfused deputy problemsIt’s useless in case of arbitrary code execution,where the attacker has full control of the applicationOnly root can use this facility
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Linux Capabilities
Linux divides root privileges into distinct units
ExamplesCAP_NET_RAW: Permit use of RAW and PACKET socketsCAP_SYS_ADMIN: Administrative operations(mount(), sethostname(), etc. . . )CAP_NET_BIND_SERVICE: Binding to reserved ports(< 1024)
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Capabilities Limitation
Common Mistakes1 Forgetting to switch from uid 02 A lot of capabilities are root equivalent
Useful for confused deputy problems
Root onlyCapabilities are a root privilege dropping facilityUseless to further restrict a normal user’s privileges
Normal users can do a lot
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Changing Root
Using chroot()
A popular way to drop filesystem accessHow else do you drop access to o+r files?Only available to root
Requires dropping privileges afterwards, or easy to escape:
Popular re-chroot() techniqueInject modules, ptrace() non chroot-ed process, etc. . .Look at capabilities for inspirations
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Changing Root
Using chroot()
A popular way to drop filesystem accessHow else do you drop access to o+r files?Only available to root
Requires dropping privileges afterwards, or easy to escape:
Popular re-chroot() techniqueInject modules, ptrace() non chroot-ed process, etc. . .Look at capabilities for inspirations
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
New namespaces: CLONE_NEW*Courtesy of Linux Containers (LXC)
Recent kernels introduced new clone()/unshare() flags
CLONE_NEWPID: new pid namespace (2.6.24)CLONE_NEWNET: new network namespace (2.6.26)CLONE_NEWIPC, CLONE_NEWUTS, CLONE_NEWNS(2.6.19)
Interesting ways to drop privileges, but only accessible by root
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Resource Limitsrlimits
Resource limits can be used for securityRLIMIT_NOFILE: can’t get new file descriptors.But can still rename() and unlink()
RLIMIT_NPROC: can’t create new processes
If used for security, soft and hard limit need to be set tozeroOr attacker could replace an existing fd to create newsockets/access new files
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Dumpable (Debuggable) Process
Linux supports a per process dumpable flag
Can be set through prctl with PR_SET_DUMPABLE
Or when executing a file you don’t own and can’t readOr when switching uid
A process without CAP_SYS_PTRACE cannot ptracea non dumpable processTherefore it’s an elevation of privilegesBut it allows to lower another process’ privileges
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Mandatory Access Control (MAC)
Linux has several MAC optionsIn the Kernel, LSM-based: SELinux, SMACK, TOMOYOOutside: GRSecurity, RSBAC, AppArmor (not for long?). . .
Offers some flexibility and lots of optionsBut, they require the administrator to set-up a policy
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Process and PrivilegesPrivilege-related Facilities
Conclusion on Privilege-related Facilities
Most of them are designed to give less privileges to rootThose which don’t still require rootEasy to protect against confused deputy problems but notagainst arbitrary code execution
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Mostly a solved problem...
General principleUse APIs that are harder to abuse than use correctly
Strings: use a C++-like buffer encapsulation (even in C)Auth: tiny API, all code in one placeMust be readable
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Easy to Abuse API: OpenSSL
OpenSSL API modeled after UNIX API
i n t SSL_read (SSL ∗ ss l , vo id ∗buf , i n t num ) ;
What does it mean if that returned "0" ?
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Hard to Read Code
for (p = old_prompt ,len = strlen (old_prompt ) ;∗p ; p++) {
if (p [ 0 ] ==’%’ ) {switch (p [ 1 ] ) {
case ’h’ :p++;len += strlen (user_shost ) − 2;subst = 1;break ;
new_prompt = (char ∗) emalloc(++len ) ;endp = new_prompt + len ;for (p = old_prompt ,
np = new_prompt ; ∗p ; p++) {if (p [ 0 ] ==’%’ ) {
switch (p [ 1 ] ) {case ’h’ :
p++;n = strlcpy (np , user_shost ,
np − endp ) ;if (n >= np − endp )goto oflow ;
np += n ;continue ;
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
The use of Multiple Processes
Use one process per "privilege level"Use different UIDsEach process should run with the minimum privilege itneedsHave a simple message protocol and transport betweenprocesses
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Vsftpd
Pre-vsftpd: anonymous⇒ root
vsftpd scenarioNo anonymous accessLogins to real accounts over SSL
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
vsftpd: pre-authentication
vsftpd: unauthenticated
user +password
FTP parsingSSL handshake
nobodyroot
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
vsftpd: post-authentication
vsftpd: authenticated
get socket FTP parsingMore SSL handshakeFile / network I/OLots of FTP commands
changeupload owner chris
nobody+ caps
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
The Messages Between Multiple Processes
A higher privileged process must distrust requests from alower privileged processBad messages could simply be garbledOr bad messages could be syntactically valid but claim evilthings
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
CompromisedFTP process
(user: nobody; chroot: /empty)
Filesystemaccess
Processattach Attack
kernel API
Hack internalnetwork
Steal / corruptIPC segments
Signal / killFTP processes
Boring DoSattacks
Steal privatekey
Abuseprivilegedchannel
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
CompromisedFTP process
(user: nobody; chroot: /empty)
Filesystemaccess
Processattach Attack
kernel API
Hack internalnetwork
Steal / corruptIPC segments
Signal / killFTP processes
Boring DoSattacks
Steal privatekey
Abuseprivilegedchannel
vsftpd v2.0
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
CompromisedFTP process
(user: nobody; chroot: /empty)
Filesystemaccess
Processattach Attack
kernel API
Hack internalnetwork
Steal / corruptIPC segments
Signal / killFTP processes
Boring DoSattacks
Steal privatekey
Abuseprivilegedchannel
?
vsftpd v2.2 (default)
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
More Subtle Trust Examples From Chromium andvsftpd
ChromiumUploading local filesystem files to a web siteCausing memory corruption in the privileged browser viaaudio-related integer overflowsRenderer crash and extracting a stack trace
vsftpdSleeping after failed login
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Preventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
Secure software and patching
Remember!Any large piece of software will have security bugs
Secure design is an important vulnerability mitigationGetting fixes to users fast is often overlooked
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Sandboxing
Sandboxing (in this talk)The ability to restrict a process’ privileges:
ProgrammacticallyWithout administrative authority on the machineDiscretionary privilege dropping
Administrative AuthorityBeing in charge of administrating the machine (or Linuxdistribution)One still can do sandboxing as a root process
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Mandatory Access Control vs. Sandboxing
Mandatory Access ControlFor administrators and distribution maintainersOne policy to rule over many programsWithout the need for control over the code
Sandboxing
For software developersOne code that works on many machinesWithout the need to administer the machines
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Threat Model of Sandboxing
Here, we assume arbitrary code execution inside thesandboxed process
The attacker fully controls the sandboxed processDropping privileges is useless if it’s revertible
We only care marginally about confused deputy problems
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Sandbox Designs
There are very few facilities to write sandboxesin the kernelMost of the one we’ve presented are only available to rootAdding new facilities to the kernel is not a short term option
We will present three designs, used in vsftpd and Chromium
ptrace() sandbox (vsftpd experiment)setuid sandboxSECCOMP sandbox
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
ptrace() Sandboxing
ptrace() sandboxing
supervisedsupervisor
kernel
syscall enter
syscall exit
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
ptrace() Sandboxing: pros
Tightly restricts kernel API, lowers attack surfaceHigh granularity of access control possibleCan be used securely, despite widely-cited race conditionsCode relatively simple (but not trivial)
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
ptrace() Sandboxing: cons
Very buggy area of kernelLots of pitfallsPerformance degradationHighly sensitive to exact kernel and glibc version andarchitecture
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
ptrace() Sandboxing: pitfalls
Race conditions: don’t allow threads (or shared memory!)Or don’t gate access control on pointer-based argumentsSIGKILL vs. the supervisor or the supervisee64-bit vs. 32-bit syscallsDesynchronizing the supervisorProbably best avoided
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Setuid Sandbox(Julien Tinnes, Tavis Ormandy)
root seemed hard to avoidNeed to drop access to the filesystemRLIMIT_NOFILE is not enough (unlink(), rename())Preventing ptrace() on other processesPrevent sending signals to other processes
Switching uid and gid would mostly solve thisWe designed a setuid sandbox
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Setuid Sandbox(Julien Tinnes, Tavis Ormandy)
root seemed hard to avoidNeed to drop access to the filesystemRLIMIT_NOFILE is not enough (unlink(), rename())Preventing ptrace() on other processesPrevent sending signals to other processes
Switching uid and gid would mostly solve thisWe designed a setuid sandbox
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Setuid Sandbox
UID switching
We require an administratively defined pool of UIDs/GIDsNo need for /etc/passwd entriesOn invocation, search for unused UID/GIDSwitch to themExecute program to sandbox
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Setuid Sandbox
How to do this statelessly ?Choose random UID/GID in the poolUse RLIMIT_NPROC to make setuid() fail if uid isalready usedIf it fails, repeat until pool is exhausted
Preventing a user from exhausting the poolIdeal: Partition the pool among UIDsTrade-off: Partition the pool against hashes of UIDs
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Setuid Sandbox
How to do this statelessly ?Choose random UID/GID in the poolUse RLIMIT_NPROC to make setuid() fail if uid isalready usedIf it fails, repeat until pool is exhausted
Preventing a user from exhausting the poolIdeal: Partition the pool among UIDsTrade-off: Partition the pool against hashes of UIDs
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
The Need for chroot()
Uid switching leaves a lot exposed/tmp races exploitationsetuid binary execution(also matters for kernel vulnerabilities exploitation)
Could we also get chroot()-ed ?
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
A Setuid Sandbox, chroot() and execve()
Problem: how do I execve() after I chroot?1 chroot() to an empty directory2 drop privileges (switch uid/gid)3 execve() target
No go
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
A Setuid Sandbox, chroot() and execve()
Problem: how do I execve() after I chroot?1 chroot() to an empty directory2 drop privileges (switch uid/gid)3 execve() target
No go
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Solving the chroot() Problem
NaiveGive CAP_SYS_CHROOTThat’s giving instant root to anyone
RealisticDon’t go through execve, drop privileges and mmap() codeNot convenient. And dangerous (hello pulseaudio)
OptimisticLet’s give a process the privilege to chroot() to an emptydirectoryCan we do that?
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Giving a Process the Ability to Change Root
Sharing the process’ FS structure
Our sandbox (process A) spawns a new process BWe use clone, with CLONE_FS so that A and Bshare their root directory, CWD, etc. . .A drop privileges, B waits for a special message from AWhen A wants to chroot(), it send a messageB chroot() to an empty directory, which also affects A
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
CLONE_FS Security Implications
A root process B shares its FS with untrusted process AThat’s very scaryOur deputy is under untrusted process influenceDrugged deputy problem ?
Mitigations (in case something goes wrong)
B can drop capabilities (but CAP_SYS_CHROOT)And set RLIMIT_NOFILE to 0,0Dropping capabilities is mostly usefulto make RLIMIT_NOFILE effective
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
CLONE_FS Security Implications
A root process B shares its FS with untrusted process AThat’s very scaryOur deputy is under untrusted process influenceDrugged deputy problem ?
Mitigations (in case something goes wrong)
B can drop capabilities (but CAP_SYS_CHROOT)And set RLIMIT_NOFILE to 0,0Dropping capabilities is mostly usefulto make RLIMIT_NOFILE effective
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Now that we Can Drop Filesystem Access. . .
Can we drop the need for the UID/GID pool range?
Not changing UID and switching to a single, common GID
Would prevent ptrace() from a sandboxed process toanother processPR_SET_DUMPABLE to prevent ptrace() amongsandboxed processWhat about signals?
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Now that we Can Drop Filesystem Access. . .
Can we drop the need for the UID/GID pool range?
Using a new PID namespace (CLONE_NEWPID) (2.6.24)
Solves many problemsOpen question: how secure is it?
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Dropping Network Access
We can use RLIMIT_NOFILEWhat if we require new descriptors (for files)?We can share our file descriptors (CLONE_FILES) with abroker process
Using CLONE_NEWNET (2.6.24+)
Can be used to cut access to the network completely
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Dropping Network Access
We can use RLIMIT_NOFILEWhat if we require new descriptors (for files)?We can share our file descriptors (CLONE_FILES) with abroker process
Using CLONE_NEWNET (2.6.24+)
Can be used to cut access to the network completely
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Setuid Sandbox: Conclusion
Chromium has been adapted to work with this sandbox(the renderer is sandboxed)We have a fully-featured version and aChromium-dedicated versionChromium’s version uses the CLONE_FS trick andCLONE_NEWPIDThe setuid sandbox is the first-level sandbox in Chromium
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP sandbox(Markus Gutschke, Adam Langley)
Secure Computing modeHas been introduced in Linux 2.6.10A thread under SECCOMP can use limited system calls
read()write()exit()sigreturn()
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP’s limitation
Design
Seccomp was designed with pure computing in mindThe "4 system calls allowed" design is simple
Too limited for a browser rendererNo memory allocations (mmap(), brk())No ability to get new file descriptors (recvmsg())
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP sandbox design
Trusted thread (TT)For each thread under seccomp, we have a trusted helperthreadUT asks TT to perform system calls on its behalfTT validates and eventually performs themEven memory allocations will work
Trusted/untrusted code sharing AS ?The trusted code needs to be in RX only memoryThe trusted code can’t access any volatile memory
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP sandbox design
Trusted thread (TT)For each thread under seccomp, we have a trusted helperthreadUT asks TT to perform system calls on its behalfTT validates and eventually performs themEven memory allocations will work
Trusted/untrusted code sharing AS ?The trusted code needs to be in RX only memoryThe trusted code can’t access any volatile memory
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP Trusted and Untrusted Threads
Thread 2(seccomp)
Thread 1
Uses RX mappings
syscallrequest
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP sandbox difficulties
No volatile memory constraintThe code has to be written in pure assemblyThe code can’t use a stack
But we need volatile memoryMany system calls pass pointers to memory (open())Evaluating complex system calls in pure assemblywould be very hard/impossible
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP sandbox: the trusted process
Something needs access to volatile memory
Complexities can be handled in a separate trusted processThe trusted process can use volatile memoryIt shares pages with the trusted threadAnd can write to them (the trusted thread can only read)
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
SECCOMP sandbox: conclusion
Has high potential to isolate the kernelStill work in progressHas still performance issuesNot yet enabled by default
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Relying on a MAC
Creating a generic sandbox by relying on a MAC
Possible if you have some control over the policyExample: SELinux Sandbox
Possible to drop privileges during execution ?
SELinux supports dynamic transitions
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Privilege dropping facilities in the Linux kernel
We have to juggle, due to the lack of discretionary privilegedropping facilities
Recent effortsLSMSBSELinux type boundariesftrace framework ?
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Virtualisation
Lots of people use virtualisation to separate privilegesBy doing that, they are trying to revert to a known problem:physical machines separation. Of course it’s not the case.It stil offers the advantage over MAC that it doesn’t exposethe Linux kernel
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Outline
1 Privileges in LinuxProcess and PrivilegesPrivilege-related Facilities
2 Writing Good CodePreventing Common Security FlawsPrivilege SeparationTrust RelationshipsUpdate Strategy
3 Sandbox designsSandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Sandboxes attack surfaces
Different sandboxes expose different attack surfacesptrace() / ftrace sandboxsetuid sandboxSECCOMP sandbox
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Trusted Path Executable
Can TPE protect the kernel?TPE usually works by limiting loading native codethrough execve() / PROT_EXEC mmap()
Different paradigm
With TPE, vulnerabilities in GNU make or CSHbecome interestingVarious interpreters can give you enough control withoutthe need for native code execution
Recent demo by dpunk using foreign function interface
J. Tinnes, C. Evans Security In-Depth for Linux Software
IntroductionPrivileges in Linux
Writing Good CodeSandbox designs
Sandboxing Definitionptrace(), setuid and SECCOMP sandboxesOther approachesAttack surface evaluation
Conclusion
Security in depth is importantLinux has no real sandboxing facilitiesIt’s difficult, but possible to write sandboxeson current Linux kernels
Worth it for some software
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Containing root
Process running as root can be containedFirst requirement is to prevent root -> kernel escalation:
modules injectionAccess to /dev/mem, /dev/kmemRaw I/O
Can also have some use outside of Mandatory Access Control
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities LimitationsThe need for uid switching
Don’t keep uid zero!Even if you drop capabilities, you generally need to changeyour uid
For compatibility reasons, capability model coexists withuid = 0⇒ all_capabilitiesOn any execve with uid=0 or euid=0 you will be granted allcapabilitiesOr you can create a root setuid executable and run it
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities: securebits
Starting with Linux 2.6.26 the kernel supports securebitsAllows to drop the backward compatibility of capabilitieswith the old modelSECURE_NOROOT and SECURE_NO_SETUID_FIXUP
You still need to drop uid 0Attacker might get a shell without securebitsAttacker can still backdoor a program executed withdifferent privileges
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities: securebits
Starting with Linux 2.6.26 the kernel supports securebitsAllows to drop the backward compatibility of capabilitieswith the old modelSECURE_NOROOT and SECURE_NO_SETUID_FIXUP
You still need to drop uid 0Attacker might get a shell without securebitsAttacker can still backdoor a program executed withdifferent privileges
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities LimitationsEquivalence to root
Root equivalenceMany capabilities are actually equivalent to root
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities LimitationsEquivalence to root
Root equivalenceMany capabilities are actually equivalent to root
CAP_SYS_MODULE, CAP_SYS_RAWIO, CAP_MKNODexecute kernel codeor communicate directly with devices
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities LimitationsEquivalence to root
Root equivalenceMany capabilities are actually equivalent to root
CAP_SYS_PTRACEIf you can ptrace() any process,you can ptrace a process with all capabilities.As explained before: if A can ptrace() B,A is more privileged than B
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities LimitationsEquivalence to root
Root equivalenceMany capabilities are actually equivalent to root
CAP_CHOWN1 Change ownership of /etc/passswd2 Modify it
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities LimitationsEquivalence to root
Root equivalenceMany capabilities are actually equivalent to root
CAP_CHROOT1 Create a working chroot environment2 Backdoor ld.so or libc3 hardlink a setuid binary inside the chroot environment4 chroot, launch setuid binary
J. Tinnes, C. Evans Security In-Depth for Linux Software
Appendix
Linux Capabilities: conclusion
Capabilities are still not widely usedThey can avoid confused deputy problemsBut are hard to use effectively in case ofarbitrary code executionIt’s not necessarily trivial to know which ones arefull-privileges equivalent
And they are only a root privileges reduction mechanism
J. Tinnes, C. Evans Security In-Depth for Linux Software
top related