Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <CAJRvFdrLNeemMygSn3e+CkmzCpYOUk1X_0LLmsq3xr9g0zU+SQ@mail.gmail.com>
References: <CAL5zq9ZFqLd-_cWNLuL-_eyC9rEPbdkzjUb2tnFTdpLtLKyxfQ@mail.gmail.com>
 <CAL5zq9Y=zmPJ2aaYwxAQpP-ybY8i62cEJCMO=CKbvjH-UNbVpw@mail.gmail.com>
 <57B1F73F.4070900@gmail.com> <CAPx=JkZNwwEwzB1-NdcyFnjHaNVc-8z_w3c0Jn8GMK8H9y+OnQ@mail.gmail.com>
 <CAJRvFdrLNeemMygSn3e+CkmzCpYOUk1X_0LLmsq3xr9g0zU+SQ@mail.gmail.com>
From: Mike Drob <mdrob@mdrob.com>
Date: Mon, 15 Aug 2016 21:42:25 -0500
Message-ID: <CAJRvFdpfwKFO4_hs7WTrsSghpB8yPW_a77FEkuDFpVCN-uWWUA@mail.gmail.com>
Subject: Re: Custom Java SecurityManager permissions
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=001a114a6ece8ea2a8053a274cc6
archived-at: Tue, 16 Aug 2016 02:42:31 -0000

--001a114a6ece8ea2a8053a274cc6
Content-Type: text/plain; charset=UTF-8

Oops, hit send too soon. I thought you were asking about the security
policy that we used to ship with.

All things considered, I'd probably axe these too, though.

On Mon, Aug 15, 2016 at 9:41 PM, Mike Drob <mdrob@mdrob.com> wrote:

> +1
>
> I do not believe the initial implementation was very well tested in terms
> of security. IIRC we kept adding permissions until CI ran without errors on
> a very old version, so it is not guaranteed to run with modern versions of
> Accumulo, given that we evolve our usage regularly.
>
> On Mon, Aug 15, 2016 at 8:13 PM, Dylan Hutchison <
> dhutchis@cs.washington.edu> wrote:
>
>> Maybe related to ACCUMULO-1188
>> <https://issues.apache.org/jira/browse/ACCUMULO-1188>?
>>
>> On Mon, Aug 15, 2016 at 10:09 AM, Josh Elser <josh.elser@gmail.com>
>> wrote:
>>
>> > +1 from me.
>> >
>> > IIRC, they used to be something to try to guard against user JARs
>> > (containing iterators) doing something malicious, but obviously they
>> > haven't been kept up given the lack of documentation. I am not sure what
>> > all is possible to say whether or not it's a completely security
>> solution
>> > too.
>> >
>> > I think without context on what they do, how they work, etc, they can be
>> > removed.
>> >
>> >
>> > Christopher wrote:
>> >
>> >> Bump. Anybody have any thoughts on these? I'm inclined to rip out the
>> >> custom permissions here. I don't think they're actually adding any
>> >> security, and we're not documenting them in any overall security
>> model. As
>> >> is, they look like remnants of an early, incomplete attempt to apply
>> the
>> >> Java security system to our code, but they don't look like they are
>> >> offering anything in the current implementation to actually improve the
>> >> security.
>> >>
>> >> On Thu, Aug 11, 2016 at 9:46 PM Christopher<ctubbsii@apache.org>
>> wrote:
>> >>
>> >> I found 7 references in our code (master branch, probably same in
>> others)
>> >>> to the java SecurityManager.checkPermissions, each with custom
>> >>> permissions
>> >>> we've created (3 in core, 1 in fate, 3 in server-base).
>> >>>
>> >>> There is no documentation for these, and I don't really know what
>> these
>> >>> are actually trying to protect against.
>> >>>
>> >>> Do these custom permissions have any actual purpose? What value are
>> these
>> >>> adding?
>> >>>
>> >>> Do we have an overall security model which we can check these
>> >>> implementations against? Or to identify where we are missing checks
>> which
>> >>> should be there? Do we really need to create custom permissions, vs.
>> some
>> >>> standardized ones?
>> >>>
>> >>>
>> >>>
>> >>
>>
>
>

--001a114a6ece8ea2a8053a274cc6--