Dan Creswell wrote:
Hi Peter,
On 4 August 2011 03:43, Peter Firmstone <[email protected]> wrote:
Dan, you're wise and I respect your view.
Thank you equally be careful how much wiseness you attribute to me and
thus how much respect you give me - nobody is perfect! :)
Security matters to me because I plan to deploy over insecure networks.
Yep, that's visible in your areas of focus in respect of River and
given it's nasty stuff to play with I appreciate your focus.
Luckily security is mostly complete, Bob Scheifler's team achieved what they
set out to do, a very difficult task I might add. But this takes skill on
the application developers part to understand and utilise.
Agreed.
For an application developer, determining policy files and permissions is
often one of the big hurdles.
Agreed.
I get where you're coming from, deployment needs to be simpler and
installation / configuration needs to be automagic.
Quite - a routine problem is the selection of an interface that does multicast.
Maybe we need a jira with a list of common difficulties experienced, so
we can pick them off one by one.
To make it possible to add in security later, requires the application
developer to follow certain rules and method calls. These are typically
very similar among different services.
Absolutely.
I'm wondering if it's possible to use annotations to hide these methods from
the application developer on the client side, so they can learn to develop
without worrying about security, perhaps using only reflective proxy's to
start with, then activate security later and start using smart proxy's when
ready?
Can I check I understand that annotations thing? I think you're saying
that we'd use annotations on their code to identify methods we'd need
to invoke for them or provide stub implementations for? Seems
reasonable if that's the case.
Correct.
I would say reflective proxy's are the easy starting point, although
if we're doing the annotations thing, maybe we can make it work
reasonably for smart proxies too. In fact, maybe annotations are a way
to make things nicer for all regardless of level of expertise. I think
we'd have to allow things to work without annotations (lots of code
out there already written) but....
Now I must confess, I've quite happily used other peoples annotations,
but admit to never having defined any.
We've got the ASM library, we could use this as an annotation processor,
to weave in what people like to refer to as boilerplate code (well
bytecode actually).
Existing code missing the annotations, wouldn't be affected.
I guess a good place to start is to identify the snippets of code we
need to create, and what annotation types we should define.
Typically we're talking proxy verification, dynamic permission grant's,
running as Subjects, using key stores and using method constraints.
Uh huh - I think the toughest of those for newbies are dynamic
permission grants and proxy verification (at least in the smart proxy
case), possibly Subjects too.
By using an annotation processor and including a permissions.perm file
in META-INF, we could weave in code that fetches the permissions from
the proxy jar and dynamically grants them, if the proxy is authenticated
and verified and provided the caller has the necessary
GrantPermissions. In this case the caller is the client Subject.
Since GrantPermission's are designed specifically for Dynamic grants,
there is an assumption that the client will grant these to proxy's it
can authenticate.
We could weave in the code that does proxy verification too. Then the
application developers only needs to work out how to run as a Subject.
The following questions remain:
1. Does the client Subject need to know the permissions it is about
to grant?
2. Is it an acceptable compromise to assume the client Subject is
prepared to grant these permissions to the proxy of any
authenticating service?
3. GrantPermission(AllPermission) would be a security risk.
4. The client Subject can have a wider scope of permissions than
those it has GrantPermission for, so it would be an administrator
choice what Permissions users can grant.
5. It's generally bad practise to ask the user directly if they want
to grant permission, they often mindlessly just say: "Yes! I want
to see the flying pig video!"
6. Do we need to retrieve the service's authenticating, Subject
retrieve its Principal's and use that information to make a
decision about the permissions the client's prepared to grant?
This sounds too fine grained to me. We probably want something
that works most of the time, is relatively secure.
7. Signed jar files can be used to restrict class loading with
DownloadPermission granted to signers, this improves security,
Authenticating the service and using proxy verification is a way
of saying, I can trust the code because I trust the authenticated
Service and it trusts the code. Signing the code is a way of
improving trust in the code, but it doesn't authenticate the
Service and the Service still needs to know if the proxy belongs
to it.
Cheers,
Peter.
Reference:
http://publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/com.ibm.websphere.osgifep.multiplatform.doc/topics/ca_java2sec.html
Java 2 security and OSGi Applications
You can use Java 2 security in OSGi applications in a similar way to
Java 2 security in Java EE applications. This topic describes the
differences when you use Java 2 security in an OSGi application.
The OSGi specifications allow you to have permissions.perm files in the
OSGI-INF directory of each bundle, so that you can apply fine-grained
control to the permissions for each bundle. The OSGi Applications
implementation in WebSphere® Application Server supports this
specification, and also allows you to have a permissions.perm file in
the META-INF directory of the OSGi application, which gives you
coarser-grained control of the permissions for the application as a whole.
A permissions.perm file is a plain text file that contains comments or
single-line permissions in the following form:
# Permissions file
( org.osgi.framework.AdminPermission "*" "*" )
( org.osgi.framework.PackagePermission "*" "exportonly,import" )
( org.osgi.framework.ServicePermission "*" "get,register")
( org.osgi.framework.BundlePermission "*" "host,provide,fragment")
Relation to Java EE applications and was.policy files
These application-level permissions.perm files perform a similar
function to was.policy files in enterprise applications. When you
migrate an application from Java EE to OSGi, any existing was.policy
file is converted into a permissions.perm file to be used with the OSGi
permissions framework.
In the conversion, any codebases specified within the was.policy file
are ignored, and all permissions specified are added to the
permissions.perm file. This means that all permissions are promoted to
the application level. If you need finer granularity, you can modify the
file after conversion. In this case, you would remove the required
permissions from the resulting permissions.perm file, and move them into
permission files within the OSGI-INF directory for each affected bundle.
Cheers,
Peter.
Two cents,
Dan.
Dan Creswell wrote:
I recall Waldo saying some time ago that systems get harder and harder
to do as you in order from:
(1) Single-thread single machine.
(2) Multi-thread single machine.
(3) Multi-machine.
(4) Multi-machine with security.
On that basis, I'm tempted to say we should make our lives easier by
setting something that limits the amount of heavy-lifting we need
before we have anything to show for it/play with. Thus, I'd say we do,
in order:
(1) We should look at easing the admin burden - in terms of scooping
up exceptions, logging, monitoring and such.
(2) Sort out a bare bones out of the box experience - minimal configs,
intelligent auto-setup for network interface selection.
(3) Security for all the above.
Now, I know and it's right to say on some levels, baking in security
from the start often is what needs to be done but Jini itself managed
without security early on and we probably ought to plan to "throw one
away" (as per Mythical Man Month) as we figure these things out so I
personally believe security can wait.
+1 for doing as much through JMX as possible by default if that's
practical (fear with multiple JVMs on one box a la simulating
distributed services it might get tough).
