9:50 a.m.
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(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>,
"teiid-designer-dev" <teiid-designer-dev(a)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/#enti... 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(a)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(a)redhat.com