Security/Automation/Winter Of Security 2015/MIG Agent Sandboxing

Team

Introduction

Although we have the same main interest with security, low-level programming and binary hacking, we are diverse in the projects and skills we have developed, each having an unique skill set. We also value open source a lot and want to make our term project a useful contribution to the community. Finally, as our master program is heavily connected to security topics and as we are interested in security and low-level programming, we are be happy to be part of the Mozilla Winter of Security program.

Members

• Teodora Băluță (irc: teob)
• Vladimir Diaconescu (irc: vladimird)
• Constantin-Alexandru Tudorică (irc: tudalex)
• University Advisor: Răzvan Deaconescu
• Mozilla Advisors: Aaron Meihm, Guillaume Destuynder

Project

Mozilla InvestiGator (MIG) is a digital forensics platform used by Mozilla to monitor the security of servers. MIG deploys an agent on systems that is used to maintain the security of the infrastructure. The agent currently runs as root in order to run investigation modules that have low-level access to the system. The goal of this project is to sandbox the MIG Agent on Linux in a way that allows each part to perform investigative work while having as little privileges as possible. The team will have to use the Linux Seccomp mechanism, and the existing Go library, to implement a sandbox in the Agent. If possible, the team will also evaluate sandboxing on MacOS and Windows.

Success Criteria

This project is successful if it provides an implementation which successfully manages to sandbox the MIG Agent, via the Go language and Seccomp library. The targeted operating system is Linux, with MacOS and Windows as possible objectives to be considered.

Roadmap

1. Investigation:
   • Go language beyond the basics
   • Building, deploying and running MIG
   • Digging into MIG; MIG internals, architecture
   • Investigate Windows and Mac OS X sandboxing solutions
2. Design:
   • Aim for generic sandboxing solution (portable, working on multiple sandboxing "back-ends")
   • Create generic sandbox requirements for MIG agent: filesystem access, network
   • Create a whitelist approach for creating a sandbox profile
   • Decide on sandbox applying flow for MIG agent; what is the flow for a MIG agent to run inside the sandbox (fork, exec, scripts, wrapper calls etc.)
3. Implementation:
   • Implement minimal sandbox for Linux seccomp using Go
   • (optional) Port/implement sandbox for Mac OS X, Windows
4. Testing and Evaluation:
   • Measure resource consumption and overhead
   • Validate implementation using existing unit tests
   • Investigate ways of validating sandboxed apps: is an app running correctly when compared to a sandboxed app

Updates

6 October

• Looked into what syscalls are called after the modules are initialised and found out that Go calls unusual syscalls on other threads (openat, smmap, mprotect, clone,..)

13 October

• Looked into sleeping the thread up to 30 seconds to see if the Go syscalls stop. They don't.
• Looked into calling the file module

20 October

Plan

• Make a small (hackish) whitelisting of the syscalls using seccomp on the ping module
• Look into how the sandboxing profile should be structured (JSON)
• A small diagram of how the sandboxing package integrates in MIG
• (optional) investigate differences of SECCOMP between kernel 2.x, 3.x and 4.x -> only research purpose, since we are aiming for 3.x compatibility

Status Update

• Teo: To provide an informal proposal regarding the way the generic sandboxing API/functionality should look like.
  • Teo: To show the small diagram of integrating sandboxing into MIG.
• Alex: Present a "quick and dirty" whitelist sandbox implementation.

Meeting Agenda

• Status update
• Feedback on informal proposal (for generic functionality)
• Input regarding application failure in case of the unlikely situation when the profile is unsuitable or the application is malicious.
• Talk about meeting reschedule (maybe Tuesday, earlier).

27 October

Plan

• Alex to look into how we can return nice formatted errors from the module when the sandbox blocks a syscall.
• Teo to provide update on her open source publishing permission from Intel.
• Teo to provide a small diagram on runtime behavior of the sandboxing module.
• Teo to provide a class-like diagram for the sandboxing profile.
• Start constructing the sandboxing profile: parameters, arguments.

Status Update

• Got permission to publish code
• Trapped the seccomp violation in Go, but couldn't get what syscall violated the sandbox profile.

Meeting Agenda

• Discuss sandbox profile structure.

5 November

Plan

• Alex and Vladimir continue to look into why trapping doesn't work and see how it works on multiple kernels (Ubuntu defaults and CentOS).
• Teo integrate the sandbox profile into each module directly.

Status Update

