More Perl regex stuff in E

[shapj@us.ibm.com]

I was thinking in terms of integrity attacks rather than security attacks.
Trojan horses are integrity attacks whose purpose is generally to perpetrate a
security attack.

Demonstrations that the information flow of a program is safe can be done at a
number of granularities.  At the OS level a whole process can be confined.  At
the language level a trusted virtual machine/runtime can undertake to restrict a
program in comparable ways.

I know of no way corresponding way to know that the code does what you think it
does other than inspection.  A secured program can still give incorrect or
compromised answers.  These can ultimately result in security compromises --
consider the case of the compiler introducing code that perpetrates a security
attack.

So, in *addition* to the things you identified for why you can trust the Perl RE
package, I would add that it's source is available for inspection and has been
inspected by a goodly number of people.  This yields some confidence that its
use will not result in combination attacks.

Jonathan S. Shapiro
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085  (Tieline: 863)
Fax: +1 914 784 7595



"Mark S. Miller" <markm@caplet.com> on 04/16/99 10:39:21 AM

To:   "E Language Discussions" <e-lang@eros.cis.upenn.edu>
cc:    (bcc: Jonathan S Shapiro/Watson/IBM)
Subject:  Re: More Perl regex stuff in E





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?