Return-Path: 
 <dev-return-5156-apmail-karaf-dev-archive=karaf.apache.org@karaf.apache.org>
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 2D93BD5EF
	for <apmail-karaf-dev-archive@minotaur.apache.org>;
 Tue, 30 Oct 2012 11:25:45 +0000 (UTC)
Received: (qmail 55537 invoked by uid 500); 30 Oct 2012 11:25:45 -0000
Delivered-To: apmail-karaf-dev-archive@karaf.apache.org
Received: (qmail 55513 invoked by uid 500); 30 Oct 2012 11:25:45 -0000
Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@karaf.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@karaf.apache.org>
List-Post: <mailto:dev@karaf.apache.org>
List-Id: <dev.karaf.apache.org>
Reply-To: dev@karaf.apache.org
Delivered-To: mailing list dev@karaf.apache.org
Received: (qmail 55480 invoked by uid 99); 30 Oct 2012 11:25:43 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2012 11:25:43 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [217.70.183.196] (HELO relay4-d.mail.gandi.net)
 (217.70.183.196)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2012 11:25:36 +0000
X-Originating-IP: 217.70.178.131
Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 9C56C1720B2
	for <dev@karaf.apache.org>; Tue, 30 Oct 2012 12:25:15 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter11-d.gandi.net (mfilter11-d.gandi.net [10.0.15.180]) (amavisd-new,
 port 10024)
	with ESMTP id UEqwWQt8J1zm for <dev@karaf.apache.org>;
	Tue, 30 Oct 2012 12:25:14 +0100 (CET)
X-Originating-IP: 82.238.224.4
Received: from [192.168.134.15] (bre91-1-82-238-224-4.fbx.proxad.net
 [82.238.224.4])
	(Authenticated sender: jb@nanthrax.net)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 25CCB1720D9
	for <dev@karaf.apache.org>; Tue, 30 Oct 2012 12:25:14 +0100 (CET)
Message-ID: <508FB919.8020307@nanthrax.net>
Date: Tue, 30 Oct 2012 12:25:13 +0100
From: =?ISO-8859-1?Q?Jean-Baptiste_Onofr=E9?= <jb@nanthrax.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: dev@karaf.apache.org
Subject: Re: Securing shell commands
References: 
 <CAEQV+EFjAwDLzV-9VZTGNFgjuKxr=1g-3dHZ=w6g_8uegj1=KA@mail.gmail.com>
In-Reply-To: 
 <CAEQV+EFjAwDLzV-9VZTGNFgjuKxr=1g-3dHZ=w6g_8uegj1=KA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

Thanks for the update Guillaume and great job !

I gonna experiment (in combination with sub-shell) and extend to JMX,=20
but it looks very good.

Thanks again,
Regards
JB

On 10/30/2012 12:20 PM, Guillaume Nodet wrote:
> I've worked last week on a solution for KARAF-979, i.e. providing a way=
 to
> secure shell commands.
> What I came up with is the following.
>
> A new simple authentication service, exposed as an OSGi service with th=
e
> following interface
>
> public interface AuthorizationService {
>
>      void checkPermission(Subject subject, String permission);
>
>      boolean isPermitted(Subject subject, String permission);
>
> }
>
>
> This service would be used transparently by karaf commands by modifying=
 the
> BlueprintCommand class and calling checkPermission with the current Sub=
ject
> and a permission which is
>     "command:" + [scope] + ":" + [command]
>
> Permissions can be set through ConfigAdmin using a single property whic=
h
> contains an xml which looks like:
>      <entries>
>         <entry permission=3D"[xxx]" roles=3D"[xxx]" type=3D"add|set|mod=
ify" />
>         [ more entries ]
>      </entries>
>
> The matching is done by checking the permission given in the call to th=
e
> AuthorizationService with the entries in the configuration.  Matching
> entries are used to compute the list of authorized roles and those role=
s
> are checked against the roles of the authenticated Subject.
> This mechanism is the same we had in ServiceMix 3.x.
>
> This allows to define permissions for a subshell or a single command.  =
It
> does not provide a very easy way to split read operations from write
> operations and this would have to be done in an example configuration m=
aybe
> to ease the user task.
> That said, the mechanism is easily extensible and we can later add
> permissions for JMX access or any other part of Karaf that would benefi=
t
> from that.
>
> Thoughts welcomed, as usual.
>
>
>

--=20
Jean-Baptiste Onofr=E9
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com