On 05/07/2014 2:41 AM, Matt Oliveri wrote:
> I still think you're thinking about Java casts the wrong way, and that
> they aren't security-related operations, and that in itself, this is
> not a design flaw.
It seems pretty clear that the set of methods define the permission set,
and thus upcasts attenuate permissions, and downcasts amplify
permissions. Therefore, ambient downcasts are an ambient rights
amplification.
Imagine a Java-like language without downcasts. Ignoring whether this is
a good design, suppose we have the following:
class ROFile {
byte[] Read();
void Seek(int pos);
}
class RWFile : ROFile {
void Write(byte[] data);
}
It seems clear that no subprogram written against ROFile can write to an
underlying file, even when given an RWFile, no matter what other
subprograms it may call to do its job.
But, as soon as you reintroduce downcasting, some subprogram could
attempt a cast to an RWFile and violate this property. Perhaps not the
immediate subprogram you call, which you may trust, but perhaps some
subprogram that *it* calls. In other words, authority is no longer the
transitive reflective closure of permission given the apparent object
type, because a downcast can amplify that object type to some more
specific type to access more methods.
Downcasting could perhaps be a closely held operation, but ambient
downcasting is definitely a design flaw. Perhaps you're thinking of some
usage which *necessitates* downcasting in Java, like simulating closed
sums. This is a much more limited pattern than pervasive downcasting
though. Unrestricted downcasting is a design flaw for secure programming.
Sandro
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
