Adding support for SE-Linux security
in [PgSql]
|
From: Bruce Momjian on 8 Dec 2009 19:58 Robert Haas wrote: > Sorry. I spent a lot of time for both CommitFest 2008-11 and > CommitFest 2009-07 in the hopes of getting something committable, and > I wasn't successful. I'm just at the end of my rope. It seems fairly > clear that Tom isn't going to commit any piece of SE-PostgreSQL at > all, ever. So who's going to do it? It doesn't make any sense to > continue trucking along with this patch into the indefinite future if > it has no hope of being committed. > > Frankly, I think this comes down to money. There are several > PostgreSQL companies which employ very capable PostgreSQL committers. > When someone is willing to pony up enough money to get those people > interested (as, I gather, has happened with block-checksumming) then > this will happen. Until then, I don't believe anyone is going to > volunteer to be responsible for a 10,000-line patch in their free > time. Tom is the only one crazy enough for that, and he said no. I have offered to review/commit the patch. I don't promise my effort will be pretty, but I will get the job done. I have not started yet because I think we are still unclear if the feature is worth the additional code maintenance. I frankly think the patch should be thought of as the SE-Linux-specific directory files, which KaiGai can maintain, and the other parts, which I think I can handle. > The next time someone submits a huge, unsolicited patch to do > ANYTHING, we should do them a favor and tell them this up front, > rather than a year and a half later. Then they could have the > appropriate conversations with the appropriate people and determine > whether to budget for it or give up. What has happened with this > patch has not served KaiGai well, or improved the image of this > community. Yes, this has not been our finest hour. :-( I think the causes have been explained already: o early patches did not have community buy-in o we are unclear about the size of the user community o we are unclear what the end user will want o the feature is complex o the features is in an unfamiliar problem-domain -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 8 Dec 2009 21:11 David P. Quigley wrote: > So I was reading through a set of slides that KaiGai has and he > mentioned a May commitfest link and I looked for the comments related to > his PGACE patches. I've been crawling through the commitfest paces so I > can figure out what the latest version of the pgace patch is. Does > anyone know when the patch was reduced to what it is today? I could salvage a legacy PGACE patch: http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch However, its code base was v8.4devel, so conflictable to the latest CVS HEAD. In addition, it contains various kind of concepts within a single patch. * comprehensive security hooks * a facility to store security identifier on the header of each row * a facility to translate between security identifier (int) and security context (text) * "security_context" writable system column support. From the current perspective, we can understand these features should be proposed as separated features. But I was young. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Smith on 8 Dec 2009 21:34 David P. Quigley wrote: > I understand that PostgreSQL is a fast moving target with a large developer base but so is the Linux Kernel and a > similar framework has been working there for years now. > It sounds like how you're thinking about this project's development model is inverted from the reality, and it's import to sort that out because it really impacts why there's so much resistance here. One reason the Linux kernel moves so fast because they don't care one lick for many types of backward compatibility, they'll just change interfaces as necessary to work around problems. To use the terms of the old 2.4 Linux kernel, there is no "stable" branch development happens against anymore; just the fast changing unstable one, that if everyone is lucky eventually converges into some usable versions anyway. Here, there is zero tolerance for any commit that destabilizes the codebase even temporarily. Until you get the whole thing sorted out usefully enough to be shippable quality, you don't go into the main (and only official) branch. Also, the PostgreSQL developers like to deliver a stable release and then change *nothing* to it except to fix bugs, supporting that release for years. We consider a released piece of software like a contract to the users, and everyone goes through lots of work to avoid changing anything unless absolutely necessary. A very large component of the concern here comes from that mindset. If this goes out, and there's a fundamental problem with it, this community doesn't even have a good process to fix that until the next major release, around a year later. In general, there is no such thing as an upgrade to a stable version that includes a serious behavior change. Having that happen is considered a major breakdown in the process, and there's only been a very small number of such situations in the past, when some just impossible to work around bug was introduced. Instead, just the absolute minimum of changes needed to fix bugs are applied to the stable, shipped versions. If a version ships with a broken enough behavior, it's quite possible that fixing it cannot be done in a way that can be distributed and applied via the standard minor version upgrade procedure used at all. The idea here is not "if it's not quite right, development is fast so it will get sorted out eventually". Instead it's "if it's not believed to be free of non-trivial bugs, don't commit it at all". SEPostgres has lived in this state for a while now. And it's not known bugs that are the problem, it's that almost all of the Postgres community can't even accurately gauge whether there are bugs or not in the code/design, which is really uncomfortable given how things work here. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 9 Dec 2009 00:18 David P. Quigley wrote: > On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote: > [snip...] >> I can say from experience that this project is very skeptical of >> frameworks that aren't accompanied by at least one, and preferably >> multiple, working implementations. So there is a bit of a chicken and >> egg problem here. What can sometimes work is to say, look, here's a >> place where I can put a hook and later I will do something complex >> with it but here are a couple of relatively simple but useful examples >> to get started. The examples form the justification for the commit >> because they are independently useful, but they are much simpler than >> what the framework may eventually end up being used for. >> >> I don't believe that this approach is feasible for SE-PostgreSQL. A >> simple version of label security is still going to be very >> complicated, and there are probably even fewer customers for such a >> thing than there are for SE-PostgreSQL. >> > > Ok if it is a chicken and egg problem then we need to find a smaller > egg. I agree that having a huge patch set isn't ideal which is why I > understand the desire to have KaiGai cut back his patches. However the > patches he is putting forward from what I've gathered have no row based > labeling and no MAC enforcement. I can understand if you want to cut > back the object model so you're not mediating every object in the system > but cutting those two features make it unusable by the customers we have > who want to use it. The coverage of access controls are tradeoff between amount of the changeset and valuable functionalities, in generally. Ultimately it is a role of developer to decide what is unseparatable core feture and what is separatable secondary one. It is my decision to restrict types of database objects to reduce burden of reviewers, so the latest one apply SELinux specific access controls on only databases, schemas, tables and columns. Even if we have a framework to host label-based MAC, its coverage shall be unchanged, because comprehensive support at once obviously makes harder to review. >>> So with regard to confidence in the design I think that part of the >>> reason for the skepticism in the fact that it was such a large code >>> drop. Even the separated parts were very large. >> Definitely true. >> >>> I think if the framework >>> patches are broken up more logically and in a way that is easier to >>> discuss then that might help the community get a grasp on what it is >>> trying to accomplish. >> Maybe, maybe not. Nobody's going to commit anything unless it's a >> complete feature. It can be a cut-down feature, but it has to be of >> independent use. If there are parts that can be peeled off of >> SE-PostgreSQL and committed independently to some good benefit, then I >> think that's a great idea. But if it's just a separation of the patch >> for clarity, I don't think there's much value in that. > > I don't think it would be just for clarity. I know that not all open > source communities are the same so I'll try to leave the anecdotal > evidence light. When submit patches for the Linux Kernel we take a > single feature and structure them as self contained logical changes. > Separating the changes logically doesn't just improve clarity but also > makes it easy to cherry pick features that can be useful on their own. > Just because the framework and the SEPostgreSQL features would be two > patch sets doesn't mean they aren't being developed in parallel. It > looks to me that we're in the same boat we were in with SELinux. We had > the feature and proposed it and someone brought up "well what about > other security models". So time was spent developing a framework that > everyone could use and as that was being done the SELinux patches were > modified to use this new framework. They were two separate features > developed in tandem. If we do it right the SEPostgreSQL code will be > isolated from the framework and we can spend time putting the framework > in and just plug in the specific security module when time comes. The > X-ACE work went in to X before the corresponding SELinux Flask module > for it and I don't believe LSM and SELinux went into the same merge > window as well. It is necessary to deploy the framework and SELinux support at same time or the framework earlier than SELinux? We can organize a common framework when the second security module will come in. From our experience, it may need similar security hooks on same or similar strategic points. In the development history, the code size and complexity had been a matter for inclusion. I also think the idea to invoke security modules via mac framework is right approach, but it increases the initial code size compared to the current approach in spite of even user visible whorth. >> I have proofread earlier versions of the docs and found them >> inadequate. There were language issues, but the bigger problem was >> that they were both too specific and yet not sufficiently detailed. >> For example, they'd say "install X package on Red Hat". Well, what if >> I'm not on Red Hat? The on the other hand they'd say "this GUC >> enables mcstrans" which means nothing to me. I think this has been >> improved somewhat in more recent version, but clearly we need (1) good >> developer documentation, so someone other than KaiGai has a chance of >> maintaining the code and keeping it correct as other things are >> changed; (2) user documentation, so that someone can read the "feature >> story" for this capability; and (3) reference documentation, >> cross-referenced with the user documentation. >> >> Having said that, fixing the documentation won't get this patch >> committed, though it's certainly a step in the right direction. For >> that we need a committer-owner. >> > > True but hopefully proper documentation will help someone decide that > they have enough information to take on that position. If you have any concern about documentations, I very welcome any feedbacks. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 9 Dec 2009 01:44
2009/12/9 Bruce Momjian <bruce(a)momjian.us>: > I frankly think the patch should be thought of as the SE-Linux-specific > directory files, which KaiGai can maintain, and the other parts, which I > think I can handle. I think that's a horribly bad idea. We have already got a similar issue with ECPG, which clearly stagnates whenever Michael is busy and don't have time to go through the patches. Because it's "his code", and nobody else knows how to and/or cares to maintain it. And this is just a single piece of the frontend that doesn't affect anything else. If you want to do something similar for sepg, then sepg needs to be turned into a full plugin system, where the plugin is a completely separate thing. In which case the plugin can be developed separately, for example on pgfoundry (and be considered to merge later, if we want, but not necessarily ever since it has a narrow user base). I haven't looked at the patch properly for quite a while, but I imagine turning it into such a plugin is not feasible. Because if it is, why haven't this been done already? :) But if it is, perhaps that is something we should consider, since it lessens the maintenance burden into "just" the API (which is still a huge burden compared to many of our APIs, but it is a lot less than what the patch is now) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |