Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| summerofcode2020projects:capsicumizationofthebasesystem [2020/05/12 20:22] – ShubhGupta | summerofcode2020projects:capsicumizationofthebasesystem [2023/01/25 15:12] (current) – Fix minor typos. vermaden | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Capsicumization of the base system ====== | ====== Capsicumization of the base system ====== | ||
| - | * Student: [[/ | + | * Student: [[/ |
| * Mentors: | * Mentors: | ||
| * [[/ | * [[/ | ||
| Line 12: | Line 12: | ||
| 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, | 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, | ||
| - | ===== Approach to solving | + | [[http:// |
| + | |||
| + | ===== Differential revisions Submitted ===== | ||
| + | |||
| + | ^ Differential | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | |||
| + | ===== Bugs Reported ===== | ||
| + | |||
| + | ^ Title ^ Status | ||
| + | | traceroute6: | ||
| + | |||
| + | ===== Approach used ===== | ||
| The generic approach that we will use to sandbox an application will involve: | The generic approach that we will use to sandbox an application will involve: | ||
| Line 26: | Line 42: | ||
| 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. | 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. | ||
| - | ===== Deliverables | + | ===== Project Overview |
| - | The deliverables I aim to develop will be: | + | The project involved picking up applications one by one and sandboxing |
| - | * 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 | + | |
| - | * 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. | + | |
| - | ===== Milestones ===== | + | ==== traceroute6 |
| - | === June 1st: Start of coding === | + | * My initial guess was that sandboxing traceroute6 should be pretty similar to sandboxing traceroute which was already done |
| - | * Interact with the %%FreeBSD%% Capsicum developers, get their opinions on the plan of action. Familiarise with the accepted conventions | + | * It turned out it wasn't because in traceroute6, send_probe() changed |
| - | === June 1st - June 15th === | + | * The fix around this problem was to use a raw socket instead of the IDP socket and create its header |
| - | * **traceroute6** - Analyze the application, | + | * This helped me understand how the headers in the various protocols work and how can I create one |
| + | * Also, while sandboxing traceroute6, | ||
| - | === June 15th - June 29th === | + | **Code** |
| - | | + | |
| + | * [[https:// | ||
| - | ==== Mid-term Evaluations #1 ==== | + | ==== fsck_ffs ==== |
| - | === July 3rd - July 10th === | + | |
| - | * **fsdb** - Make fsdb run in a sandbox successfully, | + | |
| - | === July 10th - July 17th === | + | |
| - | * **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) | + | |
| - | === July 17th - July 27th === | + | |
| - | * **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. | + | |
| - | ==== Mid-term Evaluations #2 ==== | + | |
| - | === July 31st - August 17th === | + | * I was able to sandbox |
| - | | + | * Later when I began to sandbox fsdb, I realized it uses the same setup() which fsck_ffs uses. Which means they both enter the capability mode at the same piece of code, which wasn't good because I wanted their sandboxing |
| - | === July 17th - August 24th === | + | * I moved the cap_enter() calls to their respective main() just after setup() call was finished |
| - | * **syslogd or file(1)** - Carry out the necessary testing by using the utilities mentioned above to ensure no functionality is broken | + | |
| - | === August 24th - August 31st === | + | * Testing fsck_ffs was a little tricky. I had to use mdconfig to create a fake disk with FFS file system on it, tweak its inode counts using fsdb and then run fsck_ffs on it. |
| - | * **Final Week** - Finishing up the work including | + | |
| - | ===== Test Plan ===== | + | **Code** |
| + | * [[https:// | ||
| - | ==== atf(7) and kyua(1) | + | ==== fsdb ==== |
| - | *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 [[/ | + | |
| - | ==== ktrace ==== | + | **Where and why did I enter the capability mode?** |
| - | *The ktrace utility enables kernel trace logging for the specified processes. Kernel trace data is logged to a file ktrace.out. | + | * fsdb calls setup() from the fsck_ffs directory, which opens the arg device |
| - | *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 | + | * doing cap_enter() inside wouldn' |
| + | * Hence, | ||
| - | ==== procstat ==== | + | **Why did I use cap_pwd and cap_grp casper services** |
| - | *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 | + | * printactive() |
| - | *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 | + | * printactive() is called before entering |
| + | * printactive() is also called after entering | ||
| - | ==== enotcap ==== | + | **Code** |
| - | *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, | + | * [[https:// |
| - | ===== The Code ===== | + | ==== fsck_msdosfs |
| + | |||
| + | * My initial guess was fsck_msdosfs should be trivial to sandbox, wherein I just have to cap_enter() inside the checksys() call after the filesystem is opened. | ||
| + | * The code revision worked for a single device but failed to work for multiple devices given through the command line. | ||
| + | * Which is why I had to use cap_fileargs to open the different file systems. Also, to keep the code elegant, I moved the code for opening a filesystem inside main() instead of checksys() | ||
| + | * The code was being used n different platforms, which is why I wrapped up the sandboxing logic inside HAVE_CAPSICUM | ||
| + | * Testing fsck_msdosfs was similar to fsck_ffs | ||
| + | |||
| + | **Code** | ||
| + | * [[https:// | ||
| + | |||
| + | ==== file(1) ==== | ||
| + | |||
| + | * file(1) was a little difficult to understand at first to be able to begin sandboxing it | ||
| + | * I started with Allan Jude's revision, wherein he opened a set of file descriptors prior to entering the capability mode and then provided these descriptors to the functions which needed them | ||
| + | * I tried to reciprocate a similar approach wherein I used cap_fileargs to open those descriptors and then feed them to the functions wherever needed | ||
| + | * It required changes in the libmagic and file(1) logic, which as a matter of fact lived inside file's src directory together. | ||
| + | * The application works if a file is provided to it in an argument, but breaks for the case wherein a file with the paths of all those files which are to be checked is given | ||
| + | * This requires a little change in the code, which is not trivial and I am yet working on it | ||
| + | * The moment I am able to resolve this, I should be able to send a diff and see file(1) running in a sandbox | ||
| + | |||
| + | **Code** | ||
| + | * [[https:// | ||
| + | |||
| + | ===== Testing ===== | ||
| + | |||
| + | * I used ktrace and truss actively to trace the system calls and test the code. | ||
| + | * Testing of traceroute6 could not be done effectively because my ISP does not provide me with V6 connectivity, | ||
| + | * Testing of fsck, fsdb utilities required me to create fake disks using mdconfig and create inconsistencies in them and then try to fix them up | ||
| + | |||
| + | ===== Future ===== | ||
| + | |||
| + | This year, %%GSoC%% was a tremendous learning experience for me, wherein I worked for hands on modifying legacy applications and understand the logic that they use. Trying to sandbox an application requires you to understand the underlying logic that the application uses, then only we can begin sandboxing it. Everything from writing a UDP header for traceroute to utilizing the casper services for our purpose, analyzing the different approaches, and understanding which one to choose added immensely to my learning curve. | ||
| + | |||
| + | I plan on staying in touch with my mentors and sandboxing file(1) and then start picking up some advanced work like sandboxing syslogd, which might require writing a new casper service. %%FreeBSD%% community has always been very helpful and supporting, which makes me more excited about working with them ahead in time. | ||
| + | |||
| + | ===== My Fork ===== | ||
| https:// | https:// | ||
| Line 82: | Line 127: | ||
| ===== Useful links ===== | ===== Useful links ===== | ||
| - | https://wiki.freebsd.org/ | + | * [[https://docs.google.com/document/ |
| + | * [[http:// | ||
| + | **My Past Contributions to %%FreeBSD%%** | ||
| + | * [[SummerOfCode2018Projects/ | ||
| + | |||
| + | ---- | ||
| + | |||
| + | {{tag> | ||