Adding support for SE-Linux security
in [PgSql]
|
From: Ron Mayer on 2 Dec 2009 20:10 KaiGai Kohei wrote: > Needless to say, NEC is also a supporter to develop and maintain > SE-PgSQL feature. We believe it is a necessity feature to construct > secure platform for SaaS/Cloud computing, so my corporation has funded > to develop SE-PgSQL for more than two years. Rather than "needless to say", I think this is worth elaborating on. Knowing how companies like NEC and their customers see SELinux and SE-PgSQL help their database projects would probably be one of the most compelling stories for getting broader support for the feature. Before googling "nec software" after seeing you mention this, I knew very little about NEC's software business. I can read some about NEC's software/database business for NEC North America's[1] and NEC Global Services[2] but imagine globally there's even more to it than that. Understanding how SE-PgSQL (and presumably SE-Linux) helps build a better SaaS/Cloud computing platform would probably help many people support this feature more. The cloud computing platforms I see more are ones that isolate a user's data either at a higher application layer (like salesforce) or a lower virtual machine layer (like amazon's elastic cloud). Is a vision of SE-PgSQL to help cloud computing companies sell customers access to a single underlying postgres instance, and share selected data between each other at a row level? Just curious. [1] http://www.necam.com/EntSw/ [2] http://www.necgs.com/partners.php -- 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 2 Dec 2009 20:58 Ron Mayer wrote: > KaiGai Kohei wrote: >> Needless to say, NEC is also a supporter to develop and maintain >> SE-PgSQL feature. We believe it is a necessity feature to construct >> secure platform for SaaS/Cloud computing, so my corporation has funded >> to develop SE-PgSQL for more than two years. > > Rather than "needless to say", I think this is worth elaborating on. > > Knowing how companies like NEC and their customers see SELinux and > SE-PgSQL help their database projects would probably be one of the > most compelling stories for getting broader support for the feature. > > Before googling "nec software" after seeing you mention > this, I knew very little about NEC's software business. > I can read some about NEC's software/database business for > NEC North America's[1] and NEC Global Services[2] but imagine > globally there's even more to it than that. I'm talking about our future business, not existing one. Anyway, what is important here is that out corporation makes a decision to contribute to develop and maintain an innovative OSS project rather than what our business works well. > Understanding how SE-PgSQL (and presumably SE-Linux) helps > build a better SaaS/Cloud computing platform would probably > help many people support this feature more. The cloud computing > platforms I see more are ones that isolate a user's data either > at a higher application layer (like salesforce) or a lower > virtual machine layer (like amazon's elastic cloud). Is a > vision of SE-PgSQL to help cloud computing companies sell > customers access to a single underlying postgres instance, > and share selected data between each other at a row level? > Just curious. Basically, note than we have no magic-bullets in security region. Any approach has its merits and demerits. It depends on users what should be emphasized. If we tries to separate user's information assets in the application level (like salesforce), the code to be checked and bug-free are much larger than a case when we enforce accesses in OS/RDBMS. It shall make development cost to increase. If we tries to separate user's information assets in the virtual machine layer (like amazon), the worker-hour to maintain each virtual machines larger than a case when we enforce accesses in OS/RDBMS layer. It shall make maintenance cost to increase. If we tries to separate user's information assets in the OS/RDBMS layer, the code to be checked and bug-free are less than application level checks, and all administrator need to do is manage a limited number of instances. The granularity of access controls is not a primary matter. We can separate user's information assets in table level, not only row level. In addition, we cat set up a part of shared tables, unlike virtual machine approach. I don't mean this approach it a magic-bullets, but it can be an option for security-conscious users. 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: Bruce Momjian on 3 Dec 2009 16:46 Andrew Dunstan wrote: > I think you have been remarkably good about our caution in accepting > this. You certainly have my admiration for your patience. Agreed. > What would probably help us a lot would be to know some names of large > users who want and will support this. NEC's name is a good start, but if > a few other enterprise users spoke up it would help to make the decision > a lot easier. I think the open questions we have now are: o Is SE-Linux appropriate technology for Postgres? o Does SE-Linux have a sufficient user base or potential user base to justify the additional code? o Can the code be maintained? And we have some partial answers. SE-Linux seems like the most popular of the security frameworks. There are a number of identified potential users, though we are looking to hear about more of them. Third, KaiGai is being paid by NEC to do this work and has shown to be extraordinarily dedicated to this feature. He has also offered to get other SE-Linux people involved in any patch review. I think the PostGIS example mentioned earlier is a good one. We did make some minor adjustments years ago to make things easier for them, but we had the luxury of having PostGIS be able to be developed outside of our main tree. I think with the current posted patch we have some of that benefit in that most of the code is in SE-Linux-specific directories, but the code outside those directories does have to be maintained. -- 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: Josh Berkus on 3 Dec 2009 17:23 > In words of one syllable: I do not care at all whether the NSA would use > Postgres, if they're not willing to come and help us build it. There's several 2-syllable words there. ;-) If we > tried to build it without their input, we'd probably not produce what > they want anyway. Yeah, the *complete* lack of input/help from the security community aside from the occasional "SE Linux good" posts we've gotten is troubling. We could end up with a SQL-J. Kaigai, you've said that you could get SELinux folks involved in the patch review. I think it's past time that they were; please solicit them. --Josh Berkus -- 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 4 Dec 2009 23:30
On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > >> In words of one syllable: I do not care at all whether the NSA would use >> Postgres, if they're not willing to come and help us build it. > > There's several 2-syllable words there. ;-) > > If we >> tried to build it without their input, we'd probably not produce what >> they want anyway. > > Yeah, the *complete* lack of input/help from the security community > aside from the occasional "SE Linux good" posts we've gotten is > troubling. We could end up with a SQL-J. > > Kaigai, you've said that you could get SELinux folks involved in the > patch review. I think it's past time that they were; please solicit them. Actually, we tried that already, in a previous iteration of this discussion. Someone actually materialized and commented on a few things. The problem, as I remember it, was that they didn't know much about PostgreSQL, so we didn't get very far with it. Unfortunately, I can't find the relevant email thread at the moment. In fact, we've tried about everything with these patches. Tom reviewed them, Bruce reviewed them, Peter reviewed them, I reviewed them, Stephen Frost reviewed them, Heikki took at least a brief look at them, and I think there were a few other people, too. The first person who I can recall being relatively happy with any version of this patch was Stephen Frost, commenting on the access control framework that we suggested KaiGai try to separate from the main body of the patch to break it into more managable chunks. That patch was summarily rejected by Tom for what I believe were valid reasons. In other words, in 18 months of trying we've yet to see something that is close to being committable. Contrast that with Hot Standby, which Heikki made a real shot at committing during the first CommitFest to which it was submitted. I think David Fetter summarized it pretty well here - the rest of the thread is worth reading, too. http://archives.postgresql.org/pgsql-hackers/2009-07/msg01159.php I think the only chance of this ever getting committed is if a committer volunteers to take ownership of it, similar to what Heikki has done for Hot Standby and Streaming Replication. Right now, we don't have any volunteers, and even if Tom or Heikki were interested, I suspect it would occupy their entire attention for several CommitFests just as HS and SR have done for Heikki. I suspect the amount of work for SE-PostgreSQL might even be larger than for HS. If we DON'T have a committer who is willing to own this, then I don't think there's a choice other than giving up. ....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 |