SELinux Sandbox and Ambient Authority
Dan Walsh recently introduced SELinux sandbox. This is a mechanism for launching untrusted applications from the command line, which uses a strict MAC policy to isolate the executed application from the rest of the system. There's been a good discussion of the topic LWN, and I thought it might be worth highlighting a few points.
Firstly, this sandboxing scheme is not a separate package. It's an addition to the standard SELinux security policy to define the sandboxed domain (sandbox_t) coupled with a script to set up the environment and launch applications in the sandboxed domain.
The idea for this came out of a few emails following a recent discussion about extending seccomp for more generalized sandboxing. Essentially, the question was asked "what can we do with SELinux and simple sandboxing?", and the result is now available in Fedora development. If you update to the latest policycoreutils and selinux-policy packages, it should simply be there ready to go.
The security policy for the sandbox_t domain is designed to provide the sandboxed application with only the absolute minimum set of permissions required to run. It can load shared libraries, for example, although a future refinement could provide an option to run only static binaries. It cannot interact in an ad-hoc manner with the rest of the system. A scratch tmpfs filesystem may be optionally mounted for the application if required, and unique MCS labels are used to separate sandboxes from each other. Another future refinement will likely include launching sandboxes in private namespaces.
# sandbox id -Z
unconfined_u:unconfined_r:sandbox_t:s0:c226,c674
The above shows how the id command launched via the new sandbox utility is running in the sandbox_t domain, with MCS categories c226 and c674. The values of these don't matter, as long as they're unique on the system.
As root (and note that this is not designed to be run as root, but for demonstration purposes it helps to show the confinement of privileges if they exist), you can't do anything special via sandbox:
# sandbox cat /etc/shadow
/bin/cat: /etc/shadow: Permission denied
# sandbox touch /tmp/moo.txt
/bin/touch: cannot touch `/tmp/moo.txt': Permission denied
In fact, you can't open any files on the global system.
Ambient authority describes the form of authority commonly seen in general purpose operating systems. This form of authority is what allows, for example, a user on a Linux system to open any file for which she has read access, whether she needs to open the file or not. It is seen as problematic in establishing strong security, due to problems such as The Confused Deputy, where authority (i.e. the ability to perform an action) is arbitrarily escalated throughout the system.
(For a particularly clear explanation of these concepts, they are covered in the first ten minutes of this talk by David Wagner).
When an application is launched via sandbox, with no inessential permissions, as much ambient authority as is possible has been removed by SELinux MAC. Instead, authority is explicitly provided to the sandboxed application via a pipe file descriptor handed to it via the launching process (i.e. the standard Unix scheme of constructing pipelines).
Note carefully the difference between these two commands:
# wc -l /etc/shadow
43 /etc/shadow
and
# cat /etc/shadow | wc -l
43
In the first example, the wc application directly opened the file /etc/shadow for reading. It used ambient authority to do this.
In the second example, wc was handed a file descriptor which was already opened by the calling process, and did not require any ambient authority to read the data in the file: the authority was explicitly tied to the file by the caller, and wc was entirely unaware of which file it was reading. wc in this case does not need any permissions except to access the file descriptor passed by the caller. (It still has ambient authority, however, it just didn't need to use it here).
Running the above with SELinux sandboxing in effect:
# sandbox wc -l /etc/shadow
/usr/bin/wc: /etc/shadow: Permission denied
and
# cat /etc/shadow | sandbox wc -l
43
Note that wc now has no authority now except as invoked by the calling process and passed via the sandbox. In other words, it does not have ambient authority when invoked via the sandbox.
This is a very simple and powerful concept for security purposes, as it is possible to define strict information flows between applications in a dynamic and controlled manner, without the need for additional global security policy. It's inherently Unix-y, too.
There are many potential applications of this form of sandboxing, particularly where you need to process information between different security realms (e.g. incoming mail which needs to be passed through a chain of scanning and filtering applications), and for dealing with large and complicated applications processing arbitrary untrusted data.
Keep an eye on Dan's blog for upcoming work on desktop security with SELinux sandboxing.
Firstly, this sandboxing scheme is not a separate package. It's an addition to the standard SELinux security policy to define the sandboxed domain (sandbox_t) coupled with a script to set up the environment and launch applications in the sandboxed domain.
The idea for this came out of a few emails following a recent discussion about extending seccomp for more generalized sandboxing. Essentially, the question was asked "what can we do with SELinux and simple sandboxing?", and the result is now available in Fedora development. If you update to the latest policycoreutils and selinux-policy packages, it should simply be there ready to go.
The security policy for the sandbox_t domain is designed to provide the sandboxed application with only the absolute minimum set of permissions required to run. It can load shared libraries, for example, although a future refinement could provide an option to run only static binaries. It cannot interact in an ad-hoc manner with the rest of the system. A scratch tmpfs filesystem may be optionally mounted for the application if required, and unique MCS labels are used to separate sandboxes from each other. Another future refinement will likely include launching sandboxes in private namespaces.
# sandbox id -Z
unconfined_u:unconfined_r:sandbox_t:s0:c226,c674
The above shows how the id command launched via the new sandbox utility is running in the sandbox_t domain, with MCS categories c226 and c674. The values of these don't matter, as long as they're unique on the system.
As root (and note that this is not designed to be run as root, but for demonstration purposes it helps to show the confinement of privileges if they exist), you can't do anything special via sandbox:
# sandbox cat /etc/shadow
/bin/cat: /etc/shadow: Permission denied
# sandbox touch /tmp/moo.txt
/bin/touch: cannot touch `/tmp/moo.txt': Permission denied
In fact, you can't open any files on the global system.
Ambient authority describes the form of authority commonly seen in general purpose operating systems. This form of authority is what allows, for example, a user on a Linux system to open any file for which she has read access, whether she needs to open the file or not. It is seen as problematic in establishing strong security, due to problems such as The Confused Deputy, where authority (i.e. the ability to perform an action) is arbitrarily escalated throughout the system.
(For a particularly clear explanation of these concepts, they are covered in the first ten minutes of this talk by David Wagner).
When an application is launched via sandbox, with no inessential permissions, as much ambient authority as is possible has been removed by SELinux MAC. Instead, authority is explicitly provided to the sandboxed application via a pipe file descriptor handed to it via the launching process (i.e. the standard Unix scheme of constructing pipelines).
Note carefully the difference between these two commands:
# wc -l /etc/shadow
43 /etc/shadow
and
# cat /etc/shadow | wc -l
43
In the first example, the wc application directly opened the file /etc/shadow for reading. It used ambient authority to do this.
In the second example, wc was handed a file descriptor which was already opened by the calling process, and did not require any ambient authority to read the data in the file: the authority was explicitly tied to the file by the caller, and wc was entirely unaware of which file it was reading. wc in this case does not need any permissions except to access the file descriptor passed by the caller. (It still has ambient authority, however, it just didn't need to use it here).
Running the above with SELinux sandboxing in effect:
# sandbox wc -l /etc/shadow
/usr/bin/wc: /etc/shadow: Permission denied
and
# cat /etc/shadow | sandbox wc -l
43
Note that wc now has no authority now except as invoked by the calling process and passed via the sandbox. In other words, it does not have ambient authority when invoked via the sandbox.
This is a very simple and powerful concept for security purposes, as it is possible to define strict information flows between applications in a dynamic and controlled manner, without the need for additional global security policy. It's inherently Unix-y, too.
There are many potential applications of this form of sandboxing, particularly where you need to process information between different security realms (e.g. incoming mail which needs to be passed through a chain of scanning and filtering applications), and for dealing with large and complicated applications processing arbitrary untrusted data.
Keep an eye on Dan's blog for upcoming work on desktop security with SELinux sandboxing.