Adding support for SE-Linux security
in [PgSql]
|
From: Stephen Frost on 11 Dec 2009 15:28 * Robert Haas (robertmhaas(a)gmail.com) wrote: > OK, it's clear that I've handled this badly. Sorry. My fear (however > unjustified) was that someone would go and rewrite the patch based on > an opinion that I express whether they agree with it or not. That's always going to be a risk in an open-discussion environment. Additionally, that's exactly what happened to me last go round- KaiGai rewrote the patch based on my ideas and suggestions, and the result was summarairly tossed out by Tom. Did it suck? Yes, heavily, and it frustrated me to the point that I specifically asked to not be the reviewer for SEPG during the next commitfest. At the same time, what KaiGai or others spend time on is up to them (and/or their employers). I sincerely hope that even if you suggest an approach down the road unrelated to this on some other patch you're reviewing, and then you see the results and say "whoah, that's horrible, and should never be committed", that you understand none of us would want you to commit it. Sharing your ideas or putting out suggestions isn't a commitment on your part that you'll commit the results when someone else rights it. Heck, I bet you've been down that road on your own projects and come to the realization at the end of "err, bad idea" and not committed it. Allow me to say, my apologies, I feel like I may have over-reacted a bit for my part as well. > So with that said, the idea I had was to try to pass around > pre-existing data structures related to the objects on which access > control decisions are being made, rather than Oids. That thought had crossed my mind as well, but I wasn't convinced that would actually be seen as a signifigantly different API to just having the arguments passed inline... Then again, using structures does allow you to add to them without having to modify the function definitions, and would allow David's suggestion of using function pointers to work, which we do in some other specific cases. I guess I'm curious if we (PG) have any particular feeling one way or the other about function pointers; I just don't recall seeing them used terribly often and would worry about that they might be passively discouraged? > It does have a bit of a rock management feel to it and I > really want to see if we can find a way to break that cycle. Agreed. It's been a point of frustration for me, but I've been trying to work with it so long as we at least get some constructive critisim back (Tom's review of the patch I reviewed fell into the "questionable" category for me on that call, which is what really frustrated me the most about it). A cyclic approach is typical in all software development, it's when information stops flowing about why something doesn't meet expectations or requirments that progress breaks down. Thanks! Stephen
From: Stephen Frost on 11 Dec 2009 16:26 * Robert Haas (robertmhaas(a)gmail.com) wrote: > On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost <sfrost(a)snowman.net> wrote: > > Second, the information we *don't* have from above is generally > > information about what the requesting action is. For example, when > > changing ownership of an object, we can't possibly use introspection to > > find out the role which is on the receiving end, since at that time > > we've just learned it from the parser. > > I'm not sure that I follow what you're saying here. I think maybe it > would help to discuss a concrete example, which is why I proposed a > concept patch. Or perhaps you'd like just to pick out a specific case > to discuss. Hrm, I thought I had given a specific example. Didn't do a good job of it, apparently. Let me try to be a bit more clear: ALTER TABLE x OWNER TO y; If given the table OID, there's a ton of information we can then pull about the table- the tablespace, the owner, the schema, the columns, the privileges, etc, etc. What we can't possibly figure out from the OID is the value of y. Yet, in the PG security model, the value of y matters! You have to know what y is to check if y has 'create' rights on the schema. If it doesn't (and the user executing the command isn't the superuser) then the request (under the PG model) is denied. Does that help clarify my example case? > Object creation seems to be one of the tougher cases here. When > you're altering or dropping an existing object, the decision is likely > to be based (in any system) on the properties of that object. When > you're creating an object, the decision will of course have to be > based on the properties of something else, but different access > control models might not agree on the value of "something else". It's > not immediately clear to me how to deal with that, but again it's hard > for me to discuss it in the abstract. That sounds like a pretty good example to me too, to be honest. It goes back to the same issue though- that's information you get from the command that's trying to be run and isn't available from existing objects. Using structures to track this information, allowing the function arguments to remain identical, is certainly something which can be done, and probably done with a minimal amount of fuss. Thanks, Stephen
From: Stephen Frost on 11 Dec 2009 16:29 Stephen (great name!), * Stephen Smalley (sds(a)tycho.nsa.gov) wrote: > Reference: > http://www.usenix.org/event/sec02/wright.html > http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h > > The XACE framework for the X server is described by: > http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html > > The FreeBSD MAC framework is described by: > http://www.freebsd.org/doc/en/books/arch-handbook/mac.html Thanks for these pointers! I'm sure KaiGai has probably already done a review of these, but I'll take a look and would ask others who are interested to please do the same. Seeing the different options that people have gone with (as opposed to just the SELinux/kernel version) will undoubtably be helpful in deciding the best approach forward. Thanks again! Stephen
From: Robert Haas on 11 Dec 2009 16:34 On Fri, Dec 11, 2009 at 3:28 PM, Stephen Frost <sfrost(a)snowman.net> wrote: > I sincerely hope that even if you suggest an approach down the road > unrelated to this on some other patch you're reviewing, and then you see > the results and say "whoah, that's horrible, and should never be > committed", that you understand none of us would want you to commit it. I have to thank you for saying this - unfortunately, I don't think everyone takes this approach. As you can probably figure out, my alleged rock management upthread was actually a poorly executed attempt to avoid being accused of bait-and-switch. If I don't tell you how to write the patch, you can't accuse me of moving the goalposts (of course I've now discovered the pitfalls of that approach as well...). > Sharing your ideas or putting out suggestions isn't a commitment on your > part that you'll commit the results when someone else rights it. Heck, > I bet you've been down that road on your own projects and come to the > realization at the end of "err, bad idea" and not committed it. Well, I haven't been a committer long enough to have gone through that precise process, but sure, I've tossed out ideas when they don't turn out to be good. >> So with that said, the idea I had was to try to pass around >> pre-existing data structures related to the objects on which access >> control decisions are being made, rather than Oids. > > That thought had crossed my mind as well, but I wasn't convinced that > would actually be seen as a signifigantly different API to just having > the arguments passed inline... If you'll forgive me for saying so, this is exactly the sort of thinking that I think is killing us. Who cares how it will be seen? Seen by whom? We shouldn't be writing this code to be seen - we should be writing it to be good. If doing this makes a clean, tight abstraction layer, then it's a good design. If it doesn't, then it sucks. I realize that opinions enter into this at some level, but let's try to proceed as though there's a technically right answer out there and bend our best efforts to finding it. > Then again, using structures does > allow you to add to them without having to modify the function > definitions, Personal opinion time, but I think that "without having to modify the function definitions" is a CRITICAL design component. Furthermore, "adding to them [the structures]" shouldn't be something that only happens when we decide to support a new security model, or we're little better off than if we just passed a kajillion arguments. Again, I don't want to overstate my confidence in this point, but it feels to me like we need to pass PRE-EXISTING data structures that are already being used for other things and happen to be the right stuff to enable access control decisions, and to which fields that are likely to be needed are likely to get added anyway. But it's difficult to know whether this approach can be made to work without trying it, and there are bound to be problem cases that need to be thought about, and that thinking will be more likely to lead to a good result if it happens in the community, rather than by KaiGai or any other single person in isolation. > and would allow David's suggestion of using function > pointers to work, which we do in some other specific cases. I guess I'm > curious if we (PG) have any particular feeling one way or the other > about function pointers; I just don't recall seeing them used terribly > often and would worry about that they might be passively discouraged? I'm going to vote fairly strongly against inserting function pointers at the outset. I think that we should look at the first phase of this project as an attempt to restructure the code so that the access control decisions are isolated from the rest of the code. *If* we can do that successfully, I think it will represent good progress all on its own. Inserting function pointers is something that can be done later if it turns out to be useful with a very small, self-contained patch. >> It does have a bit of a rock management feel to it and I >> really want to see if we can find a way to break that cycle. > > Agreed. It's been a point of frustration for me, but I've been trying > to work with it so long as we at least get some constructive critisim > back (Tom's review of the patch I reviewed fell into the "questionable" > category for me on that call, which is what really frustrated me the > most about it). A cyclic approach is typical in all software > development, it's when information stops flowing about why something > doesn't meet expectations or requirments that progress breaks down. Part of my frustration here is that I don't see a lot of evidence that anyone is willing to put really tangible resources into this other than KaiGai and his employer. I don't want to keep reviewing the same patches over again just because they keep getting resubmitted with various modifications. I am willing to try to be helpful with this project if that is something that you and others who are involved feel is helpful and if it can be done with a small time commitment or if, uh, I get paid. But I don't want to see a lot of community resources go into a project that is basically doomed from the get-go because KaiGai is the only one caring about it. This has already gone on for a really long time with less progress than might be hoped for, and if it's not going to live, I want it to die. Having it stick around as a zombie is the worst possible outcome. ....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: Robert Haas on 11 Dec 2009 16:41
On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost(a)snowman.net> wrote: > Hrm, I thought I had given a specific example. Didn't do a good job of > it, apparently. Let me try to be a bit more clear: > > ALTER TABLE x OWNER TO y; > > If given the table OID, there's a ton of information we can then pull > about the table- the tablespace, the owner, the schema, the columns, the > privileges, etc, etc. > > What we can't possibly figure out from the OID is the value of y. Yet, > in the PG security model, the value of y matters! You have to know what > y is to check if y has 'create' rights on the schema. If it doesn't > (and the user executing the command isn't the superuser) then the > request (under the PG model) is denied. > > Does that help clarify my example case? That case doesn't seem terribly problematic to me. It seems clear that we'll want to pass some information about both x and y. What is less clear is exactly what the argument types will be, and the right answer probably depends somewhat on the structure of the existing code, which I have not looked at. What I'm more concerned about is if the access control decision in this case were based on u for PG DAC, v for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System. If that's the case, and our function signature looks like (x,y,u,v,w), the we should worry. ....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 |