After reading the mails concerning my proposal on the list, I realized the points that were not clear enough in my proposal.
First of all, I totally aggree with all your statements, if the new privileges were not basic privileges. All new privileges are basic privileges. So they will be present in most of all cases. They do not grant any additional rights for a process. They are like the exec or fork basic privileges: They only get intersting, if the process does not have them. With dropping the new introduced privileges, the process will "give up" its identity. That means, all granting permissions that correspond with euid or groups associated with the process does not matter any more. Processes like ssh-agent that do not need their "identiity" may drop them. An exploit too these processes may not exploit the fact, that the euid/groups of the process allow some file operations that are denied to everyone. Only files that are globally readable/writable/executable may still be accessed (if there is no rule that denies the access for the identity of the process). Many daemons never ever need to read/write files that are only accessible due to the fact that they run under a special euid/egid/belong to special groups or only need these rights in the starting phase and drop them later. Dropping the privileges may also be used to enforce some kind of mandatory access control: An administrator that does not want some users to change permission of files may withdraw PRIV_FILE_IDENTITY_OWNER in their login shell. To enforce these privileges, one have to modify the permission checking order. In the normal case when all basic privilegs are given, nothing will change. I hope that I have made my intentions clearer. Perhaps you may provide me with hints what clauses in my proposal caused all the confusion so that I can correct them. Johannes -----Ursprüngliche Nachricht----- Von: Mark Shellenbaum [mailto:[EMAIL PROTECTED] Gesendet: Mi 21.06.2006 21:21 An: Nicolai Johannes Cc: [EMAIL PROTECTED]; zfs-discuss@opensolaris.org Betreff: Re: AW: [zfs-discuss] Proposal for new basic privileges related with filesystem access checks Nicolai Johannes wrote: > Thank you for your hints. > > I already investigated the zfs/ufs/tmpfs code when I wrote my proposal. > When I wrote check if set, I mean doing this with new secpolicy_vnode_* > functions. The check for the already existing privileges would of course stay > in secpolicy_vnode_owner and secpolicy_vnode_access. > The proposed checking order is of course only relevant for permission checks. > For changing permissions, I think, the new checking order is rather clear and > was not explicitely mentioned: > Just so I am understanding this correctly. All of the PRIV_IDENTITY_* privs look only at euid or egid? Are the below steps for doing a chmod(2)? > 1. Check whether process is owner of the file, if not go to step 3, else > proceed with step 2. > 2. Check whether PRIV_FILE_IDENTITY_OWNER as well as all PRIV_FILE_IDENTITY_* > privileges that correspond with the new permissions are set. If so, change > permissions and return success, else go to step 3. > 3. Check whether PRIV_FILE_OWNER is set, if so change permissions and return > success, else determine whether we come from step 1 or two and report mssing > ownership or missing priviileges to the user. > You can't break the access control rules for ZFS that are enforced by the NFSv4 spec. Typically an ACL for ZFS will be laid out so that the owner will be checked first, but a user could reconstruct an ACL so that isn't true. For UFS the owner will always be checked for first. The rules pretty much have to be: 1. file system checks to see if access should be granted, based on permission bits or file ACL. When a file has an ACL it could be either an additional access control method or an alternate in POSIX terminology. It depends on the file system which it is. 2. If access can't be granted then the file system asks the priv code if it wishes to override denying access. > The other owner related checks should be similar. > > Imagine the situation, when a procss would be able to open a file because it > is the owner of the file and the permission bits for the owner grant access. > The unmodified code would allow the access, because it won't even call the > secpolicy functions. > So unfortunately, to my mind, I have to change the file system code and > cannot incorporate my privilege checking into the existing sec_policy > functions, 8-( > If the permission bits or ACL of a file specify that it should be allowed to open a file, then the process should be allowed to open the file. I thought that privileges only granted additional access that would otherwise be denied by a file's permission bits/ACL. This sounds like you want the presence of certain privileges to override permission bits? -Mark _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
