Security: user choice

Thomas Hintz .

One of the primary ways the 3L OS provides strong security is by giving the system's user the power to choose exactly what a program can and cannot do. In a some ways it looks like the permissions system on iOS or Android but fundamentally it is much more comprehensive and secure. So how does this work?

When a program (represented by a function) is run on 3L the user can run that program in an environment of their choosing. So the function only "sees" or has access to libraries, functions, and objects that the user has chosen. For example, if the user runs the program within a new environment that environment won't have access to any variables that were in scope of the function when it was run, unless the user passes and binds that variable in the new environment. This is another way of saying the program is run in its own sandbox, one in which the user can choose what is placed in that sandbox and the program can't access anything outside the sandbox.

This is in stark contrast to the way in which programs are usually run on major OSes of today. Today users are at the mercy of application developers. If the author of a program imports and compiles a library in to their program then the user has little choice but to run that program and giving it access to that library. In 3L the user has full discretion of which library a program has access to and can even easily run multiple instances of the program with varying levels of access. Today if there is a security vulnerability in a web browser that allows a malicious webpage access to the filesystem there is little the user can do to preemptively prevent it, the user just has to wait for the browser developer to release a new version that fixes the vulnerability. With 3L the user could just run the browser in an environment that has no access to the filesystem except as required for running the browser. No matter what happens a malicious program can't exploit any holes in the browser that give it access to the unneeded files since the browser itself doesn't have access. The system also provides for more user control than just what a program has access too.

3L provides a metering system that the user has control over. When the user runs a program they can choose how much of a resource the program can utilize to prevent a system wide Denial of Service attack whether malicious or accidental; such as when a program hits a bug that causes it to hog a whole CPU core. For example, the user can choose how much memory the program can utilize and how much CPU it can use or even how many pages can be printed per time unit. These limits can even be modified as the program is running. Basic components of the metering system are integrated in to the system language runtime itself so they can't be circumvented, even by most low-level OS programs like drivers, and can be applied holistically to the entire system in a uniform and simple way.

The OSes we have today attempt to do something similar and there are also other programs that can be used to "sandbox" programs but they suffer from a critical flaw: they use blunt, crude, complicated, grainy solutions. One clear example is filesystem permissions. On most OSes a file can have read, write, and execute permissions possibly with more specificity such as allowed user groups or accounts. This system addresses some common issues and with careful setup of user account associations can mitigate a fair number of possible issues but that is very complicated and error prone to setup and often the files are still technically available to the program if the program can circumvent the file permissions. In 3L a program can be run in an environment in which the file doesn't exist for the program. Even if it circumvents or breaks some aspect of the file permissions it still can't see any file the environment didn't provide to it since a reference to it literally won't exist. There are other approaches like sandboxing a program in its own virtual machine or OS container but all of those solutions are still grainy and cumbersome to setup and use. While a pretty "locked down" system is moderately possible it takes a monumental amount of effort, so much so that it is almost never done. Most users just run their programs within their user account and that is the extent of their sandboxing. The 3L system is simple and holistic making it much easier to create a very secure system. In many ways OSes of today technically provide some level of user choice but the system is so ad-hoc and grainy that it rarely gets used and what good is a security system if it doesn't get utilized?

User choice is critical in providing strong security in any computing environment and is central to the 3L security system. Along with language and language runtime constraints, such as preventing any direct access to memory or manual memory management, user choice provides a fundamental pillar to 3L security and 3L works hard to make it simple and easy to use.

Caveats

To actually achieve the level of sandboxing that 3L provides for, a lot of work must go into defining the minimal environment a program needs to run in and making it easy for the user to modify and view. 3L provides a system for managing these environment specifications and provides default ones for all bundled applications (specified in more detail in a future posting). It will also work to include sensible default environments for applications available in the official package management system. Tools will also be available to make it easy for community contributors to share and provide defaults for packages not yet included in the official application repository.

Even with those caveats 3L is better than what we have today because of the simplicity of the system and its system-wide availability.

References