[
https://issues.apache.org/jira/browse/POOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Kleinschmidt updated POOL-352:
-------------------------------------
Description:
CallStackUtils determines at initialization time whether it is allowed to
create a security manager, then sticks that info into a static variable and
never checks it again, relying on this check to later try to create a
SecurityManager for a SecurityManagerCallStack. This is doubly wrong:
a) If the code is running in a privileged context at init time, it determines
that it can create a security manager, and then later naively assumes that
henceforth all code is privileged and also can create a security manager. Of
course this is not true, otherwise one would not need a security manager in the
first place! This info can never be kept in a static variable, it's extremely
context-dependent. So this leads to AccessControlException from invoking
newCallStack().
b) The permission to create a security manager must never be granted to any
code, unless that code has AllPermission in the first place, i.e. is already
fully privileged. This is because this permission allows circumventing the
security manager completely (simply create one that lets all checks pass).
Therefore even just checking whether you're allowed to create a secmgr is naive
- if a secmgr is installed at all you should assume that you're NOT privileged
enough to do this, simply because for sure some code that calls your code will
not be privileged enough.
was:
CallStackUtils determines at initialization time whether it is allowed to
create a security manager, then sticks that info into a static variable and
never checks it again, relying on this check to later try to create a
SecurityManager for a SecurityManagerCallStack. This is doubly wrong:
a) If the code is running in a privileged context at init time, it determines
that it can create a security manager, and then later naively assumes that
henceforth all code is privileged and also can create a security manager. Of
course this is not true, otherwise one would not need a security manager in the
first place! This info can never be kept in a static variable, it's extremely
context-dependent.
b) The permission to create a security manager must never be granted to any
code, unless that code has AllPermission in the first place, i.e. is already
fully privileged. This is because this permission allows circumventing the
security manager completely (simply create one that lets all checks pass).
Therefore even just checking whether you're allowed to create a secmgr is naive
- if a secmgr is installed at all you should assume that you're NOT privileged
enough to do this, simply because for sure some code that calls your code will
not be privileged enough.
> CallStackUtils mishandles security manager check
> ------------------------------------------------
>
> Key: POOL-352
> URL: https://issues.apache.org/jira/browse/POOL-352
> Project: Commons Pool
> Issue Type: Bug
> Reporter: Volker Kleinschmidt
> Priority: Major
>
> CallStackUtils determines at initialization time whether it is allowed to
> create a security manager, then sticks that info into a static variable and
> never checks it again, relying on this check to later try to create a
> SecurityManager for a SecurityManagerCallStack. This is doubly wrong:
> a) If the code is running in a privileged context at init time, it determines
> that it can create a security manager, and then later naively assumes that
> henceforth all code is privileged and also can create a security manager. Of
> course this is not true, otherwise one would not need a security manager in
> the first place! This info can never be kept in a static variable, it's
> extremely context-dependent. So this leads to AccessControlException from
> invoking newCallStack().
> b) The permission to create a security manager must never be granted to any
> code, unless that code has AllPermission in the first place, i.e. is already
> fully privileged. This is because this permission allows circumventing the
> security manager completely (simply create one that lets all checks pass).
> Therefore even just checking whether you're allowed to create a secmgr is
> naive - if a secmgr is installed at all you should assume that you're NOT
> privileged enough to do this, simply because for sure some code that calls
> your code will not be privileged enough.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
