Re: [HACKERS] rest of works for security providers in v9.1
2010/12/12 KaiGai Kohei kai...@ak.jp.nec.com: I'd like to see opinions what facilities should be developed to the current v9.1 development cycle. It seems to me that the next commit after the label-switcher-function patch ought to be a contrib module that implements a basic form of SE-Linux driven permissions checking. I'm pretty unexcited about continuing to add additional facilities that could be used by a hypothetical module without actually seeing that module, and I think that the label-switcher-function patch is the last piece of core infrastructure that is a hard requirement rather than nice to have. I'd rather have a complete feature with limited capabilities than half a feature with really awesome capabilities. I suspect that getting fine-grained DDL permissions into PostgreSQL 9.1 is not going to happen. There is a significant amount of complexity there and we are getting short on time. It took us three CommitFests to work through the plan we discussed at PGCon, and this isn't so much simpler that I expect to be able to do it in one. Of course, how you want to spend your time is up to you, but count me as a strong vote for postponing this work to 9.2, when there will be ample time to give it the care and attention it needs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
(2010/12/13 21:53), Robert Haas wrote: 2010/12/12 KaiGai Koheikai...@ak.jp.nec.com: I'd like to see opinions what facilities should be developed to the current v9.1 development cycle. It seems to me that the next commit after the label-switcher-function patch ought to be a contrib module that implements a basic form of SE-Linux driven permissions checking. I'm pretty unexcited about continuing to add additional facilities that could be used by a hypothetical module without actually seeing that module, and I think that the label-switcher-function patch is the last piece of core infrastructure that is a hard requirement rather than nice to have. I'd rather have a complete feature with limited capabilities than half a feature with really awesome capabilities. It is a good news for me also, because I didn't imagine SE-PostgreSQL module getting upstreamed, even if contrib module. OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL as a contrib module in the last commit fest. Probably, I need to provide its test cases and minimum documentations in addition to the code itself. Anything else? I suspect that getting fine-grained DDL permissions into PostgreSQL 9.1 is not going to happen. There is a significant amount of complexity there and we are getting short on time. It took us three CommitFests to work through the plan we discussed at PGCon, and this isn't so much simpler that I expect to be able to do it in one. Of course, how you want to spend your time is up to you, but count me as a strong vote for postponing this work to 9.2, when there will be ample time to give it the care and attention it needs. Yep, the label-switcher-function might be a good delimiter. I don't find out any disadvantages to postpone getting DDL permissions. I agree with these enhancements being pushed to v9.2 development. Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
On Mon, Dec 13, 2010 at 8:32 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote: (2010/12/13 21:53), Robert Haas wrote: 2010/12/12 KaiGai Koheikai...@ak.jp.nec.com: I'd like to see opinions what facilities should be developed to the current v9.1 development cycle. It seems to me that the next commit after the label-switcher-function patch ought to be a contrib module that implements a basic form of SE-Linux driven permissions checking. I'm pretty unexcited about continuing to add additional facilities that could be used by a hypothetical module without actually seeing that module, and I think that the label-switcher-function patch is the last piece of core infrastructure that is a hard requirement rather than nice to have. I'd rather have a complete feature with limited capabilities than half a feature with really awesome capabilities. It is a good news for me also, because I didn't imagine SE-PostgreSQL module getting upstreamed, even if contrib module. OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL as a contrib module in the last commit fest. Probably, I need to provide its test cases and minimum documentations in addition to the code itself. Anything else? Extremely detailed instructions on how to test it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
(2010/12/14 1:03), Robert Haas wrote: On Mon, Dec 13, 2010 at 8:32 AM, KaiGai Koheikai...@kaigai.gr.jp wrote: (2010/12/13 21:53), Robert Haas wrote: 2010/12/12 KaiGai Koheikai...@ak.jp.nec.com: I'd like to see opinions what facilities should be developed to the current v9.1 development cycle. It seems to me that the next commit after the label-switcher-function patch ought to be a contrib module that implements a basic form of SE-Linux driven permissions checking. I'm pretty unexcited about continuing to add additional facilities that could be used by a hypothetical module without actually seeing that module, and I think that the label-switcher-function patch is the last piece of core infrastructure that is a hard requirement rather than nice to have. I'd rather have a complete feature with limited capabilities than half a feature with really awesome capabilities. It is a good news for me also, because I didn't imagine SE-PostgreSQL module getting upstreamed, even if contrib module. OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL as a contrib module in the last commit fest. Probably, I need to provide its test cases and minimum documentations in addition to the code itself. Anything else? Extremely detailed instructions on how to test it. Indeed, it will be necessary. Two more questions: How does the contrib module behave when we try to make all the contrib modules on the platform that doesn't provide libselinux? One idea is to add a few checks about selinux environment in the configure script. I counted number of lines of the sepgsql module that implement only currently supported hooks. It has 3.2KL of code not. How about scale of the patch to review? Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
2010/12/13 KaiGai Kohei kai...@ak.jp.nec.com: It is a good news for me also, because I didn't imagine SE-PostgreSQL module getting upstreamed, even if contrib module. OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL as a contrib module in the last commit fest. Probably, I need to provide its test cases and minimum documentations in addition to the code itself. Anything else? Extremely detailed instructions on how to test it. Indeed, it will be necessary. Two more questions: How does the contrib module behave when we try to make all the contrib modules on the platform that doesn't provide libselinux? One idea is to add a few checks about selinux environment in the configure script. That sounds about right. Presumably, the handling would be similar to what we already do for sslinfo, uuid-ossp, or xml2. I counted number of lines of the sepgsql module that implement only currently supported hooks. It has 3.2KL of code not. Uh, wow. That's rather surprising. I thought that it would be measured in hundreds of lines. Aren't the hooks that we implemented a pretty close match for what SE-Linux needs? What is all that code doing? How about scale of the patch to review? Are there some inessential portions that we could strip out for v1? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
(2010/12/14 9:32), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: It is a good news for me also, because I didn't imagine SE-PostgreSQL module getting upstreamed, even if contrib module. OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL as a contrib module in the last commit fest. Probably, I need to provide its test cases and minimum documentations in addition to the code itself. Anything else? Extremely detailed instructions on how to test it. Indeed, it will be necessary. Two more questions: How does the contrib module behave when we try to make all the contrib modules on the platform that doesn't provide libselinux? One idea is to add a few checks about selinux environment in the configure script. That sounds about right. Presumably, the handling would be similar to what we already do for sslinfo, uuid-ossp, or xml2. OK, I'll follow the manner. I counted number of lines of the sepgsql module that implement only currently supported hooks. It has 3.2KL of code not. Uh, wow. That's rather surprising. I thought that it would be measured in hundreds of lines. Aren't the hooks that we implemented a pretty close match for what SE-Linux needs? What is all that code doing? The hooks are deployed well suitable for SE-Linux needs. Because a certain amount of codes are necessary to communicate between kernel and application using right security labels, the fist meaningful stuff requires this size. See below, [kai...@saba sepgsql]$ wc -l * 337 dml.c 222 hooks.c 132 initdb.sepgsql.in 710 label.c 40 language.c 40 largeobject.c 28 Makefile 70 proc.c 141 relation.c 40 schema.c 740 selinux.c 311 sepgsql.h 465 uavc.c 3276 total The largest selinux.c is the routine to communicate between user-space and kernel-space using libselinux. The second largest label.c is the routine to validate security label and to assign initial security labels. The third largest uavc.c is a facility to cache access control decision recently used. The uavc.c might be stripped out for the first version. The dml.c is as a literal. The hooks.c is entrypoints of hooks. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
2010/12/13 KaiGai Kohei kai...@ak.jp.nec.com: I counted number of lines of the sepgsql module that implement only currently supported hooks. It has 3.2KL of code not. Uh, wow. That's rather surprising. I thought that it would be measured in hundreds of lines. Aren't the hooks that we implemented a pretty close match for what SE-Linux needs? What is all that code doing? The hooks are deployed well suitable for SE-Linux needs. Because a certain amount of codes are necessary to communicate between kernel and application using right security labels, the fist meaningful stuff requires this size. See below, [kai...@saba sepgsql]$ wc -l * 337 dml.c 222 hooks.c 132 initdb.sepgsql.in 710 label.c 40 language.c 40 largeobject.c 28 Makefile 70 proc.c 141 relation.c 40 schema.c 740 selinux.c 311 sepgsql.h 465 uavc.c 3276 total The largest selinux.c is the routine to communicate between user-space and kernel-space using libselinux. The second largest label.c is the routine to validate security label and to assign initial security labels. The third largest uavc.c is a facility to cache access control decision recently used. The uavc.c might be stripped out for the first version. The dml.c is as a literal. The hooks.c is entrypoints of hooks. Hmm. So when you say 3200 lines of code, you're not counting documentation, which you definitely need. I'd say post what you have and I'll look it over and give feedback. I am not too keen on stripping out the caching mechanism. I'm not sure that's going to do much to simplify the patch. but I'm pretty sure it will make it a lot less useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
(2010/12/14 10:41), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: I counted number of lines of the sepgsql module that implement only currently supported hooks. It has 3.2KL of code not. Uh, wow. That's rather surprising. I thought that it would be measured in hundreds of lines. Aren't the hooks that we implemented a pretty close match for what SE-Linux needs? What is all that code doing? The hooks are deployed well suitable for SE-Linux needs. Because a certain amount of codes are necessary to communicate between kernel and application using right security labels, the fist meaningful stuff requires this size. See below, [kai...@saba sepgsql]$ wc -l * 337 dml.c 222 hooks.c 132 initdb.sepgsql.in 710 label.c 40 language.c 40 largeobject.c 28 Makefile 70 proc.c 141 relation.c 40 schema.c 740 selinux.c 311 sepgsql.h 465 uavc.c 3276 total The largest selinux.c is the routine to communicate between user-space and kernel-space using libselinux. The second largest label.c is the routine to validate security label and to assign initial security labels. The third largest uavc.c is a facility to cache access control decision recently used. The uavc.c might be stripped out for the first version. The dml.c is as a literal. The hooks.c is entrypoints of hooks. Hmm. So when you say 3200 lines of code, you're not counting documentation, which you definitely need. Yes, I'll need to add documentation and test cases from now, in addition to the code itself. I'd say post what you have and I'll look it over and give feedback. I am not too keen on stripping out the caching mechanism. I'm not sure that's going to do much to simplify the patch. but I'm pretty sure it will make it a lot less useful. The starter version is not intended to use in production system, so I'm optimistic even if caching mechanism is stripped out at first. I believe raw-query to SE-Linux can be easily replaced by the cached- query in the future. (In fact, I switched it before.) Although the scale is not so large, implementations of post creation hooks for language and largeobject can be stripped out, because we don't have any hooks to apply access controls on these objects, so labels of these objects are nonsense right now. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
2010/12/13 KaiGai Kohei kai...@ak.jp.nec.com: The starter version is not intended to use in production system, Well, what's the point, then? I thought we had enough infrastructure in place at this point to build a simple system that, while it wouldn't meet every use case, would be useful to some people for limited purposes. If that's not the case, I'm disappointed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
(2010/12/14 12:10), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: The starter version is not intended to use in production system, Well, what's the point, then? I thought we had enough infrastructure in place at this point to build a simple system that, while it wouldn't meet every use case, would be useful to some people for limited purposes. If that's not the case, I'm disappointed. The point is performance is not first priority right now. I guess its performance does not become a major issue, because lack of some features (such as DDL, row-level) are more glaring than its performance. It is an independent topic whether it is useful for limited purpose, or not. For example, when existing permission checks disallow all the DDL commands from web-applications anyway, it will achieve an expected role. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
2010/12/13 KaiGai Kohei kai...@ak.jp.nec.com: (2010/12/14 12:10), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: The starter version is not intended to use in production system, Well, what's the point, then? I thought we had enough infrastructure in place at this point to build a simple system that, while it wouldn't meet every use case, would be useful to some people for limited purposes. If that's not the case, I'm disappointed. The point is performance is not first priority right now. I guess its performance does not become a major issue, because lack of some features (such as DDL, row-level) are more glaring than its performance. It is an independent topic whether it is useful for limited purpose, or not. For example, when existing permission checks disallow all the DDL commands from web-applications anyway, it will achieve an expected role. But you could also install a control into ProcessUtility_hook, right? Saying, for example, you must have we_trust_you_a_lot_t to do any DDL? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
(2010/12/14 12:53), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: (2010/12/14 12:10), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: The starter version is not intended to use in production system, Well, what's the point, then? I thought we had enough infrastructure in place at this point to build a simple system that, while it wouldn't meet every use case, would be useful to some people for limited purposes. If that's not the case, I'm disappointed. The point is performance is not first priority right now. I guess its performance does not become a major issue, because lack of some features (such as DDL, row-level) are more glaring than its performance. It is an independent topic whether it is useful for limited purpose, or not. For example, when existing permission checks disallow all the DDL commands from web-applications anyway, it will achieve an expected role. But you could also install a control into ProcessUtility_hook, right? Yes, it may be an option to get control DDL statement, although it is not fine-grained. Of course, we have a trade-off to the scale of patch. Saying, for example, you must have we_trust_you_a_lot_t to do any DDL? No. Right now, it does not check anything on DDL commands, so all the clients (independent from its security label) are allowed to run any DDL commands, as long as existing permission allows it. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
2010/12/13 KaiGai Kohei kai...@ak.jp.nec.com: (2010/12/14 12:53), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: (2010/12/14 12:10), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: The starter version is not intended to use in production system, Well, what's the point, then? I thought we had enough infrastructure in place at this point to build a simple system that, while it wouldn't meet every use case, would be useful to some people for limited purposes. If that's not the case, I'm disappointed. The point is performance is not first priority right now. I guess its performance does not become a major issue, because lack of some features (such as DDL, row-level) are more glaring than its performance. It is an independent topic whether it is useful for limited purpose, or not. For example, when existing permission checks disallow all the DDL commands from web-applications anyway, it will achieve an expected role. But you could also install a control into ProcessUtility_hook, right? Yes, it may be an option to get control DDL statement, although it is not fine-grained. Of course, we have a trade-off to the scale of patch. I think it's just as important to have a coherent feature set as to make the patch small. Post something, and then we'll discuss. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rest of works for security providers in v9.1
(2010/12/14 13:31), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: (2010/12/14 12:53), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: (2010/12/14 12:10), Robert Haas wrote: 2010/12/13 KaiGai Koheikai...@ak.jp.nec.com: The starter version is not intended to use in production system, Well, what's the point, then? I thought we had enough infrastructure in place at this point to build a simple system that, while it wouldn't meet every use case, would be useful to some people for limited purposes. If that's not the case, I'm disappointed. The point is performance is not first priority right now. I guess its performance does not become a major issue, because lack of some features (such as DDL, row-level) are more glaring than its performance. It is an independent topic whether it is useful for limited purpose, or not. For example, when existing permission checks disallow all the DDL commands from web-applications anyway, it will achieve an expected role. But you could also install a control into ProcessUtility_hook, right? Yes, it may be an option to get control DDL statement, although it is not fine-grained. Of course, we have a trade-off to the scale of patch. I think it's just as important to have a coherent feature set as to make the patch small. Post something, and then we'll discuss. OK, I'll submit a patch without ProcessUtility_hook at first. Then, let's have a discussion what kind of control is available or reasonable on DDL commands. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] rest of works for security providers in v9.1
I'd like to see opinions what facilities should be developed to the current v9.1 development cycle. We have integrated some of facilities to support a starter- version of SE-PostgreSQL. It allows to hook controls on DML permission checks and assign security labels of client and database obejcts either by-hand or automatically. On the other hand, hooks on DDL permission checks are still future works from now. I believe object_access_hook is applied on various kind of DDL permission checks, but we cannot complete to put these hooks at once, because of patch scale. So, I plan to integrate the following four facilities only in the last commit-fest of v9.1, although it still does not cover comprehensive DDL accesses . * Expand object_access_hook to deliver arguments Some of DDL hooks will need to deliver several arguments in addition to OID of the object being modified. For example, a flag to show whether this deletion is cascaded, or not. So, prototype of the object_access_hook needs to be revised. My idea is to add two arguments: an integer variable for number of arguments and an array variable for the additional information. Then, macros will wrap up invocation of this hook to keep the code simple. * Permission checks on object-prep-creation It was not well concluded in the previous discussion, whether two hooks are needed, or one. I think the idea to divide creation hooks into two phases by its role eventually enables to reduce the burden of code management. Now we have OAT_POST_CREATE hooks just after registration of dependency, basically. It is a simple enough basis, and quite natural places to assign new security labels. However, several cases shall be exceptions of the basis, if we try to check permissions also in the post-creation hooks, in addition to default labeling. For example, heap_create_with_catalog() is called from five places, but only two needs permission checks: DefineRelation() and OpenIntoRel(). A few cases are not obvious whether we need permission checks in this invocation, like a code path from make_new_heap(). It defines a new pg_class entry, but the external module cannot determine from the catalog whether is is invoked on the code path that needs permission checks, or not. So, I want OAT_CREATE hooks being just after existing permission checks for the purpose of access control, not default labeling. * Permission checks on object-deletion The existing code put permission checks of object deletion on command handlers like RemoveRelations(), then it invokes functions in dependency.c to drop the specified and dependent objects (if necessary). I think it is straight-forward to put object-deletion hooks next to the existing permission checks. But it is unavailable to check cascaded objects to be removed here. So, it seems to me findDependentObjects() should be exposed to external modules to inform what objects shall be dropped. Unlike old SE-PostgreSQL implementation, I don't consider it is a good idea to put hook within dependency.c, because we need to inform dependency.c whether this deletion is by-hand, or something internals (such as cleanups of temporary objects). * Permission checks on misc easy implementables Apart from the priority of development, it seems to me that we can hook controls at the following commands quite easy. It is an idea to put hooks that we can implement with little impact around the existing codes. - GRANT/REVOKE - COMMENT ON - SECURITY LABEL Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
