[redhat-lspp] Self tets and the TSOL ST

[LC Bruzenak]

George,

Reading the requirement here it seems to me that tripwire would only
really meet half of the requirement. In the case where no files have
changed, you could argue that the TOE is still operating correctly if it
was from inception. Amy Griffis's audit watch rules also could meet that
part right?

In the case where something important has changed, this requirement says
you must perform an action (either on behalf of an authorized user
action or triggered by a change to a relevant file(s)) which ensures to
that user that the TOE is still configured "correctly". 

To me it seems that regardless of the reporting mechanism (tripwire or
the audit watch rules) the correctness checker would still be something
which must run independently and return some yea/nay answer as to its
determination.

We did something similar for our TCB files. If they change as a result
of an authorized user change, that user also had the capability to re-
set the baseline. In practice for us, that meant generating a new set of
checksums on TCB files. If they change outside that path, we did
alerting tied into our application. You won't have that mechanism
available but maybe something generic will suffice to meet the req.

I asked Amy about this and she pointed to the Linux Event Dispatcher
(LED) from Junji Kanemaru (posted to the linux audit list). This in
conjunction with the audit watch mechanism seems to me that it would be
able to meet all aspects of the requirement. I have not yet looked at
the specifics, but the concept seems to fit the bill.

The hard parts are:
1: How do you determine the "correct operation of the TOE" if a file
which is considered integral has changed? 
2: How do you protect the audit watch lists, the LED (or whatever
actioning mechanism) from subversion?

Thanks,
LCB.

ps: I know that much of this discussion is probably suited for the audit
list but since it started here I figured it was appropriate.

On Fri, 2006-01-13 at 16:10 -0600, George C. Wilson wrote:
> It looks like the TSOL security target doesn't help us much on the RBACPP self-
> test requirement.  So we're probably going to have to use tripwire or a
> lightweight script.  Here's the section that documents the deviation:
> 
> 5.1.5.3 TSF Self Test
> 
> The TSF shall run a suite of self tests periodically during normal operation,
> at the request of the authorized user, and when invocation of access rights on
> selected objects occurs to demonstrate the correct operation of the TOE.
> (FPT_TST.1)
> 
> <Application Note: The requirement of FPT_TST.1 for self tests when access
> rights are invoked on selected objects is currently not met by Trusted Solaris8.
> However, [NIST2] from the RBAC author clarifies that  In my best judgement, I
> feel this functionality is not implemented as a state of practice and hence
> conformance to the PP can be claimed without implementing this particular
> aspect of FPT_TST.1.1 requirement. Hence, although Trusted Solaris8 does not
> implement this SFR, conformance claims with [RBAC] are not affected.>
> 
> The TSF shall provide authorized users with the capability to verify the
> integrity of TSF data. (FPT_TST.1.2)
> 
> The TSF shall provide authorized users with the capability to verify the
> integrity of stored TSF executable code. (FPT_TST.1.3)
> 
> [NIST2] Letter from R. Chandramouli, re: FPT_TST.1.1 in RBAC PP, Computer
> Security Division, NIST, dated 16 July 2001.
> 
-- 
LC Bruzenak
lenny at bruzenak.com