From dev-return-6279-apmail-karaf-dev-archive=karaf.apache.org@karaf.apache.org Fri Aug 23 11:01:23 2013 Return-Path: X-Original-To: apmail-karaf-dev-archive@minotaur.apache.org Delivered-To: apmail-karaf-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8EDD310C92 for ; Fri, 23 Aug 2013 11:01:23 +0000 (UTC) Received: (qmail 19017 invoked by uid 500); 23 Aug 2013 11:01:23 -0000 Delivered-To: apmail-karaf-dev-archive@karaf.apache.org Received: (qmail 18883 invoked by uid 500); 23 Aug 2013 11:01:22 -0000 Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@karaf.apache.org Delivered-To: mailing list dev@karaf.apache.org Received: (qmail 18873 invoked by uid 99); 23 Aug 2013 11:01:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Aug 2013 11:01:22 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of david.bosschaert@gmail.com designates 209.85.212.182 as permitted sender) Received: from [209.85.212.182] (HELO mail-wi0-f182.google.com) (209.85.212.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Aug 2013 11:01:17 +0000 Received: by mail-wi0-f182.google.com with SMTP id hi8so410229wib.15 for ; Fri, 23 Aug 2013 04:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=4Cx0Qp0HnOkIpTgzb5vF7sLVqgMVeYmb5xIbD9vihKs=; b=BX7zusRaToOScUsR6iLKUyhjdAZ6ViqKgQTMlCF0OS41biarK4z26c+LxjlOR2xs7f tZTqg0Mx0/+cR2aAemncJB4mEpPHtZ+qYyPo5LL4UlRw07zyxl6JZfwxqpDkqwU312Zz uwiLTHFLOsEN6HB5urqGunS0cBucR7WrKW20XtlfFChlOV2l/lcyJeaoVGb1TBg+6Apo dsYEfL0k9+lzbWAD8Ue3tFitp7+f8qSfyT0XG1DMicKnWmcOSUiGEV/BNgUWH305cd+L CSjW6PAHthIcv4bCedkbglVVTUu7vNU939mTtLGBQuOziwEC69IM4PtGwuIWR4lTBkxB Ed3Q== X-Received: by 10.180.72.134 with SMTP id d6mr1756881wiv.8.1377255656485; Fri, 23 Aug 2013 04:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.28.73 with HTTP; Fri, 23 Aug 2013 04:00:36 -0700 (PDT) In-Reply-To: <52173CC6.9000001@nanthrax.net> References: <520D3728.4060308@die-schneider.net> <520D38D5.6000306@nanthrax.net> <5211E58C.6060200@die-schneider.net> <52168D38.9010704@die-schneider.net> <52173CC6.9000001@nanthrax.net> From: David Bosschaert Date: Fri, 23 Aug 2013 12:00:36 +0100 Message-ID: Subject: Re: Some thoughts around adding security for Karaf Shell Commands To: dev@karaf.apache.org Content-Type: multipart/alternative; boundary=f46d043439082b79b604e49b5212 X-Virus-Checked: Checked by ClamAV on apache.org --f46d043439082b79b604e49b5212 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That may be true for the Karaf MBeans but there are also other MBeans in the system. For example ones provided by the JVM. As an example take the MBean with the following object name: connector:name=3Drmi It is registered by the JVM and not through OSGi services and has a few operations (start(), stop()). By purely having the ACLs go through the service registry model you would not be able to prevent anyone from calling stop() on that mbean... It's just an example. Another example would be when an OSGi bundle registers MBeans directly (not through the WhiteBoard pattern). With the approach I suggest in KARAF-2435 you can secure any JMX operation, regardless of whether it's implemented as an OSGi service or not... Cheers, David On 23 August 2013 11:43, Jean-Baptiste Onofr=E9 wrote: > Hi guys, > > @David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean > registration. Aries JMX looks up for MBeans exposed as OSGi services. So = I > think we can leverage it. > > WDYT ? > > Regards > JB > > > On 08/23/2013 10:41 AM, David Bosschaert wrote: > >> Hi Christian, >> >> On 22 August 2013 23:14, Christian Schneider ** >> wrote: >> >> Sounds great. I have not yet looked into it in detail but the concept >>> sounds decent. >>> >>> One thing you should keep in mind is to make the authorization >>> exchangeable. For example at Talend we provide an xacml based pdp. So i= t >>> would be great to have a hook wehere we can plug this in to >>> do the auth decisions. Personally I am not a fan of xacml but this show= s >>> that different organizations would probably like to treat this >>> differently. >>> >>> >> What I did provides the authorization roles completely through >> ConfigAdmin. >> Which is pluggable in a number of ways: in Karaf we use the Felix Config >> admin which allows the registration of additional configuration provider= s. >> You can also replace the Config Admin Service itself to provide the info >> from another place... >> I guess we can always add more pluggability if that's needed. >> >> >> The way round your aproach sounds much more maintainable than xacml. So >>> it >>> might even be interesting to attach a pdp to your authorization impl :-= ) >>> >>> >> :) >> >> >> I have one other idea. How about doing the authorization for jmx and >>> commands only on the service level? At least in karaf 3 both use the sa= me >>> services so securing only the service instead of jmx and commands would >>> reduce the number of config settings needed. >>> >>> For example: >>> jmx: featureJMXBean.install(****feature) >>> >>> command: feature:install >>> >>> Both would be secured by simply securing the FeatureService. >>> >>> >> The problem with this is that there are still JMX APIs that aren't >> provided >> as OSGi services so that would leave a pretty big hole in the security i= f >> you ask me... >> For those cases where a single Service covers both JMX and the console w= e >> could use a single security point (that would be just a matter of >> configuring it that way), but I think that we still need the direct JMX >> security to make sure people can't do any damage through any of the >> non-OSGi-Service MBeans... >> >> >> One thing I am not sure about btw. is doing too much magic behind the >>> scenes. Like the config admin config you described that causes other >>> configs to be created on the fly. Perhaps we find a simpler model that >>> also >>> works. Currently I do not have a good idea how to handle it though. >>> >>> >> I agree. We need to find the balance between simplicity and ease-of-use. >> If >> you think of a simpler way without configuration generation that doesn't >> make the thing horrilbly hard to use for commands I'd love to hear it. >> >> Cheers, >> >> David >> >> > -- > Jean-Baptiste Onofr=E9 > jbonofre@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > --f46d043439082b79b604e49b5212--