Capsicumization of the base system

• Student: ShubhGupta (shubh.gupta2104@gmail.com)
• Mentors:
  • MariuszZaborski (oshogbo@)
  • MarkJohnston (markj@)

Writing an application which makes use of capsicum’s principles is not difficult. But what poses a challenge is to modify the existing applications. Most of the applications’ code was not written with privilege separation in mind. So, in order to capsicumize an application, we need to study what all does an application interact with, what all resources does it require, which can be a good point to enter the capability mode. The application might require a casper service, either out of the existing casper services or a new one. While working on a new casper service we need to focus on:

• what API we are willing to offer, mapping out the necessary functions
• what all limitations should be enforced on this service

We aim to capsicumize i.e sandbox all of the existing base applications. Many applications have been sandboxed but still a lot of applications need to be capsicumized. This project aims to sandbox some of them, namely traceroute6, fsck_ffs, fsdb, fsck_msdosfs, syslogd/file(1).

The generic approach that we will use to sandbox an application will involve:

The first phase involves getting to know the application, reading the code and understanding what the application does. This will help in identifying which part of the code is allowed in the capability mode and which is not.

After we are well versed with the application, we are ready to sandbox it. After understanding what all descriptors does the application need before entering the sandbox, we can provide those descriptors before cap_enter() We can further read the code to understand what all capabilities do the descriptors need. For example in D9303(capsicumizing traceroute) it can be clearly seen that the connect() call was made before the call to cap_enter()

The application might need a service such as a DNS lookup or opening multiple files, which won't be allowed in the sandbox. Casper makes it possible to utilise these services from inside the sandbox. If writing a new casper service, we need to figure out what API are we trying to provide and what limitations it enforces.

Finally, we select the most suitable point of calling cap_enter() and enter inside the sandbox. Now, our application runs inside a sandbox making use of Capsicum and Casper.

The deliverables I aim to develop will be:

• Understand how traceroute6 works and how it is different from traceroute. Then begin to sandbox it. After sandboxing, it carry out the necessary tests to ensure the desired functionality.
• Understand the working of fsck_ffs, fsdb, fsck_msdosfs which possibly work on a /dev file for the device being scanned. Figure out what is the best time to enter the capability mode and finally have them all sandboxed.
• Finally, based on my experience and the utility, choose one out of syslogd, file and begin to sandbox it by following a systematic approach.
• A comprehensive documentation of the work that I do maintained throughout the course of the project.

• Interact with the FreeBSD Capsicum developers, get their opinions on the plan of action. Familiarise with the accepted conventions in the organisation as well as the technologies to be used in the project

• traceroute6 - Analyze the application, its functionalities and understand how it is implemented. Refer to the changes made to capsicumize traceroute and carry out the necessary testing.

• fsck_ffs and fsck_msdox - Understand the working and implementation of the applications and capsicumize them. Carry out the necessary testing.

• fsdb - Make fsdb run in a sandbox successfully, by noticing its similarities with the fsck_ffs and fsck_msdosfs and testing every change

• syslogd or file(1) - Read and understand the implementation of the target application. Think about code re-organization if required. Collect the necessary inputs from the capsicum community on the previous work on file(1)

• syslogd or file(1) - Begin sandboxing the target application while ensuring no functionality is broken. Figuring out if a new casper service is required to be implemented and working on it.

• syslogd or file(1) - Finish up on the new casper service and use it extensively to sandbox our application.

• syslogd or file(1) - Carry out the necessary testing by using the utilities mentioned above to ensure no functionality is broken and application runs in a sandbox.

• Final Week - Finishing up the work including the constantly maintained blog based on the progress made. Ensure that the work goes upstream. Continue contributing to FreeBSD and be a part of the capsicum community.

*The Automated testing framework is used to implement test programs in a variety of languages. We can use atf-sh which is an interpreter for shell based test scripts. Our test programs will mostly include a series of tests checking the functionalities of the application and ensuring that nothing breaks down because of the sandboxing. The ATF tests rely on a separate runtime engine, namely kyua(1), which helps in executing the tests in a deterministic fashion. After writing our tests, we can build them with the help of a MakeFile, which will create a KyuaFile in the directory.

*The ktrace utility enables kernel trace logging for the specified processes. Kernel trace data is logged to a file ktrace.out. The kernel operations that are traced include system calls, namei translations, signal processing, and I/O. *The log information can help in identifying the functionality of the program, and to look if it is just able to function as required. This will help in looking which particular parts of the process were denied access and why were they denied access, if this denial disturbs the functioning of the application. Hence, it becomes an involuntarily required tool for testing the code.

*The procstat utility displays detailed information about the processes identified by the pid arguments, or if the -a flag is used, all processes. It can also display information extracted from a process core file, if the core file is specified as the argument. *Hence, we can know what capabilities are held by the process, and hence can include it in our test plan to check if the correct capabilities are held by the processes as desired.

*It basically aborts the application if it tries to do something which is not allowed in the capability mode and generates a core dump. This helps in capsicumizing, since it makes the application crash whenever something undesirable is done.

https://github.com/ShubhGupta2125/freebsd

https://wiki.freebsd.org/SummerOfCode2018Projects/ObliviousSandboxingwithCapsicum