[GSOC] capsicum report week8

Joris Giovannangeli joris at giovannangeli.fr
Mon Aug 12 05:23:18 PDT 2013


Hi,

this week I've worked in various things.

* I've implemented connectat/bindat system calls. These syscalls have
the same semantic than connect/bind, but they take a file descriptor as
an extra argument, which represents the context of call. This operation
is only used by AF_LOCAL sockets. The context fd represents the
directory from which the lookup is performed, just like for the *at
syscall familly. The code is finished, but not extensively tested yet.

* I've improve the nlookup code to avoid leaking information when in
capability mode. When NCL_CREATE/NLC_DELETE/NLC_RENAME_DST are set,
before returning errors like EEXIST or ENOENT, a check is performed to
check capability rights. For instance, if EEXIST will be returned but
CAP_UNLINKAT is not set, returns ENOTCAPABLE instead of EEXIST.

* A race can occurs during lookup with rename, hence we need to check if
we are still in the sandbox before returning a nch. Now, the check is
performed even when an error is returned, to avoid leaking information
from outside the sandbox.

* I've ported the capsicum tests from FreeBSD to dfregress.

* I've found a panic in sys_cap_ioctls_limit I don't understand yet. It
looks like the panic occurs in copyin.

* I've start to adapt uipc_usrreq.c code to capsicum. Indeed, SCM_RIGHTS
ancillary data pass file pointers, but descriptor rights are stored in
the file descriptor entry. The code for passing descriptor has to be
adapted to pass the file capabilities too. I've made good progress on
this side (it "works") but the gc stuff to handle fdrevoke is not done yet.

What I need to do next :

* finish to write a good testcase for the rename race and try it on my
code to check it does not occur.

* Fix the current panic in ioctls limit

* Add more ktrace points.

* Do more testing for the new code.


best regards,

Joris


More information about the Kernel mailing list