1 / 11

Sandboxing Project

Sandboxing Project. By Team Sandbox Asaf Cohen, Yaron Rozen. What we need to do?. Create a sandbox mechanism inside the kernel. A sandbox is a security mechanism for separating processes from the rest of the system.

meriel
Download Presentation

Sandboxing Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sandboxing Project By Team Sandbox Asaf Cohen, Yaron Rozen

  2. What we need to do? • Create a sandbox mechanism inside the kernel. • A sandbox is a security mechanism for separating processes from the rest of the system. • Purpose: run untested programs, even with root privileges with no worry.

  3. How are we going to do it? • We are implementing the sandbox mechanism with the following additions to the kernel: • Adding new system call for sandbox creation, and fork into sandbox. • Adding a struct sandbox member to task_struct. • Will hold an id and a bitmask. • The default id value will be 0 (means: no sandbox). • Changing copy_process to close unauthorized resources (according to sandbox.id). • Adding sandbox_wrapper to Entry(system_call)

  4. Adding new system calls • intsys_sb_create(bitmap, chroot_dir) • intsys_sb_destroy(sand_id) • int sys_sb_fork_into(sand_id)

  5. sandbox member in task_struct • Each sand_id will identify a single sandbox_struct in the kernel. • This structure will hold a syscall_bitmap(in future iterations: permission_bitmap) • sand_id will be given to copy_process() by sys_sb_fork()

  6. Copy_process • Inside copy_process() we add handlers to prevent copy of resources during fork, so we limit the task struct of the sandboxed process. • copy_files(clone_flags, p); • copy_fs(clone_flags, p); • copy_mm(clone_flags, p); • ....

  7. Sandbox wrapper • ENTRY(system_call) • …. • call sandbox_wrapper • Jnz failure • call *sys_call_table(,%rax,8) • intsandbox_wrapper() • Task_struct t = current()->task; • If (t.sandbox.id != 0): // sandboxed • return t.sandbox.bitmask[eax] // bitmask treatment

  8. How the sandbox is enforced? 2) Requires a service from the kernel using a system call Sandboxed Process User Mode Kernel Mode System call Kernel Entry here we add sandbox_wrapper() • Task Struct: • state • pid • … • struct sandbox = { • id (zero indicates no sandbox) • bitmap (controls syscall execution) • } 1) Each task structure has a new sandbox member, if the id is different than zero the process is sandboxed. 3) Allows/Denies the system call according to the bitmap

  9. Timeline from process perspective (1) The (pseudo)code of the parent process: intsand_id = SYSCALL(sys_sb_create, bitmap, chroot_dir) intpid = SYSCALL(sys_sb_fork_into, sand_id) if (pid = 0) { // child code runs in sandbox SYSCALL(sys_exec_once, [exec_params … ]) } else { // parent code wait(pid); // monitors child } SYSCALL(sys_sb_destroy, sand_id)

  10. Timeline from process perspective (2) • Parent task (pid = 70) is not sandboxed(sandbox.id = 0) • Calls sys_sb_create(bitmap, chroot_dir) • In the kernel a new sandbox with id 2 and the given bitmap is initalized. • Task recieves new sandbox id 2 in user mode. • Calls sys_sb_fork_into(2) • The kernel forks a new task struct with parameters: • pid = 80 • ppid = 70 • sandbox.id = 2 • sandbox.bitmap = bitmap

  11. Timeline from process perspective (3) • The child loads its code into memory using a new syscall: sys_exec_once() • sys_exec_once() performs exactly what sys_execve() does except that sys_exec_once also clears the allow bit of sys_exec_once from the bitmap. • We assume here that the the parent denies the child from using exec() in the sandbox permissions bitmap. • This is a simple solution to a “chicken and egg” problem. • The code of the child runs in sandbox number 2, that is, every syscall is analyzed in the kernel before execution according to bitmap.

More Related