security label support, part.2
in [PgSql]
|
From: Robert Haas on 22 Jul 2010 11:54 2010/7/14 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: > The attached patch is a part of efforts to support security label > on database objects. This is similar to what I had in mind as a design for this feature, but I have some gripes: 1. I am inclined to suggest the syntax SECURITY LABEL ON ... IS ..., following COMMENT ON (it's also somewhat similar to the GRANT syntax). While the hook in ExecCheckRTPerms() will only allow meaningful permissions checks on the use of relations, there will presumably be ongoing demand to add additional hooks to cover other types of objects, and I'd rather add label support all at once rather than bit-by-bit. I also think that the SECURITY LABEL syntax is more future-proof; we don't need to worry about conflicts in other parts of the grammar. 2. Similarly, the design of the hook in secabel.h is way too short-sighted and won't scale to any other object type. We don't need or want one hook per object type here. Use an ObjectAddress. 3. I am firmly of the view that we want to allow multiple security providers. I think the way this should work here is that we should keep a list somewhere of security providers known to the system, which loadable modules should add themselves to. Each such security provider should be represented by a struct containing, at least, a name and a function that gets called on relabel. The labels should be stored in the catalog. That way there is never any possibility of one security provider getting a label that was originally applied by some other security provider. If we were storing these labels in pg_class or pg_attribute or similar, the storage cost for this might be worth worrying about, but as this is a separate catalog, it's not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 22 Jul 2010 23:56 2010/7/22 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: >> Well, I like SECURITY LABEL better because it's more clear about what >> kind of label we're talking about, but if there's consensus on some >> other option it's OK with me. �Actually, we need to work the security >> provider name in there too, I think, so perhaps SECURITY LABEL FOR >> provider ON object IS labeltext. �I realize it's slightly odd >> grammatically, but it's no worse than the COMMENT syntax. >> > The "FOR <provider>" clause should be optional. I expect most use > cases installs only one security provider, rather than multiple. > > If no explicit <provider> is specified, all the security providers > check the given security label. If two or more providers are here, > of course, either of them will raise an error, because they have > different label formats. It is right. Hmm. How about if there's just one provider loaded, you can omit it, but if you fail to specify it and there's >1 loaded, we just throw an error saying you didn't specify whose label it is. >>> So, I expect we need two hooks on relabeling eventually. >>> (One for relation, one for other object classes) >> >> Please explain in more detail. >> > For relations, one SECURITY LABEL statement may relabel multiple tables > when it has child tables, if ONLY clause was not given. > So, we need to obtain oids to be relabeled using find_all_inheritors(), > and need to ask providers whether it allows, or not. > But, obviously, it is specific for relations. > > For other object class, the target object to be relabeled is identified > by <object> in SECURITY LABEL statement. It will be parsed by the upcoming > parse_object.c feature, then it solves the object name to ObjectAddress. > So, we can apply access controls after setting up the ObjectAddress with > common hooks for object classes except for relations, like: > > �void check_object_relabel(ObjectAddress object, const char *new_label); So just construct an ObjectAddress for each relation and call the check function once for each. >> I think it is 100% clear that row-level security will require >> completely separate infrastructure, and therefore I'm not even a tiny >> bit worried about this. �:-) >> > Hmm. Are you saying we may degrade the feature when we switch to the > completely separate infrastructure? Is it preferable?? Uh... no, not really. I'm saying that I don't think we're backing ourselves into a corner. What makes you think we are? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 23 Jul 2010 01:01 (2010/07/23 12:56), Robert Haas wrote: > 2010/7/22 KaiGai Kohei<kaigai(a)ak.jp.nec.com>: >>> Well, I like SECURITY LABEL better because it's more clear about what >>> kind of label we're talking about, but if there's consensus on some >>> other option it's OK with me. Actually, we need to work the security >>> provider name in there too, I think, so perhaps SECURITY LABEL FOR >>> provider ON object IS labeltext. I realize it's slightly odd >>> grammatically, but it's no worse than the COMMENT syntax. >>> >> The "FOR<provider>" clause should be optional. I expect most use >> cases installs only one security provider, rather than multiple. >> >> If no explicit<provider> is specified, all the security providers >> check the given security label. If two or more providers are here, >> of course, either of them will raise an error, because they have >> different label formats. It is right. > > Hmm. How about if there's just one provider loaded, you can omit it, > but if you fail to specify it and there's>1 loaded, we just throw an > error saying you didn't specify whose label it is. > Perhaps, we need to return the caller a state whether one provider checked the given label at least, or not. If invalid <provider> was specified so nobody checked it, nobody returns the caller a state of "checked", then it raises an error to notice invalid security provider. If valid <provider> was specified, only specified provider checks the given label, and returns the caller a state of "it was checked by xxxx". If it was omitted, all the providers try to check the given label, but it has mutually different format, so one of providers will raise an error at least. It means we have to specify the provider when two or more providers are loaded, but not necessary when just one provider. >>>> So, I expect we need two hooks on relabeling eventually. >>>> (One for relation, one for other object classes) >>> >>> Please explain in more detail. >>> >> For relations, one SECURITY LABEL statement may relabel multiple tables >> when it has child tables, if ONLY clause was not given. >> So, we need to obtain oids to be relabeled using find_all_inheritors(), >> and need to ask providers whether it allows, or not. >> But, obviously, it is specific for relations. >> >> For other object class, the target object to be relabeled is identified >> by<object> in SECURITY LABEL statement. It will be parsed by the upcoming >> parse_object.c feature, then it solves the object name to ObjectAddress. >> So, we can apply access controls after setting up the ObjectAddress with >> common hooks for object classes except for relations, like: >> >> void check_object_relabel(ObjectAddress object, const char *new_label); > > So just construct an ObjectAddress for each relation and call the > check function once for each. > OK, I'll revise it. >>> I think it is 100% clear that row-level security will require >>> completely separate infrastructure, and therefore I'm not even a tiny >>> bit worried about this. :-) >>> >> Hmm. Are you saying we may degrade the feature when we switch to the >> completely separate infrastructure? Is it preferable?? > > Uh... no, not really. I'm saying that I don't think we're backing > ourselves into a corner. What makes you think we are? > Sorry, meaning of the last question was unclear for me.... Is it a idiom? Thanks, -- KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 23 Jul 2010 08:32 * Robert Haas (robertmhaas(a)gmail.com) wrote: > I don't understand why we wouldn't be able to support multiple > providers for row-level security. Why do you think that's a problem? My guess would be that he's concerned about only having space in the tuple header for 1 label. I see two answers- only allow 1 provider for a given relation (doesn't strike me as a horrible limitation), or handle labels as extra columns where you could have more than one. Thanks, Stephen
From: Robert Haas on 23 Jul 2010 08:47 On Fri, Jul 23, 2010 at 8:32 AM, Stephen Frost <sfrost(a)snowman.net> wrote: > * Robert Haas (robertmhaas(a)gmail.com) wrote: >> I don't understand why we wouldn't be able to support multiple >> providers for row-level security. �Why do you think that's a problem? > > My guess would be that he's concerned about only having space in the > tuple header for 1 label. �I see two answers- only allow 1 provider for > a given relation (doesn't strike me as a horrible limitation), or handle > labels as extra columns where you could have more than one. I think we've been pretty clear in previous discussions that any row-level security implementation should be a general one, and SE-Linux or whatever can integrate with that to do what it needs to do. So I'm pretty sure we'll be using regular columns rather than cramming anything into the tuple header. There are pretty substantial performance benefits to such an implementation, as well. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: [RRR] CommitFest 2010-07 week one progress report Next: Copy path in Dynamic programming |