I like to alter my suggestion for one privilege and updated the list of affected syscalls:
PRIV_FILE_IDENTITY_OWNER: Allow the process to benefit from its supplemental rights associated with its identity (euid, egid and associated groups) during file or directory operations that require ownership of the file (e. g. change permission bits/acls, change access and modification times, change group or owner, remove or move in a directory with the sticky bit). To change permission bits/acls of an owned file/directory, the PRIV_FILE_IDENTITY_* privileges that correspond with the permitted/denied operation have to be set as well. Additional rights gained through PRIV_FILE_OWNER and PRIV_FILE_SETID will not be affected. Alternatively, one could define that PRIV_FILE_IDENTITY_OWNER only comes into play if ALL other PRIV_FILE_IDENTITY_* privileges are set. I favour the first solution, what do you think about it? The new privileges willl at least affect utime, open, creat, link, unlink, stat, exec, chmod, chgrp, chown, acl_set, acl_get and opendir. Of course, all these calls will be mapped to the file system vnode operations, but a more or less complete list of syscalls is good in order to modify the corresponding man pages. Concerning my three checking possibilities: Lots of time and work may be saved if there would be no need to report to the user what exactly was the cause of a denied access. Is this reporting really necessary. One could also claim that giving this information to the user, an attacker may gather additional information about the objects in the file system. -----Original Message----- From: [EMAIL PROTECTED] on behalf of Nicolai Johannes Sent: Wed 6/21/2006 1:23 AM To: zfs-discuss@opensolaris.org Cc: [EMAIL PROTECTED] Subject: [Security-discuss] Proposal for new basic privileges related withfile system access checks For my Google Summer of Code project for OpenSolaris, my job is to think about new basic privileges. I like to propose five new basic privileges that relate with file system access checks and may be used for daemons like ssh or ssh-agent that (after starting up) never read or write user specific files: PRIV_FILE_IDENTITY_READ: Allow the process to benefit from its supplemental rights associated with its identity (euid, egid and associated groups) during file or directory operations that require read permissions. Additional rights gained through PRIV_FILE_DAC_READ will not be affected. PRIV_FILE_IDENTITY_WRITE: Allow the process to benefit from its supplemental rights associated with its identity (euid, egid and associated groups) during file or directory operations that require write permissions. or ownership of the file. Additional rights gained through PRIV_FILE_DAC_WRITE, PRIV_FILE_OWNER and PRIV_FILE_SETID will not be affected. PRIV_FILE_IDENTITY_OWNER: Allow the process to benefit from its supplemental rights associated with its identity (euid, egid and associated groups) during file or directory operations that require ownership of the file if PRIV_FILE_IDENTITY_READ and PRIV_FILE_IDENTITY_WRITE are set as well. If PRIV_FILE_IDENTITY_READ and PRIV_FILE_IDENTITY_WRITE are not both present, PRIV_FILE_IDENTITY_OWNER will not grant any supplemental rights. Additional rights gained through PRIV_FILE_OWNER and PRIV_FILE_SETID will not be affected. PRIV_FILE_IDENTITY_SEARCH: Allow the process to benefit from its supplemental rights associated with its identity (euid, egid and associated groups) during directory operations that require search permissions. Additional rights gained through PRIV_FILE_DAC_SEARCH will not be affected. PRIV_FILE_IDENTITY_EXECUTE: Allow the process to benefit from its supplemental rights associated with its identity (euid, egid and associated groups) during directory operations that require execute permissions. Additional rights gained through PRIV_FILE_DAC_EXECUTE will not be affected. If this seems to be too much new privileges, one could merge PRIV_FILE_IDENTITY_EXECUTE, PRIV_FILE_IDENTIY_SEARCH and PRIV_FILE_IDENTITY_READ as well as PRIV_FILE_IDENTITY_OWNER and PRIV_FILE_IDENTITY_WRITE together. So dropping the privileges is almost the same as if the process is running under an uid/egid that does not own any file or have permissions for any file. Only almost the same because dropping the privileges won't allow to access files that have permissions associated with them that deny access with the egid/euid. The new privileges willl at least affect open, creat, link, unlink, stat, exec, chmod, chgrp, chown, acl_set, acl_get and opendir. With dropping PRIV_FILE_ALLOW_IDENTITY_OWNER (and having no privilegs like PRIV_FILE_OWNER/SETID), the process won't be able to create files/directories (every file/directory needs to have an owner and its initial permissions may be manipulated), change permissions or owner/group. But it will still be possible to delete files/directories if everyone may delete this file (and the process would be able to if the new privileges were set). My mentor, Darren Moffat, suggested that I should start integrating the new privileges checks in ZFS, UFS and TMPFS (in this order) and then proceed with the various other file systems. I am relatively certain that I will find the appropriate places in the ZFS code due to the fact that the checks will correlate with the already present checks of the established PRIV_FILE_* privileges. More worries, I have with the checking order. I suggest three possibilities here: Assume that a file should be accessed with access mode initial_access First possibility: 1. Do the ordinary ownership/permission bits/acl check with the initial_access mode. Set ordinary_access to the subset of initial_access that was not granted. Proceed with step 2. 2. Check whether the new introduced PRIV_FILE_IDENTITY_* privileges that correspond to initial_access are all set. If not, set privilege_access to the subset of initial_access, that correspond with the missing privileges and go to step 3, else set identity_access to the empty set and go to step 4. 3. Check whether the access with access mode privilege_access would be possible if the permissions gained through the process' euid/egid and associated groups of the process would not be present. Set identity_access to the subset of privilege_access that was not granted. Proceed with step four. 4. If identity_access is the empty set and ordinary_access is the empty set, return success. Else ff ordinary_access is not empty, the access was not (yet) allowed due to permission bits/acls, if identity_access is not empty, the access was not (yet) allowed due to the missing of the new introduced identity-privileges. Proceed with step 5. 5. Check whether the required already established file-privileges (PRIV_FILE_DAC_*, PRIV_FILE_OWNER, PRIV_FILE_SETID) are set in order to compensate the still missing permissions (contained in identity_access and ordinary_access). If the check fails for none of both sets, return success. If the check only fails for ordinary_access fail without setting a missing privilege in lwp_status_t. If the check fails for both sets or only for identity_access, set lwp_status_t to the missing new introduced privileges (PRIV_FILE_IDENTITY_*). Advantages of this method is that it is easy to report what (acls or identity privileges) exactly denied the access. Unfortunately, some checks will be duplicated in step 1 and 3. Second possibility: 1. Do the ordinary ownership/permission bits/acl check with the initial_access mode. Set ordinary_access to the subset of initial_access that was not granted. Proceed with step 2. 2. Check whether the access with access mode initial_access would be possible if the permissions gained through the process' euid/egid and associated groups of the process would not be present. Set identity_access to the subset of privilege_access that was not granted. Proceed with step 3. 3. For every permission contained in identity_access, check whether the corresponding PRIV_FILE_IDENTITY_* privilege is set (cache already made queries). If so, remove the permission from identity_access. 4. If identity_access is the empty set and ordinary_access is the empty set, return success. Else if ordinary_access is not empty, the access was not (yet) allowed due to permission bits/acls, if identity_access is not empty, the access was not (yet) allowed due to the missing of the new introduced identity-privileges. Proceed with step 5. 5. Check whether the required already established file-privileges (PRIV_FILE_DAC_*, PRIV_FILE_OWNER, PRIV_FILE_SETID) are set in order to compensate the still missing permissions (contained in identity_access and ordinary_access). If the check fails for none of both sets, return success. If the check only fails for ordinary_access fail without setting a missing privilege in lwp_status_t. If the check fails for both sets or only for identity_access, set lwp_status_t to the missing new introduced privileges (PRIV_FILE_IDENTITY_*). Advantages of this method is that it is easy to report what (acls or identity privileges) exactly denied the access. Furthermore, the PRIV_FILE_** privileges are only queried if necessary. Unfortunately, even more checks as in possibility 1 will be duplicated in step 1 and 2. Third possibility: 1. Check whether the new introduced PRIV_FILE_IDENTITY_* privileges that correspond to initial_access are set. Set privilege_access to the subset of initial_access, that correspond with the missing privileges. Proceed with step 2. 2. Check whether the required access with mode initial_access would be possible if the permissions - granting the operations that correlate with privilege_access - gained through the process' euid/egid and associated groups of the process would not be present. If permission is granted, return success, if not set ordinary_access to the subset of initial_access that was not granted and go to step 3. 3. Check whether the required already established file-privileges (PRIV_FILE_DAC_*, PRIV_FILE_OWNER, PRIV_FILE_SETID) are set in order to compensate the still missing permissions in ordinary_access, if so, return success, else, proceed with step 4. 4. Check whether the access with access mode privilege_access would be possible if the permissions gained through the process' euid/egid and associated groups of the process would not be present. Set identity_access to the subset of privilege_access that was not granted. Proceed with step 5. 5. Check whether the required already established file-privileges (PRIV_FILE_DAC_*, PRIV_FILE_OWNER, PRIV_FILE_SETID) are set in order to compensate the still missing permissions contained in identity_access. If the check succeeds, fail without setting a missing privilege in lwp_status_t. If the check fails, set lwp_status_t to the missing new introduced privileges (PRIV_FILE_IDENTITY_*). Advantages of this method is that there is only one (complicated) permission check in case of success. Disadvantage is that if this check fails, a second permission check has to be done and querying for privileges is repeated again. Please feel free to comment on the use / granularity / semantic / naming / implementation / checking order of the new proposed PRIV_FILE_IDENTITY_* privileges. I am also interested in writing some test cases that will check the correct semantic of access checks on files with different permissions and with different privileges set/unset by the process. Are there already file access test cases at Sun I may expand? Should test suites for OpenSolaris be written in a special kind or programming languages? Thanks in advance Johannes Nicolai _______________________________________________ security-discuss mailing list [EMAIL PROTECTED] _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
