Concerning the large number of new privileges: Yes, it is likely that a process may wish to drop all the privs together. On the other hand, dropping only PRIV_FILE_IDENTITY_OWNER would still allow to read files, write files, execute files, search files, but not change their permissions and access times. DROPPING only PRIV_FILE_IDENTITY_EXECUTE may prevent the process to benefit from special s-bit binaries, droppping only the PRIV_FIILE_IDENTITY_WRITE flag would cause a "identity read only" process, dropping only PRIV_FILE_IDENTITY_SEARCH would allow the process to create files in a world writable directory that cannot be manipulated by other users but not to destroy or investigate other files of the user in its home directory that is not global searchable, dropping both PRIV_file_identity_search and PRIV_FILE_IDENTITY_READ would still allow to create lock files in world writable directories.
If one decide for only two privileges, this would be my suggestion: PRIV_FILE_IDENTITY_READ' ::= PRIV_FILE_IDENTITY_READ | PRIV_FILE_IDENTITY_SEARCH | PRIV_FILE_IDENTITY_EXECUTE PRIV_FIILE_IDENTITY_WRITE' ::= PRIV_FILE_IDENTITY_WRITE | PRIV_FILE_IDENTITY_OWNER Without having set PRIV_FILE_IDENTITY_WRITE', creating files is impossible (unless PRIV_FILE_OWNER is set). To intially set or change permissions of a file that affect reading, searching or executing, both PRIV_FILE_IDENTITY_WRITE' and PRIV_FILE_IDENTITY_READ' have to be set (unless PRIV_FILE_OWNER is set). Do you aggree with this definition, have other ideas or think again about having 5 new privileges? Concerning the NFS issues: As long as NFS does not support transporting the privileges of the client process to the server, restricting a process that works with an NFS mount will not work. The same about third party file systems that have not yet implemented privilege awareness. To my mind, this is a point one have to accept but document in the man pages as it is the case with third party file systems, NFS and the old PRIV_FILE_DAC_* privileges. Regards Johannes Nicolai -----Ursprüngliche Nachricht----- Von: Nicolas Williams [mailto:[EMAIL PROTECTED] Gesendet: Do 22.06.2006 04:36 An: Nicolai Johannes Cc: [EMAIL PROTECTED]; zfs-discuss@opensolaris.org Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related with filesystem access checks On Thu, Jun 22, 2006 at 02:45:50AM +0200, Nicolai Johannes wrote: > Spo as I have understood you, explaining the new privileges with the > term "anonymous user" would be better? I actually thought about that > idea, but there is a subtle difference: Hmmm, no I have no good name for it. > Concerning the discussion whether five privileges are too much for the > purpose: My proposal also asks the question whether one should merge > the five privileges into two ones (PRIV_FILE_IDENTITY_{READ|WRITE} > with the semantic of state perserving/non state preserving operations. > To my mind, this is too coarsely grained in order to programmatically > restrict the power of a privileged/unprivileged process. Furthermore, > the shadowing of the existing privileges would be sematically more > consistent. The administrative effort to create nobody users, set > s-bits for special programs and track the usage of this user would > also vanish. Yeah, I think 5 is probably too many. Wouldn't apps that drop them drop all of them? > To the NFS/POSIX issue: I am not an expert in this field, but I > believe that the following two assumptions are right (correct me if I > am wrong): > > 1. Because the presence of all new basic privileges would change > anything in the established behaviour (check all three checking > possibilities if in doubt), programs with basic privileges (almost > all) will not notice the new privs at all. Right. > 2. I do not know exactly if permissions for a NFS file are checked on > server or client or both (I assume at least at the client). The new > privileges are only checked at the client, so the server is not > affected at all. In any case, having set/dropped the new privileges, > the process will be able to access files, it would normally (i.e. > without having introduced the new privileges) not be able to. The server checks permissions. IIRC Least Privilege already has some problems with NFS, namely that asserting PRIV_FILE_DAC_* over NFS does not work (unless the euid is 0). There are things that can be done about that problem strictly within the NFSv4 protocol, but for not asserting basic file privileges? I don't yet know what can be done within the protocol... ...though in the past I've proposed a stackable GSS-API mechanism or Kerberos V authorization-data element to convey client-side privilege information to the server for evaluation there. But this would be well beyond the scope of your project -- I mention it only for completeness. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
