--- Begin Message ---
What about when a client communicates with a remote server?
For example, a remote policy service, where an admin has decided to update all
nodes with new policy and a process executes that running under admin
privileges. Lets say also that the administrator has spki authority
certificates that dynamically assign his or her priviledges (using a dynamic
policy) during an ssl jeri session at the server. An alternative to spki is to
use trusted X509 certificates and authentication, that would not require a
dynamic policy grant, I just thought I'd throw in an SPKI example.
Under the existing framework, if semi trusted code (from another company) can
find a way to be run on that admin thread, it can dictate policy, for all nodes
in a djin. This might allow an attacker from one company get access to
procurement systems etc.
Instead, if the admin only has a Subject ProtectionDomain added to the call
stack, this attack is no longer possible and it becomes more viable to mix semi
trusted and trusted code in a system.
These use cases also help us model which permissions Subjects can and cannot
have, for instance some Permissions only apply in a local context, like
AWTPermission, so these permissions have no place at the services server, but
since ProtectionDomains are not serialised, only the subject, a different
SubjectProtectionDomain can be constructed at or by the server.
This means we now have more than one category:
LocalSubjectProtectionDomain
RemoteSubjectProtectionDomain
This is similar to how static Permissions are automatically granted to applets.
So the permissions granted by default in these domains would be relative to
where the Subject is running and where it originated from.
So a Principal granted AllPermission, such as an administrator, would have this
permission defined in a policy and certificates would be used to authenticate
the admin, even though the admin is defined in a RemoteSubjectProtectionDomain,
the static domain permissions are merged by the local policy provider with
those of the policy.
Untrusted code could no longer hijack the administrators privileged thread.
So this preserves the intersection model where all domains must have
Permission, rather than elevating the privileges of a thread.
It starts to become simpler to define and model when we make this minor subtle
change to subjectDomainCombiner.
Peter.
--- End Message ---
