Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Are you saying the performance penalty when full functionalities are enabled? (The meaning of bells and whistles is unclear for me.) Yes, that's what I meant. (Sorry.) We can show it on the page.22 of my presentation in PGcon2008. http://www.pgcon.org/2008/schedule/attachments/38_pgcon2008-sepostgresql.pdf It shows about 10% of penalty in maximum in pgbench, and larger database tend to have relatively less performance penalty. That doesn't really sound too bad if you are operating in an environment where security is paramount. Of course, if your vendor enables SELinux and SEPostgresql by default (even though you don't really care) then it might not be so good. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
* Robert Haas [EMAIL PROTECTED] [080924 00:15]: But I do think it's worthwhile to ask whether it makes sense to introduce a bunch of features that are only usable to people running SELinux. Actually, I'ld go one stroke farther, and ask: Does it make sense to introduce a bunch of features that are only usable to people *able to write proper SELinux policy sets* (or whatever they are called). it's very easy to imagine people wanting that feature, but NOT being willing to run SELinux to get it. Or, being more generous even, able to *run* SELinux, but not able to create a proper coherent set of SELinux policies... SELinux is standard now on most RHEL installs (and FC, and now debian, etc), but how many admins have actually made (or even just altered) a SELinux policy, and how many have just disabled it because it prevented what they thought should be a valid operation? I'm sure NSA can do both of these, but I would hazard that the number of other people able to do this well can probably be counted on my fingers... a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Aidan Van Dyk wrote: * Robert Haas [EMAIL PROTECTED] [080924 00:15]: But I do think it's worthwhile to ask whether it makes sense to introduce a bunch of features that are only usable to people running SELinux. Actually, I'ld go one stroke farther, and ask: Does it make sense to introduce a bunch of features that are only usable to people *able to write proper SELinux policy sets* (or whatever they are called). It is incorrect. In the recent years, SELinux comunity aspires to becoming that end users can setup it without editing security policy. The default security policy contains many pre-defined object types and booleans, end user can select them, if needed. For example, the default security policy of SE-PostgreSQL provides several pre-defined object types, like sepgsql_table_t, sepgsql_secret_table_t, sepgsql_ro_table_t and sepgsql_fixed_table_t for table/column/tuple. it's very easy to imagine people wanting that feature, but NOT being willing to run SELinux to get it. Or, being more generous even, able to *run* SELinux, but not able to create a proper coherent set of SELinux policies... SELinux is standard now on most RHEL installs (and FC, and now debian, etc), but how many admins have actually made (or even just altered) a SELinux policy, and how many have just disabled it because it prevented what they thought should be a valid operation? Can you think the security policy is something like a pattern file of anti-virus software running on windows desktop? I allows end-users to custamize some of options, but I have never seen a man who tries to make its pattern file by myself. Anyway, I don't think we can get a fruitful discussion like how many users enables SELinux here. Here is pgsql-hackers list. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
KaiGai Kohei wrote: Aidan Van Dyk wrote: * Robert Haas [EMAIL PROTECTED] [080924 00:15]: But I do think it's worthwhile to ask whether it makes sense to introduce a bunch of features that are only usable to people running SELinux. Actually, I'ld go one stroke farther, and ask: Does it make sense to introduce a bunch of features that are only usable to people *able to write proper SELinux policy sets* (or whatever they are called). It is incorrect. In the recent years, SELinux comunity aspires to becoming that end users can setup it without editing security policy. The default security policy contains many pre-defined object types and booleans, end user can select them, if needed. For example, the default security policy of SE-PostgreSQL provides several pre-defined object types, like sepgsql_table_t, sepgsql_secret_table_t, sepgsql_ro_table_t and sepgsql_fixed_table_t for table/column/tuple. it's very easy to imagine people wanting that feature, but NOT being willing to run SELinux to get it. Or, being more generous even, able to *run* SELinux, but not able to create a proper coherent set of SELinux policies... SELinux is standard now on most RHEL installs (and FC, and now debian, etc), but how many admins have actually made (or even just altered) a SELinux policy, and how many have just disabled it because it prevented what they thought should be a valid operation? Can you think the security policy is something like a pattern file of anti-virus software running on windows desktop? I allows end-users to Sorry, s/I allows/It allows/g custamize some of options, but I have never seen a man who tries to make its pattern file by myself. Anyway, I don't think we can get a fruitful discussion like how many users enables SELinux here. Here is pgsql-hackers list. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
KaiGai Kohei wrote: Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: Multilevel frameworks have concepts of data hiding and data substitution based on labels. That is, if a user doesn't have permissions on data, he's not merely supposed to be denied access to it, he's not even supposed to know that the data exists. In extreme cases (think military / CIA use) data at a lower security level should be substitited for the higher security level data which the user isn't allowed. Silently. Yeah, that's what I keep hearing that the spooks think they want. I can't imagine how it would play nice with SQL-standard integrity constraints. Data that apparently violates a foreign-key constraint, for example, would give someone a pretty good clue that there's something there he's not being allowed to see. Please note that SE-PostgreSQL does not adopt following technology because of its complexity. When user tries to update a PK refered by invisible FK, it generate an error. Thus, it is theoretically possible to estimate the invisible PKs by attacks with repeating. I assume if you use only non-natural keys (use sequence numbers, not codes like PHL or USA), there is no problem in finding the missing keys by repeated testing. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Aidan Van Dyk wrote: * Robert Haas [EMAIL PROTECTED] [080924 00:15]: But I do think it's worthwhile to ask whether it makes sense to introduce a bunch of features that are only usable to people running SELinux. Actually, I'ld go one stroke farther, and ask: Does it make sense to introduce a bunch of features that are only usable to people *able to write proper SELinux policy sets* (or whatever they are called). I consider this a valid concern, but given that some people want MAC and no one has shown a better way to implement MAC than SELinux, you can hardly use that as an objection against this particular patch. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Peter Eisentraut wrote: Aidan Van Dyk wrote: * Robert Haas [EMAIL PROTECTED] [080924 00:15]: But I do think it's worthwhile to ask whether it makes sense to introduce a bunch of features that are only usable to people running SELinux. Actually, I'ld go one stroke farther, and ask: Does it make sense to introduce a bunch of features that are only usable to people *able to write proper SELinux policy sets* (or whatever they are called). I consider this a valid concern, but given that some people want MAC and no one has shown a better way to implement MAC than SELinux, you can hardly use that as an objection against this particular patch. Peter, I am confused how the above statement relates to a posting you made a week ago: http://archives.postgresql.org/pgsql-hackers/2008-09/msg01067.php Now these items are arguably useful and welcome features in their own right. Unfortunately, this patch has chosen to provide these features in a way that makes them accessible to the least amount of users. And moreover, it bunches them all in one feature, while they should really be available independently. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Peter Eisentraut [EMAIL PROTECTED] writes: Aidan Van Dyk wrote: Actually, I'ld go one stroke farther, and ask: Does it make sense to introduce a bunch of features that are only usable to people *able to write proper SELinux policy sets* (or whatever they are called). I consider this a valid concern, but given that some people want MAC and no one has shown a better way to implement MAC than SELinux, you can hardly use that as an objection against this particular patch. The objection comes down to this: it's an extremely large, invasive, and probably performance-losing patch, which apparently will be of use to only a rather small set of people. It's not unreasonable to discuss just how large that set might be while we debate whether to accept the patch. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
On Wed, 24 Sep 2008 11:58:58 -0400 Tom Lane [EMAIL PROTECTED] wrote: The objection comes down to this: it's an extremely large, invasive, and probably performance-losing patch, which apparently will be of use to only a rather small set of people. It's not unreasonable to discuss just how large that set might be while we debate whether to accept the patch. I know of no one that really uses SELinux because it is a nightmare. On the other hand, this type of security is required to get into certain scary tin foil hat producing institutions. Do we want want to target those respective types of installs. If so, then we have no choice but to try and make this patch (or similar) work. If not, then I believe it is entirely too large of a change to even bother with. Now and this I think would be a first for PostgreSQL and something that may cause more trouble than it is worth but we could do: ./configure --enable-selinux # Experimental And if we find it doesn't work out, we rip it out. Yes, it is a lot of work. A great many of our community will not participate on this list and thus will not speak up to the (perceived) considerable demand for this type of feature. The fact that the gentlemen who wrote the patch kept it up to date and improved it over two release cycles suggests that there is significant interest in this somewhere. Joshua Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Joshua Drake wrote: On Wed, 24 Sep 2008 11:58:58 -0400 Tom Lane [EMAIL PROTECTED] wrote: The objection comes down to this: it's an extremely large, invasive, and probably performance-losing patch, which apparently will be of use to only a rather small set of people. It's not unreasonable to discuss just how large that set might be while we debate whether to accept the patch. I know of no one that really uses SELinux because it is a nightmare. On the other hand, this type of security is required to get into certain scary tin foil hat producing institutions. Do we want want to target those respective types of installs. If so, then we have no choice but to try and make this patch (or similar) work. If not, then I believe it is entirely too large of a change to even bother with. I think if we get the SQL-level stuff we want implemented we can see much better how much code SE-Linux support requires. For example, as the patch stands we have SE-Linux-specific tuple header fields, which seems like major overkill, but if the fields were already there for SQL feature capability the SE-Linux patch would be much less invasive. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Bruce Momjian wrote: Peter, I am confused how the above statement relates to a posting you made a week ago: http://archives.postgresql.org/pgsql-hackers/2008-09/msg01067.php Now these items are arguably useful and welcome features in their own right. Unfortunately, this patch has chosen to provide these features in a way that makes them accessible to the least amount of users. And moreover, it bunches them all in one feature, while they should really be available independently. I just want to distinguish the causalities in the various arguments that are being made. There are many ways to approach this, two of which could be: We want MAC = SELinux is the only proven way to implement MAC = let's take the patch or SELinux is way too complex = We don't take the patch = Figure out the MAC issue some other way -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Joshua Drake wrote: I know of no one that really uses SELinux because it is a nightmare. On the other hand, this type of security is required to get into certain scary tin foil hat producing institutions. Yeah, but do we even have the slightest bit of information about what exactly would be required to achieve the required levels? And whether this patch does it? And whether there would be alternative, more desirable ways to achieve a similar level? I am not arguing for or against this patch now, but I would like to know whether someone has an agenda for it. Without an agenda, future maintenance will be difficult. Reference to standards or other public documents would work best to define that agenda. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Peter, Yeah, but do we even have the slightest bit of information about what exactly would be required to achieve the required levels? And whether this patch does it? And whether there would be alternative, more desirable ways to achieve a similar level? Actually, I have some direct communication that SEPostgres will lead to PostgreSQL being widely adopted in at least one US government agency. Can't say more, of course. ;-) --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
On Wed, 24 Sep 2008 11:38:36 -0700 Josh Berkus [EMAIL PROTECTED] wrote: Peter, Yeah, but do we even have the slightest bit of information about what exactly would be required to achieve the required levels? And whether this patch does it? And whether there would be alternative, more desirable ways to achieve a similar level? Actually, I have some direct communication that SEPostgres will lead to PostgreSQL being widely adopted in at least one US government agency. Can't say more, of course. ;-) /me notes his tin foil hat argument. Joshua D. Drake --Josh -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
On Sep 24, 2008, at 2:38 PM, Josh Berkus wrote: Peter, Yeah, but do we even have the slightest bit of information about what exactly would be required to achieve the required levels? And whether this patch does it? And whether there would be alternative, more desirable ways to achieve a similar level? Actually, I have some direct communication that SEPostgres will lead to PostgreSQL being widely adopted in at least one US government agency. Can't say more, of course. ;-) And the consideration is predicated on the PostgreSQL community accepting the patch? This sounds like an opportunity for one of the numerous enterprise spin-offs. Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Josh Berkus wrote: Peter, Yeah, but do we even have the slightest bit of information about what exactly would be required to achieve the required levels? And whether this patch does it? And whether there would be alternative, more desirable ways to achieve a similar level? Actually, I have some direct communication that SEPostgres will lead to PostgreSQL being widely adopted in at least one US government agency. Can't say more, of course. ;-) We can't make decisions based on just one adoption agency, of course. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Josh Berkus [EMAIL PROTECTED] writes: Peter, Yeah, but do we even have the slightest bit of information about what exactly would be required to achieve the required levels? And whether this patch does it? And whether there would be alternative, more desirable ways to achieve a similar level? Actually, I have some direct communication that SEPostgres will lead to PostgreSQL being widely adopted in at least one US government agency. Does that mean that they have looked at this specific patch and concluded that it meets their requirements? Or just that SELinux is a checkbox item for them? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
The objection comes down to this: it's an extremely large, invasive, and probably performance-losing patch, which apparently will be of use to only a rather small set of people. It's not unreasonable to discuss just how large that set might be while we debate whether to accept the patch. Significant loss of performance for people who are not using the feature seems like it ought to be considered a non-starter. Not using MAC needs to be a fast-path. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas wrote: The objection comes down to this: it's an extremely large, invasive, and probably performance-losing patch, which apparently will be of use to only a rather small set of people. It's not unreasonable to discuss just how large that set might be while we debate whether to accept the patch. Significant loss of performance for people who are not using the feature seems like it ought to be considered a non-starter. Not using MAC needs to be a fast-path. Right now all of SE-PostgreSQL is a compile-time option so I assume the slowdown is only for compile-enabled builds. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Tom, Does that mean that they have looked at this specific patch and concluded that it meets their requirements? Or just that SELinux is a checkbox item for them? That it was a checkbox item for them, and it led to them evaluating PostgreSQL when they otherwise wouldn't have. I don't know the current status of that evaluation. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Peter Eisentraut wrote: I am not arguing for or against this patch now, but I would like to know whether someone has an agenda for it. Without an agenda, future maintenance will be difficult. Reference to standards or other public documents would work best to define that agenda. It is a bit old, but describes whole of the SE-PostgreSQL. http://sepgsql.googlecode.com/files/sepgsql_security_guide.20080214.en.pdf I think it has to be updated to reflect for the recent updates like implementation changes in row-level access controls. In addition, I also think maintenance of the feature is primarily my work, no need to say. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Bruce Momjian wrote: Robert Haas wrote: The objection comes down to this: it's an extremely large, invasive, and probably performance-losing patch, which apparently will be of use to only a rather small set of people. It's not unreasonable to discuss just how large that set might be while we debate whether to accept the patch. Significant loss of performance for people who are not using the feature seems like it ought to be considered a non-starter. Not using MAC needs to be a fast-path. Right now all of SE-PostgreSQL is a compile-time option so I assume the slowdown is only for compile-enabled builds. Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features. In addition, these are invoked via security hooks which are declared as inline functions. So, I think it does not give us additional loss of performances when you don't add the compile time option explicitly. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features. In addition, these are invoked via security hooks which are declared as inline functions. So, I think it does not give us additional loss of performances when you don't add the compile time option explicitly. That is good as far as it goes but I assume that if this patch is accepted many vendors will build with this feature enabled, and many end-users will turn off SELinux but keep the same binaries. It's important that those people don't get hosed either. It's also probably worth asking what the performance penalty is when you ARE using all the bells and whistles. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas wrote: Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features. In addition, these are invoked via security hooks which are declared as inline functions. So, I think it does not give us additional loss of performances when you don't add the compile time option explicitly. That is good as far as it goes but I assume that if this patch is accepted many vendors will build with this feature enabled, and many end-users will turn off SELinux but keep the same binaries. It's important that those people don't get hosed either. When we run a binary with this feature on non-SELinux'ed environment, security hooks simply returns with reference to the flag variable which shows whether SELinux is available on the host. It's also probably worth asking what the performance penalty is when you ARE using all the bells and whistles. Are you saying the performance penalty when full functionalities are enabled? (The meaning of bells and whistles is unclear for me.) We can show it on the page.22 of my presentation in PGcon2008. http://www.pgcon.org/2008/schedule/attachments/38_pgcon2008-sepostgresql.pdf It shows about 10% of penalty in maximum in pgbench, and larger database tend to have relatively less performance penalty. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas wrote: It's too early to vote. :-) The second and third option have prerequisite. The purpose of them is to match granularity of access controls provided by SE-PostgreSQL and native PostgreSQL. However, I have not seen a clear reason why these different security mechanisms have to have same granuality in access controls. Have you seen a clear reason why they should NOT have the same granularity? Agreed. If we implement SE-PostgreSQL row-level security first, we might find that we have to replace the code once we implement SQL-level row-level security. If we do SQL-level security first, we can then adjust it to match what SE-PostgreSQL needs. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
KaiGai Kohei wrote: [1] Make a consensus that different security mechanisms have differences in its decision making, its gulanuality and its scope I think it is the most straightforward answer. As operating system doing, DAC and MAC based access controls should be independently applied on accesses from users, and this model is widely accepted. These facilities can also have different results, gulanualities and scopes. [2] Make a new implementation of OS-independent fine grained access control If it is really really necessary, I may try to implement a new separated fine-grained access control mechanism due to the CommitFest:Nov. However, we don't have enough days to develop one more new feature from the scratch by the deadline. I reconsidered the above two options have no differences fundamentally. In other word, making a new enhanced security implementation based on requirements also means making a consensus various security mechanism can have its individual rules including guranuality of access controls. So, I'll decide to try to implement fine-grained-only security mechanism also, because someone have such a requirememt. However, its schedule is extremely severe, if is has to be submitted due to the deadline of CommitFest:Nov. It is my hope to concentrate development of SE-PostgreSQL in v8.4 development cycle, and I think the above fine-grained-only one should be pushed to v8.5 cycle. Well, those might be your priorities, but I don't think they are the community's priorities. I think the community's priorities are to add security at the SQL level, and then we can see clearly what SE-PostgreSQL requires. This has been discussed before so it should not come as a surprise. What you can do is to do things in this order: 1) Add SE-PostgreSQL capabilities that layer over existing Postgres SQL-level permissions 2) Implement fine-grained permissions at the SQL level 3) Add SE-PostgreSQL capabilities for fine-grained permissions Perhaps you can only get #1 done for 8.4; I don't know, but I knew months ago that #2 had to be done before #3, and I think that was communicated. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Bruce, I think the community's priorities are to add security at the SQL level, and then we can see clearly what SE-PostgreSQL requires. This has been discussed before so it should not come as a surprise. Well, I'm not that clear on exactly the SE implementation, but I spent a fair amount of time with Trusted Solaris and I can tell you that a multilevel security implementation would work in a different way from SQL row-level permissions. Multilevel frameworks have concepts of data hiding and data substitution based on labels. That is, if a user doesn't have permissions on data, he's not merely supposed to be denied access to it, he's not even supposed to know that the data exists. In extreme cases (think military / CIA use) data at a lower security level should be substitited for the higher security level data which the user isn't allowed. Silently. So it's quite possible that the SE and/or multilevel framework could remain parallel-but-different from SQL-level permissions, which would not include data hiding or data substitution. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Josh Berkus wrote: Bruce, I think the community's priorities are to add security at the SQL level, and then we can see clearly what SE-PostgreSQL requires. This has been discussed before so it should not come as a surprise. Well, I'm not that clear on exactly the SE implementation, but I spent a fair amount of time with Trusted Solaris and I can tell you that a multilevel security implementation would work in a different way from SQL row-level permissions. Multilevel frameworks have concepts of data hiding and data substitution based on labels. That is, if a user doesn't have permissions on data, he's not merely supposed to be denied access to it, he's not even supposed to know that the data exists. In extreme cases (think military / CIA use) data at a lower security level should be substitited for the higher security level data which the user isn't allowed. Silently. So it's quite possible that the SE and/or multilevel framework could remain parallel-but-different from SQL-level permissions, which would not include data hiding or data substitution. True, but think we would like to have all the SQL-level stuff done first, or at least decide we don't want it at the SQL level, before moving forward with adding fine-grained controls. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Bruce Momjian wrote: True, but think we would like to have all the SQL-level stuff done first, or at least decide we don't want it at the SQL level, before moving forward with adding fine-grained controls. This makes no sense. We've been sitting for years on the per-row privilege stuff, and there haven't been many takers. It doesn't look like somebody is going to write it for 8.4, which means delaying the inclusion of SE-Pgsql stuff just because that other thing is not done does not favor anyone. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Alvaro Herrera wrote: Bruce Momjian wrote: True, but think we would like to have all the SQL-level stuff done first, or at least decide we don't want it at the SQL level, before moving forward with adding fine-grained controls. This makes no sense. We've been sitting for years on the per-row privilege stuff, and there haven't been many takers. It doesn't look like somebody is going to write it for 8.4, which means delaying the inclusion of SE-Pgsql stuff just because that other thing is not done does not favor anyone. Well, does it make sense to add column-level privileges just for SE-Linux? I don't think that is wise. My logic is to build the lower levels first (SQL), then the higher levels. If that was done when the issue was originally suggested months ago it would be done but now. I don't see the rush to do things backwards just to get SE-Linux capability in 8.4, but of course that is just my opinion. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: True, but think we would like to have all the SQL-level stuff done first, or at least decide we don't want it at the SQL level, before moving forward with adding fine-grained controls. This makes no sense. We've been sitting for years on the per-row privilege stuff, and there haven't been many takers. It doesn't look like somebody is going to write it for 8.4, which means delaying the inclusion of SE-Pgsql stuff just because that other thing is not done does not favor anyone. Well, does it make sense to add column-level privileges just for SE-Linux? I don't think that is wise. My logic is to build the lower levels first (SQL), then the higher levels. If that was done when the issue was originally suggested months ago it would be done but now. I don't see the rush to do things backwards just to get SE-Linux capability in 8.4, but of course that is just my opinion. As I mentioned before, it is quite natural that different security mechanism *can* have different granualities, different decisions and so on. (No need to say, it *never* prevent they have same ones.) However, I can follow the direction of the community. If it is necessary to get merged SE-PostgreSQL feature in v8.4 cycle, I'll begin to design and implement the fine-grained-only feature sooon. In my hope, could you make progress reviewing SE-PostgreSQL feature during last half of the September and the October? It is necessary for load balancing of folks. Anyway, we have just only 35 days. If possible, I wanted to get such a funfamental suggestion more ealier. :( Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: True, but think we would like to have all the SQL-level stuff done first, or at least decide we don't want it at the SQL level, before moving forward with adding fine-grained controls. This makes no sense. We've been sitting for years on the per-row privilege stuff, and there haven't been many takers. It doesn't look like somebody is going to write it for 8.4, which means delaying the inclusion of SE-Pgsql stuff just because that other thing is not done does not favor anyone. Well, does it make sense to add column-level privileges just for SE-Linux? That's the wrong question. The question here is: does it make sense to have per-row permissions implemented on top of an abstraction layer whose sole current implementation is SE-Linux? I think the answer is yes, because (as others have said) if we ever want to have SQL-level per-row permissions, then we can implement them with no change to the patch currently in discussion. (Note that it has been said that this abstraction layer could easily be ported to work on TrustedSolaris, and probably other OS-level security mechs) I don't think that is wise. My logic is to build the lower levels first (SQL), then the higher levels. Why are you saying that SQL is the lower level? I don't think there's a lower and upper layer here. Neither can be built on top of the other one, because they are orthogonal. If that was done when the issue was originally suggested months ago it would be done but now. I don't see the rush to do things backwards just to get SE-Linux capability in 8.4, but of course that is just my opinion. :-) My opinion here is that doing it is not backwards. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Josh Berkus [EMAIL PROTECTED] writes: Multilevel frameworks have concepts of data hiding and data substitution based on labels. That is, if a user doesn't have permissions on data, he's not merely supposed to be denied access to it, he's not even supposed to know that the data exists. In extreme cases (think military / CIA use) data at a lower security level should be substitited for the higher security level data which the user isn't allowed. Silently. Yeah, that's what I keep hearing that the spooks think they want. I can't imagine how it would play nice with SQL-standard integrity constraints. Data that apparently violates a foreign-key constraint, for example, would give someone a pretty good clue that there's something there he's not being allowed to see. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Well, does it make sense to add column-level privileges just for SE-Linux? That's the wrong question. The question here is: does it make sense to have per-row permissions implemented on top of an abstraction layer whose sole current implementation is SE-Linux? Er, Bruce was asking about per-column, not per-row. There's a patch listed on CommitFest:2008-09 to introduce per-column permissions, but it's apparently still WIP. How much does that overlap/conflict with these patches? I think the answer is yes, because (as others have said) if we ever want to have SQL-level per-row permissions, then we can implement them with no change to the patch currently in discussion. If that's true, it weighs somewhat in favor of accepting this patch, but how sure are we that it's really the case? If you only have one implementation sitting on top of your abstraction layer, it's hard to know whether you've implemented a general framework for doing X or merely an interface that happens to suit the particular flavor of X that you want to do today. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas wrote: I think the answer is yes, because (as others have said) if we ever want to have SQL-level per-row permissions, then we can implement them with no change to the patch currently in discussion. If that's true, it weighs somewhat in favor of accepting this patch, but how sure are we that it's really the case? If you only have one implementation sitting on top of your abstraction layer, it's hard to know whether you've implemented a general framework for doing X or merely an interface that happens to suit the particular flavor of X that you want to do today. Yes, that is my point, and SE-Linux is just Linux, meaning it is OS-specific, making it even less generally useful. -- Bruce Momjian [EMAIL PROTECTED]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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: Multilevel frameworks have concepts of data hiding and data substitution based on labels. That is, if a user doesn't have permissions on data, he's not merely supposed to be denied access to it, he's not even supposed to know that the data exists. In extreme cases (think military / CIA use) data at a lower security level should be substitited for the higher security level data which the user isn't allowed. Silently. Yeah, that's what I keep hearing that the spooks think they want. I can't imagine how it would play nice with SQL-standard integrity constraints. Data that apparently violates a foreign-key constraint, for example, would give someone a pretty good clue that there's something there he's not being allowed to see. Please note that SE-PostgreSQL does not adopt following technology because of its complexity. When user tries to update a PK refered by invisible FK, it generate an error. Thus, it is theoretically possible to estimate the invisible PKs by attacks with repeating. In extream case, a technology called as polyinstantiation is used. http://en.wikipedia.org/wiki/Polyinstantiation It allows several tuples with different security level to have same primary key. When a higher-level user updates a tuple with lower security level, DBMS makes a new tuple with higher-level and the original one is kept unchanged. It does not prevent to leak a infomation belonging with higher security level. IIRC, FK has to refer a PK with same or lower security level to keep consistency of its visibility in polyinstantiated tables. If a lower level user modifies a PK with in same level, DBMS makes a copy of PK with higher-level. This operating does not affect higher FKs, but FK integrities are kept. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Yeah, that's what I keep hearing that the spooks think they want. I can't imagine how it would play nice with SQL-standard integrity constraints. Data that apparently violates a foreign-key constraint, for example, would give someone a pretty good clue that there's something there he's not being allowed to see. Right, so you don't let that happen. If you're giving Mr. X access to the cities table, and decide to restrict him only to cities in Europe, then if you give him access to the informants table, you'll probably restrict that to only informants located in cities that are in Europe, so, no problem. It's easy to come up with cases where there is a problem but just because there can be problems doesn't mean the technology isn't basically useful. I don't think there's much point in second-guessing the NSA: they are smart and have thought about this more than we have. But I do think it's worthwhile to ask whether it makes sense to introduce a bunch of features that are only usable to people running SELinux. Column-level permissions are the best example of this: it's very easy to imagine people wanting that feature, but NOT being willing to run SELinux to get it. It's more arguable whether data hiding falls into the same category or not, because if you're doing data hiding then arguably you're a security nut and more likely to be running (or willing to run) SELinux. Against that, my boss made me do data hiding but we have no interest in SELinux, so that's one data point the other way, though not one I'd take all that seriously. So far there has been no detailed discussion of any of the new security features that are in this patch (column-level security, row-level security, large object security, etc). For each of those features, we need to answer the following questions: 1. Do we want this feature as a part of PostgreSQL at all? 2. If #1 is yes, do we eventually want to expose this feature via a SQL interface, or some other interface substantially unlike SE-PostgreSQL? 3. If #2 is yes, will accepting this patch get us closer to that goal or further away from it? I suspect that for most of the features the answer for #1 will be yes, but the other two questions need some more careful examination. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas [EMAIL PROTECTED] writes: That's the wrong question. The question here is: does it make sense to have per-row permissions implemented on top of an abstraction layer whose sole current implementation is SE-Linux? Er, Bruce was asking about per-column, not per-row. There's a patch listed on CommitFest:2008-09 to introduce per-column permissions, but it's apparently still WIP. How much does that overlap/conflict with these patches? Yeah, Stephen Frost is working on that and still has a ways to go. I think he might get it done in time for 8.4 (ie, in time for the November commitfest) but it's far from certain. Per-column permissions are part of the SQL standard, and so I think we have to implement that without depending on any OS-specific infrastructure. So on that end I agree with Bruce's position that we should do the SQL version first and then think about extensions for SELinux. Per-row is not in the spec and so we can design that as we please. But as I mentioned a moment ago, I don't see how it can possibly play nice with foreign keys ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Bruce Momjian wrote: Robert Haas wrote: I think the answer is yes, because (as others have said) if we ever want to have SQL-level per-row permissions, then we can implement them with no change to the patch currently in discussion. If that's true, it weighs somewhat in favor of accepting this patch, but how sure are we that it's really the case? If you only have one implementation sitting on top of your abstraction layer, it's hard to know whether you've implemented a general framework for doing X or merely an interface that happens to suit the particular flavor of X that you want to do today. Yes, that is my point, and SE-Linux is just Linux, meaning it is OS-specific, making it even less generally useful. I believe the upcomig fine-grained security patch enables to make clear the security framework is NOT specific for SELinux only. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas [EMAIL PROTECTED] writes: I don't think there's much point in second-guessing the NSA: they are smart and have thought about this more than we have. No doubt, but have they told us what we'd need to know to make a non-broken implementation? I haven't seen anything about how a SQL database ought to work to play nice with SELinux or similar controls. I don't doubt that somebody inside Fort Meade has a good design for this, but I have no confidence that we do. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Tom Lane wrote: Robert Haas [EMAIL PROTECTED] writes: That's the wrong question. The question here is: does it make sense to have per-row permissions implemented on top of an abstraction layer whose sole current implementation is SE-Linux? Er, Bruce was asking about per-column, not per-row. There's a patch listed on CommitFest:2008-09 to introduce per-column permissions, but it's apparently still WIP. How much does that overlap/conflict with these patches? Yeah, Stephen Frost is working on that and still has a ways to go. I think he might get it done in time for 8.4 (ie, in time for the November commitfest) but it's far from certain. Per-column permissions are part of the SQL standard, and so I think we have to implement that without depending on any OS-specific infrastructure. Yes, I agree this position. The OS-specific infrastructure works orthogonally with native SQL standard access controls, as DAC/MAC works orthogonally on operating system. So on that end I agree with Bruce's position that we should do the SQL version first and then think about extensions for SELinux. A proposal of fine-grained security without OS is here: http://archives.postgresql.org/pgsql-hackers/2008-09/msg01528.php I'll pay my effort to submit a series of patches due to end of the Oct. Per-row is not in the spec and so we can design that as we please. But as I mentioned a moment ago, I don't see how it can possibly play nice with foreign keys ... As I noted in above message, it handles PK/FK constraints as follows: - When a user tries to insert/update a tuple with duplicate PK, it is failed independent from its visibility. - When a user tries to insert/update a tuple with FK, the refered PK have to be visible. - When a user tries to update/delete a tuple with PK which is refered by invisible FK, it is failed independent from its visibility. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
[1] Make a consensus that different security mechanisms have differences in its decision making, its gulanuality and its scope I think it is the most straightforward answer. As operating system doing, DAC and MAC based access controls should be independently applied on accesses from users, and this model is widely accepted. These facilities can also have different results, gulanualities and scopes. [2] Make a new implementation of OS-independent fine grained access control If it is really really necessary, I may try to implement a new separated fine-grained access control mechanism due to the CommitFest:Nov. However, we don't have enough days to develop one more new feature from the scratch by the deadline. I reconsidered the above two options have no differences fundamentally. In other word, making a new enhanced security implementation based on requirements also means making a consensus various security mechanism can have its individual rules including guranuality of access controls. So, I'll decide to try to implement fine-grained-only security mechanism also, because someone have such a requirememt. However, its schedule is extremely severe, if is has to be submitted due to the deadline of CommitFest:Nov. It is my hope to concentrate development of SE-PostgreSQL in v8.4 development cycle, and I think the above fine-grained-only one should be pushed to v8.5 cycle. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
[2] Make a new implementation of OS-independent fine grained access control If it is really really necessary, I may try to implement a new separated fine-grained access control mechanism due to the CommitFest:Nov. However, we don't have enough days to develop one more new feature from the scratch by the deadline. +1. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas wrote: [2] Make a new implementation of OS-independent fine grained access control If it is really really necessary, I may try to implement a new separated fine-grained access control mechanism due to the CommitFest:Nov. However, we don't have enough days to develop one more new feature from the scratch by the deadline. +1. ...Robert It's too early to vote. :-) The second and third option have prerequisite. The purpose of them is to match granularity of access controls provided by SE-PostgreSQL and native PostgreSQL. However, I have not seen a clear reason why these different security mechanisms have to have same granuality in access controls. As I mentioned before, it is quite natural that different security mechanism provides its access controls in different granuality, as widely accepted in Linux. The reason is now unclear for me. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
It's too early to vote. :-) The second and third option have prerequisite. The purpose of them is to match granularity of access controls provided by SE-PostgreSQL and native PostgreSQL. However, I have not seen a clear reason why these different security mechanisms have to have same granuality in access controls. Have you seen a clear reason why they should NOT have the same granularity? I realize that SELinux has become quite popular and that a lot of people use it - but certainly not everyone. There might be some parts of the functionality that are not really severable, and if that is the case, fine. But I think there should be some consideration of which parts can be usefully exposed via SQL and which can't. If the parts that can be are independently useful, then I think they should be available, but ultimately that's a judgment call and people may come to different conclusions. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Robert Haas wrote: It's too early to vote. :-) The second and third option have prerequisite. The purpose of them is to match granularity of access controls provided by SE-PostgreSQL and native PostgreSQL. However, I have not seen a clear reason why these different security mechanisms have to have same granuality in access controls. Have you seen a clear reason why they should NOT have the same granularity? I don't deny two different security mechanisms have same granuality. It is a choice by its architect, and it can have same or different guranuality. I realize that SELinux has become quite popular and that a lot of people use it - but certainly not everyone. There might be some parts of the functionality that are not really severable, and if that is the case, fine. But I think there should be some consideration of which parts can be usefully exposed via SQL and which can't. If the parts that can be are independently useful, then I think they should be available, but ultimately that's a judgment call and people may come to different conclusions. Yes, I also agree your opinion. SE-PostgreSQL is designed to achieve several targets in same time: - Collaboration with operating system - Mandatoty access control - Fine-grained access control If someone want the last feature only, SE-PostgreSQL provides too much for him. However, it is designed to replace security mechanism easily. Have you heared the PGACE security framework? It is designed by reference to LSM, and provides several hooks to invoke security mechanism. It checks whether the given query is legal, or not. In my second option, I will try to implement similar functionality which provides fine-grained-only on PGACE security framework. However, every security mechanism has horizontal relationship, not a hierarchy, not a dependency. So, we can make progress in parallel. (And, they can have individual guranuality and so on.) Therefore, I think that nonexistence of fine-grained-only mechanism should not block other mechanism to join development cycle. If it is really really necessary, I try to pay effort to implement the 2nd option due to the CommitFest:Nov. But, in my ideal, I want to concentrate to merge SE-PostgreSQL during v8.4 development cycle. And, I understood there are folks who want only fine-grained-only one. If possible, I want to design and implement it for v8.5 development cycle with enough days. Unfortunatelly, remained days are a bit short... Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
On Sep 19, 2008, at 1:42 PM, Robert Haas wrote: It's too early to vote. :-) The second and third option have prerequisite. The purpose of them is to match granularity of access controls provided by SE-PostgreSQL and native PostgreSQL. However, I have not seen a clear reason why these different security mechanisms have to have same granuality in access controls. Have you seen a clear reason why they should NOT have the same granularity? I realize that SELinux has become quite popular and that a lot of people use it - but certainly not everyone. There might be some parts of the functionality that are not really severable, and if that is the case, fine. But I think there should be some consideration of which parts can be usefully exposed via SQL and which can't. If the parts that can be are independently useful, then I think they should be available, but ultimately that's a judgment call and people may come to different conclusions. If the SE-PostgreSQL effort simply implemented SQL interfaces to increase security granularity, it wouldn't be SE-PostgreSQL at all. SE- PostgreSQL integrates with a set of optional system-wide access controls and is only marginally related to SQL-level database features. Since it relies on an optional component, it doesn't really make sense that anyone is surprised that the patch doesn't improve security granularity of vanilla PostgreSQL. Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
A.M. wrote: On Sep 19, 2008, at 1:42 PM, Robert Haas wrote: It's too early to vote. :-) The second and third option have prerequisite. The purpose of them is to match granularity of access controls provided by SE-PostgreSQL and native PostgreSQL. However, I have not seen a clear reason why these different security mechanisms have to have same granuality in access controls. Have you seen a clear reason why they should NOT have the same granularity? I realize that SELinux has become quite popular and that a lot of people use it - but certainly not everyone. There might be some parts of the functionality that are not really severable, and if that is the case, fine. But I think there should be some consideration of which parts can be usefully exposed via SQL and which can't. If the parts that can be are independently useful, then I think they should be available, but ultimately that's a judgment call and people may come to different conclusions. If the SE-PostgreSQL effort simply implemented SQL interfaces to increase security granularity, it wouldn't be SE-PostgreSQL at all. SE-PostgreSQL integrates with a set of optional system-wide access controls and is only marginally related to SQL-level database features. Since it relies on an optional component, it doesn't really make sense that anyone is surprised that the patch doesn't improve security granularity of vanilla PostgreSQL. I understand what you say is the part of decision making should be pluggable and like a fine-grained-only mode should be selectable. (I'm sorry, if my understanding is incorrect.) I thought this approach prevents to support various kind of enhanced security mechanism on PGACE security framework. Do you know SE-PostgreSQL is designed to use common set of security hooks named as PGACE? It provides bare hooks and minimum facilities to handle security attribute. The reason why it does not define internal structure of security mechanism is to avoid to assume specific mechanism. My preference is to switch whole of security mechanism by configuration option as SE-PostgreSQL or LSM doing. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
At the CommitFest:Sep, I got several comments about SE-PostgreSQL from Peter. (Thanks for your comments.) He asked me several questions about its concept, then I replied for them. However, it seems to me there is a difference in our opinions. In my opinion, it is quite natural that different security mechanisms can have differences in its decision making, its gulanuality and its scope. But he concerned that SE-PostgreSQL provides fine-grained access control feature, though the native PostgreSQL does not provide it yet. *) Row-level security, column-level security and so on should in my mind first exist as a native SQL-level feature. It would be hard to explain that PostgreSQL does not have column-level GRANT privileges but that you can achieve the same if you go through SELinux. I don't know his current opinion. But I think it is not worthful to stop making a progress due to differences in opinions. So, I think there are the following three options to solve the issue. [1] Make a consensus that different security mechanisms have differences in its decision making, its gulanuality and its scope I think it is the most straightforward answer. As operating system doing, DAC and MAC based access controls should be independently applied on accesses from users, and this model is widely accepted. These facilities can also have different results, gulanualities and scopes. [2] Make a new implementation of OS-independent fine grained access control If it is really really necessary, I may try to implement a new separated fine-grained access control mechanism due to the CommitFest:Nov. However, we don't have enough days to develop one more new feature from the scratch by the deadline. [3] Restrict functionalities of SE-PostgreSQL It is the most laughable idea. If SE-PostgreSQL lose its fine-grained access control feature, both of access control features have same gulanualities at least. But it makes unmotivate me so much. I believe no one agree this option. I want any comments on this topic. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Greg Smith wrote: On Wed, 17 Sep 2008, Peter Eisentraut wrote: System-wide consistency in access controls could be nice to have in some cases. But is it really achievable? In the typical three-tier web application scenario, do you really have system-wide consistency? Can you configure your application server using SELinux? Each of the tiers end up with mapping layer similar to the one implemented here to map the SELinux permissions - PostgreSQL. Java for example has a whole JVM security manager component that makes it straighforward to do such a mapping. http://articles.techrepublic.com.com/5100-10878_11-6178805.html is a good quick intro that shows how the call structure is similar to what the SE-PostgreSQL code does. I guess these security architectures have same origin. The reference monitor concept requres all accesses to data objects to be checked by a tamperproof, always-invoked module based on its policy. http://en.wikipedia.org/wiki/Reference_monitor SE-PostgreSQL uses in-kernel SELinux as a reference monitor to check all accesses to database object via SQL. And is SELinux really the desirable interface for a system-wide access control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or port SQL roles back to the operating system, or something else that captures what more people are actually using in practice. The main feature of SELinux that this crowd likes is how it manages privledge escalation risk. I'm not sure if POSIX ACLs for example are as effective at limiting the damage an exploitable suid binary can cause. As for what people are actually using, as someone who lives near the US capital I can tell you that installs using SELinux are quite plentiful around here--there really is no other UNIX-based technology for this purpose that's gotten traction inside this government like SELinux has. Anyway, even though I think picking SELinux as the primary security mechanism to integrate with is a sensible choice and I'm confident that the rest of the software stack isn't a problem, I do share your concern that implementing row and column-level security would make more sense in a general way first. Thanks for your explanation. The PGACE security framework can mount a OS independent fine grained access control feature, like Oracle Label Security. However, one concern is we have only one CommitFest remained. As I mentioned at the previous message, I think it is not a strange behavior that different security subsystems make different decisions on individual gulanualities. Ultimately, I see this patch as an interesting proof of concept -- it got us on the NSA site anyway -- but I can't see more than three people actually making use of it I take it you've never seen how big the NSA fort^H^H^H^Hfacility is? I'm not sure exactly how many orders of magnitude your estimate is off by, but I know it's at least 2 just based on conversations I've been involved in with companies around here. A lot of the US defense and homeland security related companies are adopting open-source software stacks because they can audit every level of the software, and there's a big void in that stack waiting for a database with the right security model to fill. You are right that getting code contributions back again is a challenge though. I don't have statistically reliable information. :) However, I believe there is potentially strong demand for secure database due to responses from audiences when I had presentations about SE-PostgreSQL in various opportunities. IIRC, Josh also said similar things. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
KaiGai Kohei wrote: Peter, thanks for your comments. Let's review: *) System-wide consistency in access controls could be nice to have in some cases. But is it really achievable? In the typical three-tier web application scenario, do you really have system-wide consistency? Can you configure your application server using SELinux? I'm no expert on these things, but I wonder, would it even work in a useful way, over the network, with all the different threads, processes, and sessions going on? Or how about a desktop, pgAdmin with several database connections, can those be isolated from each other or whatever the security setup may be? It's a good question. Yes, it is possible no need to say. :) We can configure Apache to kick its contents handler with a proper security context. The contents handler is a sort of Apache module to handle various kind of web contents like *.html, *.php, *.cgi and so on. The existing module (mod_selinux) eanbles to invoke CGI program with a proper security context based on HTTP authentication. In addition, the upcoming Linux kernel got a feature to assign built-in scripts its security context. SELinux applied its access controls based on the assigned security context for various kind of objects like files, sockets, IPCs, tables, columns and so on. I can provide a demonstration, pelase wait for a while to set up. The following URL can show the demonstration: http://kaigai.myhome.cx/index.php It requires HTTP authentication, and you can choose one of foo, var or baz. They can be authenticated by same password: sepgsql. The web server assigns per-user security context for its contents handler including the PHP script. It shows the result set of SQL query depends on the security context of its client. (note) This script always connects to SE-PostgreSQL server with apache role that has a privileged user rights. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
KaiGai Kohei wrote: Could you tell me the current status of reviewing process in the CommitFest:Sep? Well ... I have analyzed this patch several times now. The implementation appears to be pretty straightforward, and when the time comes, we can discuss some of the low-level details. At this time, however, I would like to take a step or two back and discuss with the rest of the community what we really want to achieve in terms of enhancing security and access control. We need wider input on this. The patch makes use of generic terms such as security enhanced and access control extensions and appropriates them to this particular implementation, and I am not really sure what direction we want to take with this. I have also reviewed your PGCon presentation to infer your goals behind this implementation. At the core of it, I can see a few things that are being done here: * System-wide consistency in access controls The idea is, if we use some system and language to control operating system permissions, it would be nice to use the same system and language to control access permissions in the database system and elsewhere. * Mandatory access control (MAC) This defines a global security policy on top of the discretionary access control currently in place. (Depending on how you interpret the terms and the capabilities of SELinux, it also provides Type Enforcement and Multilevel Security to some degree. These are related in some ways to MAC.) * Row-level security This defines a way to control access to rows, not only to columns. * Additional privileges The presented patches add ways to control permissions to alter tables, modify large objects, and other things as well as column-level privileges. Some of this is a moral prerequisite for a useful MAC setup. Now these items are arguably useful and welcome features in their own right. Unfortunately, this patch has chosen to provide these features in a way that makes them accessible to the least amount of users. And moreover, it bunches them all in one feature, while they should really be available independently. Let's review: *) System-wide consistency in access controls could be nice to have in some cases. But is it really achievable? In the typical three-tier web application scenario, do you really have system-wide consistency? Can you configure your application server using SELinux? I'm no expert on these things, but I wonder, would it even work in a useful way, over the network, with all the different threads, processes, and sessions going on? Or how about a desktop, pgAdmin with several database connections, can those be isolated from each other or whatever the security setup may be? And is SELinux really the desirable interface for a system-wide access control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or port SQL roles back to the operating system, or something else that captures what more people are actually using in practice. *) Mandatory access control could be a useful feature for some users. But must we resort to SELinux as the configuration language and implementation backend? Why couldn't we implement a MAC system in SQL using the existing language? Also, what I read is that role-based access control (RBAC) systems are equally capable of providing the sort of stronger security that MAC users are typically looking for. (In some ways, it appears to be the newer thing.) PostgreSQL already has a pretty good role system, so we could perhaps look into enhancing that to meet the necessary functional criteria that may exist. *) Row-level security, column-level security and so on should in my mind first exist as a native SQL-level feature. It would be hard to explain that PostgreSQL does not have column-level GRANT privileges but that you can achieve the same if you go through SELinux. After all, the SE-PostgreSQL patch only hooks in to several places to throw permission denied errors when appropriate, so native SQL features should be able to achieve the same. (Well, there are interesting SELinux-vs-AppArmor type differences here, that may be worth considering separately.) Ultimately, I see this patch as an interesting proof of concept -- it got us on the NSA site anyway -- but I can't see more than three people actually making use of it, and they are not going to maintain this code for us in the long run. On the other hand, it provides useful features, but with what I consider suboptimal interfaces. Considering that SELinux configurations on Red Hat are now just slowly evolving from annoying to usable after many years of work, I can't see us mustering the resources to achieve a usable configuration of this in a reasonable time, let alone the resources required to verify the whole thing so that is actually provides some assurances rather than just another way to fiddle about with the system. The way I see this, the approach to be taken
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
On Wed, 17 Sep 2008, Peter Eisentraut wrote: System-wide consistency in access controls could be nice to have in some cases. But is it really achievable? In the typical three-tier web application scenario, do you really have system-wide consistency? Can you configure your application server using SELinux? Each of the tiers end up with mapping layer similar to the one implemented here to map the SELinux permissions - PostgreSQL. Java for example has a whole JVM security manager component that makes it straighforward to do such a mapping. http://articles.techrepublic.com.com/5100-10878_11-6178805.html is a good quick intro that shows how the call structure is similar to what the SE-PostgreSQL code does. And is SELinux really the desirable interface for a system-wide access control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or port SQL roles back to the operating system, or something else that captures what more people are actually using in practice. The main feature of SELinux that this crowd likes is how it manages privledge escalation risk. I'm not sure if POSIX ACLs for example are as effective at limiting the damage an exploitable suid binary can cause. As for what people are actually using, as someone who lives near the US capital I can tell you that installs using SELinux are quite plentiful around here--there really is no other UNIX-based technology for this purpose that's gotten traction inside this government like SELinux has. Anyway, even though I think picking SELinux as the primary security mechanism to integrate with is a sensible choice and I'm confident that the rest of the software stack isn't a problem, I do share your concern that implementing row and column-level security would make more sense in a general way first. Ultimately, I see this patch as an interesting proof of concept -- it got us on the NSA site anyway -- but I can't see more than three people actually making use of it I take it you've never seen how big the NSA fort^H^H^H^Hfacility is? I'm not sure exactly how many orders of magnitude your estimate is off by, but I know it's at least 2 just based on conversations I've been involved in with companies around here. A lot of the US defense and homeland security related companies are adopting open-source software stacks because they can audit every level of the software, and there's a big void in that stack waiting for a database with the right security model to fill. You are right that getting code contributions back again is a challenge though. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Peter, thanks for your comments. Let's review: *) System-wide consistency in access controls could be nice to have in some cases. But is it really achievable? In the typical three-tier web application scenario, do you really have system-wide consistency? Can you configure your application server using SELinux? I'm no expert on these things, but I wonder, would it even work in a useful way, over the network, with all the different threads, processes, and sessions going on? Or how about a desktop, pgAdmin with several database connections, can those be isolated from each other or whatever the security setup may be? It's a good question. Yes, it is possible no need to say. :) We can configure Apache to kick its contents handler with a proper security context. The contents handler is a sort of Apache module to handle various kind of web contents like *.html, *.php, *.cgi and so on. The existing module (mod_selinux) eanbles to invoke CGI program with a proper security context based on HTTP authentication. In addition, the upcoming Linux kernel got a feature to assign built-in scripts its security context. SELinux applied its access controls based on the assigned security context for various kind of objects like files, sockets, IPCs, tables, columns and so on. I can provide a demonstration, pelase wait for a while to set up. - For overing networks, The current SELinux provides the Labeled Networking feature. It enables to deliver a peer's security context to other peer side. We can fetch delivered one with getpeercon() API. SE-PostgreSQL also uses this API to obtain the security context of client process. (*) Note that SE-PostgreSQL does not depend on Database authentication. - For different threads, The upcoming Linux kernel got a feature to assign individual security context for a thread with a constraint to prevent information boundary violation. http://marc.info/?l=selinuxm=121992782231903 - For sessions, We can set a proper security context using session variable before invoking web applications, in same way as I noted above. However, I've not provide an implementation yet. And is SELinux really the desirable interface for a system-wide access control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or port SQL roles back to the operating system, or something else that captures what more people are actually using in practice. Yes, SELinux is one of the suitable facilities. It enables to describe its security policy using abstracted attributes called as security context, independent from a sort of subsystems. For example, the POSIX ACL is an accomplished access control stuff, but it is specific for filesystem. We have no way to apply it on network access controls. In addition, it enables to reduce privilege escalation risk as Greg Smith mentioned. *) Mandatory access control could be a useful feature for some users. But must we resort to SELinux as the configuration language and implementation backend? Why couldn't we implement a MAC system in SQL using the existing language? Also, what I read is that role-based access control (RBAC) systems are equally capable of providing the sort of stronger security that MAC users are typically looking for. (In some ways, it appears to be the newer thing.) PostgreSQL already has a pretty good role system, so we could perhaps look into enhancing that to meet the necessary functional criteria that may exist. I want you to understand the proposd design *NEVER* denies mandatory access controls based on other security engine. The PGACE hooks enables to swap the access control subsystem by the configure option. I also agree that PostgreSQL already has a pretty good role and access control mechanism. However, it is hard to describe mandatory access control policy in common forms between OS and RDBMS. I don't think dual-checks are matter. The operating system applies its DAC policy known as filesystem permission and MAC policy provided by SELinux (or other facilities). *) Row-level security, column-level security and so on should in my mind first exist as a native SQL-level feature. It would be hard to explain that PostgreSQL does not have column-level GRANT privileges but that you can achieve the same if you go through SELinux. After all, the SE-PostgreSQL patch only hooks in to several places to throw permission denied errors when appropriate, so native SQL features should be able to achieve the same. (Well, there are interesting SELinux-vs-AppArmor type differences here, that may be worth considering separately.) I cannot understand the reason why these native/newer access control facilities should have same access control guranualities. These are provided by different subsystems, so they have different guranualities and results. What is the matter? The relationship of them is designed by reference to DAC and MAC on operating system. As I noted above, it checks user's request twice based
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Peter, Abhijit, Could you tell me the current status of reviewing process in the CommitFest:Sep? I can understand the patches contain several new concept and a bit large, and it is a tough work to review them comprehensively. I'm not unconcern anything even if reviwing comments are partial one. However, I cannot improve anything without any comments. :( Did the previous message which I posted help you to understand the patches? If not, please feel free to ask me anything. Thanks, KaiGai Kohei wrote: Hello, The latest SE-PostgreSQL patches are updated here: [1/4] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1005.patch [2/4] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1005.patch [3/4] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1005.patch [4/4] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1005.patch They contains rebasing to the CVS HEAD, because we cannot apply the previous ones correctly due to progress in the base version. Rest of changes are here: - A new PGACE hook: pgaceIsAllowExecutorRunHook(). It enables to control overriding ExecutorRun_hook, because several important hooks are invoked from standard_ExecutorRun(). - T_SEvalItem related equal() functions are added to nodes/equalfuncs.c. # I've left for implement them. - Fix typo in src/include/security/pgace.h BTW, I thought I have to show the overview of the patch to help reviwers. The main patch ([1/4]) is especially big and contains new concepts. The following explanation shows several key concept of SE-PostgreSQL. I'm happy if it can reduce the load of reviwers. No need to say, please feel free to ask me anything. :-) Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Hello, The latest SE-PostgreSQL patches are updated here: [1/4] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1005.patch [2/4] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1005.patch [3/4] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1005.patch [4/4] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1005.patch They contains rebasing to the CVS HEAD, because we cannot apply the previous ones correctly due to progress in the base version. Rest of changes are here: - A new PGACE hook: pgaceIsAllowExecutorRunHook(). It enables to control overriding ExecutorRun_hook, because several important hooks are invoked from standard_ExecutorRun(). - T_SEvalItem related equal() functions are added to nodes/equalfuncs.c. # I've left for implement them. - Fix typo in src/include/security/pgace.h BTW, I thought I have to show the overview of the patch to help reviwers. The main patch ([1/4]) is especially big and contains new concepts. The following explanation shows several key concept of SE-PostgreSQL. I'm happy if it can reduce the load of reviwers. No need to say, please feel free to ask me anything. :-) Thanks, Security hooks -- We called it as PostgreSQL Access Control Extention (PGACE). The src/include/security/pgace.h newly added declares these hooks as inline functions. If HAVE_SELINUX is available at build time, they have a valid implementation to invoke functions to make access control decision. When the SE-PostgreSQL feature is disabled at build time or run time, it does not change any existing behavior. These hooks have a prefix of pgace, like pgaceHeapTupleInsert(). This hook is invoked just before inserting a new tuple into a relation, and the SE-PostgreSQL subsystem can make its decision. Its argument provides information to make a decision. The pgaceHeapTupleInsert() has four arguments like the target Relation object and newly inserted HeapTuple. Specifications of each hooks are described in the src/include/security/pgace.h. Security attribute management - We need a security attribute of tuple to use it as a basic of access control decision. SELinux calls it as security context, and most of security aware operating system has similar idea called as label. It is represented as a text format like system_u:object_r:etc_t:s0, and has its characteristic that many objects tend to share a single security context. We stores text represented security attribute into pg_security system catalog and put an alternate key (oid of pg_security) on each tuples, because it is unacceptable approach to put a raw string data on individual tuples. The alternate key is stored in the tail of HeapTupleHeader, as oid doing. This field is valid when t_infomask has HEAP_HASSECURITY bit. HeapTupleHeader +-+ | : | +-+ | t_infomask | +-+ pg_security system catalog |t_hoffo---+ +---+-+ +-+| | oid | seclabel | | : || +---+-+ | : || | 16389 | system_u:object_r:sepgsql_table_t:s0 | +-+| | 16401 | system_u:object_r:sepgsql_proc_t:s0 | |*Oid security_id*|- | 16402 | system_u:object_r:sepgsql_secret_table_t:s0 | +-+| | : | : | | Oid object_id || +-+ --+ | Data field| | : | The alternate key is just a internal representation, so we have to translate it to/from text format when communicating to in-kernel SELinux, or export/import them. Note that the security attribute is also assigned to tuples within system catalogs. A security attribute of a tuple within pg_attribute means column's security attribute, and used to column-level access controls, for example. The src/backend/security/pgaceCommon.c have functions to traslate them: char *pgaceLookupSecurityLabel(Oid security_id); Oid pgaceLookupSecurityId(char *security_label); When a new security_label is given and not found on pg_security, pgaceLookupSecurityId() tries to insert a new tuple into pg_security and returns its object id as an alternate key. Two more similar functions are also declared: char *pgaceSidToSecurityLabel(Oid security_id) Oid pgaceSecurityLabelToSid(char *security_label) It also enables to translate between a cosmetic text format and an internal security identifier. An example of cosmetic format is: unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh We have a case when `pg_security` system catalog is not available because
