On Wed, Mar 07, 2007 at 10:51:35AM +0000, Darren J Moffat wrote:
> > Currently, as on other platforms, all of these daemons run as root with
> > full privileges. Further work is underway to utilise least privilege
> > and
> > other Solaris security technologies to improve this situation.
>
> Do we have a timeframe for when we can expect this to be done ?
No. It's a significant amount of work.
> Note that a perfectly acceptable first cut of this does not require
> modification of the code. Just use the Privilege Debugging Blueprint
> and the tool that is with it to determine what privileges are actually
> used and use that as the initial set that SMF gives to the start method.
We can do that if it's seen as useful. We will still need to run as euid=0
though:
PRIV_FILE_DAC_WRITE
Allow a process to write a file or directory whose per-
mission bits or ACL do not allow the process write per-
mission. All privileges are required to write files
owned by UID 0 in the absence of an effective UID of 0.
Given the nature of the privcmd driver it's not so much "least privilege" as
"a bit less privilege".
> > Additionally, the community is working on authentication schemes for
> > access to the control tools as part of the 'xend API' work. We intend to
> > leverage this work as we track upstream development.
>
> Timeframe ?
The API work will be available in Xen 3.0.5, expected some time this month.
More work would be needed after that though, as it doesn't provide a meaningful
auth scheme yet.
> Preciesly because Xen has no delegated admin system of its own there
> should be an RBAC execution profile for running the Xen admin commands
> and the rights profile should contain the RBAC authorisations used to
> control the SMF services.
>
> For example if there is an admin command that needs to be run with all
> privilege then that should be in an RBAC profile.
If it's seen as useful to have an RBAC profile that gets pretty close to
complete control over the machine (reducing available memory, allowing any
remote machine to migrate a guest to it, complete control over any/all hosted
domains), then sure, we can have this.
> This should have been covered in the main Xen case, for me though this
> case makes it very clear that was probably missed.
The current situation was identified in the materials.
john
