Gary Winiger wrote: > I'm just getting back to this (after the prereview) and getting my P1 > project under control. > > As I mentioned in the prereview, if the TMP stack is to be part of the next > Solaris Common Criteria evaluation (or anything build upon it is to be > part of that evaluation), I believe this project needs to participate in > Solaris Audit. I'm sorry to keep bringing this up. (I'd be happy if > management would tell me that I didn't need to bring this up for all > cases that seem to need it.) Perhaps I missed it in the discussion and spec. > >
I'd be happy if you stopped bringing it up as well. Especially this late in the review process. > Gary.. > ====== > 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. > gw-1a > Additionally, setting parameters and taking/switching ownership require > audit. They both are security relevant (and possibly administrative > actions). > Possibly auditable from the tpmadm utility, not sure though. This command is also not necessarily associated with a specific person/user and could be automated. > gw-1b > How are the applicable subset of the 13 MRPP (see below) required > audit events generated by this project? What is that subset? > This project is not auditing them any moreso than openssl or pktool or any number of other utilities already in Solaris audit them. The utility doing the key generation is a 3rd party utility which obviously doesn't care about Solaris audit. If we think it is important (big if, IMO), we can work with the TSS community and get the code fixed in the main source branch later. I'm not inclined to delay delivery in order to add auditing and further fork us away from the baseline source. > 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. > 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. > gw-99 Nits: > tcsd(8) should be tscd(1M) > Yes, fixed. > tcsd.conf(5) should be tcsd.conf(4) > Fixed. > There doesn't seem to be a sample tcsd.conf > OK, I will add one to the materials. > tcsd.conf(5) says /etc/tcsd.conf, the spec says /etc/security/tcsd.conf > /etc/security/tcsd.conf is correct. > tcsd(1M) man page should describe the FMRI, config/local_only property > and authorizations. > OK, I will update it. -Wyllys
