Consider a Subject ProtectionDomain that is added to the stack, instead of
Subject Principals being injected into every domain on the stack:
Subjects don't have code, they lack the ability to use one permission to gain
another, so if a ProtectionDomain representing only a Subject and its
Principals has AWTPermission("*") and AudioPermission("*"), it means users can
use a application locally as intuitively expected. However when untrusted code
appears on the stack, readDisplayPixels, accessClipboard, listenToAllAWTEvents
and record are no longer allowed, preventing an attack that could steal the
users private information. Also because the user might have
SocketPermission("*", "connect, resolve"), the untrusted code can't use it to
transmit stolen data and the application has limited network and disk acces
while the untrusted code remains on the call stack.
Here's an idea:
If we extended ProtectionDomain, say SubjectProtectionDomain, then Permissions
typically meaningingful only to code can be included in domain static
permissions, so they are automatically granted and don't have to be managed in
policy files. Application specific Permissions would still need to be granted
in policy files, so this would need to be well documented. A system property
could be set to use the default SubjectDomainCombiner behaviour if required,
allowing choice depending on deployment.
It must be remembered that developers writing existing software expect that
Principals only add extra Permissions, so they probably have not written code
with doPrivileged blocks in mind for Principals.
Assume - makes an Ass out of you and me.
Thoughts?
Cheers,
Peter.
