Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Linux Security and How Web Browser Sandboxes Really Work (NDC Oslo 2017)

524 views

Published on

The Linux Security and Isolation APIs have become the basis of some of the most useful features server-side, providing the isolation required for efficient containers.
However, these APIs also form the basis of the Chromium Sandbox on Linux, and we will study them in that context. This is the sandbox used in the Vivaldi, Brave, Chrome and Opera browsers among others. The Chromium Sandbox has a very platform specific implementation, using the platform APIs available to construct it. In this talk we will describe the requirements of the Chromium Sandbox in detail and go through how the Linux implementation fulfills these requirements.

Published in: Technology
  • Be the first to comment

Linux Security and How Web Browser Sandboxes Really Work (NDC Oslo 2017)

  1. 1. @pati_gallardo
  2. 2. Linux Security and How Web Browser Sandboxes Really Work Patricia Aas NDC Oslo 2017 @pati_gallardo
  3. 3. Patricia Aas Programmer - mainly in C++ and Java Currently : Vivaldi Technologies Previously : Cisco Systems, Knowit, Opera Software Master in Computer Science Twitter : @pati_gallardo Will put up link to slides on Twitter/LinkedIn
  4. 4. Overview of the Browser The Linux Security APIs Available Building the Sandboxes Some Problems The Plan
  5. 5. The Chromium/Blink Browser Family @pati_gallardo
  6. 6. Konqueror Safari Chrome Brave Vivaldi Opera KHTML Webkit Blink KDE Apple Google
  7. 7. Using Operating System APIs To Implement Security Mechanisms Chromium Multi Process Architecture
  8. 8. Sandboxing External & Internal Threats ● System External Threat : Protect the system from the vulnerabilities in the browser ● System Internal Threat : Protect the browser from malware on the system @pati_gallardo @pati_gallardo
  9. 9. Executables & Processes Example Vivaldi @pati_gallardo
  10. 10. The Executable Files vivaldi The bash script wrapper, launches vivaldi-bin. Sets up environment. vivaldi-bin The browser binary vivaldi-sandbox A setuid binary, not in much use today @pati_gallardo
  11. 11. The Running Processes 1. Browser : vivaldi-bin 2. Zygote (Parent) : vivaldi-bin --type=zygote 3. Zygote (Child) : vivaldi-bin --type=zygote 4. Renderer (MANY) : vivaldi-bin --type=renderer 5. GPU (Parent) : vivaldi-bin --type=gpu-process 6. GPU Broker (Child) : vivaldi-bin --type=gpu-broker@pati_gallardo
  12. 12. The Startup Sequence And the Processes @pati_gallardo
  13. 13. “There is only one” @pati_gallardo
  14. 14. ONE executable : vivaldi-bin The First: Browser Process forks into: 1. The Zygote(s) which fork into The Renderers 2. The Gpu Process which forks a Gpu Broker
  15. 15. Browser Process 1 process : browser Main: BrowserMain Manages the other processes, the IPC, the windows, GUI and network Trusted @pati_gallardo
  16. 16. Zygote Processes 2 processes: zygote Main : ZygoteMain Spawns all of the renderer processes. Parent Zygote is an init reaper process. Has some sandboxing : “Trusted” @pati_gallardo
  17. 17. Renderer Processes Many processes : renderer Main : RendererMain One for each tab etc, holds web content. Spawned by the Zygote process. Has full sandboxing: Untrusted* *Does seccomp sandbox construction @pati_gallardo
  18. 18. GPU Processes 2 processes: gpu + gpu-broker Main : GpuMain Does all interfacing directly with the GPU diver. All graphics work is piped to them + HW decoding. Has some sandboxing : “Trusted” @pati_gallardo
  19. 19. One Binary BROWSER GPUZYGOTE GPUBROKERZYGOTE RENDERER FORKCLONE EXEC EXEC CLONE FORKFORK
  20. 20. There are more But we’ll leave it at that for now :) @pati_gallardo
  21. 21. The Tools @pati_gallardo
  22. 22. vivaldi://sandbox @pati_gallardo
  23. 23. Linux Security APIs Used For The Sandbox @pati_gallardo
  24. 24. Capabilities Namespaces Chroot Seccomp Process Resource Limits YAMA LSM APIs in Use On Desktop Linux
  25. 25. Capabilities (Zygote/Renderers) Limits what a process is privileged enough to do Api : capset @pati_gallardo
  26. 26. Namespaces (Zygotes/Renderers) Limits what a process can see Api : clone/unshare @pati_gallardo
  27. 27. Chroot (Zygotes/Renderers) Limits what a process can see of the filesystem Api : chroot @pati_gallardo
  28. 28. Seccomp (Renderers/GPU/Broker) Limits which syscalls a process can call and how these calls are handled Api : seccomp @pati_gallardo
  29. 29. Resource Limits (Renderers) Limits the access this process has to platform resources Api : setrlimit @pati_gallardo
  30. 30. YAMA LSM Limits the access that other process have to this process - especially ptracing Status is checked by reading : /proc/sys/kernel/yama/ptrace_scope @pati_gallardo
  31. 31. Other APIs in USe But not covered CGroups (ChromeOs) Setuid/Setgid (Legacy) Process Groups (Chromedriver)
  32. 32. Setuid/setgid (Legacy) Increases what a process is privileged enough to do, by using the privilege of the executables owner Api : set*uid / set*gid @pati_gallardo
  33. 33. CGroups (ChromeOS) Limits the resources available to a process. Used in ChromeOS - not covered here. /proc/<PID>/cgroup /proc/cgroups @pati_gallardo
  34. 34. Process Groups (Chromedriver) Can be used to treat a group of processes as one. Used with the ‘detach’ property of Chromedriver Api : setpgid @pati_gallardo
  35. 35. The Process of Sandbox Construction @pati_gallardo
  36. 36. Remember the Goal We are trying to execute an untrusted binary inside of a sandbox
  37. 37. Windows of Opportunity & Sandbox Construction @pati_gallardo
  38. 38. The Initial Sandbox @pati_gallardo
  39. 39. Windows of Opportunity BROWSER GPU seccomp ZYGOTE USER capset chroot GPUBROKER seccomp ZYGOTE SYS_ADMIN seccomp RENDERER capset rlimit PID NO_NEW_PRIVS USER/PID/NET NO_NEW_PRIVS FORKCLONE EXEC EXEC CLONE FORKFORK Done post-fork
  40. 40. Fork / Exec A typical start of a new process on Linux is a “fork/exec” “Forking” is creating a new process “Clone” is a type of fork which can restrict a process at creation “Exec” is executing a binary in a process @pati_gallardo
  41. 41. Windows of Opportunity: fork/exec 1. Before clone/fork 2. At clone 3. Before Exec 4. At startup (input : argv)
  42. 42. Windows of Opportunity : fork 1. Before Fork 2. After Fork
  43. 43. Initial Sandbox Construction This initial sandbox construction is done at startup when the Browser process creates the Gpu and Zygote processes. The most important part of the sandboxes created here are the Namespaces created for the Zygote process @pati_gallardo GPU + Zygote
  44. 44. Before Clone / Fork As a rule the child process will inherit the privileges and limitations of its parent. This is an opportunity to release anything you don’t want to pass on. Remember the whole memory of the parent is copied* including all state * Linux does copy on write @pati_gallardo All Processes
  45. 45. At Clone : Create NAmespaces Clone flags define the process* created and will create namespaces (NS) for it 1. Test which NS are available 2. Fail if not sufficient 3. Construct the biggest supported and applicable set Emulates fork with longjmp * Also used to create threads@pati_gallardo Zygote + Renderer
  46. 46. Namespaces in use CLONE_NEWUSER No privilege is needed to create a User NS, and in one we can create a PID NS without global privilege. CLONE_NEWPID Same PID number can represent different processes in different PID namespaces. One init (PID 1) process per PID NS CLONE_NEWNET Isolate a process from network@pati_gallardo Zygote + Renderer
  47. 47. Before Exec The process will be executed in the current process. Before Exec is the last chance to clean up before the executed binary takes over @pati_gallardo GPU + Zygote
  48. 48. Before Exec : Launch Options The process is prepared for the upcoming exec (possibilities) : 1. Fix the environment 2. Fix file descriptors 3. Fix signal handling 4. Set up process group 5. Maximize resource limits 6. Set PR_SET_NO_NEW_PRIVS 7. Change current dir 8. Select executable path 9. Setup command-line@pati_gallardo GPU + Zygote
  49. 49. Shrinking the Initial Sandbox @pati_gallardo
  50. 50. Shrinking the Sandbox BROWSER GPU seccomp ZYGOTE USER capset chroot GPUBROKER seccomp ZYGOTE SYS_ADMIN seccomp RENDERER capset rlimit PID NO_NEW_PRIVS USER/PID/NET NO_NEW_PRIVS FORKCLONE EXEC EXEC CLONE FORKFORK Done post-fork
  51. 51. PR_SET_NO_NEW_PRIVS prctl(PR_SET_NO_NEW_PRIVS) Preserved across fork, clone and execve “If no_new_privs is set, then operations that grant new privileges (i.e. execve) will either fail or not grant them. This affects suid/sgid, file capabilities, and LSMs.” /usr/include/linux/prctl.h @pati_gallardo All except Browser
  52. 52. Seccomp BPF Program Program written in an assembly-like language to filter system-calls. Runs in a simple VM in kernel space. All syscalls will be filtered by this program TSYNC : Once a Seccomp Program is installed it applies to all threads in a process @pati_gallardo Renderer + Gpu + Broker
  53. 53. Seccomp : BPF Policies BPF Program defined in a Policy Fundamentally a whitelist, allows a set of syscalls and has custom handling of others An extended Policy is then generally more permissive 1. BaselinePolicy 1.1 GpuProcessPolicy 1.1.1 GpuBrokerProcessPolicy 1.2 RendererProcessPolicy@pati_gallardo Renderer + Gpu + Broker
  54. 54. Unshare- User Namespace unshare(CLONE_NEWUSER) Alternative to clone(CLONE_NEWUSER), will not create new process, but move caller. Credentials::CanCreateProcessInNewUserNS @pati_gallardo Zygote Parent
  55. 55. Chroot : Drop Access to FS A chroot is done in a clone(CLONE_FS) child that does chroot(”/proc/self/fdinfo/”) and immediately does a chdir(“/”) and _exit(0) You can see this by looking at ls -l /proc/<pid>/root Of the Zygote or any ancestor Credentials::DropFileSystemAccess @pati_gallardo Zygotes + Renderer
  56. 56. Drop Capabilities Uses capset() to drop all or some capabilities “Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled.” Man page for capabilities Credentials::DropAllCapabilities@pati_gallardo Zygotes + Renderers
  57. 57. Resource Limits : setrlimit Limits using setrlimit: 1. RLIMIT_AS : Maximum size of the process’ virtual memory (address space) in bytes 2. RLIMIT_DATA : Maximum size of the process's data segment LinuxSandbox::LimitAddressSpace @pati_gallardo Renderer
  58. 58. Sandbox Construction Make it as Restrictive as You Can Get Away With
  59. 59. Trust is Relative BROWSER GPU seccomp ZYGOTE USER capset chroot GPUBROKER seccomp ZYGOTE SYS_ADMIN seccomp RENDERER capset rlimit PID NO_NEW_PRIVS USER/PID/NET NO_NEW_PRIVS FORKCLONE EXEC EXEC CLONE FORKFORK No access to filesystem Done post-fork
  60. 60. vivaldi://sandbox @pati_gallardo
  61. 61. Some Problems @pati_gallardo
  62. 62. Debugging @pati_gallardo
  63. 63. Crash Reporting @pati_gallardo
  64. 64. Overview of the Browser The Linux Security APIs Available Building the Sandboxes Some Problems The Overview
  65. 65. How Web Browser Sandboxes Really Work @pati_gallardo
  66. 66. Sources Michael Kerrisk Book: The Linux Programming Interface Course: Linux Security and Isolation APIs Chromium/Kernel source + Linux Man Pages + lwn.net All Errors Are My Own
  67. 67. Linux Security and How Web Browser Sandboxes Really Work Patricia Aas, Vivaldi Technologies @pati_gallardo Photos from pixabay.com

×