On Tue, 15 Jan 2008, Darren J Moffat wrote:
> David Chieu wrote:
> > Interface Type Comments
> > --------------------------------------------------------------------------
> > can.suspend bool The ability to suspend as determined
> > by uadmin(2).
>
> > can.hibernate bool The ability to hibernate as determined
> > by uadmin(2).
>
> For Solaris on SPARC and x86 what are these likely to return ?
>
> I think that on (supported) x86 systems can.suspend could return true because
> that maps to ACPI S3, but currently can.hibernate will never be true. However
> on SPARC can.hibernate could be true but can.suspend would never be true. Is
> that correct ?
"Never" is a long time, but currently can.hibernate will return true
on x86 and can.suspend will return false on sparc. In this context,
'suspend' equates to entering S3, and hibernate equates to entering
S4.
>
> One of the reasons I think this is very important is because of my issue below
> about the authorisations.
>
> >
> > The following RBAC authorizations and profiles will be added.
> >
> > Authorization Names:
> > solaris.system.power.:::System Power Management::help=SystemPowerMgmt.html
> > solaris.system.power.suspend::: Suspend the System::help=Suspend.html
> > solaris.system.power.suspend.ram::: Suspend to RAM::help=SuspendToRam.html
>
> Why does suspend to RAM need its own authorisation yet hibernate does not, ie
> what is the security difference between suspended to RAM versus any other type
> of suspend ?
The choice here centered around the the question: Is there a reason
to differentiate between auths for S3 and S4?
Effectively, we believe that if a user has the privilege to do an
S4, then he also has the privilege to do an S3. Partially because the
state transition to S4 functionally goes to S3 first. But also
because we considered the possible security considerations.
In S3, system state is entirely held in RAM, and will always be
contained in the running machine. If power is lost, state is lost.
In S4, system state is first put to RAM (i.e. enter S3), and then
written to disk, and could be saved for a long time. This image
contains eveything this was contained in RAM (including the
possibility decrypted data that would othewise not be on the disk) and
*could* be:
Viewed by someone who might get physical access to the image
Copied to another machine for viewing as above
Used to continue the system on a different hardware for
further viewing.
What we concluded from this is that it might be desireable to allow
S3 and not S4, but not the opposite. This led us to the heirarcical
auth:
solaris.system.power.suspend == allows both S3 and S4
solaris.system.power.suspend.ram == only allows S3
Going back to the 'can.*' comments above, for a user to currently
suspend a Sparc they must have solaris.system.power.suspend, and
adding 'ram' would prevent the user from suspending Sparc but not x86.
---- Randy
