Re: [HACKERS] SE-PostgreSQL/Lite Review
(2009/12/12 6:27), Robert Treat wrote: One point. I'd like to introduce a use case without row-level granularity. The page.24 in this slide: http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf shows SELinux performs as a logical wall between virtual domains in web-services. Unlike physical database separation, it also allows to share a part of files/tables from multiple virtual hosts, because of its flexibility. I got the impression that this is doable with current SEPostgres stuff, would be nice to see a little more detailed writeup on how to do it. Especially if it could be linked to the hosting providors page in the wiki. Sorry, I missed to reply your message. It needs to set up apache and selinux support module (mod_selinux.so) correctly. This wiki article introduce the way to set up per virtualhost separation using SELinux. http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus?wl=en#Per_virtual-host_separation Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL/Lite Review
KaiGai Kohei escribio': Stephen Frost wrote: Josh, * Joshua Brindle (met...@manicmethod.com) wrote: Stephen Frost wrote: I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. It isn't just a case of using #if and it magically working. You'd need a system to manage multiple labels on each object that can be addressed by different systems. So instead of having an object mapped only to system_u:object_r:mydb_t:s15 you'd also have to have it mapped to, eg., ^ for Smack. I'm not sure I see that being a problem.. We're going to have references in our object managers which make sense to us (eg: table OIDs) and then a way of mapping those to some label (or possibly a set of labels, as you describe). We might want to reconsider the catalog structure a bit if we want to support more than one at a time, but I don't see it as a huge problem to support more than one label existing for a given object. If we allow multiple security labels on a database object, we have to expand the structure of system catalog whenever a new security feature will come in. I think it against to the purpose of the framework. Even if we store them external relations to reference the object by OID, we have to provide multiple interface to import/export a security label for each enhanced securities. For example, it requires much complex patch to the pg_dump. My preference is all the enhanced securities shares a common facility to manage security label, a common statement support and a common backup/restore support. Thanks, I'm worried with the performance implications that have this patch on the core of the system. If you are aggregating more security layers, There is not a database degradation? I don't know how you attack these issues. Regards. -- - TIP 4: No hagas 'kill -9' a postmaster Ing. Marcos Lui's Orti'z Valmaseda PostgreSQL System DBA Centro de Tecnologi'as de Almacenamiento y Ana'lis de Datos (CENTALAD) Universidad de las Ciencias Informa'ticas(http://www.uci.cu) Linux User # 418229 http://www.postgresql-es.org http://www.postgresql.org http://www.planetpostgresql.org -- 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] SE-PostgreSQL/Lite Review
2009/12/12 KaiGai Kohei kai...@kaigai.gr.jp: I'd like to summary about the framework. I am not necessarily in agreement with many of the points listed in this email. * Functionalities The ACE framework hosts both of the default PG checks and upcoming enhanced securities. We can build a binary with multiple enhanced security features, but user can choose one from them at most due to the security label management. Just yesterday, Stephen Frost and I were discussing whether to stick a layer of interdirection into the proposed interface layer using function pointers. We agreed to defer that decision to a later date. If, however, we eventually decide to do that, it will clearly mean that multiple security frameworks are possible simultaneously and that they can be implemented as loadable modules. On the other hand, we might decide that that design does NOT make sense, in which case we might end up with something more like the code snippet you proposed below, although I'm not sure you have the details right. We have also not decided whether to support a single security label or multiple security labels per object. I tend to think that the case for multiple labels is pretty thin, but on the other hand it's not unmangeably difficult to do so. It could be coded up using an array representation, just as we now do for reloptions. Again, I want to defer this decision until later. Right now, I want to focus on seeing whether it is all possible for us to get community buy-in on just centralizing the existing checks, without making any commitment to what may come after that. So, it basically has the following structure: Value * ac_database_create([arguments ...]) { Value *retval = NULL; /* * The default PG checks here. It is never disabled. */ switch (ace_feature) { #ifdef HAVE_SELINUX case ACE_SELINUX_SUPPORT: if (sepgsql_is_enabled()) retval = sepgsql_database_create(...); break; #endif #ifdef HAVE_SMACK case ACE_SMACK_SUPPORT: if (smack_is_enabled()) retval = smack_database_create(...); break; #endif default: break; } return retval; } Again, if we decided on a function-pointer interface, it would be up to the loaded security module whether or not to still apply the default PG checks. We have made no decision on that one way or the other. * Namespace The framework is stored in the src/backend/security/ace. As a general rule, Each source file has this naming convension: src/backend/security/ace/object_class_ace.c Maybe. Generally I think if there's a common prefix it should go at the beginning of the filename, not the end, but I don't want to get into source code organization too much at this point. It's too early to make those decisions. Uncategolized hooks (such as cascaded-deletion called from dependency system) are stored in ace/sysobj_ace.c. It is an exception. The uncategorized hooks are one of the big design decisions we need to deal with. Let's put our energy into thinking about how to make a tight, clean interface there, rather than worrying about where we put the code. All the framework functions (except for static) have ace_ prefix to distinguish from any other internal routines. I'm not convinced. Probably there will be a prefix, but since I'm envisioning the first phase of this as strictly code cleanup, it doesn't seem right to give it a prefix that means access control *extensions*. The security providers (SELinux, upcoming SMACK, ...) specific files are stored in a certain directory in src/backend/security/ace/. SE-PgSQL shall use sepgsql directory. It's way too early to decide this, IMO. * Documentation I don't plan to provide SGML documentation about ACE itself, except for internal section, because it is an internal infrastructure. For developers, src/backend/security/ace/README will provide a brief overview of the ACE framework, and every security hooks have source code comments to introduce the specification of itself. That's probably about right, but I don't want to prejudge that without further discussion in the community. * Patches As a general rule, a patch is organized for each object classes, except for very tiny object classes. e.g) pgsql-ace-02-database.patch pgsql-ace-03-schema.patch : I'll try to submit a set of patches related to the following object classes and functionalities by the 12/16. Stephen Frost is working on a patch for just one object type. I think that is a better approach than writing code for everything and then trying to review it all at once. We need to try to get consensus on the basic design before we write a lot of code. I do agree however that **if** we are able to get consensus on one object type, we should probably design the whole thing as a stack of patches that apply on top of each other, one per object type, for easier
Re: [HACKERS] SE-PostgreSQL/Lite Review
(2009/12/12 15:42), Ing . Marcos Lui's Orti'z Valmaseda wrote: KaiGai Kohei escribio': Stephen Frost wrote: Josh, * Joshua Brindle (met...@manicmethod.com) wrote: Stephen Frost wrote: I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. It isn't just a case of using #if and it magically working. You'd need a system to manage multiple labels on each object that can be addressed by different systems. So instead of having an object mapped only to system_u:object_r:mydb_t:s15 you'd also have to have it mapped to, eg., ^ for Smack. I'm not sure I see that being a problem.. We're going to have references in our object managers which make sense to us (eg: table OIDs) and then a way of mapping those to some label (or possibly a set of labels, as you describe). We might want to reconsider the catalog structure a bit if we want to support more than one at a time, but I don't see it as a huge problem to support more than one label existing for a given object. If we allow multiple security labels on a database object, we have to expand the structure of system catalog whenever a new security feature will come in. I think it against to the purpose of the framework. Even if we store them external relations to reference the object by OID, we have to provide multiple interface to import/export a security label for each enhanced securities. For example, it requires much complex patch to the pg_dump. My preference is all the enhanced securities shares a common facility to manage security label, a common statement support and a common backup/restore support. Thanks, I'm worried with the performance implications that have this patch on the core of the system. If you are aggregating more security layers, There is not a database degradation? I don't know how you attack these issues. Regards. If you don't enable any enhanced security providers, the cost to make access control decision is much the same with existing permission checks, because it just applies same checks. If you enable an enhanced security providers (such as SELinux), here is a trade-off between additional restriction and maximum performance. In my past measurement, SE-PostgreSQL with full functionalities had 2-4% of performance trade-off in pgbench test. (Note that it also enables row-level checks in my local branch.) See the page.16 of this slides: http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf We assume the user of SE-PgSQL gives security the first priority, so it will be enough acceptable penalty. 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] SE-PostgreSQL/Lite Review
(2009/12/12 21:51), Robert Haas wrote: 2009/12/12 KaiGai Koheikai...@kaigai.gr.jp: I'd like to summary about the framework. I am not necessarily in agreement with many of the points listed in this email. * Functionalities The ACE framework hosts both of the default PG checks and upcoming enhanced securities. We can build a binary with multiple enhanced security features, but user can choose one from them at most due to the security label management. Just yesterday, Stephen Frost and I were discussing whether to stick a layer of interdirection into the proposed interface layer using function pointers. We agreed to defer that decision to a later date. If, however, we eventually decide to do that, it will clearly mean that multiple security frameworks are possible simultaneously and that they can be implemented as loadable modules. On the other hand, we might decide that that design does NOT make sense, in which case we might end up with something more like the code snippet you proposed below, although I'm not sure you have the details right. I don't intend to include #ifdef ... #endif block in the patches which I'll submit in the next week. OK, it can be decided later. My opinion is enhanced security provider should be inlined. We have also not decided whether to support a single security label or multiple security labels per object. I tend to think that the case for multiple labels is pretty thin, but on the other hand it's not unmangeably difficult to do so. It could be coded up using an array representation, just as we now do for reloptions. Again, I want to defer this decision until later. Right now, I want to focus on seeing whether it is all possible for us to get community buy-in on just centralizing the existing checks, without making any commitment to what may come after that. OK, it to be later. * Namespace The framework is stored in the src/backend/security/ace. As a general rule, Each source file has this naming convension: src/backend/security/ace/object_class_ace.c Maybe. Generally I think if there's a common prefix it should go at the beginning of the filename, not the end, but I don't want to get into source code organization too much at this point. It's too early to make those decisions. But we have to deploy source code somewhere. :( At the moment, e of ace might not necessary, but it is not productive to review a patch to replace all the ac_ by ace_ later. So, I'll use this name just as a name at the moment. * Documentation I don't plan to provide SGML documentation about ACE itself, except for internal section, because it is an internal infrastructure. For developers, src/backend/security/ace/README will provide a brief overview of the ACE framework, and every security hooks have source code comments to introduce the specification of itself. That's probably about right, but I don't want to prejudge that without further discussion in the community. If something are necessary, I'll also describe SGML documentation later. At this moment, I'll include README and source code comments in the first patches in the next week. * Patches As a general rule, a patch is organized for each object classes, except for very tiny object classes. e.g) pgsql-ace-02-database.patch pgsql-ace-03-schema.patch : I'll try to submit a set of patches related to the following object classes and functionalities by the 12/16. Stephen Frost is working on a patch for just one object type. I think that is a better approach than writing code for everything and then trying to review it all at once. We need to try to get consensus on the basic design before we write a lot of code. I do agree however that **if** we are able to get consensus on one object type, we should probably design the whole thing as a stack of patches that apply on top of each other, one per object type, for easier review. That's not an approach I usually favor, but in this case I think it makes sense. What I wanted to say is that about a dozen of patches at once are not happy for us, so I'd like to submit a limited number of patches earlier. Are you saying that I should submit one-by-one and more rapidly? I don't have any reason to oppose it. 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] SE-PostgreSQL/Lite Review
Stephen Frost wrote: * Greg Smith (g...@2ndquadrant.com) wrote: I personally feel that Steven Frost's recent comments here about how the PostgreSQL code makes this harder than it should be really cuts to the core of a next step here. The problem facing us isn't is SEPostgreSQL the right solution for providing external security checks?; it's how can the PostgreSQL code be improved so that integrating external security is easier? Looking Thanks for that support, Greg. This was what I was principally trying to do with KaiGai and the commitfest patch I reviewed of his last round. Unfortunately, the committer comments I received on that patch didn't help us outline a path forward, just declared that the approach in the current patch wasn't workable. My, now much more optimistic thanks to our meeting, view is that the concept of abstracting the access controls is solid and a necessary first step; but we need to find a better way to implement it. I agree. SELinux should be one of the user selectable options. An abstraction layer for enhanced access controls are already adopted in a few open source projects (Linux kernel, X-window), and gets successed. Also thanks to our discussion, I've got a much better handle on how SELinux and the general secuirty community views PostgreSQL (and the Linux kernel for that matter)- it's an application which consists of a set of object managers. That then leads into an approach to address at least some of Tom's comments: Let's start by taking the patch I reviewed and splitting up security/access_control.c along object lines. Of course, the individual security/object_ac.c files would only include the .h's that are necessary. This would be a set of much smaller and much more managable files which only know about what they should know about- the object type they're responsible for. Basically, agreed. This file had more than 4KL in the last commit fest. IMO, however, we should consider these issues before splitting up old patch. (1) Whether the framework should host the default PG model, not only enhanced security features, or not? This patch tried to host both of the default PG model and SELinux. But, the default PG model does not have same origin with label-based mandatory access controls, such as SELinux, from a historical angle. So, this patch needed many of unobvious changes to the core routines. (2) Whether the framework should be comprehensive, or not? This patch tried to replace all the default PG checks in the core routines from the begining. It required to review many of unobvious changes in the core routine. Because I've been repeatedly pointed out to keep changeset smaller, I'm frightened for the direction. The coverage of the latest SE-PgSQL/Lite patch is only databases, schemas, tables and columns. I think it is a good start to deploy security hooks on the routines related to these objects, rather than comprehensive support from the begining. (3) In the future, whether we should allow multiple enhanced securities at the same time, or not? It was not clear in the previous commit fest. But, in fact, Linux kernel does not support multiple security features in same time, because it just makes security label management complex. (It also have another reasons, but just now unlear.) I don't think we have any good reason to activate multiple enhanced securities at same time. I think most of folks can agree with (2) and (3). But I expect opinion is divided at (1). For example, if we host the default PG checks to create a new database, all the existing checks shall be moved as follows: http://code.google.com/p/sepgsql/source/browse/trunk/pgsec/src/backend/security/access_control.c?r=2273#1430 In addition, it has to return the security context to be assigned on the new database, when it hosts SELinux. Even if this rework is limited to four kind of object classes, I'm worry about it overs an acceptable complexity. If the framework hosts only enhanced securities, this hook shall be implemented as: /* * ac_database_create * It checks permission to create a new database, and returns a security * label to be assigned on, or NULL if unnecessary. * * datName : name of the new database * srcDatOid : OID of the template database * datLabel : user given security label, or NULL */ Value * ac_database_create(const char *datName, Oid srcDatOid, Value *datLabel) { #ifdef HAVE_SELINUX if (sepgsql_is_enabled()) return sepgsql_database_create(datName, srcDatOid, datLabel); #endif return NULL; } In the caller (createdb()), this invocation shall be placed as follows: : + datLabel = ac_database_create(dbname, src_dboid, userDatLabel); : + if (!datLabel) + new_record_nulls[Anum_pg_database_datselabel - 1] = true; + else + new_record[Anum_pg_database_datselabel - 1] + =
Re: [HACKERS] SE-PostgreSQL/Lite Review
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: (1) Whether the framework should host the default PG model, not only enhanced security features, or not? This patch tried to host both of the default PG model and SELinux. But, the default PG model does not have same origin with label-based mandatory access controls, such as SELinux, from a historical angle. So, this patch needed many of unobvious changes to the core routines. I certainly understand what you're saying here. However, I feel that these changes to the core of PG are good, and are taking PG in the right direction to have a much clearer and better implemented security infrastructure. The fact that you've found a number of odd cases (duplicate checking, odd failure cases due to checks being done at various parts of the process, etc) is a testement that this is bringing the PG code forward even without the addition of SELinux support. I realize that makes it more work for you and I don't envy you that. (2) Whether the framework should be comprehensive, or not? This patch tried to replace all the default PG checks in the core routines from the begining. It required to review many of unobvious changes in the core routine. Because I've been repeatedly pointed out to keep changeset smaller, I'm frightened for the direction. The coverage of the latest SE-PgSQL/Lite patch is only databases, schemas, tables and columns. I think it is a good start to deploy security hooks on the routines related to these objects, rather than comprehensive support from the begining. I don't believe we will get support to commit a framework which is intended to eventually support the PG model (following from my answer to #1) in a partial form. Perhaps it would be good to split the patch up on a per-object-type basis, to make it simpler/easier to review (as in, patch #1: database_ac.c + changes to core for it; patch #2: table_ac.c + changes to core for it, etc; earlier patches assumed to be already done in later patches), but the assumption will almost certainly be that they will all be committed to wonderful CVS at the same time. (3) In the future, whether we should allow multiple enhanced securities at the same time, or not? It was not clear in the previous commit fest. But, in fact, Linux kernel does not support multiple security features in same time, because it just makes security label management complex. (It also have another reasons, but just now unlear.) I don't think we have any good reason to activate multiple enhanced securities at same time. To be honest, I feel that this will just fall out once we get through doing #1. I've just heard from Casey (author of the SMACK security manager, an alternative to SELinux) that the PGACE framework (which is what we suggested he look at) would be easily modified to support SMACK. I feel the same would be true of what we're talking about in #1. If you disagree with that, please let me know. I think most of folks can agree with (2) and (3). But I expect opinion is divided at (1). For example, if we host the default PG checks to create a new database, all the existing checks shall be moved as follows: http://code.google.com/p/sepgsql/source/browse/trunk/pgsec/src/backend/security/access_control.c?r=2273#1430 In addition, it has to return the security context to be assigned on the new database, when it hosts SELinux. Even if this rework is limited to four kind of object classes, I'm worry about it overs an acceptable complexity. I feel that what was at issue is that the complexity of access_control.c was far too great- because *everything* was in that one file. Splitting access_control.c into smaller files would make them more managable, and if we implement them all in a similar manner using a similar policy for function names, arguments, etc, then once the first object type is reviewed, the others will go more easily for the reviwer. If the security framework does *not* support the SQL model, I think we'll get push back from the community that it clearly couldn't be used by any other security manager generically without alot of potential changes and additional hooks that could end up bringing us all the way to being capable of supporting the SQL model anyway. I'm certainly willing to hear core indicate otherwise though. Thanks again, KaiGai. Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL/Lite Review
Robert Haas wrote: One comment I have in general about this process is that I think it would enormously reduce the level of pain associated with making these kinds of changes if we could get patches that were not full of minor issues that need to be cleaned up (like comments not properly adjusted, spelling/grammar errors, formatting inconsistent with the rest of the code base, poor English). Sure, it's not fair to ask the committers to do that. But it's not really something we can expect to get in all situations from our English as a second language contributors either--it's hard enough to get these details right even on stuff done in this country by native speakers. At least we've got a big stack of comments that usually make sense if you read them to work with on the SE-PostgreSQL patches, which is much better than the alternative. I think we need a two pronged attack on this issue. Eventually I think someone who wants this feature in there will need to sponsor someone (and not even necessarily a coder) to do a sizable round of plain old wording cleanup on the comment text of the patch. Robert is right to point out the committers are too expensive, in terms of what work for the community they could be doing besides that, to waste on that job. English editing help good enough to help a lot for this purpose isn't hard to find though. As far as formatting, it drives me a little crazy that it's not more common practice for contributors to do their own targeted pgindent runs to at least nail some of the low-hanging fruit in that area, due the difficulty of working with the tool. That's something else I think it would be nice to invest a little time in improving. For example, there's no reason we should still have to kick back patches regularly just because of tab/space issues, and I know I run into one of those nearly every CommitFest. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.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] SE-PostgreSQL/Lite Review
Stephen Frost wrote: KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: (1) Whether the framework should host the default PG model, not only enhanced security features, or not? This patch tried to host both of the default PG model and SELinux. But, the default PG model does not have same origin with label-based mandatory access controls, such as SELinux, from a historical angle. So, this patch needed many of unobvious changes to the core routines. I certainly understand what you're saying here. However, I feel that these changes to the core of PG are good, and are taking PG in the right direction to have a much clearer and better implemented security infrastructure. The fact that you've found a number of odd cases (duplicate checking, odd failure cases due to checks being done at various parts of the process, etc) is a testement that this is bringing the PG code forward even without the addition of SELinux support. I realize that makes it more work for you and I don't envy you that. The reason why I prefer MAC only framework is not a technical reason. As long as we can review it and acceptable, I have no reason to avoid it. (2) Whether the framework should be comprehensive, or not? This patch tried to replace all the default PG checks in the core routines from the begining. It required to review many of unobvious changes in the core routine. Because I've been repeatedly pointed out to keep changeset smaller, I'm frightened for the direction. The coverage of the latest SE-PgSQL/Lite patch is only databases, schemas, tables and columns. I think it is a good start to deploy security hooks on the routines related to these objects, rather than comprehensive support from the begining. I don't believe we will get support to commit a framework which is intended to eventually support the PG model (following from my answer to #1) in a partial form. Perhaps it would be good to split the patch up on a per-object-type basis, to make it simpler/easier to review (as in, patch #1: database_ac.c + changes to core for it; patch #2: table_ac.c + changes to core for it, etc; earlier patches assumed to be already done in later patches), but the assumption will almost certainly be that they will all be committed to wonderful CVS at the same time. As Rober Haas already suggested in another message, my patch in the last commit fest is too large. It tried to rework anything in a single patch. The per-object-type basis make sense for me. In my cosmetic preference, ace_ is better than ac_. The 'e' means extendable, and ace feels like something cool. :-) In X-window system, it calls its framework XACE. And I'd like to store these files in backend/security/ace/*.c, because backend/security will also store other security modules! src/ + backend/ + security/ + ace/ ... access control framework + sepgsql/ ... selinux specific code + smack/ ... (upcoming?) smack specific code + solaristx/ ... (upcoming?) solaris-tx specific code : (3) In the future, whether we should allow multiple enhanced securities at the same time, or not? It was not clear in the previous commit fest. But, in fact, Linux kernel does not support multiple security features in same time, because it just makes security label management complex. (It also have another reasons, but just now unlear.) I don't think we have any good reason to activate multiple enhanced securities at same time. To be honest, I feel that this will just fall out once we get through doing #1. I've just heard from Casey (author of the SMACK security manager, an alternative to SELinux) that the PGACE framework (which is what we suggested he look at) would be easily modified to support SMACK. I feel the same would be true of what we're talking about in #1. If you disagree with that, please let me know. Ahh, what I want to say is, whether we should allow enhanced securities. If we host the default PG model on the framework, it is an exception of the count. The reason why I prefer the default PG check + one enhanced security at most is simplification of the security label management. If two label-based enhanced securities are enabled at same time, we need two field on pg_class and others to store security context. In addition, OS allows to choose one enhanced security at most eventually. In my image, the hook should be as: Value * ac_database_create([arguments ...]) { /* * The default PG checks here. * It is never disabled */ /* enhanced security as follows */ #if defined(HAVE_SELINUX) if (sepgsql_is_enabled()) return sepgsql_database_create(...); #elif defined(HAVE_SMACK) if (smack_is_enabled()) return smack_database_create(...); #elif defined(HAVE_SOLARISTX) if (soltx_is_enabled()) return soltx_database_create(...); #endif
Re: [HACKERS] SE-PostgreSQL/Lite Review
Greg Smith wrote: It's funny; we started out this CommitFest with me scrambling to find someone, anyone, willing to review the latest SE-PostgreSQL patch, knowing it was a big job and few were likely to volunteer. Then schedules lined up just right, and last night I managed to get a great group of people all together to do perhaps the biggest single patch review ever, to work on just that. I gathered up a list of the biggest concerns about this feature and its associated implementation, we got a number of regular PostgreSQL hackers and two of the security guys you've seen on this list all in the same room, and we talked about little but SEPostgreSQL for hours. Minutes are at http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd suggest anyone interested in this feature (or in rejecting this feature) to take a look at what we covered. I just wanted to add some talking notes here. User base for the feature: While my goals for this feature line up with military/government users this is in no way the extent of the potential user base. The fact is most people won't know they want this feature until it is available. Why is that? Well, how many of you have written webapps and implemented policy logic in your application rather than the database level? Why do people currently feel the need to do this? Is it even possible to implement some complex policies (eg., PCI compliance) at the database level? If PostgreSQL version whatever suddenly had the ability to implement the policy logic in the database, would you move it there? I know I would.. Audit: In past conversations it sounded like some of the Postgres community was skeptical even about the design of the security model. For an even earlier look (September 2006) of KaiGai and the SELinux community talking about the object model and even high level design of the solution see http://marc.info/?l=selinuxm=115762285013528w=2 I've read through some of the prior patches, but haven't done an extensive audit, not only because of the size but because it became apparent relatively quickly that it was a waste of time and the community here wasn't going to accept it anyway. If this situation changes I think you'll find a few of us willing to donate time to the cause. Policy: The policy is easy once you have an object model that covers your use cases. You can see in the above discussion how we came to the object model we have now and why I've been comfortable with it since then. An interesting aside, we must have hit the object model pretty well since another RDBMS (Trusted Rubix) uses the same one as SEPostgreSQL. See http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf Works outside of SELinux: As Stephen already pointed out, Casey Schaufler (CC'd) who is the author of SMACK http://schaufler-ca.com/ believes that the abstractions provided by PGACE will allow integration of his security system as well. SMACK is already in the Linux kernel as an alternative LSM to SELinux. Further, not that I've seen the code or know how they did it, Trusted Rubix has support for multiple access control systems http://rubix.com/cms/features including Trusted Solaris, Solaris Trusted Extensions, SELinux and their own RBAC system. -- With all that said, I've very interested in seeing this work move along. In its current shape it has limited utility in my world (although I know of at least 2 solutions I've seen that run 20 Postgres servers on a single system just to have database separation). The main thing that prevents it from being used in that situation today is superuser access (eg., we can't have superusers that can go around and muck in data he's not cleared for). But I recognize that this is a first step to a potentially great system and I definitely want to see it moving forward. -- 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] SE-PostgreSQL/Lite Review
Joshua Brindle wrote: Greg Smith wrote: It's funny; we started out this CommitFest with me scrambling to find someone, anyone, willing to review the latest SE-PostgreSQL patch, knowing it was a big job and few were likely to volunteer. Then schedules lined up just right, and last night I managed to get a great group of people all together to do perhaps the biggest single patch review ever, to work on just that. I gathered up a list of the biggest concerns about this feature and its associated implementation, we got a number of regular PostgreSQL hackers and two of the security guys you've seen on this list all in the same room, and we talked about little but SEPostgreSQL for hours. Minutes are at http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd suggest anyone interested in this feature (or in rejecting this feature) to take a look at what we covered. I just wanted to add some talking notes here. User base for the feature: While my goals for this feature line up with military/government users this is in no way the extent of the potential user base. The fact is most people won't know they want this feature until it is available. Why is that? Well, how many of you have written webapps and implemented policy logic in your application rather than the database level? Why do people currently feel the need to do this? Is it even possible to implement some complex policies (eg., PCI compliance) at the database level? If PostgreSQL version whatever suddenly had the ability to implement the policy logic in the database, would you move it there? I know I would.. Audit: In past conversations it sounded like some of the Postgres community was skeptical even about the design of the security model. For an even earlier look (September 2006) of KaiGai and the SELinux community talking about the object model and even high level design of the solution see http://marc.info/?l=selinuxm=115762285013528w=2 I highly suggest a quick read of the above thread, it shows how we established an object model in fairly short order. The conversation also continues here: http://marc.info/?l=selinuxm=115786457722767w=2 and also here: http://marc.info/?l=selinuxm=117160445604805w=2 http://marc.info/?l=selinuxm=117160445611588w=2 http://marc.info/?l=selinuxm=117160445608517w=2 -- 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] SE-PostgreSQL/Lite Review
KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: As Rober Haas already suggested in another message, my patch in the last commit fest is too large. It tried to rework anything in a single patch. The per-object-type basis make sense for me. Agreed. In my cosmetic preference, ace_ is better than ac_. The 'e' means extendable, and ace feels like something cool. :-) No complaints here.. I just hope this doesn't end up being *exactly* the same as your original PGACE patches.. I'd feel terrible if we weren't able to at least improve something with this extremely long and drawn our process! And I'd like to store these files in backend/security/ace/*.c, because backend/security will also store other security modules! This is perfectly reasonable in my view. No complaints here. src/ + backend/ + security/ + ace/ ... access control framework + sepgsql/ ... selinux specific code + smack/ ... (upcoming?) smack specific code + solaristx/ ... (upcoming?) solaris-tx specific code Looks good to me. Perhaps we'll have a smack/ patch showing up very shortly as well.. The reason why I prefer the default PG check + one enhanced security at most is simplification of the security label management. If two label-based enhanced securities are enabled at same time, we need two field on pg_class and others to store security context. Ah, yes, I see your point must more clearly now. This sounds reasonable to me. In addition, OS allows to choose one enhanced security at most eventually. In my image, the hook should be as: Value * ac_database_create([arguments ...]) { /* * The default PG checks here. * It is never disabled */ /* enhanced security as follows */ #if defined(HAVE_SELINUX) if (sepgsql_is_enabled()) return sepgsql_database_create(...); #elif defined(HAVE_SMACK) if (smack_is_enabled()) return smack_database_create(...); #elif defined(HAVE_SOLARISTX) if (soltx_is_enabled()) return soltx_database_create(...); #endif return NULL; } We can share a common image image? If all of these security modules make sense as only-more-restrictive, then I have no problem with this approach. Honestly, I'm fine with the initial hooks looking as above in any case, since it provides a clear way to deal with switching out the 'default PG checks' if someone desires it- you could #if around that block as well. As it's the principle/primary, and I could see only-more-restrictive being more popular, I don't mind having that code in-line in the hook. The check itself is still being brought out and into the security/ framework. I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL/Lite Review
Greg, * Greg Smith (g...@2ndquadrant.com) wrote: I think we need a two pronged attack on this issue. Eventually I think someone who wants this feature in there will need to sponsor someone (and not even necessarily a coder) to do a sizable round of plain old wording cleanup on the comment text of the patch. For the benefit of this list (this was already discussed some at the BWPUG meeting), I agree with Greg on this and am actively looking to try and help (either directly in my spare time or indirectly as a sponsor). If anyone else is interested or can do so as well, that would be great! Please speak up! Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL/Lite Review
On Fri, 2009-12-11 at 11:36 -0500, Stephen Frost wrote: [Snip...] In addition, OS allows to choose one enhanced security at most eventually. In my image, the hook should be as: Value * ac_database_create([arguments ...]) { /* * The default PG checks here. * It is never disabled */ /* enhanced security as follows */ #if defined(HAVE_SELINUX) if (sepgsql_is_enabled()) return sepgsql_database_create(...); #elif defined(HAVE_SMACK) if (smack_is_enabled()) return smack_database_create(...); #elif defined(HAVE_SOLARISTX) if (soltx_is_enabled()) return soltx_database_create(...); #endif return NULL; } We can share a common image image? If all of these security modules make sense as only-more-restrictive, then I have no problem with this approach. Honestly, I'm fine with the initial hooks looking as above in any case, since it provides a clear way to deal with switching out the 'default PG checks' if someone desires it- you could #if around that block as well. As it's the principle/primary, and I could see only-more-restrictive being more popular, I don't mind having that code in-line in the hook. The check itself is still being brought out and into the security/ framework. I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. So when Eamon did the XACE work he allowed for stackable security modules. We do not allow for this in the Linux kernel but we can still figure out whether we want to support it for now. I'm not convinced that the ifdef model is the right way to go. There should be a security structure where pointers to the appropriate functions reside (like we have in linux) so this way you have a register_module call which takes the mac model and puts all the necessary function pointers into the structure and the hook is just a call to security-create_db. If you want to make it stackable you make security-create_db a list of function pointers that get executed in turn. I'll ask Eamon when I see him next how he handled deregistration of a particular model. Dave -- 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] SE-PostgreSQL/Lite Review
Stephen Frost wrote: KaiGai, snip I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. It isn't just a case of using #if and it magically working. You'd need a system to manage multiple labels on each object that can be addressed by different systems. So instead of having an object mapped only to system_u:object_r:mydb_t:s15 you'd also have to have it mapped to, eg., ^ for Smack. -- 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] SE-PostgreSQL/Lite Review
Josh, * Joshua Brindle (met...@manicmethod.com) wrote: Stephen Frost wrote: I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. It isn't just a case of using #if and it magically working. You'd need a system to manage multiple labels on each object that can be addressed by different systems. So instead of having an object mapped only to system_u:object_r:mydb_t:s15 you'd also have to have it mapped to, eg., ^ for Smack. I'm not sure I see that being a problem.. We're going to have references in our object managers which make sense to us (eg: table OIDs) and then a way of mapping those to some label (or possibly a set of labels, as you describe). We might want to reconsider the catalog structure a bit if we want to support more than one at a time, but I don't see it as a huge problem to support more than one label existing for a given object. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL/Lite Review
On Thursday 10 December 2009 21:47:18 KaiGai Kohei wrote: Greg Smith wrote: It's funny; we started out this CommitFest with me scrambling to find someone, anyone, willing to review the latest SE-PostgreSQL patch, knowing it was a big job and few were likely to volunteer. Then schedules lined up just right, and last night I managed to get a great group of people all together to do perhaps the biggest single patch review ever, to work on just that.I gathered up a list of the biggest concerns about this feature and its associated implementation, we got a number of regular PostgreSQL hackers and two of the security guys you've seen on this list all in the same room, and we talked about little but SEPostgreSQL for hours. Minutes are at http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd suggest anyone interested in this feature (or in rejecting this feature) to take a look at what we covered. I repent that I cannot attend here. The wikipage is a good summarize. Thanks for your efforts. There's comments there, with references for you [citation needed] types, to help answer four of the most common complaints I've seen on this list about this feature: -Is there really a user base for it? -Has it been audited by security professionals? -Is there a useful SELinux policty to support it? -Will this work with other security frameworks? I feel pretty good now that these are not really our community's problems--these have had at least modest, and in some cases extensive, due diligence applied to them. And we've confirmed there's access to expertise from the security community to help out with remaining concerns there, in person even if we plan it out right. I personally suspect they've been discouraged from getting involved more by the slow pace this has been proceeding within our community and the general disarray around it, which would be understandable. IMO, the slow pace is not a primary reason. In fact, SELinux was released at 2000 Dec, but it gets integtated into the mainline kernel at 2003 Aug with various kind of improvements. It takes about 3 years from the first relase. IIRC, now we take 2.5 years from the first announce of SE-PgSQL in this list, and various kind of improvements and cleanups had been done. It is a bit long term, but not too long term. The reason of this gap is that people have individual consciousness about their security. I often represent it as security is a subjective term. Needless to say, we don't have magic-bullets for any threats. Any technology has its metirs and limitations. However, people tend to say it is nonsense, if the feature does not match with their recognizable demands or threats. Security-folks know MAC is not magic-bullets, while it is a significant piece of system security. But some of complaints might be pointless for security experts, so had been dismotivated. From the perspective of security folks, we have to introduce it doggedly. And, I'd like to understand database folks there are various kind of security models and viewpoints here. SELinux is one of them. The parts I do believe we have reason to be concerned are with the code integration into the PostgreSQL core, and no one has any easy answers to things like isn't this going to increase CERT advisories? and who's going to maintain this besides KaiGai? I personally feel that Steven Frost's recent comments here about how the PostgreSQL code makes this harder than it should be really cuts to the core of a next step here. The problem facing us isn't is SEPostgreSQL the right solution for providing external security checks?; it's how can the PostgreSQL code be improved so that integrating external security is easier? Looking at SEPostgreSQL is great because it really highlights where the existing set of places are. This general idea matches where thinking on things like row-level security was already going too--implement this for the database in general, then link SEPostgres in as just one provider of a security restriction. Right, it seems to me the security provider is a good phrase to represent this feature. It just provides additional access control decisions based on the different perspective of security model. Please note that the access control granularity is not an essential issue. We can also assume table-level mandatory access controls for instance. The latest patch provides table/column level controls without row-level, because the current PgSQL has facilities to know what tables and columns are referenced reasonably, so SE-PgSQL also can know what tables/columns are referenced without special tricks. Please remind the earlier SE-PgSQL in v8.2.x. It walked on the Query tree to pick up what columns were accessed. I hope the review from the BWPUG helps everyone out, and that the suggestions on the wiki for the Follow-up plan are helpful. As CF
Re: [HACKERS] SE-PostgreSQL/Lite Review
Stephen Frost wrote: In my cosmetic preference, ace_ is better than ac_. The 'e' means extendable, and ace feels like something cool. :-) No complaints here.. I just hope this doesn't end up being *exactly* the same as your original PGACE patches.. I'd feel terrible if we weren't able to at least improve something with this extremely long and drawn our process! Please forget old PGACE. We're talking about our future. :-) And I'd like to store these files in backend/security/ace/*.c, because backend/security will also store other security modules! This is perfectly reasonable in my view. No complaints here. src/ + backend/ + security/ + ace/ ... access control framework + sepgsql/ ... selinux specific code + smack/ ... (upcoming?) smack specific code + solaristx/ ... (upcoming?) solaris-tx specific code Looks good to me. Perhaps we'll have a smack/ patch showing up very shortly as well.. It's a welcome feature. The reason why I prefer the default PG check + one enhanced security at most is simplification of the security label management. If two label-based enhanced securities are enabled at same time, we need two field on pg_class and others to store security context. Ah, yes, I see your point must more clearly now. This sounds reasonable to me. In addition, OS allows to choose one enhanced security at most eventually. In my image, the hook should be as: Value * ac_database_create([arguments ...]) { /* * The default PG checks here. * It is never disabled */ /* enhanced security as follows */ #if defined(HAVE_SELINUX) if (sepgsql_is_enabled()) return sepgsql_database_create(...); #elif defined(HAVE_SMACK) if (smack_is_enabled()) return smack_database_create(...); #elif defined(HAVE_SOLARISTX) if (soltx_is_enabled()) return soltx_database_create(...); #endif return NULL; } We can share a common image image? If all of these security modules make sense as only-more-restrictive, then I have no problem with this approach. Honestly, I'm fine with the initial hooks looking as above in any case, since it provides a clear way to deal with switching out the 'default PG checks' if someone desires it- you could #if around that block as well. As it's the principle/primary, and I could see only-more-restrictive being more popular, I don't mind having that code in-line in the hook. The check itself is still being brought out and into the security/ framework. Ahh, indeed, #elif does not allow a single binary to provide multiple options. You are right. I'd like to rewrite it as follows: Value * ac_database_create([arguments ...]) { Value *retval = NULL; /* * The default PG checks here. * It is never disabled */ switch (ace_feature) { #ifdef HAVE_SELINUX case ACE_SELINUX_SUPPORT: if (sepgsql_is_enabled()) retval = sepgsql_database_create(...); break; #endif #ifdef HAVE_SMACK case ACE_SMACK_SUPPORT: if (smack_is_enabled()) retval = smack_database_create(...); break; #endif #ifdef HAVE_SOLARISTX case ACE_SOLARISTX_SUPPORT: if (soltx_is_enabled()) retval = soltx_database_create(...); break; #endif default: break; } return retval; } I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. The reason why I don't want to support multiple enhanced securities at same time is complexity of security label management, not access control model. Unlike X-server, RDBMS have to manage the security label of database object persistently on the disk. It naturally needs enhancement of data structure, such as pg_class.relsecon field in the latest SE-PgSQL/Lite. If the third enhanced security does not use security label, basically, I think it is feasible. In fact, the default PG check is a security provider without security label, and it can coexist with SELinux. 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] SE-PostgreSQL/Lite Review
Stephen Frost wrote: Josh, * Joshua Brindle (met...@manicmethod.com) wrote: Stephen Frost wrote: I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. It isn't just a case of using #if and it magically working. You'd need a system to manage multiple labels on each object that can be addressed by different systems. So instead of having an object mapped only to system_u:object_r:mydb_t:s15 you'd also have to have it mapped to, eg., ^ for Smack. I'm not sure I see that being a problem.. We're going to have references in our object managers which make sense to us (eg: table OIDs) and then a way of mapping those to some label (or possibly a set of labels, as you describe). We might want to reconsider the catalog structure a bit if we want to support more than one at a time, but I don't see it as a huge problem to support more than one label existing for a given object. If we allow multiple security labels on a database object, we have to expand the structure of system catalog whenever a new security feature will come in. I think it against to the purpose of the framework. Even if we store them external relations to reference the object by OID, we have to provide multiple interface to import/export a security label for each enhanced securities. For example, it requires much complex patch to the pg_dump. My preference is all the enhanced securities shares a common facility to manage security label, a common statement support and a common backup/restore support. 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] SE-PostgreSQL/Lite Review
I'd like to summary about the framework. * Functionalities The ACE framework hosts both of the default PG checks and upcoming enhanced securities. We can build a binary with multiple enhanced security features, but user can choose one from them at most due to the security label management. So, it basically has the following structure: Value * ac_database_create([arguments ...]) { Value *retval = NULL; /* * The default PG checks here. It is never disabled. */ switch (ace_feature) { #ifdef HAVE_SELINUX case ACE_SELINUX_SUPPORT: if (sepgsql_is_enabled()) retval = sepgsql_database_create(...); break; #endif #ifdef HAVE_SMACK case ACE_SMACK_SUPPORT: if (smack_is_enabled()) retval = smack_database_create(...); break; #endif default: break; } return retval; } * Namespace The framework is stored in the src/backend/security/ace. As a general rule, Each source file has this naming convension: src/backend/security/ace/object_class_ace.c Uncategolized hooks (such as cascaded-deletion called from dependency system) are stored in ace/sysobj_ace.c. It is an exception. All the framework functions (except for static) have ace_ prefix to distinguish from any other internal routines. The security providers (SELinux, upcoming SMACK, ...) specific files are stored in a certain directory in src/backend/security/ace/. SE-PgSQL shall use sepgsql directory. * Documentation I don't plan to provide SGML documentation about ACE itself, except for internal section, because it is an internal infrastructure. For developers, src/backend/security/ace/README will provide a brief overview of the ACE framework, and every security hooks have source code comments to introduce the specification of itself. * Patches As a general rule, a patch is organized for each object classes, except for very tiny object classes. e.g) pgsql-ace-02-database.patch pgsql-ace-03-schema.patch : I'll try to submit a set of patches related to the following object classes and functionalities by the 12/16. * pgsql-ace-01-common.patch It contains common part of ACE and uncategolized ones, such as cascaded deletion from dependency, and so on. * pgsql-ace-02-database.patch It contains security hooks related to pg_database. * pgsql-ace-03-schema.patch It contains security hooks related to pg_namespace. * pgsql-ace-04-relation.patch It contains security hooks related to pg_class and pg_attribtue * pgace-ace-05-label.patch It contains security label support in SQL statement. I'd like to conclude arguable things earlier than whole of reworks. Then, we shall be able to see the rest of patches within this year. Thanks, KaiGai Kohei wrote: Stephen Frost wrote: In my cosmetic preference, ace_ is better than ac_. The 'e' means extendable, and ace feels like something cool. :-) No complaints here.. I just hope this doesn't end up being *exactly* the same as your original PGACE patches.. I'd feel terrible if we weren't able to at least improve something with this extremely long and drawn our process! Please forget old PGACE. We're talking about our future. :-) And I'd like to store these files in backend/security/ace/*.c, because backend/security will also store other security modules! This is perfectly reasonable in my view. No complaints here. src/ + backend/ + security/ + ace/ ... access control framework + sepgsql/ ... selinux specific code + smack/ ... (upcoming?) smack specific code + solaristx/ ... (upcoming?) solaris-tx specific code Looks good to me. Perhaps we'll have a smack/ patch showing up very shortly as well.. It's a welcome feature. The reason why I prefer the default PG check + one enhanced security at most is simplification of the security label management. If two label-based enhanced securities are enabled at same time, we need two field on pg_class and others to store security context. Ah, yes, I see your point must more clearly now. This sounds reasonable to me. In addition, OS allows to choose one enhanced security at most eventually. In my image, the hook should be as: Value * ac_database_create([arguments ...]) { /* * The default PG checks here. * It is never disabled */ /* enhanced security as follows */ #if defined(HAVE_SELINUX) if (sepgsql_is_enabled()) return sepgsql_database_create(...); #elif defined(HAVE_SMACK) if (smack_is_enabled()) return smack_database_create(...); #elif defined(HAVE_SOLARISTX) if (soltx_is_enabled()) return soltx_database_create(...); #endif return NULL; } We can share a common image image? If all of these security modules make sense as only-more-restrictive, then I have no problem with
[HACKERS] SE-PostgreSQL/Lite Review
It's funny; we started out this CommitFest with me scrambling to find someone, anyone, willing to review the latest SE-PostgreSQL patch, knowing it was a big job and few were likely to volunteer. Then schedules lined up just right, and last night I managed to get a great group of people all together to do perhaps the biggest single patch review ever, to work on just that.I gathered up a list of the biggest concerns about this feature and its associated implementation, we got a number of regular PostgreSQL hackers and two of the security guys you've seen on this list all in the same room, and we talked about little but SEPostgreSQL for hours. Minutes are at http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd suggest anyone interested in this feature (or in rejecting this feature) to take a look at what we covered. There's comments there, with references for you [citation needed] types, to help answer four of the most common complaints I've seen on this list about this feature: -Is there really a user base for it? -Has it been audited by security professionals? -Is there a useful SELinux policty to support it? -Will this work with other security frameworks? I feel pretty good now that these are not really our community's problems--these have had at least modest, and in some cases extensive, due diligence applied to them. And we've confirmed there's access to expertise from the security community to help out with remaining concerns there, in person even if we plan it out right. I personally suspect they've been discouraged from getting involved more by the slow pace this has been proceeding within our community and the general disarray around it, which would be understandable. The parts I do believe we have reason to be concerned are with the code integration into the PostgreSQL core, and no one has any easy answers to things like isn't this going to increase CERT advisories? and who's going to maintain this besides KaiGai? I personally feel that Steven Frost's recent comments here about how the PostgreSQL code makes this harder than it should be really cuts to the core of a next step here. The problem facing us isn't is SEPostgreSQL the right solution for providing external security checks?; it's how can the PostgreSQL code be improved so that integrating external security is easier? Looking at SEPostgreSQL is great because it really highlights where the existing set of places are. This general idea matches where thinking on things like row-level security was already going too--implement this for the database in general, then link SEPostgres in as just one provider of a security restriction. I hope the review from the BWPUG helps everyone out, and that the suggestions on the wiki for the Follow-up plan are helpful. As CF Manager, I feel we've given this patch its fair chunk of time this last month. I don't really see any options except to mark it returned with feedback yet again for now, as this CF is nearing its close and there's still plenty of open issues. My hope is that we've made progress toward answering some of the fundamental concerns that keep popping up around this patch for good, and that a plan with community members who will act on it (in this country for once) is coming together. As always, we owe KaiGai a debt for offering his code contributions, sticking through an immense amount of criticism, and suggesting ways the rest of the database might become better overall through that interaction. I do hope a committer is able to give his Largeobject access controls patch proper attention and commit it if feasible to do so. It would be nice to see confirmed progress toward the larger goal of both feature and buzzword/checkbox complete PostgreSQL security is being made through his contributions. At this point, I think someone comfortable with hacking into the PostgreSQL core will need to work on this project from that angle before even SE/PostgreSQL Lite is likely to be something we can commit. Maybe we can get KaiGai thinking in those terms instead of how he's been approaching the problem. Maybe Bruce or Steven can champion that work. I have to be honest and say that I'm not optimistic that this is possible or even a good idea to accomplish in the time remaining during this release. A patch that touches the security model in fairly fundamental ways seems like it would be much better as an alpha-1 candidate, while there's still plenty of time to shake out issues, than as a beta-1 or even alpha-3 one. And I'm skeptical that this feature really fits the true use-cases for SEPostgres without row-level filtering anyway. After our talk last night, it's obvious we need to figure out how to get that back before including the code does what people really want here. But based on looking at the market for this sort of feature, providing this new form of security integrated into the
Re: [HACKERS] SE-PostgreSQL/Lite Review
Greg Smith wrote: It's funny; we started out this CommitFest with me scrambling to find someone, anyone, willing to review the latest SE-PostgreSQL patch, knowing it was a big job and few were likely to volunteer. Then schedules lined up just right, and last night I managed to get a great group of people all together to do perhaps the biggest single patch review ever, to work on just that.I gathered up a list of the biggest concerns about this feature and its associated implementation, we got a number of regular PostgreSQL hackers and two of the security guys you've seen on this list all in the same room, and we talked about little but SEPostgreSQL for hours. Minutes are at http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd suggest anyone interested in this feature (or in rejecting this feature) to take a look at what we covered. I repent that I cannot attend here. The wikipage is a good summarize. Thanks for your efforts. There's comments there, with references for you [citation needed] types, to help answer four of the most common complaints I've seen on this list about this feature: -Is there really a user base for it? -Has it been audited by security professionals? -Is there a useful SELinux policty to support it? -Will this work with other security frameworks? I feel pretty good now that these are not really our community's problems--these have had at least modest, and in some cases extensive, due diligence applied to them. And we've confirmed there's access to expertise from the security community to help out with remaining concerns there, in person even if we plan it out right. I personally suspect they've been discouraged from getting involved more by the slow pace this has been proceeding within our community and the general disarray around it, which would be understandable. IMO, the slow pace is not a primary reason. In fact, SELinux was released at 2000 Dec, but it gets integtated into the mainline kernel at 2003 Aug with various kind of improvements. It takes about 3 years from the first relase. IIRC, now we take 2.5 years from the first announce of SE-PgSQL in this list, and various kind of improvements and cleanups had been done. It is a bit long term, but not too long term. The reason of this gap is that people have individual consciousness about their security. I often represent it as security is a subjective term. Needless to say, we don't have magic-bullets for any threats. Any technology has its metirs and limitations. However, people tend to say it is nonsense, if the feature does not match with their recognizable demands or threats. Security-folks know MAC is not magic-bullets, while it is a significant piece of system security. But some of complaints might be pointless for security experts, so had been dismotivated. From the perspective of security folks, we have to introduce it doggedly. And, I'd like to understand database folks there are various kind of security models and viewpoints here. SELinux is one of them. The parts I do believe we have reason to be concerned are with the code integration into the PostgreSQL core, and no one has any easy answers to things like isn't this going to increase CERT advisories? and who's going to maintain this besides KaiGai? I personally feel that Steven Frost's recent comments here about how the PostgreSQL code makes this harder than it should be really cuts to the core of a next step here. The problem facing us isn't is SEPostgreSQL the right solution for providing external security checks?; it's how can the PostgreSQL code be improved so that integrating external security is easier? Looking at SEPostgreSQL is great because it really highlights where the existing set of places are. This general idea matches where thinking on things like row-level security was already going too--implement this for the database in general, then link SEPostgres in as just one provider of a security restriction. Right, it seems to me the security provider is a good phrase to represent this feature. It just provides additional access control decisions based on the different perspective of security model. Please note that the access control granularity is not an essential issue. We can also assume table-level mandatory access controls for instance. The latest patch provides table/column level controls without row-level, because the current PgSQL has facilities to know what tables and columns are referenced reasonably, so SE-PgSQL also can know what tables/columns are referenced without special tricks. Please remind the earlier SE-PgSQL in v8.2.x. It walked on the Query tree to pick up what columns were accessed. I hope the review from the BWPUG helps everyone out, and that the suggestions on the wiki for the Follow-up plan are helpful. As CF Manager, I feel we've given this patch its fair chunk of time this last month. I don't really
Re: [HACKERS] SE-PostgreSQL/Lite Review
* Greg Smith (g...@2ndquadrant.com) wrote: I personally feel that Steven Frost's recent comments here about how the PostgreSQL code makes this harder than it should be really cuts to the core of a next step here. The problem facing us isn't is SEPostgreSQL the right solution for providing external security checks?; it's how can the PostgreSQL code be improved so that integrating external security is easier? Looking Thanks for that support, Greg. This was what I was principally trying to do with KaiGai and the commitfest patch I reviewed of his last round. Unfortunately, the committer comments I received on that patch didn't help us outline a path forward, just declared that the approach in the current patch wasn't workable. My, now much more optimistic thanks to our meeting, view is that the concept of abstracting the access controls is solid and a necessary first step; but we need to find a better way to implement it. Also thanks to our discussion, I've got a much better handle on how SELinux and the general secuirty community views PostgreSQL (and the Linux kernel for that matter)- it's an application which consists of a set of object managers. That then leads into an approach to address at least some of Tom's comments: Let's start by taking the patch I reviewed and splitting up security/access_control.c along object lines. Of course, the individual security/object_ac.c files would only include the .h's that are necessary. This would be a set of much smaller and much more managable files which only know about what they should know about- the object type they're responsible for. Clearly, code comments also need to be reviewed and issues with them addressed. I'm also not a fan of the skip permissions check arguments, which are there specifically to address cascade deletions, which is a requirment of our PG security model. I'd love to see a better solution and am open to suggestions or thoughts about what one would be. I know one of KaiGai's concerns in this area was performance, butas we often do for PG, perhaps we should consider that second and first consider what it would look like if we ignored performance concerns. This would change skip permissions check to what object is being deleted, and am I a sub-object of that?. I don't feel like I've explained that well enough, perhaps someone else could come up with another solution, or maybe figure out a better way to describe what I'm trying to get with this. Regarding the special-purpose shims- I feel there should be a way for us to handle them better. This might be a good use-case for column-level privileges in pg_catalog. That's pure speculation at the moment tho, I havn't re-looked at those shims lately to see if that even makes sense. I don't like them either though, for what it's worth. Regarding contrib modules- I view them as I do custom code which the user writes and loads through dlopen() into the backend process- there should be a way for it to do security right, but it ultimately has to be the responsibility of the contrib module. Admins can review what contrib modules have been made SELinux/etc aware and choose to install only those which they trust. Maybe Bruce or Steven can champion that work. See above? ;) I've had enough of a break from this and our discussion has revitalized me. I certainly welcome Bruce's comments, as well as anyone else. I have to be honest and say that I'm not optimistic that this is possible or even a good idea to accomplish in the time remaining during this release. While I agree with you, I wish you hadn't brought it up. :) Mostly because I feel like it may discourage people from wanting to spend time on it due to desire to focus on things which are likely to make it into the next release. That being said, I don't feel that'll be an issue for KaiGai or myself, but getting someone beyond us working on this would really be great, especially yourself and/or Bruce. On my side, in addition to helping coordinate everyone pushing in the same direction, I'll also continue trying to shake out some sponsorship funding for additional work out of the people in this country it would benefit. It seems I'm going to keep getting pulled into the middle of this area regularly anyway. Thank you for that. I'm planning to do the same and will certainly let people know, to the extent possible, of anything I'm able to dig up. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL/Lite Review
Stephen Frost wrote: * Greg Smith (g...@2ndquadrant.com) wrote: I have to be honest and say that I'm not optimistic that this is possible or even a good idea to accomplish in the time remaining during this release. While I agree with you, I wish you hadn't brought it up. :) Mostly because I feel like it may discourage people from wanting to spend time on it due to desire to focus on things which are likely to make it into the next release. The reason I mentioned it is that I was getting a general feeling that the community at large was going to view not getting the patch into 8.5 as a final straw for working on it. I wanted to be clear that the scope of doing this right may extend beyond that, but that shouldn't be a reason to give up on it. I think KaiGai's comments about how it took 3 years to get SELinux similarly integrated into the Linux core rather then shipping as an add-on is encouraging, in that the way and scope of how we're struggling with this topic is not something we should consider extraordinary and therefore a failing. This is not an easy thing to do for anyone who tries it. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.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] SE-PostgreSQL/Lite Review
On Thu, Dec 10, 2009 at 10:39 PM, Stephen Frost sfr...@snowman.net wrote: Let's start by taking the patch I reviewed and splitting up security/access_control.c along object lines. Of course, the individual security/object_ac.c files would only include the .h's that are necessary. This would be a set of much smaller and much more managable files which only know about what they should know about- the object type they're responsible for. Good idea. Clearly, code comments also need to be reviewed and issues with them addressed. I'm also not a fan of the skip permissions check arguments, which are there specifically to address cascade deletions, which is a requirment of our PG security model. I'd love to see a better solution and am open to suggestions or thoughts about what one would be. I know one of KaiGai's concerns in this area was performance, butas we often do for PG, perhaps we should consider that second and first consider what it would look like if we ignored performance concerns. This would change skip permissions check to what object is being deleted, and am I a sub-object of that?. I don't feel like I've explained that well enough, perhaps someone else could come up with another solution, or maybe figure out a better way to describe what I'm trying to get with this. I don't know the right solution to this either but I'm glad you're thinking about it. Regarding the special-purpose shims- I feel there should be a way for us to handle them better. This might be a good use-case for column-level privileges in pg_catalog. That's pure speculation at the moment tho, I havn't re-looked at those shims lately to see if that even makes sense. I don't like them either though, for what it's worth. I am not sure if I fully understand either the problem or your proposed solution, but it seems to me that permissions checking needs to be forcibly crammed into a fixed number of buckets. In other words, for, say, databases, there should be a finite list of objects that can be performed on databases: create, drop, connect, etc. Any permissions question that comes up has to be asked in terms of one of those operations. So if somebody writes code, in core or contrib, that displays the size of the database, it has to key off the same permissions as one of those pre-existing categories. It doesn't get to invent rules specific to that case from scratch. (Humerous interlude: I worked on a project written in C++ many years ago where there were these security context objects, and all user-visible interfaces had to check with the security context before allowing any privileged operation, using the may_i() method. By convention, variables of the security context type were always named mother, thus mother-may_i(whatever)...) [...snip...] One comment I have in general about this process is that I think it would enormously reduce the level of pain associated with making these kinds of changes if we could get patches that were not full of minor issues that need to be cleaned up (like comments not properly adjusted, spelling/grammar errors, formatting inconsistent with the rest of the code base, poor English). I can't speak for anyone else, but it seems to me that asking a committer to fix all of that stuff on top of substantive review of the patch is asking a lot. I realize that this is difficult for non-native speakers of English and a lot of work even for those who are fluent in the language, but it is part of our project culture and style to do these kinds of things right and I certainly don't want to be the one who lowers our standards in this area. For a small patch, it's not so bad to have to fix these things (though it's certainly nicer not to need to) but for a patch of five or ten thousand lines, it's a LOT of work. ...Robert -- 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] SE-PostgreSQL Specifications
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote: David Fetter wrote: On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote: Just generally, access control is a great way to describe what's actually happening here. That people conflate access control with security has resulted in a number of disasters :P My concern is access_control_ is a bit long for prefixes, but ac_ is too short to represent what it is doing. pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we use in a number of other places, and has 'ac' in it.. Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost sfr...@snowman.net writes: * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: My concern is access_control_ is a bit long for prefixes, but ac_ is too short to represent what it is doing. pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we use in a number of other places, and has 'ac' in it.. I don't see anything wrong with ac_. Short is good, and there isn't any other concept in the PG internals that it would conflict with. If there were, pg_ac_ would surely not help to disambiguate. regards, tom lane -- 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] SE-PostgreSQL Specifications
* Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: My concern is access_control_ is a bit long for prefixes, but ac_ is too short to represent what it is doing. pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we use in a number of other places, and has 'ac' in it.. I don't see anything wrong with ac_. Short is good, and there isn't any other concept in the PG internals that it would conflict with. If there were, pg_ac_ would surely not help to disambiguate. Works for me. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: My concern is access_control_ is a bit long for prefixes, but ac_ is too short to represent what it is doing. pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we use in a number of other places, and has 'ac' in it.. I don't see anything wrong with ac_. Short is good, and there isn't any other concept in the PG internals that it would conflict with. If there were, pg_ac_ would surely not help to disambiguate. Works for me. OK, I'll go on with the ac_ prefix. -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
Greg Williamson wrote: KaiGai -- I was pulled away from any work on this for a few days ... what can I do to help, if anything ? (Keeping in mind that my knowledge of the internals of postgres is, alas, minimal.) ... I had a quick look at this new page and want to take another, more careful, look. I got a few reasonable sugegstions at the last week. The one is it is important to provide a design specification from the viewpoint of developers to make clear what features are provided by SE-PostgreSQL, and it will be a good source for the official documentation for users. The other is a suggestion corresponding to the way to implement it. Its conclusion was to inject an abstraction layer to support multiple security models at first. I guess Robert concerned about my English quality in the documentation patch contained in the proposed patch set at first. In same time, lack of design specification was pointed out. It also should be provided prior to the patch to make clear what is identical to/different from the native database privilege mechanism. Both of them are documentations. But these have their own purpose, target and style to be required. It might be a causion of the confusion. In my current opinion, we should have a discussion corresponding to the design specifications and internals, and implement it prior to the user documentation. So, I would like you to give me the time to conclude the design specifications and to implement patches for the next commit fest. The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge a certain minimalism at first to prove that the concept works and doesn't damage the core functionality at all when it is not used (fairly straight forward). Eventually rough measures of the performance hit when it is used will be useful, but users will expect something of a slow-down, I suspect, in exchange foe the greater security. Are you talking about what the user documentation should include, aren't you? Indeed, I also think these items should be introduced. To that end, I am wondering if there is test data yet designed ? Are there prescribed tests (I remember seeing some but they seem to be buried in months/threads that I have not yet re-dicsovered) ? I have some experience doing QA and could perhaps also help in these, a little. I also provided a patch for the testcases of SE-PostgreSQL. For example: http://code.google.com/p/sepgsql/source/browse/tags/sepgsql/src/test/sepgsql Thanks, And let me add, I am in awe of your efforts on this ! G - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: Stephen Frost sfr...@snowman.net Cc: KaiGai Kohei kai...@kaigai.gr.jp; Robert Haas robertmh...@gmail.com; pgsql-hackers@postgresql.org; Greg Williamson gwilliamso...@yahoo.com; Sam Mason s...@samason.me.uk; Joshua Brindle met...@manicmethod.com Sent: Monday, August 3, 2009 12:09:45 AM Subject: Re: [HACKERS] SE-PostgreSQL Specifications Stephen Frost wrote: I think what I should do on the next is ... - To check up whether it is really possible to implement SELinux's model. - To describe the list of the security functions in the new abstraction layer. - To discuss the list of permission at: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls That sounds like a good approach. As we define the security functions to go into the abstraction layer, I would also say we should identify the exact pieces of existing code which are going to move. I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction In my current impression, it indeed requires a few kilo lines of changes, but it is not impossible scale. I now plans to submit two patches for the next commit fest. The one is implementation of the abstraction layer. The other is basic implementation of the SE-PostgreSQL. So, I would like to fix external specification at least. The specifications for developer notes definitions of permissions: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development As Robert suggested before, I plans to support access controls on the following database objects and permissions at the first stage. * databases * schemas * tables * columns * sequences * functions * tablespaces Do you have any comment for the directions? Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
2009/8/3 KaiGai Kohei kai...@ak.jp.nec.com: I now plans to submit two patches for the next commit fest. The one is implementation of the abstraction layer. The other is basic implementation of the SE-PostgreSQL. Is this a good idea, or would it be better to focus on the aclcheck stuff (which is what I understand you to mean here by abstraction layer) first? You will be much happier getting one patch committed than two patches not committed... getting two patches of this size in one CommitFest seems very unlikely, and I worry that the SE-PostgreSQL patch will distract your time and reviewing time from the aclcheck refactoring that must get done first, and well. ...Robert -- 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] SE-PostgreSQL Specifications
Robert Haas wrote: 2009/8/3 KaiGai Kohei kai...@ak.jp.nec.com: I now plans to submit two patches for the next commit fest. The one is implementation of the abstraction layer. The other is basic implementation of the SE-PostgreSQL. Is this a good idea, or would it be better to focus on the aclcheck stuff (which is what I understand you to mean here by abstraction layer) first? You will be much happier getting one patch committed than two patches not committed... getting two patches of this size in one CommitFest seems very unlikely, and I worry that the SE-PostgreSQL patch will distract your time and reviewing time from the aclcheck refactoring that must get done first, and well. Needless to say, the security abstraction layer shall have higher priority than SE-PostgreSQL which depends on the layer. If we can focus on the SE-PostgreSQL feature in the third commit fest, it will be better than all the facilities from the scratch. (BTW, I also have a WIP patch to support largeobject permissions.) So, we may be able to modify the development plan as follows: * 2nd CommitFest (15-Sep) - security abstraction layer (- largeobject permission) * 3rd CommitFest (15-Nov) - basic functionality of SE-PostgreSQL * 4th CommitFest (15-Jan) - full functionality of SE-PostgreSQL (row-level controls, filesystem permissions, ...) Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: So, we may be able to modify the development plan as follows: * 2nd CommitFest (15-Sep) - security abstraction layer (- largeobject permission) * 3rd CommitFest (15-Nov) - basic functionality of SE-PostgreSQL * 4th CommitFest (15-Jan) - full functionality of SE-PostgreSQL (row-level controls, filesystem permissions, ...) Not to throw water on this right from the get-go, but I think getting the security abstraction and basic SE-PostgreSQL functionality (based on existing PG permissions) into 8.5 will be enough of a stretch. row-level security needs to be implement in PG proper first, before we can add the SE-PG hooks for it. That's going to be a serious amount of work by itself, and is something which is extremely unlikely to make sense to commit that late in the cycle. Let's focus on improving aclchk.c to the point where SE-PG can be easily added without dropping hooks all over the place. If we can get that into 8.5 it will be a huge success. We can then work on row-level permissions for 8.6, first as a PG-native feature, and then with SE-PG hooks. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost wrote: KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: So, we may be able to modify the development plan as follows: * 2nd CommitFest (15-Sep) - security abstraction layer (- largeobject permission) * 3rd CommitFest (15-Nov) - basic functionality of SE-PostgreSQL * 4th CommitFest (15-Jan) - full functionality of SE-PostgreSQL (row-level controls, filesystem permissions, ...) Not to throw water on this right from the get-go, but I think getting the security abstraction and basic SE-PostgreSQL functionality (based on existing PG permissions) into 8.5 will be enough of a stretch. row-level security needs to be implement in PG proper first, before we can add the SE-PG hooks for it. That's going to be a serious amount of work by itself, and is something which is extremely unlikely to make sense to commit that late in the cycle. It seems to me it is a bit early to conclude what feature will be included into 8.5 and what feature is not so. The above plan is a very rough sketch. Anyway, what I would like to say is I can agree to focus on the security abstraction layer earlier than SE-PostgreSQL feature. -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction I'm not really a huge fan of 'security_' as a prefix for these functions, but I don't have a better suggestion right now. The initial abstraction patch shouldn't include the security context pieces. I realize that will be needed eventually, but the patch to do the abstraction and to formally move permissions checking to aclchk.c needs to stand alone. I'm also not sure that the API of having the security context be returned as a Datum makes sense.. Doesn't security_table_permissions() need to know if the query is an UPDATE or an INSERT? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
On Mon, Aug 3, 2009 at 10:19 PM, Stephen Frostsfr...@snowman.net wrote: KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: So, we may be able to modify the development plan as follows: * 2nd CommitFest (15-Sep) - security abstraction layer (- largeobject permission) * 3rd CommitFest (15-Nov) - basic functionality of SE-PostgreSQL * 4th CommitFest (15-Jan) - full functionality of SE-PostgreSQL (row-level controls, filesystem permissions, ...) Not to throw water on this right from the get-go, but I think getting the security abstraction and basic SE-PostgreSQL functionality (based on existing PG permissions) into 8.5 will be enough of a stretch. row-level security needs to be implement in PG proper first, before we can add the SE-PG hooks for it. That's going to be a serious amount of work by itself, and is something which is extremely unlikely to make sense to commit that late in the cycle. +1. Optimism is good, realism is better. Let's focus on improving aclchk.c to the point where SE-PG can be easily added without dropping hooks all over the place. If we can get that into 8.5 it will be a huge success. We can then work on row-level permissions for 8.6, first as a PG-native feature, and then with SE-PG hooks. Row-level security is going to be a very, very difficult feature to implement properly. A lot of thought is needed here to design something good. ...Robert -- 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] SE-PostgreSQL Specifications
Stephen Frost wrote: KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction I'm not really a huge fan of 'security_' as a prefix for these functions, but I don't have a better suggestion right now. If so, 'pgsec_' (PostGresql SECutiry) instead? The initial abstraction patch shouldn't include the security context pieces. I realize that will be needed eventually, but the patch to do the abstraction and to formally move permissions checking to aclchk.c needs to stand alone. I'm also not sure that the API of having the security context be returned as a Datum makes sense.. OK, I'll add pieces corresponding to the security context on the second patch (SE-PostgreSQL patch). Doesn't security_table_permissions() need to know if the query is an UPDATE or an INSERT? Either ACL_UPDATE or ACL_INSERT should be set on the required_perms. Both of them are never set in same time. Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote: KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction I'm not really a huge fan of 'security_' as a prefix for these functions, but I don't have a better suggestion right now. Just generally, access control is a great way to describe what's actually happening here. That people conflate access control with security has resulted in a number of disasters :P Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] SE-PostgreSQL Specifications
David Fetter wrote: On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote: KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction I'm not really a huge fan of 'security_' as a prefix for these functions, but I don't have a better suggestion right now. Just generally, access control is a great way to describe what's actually happening here. That people conflate access control with security has resulted in a number of disasters :P My concern is access_control_ is a bit long for prefixes, but ac_ is too short to represent what it is doing. -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
Stephen Frost wrote: I think what I should do on the next is ... - To check up whether it is really possible to implement SELinux's model. - To describe the list of the security functions in the new abstraction layer. - To discuss the list of permission at: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls That sounds like a good approach. As we define the security functions to go into the abstraction layer, I would also say we should identify the exact pieces of existing code which are going to move. I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction In my current impression, it indeed requires a few kilo lines of changes, but it is not impossible scale. I now plans to submit two patches for the next commit fest. The one is implementation of the abstraction layer. The other is basic implementation of the SE-PostgreSQL. So, I would like to fix external specification at least. The specifications for developer notes definitions of permissions: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development As Robert suggested before, I plans to support access controls on the following database objects and permissions at the first stage. * databases * schemas * tables * columns * sequences * functions * tablespaces Do you have any comment for the directions? Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
KaiGai -- I was pulled away from any work on this for a few days ... what can I do to help, if anything ? (Keeping in mind that my knowledge of the internals of postgres is, alas, minimal.) ... I had a quick look at this new page and want to take another, more careful, look. The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge a certain minimalism at first to prove that the concept works and doesn't damage the core functionality at all when it is not used (fairly straight forward). Eventually rough measures of the performance hit when it is used will be useful, but users will expect something of a slow-down, I suspect, in exchange foe the greater security. To that end, I am wondering if there is test data yet designed ? Are there prescribed tests (I remember seeing some but they seem to be buried in months/threads that I have not yet re-dicsovered) ? I have some experience doing QA and could perhaps also help in these, a little. And let me add, I am in awe of your efforts on this ! G - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: Stephen Frost sfr...@snowman.net Cc: KaiGai Kohei kai...@kaigai.gr.jp; Robert Haas robertmh...@gmail.com; pgsql-hackers@postgresql.org; Greg Williamson gwilliamso...@yahoo.com; Sam Mason s...@samason.me.uk; Joshua Brindle met...@manicmethod.com Sent: Monday, August 3, 2009 12:09:45 AM Subject: Re: [HACKERS] SE-PostgreSQL Specifications Stephen Frost wrote: I think what I should do on the next is ... - To check up whether it is really possible to implement SELinux's model. - To describe the list of the security functions in the new abstraction layer. - To discuss the list of permission at: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls That sounds like a good approach. As we define the security functions to go into the abstraction layer, I would also say we should identify the exact pieces of existing code which are going to move. I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction In my current impression, it indeed requires a few kilo lines of changes, but it is not impossible scale. I now plans to submit two patches for the next commit fest. The one is implementation of the abstraction layer. The other is basic implementation of the SE-PostgreSQL. So, I would like to fix external specification at least. The specifications for developer notes definitions of permissions: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development As Robert suggested before, I plans to support access controls on the following database objects and permissions at the first stage. * databases * schemas * tables * columns * sequences * functions * tablespaces Do you have any comment for the directions? Thanks, -- OSS Platform Development Division, NEC 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 -- 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] SE-PostgreSQL Specifications
KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: Please note that all we need to focus on is not pg_xxx_aclcheck() routines in other words. I agree, there may be other things which need to move to aclchk.c, and that routine is a good example of something which would be appropriate to move, abstract, and provide an SELinux hook for, in aclchk.c. The example is not dramatically different from the others, indeed. But, this code implicitly assume the database superuser can do anyhting, so the necessary checks are omitted from the code (because they always return allowed). Yes, I realize that's a problem. I don't know that it's a problem which has to be addressed in the first round, but I do believe we will get there. I think what I should do on the next is ... - To check up whether it is really possible to implement SELinux's model. - To describe the list of the security functions in the new abstraction layer. - To discuss the list of permission at: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls That sounds like a good approach. As we define the security functions to go into the abstraction layer, I would also say we should identify the exact pieces of existing code which are going to move. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
As Peter Eisentraut pointed out, we are not on the phase to discuss about user documentations yet. It is a reasonable idea to discuss correct specifications of SE-PostgreSQL from the viewpoint of the developers. Then, it will the a good source for the upcoming user docs. For the recent a few days, I've worked to write and edit the specification (partially copied from the draft of user documentation) for the development purpose. http://wiki.postgresql.org/wiki/SEPostgreSQL_Development I would like to have a discussion for its design specifications and make clear anything unclear for pgsql folks (including the quality of English). Because this wikipage intends to provide the specifications from the viewpoint of developers, it describes features more detailed than the user visible documentation. I intended to describe the features correctly, but it does not mean perfect, needless to say. Please feel free to ask / point out me, if something unclear or not-easy understandable. Thanks, KaiGai Kohei wrote: Here is the initial draft of SE-PostgreSQL specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft I've described it from the scratch again with paying attention for the people knowing nothing about SELinux. In some points, it uses comparison between the database privilege mechanism and SE-PostgreSQL for easy understanding. Please point out, if ... - Its composition can be improved. - Here is not enough introductions for what user wants to know. - Here is too much explanations, more brief one will be available. - Here is not easy understandable for database folks. - Here is not enough English quality. - And so on... In addition, I would like to fix its specifications during the discussion. Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: For the recent a few days, I've worked to write and edit the specification (partially copied from the draft of user documentation) for the development purpose. http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Thanks for doing this. I've taken a quick glance through it and will review it more later today. The next step, I believe, is to document the changes which need to be made to PG, at a high level, to support this specification. I think the initial goal should be to make changes mainly to aclchk.c to add the SELinux hooks. I'd like to hear from some committers about this idea: I think we should also be looking to move more of the permissions checking which is done in other parts of the code (eg: ATExecChangeOwner()) into aclchk.c, which is where I would argue it belongs. Doing so will make it much easier to add other hooks, should the need arise, and would minimize the amount of code 'touched' to add SELinux support. Strategy for code changes: Patch #1: Move permissions checks currently implemented in other parts of the code (eg: tablecmds.c:ATExecChangeOwner()) into aclchk.c. Patch #2: Change the aclchk.c function APIs, if necessary, to add additional information required for SELinux (eg: the 'old' owner). Patch #3: Add SELinux hooks into aclchk.c functions. This initial round, again, should focus on just those controls/permissions which PostgreSQL already supports. At this time, do not stress over finding every if(superuser()) and moving it to aclchk.c. Let's deal with the clear situations, such as tablecmds.c lines 6322-6342 (that entire block, including the if(!superuser()), should be ripped out and made a function in aclchk.c which is called with necessary args). We can go back and clean up the other places where we have explicit superuser() checks later, if necessary. I've finally had a chance to look through the last set of proposed patches some, and I've noticed some other issues that need to be addressed: - Let's avoid the changes to heaptuple.c for now. That's really for much later down the road when we implement row-level security. - I would expect the dependency system to be used to handle deleting things from pg_security, etc, when an object has been deleted (eg: a table was dropped). - Conversly, when new entries need to be added to pg_security, they should be done at the same level as other items being added to the catalog. In places like createdb(), where it's all one big function, I would recommend splitting out the existing catalog update into a separate function, which then makes it much clearer that the code is doing: update pg_database table, update pg_security table, update pg_dependency table. That should be done as a separate patch, of course. Remember, we're trying to make small incremental changes that make sense by themselves but at the same time will reduce the effort required to add SELinux later. - In terms of cacheing the results, is there any way we could use SysCache for this? And just handle the cacheing in the hooks, etc, from aclchk.c? I dislike having the security labels added to every tuple until we actually implement row level security. It adds alot of unnecessary complexity to the initial implementation. Note that I'm referring to the results from the kernel/syscalls, I realize you're using SysCache properly for the entries in pg_security already, and that's good. Guess that's a start on the implementation design, which I feel is the next step after specification. Perhaps you could start a wiki page on it which includes my comments? I'm in meetings for the next couple of hours, but will resume looking at this after lunch, US/Eastern time. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost wrote: KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: For the recent a few days, I've worked to write and edit the specification (partially copied from the draft of user documentation) for the development purpose. http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Thanks for doing this. I've taken a quick glance through it and will review it more later today. The next step, I believe, is to document the changes which need to be made to PG, at a high level, to support this specification. Thanks for your help. I also think it is necessary to describe what changes are needed on the core pgsql except for security routines. It is just an example: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#security_hooks_.28example.29 I believe such kind of specifications are necessary at the next. I think the initial goal should be to make changes mainly to aclchk.c to add the SELinux hooks. I'd like to hear from some committers about this idea: I think we should also be looking to move more of the permissions checking which is done in other parts of the code (eg: ATExecChangeOwner()) into aclchk.c, which is where I would argue it belongs. Doing so will make it much easier to add other hooks, should the need arise, and would minimize the amount of code 'touched' to add SELinux support. Strategy for code changes: Patch #1: Move permissions checks currently implemented in other parts of the code (eg: tablecmds.c:ATExecChangeOwner()) into aclchk.c. Patch #2: Change the aclchk.c function APIs, if necessary, to add additional information required for SELinux (eg: the 'old' owner). Patch #3: Add SELinux hooks into aclchk.c functions. Thanks for your idea. However, it seems to me this approach eventually requires bigger changeset than what the current security hooks doing. In addition, it cannot solve the differences in behavior due to the security model on which they stand. For example, when we create a new table, the native database privilege mechanism checks its permission on the schema object which the new table blongs to. On the other hand, SELinux requires to check db_table:{create} permission on the newly created table itself. In my understanding, the purpose of the design specification is to make clear for database folks what the security hooks doin and why the security hooks are deployed here. Linux kernel is a good case in success. Needless to say, most of kernel developer are not security experts. But they defined an explicit specification of the security hooks called LSM, and put these hooks on the strategic points in the kernel. (The very long source code comments describes what is the purpose of this security hook, what arguments should be given and so on for each security hooks.) This initial round, again, should focus on just those controls/permissions which PostgreSQL already supports. At this time, do not stress over finding every if(superuser()) and moving it to aclchk.c. Let's deal with the clear situations, such as tablecmds.c lines 6322-6342 (that entire block, including the if(!superuser()), should be ripped out and made a function in aclchk.c which is called with necessary args). We can go back and clean up the other places where we have explicit superuser() checks later, if necessary. At least, it works correctly as far as the native database privilege mechanism. If the specification of the security hooks is clear, I think the following manner is better than modifying DAC mechanism. if (!superuser()) { if (pg_xxx_aclcheck() != ACLCHECK_OK) aclcheck_error(); } + sepgsqlCheck(); I've finally had a chance to look through the last set of proposed patches some, and I've noticed some other issues that need to be addressed: - Let's avoid the changes to heaptuple.c for now. That's really for much later down the road when we implement row-level security. Yes, I can agree to postpone pg_security and corresponding facilities until row-level security. - I would expect the dependency system to be used to handle deleting things from pg_security, etc, when an object has been deleted (eg: a table was dropped). In the patch for v8.4.x series (with fullset functionality), it is already implemented. Any entries within pg_security referenced by the dropped table is reclaimed, when we drop a table. The matter of orphan entries are already solved. - Conversly, when new entries need to be added to pg_security, they should be done at the same level as other items being added to the catalog. In places like createdb(), where it's all one big function, I would recommend splitting out the existing catalog update into a separate function, which then makes it much clearer that the code is doing: update pg_database table, update pg_security table, update pg_dependency table. That should be
Re: [HACKERS] SE-PostgreSQL Specifications
KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: Stephen Frost wrote: Strategy for code changes: Patch #1: Move permissions checks currently implemented in other parts of the code (eg: tablecmds.c:ATExecChangeOwner()) into aclchk.c. Patch #2: Change the aclchk.c function APIs, if necessary, to add additional information required for SELinux (eg: the 'old' owner). Patch #3: Add SELinux hooks into aclchk.c functions. Thanks for your idea. However, it seems to me this approach eventually requires bigger changeset than what the current security hooks doing. Yes, it almost certainly will. However, this is really the approach that I think we need to take. I think what we're beginning to understand, collectivly, is something that some of the committers, etc, have been saying all along- implementing SELinux in PG requires alot more changes to PG than just sprinkling hooks all over the code. This is because we want to do it right, for PG, and for our users. What this means is that we need to improve the PG code first. Then, when we're happy with those changes, we can add the SELinux hooks and be comfortable that they will operate correctly, do what they're intended to, and also allow us to extend the system further for the next big privileges thing, if that happens some day. In addition, it cannot solve the differences in behavior due to the security model on which they stand. For example, when we create a new table, the native database privilege mechanism checks its permission on the schema object which the new table blongs to. On the other hand, SELinux requires to check db_table:{create} permission on the newly created table itself. That's fine. We implement a function in aclchk.c which is essentially pg_createTablePriv(schema,newtable). The logic for doing the check is moved out of tablecmds.c (or where ever) and into that function. We can then easily add to that function the SELinux hook. Is there some issue here which I'm not seeing? If so, can you please clarify? Also, I don't see db_table:{create} in the documentation anywhere. There is a db_schema:{add_name}, is that what you're referring to? How would you check the permissions on an object (and how or why would they be different than the default, unless that's also being handled at the creation time) which is in the process of being created? In my understanding, the purpose of the design specification is to make clear for database folks what the security hooks doin and why the security hooks are deployed here. I don't think we're going to have much buy-in or success sprinkling these hooks all over the PG source code. It would make maintenance a real problem for the PG folks and for those of us trying to work with SE. The SELinux hooks really need to be folded into PG's existing authentication system, and if that system needs to be improved or expanded, then that's what it requires. Linux kernel is a good case in success. Needless to say, most of kernel developer are not security experts. But they defined an explicit specification of the security hooks called LSM, and put these hooks on the strategic points in the kernel. (The very long source code comments describes what is the purpose of this security hook, what arguments should be given and so on for each security hooks.) Right, we have a number of these already, and they are represented by the aclchk.c functions. The problem that SELinux points out is that we've not been consistant with having aclchk.c do the permissions checking. Specifically on the simple stuff where we currently require owner rights. What we need to do is improve PG by pulling those checks out of the areas they are, spread all around the code, and consolidating them into aclchk.c (or a new file if that is deisred). We're not going to get anywhere by trying to add on more hooks all over the code. This initial round, again, should focus on just those controls/permissions which PostgreSQL already supports. At this time, do not stress over finding every if(superuser()) and moving it to aclchk.c. Let's deal with the clear situations, such as tablecmds.c lines 6322-6342 (that entire block, including the if(!superuser()), should be ripped out and made a function in aclchk.c which is called with necessary args). We can go back and clean up the other places where we have explicit superuser() checks later, if necessary. At least, it works correctly as far as the native database privilege mechanism. If the specification of the security hooks is clear, I think the following manner is better than modifying DAC mechanism. if (!superuser()) { if (pg_xxx_aclcheck() != ACLCHECK_OK) aclcheck_error(); } + sepgsqlCheck(); Again, this would mean dropping sepgsql() calls all over the code, because we don't currently have all of these permission checks
Re: [HACKERS] SE-PostgreSQL Specifications
On Fri, Jul 31, 2009 at 5:13 PM, Stephen Frostsfr...@snowman.net wrote: KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: Stephen Frost wrote: Strategy for code changes: Patch #1: Move permissions checks currently implemented in other parts of the code (eg: tablecmds.c:ATExecChangeOwner()) into aclchk.c. Patch #2: Change the aclchk.c function APIs, if necessary, to add additional information required for SELinux (eg: the 'old' owner). Patch #3: Add SELinux hooks into aclchk.c functions. Thanks for your idea. However, it seems to me this approach eventually requires bigger changeset than what the current security hooks doing. Yes, it almost certainly will. However, this is really the approach that I think we need to take. I think what we're beginning to understand, collectivly, is something that some of the committers, etc, have been saying all along- implementing SELinux in PG requires alot more changes to PG than just sprinkling hooks all over the code. This is because we want to do it right, for PG, and for our users. What this means is that we need to improve the PG code first. Then, when we're happy with those changes, we can add the SELinux hooks and be comfortable that they will operate correctly, do what they're intended to, and also allow us to extend the system further for the next big privileges thing, if that happens some day. In addition, it cannot solve the differences in behavior due to the security model on which they stand. For example, when we create a new table, the native database privilege mechanism checks its permission on the schema object which the new table blongs to. On the other hand, SELinux requires to check db_table:{create} permission on the newly created table itself. That's fine. We implement a function in aclchk.c which is essentially pg_createTablePriv(schema,newtable). The logic for doing the check is moved out of tablecmds.c (or where ever) and into that function. We can then easily add to that function the SELinux hook. Is there some issue here which I'm not seeing? If so, can you please clarify? Also, I don't see db_table:{create} in the documentation anywhere. There is a db_schema:{add_name}, is that what you're referring to? How would you check the permissions on an object (and how or why would they be different than the default, unless that's also being handled at the creation time) which is in the process of being created? In my understanding, the purpose of the design specification is to make clear for database folks what the security hooks doin and why the security hooks are deployed here. I don't think we're going to have much buy-in or success sprinkling these hooks all over the PG source code. It would make maintenance a real problem for the PG folks and for those of us trying to work with SE. The SELinux hooks really need to be folded into PG's existing authentication system, and if that system needs to be improved or expanded, then that's what it requires. Linux kernel is a good case in success. Needless to say, most of kernel developer are not security experts. But they defined an explicit specification of the security hooks called LSM, and put these hooks on the strategic points in the kernel. (The very long source code comments describes what is the purpose of this security hook, what arguments should be given and so on for each security hooks.) Right, we have a number of these already, and they are represented by the aclchk.c functions. The problem that SELinux points out is that we've not been consistant with having aclchk.c do the permissions checking. Specifically on the simple stuff where we currently require owner rights. What we need to do is improve PG by pulling those checks out of the areas they are, spread all around the code, and consolidating them into aclchk.c (or a new file if that is deisred). We're not going to get anywhere by trying to add on more hooks all over the code. This initial round, again, should focus on just those controls/permissions which PostgreSQL already supports. At this time, do not stress over finding every if(superuser()) and moving it to aclchk.c. Let's deal with the clear situations, such as tablecmds.c lines 6322-6342 (that entire block, including the if(!superuser()), should be ripped out and made a function in aclchk.c which is called with necessary args). We can go back and clean up the other places where we have explicit superuser() checks later, if necessary. At least, it works correctly as far as the native database privilege mechanism. If the specification of the security hooks is clear, I think the following manner is better than modifying DAC mechanism. if (!superuser()) { if (pg_xxx_aclcheck() != ACLCHECK_OK) aclcheck_error(); } + sepgsqlCheck(); Again, this would mean
Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost wrote: KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: Stephen Frost wrote: Strategy for code changes: Patch #1: Move permissions checks currently implemented in other parts of the code (eg: tablecmds.c:ATExecChangeOwner()) into aclchk.c. Patch #2: Change the aclchk.c function APIs, if necessary, to add additional information required for SELinux (eg: the 'old' owner). Patch #3: Add SELinux hooks into aclchk.c functions. Thanks for your idea. However, it seems to me this approach eventually requires bigger changeset than what the current security hooks doing. Yes, it almost certainly will. However, this is really the approach that I think we need to take. I think what we're beginning to understand, collectivly, is something that some of the committers, etc, have been saying all along- implementing SELinux in PG requires alot more changes to PG than just sprinkling hooks all over the code. This is because we want to do it right, for PG, and for our users. What this means is that we need to improve the PG code first. Then, when we're happy with those changes, we can add the SELinux hooks and be comfortable that they will operate correctly, do what they're intended to, and also allow us to extend the system further for the next big privileges thing, if that happens some day. When I scraped the idea of PGACE framework, someone (IIRC, Robert Haas) asked me whether it is possible to implement the native database privilege mechanism on the PGACE, or not. It seems to me your suggestion is similar to the idea of PGACE framework. But, note that it does not mean I criticize your idea. Let's consider the matter more using a few examples. Example 1) ALTER TABLE xxx The native database privilege mechanism checks the ownership of the target table to control the ALTER TABLE. On the other hand, SE-PgSQL checks the db_table:{setattr} permission on the target table to control the ALTER TABLE. I believe you can notice both of checks have same purpose but differences are on the criterions. It is the way to make their decisions in other word. The pg_xxx_aclcheck() interfaces provide the way to make its access control decision. The core PG code calls pg_xxx_aclcheck() to achieve its purpose which is to apply access controls on ALTER TABLE. Accordingly, if we avoid to put SE-PgSQL's security hooks on the tablecmd.c directly, what we should do is to inject an abstraction layer between tablecmd.c and aclchk.c. For example: void pg_security_alter_table(Oid relid) { if (!pg_class_ownercheck(relid, GetUserId()) aclcheck_error(...); if (!sepgsqlCheckTableSetattr(relid)) selinux_error(...); } Example 2) DROP TABLE xxx The native database privilege mechanism also checks the ownership of the target table to be dropped (except for cascaded deletion). However, SELinux want to apply db_table:{drop} permission, instead of db_table:{setattr}. It is obvious that pg_class_ownercheck() cannot be a caller of the SELinux's security hook. It should be: void pg_security_drop_table(Oid relid) { if (!pg_class_ownercheck(relid, GetUserId()) ackcheck_error(...); if (!sepgsqlCheckTableDrop(relid)) selinux_error(...); } Example 3) ACL_EXECUTE The ACL_EXECUTE permission is checked on the runtime and setup time. The meaning of runtime is obvious. It should be checked when user's query tries to execute a function. For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to create a new conversion. It is available for all the users. However, SELinux want to apply different permissions for runtime and installation time. On the runtime of the function, it applies db_procedure:{execute}. On the installation time, it applies db_procedure:{install}. Because a user defined function is installed as a part of system internals, it is available for every users. SELinux considers it is fundamentally different from a user can run a function defined myself. Because the topic is a bit abstract, it is not clear whether I can introduce what I want to say correctly, or not. Please feel free to ask me, if something unclear. In addition, it cannot solve the differences in behavior due to the security model on which they stand. For example, when we create a new table, the native database privilege mechanism checks its permission on the schema object which the new table blongs to. On the other hand, SELinux requires to check db_table:{create} permission on the newly created table itself. That's fine. We implement a function in aclchk.c which is essentially pg_createTablePriv(schema,newtable). The logic for doing the check is moved out of tablecmds.c (or where ever) and into that function. We can then easily add to that function the SELinux hook. Is there some issue here which I'm not seeing? If so, can you please clarify?
Re: [HACKERS] SE-PostgreSQL Specifications
Robert Haas wrote: FWIW, pretty much +1 from me on everything in here; I think this is definitely going in the right direction. It's not the size of the patches that matter; it's the complexity and difficulty of verifying that they don't break anything. And it's not cumulative: three easy patches are better than one hard one, as long as they're really self-contained. The idea of restructuring the aclcheck mechanism to support sepgsql is, IMO, brilliant. As I noted in the reply to Stephen Frost, what should be controled (e.g, ALTER TABLE) and how to check it (e.g, ownership based control) are different things. If we go on the direction to restructure the current aclcheck mechanism and to integrate entry points of security features into a single file, I really really want an implementation independent layer which focuses on access controls. 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] SE-PostgreSQL Specifications
KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: It seems to me your suggestion is similar to the idea of PGACE framework. It is, but it's being done as incremental changes to the existing structures, and working with them, instead of ignoring that they exist. Let's consider the matter more using a few examples. Example 1) ALTER TABLE xxx The native database privilege mechanism checks the ownership of the target table to control the ALTER TABLE. On the other hand, SE-PgSQL checks the db_table:{setattr} permission on the target table to control the ALTER TABLE. I believe you can notice both of checks have same purpose but differences are on the criterions. It is the way to make their decisions in other word. The pg_xxx_aclcheck() interfaces provide the way to make its access control decision. The core PG code calls pg_xxx_aclcheck() to achieve its purpose which is to apply access controls on ALTER TABLE. Accordingly, if we avoid to put SE-PgSQL's security hooks on the tablecmd.c directly, what we should do is to inject an abstraction layer between tablecmd.c and aclchk.c. For example: void pg_security_alter_table(Oid relid) { if (!pg_class_ownercheck(relid, GetUserId()) aclcheck_error(...); if (!sepgsqlCheckTableSetattr(relid)) selinux_error(...); } Right, something along these lines, where the function lives in aclchk.c and is part of its overall API. This also shows pretty clearly how, if we needed to add other hooks into the permissions for this operation, we could do so. It also shows how we could *first* build: void pg_security_alter_table(Oid relid) { if (!pg_class_ownercheck(relid, GetUserId()) aclcheck_error(...); } and make the corresponding changes in tablecmds.c, etc, and do that as a separate patch. Once that's done, we can review it, test it, etc, as just an incremental change to PG. This should be much easier/faster to review as a patch as well, and to convince ourselves that we havn't broken PG's current security (which is an extremely critical thing). Additionally, when we then come back and add SELinux hooks, they will be done in an isolated area and be additions to a system which has been made to support such an extension. Example 2) DROP TABLE xxx The native database privilege mechanism also checks the ownership of the target table to be dropped (except for cascaded deletion). However, SELinux want to apply db_table:{drop} permission, instead of db_table:{setattr}. It is obvious that pg_class_ownercheck() cannot be a caller of the SELinux's security hook. It should be: void pg_security_drop_table(Oid relid) { if (!pg_class_ownercheck(relid, GetUserId()) ackcheck_error(...); if (!sepgsqlCheckTableDrop(relid)) selinux_error(...); } Right. Similar to above. Example 3) ACL_EXECUTE The ACL_EXECUTE permission is checked on the runtime and setup time. The meaning of runtime is obvious. It should be checked when user's query tries to execute a function. For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to create a new conversion. It is available for all the users. However, SELinux want to apply different permissions for runtime and installation time. On the runtime of the function, it applies db_procedure:{execute}. On the installation time, it applies db_procedure:{install}. Because a user defined function is installed as a part of system internals, it is available for every users. SELinux considers it is fundamentally different from a user can run a function defined myself. I'm not sure I follow how this is dramatically different from the other examples. We have checks in place in PG already at both runtime of the function (user has 'execute' privilege) and at creation time (functions are created in schemas, after all). If there are checks that PG doesn't do today but which SELinux wants, those can be added too.. But as we've discussed, that should be postponed until we get this initial structure in place to allow PG to be extensible in this way. Because the topic is a bit abstract, it is not clear whether I can introduce what I want to say correctly, or not. Please feel free to ask me, if something unclear. Yeah, I don't entirely get what you're trying to say here. Perhaps you could try and rephrase it? It is described at: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Common_object_behavior When we create a new table, SELinux's mode requires all the following permissions individually. - db_schema:{add_name}, because a table is created under a certain schema - db_table:{create} due to the common object behavior - db_column:{create} for each columns, due to the common object behavior Note that the newly created object does not exist when SE-PgSQL checks its db_xxx:{create} permission. Accordingly, it computes a default security
Re: [HACKERS] SE-PostgreSQL Specifications
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote: As I noted in the reply to Stephen Frost, what should be controled (e.g, ALTER TABLE) and how to check it (e.g, ownership based control) are different things. If we go on the direction to restructure the current aclcheck mechanism and to integrate entry points of security features into a single file, I really really want an implementation independent layer which focuses on access controls. I think that's what I'm advocating.. If, by that, you mean we should do it in a separate file from aclchk.c, I'm not against that. It would likely mean moving some things *from* aclchk.c into it, and then just using aclchk.c for helpers to support the PG permissions. I'm not sure which way would be easier to handle in terms of patch review, etc.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost wrote: For example: void pg_security_alter_table(Oid relid) { if (!pg_class_ownercheck(relid, GetUserId()) aclcheck_error(...); if (!sepgsqlCheckTableSetattr(relid)) selinux_error(...); } Right, something along these lines, where the function lives in aclchk.c and is part of its overall API. This also shows pretty clearly how, if we needed to add other hooks into the permissions for this operation, we could do so. It also shows how we could *first* build: void pg_security_alter_table(Oid relid) { if (!pg_class_ownercheck(relid, GetUserId()) aclcheck_error(...); } and make the corresponding changes in tablecmds.c, etc, and do that as a separate patch. Once that's done, we can review it, test it, etc, as just an incremental change to PG. This should be much easier/faster to review as a patch as well, and to convince ourselves that we havn't broken PG's current security (which is an extremely critical thing). Additionally, when we then come back and add SELinux hooks, they will be done in an isolated area and be additions to a system which has been made to support such an extension. Basically, I can agree this approach. However, it is necessary to consider the idea deeply whether it is really possible to implement the SELinux's model correctly, or not. For example, ExecCheckRTEPerms() checks permissions on DML statement. It allows users to access required table and columns, if he has appropriate permissions on the table OR all the columns in use. But SELinux requires the client needs to be allowed on the table AND all the columns in use. Please note that all we need to focus on is not pg_xxx_aclcheck() routines in other words. Example 3) ACL_EXECUTE The ACL_EXECUTE permission is checked on the runtime and setup time. The meaning of runtime is obvious. It should be checked when user's query tries to execute a function. For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to create a new conversion. It is available for all the users. However, SELinux want to apply different permissions for runtime and installation time. On the runtime of the function, it applies db_procedure:{execute}. On the installation time, it applies db_procedure:{install}. Because a user defined function is installed as a part of system internals, it is available for every users. SELinux considers it is fundamentally different from a user can run a function defined myself. I'm not sure I follow how this is dramatically different from the other examples. We have checks in place in PG already at both runtime of the function (user has 'execute' privilege) and at creation time (functions are created in schemas, after all). If there are checks that PG doesn't do today but which SELinux wants, those can be added too.. But as we've discussed, that should be postponed until we get this initial structure in place to allow PG to be extensible in this way. What I would like to say was how does the user defined function is used. (However, it is the issue corresponding to the security model, not where we should put the security hooks.) For example, type input/output handlers are invoked without permission checks on runtime. We never see an error due to the lack of permission to execute textout() function. The native privilege model assumes type input/output handlers can be trusted, because only superuser can set up own types. (In fact, DefineType() checks superuser() at the head.) So, rest of the routine does not check anything based on the assumption of the superuser. See the #ifdef NOT_USER ... #endif block in DefineType(). It looks like the native database privilege mechanism does not check such a permission, however, it implicitly assume ACL_EXECUTE permission is always allowed for superuser. Here, it seems to me ACL_EXECUTE has two different meanings here. The one is obvious. It is a privilege a certain user to execute a certain function in his query. The other is a privilege a certain user allows everyone to execute a certain a part of the system internal stuff (such as type input/output handlers). The example is not dramatically different from the others, indeed. But, this code implicitly assume the database superuser can do anyhting, so the necessary checks are omitted from the code (because they always return allowed). I think it is also necessary to follow these implicit permission check. As I mentioned above, if (enhanced) PG's access control mechanism can contain all the needed SELinux hooks, I can agree to put security hooks inside the PG's security. However, note that I have a legitimate reason that we cannot put SELinux hooks inside the *current* pg_xxx_aclcheck() routines, to implement the security model of SELinux correctly. Sure, and that's fine. I think the problem that you keep running into is this: You don't want to touch the PG code too much for
Re: [HACKERS] SE-PostgreSQL Specifications
Peter Eisentraut wrote: On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote: Peter Eisentraut wrote: On Sunday 26 July 2009 14:35:41 Sam Mason wrote: I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This is not supposed to be user documentation. It's supposed to be a feature specification that an implementation can be validated against. Hmm... What kind of descriptions are necessary for a feature specifications? It describes what the feature does and why. Currently, I guess the specification describes when/where the security hook should be invoked, what permission should be checked and what result should be returned for each security hooks. Is it correct? Or, do you expect any other stuffs? That is a pretty good start, but it's drifting into implementation details. Apart from that, user documentation is also necessary. If the specification should be described from completely different viewpoint, I'll provide it. Yes, user documentation will eventually also be necessary, and the original specification may be usable as a source for that. I'm just reacting to those who commented whether or not references should be added and what reference style the documentation uses. We're not there yet. The purpose of this document is to explain what the feature does, not to teach users to use the feature. For a couple of days, I have paid my efforts to provide the design specifications more than user documentations. (But a few sections are under construction.) http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Some of sections are copied from the SEPostgreSQL_Draft and edited, rest of sections are also revised to represent its feature and behavior more correctly. At the current moment, I can agree it is too early to discuss the style for user documentation. So, I would like to freeze the efforts to the user documentation for a while, and begin to discuss the design specification which focuses on developers. Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
I revised the SE-PostgreSQL Specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft - Put several external link to introduce something too detail for PostgreSQL documentations. - Paid attention not to use undefined terminology, such as security context, security policy and mandatory access controls. - Revised whole of the composition in the Brief overview section. - Put an example of security policy rule. - SECURITY_LABEL option was replaced by SECURITY_CONTEXT to avoid meaningless confusion. I believe it become better than previous revision. Thanks, KaiGai Kohei wrote: Sam Mason wrote: On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This will be somewhat of a break from normal PG documentation because so far everything has been self contained, it's chosen its own interpretation of the SQL standard and it needs to document that. SE-PG will be interacting with much more code from outside and showing which parts of these are PG specific vs. which parts are common to all SELinux seems important. If you try to document *everything* you're going to be writing for years and give the impression that everything is implemented in SE-PG. A dividing line needs to be drawn between what is PG specific and what is SELinux (why not SEL?). It also seems to me reasonable suggestion. However, a reasonable amount (which should be adjusted under discussions) of description should be self-contained. For example, security context is a formatted short string is not enough to understand why it is necessary and what is the purpose. As Robert suggested, a few example and definition of technical terms will help database folks to understand what it is, even if self-contained explanation is not comprehensive from viewpoint of security folks. Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
On Sunday 26 July 2009 14:35:41 Sam Mason wrote: I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This is not supposed to be user documentation. It's supposed to be a feature specification that an implementation can be validated against. -- 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] SE-PostgreSQL Specifications
Thanks for the updates. I might suggest a couple of small changes: a) a section that explains comments like This is not supported in the initial version -- do you mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ? If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB hackers would care if is it is not to be included. How much do these compromise the design, and if so, are there specific plans for implementing them ? b) something which explains the differences between SELinux and SEPostgreSQL on the one hand (for SE fans). You've done a good job of outlining the differences and similarities with the more standard ACL methods and that needs to be kept prominent so people with DB experience can see the differences. I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a very high level outline and so I'd be tempted to move all implementation details to another page -- basically everything from Installation on, with the exception of the overview of the dump issues, is (to my eye) a detail that doesn't need exposing (yet). I'll send mail when I have a few paragraphs done so you can check it and see if you approve. Apologies for top-posting -- lame mailer. Greg W. - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: KaiGai Kohei kai...@kaigai.gr.jp Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org Sent: Monday, July 27, 2009 11:57:32 PM Subject: Re: [HACKERS] SE-PostgreSQL Specifications I revised the SE-PostgreSQL Specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft - Put several external link to introduce something too detail for PostgreSQL documentations. - Paid attention not to use undefined terminology, such as security context, security policy and mandatory access controls. - Revised whole of the composition in the Brief overview section. - Put an example of security policy rule. - SECURITY_LABEL option was replaced by SECURITY_CONTEXT to avoid meaningless confusion. I believe it become better than previous revision. Thanks, KaiGai Kohei wrote: Sam Mason wrote: On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This will be somewhat of a break from normal PG documentation because so far everything has been self contained, it's chosen its own interpretation of the SQL standard and it needs to document that. SE-PG will be interacting with much more code from outside and showing which parts of these are PG specific vs. which parts are common to all SELinux seems important. If you try to document *everything* you're going to be writing for years and give the impression that everything is implemented in SE-PG. A dividing line needs to be drawn between what is PG specific and what is SELinux (why not SEL?). It also seems to me reasonable suggestion. However, a reasonable amount (which should be adjusted under discussions) of description should be self-contained. For example, security context is a formatted short string is not enough to understand why it is necessary and what is the purpose. As Robert suggested, a few example and definition of technical terms will help database folks to understand what it is, even if self-contained explanation is not comprehensive from viewpoint of security folks. Thanks, -- OSS Platform Development Division, NEC 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 -- 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] SE-PostgreSQL Specifications
On Mon, Jul 27, 2009 at 01:53:07PM -0400, Chris Browne wrote: s...@samason.me.uk (Sam Mason) writes: On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote: Robert Haas wrote: In some cases, the clearance of infoamtion may be changed. We often have dome more complex requirements also. OK, so there is some other trusted entity that has unfettered access to both databases and its job is to manage these requirements. No, that's not what this implies. What this implies is along the following lines... If a user at the more secret level updates some data that had been classified at a lower level, then that data gets reclassified at the higher level. I still think it does; but maybe there are other ways of arranging things. The problem seems to be that if each user only has write access to their own level then the is no bound as to how far the two databases will get out of sync with each other. Some way has to be made of declassifying data and so bound the amount of difference between the two. This declassification can not done by a normal user as they can only write in their own level. This trusted entity has to exist to punch a hole in the security to do something that wouldn't otherwise be allowed to happen, information normally only flows up the hierarchy. -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
[wretched top-posting -- begs forgiveness!] KaiGai -- I have edited the first three sections (up to but not including Architecture), mostly cleaning up language but I did run into a few places where I am not sure if I got the proper meaning -- I flagged those in square brackets (e.g.[...]) and with your name. Feel free to change them, accept them, or confer back with me about them. In particular, in the Security policy section you had: TE rules use the third field in the security context. It is called type or domain (for processes). allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock}; I thought that colons were used to split these fields, so the above line would have only 2 ? Perhaps after the httpd_t ? I'd like to get some feedback from you (and any other readers) before I do more ... I need to go deal an invasion of the kitchen -- it is garbage collection morning (early) and I just had a pretty young skunk and two raccoon kits in rapid order and I have to clean up and secure the premises. Regards! G - Original Message From: Greg Williamson gwilliamso...@yahoo.com To: KaiGai Kohei kai...@ak.jp.nec.com; KaiGai Kohei kai...@kaigai.gr.jp Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org Sent: Tuesday, July 28, 2009 1:20:29 AM Subject: Re: [HACKERS] SE-PostgreSQL Specifications Thanks for the updates. I might suggest a couple of small changes: a) a section that explains comments like This is not supported in the initial version -- do you mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ? If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB hackers would care if is it is not to be included. How much do these compromise the design, and if so, are there specific plans for implementing them ? b) something which explains the differences between SELinux and SEPostgreSQL on the one hand (for SE fans). You've done a good job of outlining the differences and similarities with the more standard ACL methods and that needs to be kept prominent so people with DB experience can see the differences. I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a very high level outline and so I'd be tempted to move all implementation details to another page -- basically everything from Installation on, with the exception of the overview of the dump issues, is (to my eye) a detail that doesn't need exposing (yet). I'll send mail when I have a few paragraphs done so you can check it and see if you approve. Apologies for top-posting -- lame mailer. Greg W. - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: KaiGai Kohei kai...@kaigai.gr.jp Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org Sent: Monday, July 27, 2009 11:57:32 PM Subject: Re: [HACKERS] SE-PostgreSQL Specifications I revised the SE-PostgreSQL Specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft - Put several external link to introduce something too detail for PostgreSQL documentations. - Paid attention not to use undefined terminology, such as security context, security policy and mandatory access controls. - Revised whole of the composition in the Brief overview section. - Put an example of security policy rule. - SECURITY_LABEL option was replaced by SECURITY_CONTEXT to avoid meaningless confusion. I believe it become better than previous revision. Thanks, KaiGai Kohei wrote: Sam Mason wrote: On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This will be somewhat of a break from normal PG documentation because so far everything has been self contained, it's chosen its own interpretation of the SQL standard and it needs to document that. SE-PG will be interacting with much more code from outside and showing which parts of these are PG specific vs. which parts are common to all SELinux seems important. If you try to document *everything* you're going to be writing for years and give the impression that everything is implemented in SE-PG. A dividing line needs
Re: [HACKERS] SE-PostgreSQL Specifications
Peter Eisentraut wrote: On Sunday 26 July 2009 14:35:41 Sam Mason wrote: I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This is not supposed to be user documentation. It's supposed to be a feature specification that an implementation can be validated against. Hmm... What kind of descriptions are necessary for a feature specifications? Currently, I guess the specification describes when/where the security hook should be invoked, what permission should be checked and what result should be returned for each security hooks. Is it correct? Or, do you expect any other stuffs? Apart from that, user documentation is also necessary. If the specification should be described from completely different viewpoint, I'll provide it. 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] SE-PostgreSQL Specifications
Greg Williamson wrote: [wretched top-posting -- begs forgiveness!] KaiGai -- I have edited the first three sections (up to but not including Architecture), mostly cleaning up language but I did run into a few places where I am not sure if I got the proper meaning -- I flagged those in square brackets (e.g.[...]) and with your name. Feel free to change them, accept them, or confer back with me about them. Thanks for your efforts so much. I'll confirm it tomorrow (in JST). In particular, in the Security policy section you had: TE rules use the third field in the security context. It is called type or domain (for processes). allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock}; I thought that colons were used to split these fields, so the above line would have only 2 ? Perhaps after the httpd_t ? It says the third field in the security policy, not a rule in the security policy. Sorry, it might be introduced more carefully. In the default security policy, web server process performs labeled as system_u:system_r:httpd_t:s0. ^^^ This rule is checked when web server process tries to access a table labeled as system_u:object_r:sepgsql_ro_table_t:s0, for example. ^^ The TE rule is defined between the pair of third field (which is called type or domain) of security contexts. # BTW, basically, the second field is used for RBAC rules, the fourth field # is used for MLS rules. The first field is used to record who create the # object. Thanks, I'd like to get some feedback from you (and any other readers) before I do more ... I need to go deal an invasion of the kitchen -- it is garbage collection morning (early) and I just had a pretty young skunk and two raccoon kits in rapid order and I have to clean up and secure the premises. Regards! G - Original Message From: Greg Williamson gwilliamso...@yahoo.com To: KaiGai Kohei kai...@ak.jp.nec.com; KaiGai Kohei kai...@kaigai.gr.jp Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org Sent: Tuesday, July 28, 2009 1:20:29 AM Subject: Re: [HACKERS] SE-PostgreSQL Specifications Thanks for the updates. I might suggest a couple of small changes: a) a section that explains comments like This is not supported in the initial version -- do you mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ? If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB hackers would care if is it is not to be included. How much do these compromise the design, and if so, are there specific plans for implementing them ? b) something which explains the differences between SELinux and SEPostgreSQL on the one hand (for SE fans). You've done a good job of outlining the differences and similarities with the more standard ACL methods and that needs to be kept prominent so people with DB experience can see the differences. I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a very high level outline and so I'd be tempted to move all implementation details to another page -- basically everything from Installation on, with the exception of the overview of the dump issues, is (to my eye) a detail that doesn't need exposing (yet). I'll send mail when I have a few paragraphs done so you can check it and see if you approve. Apologies for top-posting -- lame mailer. Greg W. - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: KaiGai Kohei kai...@kaigai.gr.jp Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org Sent: Monday, July 27, 2009 11:57:32 PM Subject: Re: [HACKERS] SE-PostgreSQL Specifications I revised the SE-PostgreSQL Specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft - Put several external link to introduce something too detail for PostgreSQL documentations. - Paid attention not to use undefined terminology, such as security context, security policy and mandatory access controls. - Revised whole of the composition in the Brief overview section. - Put an example of security policy rule. - SECURITY_LABEL option was replaced by SECURITY_CONTEXT to avoid meaningless confusion. I believe it become better than previous revision. Thanks, KaiGai Kohei wrote: Sam Mason wrote: On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them
Re: [HACKERS] SE-PostgreSQL Specifications
On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote: Peter Eisentraut wrote: On Sunday 26 July 2009 14:35:41 Sam Mason wrote: I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This is not supposed to be user documentation. It's supposed to be a feature specification that an implementation can be validated against. Hmm... What kind of descriptions are necessary for a feature specifications? It describes what the feature does and why. Currently, I guess the specification describes when/where the security hook should be invoked, what permission should be checked and what result should be returned for each security hooks. Is it correct? Or, do you expect any other stuffs? That is a pretty good start, but it's drifting into implementation details. Apart from that, user documentation is also necessary. If the specification should be described from completely different viewpoint, I'll provide it. Yes, user documentation will eventually also be necessary, and the original specification may be usable as a source for that. I'm just reacting to those who commented whether or not references should be added and what reference style the documentation uses. We're not there yet. The purpose of this document is to explain what the feature does, not to teach users to use the feature. -- 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] SE-PostgreSQL Specifications
Greg Williamson wrote: Thanks for the updates. I might suggest a couple of small changes: a) a section that explains comments like This is not supported in the initial version -- do you mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ? If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB hackers would care if is it is not to be included. How much do these compromise the design, and if so, are there specific plans for implementing them ? The This is not supported ... comment means this feature is not included within the initial patch submitted to the next commit fest, so the corresponding section is not also included within the documentation patch at that time. However, I expect all the features and corresponding user documents should be included within the stable v8.5 release. So, I also described these sections with notations. b) something which explains the differences between SELinux and SEPostgreSQL on the one hand (for SE fans). You've done a good job of outlining the differences and similarities with the more standard ACL methods and that needs to be kept prominent so people with DB experience can see the differences. I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a very high level outline and so I'd be tempted to move all implementation details to another page -- basically everything from Installation on, with the exception of the overview of the dump issues, is (to my eye) a detail that doesn't need exposing (yet). At first, what should be included within the PostgreSQL official documentation? I don't think here is any opposition to include - Steps to installations - Enhancement in SQL statement - External links something like: It provides mandatory access controls. See the http://. for details. Needs to be discussed - Securtiy model overview, such as security context, security policy and so on. - Feature overview, such as example of access controls. - References to object classes and permissions. (Basically, it is not necessary for end users.) If we prepare a comprehensive external documentation, one idea is to revise the series of wikipages at: http://wiki.postgresql.org/wiki/SEPostgreSQL Thanks, I'll send mail when I have a few paragraphs done so you can check it and see if you approve. Apologies for top-posting -- lame mailer. Greg W. - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: KaiGai Kohei kai...@kaigai.gr.jp Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org Sent: Monday, July 27, 2009 11:57:32 PM Subject: Re: [HACKERS] SE-PostgreSQL Specifications I revised the SE-PostgreSQL Specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft - Put several external link to introduce something too detail for PostgreSQL documentations. - Paid attention not to use undefined terminology, such as security context, security policy and mandatory access controls. - Revised whole of the composition in the Brief overview section. - Put an example of security policy rule. - SECURITY_LABEL option was replaced by SECURITY_CONTEXT to avoid meaningless confusion. I believe it become better than previous revision. Thanks, KaiGai Kohei wrote: Sam Mason wrote: On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This will be somewhat of a break from normal PG documentation because so far everything has been self contained, it's chosen its own interpretation of the SQL standard and it needs to document that. SE-PG will be interacting with much more code from outside and showing which parts of these are PG specific vs. which parts are common to all SELinux seems important. If you try to document *everything* you're going to be writing for years and give the impression that everything is implemented in SE-PG. A dividing line needs to be drawn between what is PG specific and what is SELinux (why not SEL?). It also seems to me reasonable suggestion. However, a reasonable amount (which
Re: [HACKERS] SE-PostgreSQL Specifications
s...@samason.me.uk (Sam Mason) writes: On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote: Robert Haas wrote: In some cases, the clearance of infoamtion may be changed. We often have dome more complex requirements also. OK, so there is some other trusted entity that has unfettered access to both databases and its job is to manage these requirements. No, that's not what this implies. What this implies is along the following lines... If a user at the more secret level updates some data that had been classified at a lower level, then that data gets reclassified at the higher level. If this sort of outcome is problematic, then that suggests that maybe the attempt at sharing wasn't such a good idea. Thus, it is necessary a capability to store and manage data objects with different security labeles in a single database instance here. (If we don't want to use commercial solutions instead.) SE-PG is about doing the above in one database and allowing more rigorous checks to be done? I don't think the issue is so much about more rigorous; it's about having mandatory labelling that is handled consistently. -- (reverse (concatenate 'string ofni.sesabatadxunil @ enworbbc)) http://linuxdatabases.info/info/rdbms.html The people's revolutionary committee has decided that the name e is retrogressive, unmulticious and reactionary, and has been flushed. Please update your abbrevs. -- 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] SE-PostgreSQL Specifications
Chris Browne wrote: s...@samason.me.uk (Sam Mason) writes: On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote: Robert Haas wrote: In some cases, the clearance of infoamtion may be changed. We often have dome more complex requirements also. OK, so there is some other trusted entity that has unfettered access to both databases and its job is to manage these requirements. No, that's not what this implies. What this implies is along the following lines... If a user at the more secret level updates some data that had been classified at a lower level, then that data gets reclassified at the higher level. If this sort of outcome is problematic, then that suggests that maybe the attempt at sharing wasn't such a good idea. Theoretically, such kind of updates are not visible for lower security level users. In other word, a tuple can have multiple version depending on the security level, it might be called as polyinstantication. However, SE-PostgreSQL and SELinux which provides the security policy adopt more simple solution. Its security policy prevent any writer operations on the data object which dose not have identical security level. In other word, if the database client has classified level. He cannot write anything on both of unclassified and secret, but it is possible for classified data object. Thus, it is necessary a capability to store and manage data objects with different security labeles in a single database instance here. (If we don't want to use commercial solutions instead.) SE-PG is about doing the above in one database and allowing more rigorous checks to be done? I don't think the issue is so much about more rigorous; it's about having mandatory labelling that is handled consistently. Yes, it shall perform correctly as far as SE-PostgreSQL manages security context of database objects and makes its access control decision without any exceptions. Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
KaiGai -- I have a few suggestions which I will post in a bit, and some rather extensive edits of the existing Wiki, mostly for syntax rather than content. How do you want the latter ? I can email them offline as text, or you could set me up with a login on the wiki and I could do them in place (perhaps paragraph by paragraph) ? Thanks, and apologies for the delay ! Greg W. ps most of what I have is orthogonal to the lively discussions since Friday. -- 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] SE-PostgreSQL Specifications
Greg Williamson wrote: KaiGai -- I have a few suggestions which I will post in a bit, and some rather extensive edits of the existing Wiki, mostly for syntax rather than content. How do you want the latter ? I can email them offline as text, or you could set me up with a login on the wiki and I could do them in place (perhaps paragraph by paragraph) ? Thanks for your helps. I think it is good idea to edit wikipage because we can easily check and understand its update history. IIRC, you can create a wiki account from: http://www.postgresql.org/community/signup BTW, I changed the structure of chapters/sections in former of the documentation to reduce usage of undefined terminology and so on. Sorry, if it overlapped with your efforts. And, please note that the 3.2 Access controls section is still on work. Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote: Robert Haas wrote: Sam Mason wrote: The traditional approach would be to maintain multiple physically separate databases; in this setup it's obvious that when you perform a backup of one of these databases you're only seeing a subset of all of the objects. Isn't SE-PG just allowing you to do this within a single PG database? Partly. There's also a concept called read down, which is important. It allows you to have, say, secret and classified data in the same database, and let the secret users see both types but the classified users see only the classified stuff, not the secret stuff. If you want to store intelligence data about the war in Iraq and intelligence data about the war in Afghanistan, it might not be too bad to store them in separate databases, though storing them in the same database might also make things simpler for users who have access to both sets of data. But if you have higher and lower classifications of data it's pretty handy (AIUI) to be able to let the higher-secrecy users read the lower-secrecy data - if you used separate databases to simulate read-down, you'd have to replicate data between them, and also have some manual mechanism for tracking which level of secrecy applied to which to which data. It seems a correct description. In addition, we also need to prevent that higher-secrecy users writes anything to the lower-secrect objects to prevent information leaks. OK, so to bulk out this physical analogy we'd have two physical servers one that stores higher-secrecy stuff and one for lower-secrecy stuff. Users with higher clearance are able to read/write the higher secrecy database but only read the lower secrecy database. Users with lower clearance can only read/write the lower secrecy database, ideally they aren't even aware of the existence of the higher secrecy one. In some cases, the clearance of infoamtion may be changed. We often have dome more complex requirements also. OK, so there is some other trusted entity that has unfettered access to both databases and its job is to manage these requirements. Thus, it is necessary a capability to store and manage data objects with different security labeles in a single database instance here. (If we don't want to use commercial solutions instead.) SE-PG is about doing the above in one database and allowing more rigorous checks to be done? -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This will be somewhat of a break from normal PG documentation because so far everything has been self contained, it's chosen its own interpretation of the SQL standard and it needs to document that. SE-PG will be interacting with much more code from outside and showing which parts of these are PG specific vs. which parts are common to all SELinux seems important. If you try to document *everything* you're going to be writing for years and give the impression that everything is implemented in SE-PG. A dividing line needs to be drawn between what is PG specific and what is SELinux (why not SEL?). For the security policy, I introduce it at the security model section: | Access control is conceptually to decide a set of allowed (or denied) | actions between a certain subject (such as a database client) and an | object (such as a table), and to apply the decision on user's requests. | At the database privilege system, ACL stored in database objects itself | holds a list of allowed actions to certain database roles, and it is | applied on the user's request. | SELinux also holds massive sets of allowed actions between a certain | subject and a certain object, we call them security policy. Is it obscure? I find that somewhat opaque as well! sorry At this point, the SELinux user's guide in Fedora is the most comprehensive documentation. It is described from the viewpoint of SELinux users, not experts or developers. http://docs.fedoraproject.org/selinux-user-guide/ OK, thanks! -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
KaiGai Kohei wrote: The SELinux provides a certain process privilege to make backups and restore them. In the (currect) default policy, it is called unconfined. However, it is also *possible* to define a new special process privilege for backup and restore tools. For example, it can access all the databse objects and can make backups, but any other process cannot touch the backup files. It means that DBA can launch a backup tool and it creates a black-boxed file, then he cal also lauch a restore tool to restore the black-boxed backup, but he cannot see the contents of the backup. (It might be a similar idea of sudo mechanism.) Really? How you enforce this black box rule for a backup made across the network? From the server's POV there is no such thing as a backup. All it sees is a set of SQL statements all of which it might see in some other context. cheers andrew -- 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] SE-PostgreSQL Specifications
Sam Mason wrote: On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This will be somewhat of a break from normal PG documentation because so far everything has been self contained, it's chosen its own interpretation of the SQL standard and it needs to document that. SE-PG will be interacting with much more code from outside and showing which parts of these are PG specific vs. which parts are common to all SELinux seems important. If you try to document *everything* you're going to be writing for years and give the impression that everything is implemented in SE-PG. A dividing line needs to be drawn between what is PG specific and what is SELinux (why not SEL?). It also seems to me reasonable suggestion. However, a reasonable amount (which should be adjusted under discussions) of description should be self-contained. For example, security context is a formatted short string is not enough to understand why it is necessary and what is the purpose. As Robert suggested, a few example and definition of technical terms will help database folks to understand what it is, even if self-contained explanation is not comprehensive from viewpoint of security folks. 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] SE-PostgreSQL Specifications
Andrew Dunstan wrote: KaiGai Kohei wrote: The SELinux provides a certain process privilege to make backups and restore them. In the (currect) default policy, it is called unconfined. However, it is also *possible* to define a new special process privilege for backup and restore tools. For example, it can access all the databse objects and can make backups, but any other process cannot touch the backup files. It means that DBA can launch a backup tool and it creates a black-boxed file, then he cal also lauch a restore tool to restore the black-boxed backup, but he cannot see the contents of the backup. (It might be a similar idea of sudo mechanism.) Really? How you enforce this black box rule for a backup made across the network? From the server's POV there is no such thing as a backup. All it sees is a set of SQL statements all of which it might see in some other context. The recent SELinux provide a feature to exchange the security context of peer process over the network connection. It allows to control a certain process to send/receive packets to/from only a certain process, even if they communicate using remote connection. This feature is named Labeled IPsec. The key exchange daemon (racoon) was enhanced to exchange the security context of peer processes also, prior to the actual communications. 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] SE-PostgreSQL Specifications
KaiGai Kohei wrote: Andrew Dunstan wrote: KaiGai Kohei wrote: The SELinux provides a certain process privilege to make backups and restore them. In the (currect) default policy, it is called unconfined. However, it is also *possible* to define a new special process privilege for backup and restore tools. For example, it can access all the databse objects and can make backups, but any other process cannot touch the backup files. It means that DBA can launch a backup tool and it creates a black-boxed file, then he cal also lauch a restore tool to restore the black-boxed backup, but he cannot see the contents of the backup. (It might be a similar idea of sudo mechanism.) Really? How you enforce this black box rule for a backup made across the network? From the server's POV there is no such thing as a backup. All it sees is a set of SQL statements all of which it might see in some other context. The recent SELinux provide a feature to exchange the security context of peer process over the network connection. It allows to control a certain process to send/receive packets to/from only a certain process, even if they communicate using remote connection. This feature is named Labeled IPsec. The key exchange daemon (racoon) was enhanced to exchange the security context of peer processes also, prior to the actual communications. Interesting, I can see this having some use in quite a number of areas. Of course, in the end, it still comes down to this issue, which is as old as Plato: Quis custodiet ipsos custodes? (see http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F ) cheers andrew */ /* -- 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] SE-PostgreSQL Specifications
Robert Haas wrote: If you want to store intelligence data about the war in Iraq and intelligence data about the war in Afghanistan, it might not be too bad to store them in separate databases, though storing them in the same database might also make things simpler for users who have access to both sets of data. But if you have higher and lower classifications of data it's pretty handy (AIUI) to be able to let the higher-secrecy users read the lower-secrecy data Nice example. Is this system being designed flexibly enough so that one user may have access to the higher-secrecy data of the Iraq dataset but only the lower-secrecy Afghanistan dataset; while a different user may have access to the higher-secrecy Afghanistan data but only the lower-secrecy Iraq data? I imagine it's not uncommon for organizations to want to have total access to their data, but expose more limited access to other organizations they communicate with. -- 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] SE-PostgreSQL Specifications
Andrew Dunstan wrote: KaiGai Kohei wrote: Andrew Dunstan wrote: KaiGai Kohei wrote: The SELinux provides a certain process privilege to make backups and restore them. In the (currect) default policy, it is called unconfined. However, it is also *possible* to define a new special process privilege for backup and restore tools. For example, it can access all the databse objects and can make backups, but any other process cannot touch the backup files. It means that DBA can launch a backup tool and it creates a black-boxed file, then he cal also lauch a restore tool to restore the black-boxed backup, but he cannot see the contents of the backup. (It might be a similar idea of sudo mechanism.) Really? How you enforce this black box rule for a backup made across the network? From the server's POV there is no such thing as a backup. All it sees is a set of SQL statements all of which it might see in some other context. The recent SELinux provide a feature to exchange the security context of peer process over the network connection. It allows to control a certain process to send/receive packets to/from only a certain process, even if they communicate using remote connection. This feature is named Labeled IPsec. The key exchange daemon (racoon) was enhanced to exchange the security context of peer processes also, prior to the actual communications. Interesting, I can see this having some use in quite a number of areas. Of course, in the end, it still comes down to this issue, which is as old as Plato: Quis custodiet ipsos custodes? (see http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F ) The administrator needs to set up and manage both of the hosts to keep consistent security policy, but it is not a technical issue. We have security issues broader than what technical feature can solve, and the technical security feature is a piece of them. (Needless to say, it is an important piece.) For example, any kind of access controls are ineffective to phisical attacks, so we need to place the server in data centers with physical controls on entering or leaving a room. Referring any ISO/IEC15408 certifications, they defines a certain environment in which the certified products to be used. It means the certification is valid on the required environments. The technical security feature is an important piece, but not all. 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote: Sam Mason wrote: This would seem to imply that all user defined trusted code has to perform its own permission checks. How is MAC any different from DAC in the presence of code such as: CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD LANGUAGE 'sql' SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0' AS 'SELECT * FROM customer'; In this case, confined users cannot create a function labeled as 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is controlled by db_procedure:{create} permission. Yes, that seems reasonable. The fact that you're still talking about confined users is slightly worrying and would seem to imply that there is still a superuser/normal user divide--it's probably just a terminology thing though. One thing I know I don't understand is what the security labels actually mean; I've had a couple of searches through your pages now and can't see anything described nor pointers to external documentation. Confined user can create a function with user_sepgsql_proc_exec_t (which is the default one for confined users), but it is not a trusted procedure, so the SELECT * FROM customer is executed with confined user's privileges as is, then it will be failed due to the lack of permission on the customer.credit. So an unconfined user (whatever that means??) is basically working with DACs then? -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
Sam Mason wrote: On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote: Sam Mason wrote: This would seem to imply that all user defined trusted code has to perform its own permission checks. How is MAC any different from DAC in the presence of code such as: CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD LANGUAGE 'sql' SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0' AS 'SELECT * FROM customer'; In this case, confined users cannot create a function labeled as 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is controlled by db_procedure:{create} permission. Yes, that seems reasonable. The fact that you're still talking about confined users is slightly worrying and would seem to imply that there is still a superuser/normal user divide--it's probably just a terminology thing though. One thing I know I don't understand is what the security labels actually mean; I've had a couple of searches through your pages now and can't see anything described nor pointers to external documentation. I assume the wikipage (SEPostgreSQL_Draft) is a draft for the PostgreSQL official documentation. However, the list of security labels originates from the default security policy in SELinux. So, I think an external link will be preferable for the references. TODO: I'll make the list of security labels we can assign on. Confined user can create a function with user_sepgsql_proc_exec_t (which is the default one for confined users), but it is not a trusted procedure, so the SELECT * FROM customer is executed with confined user's privileges as is, then it will be failed due to the lack of permission on the customer.credit. So an unconfined user (whatever that means??) is basically working with DACs then? Sorry for using the undefined terminology. The default security policy provides several security contexts that we can assign on user's shell process, such as user_t, staff_t and unconfined_t. (Please note that the security context of processes means its privileges.) SELinux checks privileges of processes without any exceptions. However, the default security policy allows anything on unconfined_t label. It means unconfined users are allowed anything according to the policy. (BTW, we can unplug the unconfined label using modular policy stuff.) On the other hand, rest of security context (user_t, staff_t or httpd_t for web servers) are confined, because the security policy does not allow such widespread permissions. 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] SE-PostgreSQL Specifications
Sam Mason s...@samason.me.uk writes: Yes, that seems reasonable. The fact that you're still talking about confined users is slightly worrying and would seem to imply that there is still a superuser/normal user divide--it's probably just a terminology thing though. There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. regards, tom lane -- 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] SE-PostgreSQL Specifications
On Jul 25, 2009, at 11:06 AM, Tom Lane wrote: Sam Mason s...@samason.me.uk writes: Yes, that seems reasonable. The fact that you're still talking about confined users is slightly worrying and would seem to imply that there is still a superuser/normal user divide--it's probably just a terminology thing though. There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. This behavior is no different than when taking/using an SE-enabled filesystem backup. And woe to the admin who doesn't test his backups- caveat emptor. Still, it would be nice if pg_dump warned or stopped if the backup it created was completely useless (missing data dependencies), no? Cheers, M -- 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote: Sorry for using the undefined terminology. I think this is the largest missing part of the docs at the moment; there is a whole new world of definitions that need to be understood before the SE-PG stuff is understandable/usable by anyone and none of it is explained in a way I can understand. External links are fine at the moment (I think) but descriptions will need to exist. For example you currently define a security context as a formatted short string---how does that tell me why I would want one or what it does! As an example, PG currently has the following to describe what a role is: http://www.postgresql.org/docs/current/static/database-roles.html I'd expect a similar definition for each of the major terms in SE-PG; at the moment these seem to be security label, security context, security policy and others? What do others think? Hope that helps explain my confusion! If you point me at some docs I'll be happy to write/edit things to make them more relevant to PG. -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote: There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. That should be solved by different methods; as A.M said pg_dump can complain if it doesn't see everything it expected to (which should handle the naive user case) and backdoors can be put in the scheme that will (by default?) initially allow a backup subject unfettered read-only access to each object. I'm expecting that this access can be revoked as needed from sensitive tables. -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote: There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. I imagine it would be possible to run pg_dump on a database where you couldn't see all of the objects, and get a dump of just those, but that's only tangentially related to whether such things as superusers exist. If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. And while I believe SE-Linux/SE-PostgreSQL would allow you to configure such a system, you might want to think carefully before you decide to do so, and the system certainly shouldn't (and can't) force you to set it up that way. The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. That should be solved by different methods; as A.M said pg_dump can complain if it doesn't see everything it expected to (which should handle the naive user case) and backdoors can be put in the scheme that will (by default?) initially allow a backup subject unfettered read-only access to each object. I'm expecting that this access can be revoked as needed from sensitive tables. If pg_dump can tell that there is information missing, the system hasn't done a very good job of hiding its existence, which is surely the whole point here. Even if SE-PostgreSQL isn't explicitly worried about eliminating covert channels, it seems like a terrible idea to design a database backup tool that operates by exploiting ones we haven't chosen to eliminate. ...Robert -- 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote: On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Yes, that sounds more precise! I'm still unsure of terminology; what's a unconfined role? I guess the layman's description is similar to a superuser, but I'm sure there's a more refined definition somewhere. Hum, I've just found Fedora's guide, is the following considered a reasonable picture: http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. I imagine it would be possible to run pg_dump on a database where you couldn't see all of the objects, and get a dump of just those, but that's only tangentially related to whether such things as superusers exist. I'm not sure what point you're trying to make; in my understanding superusers can see and do anything--hence they can make a backup. If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. The traditional approach would be to maintain multiple physically separate databases; in this setup it's obvious that when you perform a backup of one of these databases you're only seeing a subset of all of the objects. Isn't SE-PG just allowing you to do this within a single PG database? And while I believe SE-Linux/SE-PostgreSQL would allow you to configure such a system, you might want to think carefully before you decide to do so, and the system certainly shouldn't (and can't) force you to set it up that way. I agree that this would seem to make the resulting system easier to manage, however I can also imagine scenarios where the converse would be true. This is a fuzzy engineering decision of the sort that I don't like making without a use case---and it would be nice to have several here. pg_dump can complain if it doesn't see everything it expected to If pg_dump can tell that there is information missing, the system hasn't done a very good job of hiding its existence, which is surely the whole point here. Hum, good point--scratch that idea then! -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
Sam Mason wrote: On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote: Sorry for using the undefined terminology. I think this is the largest missing part of the docs at the moment; there is a whole new world of definitions that need to be understood before the SE-PG stuff is understandable/usable by anyone and none of it is explained in a way I can understand. External links are fine at the moment (I think) but descriptions will need to exist. For example you currently define a security context as a formatted short string---how does that tell me why I would want one or what it does! As an example, PG currently has the following to describe what a role is: http://www.postgresql.org/docs/current/static/database-roles.html Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'd expect a similar definition for each of the major terms in SE-PG; at the moment these seem to be security label, security context, security policy and others? What do others think? The security label is an identical one with security context. Due to the historical reason, I uses a term of SECURITY_LABEL for interfaces, but it might be more easy understandable to use SECURITY_CONTEXT instead. For the security policy, I introduce it at the security model section: | Access control is conceptually to decide a set of allowed (or denied) | actions between a certain subject (such as a database client) and an | object (such as a table), and to apply the decision on user's requests. | At the database privilege system, ACL stored in database objects itself | holds a list of allowed actions to certain database roles, and it is | applied on the user's request. | SELinux also holds massive sets of allowed actions between a certain | subject and a certain object, we call them security policy. Is it obscure? In addition, I also think it needs to define some other terms explicitly. For example, what the term of labeled means. Hope that helps explain my confusion! If you point me at some docs I'll be happy to write/edit things to make them more relevant to PG. At this point, the SELinux user's guide in Fedora is the most comprehensive documentation. It is described from the viewpoint of SELinux users, not experts or developers. http://docs.fedoraproject.org/selinux-user-guide/ 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote: | Access control is conceptually to decide a set of allowed (or denied) | actions between a certain subject (such as a database client) and an | object (such as a table), and to apply the decision on user's requests. | At the database privilege system, ACL stored in database objects itself | holds a list of allowed actions to certain database roles, and it is | applied on the user's request. | SELinux also holds massive sets of allowed actions between a certain | subject and a certain object, we call them security policy. Is it obscure? It's obscure to me. :-) I think you need to define security policy more precisely and give at least one or two examples of security policy entries. ...Robert -- 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] SE-PostgreSQL Specifications
Robert Haas wrote: On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote: | Access control is conceptually to decide a set of allowed (or denied) | actions between a certain subject (such as a database client) and an | object (such as a table), and to apply the decision on user's requests. | At the database privilege system, ACL stored in database objects itself | holds a list of allowed actions to certain database roles, and it is | applied on the user's request. | SELinux also holds massive sets of allowed actions between a certain | subject and a certain object, we call them security policy. Is it obscure? It's obscure to me. :-) I think you need to define security policy more precisely and give at least one or two examples of security policy entries. OK, I'll try to define it more precisely and introduce a few examples in the documents. 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 7:49 PM, Sam Masons...@samason.me.uk wrote: On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote: On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Yes, that sounds more precise! I'm still unsure of terminology; what's a unconfined role? I guess the layman's description is similar to a superuser, but I'm sure there's a more refined definition somewhere. Hum, I've just found Fedora's guide, is the following considered a reasonable picture: http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. I imagine it would be possible to run pg_dump on a database where you couldn't see all of the objects, and get a dump of just those, but that's only tangentially related to whether such things as superusers exist. I'm not sure what point you're trying to make; in my understanding superusers can see and do anything--hence they can make a backup. If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. The traditional approach would be to maintain multiple physically separate databases; in this setup it's obvious that when you perform a backup of one of these databases you're only seeing a subset of all of the objects. Isn't SE-PG just allowing you to do this within a single PG database? Partly. There's also a concept called read down, which is important. It allows you to have, say, secret and classified data in the same database, and let the secret users see both types but the classified users see only the classified stuff, not the secret stuff. If you want to store intelligence data about the war in Iraq and intelligence data about the war in Afghanistan, it might not be too bad to store them in separate databases, though storing them in the same database might also make things simpler for users who have access to both sets of data. But if you have higher and lower classifications of data it's pretty handy (AIUI) to be able to let the higher-secrecy users read the lower-secrecy data - if you used separate databases to simulate read-down, you'd have to replicate data between them, and also have some manual mechanism for tracking which level of secrecy applied to which to which data. All of the foregoing is my very layman's understanding of this, so take it with a grain of salt. ...Robert -- 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] SE-PostgreSQL Specifications
Sam Mason wrote: On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote: On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Yes, that sounds more precise! Yes, Rober's explanation is correct. I'm still unsure of terminology; what's a unconfined role? I guess the layman's description is similar to a superuser, but I'm sure there's a more refined definition somewhere. Hum, I've just found Fedora's guide, is the following considered a reasonable picture: http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html Please note that SELinux/SE-PgSQL checks all the requests from users without any exceptions, even if he is a superusers. It makes its access control decisions based on the security policy. The default security policy (which is provided by SELinux's community) allows anything on the unconfined ones. Thus, it is allowed anything at the result. (Needless to say, DAC permission checks are applied independent from whether it is confined or unconfined in SELinux.) It is important the decision is always according to the security policy. And while I believe SE-Linux/SE-PostgreSQL would allow you to configure such a system, you might want to think carefully before you decide to do so, and the system certainly shouldn't (and can't) force you to set it up that way. I agree that this would seem to make the resulting system easier to manage, however I can also imagine scenarios where the converse would be true. This is a fuzzy engineering decision of the sort that I don't like making without a use case---and it would be nice to have several here. The SELinux provides a certain process privilege to make backups and restore them. In the (currect) default policy, it is called unconfined. However, it is also *possible* to define a new special process privilege for backup and restore tools. For example, it can access all the databse objects and can make backups, but any other process cannot touch the backup files. It means that DBA can launch a backup tool and it creates a black-boxed file, then he cal also lauch a restore tool to restore the black-boxed backup, but he cannot see the contents of the backup. (It might be a similar idea of sudo mechanism.) It is a separated issue whether the *default* security policy should supports such an extreme protection, or not. However, SELinux community shall provide its security policy to make backup and restore them correctly, and suggest what privilege should be assigned on the user sheel which launches backup and restore tools. If it does not work correctly, it is a simply bug. TODO: I've not provide a draft documentation for backup options to pg_dump command, but it will be necessary to be reviewed. It should contains what security context should be assigned on the user shell which launches the pg_dump also. 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] SE-PostgreSQL Specifications
Robert Haas wrote: If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. The traditional approach would be to maintain multiple physically separate databases; in this setup it's obvious that when you perform a backup of one of these databases you're only seeing a subset of all of the objects. Isn't SE-PG just allowing you to do this within a single PG database? Partly. There's also a concept called read down, which is important. It allows you to have, say, secret and classified data in the same database, and let the secret users see both types but the classified users see only the classified stuff, not the secret stuff. If you want to store intelligence data about the war in Iraq and intelligence data about the war in Afghanistan, it might not be too bad to store them in separate databases, though storing them in the same database might also make things simpler for users who have access to both sets of data. But if you have higher and lower classifications of data it's pretty handy (AIUI) to be able to let the higher-secrecy users read the lower-secrecy data - if you used separate databases to simulate read-down, you'd have to replicate data between them, and also have some manual mechanism for tracking which level of secrecy applied to which to which data. It seems a correct description. In addition, we also need to prevent that higher-secrecy users writes anything to the lower-secrect objects to prevent information leaks. In some cases, the clearance of infoamtion may be changed. We often have dome more complex requirements also. Thus, it is necessary a capability to store and manage data objects with different security labeles in a single database instance here. (If we don't want to use commercial solutions instead.) 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] SE-PostgreSQL?
Robert Haas wrote: I think the best thing for this patch right now is to move it to Returned with Feedback. I can't see any way that this patch is going to be made committable for this CommitFest, and I think that pretending otherwise is only encouraging KaiGai to do another of his lighting rework-and-resubmits. While those are very impressive, they're not getting us where we need to be. I think that what KaiGai needs to do here is get the spec written (with the help of Greg Williamson and anyone else who is willing to pitch in), and submit it for comments. I don't think there will be a problem getting that reviewed outside of a CommitFest, and it's not a patch anyway, so the time that it gets submitted is not crucial. What is crucial is that it is a good spec that everyone can read, and hopefully understand and discuss. There is no point writing any more code, or submitting any more patches, until we have agreement on what those patches are supposed to do. I also agree that the easy understandable specification what SE-PostgreSQL tries to achieve is more important than implementation. I described it from the scratch again. Here is an initial draft: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft I would like to improve documentation quality and fix its specification during the discussion. I am going to go ahead and mark this as Returned with Feedback. Agreed. -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
Excellent ... I'll try to have something tomorrow (Friday PDT) but I've got some non-work related issues which may keep from giving this a good look until the weekend (FWIW). I'll post any questions I have. Thanks, Greg W. - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: Robert Haas robertmh...@gmail.com Cc: pgsql-hackers@postgresql.org; KaiGai Kohei kai...@kaigai.gr.jp; Greg Williamson gwilliamso...@yahoo.com; Sam Mason s...@samason.me.uk; Joshua Brindle met...@manicmethod.com Sent: Thursday, July 23, 2009 9:54:10 PM Subject: SE-PostgreSQL Specifications Here is the initial draft of SE-PostgreSQL specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft I've described it from the scratch again with paying attention for the people knowing nothing about SELinux. In some points, it uses comparison between the database privilege mechanism and SE-PostgreSQL for easy understanding. Please point out, if ... - Its composition can be improved. - Here is not enough introductions for what user wants to know. - Here is too much explanations, more brief one will be available. - Here is not easy understandable for database folks. - Here is not enough English quality. - And so on... In addition, I would like to fix its specifications during the discussion. Thanks, -- OSS Platform Development Division, NEC 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] SE-PostgreSQL Specifications
On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote: Here is the initial draft of SE-PostgreSQL specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft Hey, this is really cool. Think it is a nice introduction. Fixed some of the really obvious language stuff and an example but the English is quite good. One thing I know people are going to ask: why did you use names like create and delete and not the usual names that postgresql itself uses. I suspect the answer is because that's the standard naming used in SELinux, but I think you need to spell that out somewhere. The same for the db_* convention. Do you have a reference to naming conventions for SELinux permissions? I need to think it over some more, but it's a really good start. Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
Martijn van Oosterhout wrote: On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote: Here is the initial draft of SE-PostgreSQL specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft Hey, this is really cool. Think it is a nice introduction. Fixed some of the really obvious language stuff and an example but the English is quite good. Thanks, but I found an incorrect change at the trusted procedure section. Old) CREATE TABLE customer ( cid integer primary key, cname varchar(32), credit varchar(32) - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0' - ); New) CREATE TABLE customer ( cid integer primary key, cname varchar(32), credit varchar(32) + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'; This example intends to assign secret label on the credit column, not whole of the table. Note that the default security context shall be assigned on the table and rest of columns in this case. | For example, when the customer table is defined as follows, | unprivileged users cannot see the contents of customer.credit | because it is labeled as sepgsql_secret_table_t which means | all the accesses are denied from confined domains. Is the description inadequate to note the example tries to assign a certain security context on the customer.credit column? BTW, in the later case, the table is labeled as secret, then columns inherit table's security context in the default, so the table and all the columns are labeled as secret. One thing I know people are going to ask: why did you use names like create and delete and not the usual names that postgresql itself uses. I suspect the answer is because that's the standard naming used in SELinux, but I think you need to spell that out somewhere. The same for the db_* convention. Do you have a reference to naming conventions for SELinux permissions? http://oss.tresys.com/repos/refpolicy/trunk/policy/flask/access_vectors All the object classes managed in userspace object manager have its prefix. For example, X-window objects has x_* prefix. Kenel objects don't have any prefix, such as file. Referring the other base object classes, it uses create, getattr, setattr, relabelfrom and relabelto commonly. However, a permission to remove the object itself is named reflecting to the characteristics of the object. For example, file:{unlink} and ipc:{destroy} mean a permission to remove itself. I believe drop is an appropriate naming for database objects. TODO: add description at the Object classes and permissions why object classes are prefixed by db_* I need to think it over some more, but it's a really good start. Have a nice day, -- 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] SE-PostgreSQL Specifications
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: Here is the initial draft of SE-PostgreSQL specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft Thanks for this, it really does help, I believe. I've been reviewing it and am also planning on helping refine and improve upon it. I'd like to spend time working on the patch as well but I'm hesitant to commit to that right now due to other obligations. We'll see how it goes. Thanks again, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frostsfr...@snowman.net wrote: Thanks for this, it really does help, I believe. I've been reviewing it and am also planning on helping refine and improve upon it. I'd like to spend time working on the patch as well but I'm hesitant to commit to that right now due to other obligations. We'll see how it goes. At this point, I think refining and improving the spec is probably considerably more important than writing the code. ...Robert -- 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote: Thanks, but I found an incorrect change at the trusted procedure section. Old) CREATE TABLE customer ( cid integer primary key, cname varchar(32), credit varchar(32) - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0' - ); New) CREATE TABLE customer ( cid integer primary key, cname varchar(32), credit varchar(32) + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'; This example intends to assign secret label on the credit column, not whole of the table. Note that the default security context shall be assigned on the table and rest of columns in this case. The show_credit() function in this section would seem to leak authority as well; it seems possible to determine if customers exist that otherwise may otherwise hidden. For example, imagine we have a row in the customer table with cid=1 whose security label would normally prevent. We can perform: SELECT show_credit(1); and, as far as I can tell, this call would succeed. -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
Sam Mason wrote: On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote: Thanks, but I found an incorrect change at the trusted procedure section. Old) CREATE TABLE customer ( cid integer primary key, cname varchar(32), credit varchar(32) - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0' - ); New) CREATE TABLE customer ( cid integer primary key, cname varchar(32), credit varchar(32) + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'; This example intends to assign secret label on the credit column, not whole of the table. Note that the default security context shall be assigned on the table and rest of columns in this case. The show_credit() function in this section would seem to leak authority as well; it seems possible to determine if customers exist that otherwise may otherwise hidden. For example, imagine we have a row in the customer table with cid=1 whose security label would normally prevent. We can perform: SELECT show_credit(1); and, as far as I can tell, this call would succeed. This example shows that confined client cannot read credit card number without using trusted procedure, but trusted procedure returns masked one. It does not intend to hide existence of entries within customer table. See the third box in the section. postgres=# SELECT cid, cname FROM customer; cid | cname -+--- 10 | jack 13 | adam 14 | liza (3 rows) This query does not read from customer.credit, so it should be succeeded. 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] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote: Sam Mason wrote: The show_credit() function in this section would seem to leak authority as well; it seems possible to determine if customers exist that otherwise may otherwise hidden. For example, imagine we have a row in the customer table with cid=1 whose security label would normally prevent. We can perform: SELECT show_credit(1); and, as far as I can tell, this call would succeed. This example shows that confined client cannot read credit card number without using trusted procedure, but trusted procedure returns masked one. It does not intend to hide existence of entries within customer table. This would seem to imply that all user defined trusted code has to perform its own permission checks. How is MAC any different from DAC in the presence of code such as: CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD LANGUAGE 'sql' SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0' AS 'SELECT * FROM customer'; (I hope I've modified the example correctly!) -- Sam http://samason.me.uk/ -- 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] SE-PostgreSQL Specifications
Sam Mason wrote: On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote: Sam Mason wrote: The show_credit() function in this section would seem to leak authority as well; it seems possible to determine if customers exist that otherwise may otherwise hidden. For example, imagine we have a row in the customer table with cid=1 whose security label would normally prevent. We can perform: SELECT show_credit(1); and, as far as I can tell, this call would succeed. This example shows that confined client cannot read credit card number without using trusted procedure, but trusted procedure returns masked one. It does not intend to hide existence of entries within customer table. This would seem to imply that all user defined trusted code has to perform its own permission checks. How is MAC any different from DAC in the presence of code such as: CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD LANGUAGE 'sql' SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0' AS 'SELECT * FROM customer'; (I hope I've modified the example correctly!) In this case, confined users cannot create a function labeled as 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is controlled by db_procedure:{create} permission. Confined user can create a function with user_sepgsql_proc_exec_t (which is the default one for confined users), but it is not a trusted procedure, so the SELECT * FROM customer is executed with confined user's privileges as is, then it will be failed due to the lack of permission on the customer.credit. 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] SE-PostgreSQL?
On Sat, Jul 18, 2009 at 12:06 PM, David Fetterda...@fetter.org wrote: At this point, SE-PostgreSQL has taken up a *lot* of community resources, not to mention an enormous and doubtless frustrating amount of Kohei-san's time and effort, thus far without a single committed patch, or even a consensus as to what it should (or could) do. Rather than continuing to blunder into the future, I think we need to do a reality check in the form of a couple of questions: 1. Among the committers who could maintain the features, whatever they turn out to be, who is actually volunteering to do so? 2. Apart from Kohei-san and Stephen Frost, is anybody actually interested in having this feature at all? I would submit that if we get fewer than three enthusiastic, me!s on the first, or fewer people than five on the second, we just need to bounce this feature and move on. As I see it, those numbers are a bare minimum, although one could fairly argue that I've underestimated the minimum for the second. I count zero for the first question and five for the second, although two of those five (Josh Berkus and Ron Mayer) expressed doubt about this patch set as an implementation of this feature, and only one person (Greg Williamson) volunteered to help. I think, though, that we have on the other thread gotten closer to a solution to some of the problems that have been plaguing this feature, including, in particular, the need for a clear spec and very complete docs. I think the best thing for this patch right now is to move it to Returned with Feedback. I can't see any way that this patch is going to be made committable for this CommitFest, and I think that pretending otherwise is only encouraging KaiGai to do another of his lighting rework-and-resubmits. While those are very impressive, they're not getting us where we need to be. I think that what KaiGai needs to do here is get the spec written (with the help of Greg Williamson and anyone else who is willing to pitch in), and submit it for comments. I don't think there will be a problem getting that reviewed outside of a CommitFest, and it's not a patch anyway, so the time that it gets submitted is not crucial. What is crucial is that it is a good spec that everyone can read, and hopefully understand and discuss. There is no point writing any more code, or submitting any more patches, until we have agreement on what those patches are supposed to do. I am going to go ahead and mark this as Returned with Feedback. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SE-PostgreSQL Specifications
Here is the initial draft of SE-PostgreSQL specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft I've described it from the scratch again with paying attention for the people knowing nothing about SELinux. In some points, it uses comparison between the database privilege mechanism and SE-PostgreSQL for easy understanding. Please point out, if ... - Its composition can be improved. - Here is not enough introductions for what user wants to know. - Here is too much explanations, more brief one will be available. - Here is not easy understandable for database folks. - Here is not enough English quality. - And so on... In addition, I would like to fix its specifications during the discussion. Thanks, -- OSS Platform Development Division, NEC 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