New capsicum features

Work in progress

This Wiki page is a work in progress and has yet to be reviewed and validated for accuracy.

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:

Current Status

Item

Status

SOURCE

Notes

Write two new capability rights

COMPLETED - NOT COMMITED

//depot/user/oshogbo/capsicum_rights/...

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

/depot/user/oshogbo/capsicum/lib/libc/gen/fts.c

Port wc(1)

COMPLETED - NOT COMMITED

//depot/user/oshogbo/capsicum_rights2/usr.bin/wcc/wc.c

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

r254499

Discussion

"COMPLETED - NOT COMMITED" - mens that these change was not commited to deadline (which was for this project 16 Sep 2013).

Deliverables

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:

  1. Open also current working directory (CWD)
  2. 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.

Perforce

Capsicum

Weekly status report

My blog post related to GSoC

SummerOfCode2013/CapsicumFeatures (last edited 2013-09-16 10:27:32 by MariuszZaborski)