river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <peter.firmst...@zeus.net.au>
Subject Re: Distributed network security
Date Mon, 02 Jul 2012 08:05:40 GMT
Maybe this time?

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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message