Adding support for SE-Linux security
in [PgSql]
|
From: Robert Haas on 8 Dec 2009 16:42 On Tue, Dec 8, 2009 at 3:24 PM, Stephen Frost <sfrost(a)snowman.net> wrote: > * Robert Haas (robertmhaas(a)gmail.com) wrote: >> One of the major and fundamental stumbling blocks we've run into is >> that every solution we've looked at so far seems to involve adding >> SE-Linux-specific checks in many places in the code. > > I've really got to take exception to this. I've only been following > along and not really participating because, to be honest, I'm frustrated > with how this has gone down. In the end there were at least two > patches, in my view, that *didn't* involve adding SE-Linux-specific > checks everywhere. The patch that I reviewed that got thrown out by > Tom, and the original PGACE framework. Both of those added alot of > *hooks*, because they were necessary, but nothing made those hooks > particularly "SELinux-specifc". We're hearing alot about things being > SELinux-specific from people who also profess to not know SELinux. 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. 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. > I agree that's frustrating, but I don't see it as a > particular reason to throw out the entire concept of a modular security > framework. I don't either. There were certainly technical things in the previous patch that could stand to have been improved, and I think the general approach has some potential. ....Robert -- 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: "David P. Quigley" on 8 Dec 2009 16:41 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. > > 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. > > 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. > ...Robert -- 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: Tom Lane on 8 Dec 2009 16:51 Peter Eisentraut <peter_e(a)gmx.net> writes: > PGACE wasn't a plugin system. It was an API inside the core code. If > it had been a plugin system, this would have been much easier, because > the plugin itself could have been developed independently. Well, it should certainly have used function pointers or something to allow better pluggability, but that would have been a trivial change. I don't believe that doing so would have made development any easier. The real problem in all this is to answer the question "do we have the right hooks in the right places?". Whether the hooks lead to function pointers or hard-wired calls doesn't enter into that. Moreover, since we can confidently say that all the early answers will be "no", it would be a serious mistake to try to develop the plugin independently. Having to keep two independent sets of source code in sync would waste a lot of effort every time you realized you needed to adjust the hook definitions. Once you'd gotten to a releasable state maybe you could assume the hook definitions would become stable, but right now I have no confidence in that at all. regards, tom lane -- 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: "David P. Quigley" on 8 Dec 2009 17:42 On Tue, 2009-12-08 at 16:51 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e(a)gmx.net> writes: > > PGACE wasn't a plugin system. It was an API inside the core code. If > > it had been a plugin system, this would have been much easier, because > > the plugin itself could have been developed independently. > > Well, it should certainly have used function pointers or something to > allow better pluggability, but that would have been a trivial change. > I don't believe that doing so would have made development any easier. > The real problem in all this is to answer the question "do we have the > right hooks in the right places?". Whether the hooks lead to function > pointers or hard-wired calls doesn't enter into that. Moreover, since > we can confidently say that all the early answers will be "no", it would > be a serious mistake to try to develop the plugin independently. > Having to keep two independent sets of source code in sync would waste > a lot of effort every time you realized you needed to adjust the hook > definitions. Once you'd gotten to a releasable state maybe you could > assume the hook definitions would become stable, but right now I have no > confidence in that at all. > > regards, tom lane > I disagree with several of your statements above. While the question of whether or not the hooks are in the right place is up for debate what the hooks should be is something that I think has been explored pretty well. The hooks should reflect the object model. Where you need to put them to enforce permission is a different story. Also maintaining a module and a framework is not a waste of time. If your security module has a tremendous code churn when the interface to the program is modified you should reevaluate your design. Both SELinux and the Flask X-ACE modules are examples where an existing extension had a modular framework developed after the fact and easily integrated into the project. The majority of the work is moving to a framework not changing function prototypes in code that's already in the framework. Dave -- 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 19:19
Robert Haas wrote: > On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley <dpquigl(a)tycho.nsa.gov> wrote: >> I'd be willing to take a look at the framework and see if it really is >> SELinux centric. If it is we can figure out if there is a way to >> accomodate something like SMACK and FMAC. I'd like to hear from someone >> with more extensive experience with Solaris Trusted Extensions about how >> TX would make use of this. I have a feeling it would be similar to the >> way it deals with NFS which is by having the process exist in the global >> zone as a privileged process and then multi-plexes it to the remaining >> zones. That way their getpeercon would get a label derived from the >> zone. > > Well, the old patches should still be available in the mailing list > archives. Maybe going back and looking at that code would be a good > place to start. The non-ripped-out code has been cleaned up a lot > since then, but at least it's a place to start. We can see old branches here: http://code.google.com/p/sepgsql/source/browse/branches/pgsql-8.3.x/sepgsql/src/backend/security/pgaceHooks.c But I don't provide this framework for the 8.4.x/8.5.x, because this idea was rejected in the earlier discussion. Please consider it represent just a concept. 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 |