PERFORCE change 134745 for review

[Robert Watson]

http://perforce.freebsd.org/chv.cgi?CH=134745

Change 134745 by rwatson at rwatson_freebsd_capabilities on 2008/02/03 21:40:37

	Move TODO list in sys_capabilities.c to global TODO, and reference
	it.  Trim some done items, such as fexecve(2), capability mode
	flagging for system calls from the list on the way.

Affected files ...

.. //depot/projects/trustedbsd/capabilities/TODO#3 edit
.. //depot/projects/trustedbsd/capabilities/src/sys/kern/sys_capability.c#11 edit

Differences ...

==== //depot/projects/trustedbsd/capabilities/TODO#3 (text+ko) ====

@@ -22,3 +22,25 @@
 
 Low-level TODO list:
 
+- Review poll/select/kqueue behavior, and in particular decide if/how we want
+  CAP_EVENT to work.
+
+- UNIX domain socket passing of file descriptors may need modification to
+  take into account indirectly referenced descriptors hung off of
+  capabilities in its GC routine.
+
+- Consider moving to per-class capability masks, such as CAP_SOCK_FOO, and a
+  per-class mask identifying possible rights.
+
+- Look at multi-operation calls such as getsockopt(), setsockopt(), ioctl(),
+  fcntl(), etc, which may have both global implications and also reflect a
+  diverse set of rights.  Should we do something more fine-grained and
+  request a specific capability based on arguments and other context?
+
+- Should there be a priv(9) privilege to expand capability rights?  (no)
+
+- Refine access control on sysctl infrastructure sysctls, such as name
+  lookup, etc.
+
+- mmap(2) needs to look at capability masks, not just file flags to determine
+  maxprot.

==== //depot/projects/trustedbsd/capabilities/src/sys/kern/sys_capability.c#11 (text+ko) ====

@@ -37,29 +37,11 @@
  * nesting, we directly reference the underlying object but with a new mask,
  * rather than referencing the previous capability.
  *
- * XXXRW:
- * - Some operations, such as poll/select/kqueue are explicitly aware of file
- *   descriptors and may need adapting.
- * - UNIX domain socket passing of file descriptors will likely need work,
- *   especially relating to garbage collection.  Do we need to teach the GC
- *   routines to walk through capabilities to the underlying object
- *   descriptors so it knows they are reachable?
- * - The list of capability rights is probably inadequate.
- * - Should there be a privilege to expand capability rights?
- * - Should different underlying object sets have different valid capability
- *   rights?  I.e., CAP_SOCK_*, CAP_VNODE_*, etc?
- * - Need a way to mask system calls based on capability mode and only allow
- *   approved system calls.  A flag in syscalls.master?
- * - Need to refine access control on sysctl infrastructe sysctls, such as
- *   name lookup.
- * - mmap should incorporate capability rights into maxprot, not just file
- *   flags.
- * - Need fexec() or similar primitive to launch code in a sandbox.  What
- *   should this look like?
+ * XXXRW: See the global TODO for things that need to be done.
  */
 
 #include <sys/cdefs.h>
-__FBSDID("$P4: //depot/projects/trustedbsd/capabilities/src/sys/kern/sys_capability.c#10 $");
+__FBSDID("$P4: //depot/projects/trustedbsd/capabilities/src/sys/kern/sys_capability.c#11 $");
 
 #include <sys/param.h>
 #include <sys/capability.h>