• Used C code in order to get the information from the SIGSYS signal[1]
• Added the sandbox profile in the module structure (WIP).

Meeting Agenda

• Plan next week's agenda

12 November

Plan

• Sandbox testing
• Sandbox profile done
• Profiles for all modules
• (optional) Diagrams

Status Update

• Tested the unshare syscall in kernel 3.19 and kernel 4.2 and it only applies to the current thread.
• Finish sandbox profile & pull request submitted [2].
• Decided that we should sandbox the process from the beginning.

Meeting Agenda

• Move the meeting 1h earlier. We changed to winter time and now the meeting is 1h later.
• Review sandbox profile, plan to move it to a different package so that it is reused.

19 November

Plan

• Write sandbox tests
• Profiles for all modules
  • Convert syscall id to names for the error message
  • Sort whitelist based on usage (strace -c)
  • Add comment for dangerous whitelisted syscalls
• (optional) Diagrams

Status Update

• Sandbox profile for netstat module [3]

Meeting Agenda

• scribe module small discussion (apply sandbox to the sub-process)
• schedule for holidays

26 November

Plan

• Diagrams
• Profiles for all modules
  • Look at some more parameters for the netstat module (like localmac)
  • Convert syscall id to names for the error message
  • Sort whitelist based on usage (strace -c)
  • Add comment for dangerous whitelisted syscalls
• Write sandbox tests

Status Update

• Vladimir wrote a script that parses all the syscall ids
• Alex worked on the Timediff and Memory modules sandboxes.
• Teo worked on the Netstat module sandbox and on Diagrams

Meeting Agenda

• Discuss the status update

3 December

Plan

• Profiles for the rest of the modules (timedrift, memory, file, example)
• Add comment for dangerous whitelisted syscalls
• Add conditional for sandbox profile
• Write sandbox tests

Status update

• Vladimir and Alex finished profiles for the rest of the modules [4]
• Teo worked on sandbox profile [5]

Meeting Agenda

• Discussion of the memory module
• Conditions for rules - research how they are translated in the libseccomp & see if they can be loaded before
• Discussion for a Mozilla repository
• Start writing tests in order to have a pull request
• Next week - no hangout, use email/IRC
• School report to be written in January (deadline 30 January)

17 December

Plan

• Diagram for sandbox runtime [6]
• Write sandbox tests

Status update

• Teo looked at conditional rules. These will work for integer (uint64) values, not for pointers passed as arguments (cannot dereference)
• Alex made a VM with the mig setup for running functional test
• Vladimir working on extracting the sandboxing code from it

30 December

Plan

• Look into how Go testing works. If we can add sandbox testing. And if these are tested all together and the sandboxes conflict
• Look into applying conditionals on what we can do (ex: flags)
• Extract our sandboxing code to another Go package
• Start a thread about a meeting during the holidays
• Make a PR

Status update

• Moved the sandbox code to [7]
• Made a PR [8]

Meeting agenda

7 January

Plan

• Look into how Go testing works.
• Fix the PR
• Move the sandbox initialisation after create files
• Look into applying conditionals on what we can do (ex: flags)
• Move it to mozilla org

Status update

• Use trusty for travis-ci and make a PR [9]
• Moved to mozilla repo [10]

Meeting agenda

14 January

Plan

• Look into how Go testing works
• Look into applying conditionals on what we can do (ex: flags)
• Make a single PR with both travis-ci and sandbox implementation
• Blog post and video presentation after the university report (end of January)

Status update

21 January

Plan

• Rewrite the exit checks for the filter loading
• Build on other platforms (make mig-agent OS=darwin)
• Comment the syscalls that we do not know where they come from
• Add an example to the mozilla/mig-sandbox README - how to use the sandbox
• Make the PR work :)

Status update

• Teo worked on the research report draft
• Alex made it build on MacOS [11]
• Vladimir investigated where the syscalls come from

28 January

Plan

• Rewrite the exit checks for the filter loading
• Comment the syscalls that we do not know where they come from
• Add an example to the mozilla/mig-sandbox README - how to use the sandbox
• Make the PR work :) - to be merged on a separate branch in the mig repo
• Presentation for aprox 2 weeks after the 28th

4th February

• Write notes that would let people know that '-i' bypasses the sandbox
• Write a standard sandbox profile for the Go runtime
• Write a module that is only meant to trigger violation for testing
• Make issues for future work in their respective repo (mig or mig-sandbox)
• Next meeting on 11th Feb (keep working on PR, use email, IRC in the meantime for issues)