"Keith Patrick" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Comparing the granularity of security would be interesting. I never got
the
> opportunity to really delve into Java security (my work there was
primarily
> in UIs, plus when I started, there was a mentality of "It's Java, so it's
> secure."), so I think it would be interesting to see where Java has come
vs.
> where .Net is with regards to code access security.

Interesting you should mention that. Code access security seems to be
touted as a new thing. In fact, it seems that you could do very similar
things in Java since JDK1.2. For instance, taking the list of CAS features
from:
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconintroductiontocodeaccesssecurity.asp
Am I missing the point of CAS somewhere? What does .NET security offer
which is actually new?


1. Defines permissions and permission sets that represent the right to
access various system resources:
- Java has a hierarchy of extensible permission objects which encapsulate
the individual complexities of permission sets such as File access and Web
access. Permissions can be grouped into sets and assigned to
ProtectionDomains (analogous to ApplicationDomains)

2. Enables administrators to configure security policy by associating sets
of permissions with groups of code (code groups):
- System administrators can toggle these permissions on and off at a similar
granularity to .NET. The code group abstraction is there too, albeit
indirectly.

3. Enables code to request the permissions it requires in order to run, as
well as the permissions that it would be useful to have, and specifies which
permissions the code must never have:
- I don't understand why it's useful to request permissions, as they will be
granted by default if the local policy allows, right? Unfortunately I don't
think Java can programmatically refuse certain permissions. Nonetheless,
Java can check runtime permissions to handle any shortfall in permissions
gracefully.

4. Enables code to demand that its callers have specific permissions.
5. Enables code to demand that its callers possess a digital signature,
thus allowing only callers from a particular organization or site to call
the protected code.
- Not too sure about these in Java.

6. Enforces restrictions on code at run time by comparing the granted
permissions of every caller on the call stack to the permissions that
callers must have.
- For every privelleged operation the call stack will be traversed and
permissions checked. There is also the concept of 'privelleged code' which
I think is similar to permission assertions in .NET.

Ben

I'm afraid I can't offer any answers on the Java side...I didn't even know
it had it (was never really pushed as a core feature when I was doing solely
Java coding). I'm curious as to whether Java has a notion of declarative
security that performs checks upon loading (also, it provides a nice
advantage of having a security policy that you can examine before running,
so you can say, "I know for a fact that MyAssembly.dll is not the cause of
the files being deleted because the entire assembly refuses the permission
outright").
Regarding your question as to why you should request a permission that is
granted by default -> The local policy is independent of the CAS settings,
so even though you can assume the user has certain rights, your assembly's
CAS may refuse them all. By explicitly turning on only the ones you need,
you a) ensure your assembly is as safe as it can possibly be and still
function as intended, and b) you ensure that if, for some reason, local
policy is changed, the requirements and checks of your assembly remain
intact.

Something I know, .NET allows more granular control over "stack walks". In
Java security checks/stack walks for everything, killed the performance.

"Ben" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Keith Patrick" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Comparing the granularity of security would be interesting. I never got
> the
> > opportunity to really delve into Java security (my work there was
> primarily
> > in UIs, plus when I started, there was a mentality of "It's Java, so
it's
> > secure."), so I think it would be interesting to see where Java has come
> vs.
> > where .Net is with regards to code access security.
>
> Interesting you should mention that. Code access security seems to be
> touted as a new thing. In fact, it seems that you could do very similar
> things in Java since JDK1.2. For instance, taking the list of CAS
features
> from:
>
http://msdn.microsoft.com/library/de...us/cpguide/htm
> l/cpconintroductiontocodeaccesssecurity.asp
> Am I missing the point of CAS somewhere? What does .NET security offer
> which is actually new?
>
>
> 1. Defines permissions and permission sets that represent the right to
> access various system resources:
> - Java has a hierarchy of extensible permission objects which encapsulate
> the individual complexities of permission sets such as File access and Web
> access. Permissions can be grouped into sets and assigned to
> ProtectionDomains (analogous to ApplicationDomains)
>
> 2. Enables administrators to configure security policy by associating
sets
> of permissions with groups of code (code groups):
> - System administrators can toggle these permissions on and off at a
similar
> granularity to .NET. The code group abstraction is there too, albeit
> indirectly.
>
> 3. Enables code to request the permissions it requires in order to run,
as
> well as the permissions that it would be useful to have, and specifies
which
> permissions the code must never have:
> - I don't understand why it's useful to request permissions, as they will
be
> granted by default if the local policy allows, right? Unfortunately I
don't
> think Java can programmatically refuse certain permissions. Nonetheless,
> Java can check runtime permissions to handle any shortfall in permissions
> gracefully.
>
> 4. Enables code to demand that its callers have specific permissions.
> 5. Enables code to demand that its callers possess a digital signature,
> thus allowing only callers from a particular organization or site to call
> the protected code.
> - Not too sure about these in Java.
>
> 6. Enforces restrictions on code at run time by comparing the granted
> permissions of every caller on the call stack to the permissions that
> callers must have.
> - For every privelleged operation the call stack will be traversed and
> permissions checked. There is also the concept of 'privelleged code'
which
> I think is similar to permission assertions in .NET.
>
> Ben
>
>
>
>
>

Correct me if I'm wrong about attributes in java. I don't think java has
attributes yet. Only in next version. So probably no flexible and extensible
declarative security.

"Keith Patrick" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I'm afraid I can't offer any answers on the Java side...I didn't even know
> it had it (was never really pushed as a core feature when I was doing
solely
> Java coding). I'm curious as to whether Java has a notion of declarative
> security that performs checks upon loading (also, it provides a nice
> advantage of having a security policy that you can examine before running,
> so you can say, "I know for a fact that MyAssembly.dll is not the cause of
> the files being deleted because the entire assembly refuses the permission
> outright").
> Regarding your question as to why you should request a permission that is
> granted by default -> The local policy is independent of the CAS settings,
> so even though you can assume the user has certain rights, your assembly's
> CAS may refuse them all. By explicitly turning on only the ones you need,
> you a) ensure your assembly is as safe as it can possibly be and still
> function as intended, and b) you ensure that if, for some reason, local
> policy is changed, the requirements and checks of your assembly remain
> intact.
>
>