[cap-talk] versioning/translating an API syscall & __syscall

[John Carlson]

Referencing /usr/include/sys/syscall.h, I see a list of system calls.
0 syscall
	We shouldn't allow everyone access to every system call.  Thus this  
would be removed in a capability system
1 exit
	Should processes be allowed to terminate themselves?  I would say  
this applies to a capability system as well
2 fork
	We shouldn't allow a program to create so many processes that it  
overwhelms the system.  Otherwise I think this is okay
3 read
	since this takes a file descriptor, which is a capability, it is  
somewhat okay.  We should probably have capabilities for reading and  
writing, which is defined by open, see below

4 write
	since this takes a file descriptor, which is a capability, it is  
somewhat okay.  We should probably have capabilities for reading and  
writing, which is defined by open, see below
5 open
	is nasty.  It uses ambient authority to create capabilities.  The  
path to open shouldn't start at /, it should start at the current  
directory, I think.  So
open needs capability to the current directory, and a capability to  
the file to open.  Perhaps we should ignore open, and just provide a  
way to read capabilities in a folder.  Maybe more people can help here  
with what we need to replace open.  The basic things we need to have  
are (readonly, writeonly, readwrite, nonblock, append, create,  
truncate, open exclusive, shared lock, exclusive lock).  It would be  
nice to have some way to replace a path with the final file capability  
we are trying to access.
6 close
	closes/revokes a capability.  Should be okay.
7 wait
	I'm unsure of the security implications of waiting for a process to  
exit
9  link
	These use ambient authority to view file system.  This is essentially  
is adding a file capability to a folder capability
10  unlink
	This would remove a file capability from a folder capability
12 chdir
	This would be removed and replaced by the fchdir
13 fchdir
	Change the current folder to a capability
14 mknod
	We would make the path a put into a folder capability
15 chmod
	Works on ambient authority.  Would be replaced by what we use in fcmod
16 chown
	There are no owners in a capability system.  bye!  We would probably  
have some kind of communication identification however.
17 obreak (brk?)
	Use mmap instead.
18 fstat
	Gets  information about a file.  The ambient authority ones are  
thrown out or uses a relative folder path.  This should take a file  
capability.  Owner and group aren't relevant.  Permissions aren't  
relevant
20 getpid
	I'm not sure if a process requires its id
23  setuid
	I'm not sure we want to change user ids in the system
24 getuid
	I'm not sure if we want the user to be able to get their user id
25 geteuid
	I'm not sure if we want the user to get the effective user id
26 ptrace
	The calling process would have to have a capability to control the  
other process.  We may want special capabilities on ptrace to support  
various debugging operations.
27 recvmsg
	uses file descriptor capabilities
28 	sendmsg
	uses file descriptor capabilities
29 recvfrom
	uses file descriptor capabilities
30 accept
	uses file descriptor capabilities
31 getpeername
	probably okay, uses file descriptors, unless your worried about  
covert channels through the addresses of the connections
32 getsockname
	probably okay, unless you don't want the process to get at its  
address.  uses file descriptors
33 access
	find out about the operations on a capability
34 chflag
	set rights on a path must not use root "/".  Replace with capability
35 fchflags
	set rights on a capability
36 sync
	probably okay
37 kill
	can only kill with a process kill capability
39 getppid
	not sure we want this, unless the parent gives the child a process  
capability to get the id of the parent
41 dup
	Inalienable right to share capabilities
42 pipe
	creates communication capabilities
43 getegid
	Not sure we need effective group ids
44 profil
	process must have capability to profile itself.
46 sigaction
	process must have capability to install new handlers for signals.   
Would need feedback about what we should allow a process to handle in  
a capability system
47 getgid
	Do capability systems provide getgid?
48 sigprocmask
	same stuff as sigaction
49 getlogin
	If the user is authenticated, get their name.  We may also want this  
to provide the user with their basic set of capabilities
50 setlogin
	This would be used to give the user their basic set of capabilities
51 acct
	restricted auditing call.  Would need to figure out a replacement on  
a capability system, or perhaps allow it.
52 sigpending
	same stuff as sigaction, what do we allow a process to see?
53 sigaltstack
	similar to sigaction, if the user has memory, should we allow the  
user to change where the stack is located?
54 ioctl
	A rat's nest.  Need to replace with a full set of capabilities
55 reboot
	restricted to people who have the capability
56 revoke
	would work on a capability, not a path
57 symlink
	file system capabilities
58 readlink
	file system capabilities
59 execve
	need execute capability, need way to handle interpreters
60 umask
	default capability when creating files
61 chroot
	Ensure the user can't receive capabilities, and nothing in the file  
system is pointed outside the constraining space.
65 msync
	Need permission to persist a block of memory
66 vfork
	yuck
69 sbrk
	like brk
70 sstk
	I don't know what this is
72 ovadvise
	I don't know what this is
73 munmap
	Would need memory capabilities
74 mprotect
	rights amplification and revocation on memory pages.
75 madvise
	Would need special capabilities
78 mincore
	Would need page capabilities
79 getgroups
	Needed?
80 setgroups
	Needed?
81 getpgrp
	Like file system capabilities, but with processes
82 setpgid
	More with process caps
83 setitimer
	Would require clock capabilities
85 swapon
	memory management caps
86 getitimer
	Would require clock capabilities
	

Enough for tonight