Security Risk?

[Kevin Bealer]

Manfred Nowak wrote:
> Bill Baxter wrote
> 
>> It's like breaking into the burglar's house, dumping your
>> valuables in the middle of the floor and then tauting him with
>> "let's see you steal THAT!" as you strut out the door.
> 
> Yes that is one side of the problem, if one trusts the wrong one.
> 
> But the other part is, that after you left the burglars house another 
> burglar ties you to the valuables he just stole from someone else and 
> by beeing unable to cut that ropes you are doomed to transport the 
> stolen valuables for that burglar.
> 
> And this part seems to be avoidable.
> 
> -manfred

Are you used to programming in Java?  I ask because in Java you can 
build classes that are secure from other classes in the same binary (to 
some degree), but in C, C++, D, you need to do security that is between 
processes.  This means be very careful about user data, never assume 
anything about the data, and never try to run anything the user provides 
as code or as an expression.

The Java way means that you can pull a compiled object from a database 
and run its methods with reflection.  I don't think this is ever safe in 
C++ or D unless you know what all the classes do.

C++, C, D, can't do 'class security' the Java way because they are not 
interpreted languages.  I don't think there is a way around this except 
to compile and run the untrusted code in another process -- and even 
this is a bad idea if you don't trust the code.

But my understanding of Java security in this regard is somewhat simple 
since I've never actually implemented much Java that needed or tried to 
be secure.

Kevin