zfs discuss - Jun 2006 - Proposal for new basic privileges related with file 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

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: security-discuss-bounces at opensolaris.org on behalf of Nicolai Johannes
Sent: Wed 6/21/2006 1:23 AM
To: zfs-discuss at opensolaris.org
Cc: security-discuss at opensolaris.org
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
security-discuss at opensolaris.org

> 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?
We do extensive file access testing as part of the zfs test suite.
The test suite is mostly written in ksh scripts with some C code. 
We should have the test suite available externally via 
OpenSolaris.org sometime in July or August. In the meantime
I would code up your unit tests in ksh so they can be more
easily integrated. We''ll keep you posted as progress in
releasing the test suite is made.

Cheers,
Jim
 
 
This message posted from opensolaris.org

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

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:

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.

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-(

Please tell me if I am wrong.

Thank you

Johannes


-----Urspr?ngliche Nachricht-----
Von: Mark Shellenbaum [mailto:Mark.Shellenbaum at Sun.COM]
Gesendet: Mi 21.06.2006 18:11
An: Nicolai Johannes
Cc: zfs-discuss at opensolaris.org; security-discuss at opensolaris.org
Betreff: Re: [zfs-discuss] Proposal for new basic privileges related with
filesystem access checks
 
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

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

>Just so I am understanding this correctly.  All of the PRIV_IDENTITY_* 
>privs look only at euid or egid?
I find the formulation a bit strange; no operation in the kernel,
except for the much maligned access() use anything other than effective
ids.

Could we please have an example of what these privileges are
supposed to prevent doing?  And what lacking them would still
allow you to do?

Casper

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:Mark.Shellenbaum at Sun.COM]
Gesendet: Mi 21.06.2006 21:21
An: Nicolai Johannes
Cc: security-discuss at opensolaris.org; zfs-discuss at 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

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:Mark.Shellenbaum at Sun.COM]
> Gesendet: Mi 21.06.2006 21:21
> An: Nicolai Johannes
> Cc: security-discuss at opensolaris.org; zfs-discuss at 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
> 
>

