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, 0 insertions, 766 deletions
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn deleted file mode 100644 index 85695978..00000000 --- a/community/gsoc/project_ideas/libcap/details.mdwn +++ /dev/null @@ -1,766 +0,0 @@ -[[!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 |