Nicolai Johannes wrote:
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:
You might want to consider a different implementation order. I would
recommend TMPFS, UFS and then ZFS. The reason for this is TMPFS only
has permission bits and UFS has a simpler ACL model than ZFS.
Standard file access for ufs/zfs/tmpfs does basically the following:
1. check requested access mode against files permission bits/acl.
2. If access is NOT granted from step 1, then secpolicy_vnode_access()
is called which will then determine if process has necessary
privileges to grant the request.
3. Solaris file systems never check explicitly for PRIV_XXX_XXXX
privileges. Instead it relies on secpolicy_XXX() functions to handle
those decisions.
If you are able to implement the new priv checking in the already used
secpolicy functions, then hopefully you shouldn't need to modify any
file system code.
Access checking for chown/chgrp/utime/... aka VOP_SETATTR() goes through
a different flavor of secpolicy functions.
-Mark
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
