Reply to thread

Message: [QUOTE="Twisted, post: 653111"] As security-conscious Java programmers surely know, package-private access doesn't stop untrusted code having access -- anyone, including Joe Cracker, can make a class and define it in *your* package. But this could be changed. Here's how: * A "closed package" would have a certain format to its name, such that the name started with a string that could be converted into a fairly large integer + check digits and validated with some sort of CRC check; then a dot and arbitrary further characters. Any package name meeting this description (i.e. the first word, dot-delimited, when decoded in the appropriate manner, passes its validation check) would be closed. The scheme would be designed so that ordinary words would not tend to pass the check (a rare but legal identifier character, say, might be always present). Accidentally creating closed packages would therefore be easily avoidable. The CRC check/whatever would serve this purpose, not a security purpose. * The VM would balk at loading any class defined in a closed package unless it met an authentication check. * The authentication check would consist in extracting/obtaining a signature chunk from/relating to the class, decoding it using the integer obtained from the package name above as a public key, and comparing against a SHA-1 (or even stronger hash) of the class. Then no class would be loaded into a closed package that wasn't signed by whoever named the package. Knowing the name of the package gives someone only the public of a key-pair, so does not enable Joe Cracker to introduce a hostile class thereto; altering an existing class binary or recompiling from modified source would likewise change the hash and invalidate the signature. The signature would prove, then, that *the specific binary loaded* by the VM was authorized by the package "owner" (whoever generated the key pair, and then the package name from the public key of the pair), or at least knew the private key. Note that the signature would not necessarily have to be part of the ..class file. It could be loaded off a Web site, authentication server, or whatever seems appropriate. It could come from an untrusted source; the worst they could do by altering/spoofing signatures without knowing the private key is disable some classes in protected packages. This might enable a denial of service attack, of course, so having multiple and/or local signature info and accepting a class if you accept any signature for it might make sense. Runtime .class generation into, or alteration of classes in, closed packages might need to be disallowed (VM balks), or limited to being done by classes already in the package. Subpackages (i.e., given package.this.that, foo.package.this.that) already don't have privileged access to package private members, and so aren't a security risk here. Of course, the proposed scheme would break the "com.foo.bar" reversed-hostname package naming convention, but could be altered to suit. Or we could dispense with that convention. I'm not a big fan of it anyway, since it implicitly discriminates against anyone who can't afford to pay a premium for their own personal domain name on top of whatever they already pay for internet access (not to think of people with NO NET ACCESS AT ALL) ... and therefore a lot of individual, garage-band, and FOSS developers. (I don't know what a .com domain goes for currently, but I do know it's a recurring fee rather than one-time, and I also know that if it's so much as one red cent plus the need to go out and sign up with a CC company to have a CC# to put in some Web form somewhere so that the next CD Universe type event will expose me to a risk of identity theft, then it is one red cent more than I am willing to pay for the ability to follow this naming convention -- so sue me.) [/QUOTE]

Verification