I'm sponsoring the following fast-track for Casper Dik (FGAP). This case
instantiates a set of Consolidation Private interfaces to permit fine-
grained policy checks by a user-level policy daemon. This case has Micro
binding and the timer is set for next Wednesday Feb 20th.
-Mike
---8<---
1. Technical Description
The Fine Grained Access Permissions (FGAP) project will provide a mechanism
and associated framework to allow per-object exceptions to the kernel
security policy. I.e., rather than giving the file_dac_read privilege
to a process or user, you can give access to only one particular file
or set of files.
This case instantiates the initial set of interfaces as Consolidation Private
in order to enable early access and experimentation for developers as we
explore the full set of interfaces that are required for such a policy
mechanism. The intent of the project team is to then return with a future
case providing man pages for the completed interfaces and upgrading the
interfaces to Committed when we have sufficient developer feedback.
The current policy checks are performed through the secpolicy* functions
and ultimately funneling through priv_policy*.
The FGAP mechanism intervenes at the latest possible moment and when
the process in question does not have sufficient privileges, rather
than returning failure, an upcall is performed to a daemon which has
registered interest in handling exemptions for (a) particular
privilege(s).
This upcall passes along additional information about the object,
such as:
- filesystem pathname
- reserved port protocol and port number
and, as this call is made in the context of the caller, it also makes
available the full process context of the calling process through the
user credential.
To this end some additional parameters are passed to the relevant
secpolicy_* ()functions, such as the "vnode *", port numbers and protocols.
Only processes marked with the "PRIV_XPOLICY" process flags will be
subject to the upcall mechanism, making the overhead for ordinary
processes negligible.
There are several ways to register a "klpd" globally or local to a set
of related processes. A klpd is registered for a specific set of
privileges and the registering process will need to possess these
privileges.
2. Security Considerations
A process which registers a daemon requires the privileges it registers
for. The processes which run under the policy are required to have
the privileges required in their limit set.
A process can only (partially) exceed its privileges if allowed to
do so by a privileged policy broker.
When the daemon fails or dies, all failures will be safe as all further
policy calls will fail.
3. Reliability Considerations
Only processes which run under the policy on a system which is
configured with a policy for a set of processes or globally are affected.
The mechanism shipped by this project will not include any such
by default.
This fasttrack defines the following "Consolidation Private" interfaces
INTERFACES
+-----------------------+------------------+------------------------+
| Interface | Classification | Comments |
+-----------------------+------------------+------------------------+
| <klpd.h> | Consolidation | |
| klpd_create | Private | libc.so, SUNWprivate |
| klpd_getpath | | |
| klpd_getport | | |
| klpd_getucred | | |
| klpd_register | | |
| klpd_register_id | | |
| klpd_unregister | | |
| klpd_unregister_id | | |
| | | |
| PRIV_XPOLICY | | <sys/priv.h> |
| (flag to setpflags) | | |
| | | |
| ppriv(1) -x | | New option |
+-----------------------+------------------+------------------------+
and extends the "ppriv(1)" command with the ability to report and set
the PRIV_XPOLICY flag using the "-x" argument.
The intention is to fully document and publish the final versions of
these interfaces in a future case, once the project team has had sufficient
time to experiment with them and receive feedback from the community.
