Adding support for SE-Linux security
in [PgSql]
|
From: KaiGai Kohei on 7 Dec 2009 20:27 Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian <bruce(a)momjian.us> writes: >>> Robert Haas wrote: >>>> 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. >> That leaves a wide gray area where there are a few people using it but >> not really enough to justify the support effort. Even if there are >> demonstrably no users (which can never be demonstrated in practice), >> politically it's very hard to rip out a "major feature" --- it makes the >> project look bad. So I think the above is Pollyanna-ish nonsense. > > I don't even know what "Pollyanna-ish nonsense" means, and it would be > better if you used less flowery/inflamitory prose. Apart from standpoint of the discussion, idiomatic phrases are not oftern friendly for non-native English speakers. >> Once we ship a release with SEPostgres in it, we're committed. > > The MS Windows port took 1-2 years to solidify and during the > solidification period we accepted problems and didn't treat it as a > major platform. I think if SE-Linux support is added, there would be a > similar period where the features is not treated as major while we work > out any problems. We might even label it that way. It also seems to me an realistic attitude. The first guy needs courage independently from the class of features. Thus, anybody attend to see case examples in conferences. I don't think here is no fundamental differences. > Labeling SE-Postgres as such might minimize the political problems of > removing it in the future, if that becomes necessary. For us, the name is not an important issue. And, I believe our continued contributions in the future shall make it unnecessary to remove it later. 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
From: KaiGai Kohei on 7 Dec 2009 20:42 Robert Haas wrote: > On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(a)momjian.us> wrote: >> 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. > > Well, there's no point in putting that framework back in unless we can > make it sufficiently general that it could be used to serve the needs > of more than one security model. And so far, the signs have not been > promising. David Quigley suggests downthread that making a truly > general model isn't really possible, and he may be right, or not. I > was just mentioning that it's an angle I have been thinking about > investigating, but it may be a dead end. I also agree that the common framework just increases complexity of the patch at the moment. > The real issue is making the code committable, and then maintaining > it, as Tom rightly says, forever. We've got to make sure that we're > willing to take that on before we do it, and I don't think it's a > small task. It isn't so much whether we want the feature as whether > the level of effort is proportionate to the benefit. Needless to say, we can provide development resource to maintain this feature. If we escape to anywhere just after commit it, it will be removed as Bruce pointed out. But it shall be incorrect. 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
From: KaiGai Kohei on 7 Dec 2009 21:33 I could not find the message from David P. Quigley in the list, although pgsql-hackers(a)postgresql.org was Cc:'ed. (something troubled?) So, I'll send it again for your information. -------- Original Message -------- Subject: Re: [HACKERS] Adding support for SE-Linux security Date: Mon, 07 Dec 2009 14:53:03 -0500 From: David P. Quigley <dpquigl(a)tycho.nsa.gov> Organization: National Security Agency To: Tom Lane <tgl(a)sss.pgh.pa.us> CC: Bruce Momjian <bruce(a)momjian.us>, Robert Haas <robertmhaas(a)gmail.com>, Josh Berkus <josh(a)agliodbs.com>, KaiGai Kohei <kaigai(a)ak.jp.nec.com>, jd(a)commandprompt.com, David Fetter <david(a)fetter.org>, Itagaki Takahiro <itagaki.takahiro(a)oss.ntt.co.jp>, KaiGai Kohei <kaigai(a)kaigai.gr.jp>, pgsql-hackers(a)postgresql.org References: <200912071800.nB7I0KB01863(a)momjian.us> <21873.1260209825(a)sss.pgh.pa.us> On Mon, 2009-12-07 at 13:17 -0500, Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > Robert Haas wrote: > >> 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. > > That leaves a wide gray area where there are a few people using it but > not really enough to justify the support effort. Even if there are > demonstrably no users (which can never be demonstrated in practice), > politically it's very hard to rip out a "major feature" --- it makes the > project look bad. So I think the above is Pollyanna-ish nonsense. > Once we ship a release with SEPostgres in it, we're committed. > > > 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. > > The main problem I saw with ACE was that it didn't appear to actually > add any flexibility --- it was just an extra layer of function calls > in an entirely SELinux-centric design. In order to have a "pluggable > interface" layer that is worth the electrons it's written on, you need > to start out with more than one target system in mind to be plugged in. > So that would mean, at minimum, investigating something like AppArmor or > TrustedSolaris to see what its needs are before we sit down to design > the plugin layer. (Which, of course, nobody here is actually interested > enough to do. But without that research there is no point in demanding > a plugin layer.) > > regards, tom lane > Not to start a flame war here about access control models but you gave 3 different examples one of which I don't think has any means to do anything productive here. Looking at the 3 examples you gave and what SEPostgres is trying to accomplish here is what I see. The point of SEPostgres is to do object labeling in a database. Two of the three examples you gave are label based security mechanisms. AppArmor while it might be able to have a scheme to mediate access to database/table doesn't seem to have a reasonable way to write policy to individual records. Since AppArmor is path name based you need an identifiable path to whatever you want to write access control rules for. With something like a database where data dynamically comes and goes and changes doing rules on individual records seems difficult. I also can't find any information about AppArmor being used as a user-space object manager. If someone wants to prove me wrong I'm willing to listen to their argument. Lets look at the remaining two. Do you really mean TrustedSolaris(TSOL) or do you mean Solaris with Trusted Extensions(TX). There is a big difference here. From my understanding Sun no longer supports TSOL and moved on to TX. The difference here is that they moved from fine grained object labeling to zone based labeling. There is a project currently in development (although moving a bit slow) called FMAC which will bring SELinux style MAC to Solaris which will reintroduce fine grained labeling. You will still be able to use zones however process and object labels will not be based on zone in FMAC. I understand the concerns with a generic framework introducing a lot of code. The Linux Kernel LSM Framework seems to grow as more models are introduced but if you want to support various models you have to live with the fact that there is no common interface for all of these systems. It has been tried numerous times in the past and has failed. >From what I've seen I think that will be less of a concern with Postgres since the objects that Kaigai wants to mediate is a much smaller set than the kernel. If you want to see another instance of where work similar to this was done you should look at the X-Access Control eXtensions (X-ACE) found in the X server. Eamon Walsh designed this framework based not on anything SELinux specific but through an analysis of the X Server which yielded a list of object he though needed mediating. There are two modules for X-ACE now the FLASK module (SELinux) and a module put forth by Casey Schaufler for his SMACK work. >From what I've seen on the SELinux list Kaigai's design of SEPostgres was conducted in a similar way. I'll be willing to answer any questions you have for me in order to help Kaigai's work along. Normally another member of our team would be participating in this but he is unavailable at the moment. When he is available again I'm sure he will participate in the discussion. -- 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
From: Alvaro Herrera on 7 Dec 2009 21:57 KaiGai Kohei escribi�: > I could not find the message from David P. Quigley in the list, > although pgsql-hackers(a)postgresql.org was Cc:'ed. > (something troubled?) Weird. It didn't even made it to the moderator queue for some reason. Perhaps the system dropped it as spam. > So, I'll send it again for your information. Good move. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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: Greg Smith on 7 Dec 2009 22:25
David P. Quigley wrote: > Not to start a flame war here about access control models but you gave 3 > different examples one of which I don't think has any means to do > anything productive here. You won't be starting a flame war for the same reason some of the community members are so concerned about this patch. There aren't enough people familiar with this part of the security field within our database developer community to even be able to answer fairly basic questions like the one you just clarified. If you can help bring more qualified reviewers to bear on that, it would be extremely helpful. I even tried to organize a meetup between PostgreSQL hackers working in this area and the security people I knew around here (Baltimore/DC) last year, but just couldn't find any interested enough to show. Other than a brief visit on this list from some of the Tresys guys, we haven't seen much input here beyond that offered by the patch author, who's obviously qualified but at the end of the day is still only one opinion. He's also not in a good position to tell other people their ideas are misinformed either. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.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 |