diff options
Diffstat (limited to 'community/gsoc/project_ideas/libcap/details.mdwn')
| -rw-r--r-- | community/gsoc/project_ideas/libcap/details.mdwn | 766 |
1 files changed, 766 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn new file mode 100644 index 00000000..85695978 --- /dev/null +++ b/community/gsoc/project_ideas/libcap/details.mdwn @@ -0,0 +1,766 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Details on implementing libcap"]] + + +This is the proposal submitted by David Hedberg for GSoC 2010 (who opted +to go with another mentoring organization), adapted from an initial +proposal and several amendments into a single document, but the idea +is to further adapt it to a more neutral design document over time. + + +# The proposal + +### Quick description of POSIX capabilities + +The original suggestion can be found [[here|libcap]]. +POSIX capabilities never actually entered the POSIX standard but was +left as a draft. Linux has nevertheless implemented this draft, and +there are reasons for doing the same in the Hurd - a more fine grained +control of rights leading to increased security being one of them. + +POSIX capabilities are give on a per-process basis, and basically allows +splitting up those rights usually granted to root into smaller and more +specific rights. Examples of capabilities are CAP_CHOWN and CAP_KILL, +overriding certain restrictions on chown and allowing the process to +kill processes with different UID's, respectively. + +Each process is given three sets with capabilities: the Permitted set +(P), the Effective set (E) and the Inheritable set (I). The effective +set contains the capabilities that are currently active. The permitted +set contains the capabilities that the process has the right to use. +The inheritable set contains the capabilities that can be inherited +by children to the process. A process can drop capabilities from its +permitted set, but not set them. The effective set and the inheritable +set can be changed freely as long as they stay subsets of the permitted +set. + +Capabilities can also be set on executables. When executed, the resulting +process is given the capabilities both as defined by the parent process +and by the capabilities set on the file (formula below), resulting in +what might be explained as a fine-grained setuid. Implementing this +requires support for *xattr* or similar. + +Some applications that are currently using capabilities are samba, ntp, +vsftp, pure-ftpd, proftpd, squid, asterisk and dovecot. + + +### A quick description of capabilities in Linux + +Each process has a three bit fields representing each of the three +sets (P, E and I). Each bit field is currently built up of two (32 +bit) integers to be able to hold the 33 currently defined capabilities +(see linux/capability.h). Each process further has a bounding set which +bounds the permitted set. Two [[system call]]s handles the setting and getting +of capabilities; *capset* and *capget*. Some related functionality +can also be controlled by calling *prctl*: the right to read/drop the +bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether +or not the process should keep its capabilities when a change is made +to the threads UID's (PR_SET_KEEPCAPS/PR_GET_KEEPCAPS). User space +applications are expected(recommended?) to use libcap to take advantage +of the functionality provided. Some applications also use libcap-ng +which is "intended to make programming with POSIX capabilities much +easier than the traditional libcap library". Most applications seem +to be using the original libcap, however. + + +## Implementing libcap + +The exercise for this assignment was to get the libcap used in +Linux to compile under the Hurd. This was accomplished using the +latest git version of libcap from (..), corresponding to libcap +2.19. The changes were simple and amounted to simply removing the +dependency on some Linux-specific headers and creating stubs for +capset, capget and prctl described above. This suggests that porting +this library to the Hurd once the proper functionality is in place +could be relatively simple. The patch is available +[here](https://alioth.debian.org/tracker/index.php?func=detail&aid=312442&group_id=30628&atid=410472 "Alioth"). +One could also consider implementing the three missing functions in the +Hurd (or Hurd glibc) which would allow the usage of the Linux libcap +without modifications. As the Linux libcap maintainer might or might +not be interested in making libcap multi platform, this approach might +be preferable. + + +## Implementing POSIX capabilities in the Hurd + +As I am still reading up on how things fit together in the Hurd this is +very likely to contain some misunderstandings and be at least partly off +the mark. I intend to have grasped this by the time I start working on +it however, if I were to be given the chance. Below are two possible +approaches as I have understood them after some reading and discussions +on #hurd@freenode. + + +### The basics, Approach 1: Special UID's + +Let each capability be represented by a specific UID. One could imagine +reserving a range of the possible uid_t's for this purpose. The euids +vector in the authhandle struct could perhaps hold the effective set while +the auids vector could hold the permitted set as these seem to roughly +correspond to eachother in intent. This leaves the Inheritable set. +One solution could be to store the inheritable set in the agids vector, +but that does not seem to be a very natural nor nice solution. One could +extend the authhandle struct with an additional vector, but one would then +need to also extend the auth interface with RPC's to be able to modify +and access it. Another possibility is to store all the capabilities +in the same idvec and use separate defines for the the different sets +(CAP_P_CHMOD, CAP_E_CHMOD, CAP_I_CHMOD). This does not seem like a +good solution. + +Storing each capability in its own uid_t might also arguably be somewhat +wasteful, although this is probably of secondary concern (if at all). +One could also imagine that legacy applications might be confused, +although I am not sure I can see any obvious problems. What happens +when a process have only capability id's? + + +### The basics, Approach 2: Extend the auth interface + +This approach would expand the auth interface and extend +the auth server with another set of RPC's for capabilities +(*auth_getcaps*, *auth_makecaps*, *auth_user_authenticate* and +*auth_server_authenticate*), mirroring those currently declared for id's. +This would obviously require changes to more parts of the Hurd for +processes to be able to take advantage of capabilities, but as the logic +behind handling capabilities and that behind handling user id's might +not be completely comparable, this might make for a cleaner solution. +It would also remove the problem of having to sensibly map all the +three capability sets onto semantically differing sets of user/group +ids, something that might be even more important if we were to also +implement something like the bounding sets used in Linux or perhaps +other related functionality. We are also not limited to having to store +the capabilities as id vectors, although doing so would perhaps still +make sense. + + +### The individual capabilities + +Implementing the individual capabilities will probably have to be thought +of on a case-by-case basis. Taking chown (in *libdiskfs*) as an example, +the exact approach would differ slightly depending on how the approach +taken to implement capabilities. If the first approach were to be taken, +the UID's (and thus the capabilities) of the caller would already be +available to the function through the *iouser* struct contained in the +*protid* struct given as the first argument. Implementing capabilities +would then simply be a matter of checking for the special UID's. If the +second approach were to be taken, one would need to perhaps expand the +iouser struct to contain information about the capabilities. + +Just like Linux has defined many Linux-specific capabilities - some of +which could certainly be useful also applied to the Hurd - one could +also imagine extending the POSIX capability system also for Hurd specific +purposes. + + +## Some applications using capabilities + +#### Samba 3 + +Uses CAP_MKNOD and CAP_LEASE in smbd to only keep the necessary abilities. +Documentation mentions CAP_LINUX_IMMUTABLE as a way to protect files +from being deleted. Can also use a couple of IRIX specific capabilities +(CAP_NETWORK_MGT and CAP_DEVICE_MGT) as alternatives to the Linux-specific +ones if running on IRIX. + + +#### ntpd + +Checks if capabilities are supported, more precisely if CAP_SYS_TIME, +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT and CAP_NET_BIND_SERVICE are +supported. If they are supported, it uses prctl with PR_SET_KEEPCAPS +to keep privileges across setuid() and then drops root. After done with +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT it drops every capability except +CAP_SYS_TIME and, if needed, CAP_NET_BIND_SERVICE. + + +#### vsftpd + +Uses CAP_CHOWN, CAP_NET_BIND_SERVICE when using the "one process" +security model (typically disabled by default). + + +#### proftpd-basic + +Provides support for capabilities from mod_cap. Uses CAP_USE_CHOWN, +CAP_USE_DAC_OVERRIDE, CAP_USE_DAC_READ_SEARCH and CAP_USE_AUDIT_WRITE. +Distribution contains README.capabilities with some explanations. +Also ships with their own libcap for some reason, based on libcap 1.10. + + +#### dovecot + +Keeps CAP_CHOWN, CAP_SYS_CHROOT, CAP_SETUID, CAP_SETGID, +CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE for proper operations, drops +the rest. + + +#### bind9 + +Reasons for each capability are clearly noted in comments in update.c +in linux_initialprivs() and linux_minprivs(). initialprivs drops all +capabilities and proceeds to set CAP_NET_BIND_SERVICE, CAP_SYS_CHROOT, +CAP_SETUID, CAP_SETGID, CAP_DAC_READ_SEARCH and CAP_CHOWN. minprivs only +sets CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE. + + +#### pulseaudio + +Mentions CAP_NICE (CAP_SYS_NICE), but does not appear to be using it +(anymore?). Seems to use libcap to drop caps, however. + + +#### pinentry + +Checks if CAP_IPC_LOCK is available and "uses it" to gain only the +ability to lock memory when needed. + + +#### zsh + +Comes with a module "caps" which contains "[b]uiltins for manipulating +POSIX.1e (POSIX.6) capability (privilege) sets." Most useful here is the +"cap" builtin, which makes it possible to change the shell's process +capability sets. This might be useful for testing. + + +#### inetutils (ping,traceroute) + +Does not use capabilities explicitly, but is nevertheless a useful +example of how file capabilities could be used. ping and traceroute +are currently installed suid root since they need to be able to open +raw sockets. With file capabilities, this could be accomplished by +instead setting the capability CAP_NET_RAW on the two executables, +thus giving the utilities almost only the specific rights they need. + + +## The capabilities + +The above might give some hint as to what capabilities should be +prioritized. One assumption I have made is that the goal of this project +is to implement, as far as possible, the same functionality as what is +present in Linux. No effort has (so far) been made to look into possible +applications specific to the Hurd. + +A few of the above mentioned applications also explicitly uses +PR_SET_KEEPCAPS (through prctl()) to specify that capabilities should +be passed on to children. This means that the implementation in the +Hurd should take this into account. + +I have below done a preliminary classification of the capabilities +as defined in Linux capability.h into four "classes": Network, File +management, "glibc -> mach" and Other. There are also some capabilities +that either depend on functionality not implemented or are too Linux +specific. I have not described each capability in detail as looking +at the comments in capability.h and reading in capabilities(7) are +better sources. + + +### The Networking Class + +These would mostly affect pfinet. The general picture seem to be that +pfinet currently uses a boolean (int) isroot in struct sock_user to keep +track of the credentials of the caller. This would need to be expanded +somehow to keep track of the separate capabilities. + +CAP_NET_BIND_SERVICE: Allow binding to TCP/UDP sockets below 1024 +CAP_NET_RAW: Allow use of RAW and PACKET sockets. +CAP_NET_BROADCAST: "Allow broadcasting, listen to multicast" +CAP_NET_ADMIN: This seem to be a bit of a "catch-all" for network-related +administration. + + +### The Files Management Class + +The description of CAP_CHOWN in the original proposal should apply to +(most of?) these. That is, modify the iouser struct. At least libdiskfs +should be modified, but the same or similar modifications might need to +be made to several servers (libnetfs..? The actual servers implementing +the filesystem?) + +CAP_CHOWN: "Make arbitrary changes to file UIDs and GIDs" +CAP_FOWNER: allow chmod, utime, .. for files not owned. +CAP_FSETID: Don't clear setuid/setgid when a file is modified. +CAP_DAC_OVERRIDE and +CAP_DAC_READ_SEARCH: Bypasses file/directory read/write/execute permission +checks. ( hurdexec.c, file-access.c, .. ? ) +CAP_MKNOD: allows usage of "the privileged aspects of mknod()". Does this +one make sense in the Hurd? + + +### The (glibc -> gnumach) Class + +These seem to be implemented in glibc by direct calls to gnumach. +If they should be implemented, maybe a proxy in the Hurd is needed? + +CAP_SYS_TIME: manipulate the system clock, set real-time clock. +CAP_IPC_LOCK: mlock, mlockall, mmap, shmctl +CAP_KILL: No permission checks for killing processes +CAP_SYS_NICE: setpriority/getpriority for arbitrary processes. + + +### The Rest Class + +CAP_SYS_CHROOT: Allows usage of chroot(). +It's either really simple (not needed in the case of the Hurd) or really +difficult. Needs some figuring out. One of the calls that should be +high-priority. +CAP_SYS_ADMIN: General administration rights. Seemingly sprinkled out +into just about everything. Quick grep through the Linux sources gives +440 hits in .c-files. +CAP_SYS_BOOT: Allow use of reboot(). +glibc calls init:startup_reboot.. +CAP_SETGID: Allows usage of setgid,setgroups and "forged gids on socket +credentials passing" +CAP_SETUID: Allows usage of set*uid and "forged pids on socket credentials +passing" +CAP_SYS_TTY_CONFIG: vhangup, some other places. vhangup() is a stub in +the Hurd, but maybe the console server is otherwise affected? +CAP_SYS_RESOURCE: Override various limits. (quota, reserved space etc. +on ext2, interrupt frequencies, consoles,...). According to "The Critique" +mach performs no resource accounting so some of these might be moot to +implement, while others still apply. +CAP_SYS_RAWIO Allow raw input/output. Sprinkled in many places, +device drivers among others. Many of these will probably be difficult +to implement. +CAP_SETPCAP: This one has (or had?) two different usages in Linux: +If file capabilities are not supported it gives the right to grant +or remove capabilities from the permitted set of arbitrary processes. +If file capabilities are supported, it allows for removing capabilities +from the bounding set of the current process. As the Hurd implementation +won't have file capabilities initially it might make sense to implement +this if possible. If bounding sets are implemented this should probably +be the way provided to modify them. + + +### Unimplementable + +*(At this point in time, as far as I can determine)* + +CAP_LINUX_IMMUTABLE: depends on chattr etc. working. +CAP_SETFCAP: depends on xattr's +CAP_SYS_PACCT: acct() missing in the Hurd. +CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_MAC_OVERRIDE, CAP_MAC_ADMIN, +CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL, CAP_LEASE + + +## Priority when implementing + +The two most used capabilities as unscientifically judged from +the selection of applications above are CAP_NET_BIND_SERVICE and +CAP_CHOWN, suggesting that implementing the "network class" and the +"file management" class of capabilities as classified above might be a +good start. These also, to me, seem to be easier classes to implement. +CAP_NET_ADMIN might need some extra work. + +Second most common were CAP_SYS_CHROOT, CAP_SETGID and CAP_SETUID. I am +not completely clear on how these should be handled. + +Assuming those are out of the way, CAP_IPC_LOCK, CAP_SYS_TIME, CAP_KILL +and CAP_SYS_NICE might be a good choice to tackle if possible. This +might, if I have understood things correctly, involve writing a proxy +Hurd server for these calls in mach. + +CAP_SYS_ADMIN, CAP_SYS_RESOURCE and CAP_SYS_RAWIO. These contains a bit +of "everything" (ADMIN being the worse one), meaning that experience +and infrastructure gained from implementing the previous capabilities +might come in handy. CAP_SYS_RAWIO might be difficult; it can be found +inside many drivers in the Linux source. + + +## Additional general details + +[This article](http://www.ibm.com/developerworks/library/l-posixcap.html) +contains a good general description of how capabilities in Linux +works. As there will be no file capabilities in the Hurd initially, +an approach emulating the behavior Linux exhibits when SECURE_NOROOT +and SECURE_NO_SETUID_FIXUP are *not* set seems to be a good start. +This is called the "root-user-is-privileged" model in the article, +and somewhat simplified it means that processes started by root, or +setuid-root, is given all capabilities no matter what capabilities the +parent might or might not hold at the time of execution. Quoting verbatim +from the article: + +> * When SECURE_NOROOT is not set, then when a process executes a file, +> the new capability sets may be calculated as though the file had some +> file capability sets set fully populated. In particular: +> +> * The file inheritable and permitted sets will be full on if the +> process's real or effective uid is 0 (root) or the file is setuid +> root. +> +> * The file effective set will be full on if the process's effective +> uid is root or the file is setuid root. +> +> +> * When SECURE_NO_SETUID_FIXUP is not set, then when a process switches +> its real or effective uids to or from 0, capability sets are further +> shifted around: +> +> * If a process switches its effective uid from 0 to non-0, then its +> effective capability set is cleared. +> +> * If a process switches its real, effective, or saved uids from at +> least one being 0 to all being non-zero, then both the permitted +> and effective capabilities are cleared. +> +> * If a process sets its effective uid from non-zero to 0, then the +> effective capabilities are set equal to the permitted capabilities. + +The capabilities of the resulting process are determined by the following +formulas, again taken from the article, with p for Process and f for file: + +> pI' = pI +> pP' = fP | (fI & pI) +> pE' = pP' & fE + +The security under the above described model, being what at least some +of the applications I listed in my last comment employs, is basically +the following (also detailed somewhat in the same article): + +* Execute process as root (or setuid) to gain all capabilities. + +* Use the prctl [[system call]] to enable keepcaps for the process + (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process). + keepcaps should be off by default. + +* setuid to a non-root user, and by doing so losing the possibility to + regain capabilities by simply starting a new process. + +* Drop all the capabilities except those few actually needed. + + +## Infrastructure details - Special UIDs approach + +The auth server must somehow keep track of three sets of capabilities. +I suggest keeping these three sets in three additional idvec's in the +authhandle struct, and will for the purpose of this description name +these pcaps (permitted), ecaps (effective) and icaps (inheritable). +This will simplify keeping track of the internal logic somewhat. +In addition to this, there is a need to keep track of the "keepcaps" flag +as described above. I suggest representing this with an int keepcaps +in the same struct. + +1. Expand authhandle struct with three additional idvecs and one integer. +Fix static functions handling the struct, such as destroy_authhandle. + +2. Implement the necessary logic in auth_makeauth to handle capabilities. + +Problems: +Assume that all capabilities are mapped onto uids, given names on the form +uid_<capability>, for example uid_cap_net_raw. Assume that the presence +of an uid in euids suggest that the capability is in the effective set +of the process, that the presence of this uid in auids suggests that it +is in the permitted set of the process, and that the presence of this +uid in aguids suggest that it is in the inheritable set of the process. +That they are internally stored in separate idvec's can be ignored as +an implementation detail. + +* The UID's have as it is different meanings depending on where in the + array they are positioned, and certain clients seem to rely on this. + The first UID in euids is the effective uid, and the first and second + UIDs in auids are the real and saved UIDS respectively. At least + some users of makeauth would need to made aware of capabilities, + for example setuid in glibc. + +* Setting/getting the keepcaps-flag is also a bit of a problem. To avoid + changing the auth interface yet another special UID could be used + for this purpose, although that seems to be really stretching it. + The cleaner solution would probably be to expand the interface with + something along the lines of auth_setkeepcaps/auth_getkeepcaps. + This interface would only be used by prctl. + +Another problem with this approach is that it seems a bit difficult +to oversee the affects that using other RPC's like fsys_getroot and +io_restrict_auth might have on capabilities. + + +## Infrastructure details - "extend-interfaces" approach + +This approach has started to seem like the better way to me, as the +usage of capabilities becomes more explicit through the entire "chain", +perhaps making it somewhat more easy to understand all the interactions. + +I suggest something like the following new interface methods: + +*** + + +### The auth interface + + routine auth_getauth_caps ( + handle: auth_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + routine auth_makeauth_caps ( + handle: auth_t; + other_handles: portarray_t; + euids: idarray_t; + auids: idarray_t; + egids: idarray_t; + agids: idarray_t; + ecaps: idarray_t; + pcaps: idarray_t; + icaps: idarray_t; + flags: int; /* keepcaps.. ? */ + out newhandle: mach_port_make_send_t); + + routine auth_server_authenticate_caps ( + handle: auth_t; + sreplyport reply: mach_port_poly_t; + rendezvous: mach_port_send_t; + newport: mach_port_poly_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + +### The io interface + + routine io_restrict_auth_caps ( + io_object: io_t; + RPT + out new_object: mach_port_send_t; + uids: idarray_t SCP; + gids: idarray_t SCP; + ecaps: idarray_t SCP); + + +### The fsys interface + + routine fsys_getroot_caps ( + fsys: fsys_t; + RPT + #ifdef FSYS_GETROOT_UREPLY + ureplyport ureply: mig_reply_port_t; + #endif + dotdot_node: mach_port_send_t; + gen_uids: idarray_t; + gen_gids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t; + flags: int; + out do_retry: retry_type; + out retry_name: string_t; + out file: mach_port_send_t); + +*** + +These are meant to be able to replace the old methods with +capability-aware methods, instead of merely complementing them. +The replacing work could then be made a more gradual process. Steps: + +* Extend authhandle with the same data members as in the UID-case. + +* Implement new _caps-functions according to described interface + extensions above, refactor code a bit to share common uid-handling + logic. Both makeauth's should drop all capabilities if switching from + uid 0 without having keepcaps. For example, keepcaps should be unset + by default. + +* Fix glibc. Extend hurd_id_data in hurd/id.h to store capabilities, + switch to capability aware functions where necessary. + +* io-reauthenticate. Fix implementations to use + auth_server_authenticate_caps instead. For this we also need somewhere + to save the caps, so it ties in with for example the extension of + iouser as mentioned in the details. + +* fsys_getroot. Implement fsys_getroot_caps in libdiskfs, trans, + libtreefs, libtrivs, libnetfs. Fix users of function in libdiskfs, + libfshelp, settrans, libtreefs, clookup. + +* io_restrict_auth. Implement io_restrict_auth_caps in libdiskfs, + libtreefs, libtrivfs, libnetfs, boot. Fix users in utils(symlink, + firmlink), libtrivs, term, clookup + +Among the problems might be that there are a lot of arguments that +needs to be passed around, and that it seems somewhat ugly to end up +with function names referencing caps in particular. + +Below some more about the specific capabilities. This should in large +be common to the two approaches above. + + +## Actually handing out the capabilities to process + +This seems like a good job for the file_exec route in the fs interface. +Quoting from the comments above the definition in fs.defs: "*Necessary +initialization, including authentication changes associated with set[ug]id +execution must be handled by the filesystem*". The capability-granting +functionality should to be added in at least the implementations in +libdiskfs and libnetfs as far as I can determine, and should be "easy +enough" once the infrastructure for implementing the file-related +capabilities (CAP_CHOWN etc.) are in place. This also seem to make +sense considering the future possibility for file capabilities. + + +## Some implementation details of individual capabilities. + +### Net-related capabilities. + +This turned out to be a bit less work than I had thought, as the +imported Linux code already seem to contain all the necessary checks. +What remains to do to implement all of these capabilities is mostly a +matter of putting some infrastructure in place. + +* In struct sock_user (pfinet.h), change isroot for idvec + caps. Alternatively, add idvec caps. + +* Change the function make_sock_user in socket.c to take an idvec caps + as a parameter and properly set the given caps to the corresponding + idvec in sock_user. + +* Fix users of make_sock_user: S_io_reauthenticate, S_io_restrict_auth, + S_socket_create, S_socket_accept. This should be doable with the + current infrastructure. For example, S_socket_create currently + sets isroot in the new sock_user from the corresponding member in + the trivfs_protid struct. This does not present a problem however, + as the latter struct also provides access to an iouser (iohelp.h) + from which the needed uids of the user should be available. + +* Fix up parts of source from Linux, modify task_struct add idvec, + modify prepare_current to take the caps idvec instead of isroot. + Re-implement the existing function capable(int cap) to actually check + for the capability passed as an argument instead of just return isroot. + +* Change a few isroot's at 3 other places in the code to check for + capabilities. Since these places all have access to isroot and thus by + implication the sock_user, they also have access to the new capability + information; no restructuring necessary. + + +### File-related capabilities + +While there are a lot of servers in the Hurd, I am not sure all of these +capabilities actually make sense to implement in all of them. + + +#### CAP_CHOWN + +Implementing this in libdiskfs should take care of it where it makes +sense. Servers using libdiskfs uses iouser from libiohelp to hold +user credentials. As noted above, this struct is already capable of +holding our capabilities as uid's or is otherwise extended to contain +the necessary idvecs if using the second general approach. Adding a +check along the lines of *idvec_contains(uid_cap_chown)* in function +diskfs_S_file_chown (file-chown.c) should be all that's needed. + +In libnetfs, netfs_attempt_chown is declared as a function that the +server using the library must implement. Any checks for chown rights +are however most likely performed on the server side, suggesting that +there is nothing we can do here to implement CAP_CHOWN. Even if we do +need to add something, an iouser containing the necessary information +to implement the checks in a manner analogous to that in libdiskfs seems +to be passed to each important function. + + +#### CAP_DAC_* + +These might actually make sense to implement in more servers, and the +logic seems somewhat involved. Need to add the necessary checks to +at least file_check_access, file_exec in libdiskfs. file_exec also in +libnetfs, probably. Possibly changes also in other places. + +The main difficulties overall seem to lie in getting the infrastructure +properly in place rather than implementing most of the individual +capabilities, and I have updated the schedule a bit in an attempt to +reflect this. + + +## Schedule updating + +The more I look into this the less time it seems likely to take to +do the work. Below is my best estimation at the moment, and I have +basically adjusted everything to what I think is more likely estimations. +If this is correct I would be more or less around midterm. I haven't +gone completely to the individual level as that doesn't seem to make +sense, but what is clustered together are either related capabilities +or a collection of capabilities classified roughly with regards to how +much I know about the area and how many different rights they control. +It's not my intention to "slack off" or anything, so if this estimation +were to be correct I could perhaps take a look at the xattrs-patch, +or spend the rest of my time fixing PATH_MAX-issues. Then again, maybe +there is some great difficulty hidden somewhere. + + +#### Some justifications: + +Dummy libcap, more or less done. +*1 day* (making sure it "fails gracefully" shouldn't really take longer than this) + +Application for testing, the beginnings of a fairly extensive "test suit" on Linux. +*2 days* + +Basic infrastructure. +*5 days*, depends on the chosen approach, but it is probably wise to +reserve at least a bunch of days for this. + +Implementations of prctl/capset/capget in libshouldbeinlibc, +or a port of libcap to the Hurd in any other way. +*5 days* + +CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_NET_BROADCAST, CAP_NET_ADMIN +*4 days*, as noted above this should be easy, but it might uncover bugs +in the newly implemented infrastructure for example. + +CAP_CHOWN,CAP_FOWNER,CAP_FSETID +*2 days*, I think these only needs to be done in libdiskfs + +CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH +*4 days*, these might need changes to various servers + +CAP_SYS_TIME,CAP_IPC_LOCK,CAP_KILL +CAP_SYS_NICE,CAP_SYS_CHROOT,CAP_SYS_BOOT +*2 weeks*, these are varied and I'm not that sure exactly how each should +be tackled so some research is needed. + +CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +*4 days* + +CAP_SYS_ADMIN,CAP_SYS_RESOURCE,CAP_SYS_RAWIO +*2 weeks*, these too are pretty varied and some might need some individual +researching + +CAP_SETPCAP +*1 day* + + +## Schedule + +24/5 Start coding +25/5 Dummy libcap ready for use. +27/5 The beginnings of a "test suite", written on Linux. + 1/6 Basic infrastructure in place + 6/6 Dummy libcap extended with real functionality to make use of + implemented capability and infrastructure, or the Hurd adapted for + compatibility with Linux libcap. +10/6 The "network class" of capabilities implemented. +12/6 CAP_CHOWN, CAP_FOWNER, CAP_FSETID +16/6 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH +30/6 CAP_SYS_TIME, CAP_IPC_LOCK, CAP_KILL, CAP_SYS_NICE, + CAP_SYS_CHROOT, CAP_SYS_BOOT + 4/7 CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +12/7 "Mentors and students can begin submitting mid-term evaluations" +16/7 GSoC Mid-term evaluations deadline. +18/7 CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_SYS_RAWIO +19/7 CAP_SETPCAP |