First cut at assigning classes to data and sandboxes. There are currently two annotations: __soaap_classify(L) that allows the assigning of a class to an item of data (currently struct fields) and __soaap_clearance(L) for specifying that a sandboxed method is allowed to access data in class L.

SOAAP picks up these annotations and performs a taint analysis to see where loads of sensitive data propagate to. Every sandboxed load and store instruction is then checked to see if sensitive data is being accessed for which the sandbox does not have clearance for.

Although I use the terms classify and clearance, what I'm trying to introduce is the notion of classes of sandboxes and data and being able to specify (i) membership of this class and (ii) being able to access members of the class. Currently classes are non-hierarchical.
OpenSSH also has sensitive global variables, so have implemented support
for assigning sensitivity classes to these. The analysis then treats loads
of these globals as being sources of taint and performs taint propagation.
Post-taint-propagation, we check for accesses of sensitive data in contexts
that are not allowed to and report warnings.
Added support for naming persistent sandboxes. This introduces a new annotation: __soaap_sandbox_persistent_named which takes a string name argument. For example:

__soaap_sandbox_persistent_named("network")
void fetch(char* URL) {
  ...
}
Integrate from master branch. Made perf_analysis work with the latest changes at soaap_analysis.
Fixed a bug that prevented perf analysis to work on ephemeral sandboxes.
Added initial support for annotating struct fields and global variables as being sandbox-private with the name of the sandbox specified as a parameter (e.g. __soaap_sandbox_private("network")). A taint analysis is performed to approximate the propagation of this sensitive data. Finally, a check is made to see a sandbox may access data that it is not supposed to. Currently, this check is limited to sandboxes but next I will do the check for the privileged parent too.
Access checks now being performed in privileged methods. Next thing is to check for private data leaking from sandboxes such as via callgates, propagation to other global variables, etc. I also want to be able to annotate local variables as being sandbox-private.
Added support for sandbox-private local variables.
SOAAP can now find leaks of sandbox-private data via global variables.
Sample error message:

*** Sandboxed method dostuff executing in sandboxes: [network] may leak private data through global variable x
+++ Line 20 of file test-sandboxprivate-leakviaglobal.c

  4 int x;
  5
  6 void dostuff();
  7
  8 int main() {
  9   dostuff();
 10   printf("value of secret sandbox-private local variable: %d\n", x);
 11   return 0;
 12 }
 13
 14 __soaap_sandbox_persistent_named("network")
 15 void dostuff() {
 16   int y __soaap_sandbox_private("network");
 17   y = 25;
 18   int z = y;
 19   printf("leaking sandbox-private y to global x\n");
 20   x = z;
 21 }
Implemented leak detection via environment variables. Example error:

*** Sandboxed method dostuff executing in sandboxes: [box] may leak private data through env var "PUBLIC"
+++ Line 18 of file test-sandboxprivate-leakviasetenv.c

for the code...

  1 #include "soaap.h"
  2 #include <string.h>
  3 #include <stdlib.h>
  4
  5 void dostuff();
  6
  7 int main() {
  8   dostuff();
  9   printf("value of secret sandbox-private password: %s\n", getenv("PUBLIC"));
 10   return 0;
 11 }
 12
 13 __soaap_sandbox_persistent_named("box")
 14 void dostuff() {
 15   char* password __soaap_sandbox_private("box");
 16   password = "mypass";
 17   printf("leaking sandbox-private password to environment variable PUBLIC\n");
 18   setenv("PUBLIC", password, 1);
 19 }
Support for leakage via extern functions.
1) Fixed handling of calls into another sandbox. Previously, a callee sandbox entry point was treated as executing in the caller's sandbox but actually this is a cross-domain call so it should be recorded as executing in the callee sandbox context.

2) Fixed the definitions of __declare_callgates and __declare_callgates_helper in soaap.h so that they actually appear in the llvm bitcode file.

3) Implemented support for detecting leakage via callgates.

Example error:

*** Sandboxed method dostuff executing in sandboxes: [box] may leak private data through callgate privfunc
+++ Line 17 of file test-sandboxprivate-leakviacallgates.c

Example code:

  1 #include "soaap.h"
  2 #include <string.h>
  3
  4 void dostuff();
  5 void privfunc(int p1);
  6
  7 __soaap_callgates(privfunc);
  8
  9 int main() {
 10   dostuff();
 11   return 0;
 12 }
 13
 14 __soaap_sandbox_persistent_named("box")
 15 void dostuff() {
 16   int key __soaap_sandbox_private("box");
 17   privfunc(key);
 18 }
 19
 20 void privfunc(int p1) {
 21   printf("p1: %d\n", p1);
 22 }

4) Implemented support for detecting leakage via a call into another sandbox:

*** Sandboxed method dostuff1 executing in sandboxes: [get] may leak private data through a cross-sandbox call into: [auth]
+++ Line 16 of file test-sandboxprivate-leakviacrosssand.c

Example code:

  1 #include "soaap.h"
  2 #include <string.h>
  3
  4 void dostuff1();
  5 void dostuff2(int x);
  6
  7 int main() {
  8   dostuff1();
  9   return 0;
 10 }
 11
 12 __soaap_sandbox_persistent_named("get")
 13 void dostuff1() {
 14   int key = 813;
 15   printf("leaking sandbox-private password to another sandbox\n");
 16   dostuff2(key);
 17 }
 18
 19 __soaap_sandbox_persistent_named("auth")
 20 void dostuff2(int x) {
 21   printf("x: %d\n", x);
 22 }
committed some sample annotated files
Fix to SOAAP include file to avoid a 'duplicate symbol' linker error
Added BSD includes and Makefile
debug output conditionalised
LLVM currently has a bug wherein calls to the intrinsic @llvm.ptr.annotation.p0i8 (which gets inserted for struct field annotations) are not removed before code generation occurs. This commit contains a workaround whereby we manually remove the calls at the end of the CallEdgeProfiling and SoaapPass passes.
Removed global variable warnings for extern global variables, otherwise we get warnings for libc
Implemented support for finding writes to shared global variables that occur outside sandboxes and thus will not be propagated to sandboxes. I had previously implemented this check in valgrind but forgot to also implement it in our static analysis.
Added the __soaap_past_vulnerability_block and __soaap_past_vulnerability_func annotations for code blocks and functions respectively. Currently SOAAP just finds these annotations and outputs that it has. Next step is to do something useful with them.