New capsicum features
Student: Mariusz Zaborski (<oshogbo AT freebsd DOT org>)
Mentor: Pawel Dawidek (<pjd AT freebsd DOT org>)
Work in progress
This Wiki page is a work in progress and has yet to be reviewed and validated for accuracy.
Contents
Project Description:
During this project I will write new features for Capsicum and I will also port fetch services to use Capsicum. New features in Capsicum will be:
- two new capability rights (CAP_SEND_RIGHTS and CAP_RECV_RIGHTS) for control sending and receive descriptors by Unix domain sockets.
- Implement new services for Casper daemon:
- system.unix - service provides connect and listen on Unix domain socket.
- system.udp - service enabling connect, listen, sending and receive UDP packages.
- close fetch(1) in capability mode.
Current Status
Item |
Status |
SOURCE |
Notes |
Write two new capability rights |
COMPLETED - NOT COMMITED |
Reason, We also need discussion do we need so much change for such little thing |
|
Write system.unix |
INCOMPLETE |
|
|
Write system.udp |
INCOMPLETE |
|
|
Port fetch(1) application |
INCOMPLETE |
|
|
Port rwhod(8) |
COMPLETED - COMMITED |
r252596 r252598 r252602 r252603 r252605 r254480 r254486 r255227 |
|
Port bsdgrep(1) |
PARTIAL COMPLETE |
//depot/user/oshogbo/capsicum_rights2/usr.bin/grepc/...//depot/user/oshogbo/capsicum_rights2/usr.bin/grepf/... |
grepf - bsdgrep using fork technique. grepc - bsdgrep with casper. We still have problem with recursive open file with casper. We don't have service which provides such methods. |
Make fts(3) capability friendly |
COMPLETED - NOT COMMITED |
|
|
Port wc(1) |
COMPLETED - NOT COMMITED |
wcc (wc with casper) |
|
New function fdclose |
COMPLETED - NOT COMMITED |
//depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.c //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.3 |
Reson: code freeze |
New function fdclosedir |
COMPLETED |
"COMPLETED - NOT COMMITED" - mens that these change was not commited to deadline (which was for this project 16 Sep 2013).
Deliverables
- First 3 weeks: Write two new capability rights
- Next 3 weeks: Write system.unix
- Next 3 weeks: Write system.udp
- Next 2 weeks: Port fetch(1) application
- Next 1 weeks: Write documentation for new features and write recommendations how write extensions for Capsicum.
Repository
Problems Encountered
Capsicum relative and absolute path
During porting the bsdgrep(1) I encountered some problems. First assumption of porting the bsdgrep(1) was that all file processing will be done in sandbox. Second assumption was that there will be two process. One will open files descriptor and send it using Unix domain socket to the second process. The second process will process the file and print result. This method is a little more safer because if somebody will give to bsdgrep(1) some prepared file that will be a exploit for the bsdgrep(1) he still don't have access to full root directory and know nothing about rest of files. Of course there is still some risks about that untrusted process but the threat is more smaller. Also the first assumption implies that the -f or --file will be also processed in the sandbox. The problem is that if we fork(2) before parsing arguments program must serve a lot of data using Unix domain sockets (all patterns and flags) which will very complicate the program, so we decided to not processing the given arguments using two process. Those assumption also force us to enter the capability mode as fast as we can (even before the argument parsing step). In the capability mode you can't make any open(2), you can only make openat(2). This force us to open root directory before enter capability mode. Here start the problems. In capability mode we can't give absolute path even if our given file descriptor is pointing to the root. This isn't big problem we even was able to solve it simply skip the first char of absolute path '/'. Then we enter the second problem which are relative path. We only opened the root directory so we have two options:
- Open also current working directory (CWD)
- Try to translate all of given relative path to absolute path
I decided to try the second way. In C library is very useful function called realpath(3). The problem with it was that she use getcwd(3) and lstat(2) (yes, as you predict those function are forbidden in capability mode). So I change a little of it to be a more sandbox friendly (the result you can see here: safe_realpath function. The problem was resolved by add the root file descriptor and the cwd we simply use the cwd instead of the getcwd(3) and we do fstatat(2) with the root file descriptor as argument. With the fts_openat its looks to work fine. Unfortunate this isn't true. Firstly we break a API all of ours path are printed as absolute paths. In original bsdgrep(3) we got path depended of the given argument, here we got always absolute path. This we could solve for example using structure with current name and flag which describe is the path was relative or absolute and write another function which will translate absolute path to the relative path using given cwd. The second and the bigger problem are the symlinks. We can open only symlinks that show to the files in the current or sub directory we can't open the are upon (start with ..) or are the shows to absolute path (start with /). This is also on this day (06 Aug 2013) problem also with my version of fts(3). We could try to do readlink and then translate it to the absolute path and then open it with the root directory. As you can see all those thinks start be a little bit complicate. For now we decided to suspend the full bsdrep(3) and sandbox only the parsing part. It is the chance we will go one step further and create fts(3) which will do all those thinks.
Links
Perforce
Capsicum
Weekly status report