Computers are getting faster, smaller, more connected, and more capable, but when it comes to security, everything is broken. Along with correct-by-construction software (e.g. Certified Programming with Dependent Types), the best weapon I see is object capability discipline.
Before I get into my wish list of projects and issues, I'd like to point out dckc/awesome-ocap, my list of capability security technology that is ready to use today, including everything from seL4, an open source operating-system kernel with an end-to-end proof of implementation correctness and security enforcement to Sandstorm, a self-hostable SAAS platform.
Secure module loading for node.js
discipline, but support in node.js for some of the best parts is
lacking and hence there's no guarantee that calling and enhanced
sqrt() from some npm module will not send an HTTP request to launch
Mark Miller demonstrated the feasibility of secure loading as far back
as 2011 with makeSimpleAMDLoader.js. I'm trying to fully
understand node's incomplete support for
Meanwhile, I'm having fun with Capper; see finquick.
Sandstorm dev tools on Ubuntu 16.04
Ubuntu's 16.04 kernels handle pid namespaces in a way that interferes with the sandstorm dev tools. Tracking issue: 2526.
I figured out how to build sandstorm apps with nix, but without the dev tools, the edit/test/debug cycle time is too long.
Capability security for mainstream linux with CloudABI, capsicum
While considering alternative kernels, I ran into a linking issue when trying to build a linux kernel that supports capsicum and CloudABI. (There was a PPA for capsicum for a while...)
CloudABI or capsicum at work would be so great. But it's a long way off... we're struggling to migrate to SuSE 12 so we can try out Docker.
For example, a research workflow app I maintain needs to be able to send mail, but - only from one address - only using templated bodies - only to users who have in some way asked for it
Design sketch: at at investigator request time, user grants "capability to send app-template mail to addresses X, Y, Z".
bus1, Capability-based IPC for Linux
I'm heartened by momentum around bus1.
On top of the lack of composability in the chmod/chgroup, there's a
mounting kludge tower of stuff like SELinux and (to a lesser extent?)
AppArmour. I was doing a storage audit and learning how
the serial number of my drives. I had heard of udev and systemd, but I
had no idea it uses netlink
("a more flexible alternative to ioctl") to communicate with the
Object capability discipline for Docker
Is this even possible? I can't get my head around the Docker security story.
Uniform, composable FFI and stdlib for pony
Pony aims to be a high-performance capability-secure language. I would love to see it make some inroads on golang: while go addresses (many of) the memory-safety issues of C/C++, its standard library is full of ambient authority and its type system dooms developers to lots of boilerplate maintenance.
I'm struggling (mostly for time) to convince the pony community that a reasonably simple policy can eradicate ambient authority from the standard library.
In discussion of my network API PR, I learned that the pony designers don't (yet) see interposition as a key component of robust composition.
Safe systems programming on seL4 and genode
Robigalia aims to be a persistent capability OS built on seL4 and rust.
Rust on seL4 is pretty bleeding-edge: SEL4PROJ/rust-camkes-samples/issues/1 documents my trials and tribulations. https://github.com/seL4/refos looks interesting.
Object capability discipline support in rust
We supporters of the 2012 proposals to isolate ambient authority in the rust stdlib didn't make our case well enough for the 1.0 cut-off, but there is renewed interst in refactoring std for ultimate portability. One result of this could be a std alternative with no ambient authority.