Capsicum and Casper - a Fairy Tale About Solving Security Problems

Capsicum and Casper - a Fairy Tale About Solving Security Problems

Capsicum and Casper - a fairy tale about solving security problems Mariusz Zaborski Wheel Systems, FreeBSD [email protected] 1 Introduction • stdio - one of the most common, allows us to allo- cate memory, and perform basic io operations (like Every year the list of security bugs is shocking. Oper- using stdout), ating systems start to innovate new mitigation techniques like ASLR or canneries which only makes exploiting • rpath - allows functions which only cause read-only harder but many in many cases still possible. We also try effects on the filesystem (eg. open(2) on an existing to mitigate on a lower level like the NX bit in the CPU, file with read flag only), but researchers again have found a method of bypassing • wpath - allows system calls which may cause write- this technique by the so-called return oriented program- effects on filesystems, ing. Another way of handling security problems is by us- • cpath - allows functions which may create new files, ing a sandbox environment. Some researches try to use a • proc and exec - allow to fork and execute another sandbox on a big scale, like running different virtual ma- program. chines for different tasks, while others try to use them on a smaller scale like in a process. In this article we focus Pledge always allows you to reduce permissions by sim- just on two of them. Process sandboxing should be easy, ply calling pledge(2) again. flexible, scalable and lightweight. Two of the most recent Statistics show that Pledge is very easy to use to sand- work in BSD world deserve for our attention - Capsicum box application. Over 400 programs in OpenBSD use and Pledge. pledge. These sandboxing techniques have their strengths and At listing 1 we have an example of how cat(1) program weaknesses. Process sandboxing can sometimes be too was sandboxed using pledge(2). The program has access restrictive for some of the challenges found in the real to stdio (cat(1) needs stdout to print result) and have ac- world and this is the moment when Casper enters the cess to all filesystem as long as it is read only. A big scene. advantage is that cat(1) can’t create any socket or pass descriptors. So in the end the usage of Pledge comes 2 Pledge to understanding the program and to giving it the right promises. Pledge (historically tame) is a sandbox framework cre- @@ −66,6 +66,9 @@ ated for OpenBSD project [1]. Pledge assumes that we can divide any program into two parts. One of which setlocale(LCn ALL , ” ” ) ; is the initialization phase in which all the preparations i f (pledge(”stdio rpath”, NULL) == −1) are performed (e.g. arguments parsing) and the other err(1, ”pledge”); one which is the main loop, containing the actual op- erations (e.g. parsing a file). Pledge allows us to de- while ((ch = getopt(argc, argv, ”benstuv”)) != −1) cide which system calls can by be accessed by so called switch ( ch ) f ”promises”. Each promise gives us a different set of sys- case ’ b ’ : tem calls with different options. At the moment Pledge Listing 1: pledge(2) used in a cat(1) program in implements around 24 promises, in which we can count: OpenBSD. [2] As you can see in the listing 1 pledge has two argu- Capabilities in Capsicum are represented by file descrip- ments. The first was already describe in depth earlier. In tors. In sandbox you can’t create a new descriptor from the future it will be possible to pass as a second argument global namespace, but you can still use privileges that a list of paths which will be whitelisted from the Pledge you already have. For instance, you can’t open any new sandbox. At the time of writing this article these options files2, but we can use capability which we have, lets say were not yet implemented and always end with the error descriptor to the directory and using openat(2) syscall we message: ”Invalid argument”. can still open files from that directory. In Capsicum we What is also very interesting and also quite surprising have two ways to obtain capabilities. The first way is to is that the author of Pledge has hard coded paths to some get credentials before entering sandbox, so for example files in the kernel. For example, even in sandbox, you are in the initial phase of the program we open files, create always able to do operations like: sockets and then enter sandbox to perform complicated algorithms. The second way is to obtain them from other • open(2) files like /etc/localtime and any files below process. File descriptors are ideal as the carrier of the ca- /usr/share/zoneinfo, pabilities, they can be inherited by a child process after fork and also if the two processes share an Unix domain • readlink(2) may operate on /etc/malloc.conf, socket descriptors can be passed around. • sysctl(3) read-only operations like getdomain- The second part of Capsicum allows us to limit the name(3), gethostname(3), getifaddrs(3), uname(3). process even further. Capability rights are a special flags added to file descriptors which tells the kernel how you As motioned earlier, you can use an exec promise can use them. We can limit descriptors to be read-only, which allow you to execute another program. This is an write-only, read-write but what is very interesting and example of promises which you should be very careful very useful is that you can even specify that descriptor about, and which unfortunately is over used1. The real to be append only3. In the FreeBSD we have defined problem with exec is that promises are not inherits be the around 80 capability rights. For example as file specific new process. If a potential attacker would exploit your rights we have: program he can try then run other application from your system which can lead to a security gap. • CAP FCHMOD allows change mode (fchmod(2)), Pledge in its assumption is very similar to the • CAP FSTAT allows getting file stats (fstat(2)), seccomp-bpf. The difference is that with pledge we have multiple predefined set of allowed/forbidden syscalls and • CAP UNLINKAT allows file deletion (unlinkat(2)). arguments. In case of seccomp-bpf we must define such list and it is easily desynchronized after every update [3]. A full list of the Capsicum capability rights can be found Pure seccomp-bpf is also very hard to use but now we in the FreeBSD rights(4) manual page. Capsicum was can use libseccomp which simplify it a lot. first introduced in FreeBSD 9.0. Currently, there is ongo- OpenBSD released pledge in 2015 and it is still con- ing work to port Capsicum to Linux and DragonFlyBSD sidered as experimental feature and its API can change. [5] [6]. 3 Capsicum 3.1 Sandboxing uniq(1) Capsicum is a lightweight OS capability and sand- As an example of using Capsicum in practice we will box framework implementing a hybrid capability system use a uniq(1) case. First what we need to do is to un- model [4]. The process sandbox system’s architecture in derstand what the program is doing. The uniq(1) is used FreeBSD can be divided into two modules: to filter out repeated lines in a file. In the code we can see that our application is operating on input and out- • Tight sandboxing (cap enter(2)) put descriptors. Both of them can be file or stdout/st- din descriptors. In listing 2 we have code responsible • Capability rights (cap rights limit(2)) for setting capability rights on descriptor. We are us- ing cap rights init(3) function to initialize a structure re- By calling cap enter(2) we enter a sandbox or so sponsible for keeping capabilities (cap rights t). Unfor- called capability mode. Capability mode is inherited by tunately the description of this structure is beyond this all descendent processes and cannot be removed. Any attempt to access to any global namespaces (such as path 2We can’t because we trying to access path namespace. names or pid namespace) will be prevented by the kernel. 3In our software at Wheel company we use such descriptor as log descriptor, if somebody would break in to the sandboxed program he 1At the moment around 70 programs is using it. can’t overwrite any previous log. 2 article but if you are interested why do we have it in such entering the main function we are already in the capa- form you can look into another article [9]. bility mode. If we want to open a socket or open files After setting up all descriptors we can enter capabil- in this environment we need to define a special YAML ity mode which we see on listing 3. Some perceptive file with will be parsed before executing a user code and reader can notice that we not only are checking result of after entering main function descriptors will be available cap rights limit(3) or cap enter(2) we also are checking for use. errno value. If the FreeBSD kernel is unable to enter ca- The author hopes that CloudABI will be used more pability mode it will fail but if it will fail with ENOSYS frequently in the Cloud platforms. that means that the FreeBSD kernel is compiled without Capsicum support and we want to continue execution. 5 Comparison c a p r i g h t s t r i g h t s ; ... i f p = s t d i n ; As we can see Capsicum and Pledge present a totally ifn = ”stdin”; different approach to the security problem.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    8 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us