Home » Eclipse Projects » Equinox » security concerns
|
| Re: security concerns [message #25895 is a reply to message #25696] |
Tue, 17 June 2003 00:36   |
 Keith Kimball
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
>> What about the case that there a 2 versions of a library each
>> signed by a different user. Depending upon which version is
>> selected, different permissions are granted. Is
>> this an issue?
Need new Policy format and implementation. The default policy
implementation uses a permissions format that is insufficiently
expressive for what we want to do. Would probably use an XML based
format (XACML?). The Policy class implementation also needs to support
dynamic changes during runtime
>> Could you give an example of where the Policy format is insufficeint?
Will need to add doPrivileged() blocks to critical code in the platform.
Basically, when Permissions are insufficiently expressive such that
code needs to figure out dynamically based on context whether an
operation should be carried out, a 'doPrivileged' section needs to be
introduced in the code. For example consider the following call stack:
platform.Code.criticalMethod() -> performs critical operation
platform.Code.someMethod() -> calls criticalMethod()
unknown.Code.otherMethod() -> calls someMethod()
If there is a sufficiently expressive Permission object that could apply
to this call stack in all scenarios, (i.e. no matter what the context,
the permission defines whether "unknown.Code.otherMethod()" is allowed
to do the critical operation) then we do not need a doPrivileged block.
An example of that might be using a FilePermission to protect a specific
file. I.E. if critical method is going to access a specific File (or
directory) and we know that in ALL circumstances we want
unknown.Code.otherMethod() to only have 'read' permission on that file
then we don't need a doPrivileged block inside criticalMethod. We would
simply grant the permission to read the particular file. Note that a
Permission that granted permission to read ALL files would not be
expressive enough here because it would be more permissive than we want.
If, on the other hand, whether we allow the "unknown.Code.otherMethod"
to perform the operation is determined by contextual information
unavailable when the Permission is defined (we didn't know the path to
the file), or simply of a nature that can't be expressed by the
Permission (for example, we want to provide access to parts of a file
but not other parts, and perhaps only if other context metadata is
satisfied such as who the current 'user' is, then in that case, we need
to do two things to the 'criticalMethod()' code. 1) we need to put a
doPrivileged section in it to stop the security checks from going
further down the stack and 2) we need to actually codify the logic to
figure out programmatically whether the operation should be performed or
not.
>> Could this be made simplier? The way I think of it is that if
>> you're doing an operation on your own behalf and not being spoofed
>> by your caller, you add the doPrivilege.
>>
>> The USE case I think of is that the users asks for the
>> current time and the time routine needs to read the disk to determine
>> the time zone. The "time routine" does a doPrivilege to assert that
>> it is reading the disk on its own behalf rather than for the user.
>> If you trust the time routine to read the disk, the operation is
>> permitted. Without the doPrivleged operation, the stack is scanned
>> further and if any frame contains code which is untrusted to read
>> the disk, a SecurityException is raised.
Need a new AccessController implementation. This is where we need to
trap unpermitted actions and handle them in a user-friendly way such as
by asking the user if he/she wants to allow the action once, or allow
the action always or deny it, whatever. In a GUI application, this
means putting up appropriate wizard panels to prompt the user. For a
headless application, it may mean prompting at stdin.
>> Why not provide your own SecurityManager which only overrides
>> CheckPermission? The implementation could call the normal
>> CheckPermisison and if it fails then prompt the user and
>> take the appropriate action (such as modifiying the policy
>> file) based on the response.
>>
>> I'm not sure you can provide your own AccessController.
>> It is a final class and I'm not sure there's a mechanism to
>> install your own - don't know.
It is expected that running the platform with a security manager enabled
will cause a performance hit during runtime. This impact can be avoided
by code that does not directly or indirectly invoke a privileged action
(thus triggering a security stack crawl), however that does not seem
likely for the bulk of really useful code.
>> Do we know if the degradation is measurable? Aren't most of the
>> operations infrequent?. For example, a file open is checked but
>> NOT each of the IO operations.
The platform could run without a security manager enabled and this hit
should go away. However, 'doPrivileged()' sections of code may still
have an impact, depending on how well designed they are.
>> Again, is it measurable?
|
|
|
| Re: security concerns [message #25977 is a reply to message #25895] |
Tue, 17 June 2003 17:48 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Keith Kimball wrote:
>
> >> What about the case that there a 2 versions of a library each
> >> signed by a different user. Depending upon which version is
> >> selected, different permissions are granted. Is
> >> this an issue?
>
I don't think so. A code source is the aggregate of two things: the URL
pointing to the code's location (codebase) and the identity of the
vendor (i.e. one or more certificates). Thus, two versions would indeed
be treated as different code sources and might need different sets of
permissions. This would mainly be problematic in the case of an upgrade
where it would be a user inconvenience to prompt him/her again for
permissions that were presumably already granted to the old version. If
the vendor uses the same signer for both versions, though, then so long
as we are granting permissions based on signer, rather than codebase,
this would not happen. I expect it would be rare that a vendor would
use a different signature for a later version of the same code.
> Need new Policy format and implementation. The default policy
> implementation uses a permissions format that is insufficiently
> expressive for what we want to do. Would probably use an XML based
> format (XACML?). The Policy class implementation also needs to support
> dynamic changes during runtime
>
> >> Could you give an example of where the Policy format is insufficeint?
>
I got this from two sources in conversation. I'll push for more
detailed explanation and get back on this. I'm thinking that better
federation and portability are concerns. One usecase that is definitely
not currently addressed is to run with a Policy object sourced from a
server or db thus controlling administratively both what code has
permission to run on the target machine but also the user rights all
with the same policy. This would require a new Policy implementation.
I'm not saying we need to go all the way here right away. We can
probably start with something much closer to the basics.
> Will need to add doPrivileged() blocks to critical code in the platform.
> Basically, when Permissions are insufficiently expressive such that
> code needs to figure out dynamically based on context whether an
> not.
>
> >> Could this be made simplier? The way I think of it is that if
> >> you're doing an operation on your own behalf and not being spoofed
> >> by your caller, you add the doPrivilege.
> >>
> >> The USE case I think of is that the users asks for the
> >> current time and the time routine needs to read the disk to determine
> >> the time zone. The "time routine" does a doPrivilege to assert that
> >> it is reading the disk on its own behalf rather than for the user.
> >> If you trust the time routine to read the disk, the operation is
> >> permitted. Without the doPrivleged operation, the stack is scanned
> >> further and if any frame contains code which is untrusted to read
> >> the disk, a SecurityException is raised.
>
There are two patterns to usage of doPrivileged blocks. One is to stop
the stack crawl prematurely at trusted code and always grant permission
within the context of the trusted code. The other is to stop the stack
crawl prematurely at trusted code which uses run-time logic to itself
decide whether to grant permission. For example, suppose your clock
code had write routines. You might allow calling routines to set the
time if the user is in an admin group but otherwise not. Or you might
allow the calling code to set it forward, but never back. The point is
these are decisions that may not be resolvable by application of a basic
Permission to the stack crawl. Instead they may require the use of
contextual runtime logic.
> Need a new AccessController implementation. This is where we need to
> trap unpermitted actions and handle them in a user-friendly way such as
> by asking the user if he/she wants to allow the action once, or allow
> the action always or deny it, whatever. In a GUI application, this
> means putting up appropriate wizard panels to prompt the user. For a
> headless application, it may mean prompting at stdin.
>
> >> Why not provide your own SecurityManager which only overrides
> >> CheckPermission? The implementation could call the normal
> >> CheckPermisison and if it fails then prompt the user and
> >> take the appropriate action (such as modifiying the policy
> >> file) based on the response.
> >>
> >> I'm not sure you can provide your own AccessController.
> >> It is a final class and I'm not sure there's a mechanism to
> >> install your own - don't know.
>
Yeah, I agree here. It slipped by me that AccessController is final.
For our purposes, overriding the checkPermission() in SecurityManager
should be sufficient. The above paragraph will be switched to read
'Need a new SecurityManager'.
> It is expected that running the platform with a security manager enabled
> will cause a performance hit during runtime. This impact can be avoided
> by code that does not directly or indirectly invoke a privileged action
> (thus triggering a security stack crawl), however that does not seem
> likely for the bulk of really useful code.
>
> >> Do we know if the degradation is measurable? Aren't most of the
> >> operations infrequent?. For example, a file open is checked but
> >> NOT each of the IO operations.
>
All I can offer at this point is that the impact is non-zero. A lot
depends on the nature of your application. If you are just opening a
file once, spending lots of time operating on it and then closing it,
then the impact of a FilePermission check is negligable. If, however,
you are opening and then closing (and discarding references to) many,
many FileInputStream/FileOutputStream objects, then you will get a
bigger hit. When Eclipse does it's various operations, does it retain
the streams pointing to the various files? It is considered good
behavior to close() streams when temporarily done with them, but in
regards to minimizing security checks an optimization may be to cache
the stream objects. Unfortunately, that may hit you harder in terms of
memory and object graph load.
We will have to eventually try some benchmarks of running eclipse with
and without a security manager. It does not make sense to just write
code snippets and try them, though, unless they replicate operations in
eclipse.
> The platform could run without a security manager enabled and this hit
> should go away. However, 'doPrivileged()' sections of code may still
> have an impact, depending on how well designed they are.
>
> >> Again, is it measurable?
>
Everything is measurable, but not until we have something to measure. :-)
|
|
| |
| Re: security concerns [message #26973 is a reply to message #26225] |
Fri, 20 June 2003 11:18 |
Eclipse User |
|
|
|
Originally posted by: d3l3t3-heavy-n0sp4m.ungoverned.org
Running Oscar significantly decreases start-up performance, that is for
sure...after that, it definitely depends on what the application is doing.
-> richard
Keith Kimball wrote:
> Mel we're on the same page regarding performance - measure prior to
> optimization. I wanted to point out that the natural assumption that
> adding security will be expensive could easily be wrong due to the fact
> that the opertions checked are infrequent.
>
> Regaring the question of in the presence of security, OSGI's library
> selection might effect which bundles run and which fail, you correctly
> point out that this is unlikely as if there are multiple versions of a
> library, they're mostly signed by the same entity. Thanks.
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:40:34 GMT 2024
Powered by FUDForum. Page generated in 0.03657 seconds |
] 
Search
Help
Register
Login
Home
