Discussion: Filesystem based isolation (security)

#1

Most current operating systems (all Unix-based, Windows) have one major disadvantage, which is critical to security:
By default and with minor exceptions, any application can read any system file, execute any application and read+write any user data. Minor exceptions are:

  • Windows: ACLs for AppData/Roaming
  • RBACs like SELinux, AppArmor: massive amount of metadata for blacklisting and whitelisting
  • filesystem permissions based on user name and file metadata: limited approach

This leads to situations that can go wrong easily:

  • any application running as my user ID can read all my application data and private data, leaking them to 3rd parties e.g. over the network
  • any application can modify any application data of other applications, installing malware or messing them up
  • any application can modify my private data without me knowing

More specific, these situations are used by attackers:

  • my web browser is able to run a shell – it doesn’t have to
  • my PDF reader application can edit files like ~/.bashrc installing malware

Most problematic situations described above can be avoided by a more strict, whitelist-based design:

  • by default, any application can see no files
  • exceptions to the rule above:
    • files owned by the application (executable)
    • shared libraries used and files owned by them
    • configuration files
  • some applications need to be excluded from these rules, e.g. file managers or some command line tools

Access to user private data (e.g. traditional “Desktop” folder) is done by a third party, some kind of delegate process related to a file manager, displaying and handling file chooser dialogs.
Examples:

  1. A user want to download a file with my web browser. My web browser invokes the delegate process, which opens a file chooser letting the user choose where to save the file. The delegate may remember this location (e.g. “Downloads folder”) and permanently allow the web browser to save files there. The web browser still doesn’t have any write access to any private data except writing new files to Downloads dir.
  2. A user wants to edit a private file using an editor or word processor. This application calls the delegate, the delegate opens a file chooser and lets the user select a file to open. Then it transfers the file (or file descriptor) to the application.
  3. A user wants to edit a system config file. As above, it asks the delegate to show a file chooser dialog. The delegate can act as a authentication agent allowing an unprivileged application edit this file and doing the privileged operation (open/save file) in the delegate.

Results and positive side-effects:

  • reduced attack surface. GUI applications don’t usually need to start shells
  • reduced space for packaging mistakes and programming errors
  • clear distinction between private user data and user-specific application data
  • metadata is available for removing user-specific application data when application is removed
  • have a usable and safe way for unprivileged applications editing privileged files

Downsides:

Any comments or ideas on that?
Is there any chance to get this implemented in Redox? Do you want to be backwards compatible or stop making the same mistakes Linux is doing?

Edit: You could use existing partial solutions and do sandboxing, chroot or use (Linux) namespaces, but this introduces an overhead. And all those technologies are not enabled by default, but have to be configured for each application. Implementations are not tested well enough and are written in a monolithic C software or kernel.

5 Likes
#2

SYSSUPERVISE can be used for this form of virtualization.

#3

I think this is definitely an issue, but I don’t think it’s one that should be directly solved by the OS. The OS should make it relatively easy to add this to something like a package manager, but it shouldn’t be an innate part of all applications.

I think just having SYSSUPERVISE available is ok, and then it’d be awesome to have a package manager-application for installing non-built-in applications. A package manager could, reasonably, wrap all installed binaries in it’s own code which uses SYSSUPERVISE to limit the access of the application.

#4

I like this idea,

given SYSUPERVISE, I don’t think a solution in the core operating system is needed, but I think it would be nice if it would be the default way to run any kind of application on Redox and therefor it should be really “close” (in development) to Redox.

With close I mean that for a nice compatibility with all kind of applications such system
might require some “cooperation” with e.g. some redox interface design, witch a
normal “external” program could not expect to get :smile:

PS:
also we should differ between “Applications” and other programs like command line utils.
Many applications open files over the systems (or ui-toolkits) file chooser, witch make
hooking in a access controll not vary hard. But doing so for e.g. custom command line
programs might be hard (but I am convinced it is possible but would brake some program command line interfaces).

