[teiid-designer-dev] [teiid-dev] Teiid/Teiid Designer Security

[Steven Hawkins]

>What is the current default - update-able nor not?

Should be updatable.

> Agreed.  If data role checking is on by default in Teiid, some global 
state in the VDB should indicate whether or not it is "participating" in 
data role usage.  Perhaps that global state is the presence of at least 
one role.  Perhaps it's a discrete setting.  The challenge with only 
checking roles if the VDB has them is that a user can assume the system 
is locked down because role checking is on but a VDB with no roles 
defined will be wide open.

You may be getting at something like an additional server setting "don't activate VDBs without roles".  The problem is that you really can't protect VDB designers from themselves after a certain point.  Just because a VDB has roles doesn't mean there isn't a default role that gives access to everything to everyone.  I would be in favor of just enforcing roles if they are present.  That also helps prevent more porting efforts with legacy VDBs if the default of the server is changed to check roles.  

> Visibility is more than security.  It's encapsulation.  I don't think 
users should use roles for that purpose - if that's what you're suggesting.

No I'm suggesting that visibility only applies to whether a table/model shows up in the system tables and has nothing to do with whether it can be accessed.  To restrict accessibility, then roles would be used.  This keeps the features distinct, but diminishes the visibility feature as encapsulation.  It seems like the overlap of these features is where most of the security confusion came from.  It seems that some assumed visible implied permissions.

I got tired of typing the last email, but would add that we could also consider SYS/pg_catalog as allow by default (instead of deny by default).  Then system procedures would check their own authorizations against what is being targeted, e.g. refreshMatView may require an update permisison against the mat view.  This would side step the question of whether the designer role permission editor should add controls for SYS/pg_catalog (TEIIDDES-568).    

----- Original Message -----
From: "Ken Johnson" <kejohnso at redhat.com>
To: "Steven Hawkins" <shawkins at redhat.com>
Cc: "teiid-dev" <teiid-dev at lists.jboss.org>, "teiid-designer-dev" <teiid-designer-dev at lists.jboss.org>
Sent: Monday, August 23, 2010 9:03:39 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Teiid/Teiid Designer Security

  On 08/21/2010 09:48 AM, Steven Hawkins wrote:
> Hell all,
>
> There is still a lot of confusion about security floating around.  After another office conversation on Friday, it would be best to have an open discussion.
>
> First some perspective.  MetaMatrix documentation described the securitizing process in layers (an expanded version of this will be added to the Teiid docs):
>
> 1. Be selective about what metadata is imported - only modeled items can be accessed.  Most if not all customers do this.
> 2. Change the physical metadata - e.g. mark a table as non-updatable - this is enforced regardless.  Some customers would do this.
What is the current default - update-able nor not?

> 3. Mark models as non-visible if users should not have access to them.  This could be set at design time or on the vdb. Advanced customers would do this.
Perhaps moderately advanced.  This is presented as best practice in 
basic discussions with users as both a security concern and a method to 
encourage encapsulation/loose-coupling.

> 4. Apply data roles at deploy-time to visible models.  With roles/entitlement checking turned on a server is "locked down", since we are deny by default.  Roles must be created for every VDB to provide any access.  A few customers would do this.
>
> To clarify how permissions are applied, please see the MetaMatrix documentation or http://docs.jboss.org/teiid/7.1.0.Final/reference/en-US/html_single/#entitlements for an updated explanation.  In short, permissions are applicable to every visible resource and only checked against what is accessed by the top level of the user query.  If visible virtual model B uses visible virtual model A which in turn accesses non-visible physical Z, then both A and B both should have roles/permissions applied because they are visible - B does not use the permissions of A.  Z does not need roles/permissions because it cannot be targeted by a user query regardless.
>
> It has been asserted there is an inherent security flaw with this approach.  That is simply not true.  Since we are deny-by-default, adding visible models (such as B) to a VDB is NOT "insecure" until the Designer user (or deployer in MetaMatrix) adds permissions to the applicable data roles.  Even then the notion of insecure would be based around the idea that permissions have been added inconsistently - for example, a particular column value from Z is readable in A, but not B.  As often as not this could be described as a feature.  This "application level" style of security makes it easy to present transformed values that would be otherwise be inaccessible with granular permissions.
>
> I became aware the other day that we are changing the default visibility on physical models.  Just to make

IMO, phys models should remain visible by default.  Making invisible 
will make initial development/debugging that much more onerous.

> sure we understand that change better, please consider that having the default of physical models as non-visible only makes usage of VDBs without data roles (the majority use case) harder.  It does not make vdbs with data roles more secure.  Since we are deny by default, someone still has to take an explicit action to make a new model accessible when using roles.  There is also an issue that any virtual update procedure is not a perfect substitute for a performing an update on a physical table.  Virtual update procedures support insert into with a queryexpression 1 row at a time and do not allow referencing columns of view in either values or criteria.  Forcing the use of virtual layers is not the right approach, it is merely a recommendation based upon the ease of use of the design-time visibility setting.

> With that said there have been a couple of issues raised relevant to security:
>
> TEIID-1220 - came about because of discussions with Paul where it was clear that breaking with legacy will help usability.  Specifically having data role checking turned on requires every VDB to have roles, since this is now a design time and not a deploy time operation, it is especially onerous to go back and add roles as an afterthought to existing VDBs.  The simple fix is to turn data role checking on by default and to only check roles if a vdb has them.  This will be targeted to 7.1.1. An additional feature would be the ability to turn off role checking on a VDB through a managed property.

Agreed.  If data role checking is on by default in Teiid, some global 
state in the VDB should indicate whether or not it is "participating" in 
data role usage.  Perhaps that global state is the presence of at least 
one role.  Perhaps it's a discrete setting.  The challenge with only 
checking roles if the VDB has them is that a user can assume the system 
is locked down because role checking is on but a VDB with no roles 
defined will be wide open.


> TEIIDDES-568 - SYS and pg_catalog schemas are not yet covered by the data-role editor.
>
> TEIIDDES-577 - should non-visible models not be shown in the data-role editor?

I think non-visible models should show up in data-role editor but should 
be identified as non-visible (grayed out or something).  If a user is 
applying data roles to a model and then later makes a decision to make 
the model non-visible, it may be confusing for it to no longer display 
in the editor.  Also, would roles/permissions be preserved if the 
modeler toggles visibility?


> In these latter cases there are a couple of alternative approaches that may help clarify some of the security confusion.  The first observation is that the visibility mechanism is no longer easy to differentiate since both visibility and data roles are set at design time.  A possible simplification is to not use the coarse grained notion of visibility for data access restrictions.  Instead if a user wants to make a model (or any resource non-visible) that would be the same as creating a data role ("default") that does not have permissions for model.  That role would need a mapping or a boolean attribute to denote that any authenticated user has the role.

Visibility is more than security.  It's encapsulation.  I don't think 
users should use roles for that purpose - if that's what you're suggesting.


> Visibility checking is applied differently than roles - visibility also limited what is returned through the system tables and is also considered at resolving time (a non-visible table reference must be fully qualified).  I can find no precedent for roles having a similar effect.  That is all entries will be visible in metadata and resolvable against partial names and "SELECT *".  There are other examples of being able to mark a table as hidden, which means that it will not show up in the system metadata but is otherwise accessible.  If we do apply visibility likewise, then the visibility role concepts are distinct.

> Steve
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev


-- 
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson at redhat.com