Using the Security Manager to restrict access to a single package

Question

After reading up on the Security Manager, the package.access property and the use of the [accessClassInPackage RuntimePermission|http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html#RuntimePermission] , it seemed to me that it would possible to set up the following: I have a security-sensitive code base packaged in a jar, and I want to make sure that only one client code base that I specify is permitted to access it. The idea here is to prevent malicious code from executing anything in the sensitive code base; the sensitive code is only accessible to one client that I name in a security policy file. Perhaps rather foolishly, I advised a client to consider this before testing out a sample myself, because much to my surprise, it appears to me that it isn't possible to get the Security Manager to do this at all. Am I missing something? I'm a bit startled by this conclusion -- it seems like such an obvious use for the Security Manager, I'm hard-pressed to be believe that it can't be done, and more inclined to suspect that I'm going about it wrong.
Here's what I thought I could do: set up the package.access property so that it denies access to any package; then in the policy file, grant the RuntimePermission/accessClassInPackage to the client code base that is permitted to access the sensitive code.
Of course, you wouldn't want the package.access property to exclude all packages in the global java.security file, because then no code could be accessed at all. It would be necessary to use the trick of resetting the package.access property within the code, as [illustrated in the secure coding guidelines|http://java.sun.com/security/seccodeguide.html#1-1a] .
But the problem lies in the idea of "use the package.access property to deny access to +any+ package". There doesn't seem to be any way to use wildcards or the like with the property -- it has to specifically name packages (or package prefixes) to which access is forbidden. It wouldn't do to try to name the packages to which I'm trying to prevent access, since we're trying to prevent access from malicious code -- the attacker could just choose package names that aren't on the list. I'd really need to say that access is denied to all packages, except for those in the permitted code base, but the security mechanisms for package access don't seem to allow that.
Moreover, the trick of changing the value of package.access can't be done within the client code -- otherwise, the attacker client would just set the property to his own purposes. But it can't really be done within the sensitive package either, because the whole idea is to prevent access to that package, and by the time it's busy setting the property, it's already too late, because the package has to have been accessed by a client to get there at all.
It seems to me that this a symptom of something I've never really understood about the design of the Security Manager -- you can grant permissions to specific code bases, but you can't revoke permissions from specific code bases, let alone all code bases. What I want to do here is grant access permission to one specific code base and revoke it from all others. There doesn't seem to be any way to express that with the mechanisms of the Security Manager.
The more I look at it, the more it seems that there's just no way to use the Security Manager this way -- set up package access so that a specific code base can only be accessed by one specific client code base. There are surely other ways to get the effect that I'm looking for, but as far as I can tell, none of them involve restricting package access (for example: define a custom permission, grant it only to the permitted client. and check against that permission within the sensitive code base; meaning that the sensitive code has to be accessible to anyone in the first place). This conclusion really surprises me (not to mention my bit of embarrassment with the client); wouldn't this be precisely the sort of thing the Security Manager ought to be good for?

Answer 1

You're looking at this back to front. The security policy file is there for the client to decide how much access he is going to give this application, not for to application to restrict who can use it. If you want to control what used to be called 'state orientation' you can do that directly by looking down the stack trace inside your code.