Do sandbox even command line tools you would have to use some meta information shipping with a hypothetical Redox package manager and use som algorithm to extract possible paths from the command line arguments, but well it would be a lot of work to build and more work to port applications so I doubt it will be done :wink:

#5

Thanks! I haven’t seen this one.

#6

Thank you for your feedback, suggestions to use sys_supervise and thoughts on it.

I think it should be part of the OS (but not of the kernel) – so I like the idea of sys_supervise. It should be default for all “user” applications like file managers, web browsers, editors, word processors, …. Containing applications would be a huge gain for security.

That’s true. It would partially break compatibility.

CLI tools: Yes, their model of computing is not compatible with what I suggested. They often cannot be enforced to these limitations.

1 Like
#7

Before you go much further in this space, please take a look at the related security work. This is an example article from a security researcher at Cambridge, who went on to design the security framework in iOS. It touches on some of the same concerns and how these have been addressed over the last decade or so.

http://queue.acm.org/detail.cfm?id=2430732

The result of this work was “Capsicum”, which “can be used for application and library compartmentalisation, the decomposition of larger bodies of software into isolated (sandboxed) components in order to implement security policies and limit the impact of software vulnerabilities.”

Capsicum ships as part of the FreeBSD kernel (which the author of that that article is major contributor) .

https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4

1 Like
#8

What about when you launch a program, then issue SYSSUPERVISE? Is there a brief window where the process is unsupervised?

#9

forgive me if this is ignorant, i’m just starting to look at rust/redox but… can’t you run the gui in a SYSSUPERVISEd shell? or, it doesn’t seem very difficult to scheme a passthrough to
a linked/restricted user account to handle gui/apps?

#10

Interesting, exactly this is the question that brought me here! Looking for a rust-based OS I came across Redox-OS. However I find the concept of capability based access control like discussed around the L4-related OSes critical to somehow handle the problem that not every program run by a user may access all data of that user.
In the end I would love to see that sort of access control in a modern micro-kernel rust-based user friendly OS.

– Just my 2 cent.

Best regards

#11

This is easy to do with scheme namespaces, look at https://github.com/redox-os/contain for an example

1 Like
#12

If Redox is really going to be a security-first system, something like this is necessary. I think it would be silly to put it in the kernel (which is meant to be minimized, also for security reasons), but I definitely think it should be a basic function of the operating system analogous to the security measures in monolithic kernels. Even as a casual user I would find this level of security extremely desirable, and would like it to be built-in and default.

This is exactly what I’m talking about. I don’t want my PDF reader to access anything except the document I explicitly asked it to display. I’d be willing to sacrifice a fair bit of performance on extra processes to make sure this doesn’t happen.

Designing the whole OS around a safe permission system would probably yield a simpler (and IMO better) piece of software. Security should be the way Redox works, not an add-on. IMO, additional software should be used for non-native compatibility (such as Unix support), not for keeping the base system safe from malfunctioning or compromised software.

Wasn’t Rust created to correct the same old mistakes C has been making? Since Redox is meant to take advantage of Rust, it makes sense for Redox to correct the mistakes of Linux in the same way that Rust corrects the mistakes of C.

OSX apps and Linux appimage came up in this thread. There are definitely advantages to packing applications up in little self-contained bundles this way, one of them being isolation. This sort of solution seems to complement the original suggestion. To modify something outside of its own app bundle, a program would have to go through the delegate process to get permission from the user. This is a great solution, because then I can install any random application I want off the internet with the confidence that it can only screw up 1) its own files or 2) files I explicitly told it to access.

One approach might be to limit command line utilities by default to files within the directory the user called it from. e.g. if you call the cp command within your Documents folder, that command (and any commands it calls) can only access things inside of Documents and its sub-directories. If you wanted to parse arguments for valid URLs, you could give the command access to those too. If the user trusts the command line utility completely, they can run the tool from their user or even root directory to give it access to everything. This approach would keep a suspicious utility from sneaking out behind your back to do things in other locations, while giving it access to the files you most likely intended for it to access by default.