At 07:39 AM 4/16/99 -0700, Mark S. Miller wrote:
>At 07:32 AM 4/16/99 , shapj@us.ibm.com wrote:
>>I would add to your list that the code is inspectable, and modulo clever
>>attacks
>>within the JVM of the type described in Kernighan's Turing Award talk, it is
>>therefore likely to be free of trojan horses.
>
>Could you define "inspectable"? If you mean human understandable, as
>opposed to obfuscated, I believe and hope that isn't true. Our security
>should rest only on checks that the code starts with no privileges, and is
>constrained to follow capability discipline. What kind of trojan horse do
>you have in mind?
>
I think what Jonathan is referring to here is what the Orange Book people refer to as "assurance". The KeyKOS architecture was capable of meeting the A1/B3 security requirements. The NCSC people wanted to evaluate it at the B2 level because they were not sure they could achieve a B3 level of confidence in the assembler language implementation.
The bottom line is, you need a good reason to believe that your security kernel actually correctly implements its specification. In E, the JVM, and some of the E runtime make up the security kernel which is shared by everyone. (It would be a good idea to call out exactly what that kernel is.) In addition, if a user writes code which makes security relevant decisions, that code, and all the tools it uses is part of that application's security kernel.
Cheers - Bill