security label support, part.2
in [PgSql]
|
From: KaiGai Kohei on 23 Jul 2010 08:59 (2010/07/23 20:44), Robert Haas wrote: > 2010/7/23 KaiGai Kohei<kaigai(a)ak.jp.nec.com>: >>> 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. > > Return to the caller? This is an SQL command. You either get an > error, or you don't. > Ahh, I was talked about relationship between the core PG code and ESP module. It means the security hook returns a state which informs the core PG code whether one provider checked the given label, then the core PG code can decide whether it raise an actual error to users, or not. In other words, I'd like to suggest the security hook which returns a tag of ESP module, as follows: const char * check_object_relabel_hook(const ObjectAddress *object, const char *provider, const char *seclabel); The second argument reflects "FOR <provider>" clause. It informs ESP modules what provider is specified. If omitted, it will be NULL. Then, ESP module which checked the given security label must return its tag. Maybe, "selinux", if SE-PostgreSQL. Or, NULL will be returned if nobody checked it. If NULL or incorrect tag is returned, the core PG code can know the given seclabel is not checked/validated, then it will raise an error to users. Elsewhere, the validated label will be stored with the returned tag. It enables to recognize what label is validated by SELinux, and what label is not. >> 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. > > Yeah, but it won't be a very clear error, and what if you have, say, a > provider that allows arbitrary strings as labels? Since this is a > security feature, I think it's a pretty bad idea to allow the user to > do anything that might be ambiguous. > It is provider's job to validate the given security label. So, if we install such a security module which accept arbitrary strings as label, the core PG code also need to believe the ESP module. But the arbitrary label will be tagged with something other than "selinux", so it does not confuse other module, according to the above idea. >> It means we have to specify the provider when two or more providers are >> loaded, but not necessary when just one provider. > > But that should be fine. Loading multiple providers should, as you > say, be fairly rare. > >>>>> 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? > > 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? > I don't have any clear reason why we wouldn't be able to support multiple labels on user tuples, but it is intangible anxiety, because I have not implemented it as a working example yet. (So, I never think it is impossible.) Thanks, -- KaiGai Kohei <kaigai(a)kaigai.gr.jp> -- 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 23 Jul 2010 09:36 On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei <kaigai(a)kaigai.gr.jp> wrote: > (2010/07/23 20:44), Robert Haas wrote: >> >> 2010/7/23 KaiGai Kohei<kaigai(a)ak.jp.nec.com>: >>>> >>>> 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. >> >> Return to the caller? �This is an SQL command. �You either get an >> error, or you don't. >> > Ahh, I was talked about relationship between the core PG code and ESP > module. > It means the security hook returns a state which informs the core PG code > whether one provider checked the given label, then the core PG code can > decide whether it raise an actual error to users, or not. > > In other words, I'd like to suggest the security hook which returns a tag > of ESP module, as follows: > > �const char * > �check_object_relabel_hook(const ObjectAddress *object, > � � � � � � � � � � � � � �const char *provider, > � � � � � � � � � � � � � �const char *seclabel); I don't think that's a very good design. What I had in mind was a simple API for security providers to register themselves (including their names), and then the core code will only call the relevant security provider. I did try to explain this in point #3 of my original review. -- 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 23 Jul 2010 07:44 2010/7/23 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: >> 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. Return to the caller? This is an SQL command. You either get an error, or you don't. > 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. Yeah, but it won't be a very clear error, and what if you have, say, a provider that allows arbitrary strings as labels? Since this is a security feature, I think it's a pretty bad idea to allow the user to do anything that might be ambiguous. > It means we have to specify the provider when two or more providers are > loaded, but not necessary when just one provider. But that should be fine. Loading multiple providers should, as you say, be fairly rare. >>>> 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? 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? -- 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 26 Jul 2010 03:02 The attached patches are revised ones, as follows. * A new SECURITY LABEL statement replaced the previous ALTER TABLE statement with SECURITY LABEL TO option. It has the following syntax. SECURITY LABEL [ FOR <provider> ] ON <object class> <object name> IS '<label>'; E.g) SECURITY LABEL ON TABLE t1 IS 'system_u:object_r:sepgsql_table_t:s0'; * It supports multiple security providers to assign its security label on a database object. The pg_seclabel catalog was modified as follows: CATALOG(pg_seclabel,3037) BKI_WITHOUT_OIDS { Oid reloid; /* OID of table containing the object */ Oid objoid; /* OID of the object itself */ int4 subid; /* column number, or 0 if not used */ + text tag; /* identifier of external security provider */ text label; /* security label of the object */ } FormData_pg_seclabel; The new 'tag' field identifies which security provider manages this security label. For example, SE-PostgreSQL uses "selinux" for its identifier. * The security hook to check relabeling become to be registered using register_object_relabel_hook() which takes a tag of ESP module and a function pointer to the security hook. ExecSecLabelStmt() picks up an appropriate security hook, then it shall be invoked even if multiple modules are loaded. * Add _copySecLabelStmt() on nodes/copyfuncs.c and _equalSecLabelStmt() on nodes/equalfuncs.c, because I forgot to add them, although new parsenode (SecLabelStmt) was added. * Add descriptions about pg_seclabel catalog and SECURITY LABEL statement on the documentation. Thanks, (2010/07/23 22:36), Robert Haas wrote: > On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei<kaigai(a)kaigai.gr.jp> wrote: >> (2010/07/23 20:44), Robert Haas wrote: >>> >>> 2010/7/23 KaiGai Kohei<kaigai(a)ak.jp.nec.com>: >>>>> >>>>> 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. >>> >>> Return to the caller? This is an SQL command. You either get an >>> error, or you don't. >>> >> Ahh, I was talked about relationship between the core PG code and ESP >> module. >> It means the security hook returns a state which informs the core PG code >> whether one provider checked the given label, then the core PG code can >> decide whether it raise an actual error to users, or not. >> >> In other words, I'd like to suggest the security hook which returns a tag >> of ESP module, as follows: >> >> const char * >> check_object_relabel_hook(const ObjectAddress *object, >> const char *provider, >> const char *seclabel); > > I don't think that's a very good design. What I had in mind was a > simple API for security providers to register themselves (including > their names), and then the core code will only call the relevant > security provider. I did try to explain this in point #3 of my > original review. > -- KaiGai Kohei <kaigai(a)ak.jp.nec.com>
First
|
Prev
|
Pages: 1 2 Prev: [RRR] CommitFest 2010-07 week one progress report Next: Copy path in Dynamic programming |