Adding support for SE-Linux security
in [PgSql]
|
From: Tom Lane on 11 Dec 2009 19:52 Robert Haas <robertmhaas(a)gmail.com> writes: > What exactly do you mean by a SubOID? I'm not really following that part. I assume he's talking about the object reference representation used in pg_depend, which is actually class OID + object OID + sub-object ID. The only object type that has sub-objects at the moment is tables, wherein the sub-objects are columns and the sub-object IDs are column numbers. The sub-object ID is zero for all other cases. 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: KaiGai Kohei on 11 Dec 2009 20:02 Robert Haas wrote: > 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. Theoretically, (x,y,u) -> (x,y,u,v) -> (x,y,u,v,w) may happen. However, if the new suggested security model is too far from the known security model, we should consider whether it performs correctly at first before commit it. As long as we describe a security model corresponding to database objects, it is hard to consider a possibility of infinite increasing in the future. Thanks, -- KaiGai Kohei <kaigai(a)kaigai.gr.jp> -- 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: Bruce Momjian on 11 Dec 2009 20:41 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > Unlike Tom (I think), I do believe that there is demand (possibly only > > from a limited number of people, but demand all the same) for this > > feature. > > Please note that I do not think there is *zero* demand for the feature. > There is obviously some. What I find highly dubious is whether there is > enough demand to justify the amount of effort, both short- and long-term, > that the community would have to put into it. Well, the bottom line is that this effort should grow the development and user community of Postgres --- it if doesn't, it is a failure. > > And I also believe that most people in our community are > > generally supportive of the idea, but only a minority are willing to > > put in time to make it happen. So I have no problem saying to the > > people who want the feature - none of our committers feel like working > > on this. Sorry. On the other hand, I also have no problem telling > > them - good news, Bruce Momjian thinks this is a great feature and > > wants to help you get it done. I *do* have a problem with saying - we > > don't really know whether anyone will ever want to work on this with > > you or not. > > If I thought that Bruce could go off in a corner and make this happen > and it would create no demands on anybody but him and KaiGai-san, I > would say "fine, if that's where you want to spend your time, go for > it". But even to state that implied claim is to see how false it is. > Bruce is pointing to the Windows port, but he didn't make it happen > by himself, or any close approximation of that. Everybody who works > on this project has been affected by that, and we're *still* putting > significant amounts of time into Windows compatibility, over five years > later. The Windows port was primiarly done by Magnus, Claudio Natoli, and Andrew Dunstan. The good thing about that group is that their involvement in Win32 did not take them away from existing Postgres work --- in fact I think it increased Magnus's and Andrew's involvement. As I stated above, I expect the SE-Postgres work to be done mostly by new people and to expand our development team. KaiGai is certainly a new addition, and I think there is already an indication that new people are getting involved. Of course, our existing people will have to help too, but as I stated a few days ago, I expect security-specific stuff to be maintained mostly by new people, and our existing folks are going to have to help with hooks, plus adding things like mandatory access control and row-level security to base Postgres. (I do think it is inevitable that those will be added some day. I agree the security folks will be accelerating that. Hopefully we will get more good out of this than the inconvenience of this accelerated security stuff.) > My guess is that a credible SEPostgres offering will require a long-term > amount of work at least equal to, and very possibly a good deal more > than, what it took to make a native Windows port. If SEPostgres could > bring us even 10% as many new users as the Windows port did, it'd > probably be a worthwhile use of our resources. But again, that's an > assumption that's difficult to type without bursting into laughter. Odds are SEPostgres will add perhaps 1% new users compared to Win32, but perhaps very important, energetic, and visible users. As stated earlier, the base Postgres security additions like row-level security are going to be inconvenient, but I do think we will eventually need them anyway, so I don't see them as SE-Postgres burdens. I am not replying to many of these emails so I don't appear to be brow-beating (forcing) the community into accepting this features. I might be brow-beating the community, but I don't want to _appear_ to be brow-beating. ;-) -- 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: Robert Haas on 11 Dec 2009 20:49 On Fri, Dec 11, 2009 at 8:41 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > I am not replying to many of these emails so I don't appear to be > brow-beating (forcing) the community into accepting this features. I > might be brow-beating the community, but I don't want to _appear_ to be > brow-beating. ;-) LOL. At least you're honest... ....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: Bruce Momjian on 11 Dec 2009 20:59
Ron Mayer wrote: > Bruce Momjian wrote: > > Well, the bottom line is that this effort should grow the development > > and user community of Postgres --- it if doesn't, it is a failure. > > Really? Even if it only allows existing Postgres users and companies to > expand their use into higher security applications IMHO it's a success. > > If a main goal were increasing users, implementing MySQL-isms > and MSFTSqlServer-isms would seem the biggest bang for the buck. Well, it should expand the user-base because right now we don't have many current users who are looking for these features --- if we did, it would be an easy decision to add these features. Second, it should add new developers because we have limited developer resources, and I am not sure adding additional security is at the top of our priority list, and we don't have many security-expert developers so by definition we need more to implement this reliably. These might be unpleasant opinions, but I believe they are accurate. -- 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 |