> > gw-1
> > Presumably all functionality (including tpmadm(1m)) goes through
> > tcsd(1m).
> > I saw mention of it doing authentication and authorization. As the
> > project team knows from the prereview, both require to be auditable
> > in the Solaris Audit trail.
> >
>
> TCSD does not do authentication and authorization in the Solaris/Unix sense.
> We have discussed this and I thought we had consensus that audit was NOT
> needed in
> this case.
>
>
> > From today's reading of the case log, tpadm, tcsd, I've missed
> > seeing where authorization (in the Solaris sense) is supported.
> > Is the reference here, the generic if user foo knows password
> > bar, foo is authorized to do actions baz? (It would seem those
> > actions should be auditable.)
> >
> No, that example is not quite applicable in this situation. "actions"
> w.r.t the TCS Daemon
> are not authenticated on a per-user basis. TCSD "authorizes" certain
> commands to be
> performed from a remote client depending on the configuration parameters
> in the tcsd.conf
> file, not based on passwords. It also has no concept of a "user" and
> doesn't have support
> to filter based on IP addresses.
I guess I've completely misunderstood the architecture here.
I thought tpmadm used the library which called to tcsd which
was the policy engine for all the functions passed to the
TPM. Thus it all seemed to fall within various audit requirements.
More time please. Perhaps off line.... to clear it up.
Could we talk later today?
> > gw-1c
> > Introduction of an object (storage or otherwise) into a subject's
> > address space requires auditability.
> >
>
> For example?
>
> > gw-2
> > As the TPM can be switched between various owners, what it the
> > object reuse policy/implementation?
> >
>
> I don't quite understand the question. The TPM doesn't switch between
> owners.
> The platform owner issues the "takeownership" command 1 time when the system
> is first provisioned (or whenever the owner wants to start using the
> TPM). It
> is not something that is done repeatedly for different users. As mentioned
> earlier, this is possibly a good candidate for auditing later.
Please see the ObjectReuse file in the case directory. It
is the quote of the relevant parts of the criteria.
I'm not sure how else to state them. I thought the project
team had seen them some time ago when I sent this all out
to the management.
> > gw-3
> > Only indirectly related to this case: Since Validated Execution
> > (PSARC/2008/195) is mentioned as a consumer, one presumes validated
> > execution is to be done within zones, what does that imply for
> > cross/multi-zone use of this project? Will that require opening
> > the daemon to listening for requests from off machine?
> > Same question about TX and its use of zones as labeled separation.
>
> The Zones issue and virtualization issue were discussed in-depth over
> the past few days,
> see the recent mail in the case logs.
>
> In Summary: We need a more robust long-term solution
> for communication from Zones and TX since network-communication is not
> always available or desirable. For now, the workaround is to use the
> existing network
> communication support already available and continue to monitor the TCG
> working groups that care about virtualization support.
Yes, I got that from the discussion. Let me rephrase:
It seems Validated Execution is a consumer of this project.
Until the TPM virtualization project is completed, how
will Validated Execution in non-global zones (TX) be effected
by this project? For example: will tcsd need to listen for
non-local connections? Is it just not applicable since
ValEx only uses the TPM when booting the GZ? ...
Gary..
