Nicolai Johannes wrote:
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.
Can you give us an example of a 'file' the ssh-agent wishes to open and
what the permission are on the file and also what privileges the
ssh-agent has, and what the expected results are.
You need to be very careful about changing the rules for access control,
since you may end up breaking POSIX compliance.
-Mark
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
