Re: Finer grained security

[Swapnil Bawaskar <sb...@pivotal.io>]

Thanks for feedback! I have tried to incorporate this on our wiki:
https://cwiki.apache.org/confluence/display/GEODE/Finer+grained+security.
Comments welcome.

On Thu, Apr 27, 2017 at 1:33 PM John Blum <jb...@pivotal.io> wrote:

> +1 to Jake's comments, and is a fundamental property of Java's security
> internally.
>
> On Thu, Apr 27, 2017 at 1:09 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
>
> > Typical solution to the X service needs to create something it service Y
> > where user has permission to X but not to Y is to treat the actions on Y
> > performed by X to be trusted. Often I have seen this implemented such
> that
> > after asserting permission on "create" on X that X performs actions on Y
> as
> > a trusted principal, like a "SYSTEM" user. The other option is to give
> each
> > service a trusted account and elevate to "SERVICE-X" where Y would allow
> > "SERVICE-X" to perform some set of operations.
> >
> > See
> > https://docs.oracle.com/javase/7/docs/api/javax/
> > security/auth/Subject.html#doAs(javax.security.auth.
> > Subject,%20java.security.PrivilegedAction
> > )
> >
> > -Jake
> >
> >
> > On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz <ms...@pivotal.io>
> wrote:
> >
> > > We have seen users who need per-Region permission for Data read/write,
> so
> > > there is precedent there at least.
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> > >
> > > On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra <
> > pulkit.chandra@gmail.com>
> > > wrote:
> > >
> > > > For per instance permission, I would say look for the evidence. Do we
> > > have
> > > > evidence that customers want per instance permission? If not may be
> > > > implement minimally in the first cut and validate with customers if
> > they
> > > > want per instance model?
> > > >
> > > > About Lucene concern, It is in fact good to provide permission for
> per
> > > > logical operation that implementation is doing. This will align the
> > > > security permission with operations performed and provide better
> design
> > > of
> > > > a role. I would argue if you are able to perform 2 logically separate
> > > > operations with single permission is perhaps a smell that you might
> not
> > > > have enough permissions.
> > > >
> > > > my $0.02
> > > >
> > > > On Wed, 26 Apr 2017 at 16:54 Dan Smith <ds...@pivotal.io> wrote:
> > > >
> > > > > I agree that async event queues seem like a different case than wan
> > or
> > > > > disk. In that case you are not using anything that creating a
> region
> > > > > doesn't do.
> > > > >
> > > > > Shouldn't creating a region be DATA:MANAGE:DISK? Requiring DATA
> > > > privileges
> > > > > for a region without disk and CLUSTER privileges for a region with
> > disk
> > > > > seems weird. Same issues with creating a region that uses WAN.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Wed, Apr 26, 2017 at 12:53 PM, Diane Rose Hardman <
> > > > dhardman@pivotal.io>
> > > > > wrote:
> > > > >
> > > > > > One more possible complication is that creating a Lucene index
> will
> > > > also
> > > > > > create an AsyncEventQueue. Today the required permission to
> create
> > > the
> > > > > AEQ
> > > > > > is DATA:MANAGE which coincidentally nicely matches the permission
> > > > > required
> > > > > > to create an OQL index.
> > > > > > Pulling out the AEQ as a separate resource will affect Lucene
> index
> > > > > > creation. FYI.
> > > > > >
> > > > > > On Tue, Apr 25, 2017 at 3:10 PM, Jinmei Liao <ji...@pivotal.io>
> > > > wrote:
> > > > > >
> > > > > > > DATA:*:RegionA would allow you to only operate that region but
> > not
> > > > all
> > > > > of
> > > > > > > them.
> > > > > > >
> > > > > > > if we want to control a specific wan, maybe we add a fourth
> > > > parameter:
> > > > > > > cluster:*:wan:wanName, same goes for Disk etc.
> > > > > > >
> > > > > > > On Tue, Apr 25, 2017 at 3:03 PM, Jacob Barrett <
> > > jbarrett@pivotal.io>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Think further, what about the team that ask that I be able to
> > > > mange a
> > > > > > > > region not all regions, or a wan not all wan. It may be time
> to
> > > > think
> > > > > > > about
> > > > > > > > a full per instance /
> > > > > > > > named resource based security model.
> > > > > > > >
> > > > > > > > On Tue, Apr 25, 2017 at 2:59 PM Jared Stewart <
> > > jstewart@pivotal.io
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > I think it would also be a good idea to move the current
> > > > operations
> > > > > > > > > permitted by CLUSTER:MANAGE ( stop server, alter runtime,
> > etc)
> > > to
> > > > > > > require
> > > > > > > > > the more specific CLUSTER:MANAGE:MEMBER in order to avoid
> > > > > ambiguity.
> > > > > > > > (This
> > > > > > > > > is not a breaking change since CLUSTER:MANAGE implies
> > > > > > > > > CLUSTER:MANAGE:MEMBER.)
> > > > > > > > >
> > > > > > > > > > On Apr 25, 2017, at 2:48 PM, Swapnil Bawaskar <
> > > > > > sbawaskar@pivotal.io>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > In our current security model, a user with DATA:MANAGE
> can
> > > > create
> > > > > > > > > regions,
> > > > > > > > > > create disk stores, WAN gateways etc. I think this is a
> > very
> > > > wide
> > > > > > > > scope,
> > > > > > > > > > because an administrator may want to give create region
> > > > privilege
> > > > > > to
> > > > > > > a
> > > > > > > > > > developer, but not necessarily give them the ability to
> > > create
> > > > > disk
> > > > > > > > > stores
> > > > > > > > > > or send the data in that region over WAN. I propose that
> we
> > > > > refine
> > > > > > > the
> > > > > > > > > > security model to make it finer grained.
> > > > > > > > > >
> > > > > > > > > > I propose that Disk, WAN and AsyncQueue be treated as
> > > resources
> > > > > in
> > > > > > > the
> > > > > > > > > > security framework. These resources will be controlled at
> > the
> > > > > > CLUSTER
> > > > > > > > > > level. As with any other resource, admins will be able to
> > > grant
> > > > > > READ,
> > > > > > > > > WRITE
> > > > > > > > > > and MANAGE permissions to these resources. In terms of
> > shiro,
> > > > > this
> > > > > > > will
> > > > > > > > > > take the form: CLUSTER:READ/WRITE/MANAGE:
> > DISK,WAN,ASYNCQUEUE.
> > > > > > > > > >
> > > > > > > > > > Here is how it will work out for each resource:
> > > > > > > > > > DISK
> > > > > > > > > > 1. CLUSTER:MANAGE:DISK - allows users to create/manage
> disk
> > > > > stores
> > > > > > > > > > 2. CLUSTER:WRITE:DISK - allows users to create regions
> that
> > > > > > > > > write/overflow
> > > > > > > > > > to disk stores
> > > > > > > > > > 3. CLUSTER:READ:DISK - should be covered by DATA:READ,
> does
> > > not
> > > > > > make
> > > > > > > > > sense
> > > > > > > > > > here
> > > > > > > > > >
> > > > > > > > > > WAN:
> > > > > > > > > > 1. CLUSTER:MANAGE:WAN - allows users to create gateway
> > > senders
> > > > > and
> > > > > > > > > receivers
> > > > > > > > > > 2. CLUSTER:WRITE:WAN - allows users to create regions
> that
> > > > write
> > > > > > data
> > > > > > > > to
> > > > > > > > > > gateway senders
> > > > > > > > > > 3. CLUSTER:READ:WAN - allows users to create regions that
> > > read
> > > > > data
> > > > > > > > from
> > > > > > > > > > gateway receivers
> > > > > > > > > >
> > > > > > > > > > We can add other things like functions here as well.
> > > > > > > > > >
> > > > > > > > > > Thoughts?
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers
> > > > > > >
> > > > > > > Jinmei
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>