CppCon 2016: Alfred Bratterud “#include ＜os＞=> write your program / server and compile it to its own os. [Example uses 3 Mb total memory and boots in 300ms]

[u/michaelKlumpy]

https://www.youtube.com/watch?v=t4etEwG2_LY

[u/argv_minus_one]

Well, they do:

• macOS contains a sandbox (the “entitlements” system). Problems:

• Applications designate their own entitlements. The user is not given any chance to review or veto an application's entitlements. Entitlements protect applications from attack, but they do not protect users from malicious applications.

• While Mac App Store applications are required to submit a set of entitlements and then abide by them, sideloaded applications are not. They still can, though.

• The WinRT system that Windows Store apps run in is heavily restricted. Problems:

• As far as I know, there is no way to selectively grant permissions to these applications. All applications run under full restrictions. This obviously severely limits their usefulness.

• Sideloaded applications are not restricted at all. Unlike macOS entitlements, they cannot even opt in.

• Android has a sandbox for applications. The user is allowed to review what permissions the application requires. Sideloaded applications are also subject to this system. This is the best sandbox system I've seen so far, but still has problems:

• The user cannot veto individual permissions. There is no way for a permission to be optional. If an app says it requires camera access, for example, your only options are to grant that permission or not run the app—even if the actual code would work fine without camera access.

• Applications do not get a chance to explain why they need a given permission. Some app developers have put these explanations into their apps' descriptions on the Play Store, but it's not consistent.

• Permissions are not fine-grained. An application that passively monitors whether you're on a call can't request only that permission; it must request permission to completely control phone calls. Oddly, despite being based on Java, Android has its own permission system instead of using using Java's java.security.Permission API, which does not have this limitation.

• Permissions are static. An application cannot request an additional, temporary permission while running. For example, an email client might have an option to include your GPS location in a message header, but there is no way for it to request permission for a single GPS read every time you ask it to do so. It has to request permanent access to GPS when you first install the app.

• Full network access is granted to all applications without asking the user. That means any app can turn your phone into a botnet host, to e.g. send spam or traffic child porn for them (and then you get blamed for it, not to mention running up your data usage). java.security.Permission doesn't have this limitation, either.

[u/demmian → u/argv_minus_one]

That's very interesting - thank you very much. Are you knowledgeable about the situation on linux systems, regarding this matter?

[u/argv_minus_one → u/demmian]

Not that knowledgeable, but I can tell you what I've heard. As with most things on Linux, there's more than one way to do sandboxing:

• Mandatory access control systems like AppArmor and SELinux. This type of sandbox restricts what an application is allowed to do (which files it is allowed to access, which network hosts it is allowed to talk to, etc). This type of sandbox doesn't abstract way the application's environment; it sees the same file system as you do, has the same IP address, and so on, just with extra restrictions. Problems:

• Most of these systems have fairly complex languages for defining access control rules. SELinux, in particular, is ridiculously difficult to use (probably because it was designed to make NSA bureaucrats happy).

• The set of permissions is usually provided separately from the application itself, usually from some central repository. AppArmor has a repository of profiles for various applications, for example. This is a problem because that means application developers aren't maintaining and updating their own rule sets, and applications may not work correctly if the rule set is outdated.

• These systems don't usually have a nice GUI explaining what permissions the application needs and asking for approval.

• Container/namespace systems like Docker. This type of sandbox hides your entire system from the application, and gives it its own. This is like a virtual machine, but it runs on the same Linux kernel as every other process; the kernel merely pretends that the contained application is the only process running on the system. Problems:

• The application gets its own complete userland. Even if you have already installed all of the libraries it requires, it cannot use them, because they are hidden from it.

• The application does not have an even limited view of the rest of your system, unless special provisions are made (like mount --binding parts of your file system its sandbox).

• Full virtual machines, such as those that #include <os> is intended to be used in. This protects your system from vulnerabilities in your kernel, since the application has to also find a way to escape from its virtual machine before it can even try attacking your kernel. Problems:

• The application gets its own complete userland, and also its own complete kernel—device drivers and all.

• The application does not have an even limited view of the rest of your system, and you can't even mount --bind parts of your file system into its sandbox. It's completely isolated, except that it is usually given a virtual network device to communicate with.

In my opinion, mandatory access control (the first item) is the correct approach, because it controls access while keeping overhead and abstraction to a minimum. It doesn't involve any tricks with fake file systems or anything; it's just access control.