Plenty of Space Left for OS-level Innovation

As one of the few people still left without circles to drag people into I had to find some other ways to occupy some spare cycles this weekend.

One of the things I ended up spending time with was videos from Apple’s WWDC 2011, as I was curious to see what core OS changes they are making with Lion.

I’ve long been a fan of Apple Engineering and admire the really great software they are building on top of their excellent Unix foundations. The highlight in Lion for me is probably the App Sandbox. Though XPC, Versions and push notifications/iCloud are all very interesting.

The App Sandbox gives each application which opts to use it a private container. File, network and hardware access are all prevented by default unless the app has registered for an exception. Once sandboxed the application can only access files within its sandbox, if the file access exceptions are enabled the user allows the application access to other files through the standard file access sheet (dialog) and behind the scenes the Powerbox has access to the full file system and gives file access to the selected file to the application.

This means in the worst case a compromised application should only ever be able to affect the few files the user has chosen to allow into the sandbox, rather than being able to wreak havoc with the entire file system.

The App Sandbox impresses me for many reasons:

  • Learning about it I had an aha moment, I immediately began to imagine the underlying implementation of such a container mechanism.
  • The developer positioning is excellent; “come play in our sandbox and we’ll keep you and your users safe” rather than talk of jails, etc. The positioning as a last line of defence seems wise also.
  • They have a well tested kernel-level technology for sandboxing from the iOS and are able to leverage this technology created for handsets on the desktop, thanks to their shared core OS.
  • It’s trivially easy to adopt for most developers and has a clear and easy to use migration path.
    All a developer need do is opt in to the sandbox, pick which of the small amount of exceptions (15 or so?) they want for their app and that’s it.
    Migration is handled through a manifest file which tells the OS where to pull files from on first run of the newly sandboxed application.
  • Powerbox is a badly named but cleverly designed arbitrator allowing applications to work as usual whilst still offering users protection. All the application need do is use standard Apple API’s and the OS does the real work.

Next I’m going to go and read up on Linux security mechanisms. I expect that at least one of the kernel-level security frameworks will enable such behaviour, I just wonder if they are so easy for developers to adopt. Guiltily I’ve gotten into the habit of disabling SELinux each time I do a clean OS install, because when it first started cropping up there were too many things I wanted to do which were blocked and not enough time, inclination or (if I recall correctly) documentation for me to work out how to get do them in a compliant way.

I wonder how much has changed in the intervening years and what SMACK and Tomoyo do differently?

Update: I may have mocked the term Powerbox but it’s not one Apple coined, browsing some security focused OS research I discovered the term again and a little more digging revealed that Wikipedia has a section on it in their File Dialog page and that Capdesk was the first desktop environment to include a Powerbox file dialog.

2 comments

  1. I don’t know about SMACK or Tomoyo (or RBAC), but I have spent a bit of time with AppArmor.

    It’s easy to get to grips with and needs only a single file writing (with include files available for common abstractions) to define the accesses.

    You can have applications in “complain” mode where the accesses aren’t denied but are logged, so it’s easy to confirm what is going on.

    I’ve got an apparmor profile for mosquitto. It’s 24 lines. I haven’t got an selinux profile.

    1. I’d forgotten about AppArmor (I really should have just looked at Documentation/security in the kernel tree) – it does sound fairly simple and your description of complain mode reminds me of SELinux’s permissive mode.

      Thanks Roger, I’ve added that to my list of security systems to investigate.

Comments are closed.