[redhat-lspp] Self tets and the TSOL ST

[Lenny Bruzenak]

On Mon, 2006-01-23 at 10:34 -0500, Steve Grubb wrote:
> 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. 

I agree you could make a case for the RPM as long as you either 
1) have a mechanism to protect it from change, or
2) just draw the line in the sand there as to how far you are willing to
exert effort on this problem.

As you say though, the cert rpm config will not always match real world
installs. In this case I'd think a certifiable re-baseline mechanism
would work. Is this possible to certify a procedure or mechanism rather
the config file per se?

I think that there is more also. Some files are allowed to change but
only through approved methods. MLS policy files for example. I'd like
them to be dynamically changeable by an authorized user but have a
notification method if changed outside that approved process chain.

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

I was thinking that the mechanism could be constructed to check the logs
rather than the files. And, to agree, a few weeks later the file might
be replaced with the correct one. 
Don't the audit logs have near-real time info?

> > 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 do not follow; maybe because I am thinking it all can trigger off
audit and it seems you do not think it possible?

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

I understand.
I am still thinking that the on-demand check can be realized by a means
other than a file scan. 
If your audit watch rules are correct and working I believe there to be
a way to configure the LED to save accounting of changes.
If that's true, the on-demand check need only parse the accounting to
meet the requirement.

If you trust the audit watch rules it just seems to me that you could
leverage that effort.

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

OK.

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

Why is that phrase more important than the that which follows, 
"and when invocation of access rights on selected objects occurs"?

Am I misreading it? If one omits that phrase I totally agree with you on
this. But if I'm interpreting the sentence correctly it seems to say the
following (rephrased):

Self tests shall be run on the TSF.
These tests shall demonstrate the correct operation of the TOE.
They shall be run when on of the following conditions occurs:
1: Periodically during normal operation.
2: At the request of an authorized user.
3: Anytime access rights are invoked on the selected objects.

I think this is the correct interpretation because if it were only at
the authorized user request why have the requirement have the
"periodically" part in there at all? 

I guess the evaluators and you are probably more tuned in than myself,
so it is certainly possible the intent was more as you say and I am
interpreting this incorrectly.

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

Thanks for the insight and info,
LCB.

-- 
Lenny Bruzenak <lenny at bruzenak.com>