AW: [aosd-discuss] New-guy-type questions

[Arno.Schmidmeier at sirius-eos.com]

Hi all,
All your statements are valid, for a group which develop, assembles and
deploy an AOSD based project/product.
But I believe these statements are not true, if a third person can apply
AOSD between development and deployment. In this cases, your cosmos schemas
should be stored inside the binaries, too.

These problems are outlined in the classical security scenario, where Malroy
applies AOSD to compromise Alice and Bob.

e.g. now imagine a very very simple security exploit with AOSD at hand.
Malroy write following aspect: (I use aspectJ for convenience, 
the idea can be realized by any other AOSD tool, which does support binary
weaving)

String around():PasswordMethod(){
	String Password=proceed();
	System.out.println("Key I have got it. The password is"+Password);
	return Password;	
}

Malroy applies this patch to a java application, which Bob uses to access
the database of Alice.

I would like to have a possibility, to prohibit such simpliest security
exploits, in the languages which do offer binary weaving.

Sorry, I still do not see, how you can solve this requirement with your
cosmos schema.

kind regards
   Arno

P.S. I do not have a solution for such a kind of scenario. I just wanted to
outline a lot of work, for VM manufactors, AOSD researchers, Security
Researchers, etc.

> -----Ursprüngliche Nachricht-----
> Von: Juri Memmert [mailto:memmert at jpmdesign.de]
> Gesendet: Freitag, 4. Oktober 2002 14:41
> An: Arno.Schmidmeier at sirius-eos.com
> Cc: AOSD
> Betreff: RE: [aosd-discuss] New-guy-type questions
> 
> 
> Am Fre, 2002-10-04 um 13.21 schrieb Arno.Schmidmeier at sirius-eos.com:
> 
> 
> Hi all,
> 
> 
> > Juris approach is quite fine (I realy like it), 
> > as long as you have following assumption:
> > The binary code can be adviced/extended modified, without 
> breaking the 
> > initial purpose of the binary code.
> 
> Why is that?
> 
> As I stated:
> 
> > > I solve this problem normally by defining what elements I 
> do not want to
> > > be overwritten in the Cosmos schema accompanying the application.
> > > Any modification of that definition is also kept in that schema as
> > > separate concerns.
> > > Then, for a new (or even nightly) build, the schema is 
> analyzed and the
> > > changes to the policies are noted and either accepted or 
> rejected by the
> > > build manager.
> 
> I did not say that the change needs to comply to the initial 
> purpose of
> the code. This is an assumption that you can't fulfill more often than
> not.
> 
> The contracts defining whether to allow weaving state (to borrow your
> example):
> 
> > The caller requires, that he is invoking directly the 
> method, because the  
> > return value shall not be read, shall not be modified, etc.
> > The called function requires, that the return value, is delivered 
> > to the code who requested it, and that the return value 
> shall not read,
> > altered, etc.
> 
> The new development step, which wants to change that defines another
> contract.
> The original contract and the changed contract are evaluated by the
> build manager / architect / lead developer / etc.
> If the change of the contract is acceptable, the original method is
> modified through the weaver.
> If the contract is not acceptable, it is not modified.
> 
> The decision is stored in the cosmos, too. Thus, later builds 
> don't have
> to concern themselves with decisions already made, unless explicitly
> desired.
> 
> You write:
> > These are decisions what the original developer, who wrote 
> the method had
> > made.
> > And these decisions must not be changed by anybody. 
> 
> Why is that? Don't developers err? Don't requirements change? Don't
> applications evolve? Don't customers change their minds? (Sorry for
> being ironic, but you know the problems)
> 
> Let us assume your problem and modify it a bit:
> 
> public String getPassword()
> {
>   // Here, a database is queried for the password
> }
> 
> is changed to
> 
> public String getPassword()
> {
>   // Here, the LDAP is queried for the password
> }
> 
> The contract of the method remains the same, so the change is 
> valid, as
> you said.
> 
> Change it to
> 
> public String getPassword()
> {
>   // Here, a database is queried for the password
>   // The password is a PGP private key that is used to sign messages
>   // sent to the server.
>   // It is now stored for a while in a cache to reduce the load on the
>   // server and for work offline.
>   // This is done in a secure manner, so that no new problems occur
> }
> 
> Yes, I am aware that this is not a good example as there are other
> ways... but this method is the central password handling 
> method, so the
> change belongs here.
> 
> This change definitely breaks the developer's initial purpose. But he
> didn't anticipate that kind of use.
> Should we prohibit that kind of use?
> 
> > So they should be stored somewhere in the binary format, if 
> you have binary
> > "weaving".
> 
> I think we should not prohibit it.
> 
> The Cosmos schema is a central part of the development process. The
> application would not be complete without it. Thus, the storage in the
> Cosmos schema is good enough for the development as I see it... but
> maybe I miss something?
> 
> As soon as the application leaves the project and is used somewhere
> else, they get all the documentation, including the Cosmos schema.
> If they don't use AOSD, they can't use it anyway... and if 
> they use it,
> they should better look at what is in the schema... ;-)
> 
> Were the definition in binary format, they would be blocked 
> from reusing
> a piece of code that is important to them.
> 
> Let us assume a class (in sudo code)
> 
> public class PasswordHandler()
> {
>   public String getPassword();
>   public void setNewPassword(String aNewPassword);
>   public int getPasswordAge();
>   public void agePasswordBy(int secondsToAgeThePasswordBy);
> }
> 
> and you prohibit changes to getPassword(), then they'd be hard pressed
> to reuse the rest within the context of PasswordHandler.
> 
> Let's assume, they want getPassword() to generate random 
> passwords that
> should be broadcasted to various recipients in a P2P network... that
> would break the contracts you stated.
> 
> They could always copy the methods of PasswordHandler to
> NewPasswordHandler.
> NewPasswordHandler would contain the new getPassword method 
> and finally,
> you'd rename it back to PasswordHandler, but is that the right way to
> circumvent the "don't AOP me" block?
> 
> 
> > Because I assume, that you do not treat your cosmos schema 
> as binary format,
> 
> No, I don't treat it as binary information... That may change in later
> versions of the Cosmos (Stan Sutton is working on a class-based
> incarnation while mine is XML), but as it is under version 
> control, the
> integrity is quite well guarded.
> 
> 
> Kind regards,
> 
> 
> 	Juri
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://server2.hostvalu.com/pipermail/discuss_aosd.net/attachments/20021004/a252af2d/attachment.htm