Adding support for SE-Linux security
in [PgSql]
|
From: Stephen Frost on 8 Dec 2009 15:24 * 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. Indeed, as I recall, the patch I reviewed was primairly trying to just addess pulling out the hooks necessary for the existing PostgreSQL security model. Very little of it was SE-Linux specific *anything*. I contend that while the specific hooks which would be added *in places that don't already have checks* (in most places, the hook was added to replace an existing check) are hooks that then make sense for SELinux, they would also make sense for other frameworks. They may also not be a complete list, but once the *framework* is in place, adding new hooks (presuming another model would like a hook somewhere that SELinux and the existing PG security framework don't) should not require some kind of forklift upgrade. > It would be nice > if it were possible to use the exist permissions-checking functions > and have them check a few more things while they're at it, but it's > looking like that won't be feasible, or at least no one's come up with > a plausible design yet. The problem is that the existing permissions-checking is done all over the place. That's not ideal from the get-go, in my opinion. Unfortuantely, when we moved all of the permissions-checking to a single place, it required knowing about alot of the backend, which Tom took exception to. 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. Perhaps we need to better expose just those pieces the security framework cares about from the other parts of the backend- it's entirely likely that the reason it has to know about everything is that, due to where all the existing security checks are, they just (ab)used the fact that they had access to that information at hand for that object type. > Consequently there are checks spread > throughout the code, which definitely complicates both validation and > maintenance. One question I have is - are the places where those > checks are placed specific to SE-Linux, or would they be applicable to > any sort of label-based MAC? The patch which I worked with Kaigai on was specifically geared to first try to get a patch which addressed the existing PG security model in a modular way, to allow additional hooks to be added later in places which needed them, and to provide the information for other models to make a decision about the permission. I don't feel it was particularly SE-Linux specific at all, but rather a first step towards being able to support something beyond the model we have today (anything..). Thanks, Stephen
From: Robert Haas on 8 Dec 2009 15:26 On Tue, Dec 8, 2009 at 2:50 PM, David P. Quigley <dpquigl(a)tycho.nsa.gov> wrote: > On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote: >> On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> > Robert Haas <robertmhaas(a)gmail.com> writes: >> >> 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. It would be nice >> >> if it were possible to use the exist permissions-checking functions >> >> and have them check a few more things while they're at it, but it's >> >> looking like that won't be feasible, or at least no one's come up with >> >> a plausible design yet. >> > >> > I don't think that it's about SELinux. The real issue here is that >> > KaiGai-san is about a mile out in front of the PG hackers community >> > in terms of his ambitions for the scope of what can be controlled by >> > security policy. If the patch were only doing what the community has >> > actually agreed to, there would be little need for it to touch anything >> > but the aclcheck functions. >> > >> > Now I recognize that a large part of the potential attraction in this >> > for the security community is exactly the idea of having fine-grain >> > security control. But if you ever want anything significantly different >> > from SQL-standard permission mechanisms, there's going to have to be a >> > whole lot more work done. Basically, nobody in the PG community has got >> > any confidence either in the overall design or the implementation >> > details for locking things down that aren't already controlled by SQL >> > permission mechanisms. >> >> I think that's basically right. Further, I think this is basically a >> resource issue. If you were inclined to spend a large amount of your >> time on this problem, you could either gain confidence in the present >> design and implementation or come up with a new one in which you did >> have confidence. But it doesn't seem important enough to you (or your >> employer) for the amount of time it would take, so you're not. I >> think there are other committers and community members in a similar >> situation - basically all of them. > > I have to agree with Chad (downthread) that I don't see much in KaiGai's > hook patch that prevents its use by other security models. I will say > though one thing that might have been done wrong was with how it was > presented. In actuality his patch set is two projects (at least). The > first is the framework. So I think the goal should have been to get the > framework integrated first and then work on the SELinux module after > that. The framework patch alone consists of at least 4 sets of logical > changes that could have been separated to make review easier. Once the > framework was in, work could be done to get the SELinux module in while > reducing overhead from the case where no module is loaded. 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. > 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. > In terms of documentation I was reading through the wiki at > sepgsql.googlecode.com and aside from some wordsmithing/grammar things > it is pretty solid with describing what it is trying to accomplish. One > problem that I see is that at first glance it does appear to be very > SELinux centric. It describes access based on types and SELinux contexts > which is understandable based on the fact that it describes the > framework and the module. Something to note is that the documentation > describes an object model for the program. I think that would be a good > place to focus the discussion with respect to a framework if we decide > to pursue it. 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. ....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:14 On Tue, 2009-12-08 at 15:24 -0500, Stephen Frost 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. > > Indeed, as I recall, the patch I reviewed was primairly trying to just > addess pulling out the hooks necessary for the existing PostgreSQL > security model. Very little of it was SE-Linux specific *anything*. > > I contend that while the specific hooks which would be added *in > places that don't already have checks* (in most places, the hook was > added to replace an existing check) are hooks that then make sense > for SELinux, they would also make sense for other frameworks. They > may also not be a complete list, but once the *framework* is in > place, adding new hooks (presuming another model would like a hook > somewhere that SELinux and the existing PG security framework don't) > should not require some kind of forklift upgrade. > > > It would be nice > > if it were possible to use the exist permissions-checking functions > > and have them check a few more things while they're at it, but it's > > looking like that won't be feasible, or at least no one's come up with > > a plausible design yet. > > The problem is that the existing permissions-checking is done all over > the place. That's not ideal from the get-go, in my opinion. > Unfortuantely, when we moved all of the permissions-checking to a single > place, it required knowing about alot of the backend, which Tom took > exception to. 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. Perhaps we need to better expose just those pieces the > security framework cares about from the other parts of the backend- it's > entirely likely that the reason it has to know about everything is that, > due to where all the existing security checks are, they just (ab)used > the fact that they had access to that information at hand for that > object type. > > > Consequently there are checks spread > > throughout the code, which definitely complicates both validation and > > maintenance. One question I have is - are the places where those > > checks are placed specific to SE-Linux, or would they be applicable to > > any sort of label-based MAC? > > The patch which I worked with Kaigai on was specifically geared to first > try to get a patch which addressed the existing PG security model in a > modular way, to allow additional hooks to be added later in places which > needed them, and to provide the information for other models to make a > decision about the permission. I don't feel it was particularly > SE-Linux specific at all, but rather a first step towards being able to > support something beyond the model we have today (anything..). > > Thanks, > > Stephen I think what makes people think that the changes are SELinux specific is that the examples given use SELinux contexts. I think it should be made clear that saying that in the PG there is a database object and we want to mediate access to create database objects is not SELinux or even MAC model specific (asside from labels). However to say that a program labeled myapp_t can connect to the database and create a table and when its created its labeled mytable_t that would be something SELinux specific. The framework idea separates that. It says hey here are the objects in the system and here are the actions on them that we want to mediate. I will admit that since SELinux is the driving MAC model for the framework you're going to find that the objects and permissions are the ones that it wants to control. However like Steven said, adding a hook later on or having a model not use a hook is not a Herculean task. We've proven time and time again with the LSM framework that when a feature is added it is trivial to introduce a new hook to mediate it or to place an existing hook. 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. 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: Peter Eisentraut on 8 Dec 2009 16:29 On mån, 2009-12-07 at 17:33 +0100, Martijn van Oosterhout wrote: > On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote: > > > Given the extreme patience and diligence exhibited by KaiGai, I > > > hesitate to say this, but it seems to me that this would be > > > critically important for the long term success of this feature. I > > > have no idea how much work it would be to make the interface to the > > > external security system pluggable, but if it's at all feasible, I > > > think it should be done. > > > > This is how the code was developed initially -- the patch was called > > PGACE and SELinux was but the first implementation on top of it. > > I find it astonishing that after SE-PgSQL was implemented on top of a > pluggable system (PGACE) and this system was removed at request of the > "community" [1] that at this late phase people are suggesting it needs > to be added back again. Havn't the goalposts been moved enough times? 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. -- 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: Peter Eisentraut on 8 Dec 2009 16:31
On mån, 2009-12-07 at 11:45 -0500, Chris Browne wrote: > I feel about the same way about this as I did about the adding of > "native Windows" support; I'm a bit concerned that this could be a > destabilizing influence. I was wrong back then; the Windows support > hasn't had the ill effects I was concerned it might have. Windows support certainly has had ill effects, but the benefits of supporting Windows clearly outweigh that. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |