Adding support for SE-Linux security
in [PgSql]
|
From: Martijn van Oosterhout on 7 Dec 2009 11:33 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? [1] http://archives.postgresql.org/pgsql-hackers/2009-01/msg02295.php (It seems we've gone from a patch that had been around for years solving actual people's problems to a patch which does barely anything and we don't know whether it solves anybodies problem). Have a nice day, -- Martijn van Oosterhout <kleptog(a)svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
From: Tom Lane on 7 Dec 2009 11:54 Martijn van Oosterhout <kleptog(a)svana.org> writes: > 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? The reason the goalposts keep moving is that nobody has a very clear handle on what the requirements are, which stems from the lack of a clear target community with definable needs. We have had a couple of apparently-knowledgeable people pop up and say "you should do this", but then they disappear again without sticking around for any detailed discussion of features (let alone code). > (It seems we've gone from a patch that had been around for years > solving actual people's problems to a patch which does barely anything > and we don't know whether it solves anybodies problem). Do we know that any version of this patch has solved any actual people's problems? I know KaiGai-san has been putting it out as a Fedora package but there's little if any evidence that anyone's actually using that. 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: Chris Browne on 7 Dec 2009 11:45 tgl(a)sss.pgh.pa.us (Tom Lane) writes: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce(a)momjian.us> wrote: >>> I wonder if we should rephrase this as, "How hard will this feature be >>> to add, and how hard will it be to remove in a few years if we decide we >>> don't want it?" > >> Yes, I think that's the right way to think about it. At a guess, it's >> two man-months of work to get it in, > > It's not the "get it in" part that scares me. The problem I have with > it is that I see it as a huge time sink for future maintenance problems, > most of which will be classifiable as security breaches which increases > the pain of dealing with them immeasurably. Ah, yes, the importance of this is not to be underestimated... Once "SE-Pg" is added in, *any* bug found in it is likely to be considered a security bug, and hence a candidate for being a CERT Advisory. Some bad things are liable to happen: a) Such problems turn into a "hue and cry" situation requiring dropping everything else to "fix the security problem." b) If everyone isn't using "SE-Pg", then people won't be particularly looking for bugs, and hence bugs are likely to linger somewhat, with the consequence that a) occurs with some frequency. c) Having a series of CERT advisories issued is not going to be considered a good thing, reputation-wise! 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. I'd hope that my concerns about "SE-Pg" are just as wrong as my concerns about native Windows support. Hope doesn't make it so, alas... -- select 'cbbrowne' || '@' || 'gmail.com'; http://www3.sympatico.ca/cbbrowne/languages.html "Just because it's free doesn't mean you can afford it." -- Unknown
From: Tom Lane on 7 Dec 2009 12:21 Chris Browne <cbbrowne(a)acm.org> writes: > 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. That's an interesting analogy. I too am not entirely convinced that it's a good comparison, but if it is, consider these points: * The goal of the Windows port was pretty well-defined and easily tested: "make it work on Windows". The goalposts didn't move except perhaps when MS came out with new Windows versions. * We had a *lot* of users available to help flush out problems. * There wasn't any need to treat bugs as security sensitive, which is problematic not least because it restricts the free flow of information. Any one of those points would be good reason to think that getting SEPostgres to stability will be lots more drawn-out and painful than getting the Windows port to stability was. With all three pointing in the same direction, the tea leaves don't look good. 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: Bruce Momjian on 7 Dec 2009 13:00
Robert Haas wrote: > > Agreed. ?SE-Linux support might expand our user base and give us > > additional credibility, or it might be a feature that few people use --- > > and I don't think anyone knows the outcome. > > > > I wonder if we should rephrase this as, "How hard will this feature be > > to add, and how hard will it be to remove in a few years if we decide we > > don't want it?" ?SE-Linux support would certainly put Postgres in a > > unique security category, and it builds on our existing good security > > reputation. > > Yes, I think that's the right way to think about it. At a guess, it's > two man-months of work to get it in, and ripping it out is likely > technically fairly simple but will probably be politically impossible. I figure if there is sufficient usage, we will not need to remove it, and if there isn't, we will have no objections to removing it. > > but I am not advocating AppArmor support. ?I think the whole issue is > > whether support for external integrated security systems is appropriate > > for Postgres. > > It's not something I've run into a need for in my own work, but I > think there are definitely people out there who do need it, and I'd > like to see us be able to support it. One of the things that I think > would be worth looking into is whether there is a way to make this > pluggable, so that selinux and apparmor and trusted solaris and so on > could make use of the same framework, but that requires understanding > all of them well enough to design a framework that can meet all of > those needs. Every framework effort we've seen from KaiGai so far has > seemed extremely SE-Linux-specific and therefore pointless. But > really doing this right is a big development project, and not > something I can do in my free time. As Alvaro mentioned, the original patch used ACE but it added too much code so the community requested its removal from the patch. It could be re-added if we have a need. -- 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 |