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:
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.
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.
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:
Breaks many applications, often breaks portability of Unix applications to Redox.
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.
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.
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
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
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.
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.
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) .
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?
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.
