[redhat-lspp] Self tets and the TSOL ST

Steve Grubb sgrubb at redhat.com
Mon Jan 23 15:34:12 UTC 2006


On Friday 20 January 2006 19:31, LC Bruzenak wrote:
> 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.

And how would you know that files haven't changed? As I understand it, there 
are 3 pieces to the puzzle. Executables should be consistent, Config files 
should be consistent, and in memory policy should match what's on disk or be 
explained. I think rpm could be used to verify that executables haven't 
changed. The problem is the config files. The cert rpm will have 
configuration changes that rpm will flag as changed everytime its run, so rpm 
becomes useless for this. 

> Amy Griffis's audit watch rules also could meet that 
> part right?

No, not at all. If there is an audit rule that watches the file you will get a 
message in the logs saying that a change occurred. A few weeks later, that 
message is no longer in the logs and you have no idea of consistency. 
Besides, the requirements say that there will be a toll available that can be 
run at will for authorized users to check the consistency.

> 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.

The watch rules only help when you run the consistency checker and notice a 
change and want to when, and who did it.

> 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.

No, no, no! These do not provide an on demand check.

> 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.

The self test is not an audit requirement. The self test will send audit 
events, but that's the extent of the relationship.

> > 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,

This is the important phrase...at the request of the authorized user.

> > 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)

Notice the "on-demand" capability.

-Steve




More information about the redhat-lspp mailing list