Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Thu, 20 Oct 2016 09:18:58 +0000 (UTC)
From: "Karl Pauls (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12923290.1450624149000.37907.1476955138340@Atlassian.JIRA>
In-Reply-To: <JIRA.12923290.1450624149000@Atlassian.JIRA>
References: <JIRA.12923290.1450624149000@Atlassian.JIRA> <JIRA.12923290.1450624149172@arcas>
Subject: [jira] [Commented] (FELIX-5148) Framework Security unusable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 20 Oct 2016 09:19:00 -0000


    [ https://issues.apache.org/jira/browse/FELIX-5148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591307#comment-15591307 ] 

Karl Pauls commented on FELIX-5148:
-----------------------------------

It isn't ConfigAdmin that has to do the doPriv. The point is that the ManagedService interface doesn't mention any security requirements - hence, the implementations of ManagedService need to do security sensitive calls inside a doPriv to make sure ConfigAdmin isn't on the stack. 

In general, I don't think there is a way for the caller to pop itself from the security call stack. That is something only the callee can do (unless I'm missing something). Anyways, I'm not saying that the OSGI-INF/permissions.perm are wrong. The problem is that say require the log service implementation (and the ManagedService ones) to follow their interface contract and not require permissions from their caller (which in the real world is a hard to achieve requirement).

> Framework Security unusable
> ---------------------------
>
>                 Key: FELIX-5148
>                 URL: https://issues.apache.org/jira/browse/FELIX-5148
>             Project: Felix
>          Issue Type: Bug
>          Components: Configuration Admin, Framework Security
>    Affects Versions: framework.security-2.4.0, configadmin-1.8.0
>            Reporter: Oliver Lietz
>            Assignee: Karl Pauls
>         Attachments: FELIX-5148.site.patch, FELIX-5148.sling-launchpad-builder.patch
>
>
> While fixing an issue with Sling and RMI (SLING-5375) reported by an user I came across an issue (KARAF-3400) reported by [~achim_nierbeck] for Karaf related to framework security.
> There is also an issue with [Sling's own OSGi launcher Launchpad|https://svn.apache.org/viewvc/sling/trunk/launchpad/builder/] and framework security when using {{org.apache.felix.configadmin}} >= {{1.8.0}}.
> {{all.policy}}:
> {noformat}
> grant {
>    permission java.security.AllPermission;
> };
> {noformat}
> Adding {{org.apache.felix/org.apache.felix.framework.security/2.4.0}} to {{boot.txt}} and starting with arguments described on [Framework Security's page|http://felix.apache.org/documentation/subprojects/apache-felix-framework-security.html] (which looks broken) and [{{-Djava.security.manager}}|http://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc6.html] ([Building Secure OSGi Applications|http://de.slideshare.net/marrs/building-secure-osgi-applications]) throws a {{java.security.AccessControlException}}:
> {noformat}
> java -Djava.security.manager -Djava.security.policy="all.policy" -Dorg.osgi.framework.security="osgi" -jar org.apache.sling.launchpad-9-SNAPSHOT.jar
> {noformat}
> {noformat}
> [...]
> [...] *ERROR* [FelixStartLevel] ERROR: Error starting slinginstall:org.apache.felix.configadmin-1.8.0.jar (java.security.AccessControlException: access denied ("java.io.FilePermission" "/[...]/sling/config" "read"))
> java.security.AccessControlException: access denied ("java.io.FilePermission" "/[...]/sling/config" "read")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> 	at java.security.AccessController.checkPermission(AccessController.java:884)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> 	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> 	at java.io.File.isDirectory(File.java:844)
> 	at org.apache.felix.cm.file.FilePersistenceManager.<init>(FilePersistenceManager.java:342)
> 	at org.apache.felix.cm.impl.ConfigurationManager.start(ConfigurationManager.java:244)
> 	at org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1709)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:688)
> 	at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
> 	at org.apache.felix.framework.Felix.startBundle(Felix.java:2144)
> 	at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
> 	at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> 	at java.lang.Thread.run(Thread.java:745)
> [...]
> {noformat}
> I had to remove OSGi Subsystems support from {{boot.txt}} when using {{org.apache.felix.configadmin}} {{1.6}}:
> {noformat}
>     org.apache.felix/org.apache.felix.coordinator/1.0.0
>     org.eclipse.equinox/org.eclipse.equinox.region/1.2.101.v20150831-1342
>     org.apache.aries.subsystem/org.apache.aries.subsystem.api/2.0.6
>     org.apache.aries.subsystem/org.apache.aries.subsystem.core/2.0.6
> {noformat}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)