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.
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.
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.)
gw-1a
Additionally, setting parameters and taking/switching ownership require
audit. They both are security relevant (and possibly administrative
actions).
gw-1b
How are the applicable subset of the 13 MRPP (see below) required
audit events generated by this project? What is that subset?
gw-1c
Introduction of an object (storage or otherwise) into a subject's
address space requires auditability.
gw-2
As the TPM can be switched between various owners, what it the
object reuse policy/implementation?
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.
gw-99 Nits:
tcsd(8) should be tscd(1M)
tcsd.conf(5) should be tcsd.conf(4)
There doesn't seem to be a sample tcsd.conf
tcsd.conf(5) says /etc/tcsd.conf, the spec says /etc/security/tcsd.conf
tcsd(1M) man page should describe the FMRI, config/local_only property
and authorizations.
===============================================================================
From the Medium Robustness Protection Profile(s)
The basic Audit requirement reads:
Explicit: Baseline Cryptographic Module (FCS_BCM_EXP.1)
Cryptographic Key Generation (for symmetric keys) (FCS_CKM.1(1))
Failure of the symmetric key generation process 9
Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1(2))
Failure of the asymmetric key generation process 9.
Cryptographic Key Distribution (FCS_CKM.2)
Failure to properly complete the key distribution process 9
Cryptographic Key Destruction (FCS_CKM.4)
Failure of the key zeroization process 9
Explicit: Cryptographic Key Validation and Packaging (FCS_CKM_EXP.1)
Failure of a key validation technique 9.
Explicit: Cryptographic Key Handling and Storage (FCS_CKM_EXP.2)
Failure in key handling or storage 9.
Cryptographic Operations Availability (FCS_COA_EXP.1)
Cryptographic Operation (for data encryption/decryption) (FCS_COP.1(1))
Failure in encryption or decryption 9.
Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2))
Failure in cryptographic signature 9.
Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3))
Failure in hashing function 9.
Cryptographic Operation (for cryptographic key agreement) (FCS_COP.1(4))
Failure in cryptographic key exchange 9.
Explicit: Random Number Generation (FCS_COP_EXP.1)
Failure in the randomization process 9
FootNote 9:
Typically, upon detection of a crypto-related failure, a system indication
should be generated, and the system should transition to a known safe (secure)
state. The generation of an audit log can provide a mechanism for capturing
more information about a failed event. The exact content of the crypto-related
audit log is implementation-dependent. However, the log should include
information that could help pinpoint the part of the crypto-related process
that failed, but without compromising the value of any critical cryptographic
security parameters. In addition, the audit record requirements specified in
FAU_GEN.1.2 should be considered and included where appropriate. As a simple
example, detection of a key checkword error during an internal transfer of
key might be implemented as follows: Generate a "Bad Key" error message to the
system, prevent use of the bad key and zeroize it, and generate an audit
record that includes the date of the event, the time of the event, "key
checkword error", bad key ID tag or subject/user associated with the bad key,
and "failed key transfer during internal handling".
The FCS_ stuff refers to other parts of the Protection Profile.