>Processes like ssh-agent that do not need their "identiity" may
drop >them. An exploit too these processes may not exploit the fact, that
t>he euid/groups of the process allow some file operations that are
den>ied to everyone. Only files that are globally
readable/writable/execu>table may still be accessed (if there is no rule that
denies the acce>ss 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
r>un under a special euid/egid/belong to special groups or only need
th>ese rights in the starting phase and drop them later.
>Dropping the privileges may also be used to enforce some kind of
mand>atory access control: An administrator that does not want some users
>to change permission of files may withdraw PRIV_FILE_IDENTITY_OWNER i>n
their login shell.
I''m not sure if I like the name, then; nor the emphasis on the
euid/egid (as those terms are not commonly used in the kernel;
there''s a reason why the effective uid was cr->cr_uid and not
cr_euid.

In other words, what your are doing is creating a "nobody" user with
an ordinary user id.

In that case, the fact of having five different privileges to
shadow the five FILE privileges is perhaps going overboard.

It''s also perhaps more easily understood when referred to in the
frame of reference of an anonymous user.

There are also some other strange corner cases; e.g., opening files
in /tmp with a umask other than 0.

Casper

On Thu, Jun 22, 2006 at 01:01:38AM +0200, Casper.Dik at Sun.COM
wrote:
> I''m not sure if I like the name, then; nor the emphasis on the
> euid/egid (as those terms are not commonly used in the kernel;
> there''s a reason why the effective uid was cr->cr_uid and not
cr_euid.
> 
> In other words, what your are doing is creating a "nobody" user
with
> an ordinary user id.
Yes.  It''s kind of enticing.
> In that case, the fact of having five different privileges to
> shadow the five FILE privileges is perhaps going overboard.
> 
> It''s also perhaps more easily understood when referred to in the
> frame of reference of an anonymous user.
> 
> There are also some other strange corner cases; e.g., opening files
> in /tmp with a umask other than 0.
As I interpret the proposal file creation in /tmp would succeed, but
opening existing files owned by the process'' actual euid cannot be
opened if thes basic privs are dropped.

How would dropping this basic priv work with NFS though?

Nico
--

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:

Think about a process that runs under user bar and group foo that have all basic
privileges set and tries to access
a file test that is owned by anotheruser and group foo.
The path to the file has search permissions for everyone.
The permission bits are as follows: rwx---rwx
The process is not able to open the file in read mode, an anonymous user would
be, dropping PRIV_FILE_IDENTITY_READ won''t allow the access as well
(see the three checking possibilities for details), only having set
PRIV_FILE_DAC_READ would allow the process.
That was the only reason I have not used the term "anonymous user" but
used the expression "benefit from additional rights associated through the
process'' identity".

If the file test is owned by a group, the process is not member of, access will
be granted in both cases. If the file is owned by user bar and/or group foo and
rwx bits are rwxrwx-w-, read access is only allowed if PRIV_FILE_IDENTITY_READ
or PRIV_FILE_DAC_READ is set, write access is allowed in every case.

If the path to the file has not search permissions for everyone, but search
permissions for the identity of the process, PRIV_FILE_IDENTITY_SEARCH or
PRIV_FILE_DAC_SEARCH has been set. If the identity of the process has only
search permissions for everyone but not for the identity of the process, only
PRIV_FILE_DAC_SEARCH will help to allow the access.

In case of mixed access modes, the checking possibilities will manage that only
privileges are required, that are actually needed.


The identity is to my mind determined through euid/egid and the associated
groups, what term should I use in order not to cause confusion here?

To the file creation problematic: In the proposal was mentioned, that file
creation is only allowed if PRIV_FILE_OWNER is set and the required privileges
for the initial permissions:

--- quote ---

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?

--- end of quote ---

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.

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.

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.

Please tell me, which problems with POSIX and NFS semantics still exist with the
new privileges.

If the semantic of the new permissions is not clear yet, I will give further
examples.

Thanks in advance

Johannes


PS: The longer I think about my three checking possibilities the more I favour
option two.


-----Urspr?ngliche Nachricht-----
Von: Nicolas Williams [mailto:Nicolas.Williams at Sun.COM]
Gesendet: Do 22.06.2006 01:36
An: Casper.Dik at Sun.COM
Cc: Nicolai Johannes; security-discuss at opensolaris.org; zfs-discuss at
opensolaris.org; Mark Shellenbaum
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
 
On Thu, Jun 22, 2006 at 01:01:38AM +0200, Casper.Dik at Sun.COM
wrote:
> I''m not sure if I like the name, then; nor the emphasis on the
> euid/egid (as those terms are not commonly used in the kernel;
> there''s a reason why the effective uid was cr->cr_uid and not
cr_euid.
> 
> In other words, what your are doing is creating a "nobody" user
with
> an ordinary user id.
Yes.  It''s kind of enticing.
> In that case, the fact of having five different privileges to
> shadow the five FILE privileges is perhaps going overboard.
> 
> It''s also perhaps more easily understood when referred to in the
> frame of reference of an anonymous user.
> 
> There are also some other strange corner cases; e.g., opening files
> in /tmp with a umask other than 0.
As I interpret the proposal file creation in /tmp would succeed, but
opening existing files owned by the process'' actual euid cannot be
opened if thes basic privs are dropped.

How would dropping this basic priv work with NFS though?

Nico
--

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
--

Mark Shellenbaum wrote:
> 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?
There are two types of privileges in Solaris 10 onwards, this is 
different to anything Trusted Solaris did before and different to the 
(never ratified and defunct) POSIX capabilities that Linux has.

The normal privileges empower, ie they allow override where you
wouldn''t
normally be allowed to do something.

There is also the concept of "basic" privileges, these are things that
users and normally do.  Currently that set is: proc_fork, proc_exec, 
proc_session, proc_info, file_link_any.

If you look at nfsd you will see that it has the basic privileges 
removed from it.  This is further protection against exploitation due to 
bugs.

Johannes project is to expand the basic priv set.

A couple of examples where these file basic privileges could be used are:

Anything running as daemon - daemon doesn''t own files and
shouldn''t
generally.  So if there are files owned by daemon they might not be ones 
belonging to that process.

ssh(1) and ssh-agent(1) after there initial startup.  For ssh-agent(1) 
it should ONLY communicate over the UNIX domain socket; dropping the new 
  file basic privs that Johannes is proposing provides protection to 
ensure that ssh-agent can''t be a conduit to steal user data.  For
ssh(1)
it is slightly less obvious but it is possible that a bad peer SSH 
server could exploit the client.  If ssh(1) drops basic file privs after 
  it reads all the config it is a good layer of protection.


-- 
Darren J Moffat

>On Thu, Jun 22, 2006 at 01:01:38AM +0200, Casper.Dik at Sun.COM wrote:
>> I''m not sure if I like the name, then; nor the emphasis on the
>> euid/egid (as those terms are not commonly used in the kernel;
>> there''s a reason why the effective uid was cr->cr_uid and
not cr_euid.
>> 
>> In other words, what your are doing is creating a "nobody"
user with
>> an ordinary user id.
>
>Yes.  It''s kind of enticing.
I''m not entirely clear as to the problem which it solves; I think
I''d much rather have a user which cannot modify anything.

As I understand the proposal, you can still read/modify world
accessible files.
>As I interpret the proposal file creation in /tmp would succeed, but
>opening existing files owned by the process'' actual euid cannot be
>opened if thes basic privs are dropped.
Right; but often programs work by reopening such files; that will now
fail.
>How would dropping this basic priv work with NFS though?
Not until we make privileges visible over NFS which is a tough nut
to crack.

Casper

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:Nicolas.Williams at sun.com]
Gesendet: Do 22.06.2006 04:36
An: Nicolai Johannes
Cc: security-discuss at opensolaris.org; zfs-discuss at 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
--

Yes, world readable/writable files can still be accessed by dropping the new
privileges. One reason are library calls that need to read some public files
(like things in /etc). The need to manipulate or remove world writable files is
harder to justify, on the other hand, world writable files are hard to find.

One may define two additional basic privileges (say
PRIV_FILE_ALLOW_{WRITE|READ}) that would be checked first, but so, we have two
further privileges 8-)


-----Urspr?ngliche Nachricht-----
Von: casper at holland.sun.com im Auftrag von Casper.Dik at Sun.COM
Gesendet: Do 22.06.2006 11:55
An: Nicolas Williams
Cc: Nicolai Johannes; security-discuss at opensolaris.org; zfs-discuss at
opensolaris.org; Mark Shellenbaum
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
 
>On Thu, Jun 22, 2006 at 01:01:38AM +0200, Casper.Dik at Sun.COM wrote:
>> I''m not sure if I like the name, then; nor the emphasis on the
>> euid/egid (as those terms are not commonly used in the kernel;
>> there''s a reason why the effective uid was cr->cr_uid and
not cr_euid.
>> 
>> In other words, what your are doing is creating a "nobody"
user with
>> an ordinary user id.
>
>Yes.  It''s kind of enticing.
I''m not entirely clear as to the problem which it solves; I think
I''d much rather have a user which cannot modify anything.

As I understand the proposal, you can still read/modify world
accessible files.
>As I interpret the proposal file creation in /tmp would succeed, but
>opening existing files owned by the process'' actual euid cannot be
>opened if thes basic privs are dropped.
Right; but often programs work by reopening such files; that will now
fail.
>How would dropping this basic priv work with NFS though?
Not until we make privileges visible over NFS which is a tough nut
to crack.

Casper

Concerning the reopen problem of files created in world writable directories:
One may use the following algorithm:
First compute the permissions of the newly created file.
For every permission granted to the user or group, check whether the
corresponding identity-privilege is set. If not, the permission also has to be
granted for everyone. If this is not the case, file creation is denied.

With following this algorithm, every file we were able to open, we are also able
to reopen.

-----Urspr?ngliche Nachricht-----
Von: casper at holland.sun.com im Auftrag von Casper.Dik at Sun.COM
Gesendet: Do 22.06.2006 11:55
An: Nicolas Williams
Cc: Nicolai Johannes; security-discuss at opensolaris.org; zfs-discuss at
opensolaris.org; Mark Shellenbaum
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
 
>On Thu, Jun 22, 2006 at 01:01:38AM +0200, Casper.Dik at Sun.COM wrote:
>> I''m not sure if I like the name, then; nor the emphasis on the
>> euid/egid (as those terms are not commonly used in the kernel;
>> there''s a reason why the effective uid was cr->cr_uid and
not cr_euid.
>> 
>> In other words, what your are doing is creating a "nobody"
user with
>> an ordinary user id.
>
>Yes.  It''s kind of enticing.
I''m not entirely clear as to the problem which it solves; I think
I''d much rather have a user which cannot modify anything.

As I understand the proposal, you can still read/modify world
accessible files.
>As I interpret the proposal file creation in /tmp would succeed, but
>opening existing files owned by the process'' actual euid cannot be
>opened if thes basic privs are dropped.
Right; but often programs work by reopening such files; that will now
fail.
>How would dropping this basic priv work with NFS though?
Not until we make privileges visible over NFS which is a tough nut
to crack.

Casper

>
>Concerning the reopen problem of files created in world writable
dire>ctories:
>One may use the following algorithm:
>First compute the permissions of the newly created file.
>For every permission granted to the user or group, check whether the
>corresponding identity-privilege is set. If not, the permission also >has
to be granted for everyone. If this is not the case, file creatio>n is
denied.
`Uhm, this requires the anonymous user to have all its files world read//write
which is a non-starter if you ask me.
>With following this algorithm, every file we were able to open, we ar>e
also able to reopen.
Yes, but that requires changing code so programs like "vi" and library
routines like mktemp() no longer function.

Casper

>
>Yes, world readable/writable files can still be accessed by dropping >the
new privileges. One reason are library calls that need to read so>me public
files (like things in /etc). The need to manipulate or remo>ve world writable
files is harder to justify, on the other hand, worl>d writable files are hard
to find.
>
>One may define two additional basic privileges (say
PRIV_FILE_ALLOW_{>WRITE|READ}) that would be checked first, but so, we have
two further> privileges 8-)=20
Perhaps the outcome of the discussion is that we really only need
two.

Certainly I think that the design needs to be approached from the proper
end: implement a prototype and then see what the effects are of removing
the privileges from processes and see whether that is actually useful.

To me, a "PRIV_OBJECT_MODIFY" which is required for any file modifying
operation would seem to be more useful as often a read-only user is
a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
in case you want to prevent any reading.

I''m not sure what the distinction of not being able to read the files
you own buys you.

Certainly the awkward wording including euid/egid and supplemental groups
should be changed into something which more clearly expresses the intent:
"privilege required for non-anonymous access"

Casper

You are right that vi or mktemp will not longer function with this approach. 
On the other hand, only programs that will really know what they are doing 
will drop basic privileges. I do not see a reason for most applications (like 
vi) will do so.
Imagine a process has no identity (it dropped the required privileges). Of 
course, it should not be able to create file it is itself not able to open. 
In my opinion, this would be inconsistent.

My mentor made the suggestion that I should provide the list with a prototype 
implementation of the new privileges for a filesystem and also write a demo 
program that shows that it works. Later on, I may modify ssh-agent to 
demonstrate the new privileges on a program that really benefit from it.

To the list: What file system should I use to implement my prototype?
Do you prefer 5(+2) or 2(+2) privileges (the +2 is for the case that even 
reading writing globally writable/readable files should be denied).
What checking order should I use? (I am in favour of possibility 2).
Is the open policy consistent for you or should the creation of files should 
be generally forbidden if not all new privileges are set?

Thanks in advance

Johannes Nicolai

On Thursday 22 June 2006 12:56, you wrote:
> >Concerning the reopen problem of files created in world writable
dire> >ctories:
> >One may use the following algorithm:
> >First compute the permissions of the newly created file.
> >For every permission granted to the user or group, check whether the
> >corresponding identity-privilege is set. If not, the permission also
> >has to be granted for everyone. If this is not the case, file
creatio> >n is denied.
>
> `Uhm, this requires the anonymous user to have all its files world
> read//write which is a non-starter if you ask me.
>
> >With following this algorithm, every file we were able to open, we
ar> >e also able to reopen.
>
> Yes, but that requires changing code so programs like "vi" and
library
> routines like mktemp() no longer function.
>
> Casper

On Thu, Jun 22, 2006 at 11:55:05AM +0200, Casper.Dik at Sun.COM
wrote:
> >Yes.  It''s kind of enticing.
> 
> I''m not entirely clear as to the problem which it solves; I think
> I''d much rather have a user which cannot modify anything.
The "canonical" example would be, I think, ssh-agent(1), although
I''m
not sure it''s safe to drop basic privileges given the possibility of it
using complex crypto frameworks (currently it uses OpenSSL, but through
it it could use PKCS#11).

A user that cannot modify anything, not even temp files made by them,
seems much too narrowly constrained.
> As I understand the proposal, you can still read/modify world
> accessible files.
Yes.
> >As I interpret the proposal file creation in /tmp would succeed, but
> >opening existing files owned by the process'' actual euid
cannot be
> >opened if thes basic privs are dropped.
> 
> Right; but often programs work by reopening such files; that will now
> fail.
It could be made to work...

Another concern would be: what UID owns files created by such processes?
> >How would dropping this basic priv work with NFS though?
> 
> Not until we make privileges visible over NFS which is a tough nut
> to crack.
For non-basic privs we can always do things with the client''s root
credential and, when creating files, use the create_as option in NFSv4.
Then the client could emulate FILE_DAC_*.

For basic privs it''s harder; if the client had a "nobody"
credential
then it could use that.

The general solution to the NFS problem with privileges is, IMO, as I
outlined earlier, through the GSS-API.

On Thursday 22 June 2006 16:55, you wrote:
> >Yes, world readable/writable files can still be accessed by dropping
> >the new privileges. One reason are library calls that need to read
so> >me public files (like things in /etc). The need to manipulate or
remo> >ve world writable files is harder to justify, on the other hand,
worl> >d writable files are hard to find.
> >
> >One may define two additional basic privileges (say
PRIV_FILE_ALLOW_{> >WRITE|READ}) that would be checked first, but so, we
have two further> > privileges 8-)=20
>
> Perhaps the outcome of the discussion is that we really only need
> two.
Okay, one vote for only two privileges.
>
> Certainly I think that the design needs to be approached from the proper
> end: implement a prototype and then see what the effects are of removing
> the privileges from processes and see whether that is actually useful.
>
> To me, a "PRIV_OBJECT_MODIFY" which is required for any file
modifying
> operation would seem to be more useful as often a read-only user is
> a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
> in case you want to prevent any reading.
So you are in favour of a general turn file acces/manipulation on/off switch.

> I''m not sure what the distinction of not being able to read the
files
> you own buys you.
Imagine a process that is started by an ordinary user with the only intent to 
react on IPC and perhaps read some files in /etc/, /var or other public 
readable objects (like files in its home directory with sufficient permission 
bits for everyone) from time to time.
In this case, you may drop PRIV_OBJECT_MODIFY, but not PRIV_OBJECT_ACCESS. An 
exploit of the process may spy out files that may only be read by the user 
but not by everyone.
Other example where you benefit from accessing public but not your own files 
may be for server side scripting applications of different users that share 
the same account, automated benchmark suites, hosting of programming 
competitions, hosted computation software, evaluation of programming 
exercises of students, ...
You may read about further examples in my technical report "Secure
execution
of untrusted code" (unfortunately only in German) on 
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_09_Sichereausfuehrung.pdf

>
> Certainly the awkward wording including euid/egid and supplemental groups
> should be changed into something which more clearly expresses the intent:
> "privilege required for non-anonymous access"
>
> Casper
Totally agree with you.

>Another concern would be: what UID owns files created by such processes?
I don''t think it could be anything other than the current euid;
otherwise it is too easy to create files under a different uid.
>For non-basic privs we can always do things with the client''s root
>credential and, when creating files, use the create_as option in NFSv4.
>Then the client could emulate FILE_DAC_*.
>
>For basic privs it''s harder; if the client had a "nobody"
credential
>then it could use that.
No, because it''s not fine-grained enough.

Casper

On Thursday 22 June 2006 17:15, you wrote:
> On Thu, Jun 22, 2006 at 11:55:05AM +0200, Casper.Dik at Sun.COM wrote:
> > >Yes.  It''s kind of enticing.
> >
> > I''m not entirely clear as to the problem which it solves; I
think
> > I''d much rather have a user which cannot modify anything.
>
> The "canonical" example would be, I think, ssh-agent(1), although
I''m
> not sure it''s safe to drop basic privileges given the possibility
of it
> using complex crypto frameworks (currently it uses OpenSSL, but through
> it it could use PKCS#11).
>
> A user that cannot modify anything, not even temp files made by them,
> seems much too narrowly constrained.
>
> > As I understand the proposal, you can still read/modify world
> > accessible files.
>
> Yes.
>
> > >As I interpret the proposal file creation in /tmp would succeed,
but
> > >opening existing files owned by the process'' actual euid
cannot be
> > >opened if thes basic privs are dropped.
> >
> > Right; but often programs work by reopening such files; that will now
> > fail.
>
> It could be made to work...
Do you think about something similar to my proposed algorithm for this issue 
or have a different idea?
>
> Another concern would be: what UID owns files created by such processes?
To my mind, the euid of the "anonymous" process. That is why I
intended to
introduce five and not only two privileges. PRIV_FILE_IDENTITY_OWNER would be 
required to create files.
In the scenario with only two privileges, having set 
PRIV_FILE_IDENTITY_{WRITE|READ} would give you back your "writing/reading 
identity", see my proposed open algorithm for reference.
>
> > >How would dropping this basic priv work with NFS though?
> >
> > Not until we make privileges visible over NFS which is a tough nut
> > to crack.
>
> For non-basic privs we can always do things with the client''s root
> credential and, when creating files, use the create_as option in NFSv4.
> Then the client could emulate FILE_DAC_*.
>
> For basic privs it''s harder; if the client had a
"nobody" credential
> then it could use that.
>
> The general solution to the NFS problem with privileges is, IMO, as I
> outlined earlier, through the GSS-API.

On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes
wrote:
> Concerning the reopen problem of files created in world writable
> directories: One may use the following algorithm: First compute the
> permissions of the newly created file.  For every permission granted
> to the user or group, check whether the corresponding
> identity-privilege is set. If not, the permission also has to be
> granted for everyone. If this is not the case, file creation is
> denied.
I was thinking of caching the {vfs, inode #, gen#, pid} and using that
to allow such processes to re-open files they _recently_ (the cache
should have LRU/LFU eviction) opened.

On Thu, 2006-06-22 at 10:55, Casper.Dik at sun.com
wrote:
> To me, a "PRIV_OBJECT_MODIFY" which is required for any file
modifying
> operation would seem to be more useful as often a read-only user is
> a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
> in case you want to prevent any reading.
I''d draw a distinction between:
	- permitting the creation of new writeable descriptors
	- using existing writeable descriptors to modify objects.

which do you mean here?  I think the former is more useful..

						- Bill

On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams
wrote:
> On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
> > Concerning the reopen problem of files created in world writable
> > directories: One may use the following algorithm: First compute the
> > permissions of the newly created file.  For every permission granted
> > to the user or group, check whether the corresponding
> > identity-privilege is set. If not, the permission also has to be
> > granted for everyone. If this is not the case, file creation is
> > denied.
> 
> I was thinking of caching the {vfs, inode #, gen#, pid} and using that
> to allow such processes to re-open files they _recently_ (the cache
> should have LRU/LFU eviction) opened.
That doesn''t seem like a very predictable interface.  The security
guarantees
are not very strong.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

On Thu, Jun 22, 2006 at 11:06:48AM -0700, Jonathan Adams
wrote:
> On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote:
> > On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
> > > Concerning the reopen problem of files created in world writable
> > > directories: One may use the following algorithm: First compute
the
> > > permissions of the newly created file.  For every permission
granted
> > > to the user or group, check whether the corresponding
> > > identity-privilege is set. If not, the permission also has to be
> > > granted for everyone. If this is not the case, file creation is
> > > denied.
> > 
> > I was thinking of caching the {vfs, inode #, gen#, pid} and using that
> > to allow such processes to re-open files they _recently_ (the cache
> > should have LRU/LFU eviction) opened.
> 
> That doesn''t seem like a very predictable interface.  The security
guarantees
> are not very strong.
Thinking about PID re-use, yes, but I''m not trying to design the
specific details -- I think a set of items to cache that provides strong
security guarantees can be found.  The interface would remain
unpredictable in other ways, but that seems like a small price to pay
considering the use cases.

>On Thu, 2006-06-22 at 10:55, Casper.Dik at sun.com wrote:
>> To me, a "PRIV_OBJECT_MODIFY" which is required for any file
modifying
>> operation would seem to be more useful as often a read-only user is
>> a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
>> in case you want to prevent any reading.
>
>I''d draw a distinction between:
>	- permitting the creation of new writeable descriptors
>	- using existing writeable descriptors to modify objects.
>
>which do you mean here?  I think the former is more useful..

Yes; the former, not the latter.  The Unix semantics of allowing
inherited filedescriptors to just work is required; think, e.g.,
/dev/tty and others.  Stdin/stdout/stderr.

Casper

I am afraid, that I dislike the idea as well. You also need to record the
privileges of the process (perhaps the process chose to drop and set the new
privileges from time to time). It really complicates a safe and easy to verify
implementation.
To my mind, processes that will drop the new privileges really know what they
can do and how they should do things. In my opinion, creating files that may not
be accessed by the process if already present should not be allowed at all.

Regards

Johannes

-----Urspr?ngliche Nachricht-----
Von: Nicolas Williams [mailto:Nicolas.Williams at Sun.COM]
Gesendet: Do 22.06.2006 20:11
An: Jonathan Adams
Cc: Nicolai Johannes; zfs-discuss at opensolaris.org; security-discuss at
opensolaris.org; Casper.Dik at Sun.COM
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
 
On Thu, Jun 22, 2006 at 11:06:48AM -0700, Jonathan Adams
wrote:
> On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote:
> > On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
> > > Concerning the reopen problem of files created in world writable
> > > directories: One may use the following algorithm: First compute
the
> > > permissions of the newly created file.  For every permission
granted
> > > to the user or group, check whether the corresponding
> > > identity-privilege is set. If not, the permission also has to be
> > > granted for everyone. If this is not the case, file creation is
> > > denied.
> > 
> > I was thinking of caching the {vfs, inode #, gen#, pid} and using that
> > to allow such processes to re-open files they _recently_ (the cache
> > should have LRU/LFU eviction) opened.
> 
> That doesn''t seem like a very predictable interface.  The security
guarantees
> are not very strong.
Thinking about PID re-use, yes, but I''m not trying to design the
specific details -- I think a set of items to cache that provides strong
security guarantees can be found.  The interface would remain
unpredictable in other ways, but that seems like a small price to pay
considering the use cases.

To the question whether we should care about being able to write files at all:
I am not sure whether the following access checks are done by the file system
layer, but what is with files in /dev/, named pipes and Unix Domain Sockets?
Also for lockfiles, that may be removed by other users, writing file would make
sense.

Regards

Johannes Nicolai

-----Urspr?ngliche Nachricht-----
Von: casper at holland.sun.com im Auftrag von Casper.Dik at sun.com
Gesendet: Do 22.06.2006 20:23
An: Nicolas Williams
Cc: Jonathan Adams; Nicolai Johannes; security-discuss at opensolaris.org
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
 
>Thinking about PID re-use, yes, but I''m not trying to design the
>specific details -- I think a set of items to cache that provides strong
>security guarantees can be found.  The interface would remain
>unpredictable in other ways, but that seems like a small price to pay
>considering the use cases.
I think that this "cache design" really points to deficiencies in
the underlying architecture. If you have to add workarounds for
certain parts of the behaviour, you generally do better reconsidering
the initial design.  And to question whether we actually care about
being able to write files at all.

Casper

On Thu, Jun 22, 2006 at 08:36:05PM +0200, Nicolai Johannes
wrote:
> To the question whether we should care about being able to write files at
all:
> 
> I am not sure whether the following access checks are done by the
> file system layer, but what is with files in /dev/, named pipes and
> Unix Domain Sockets? Also for lockfiles, that may be removed by other
> users, writing file would make sense.
A daemon which needs to open these things could keep the WRITE privilege in
it''s permitted set, and only set it while it needed it.  I''d
imagine that
for most daemons, you could simply drop WRITE entirely, because you never
need to do a open(..., O_WRITE) afterwards.

As with most basic privileges, you need to be careful if you drop it.  This
is not a surprise.

Cheers,
- jonathan
> -----Urspr?ngliche Nachricht-----
> Von: casper at holland.sun.com im Auftrag von Casper.Dik at sun.com
> Gesendet: Do 22.06.2006 20:23
> An: Nicolas Williams
> Cc: Jonathan Adams; Nicolai Johannes; security-discuss at opensolaris.org
> Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges
related with filesystem access checks
>  
> 
> >Thinking about PID re-use, yes, but I''m not trying to design
the
> >specific details -- I think a set of items to cache that provides
strong
> >security guarantees can be found.  The interface would remain
> >unpredictable in other ways, but that seems like a small price to pay
> >considering the use cases.
> 
> I think that this "cache design" really points to deficiencies in
> the underlying architecture. If you have to add workarounds for
> certain parts of the behaviour, you generally do better reconsidering
> the initial design.  And to question whether we actually care about
> being able to write files at all.
> 
> Casper
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
-- 
Jonathan Adams, Solaris Kernel Development

On Wed, Jun 21, 2006 at 04:34:59PM -0600, Mark Shellenbaum
wrote:
> 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.
ssh-agent(1) should need to open no files, once setup is complete, other
than world-readable files needed by whatever libraries.  ssh-agent(1)
speaks a protocol with remote peers (through IPC to ssh(1)); thus
limiting what it can do should it be compromised is appealing.
> You need to be very careful about changing the rules for access control, 
> since you may end up breaking POSIX compliance.
That''s presumably why these would be basic privileges (Darren and
Nicolai can confirm).

Mark Shellenbaum wrote:
> 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.
The whole point is that ssh-agent should NEVER be opening any files that 
the user it runs as owns after its initial startup.   It may due to 
library implementation details need to open world readable system files 
(such as /etc/default/nss as an implementation detail of parts of the 
nsswitch).
> You need to be very careful about changing the rules for access control, 
> since you may end up breaking POSIX compliance.
basic privileges already has this potential.  It is okay here because 
the application is explicitly requesting this behaviour.  An application 
that only calls POSIX APIs would not be impacted by these new basic 
privileges (unless it was purposely started from an environment with 
them removed from the limit set).

-- 
Darren J Moffat

>Thinking about PID re-use, yes, but I''m not trying to design the
>specific details -- I think a set of items to cache that provides strong
>security guarantees can be found.  The interface would remain
>unpredictable in other ways, but that seems like a small price to pay
>considering the use cases.
I think that this "cache design" really points to deficiencies in
the underlying architecture. If you have to add workarounds for
certain parts of the behaviour, you generally do better reconsidering
the initial design.  And to question whether we actually care about
being able to write files at all.

Casper
_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org

>On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote:
>> On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
>> > Concerning the reopen problem of files created in world writable
>> > directories: One may use the following algorithm: First compute
the
>> > permissions of the newly created file.  For every permission
granted
>> > to the user or group, check whether the corresponding
>> > identity-privilege is set. If not, the permission also has to be
>> > granted for everyone. If this is not the case, file creation is
>> > denied.
>>
>> I was thinking of caching the {vfs, inode #, gen#, pid} and using that
>> to allow such processes to re-open files they _recently_ (the cache
>> should have LRU/LFU eviction) opened.
>
>That doesn''t seem like a very predictable interface.  The security
guarantees
>are not very strong.

It carries a large "DANGER, WILL ROBINSON" sign.

(Removed zfs-discuss)

Casper
_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org