Re: [HACKERS] contrib/sepgsql regression tests are a no-go
Robert Haas wrote: On Tue, Sep 27, 2011 at 6:30 PM, Tom Lanet...@sss.pgh.pa.us wrote: snip If I have to break up the recipe with annotations like run this part as root and then these commands no longer need root, I don't think that's going to be an improvement over either of the above. Fair enough, I'm not going to get bent out of shape about it. There's some aesthetic value in the way you're proposing, and anyone who is doing this ought to know enough to make the details of how you write it out mostly irrelevant. Long term a better option may be to use mocking to test policy enforcement without modifying the system policy. I've used test-dept http://code.google.com/p/test-dept/ on a couple projects and while it is a huge pain to get up and running it is very nice for mocking outside code (in this case libselinux calls) and getting predictable output to test your functionality. It would also let you run the tests on a non-SELinux system. There are other c mocking frameworks, this is just the one I have experience with. test-dept might not be suitable for Postgres because it uses arch-specific awk scripts to munge symbol tables, and only supports x86, x86_64 and sparc right now. -- 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] Adding support for SE-Linux security
Stephen Frost wrote: Tom, snip The proposals to make SEPostgres drive regular SQL permissions never came out of anyone from that side, they were proposed by PG people looking for a manageable first step. I do not believe this to be accurate. Josh, were you able to find any public documentation on Trusted Rubix (is that the right name?)? The RDBMS security policy hashed out on the SELinux list during the discussion of Rubix and SEPG certainly included support for table-level objects, did it not? I expect that the SELinux list contributors would have pointed out if they didn't feel that was at all valuable. Trusted RUBIX does use the same SELinux object classes and permissions that were originally added to the policy to support SEPostgreSQL. You can look at http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf and see how they use SELinux in their RDBMS. Pay particular attention to page 15 where they are saying which object classes and permissions they are using. They even implement row level security (the db_tuple object class) Perhaps what is at issue is the terminology being used here though, or the approach to enforment being considered. Part of the discussion at the BWPUG meeting involved the option for SEPG to be a more-restrictive only model in it's implementation. Essentially, this means that all permissions handling is done the same as it is today, except that once the PG model has decided an action is allowed, SEPG kicks in and does any additional checking of the action being requested it wants and may deny it. At the end of the day, I don't feel that it really changes the architecture of the code though. Perhaps users of SELinux will always want that, but the argument we've heard time and time again here is that this should be a generalized approach that other security managers could hook into and use. To do that, I feel we first have to start with the PG model, which *does* care about all the SQL permissions. Let's extract the various complaints and concerns about SELinux that have been thrown around this list and instead consider our first client of the PG modular security framework to be the existing PG SQL permissions system. If we can agree to that, then it's clear that we can't just hand-wave the requirement that it be capable of driving the regular SQL permissions. Whatever you might believe about the potential market for SEPostgres, you should divide by about a hundred as long as it's only an alternate interface to SQL permissions. See particularly here: http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG#Revisiting_row-level_security Without it, it's questionable whether committing the existing stripped-down patch really accomplishes anything --- how much clearer can they be? Again, let's please address row-level security first at the PG level. That was recommended previously by many on this list and is clearly a useful feature which can stand alone in any case. If you're not prepared to assume that we're going to do row level security, it's not apparent why we should be embarking on this course at all. And if you do assume that, I strongly believe that my effort estimate above is on the optimistic side. I do assume we're going to do row level security, but I do not feel that we need to particularly put one in front of the other. I also feel that SEPG will be valuable even without row-level security. One of the realms that we discussed at BWPUG for this is PCI compliance. I'm hopeful Josh will have an opportunity to review the PCI compliance cheat-sheet that I recall Robert Treat offering and comes to agreement that SEPG w/o row-level security would greatly improve our ability to have a PCI compliant system backed with PG. Thanks, Stephen -- 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] SE-PostgreSQL/Lite Review
Greg Smith wrote: It's funny; we started out this CommitFest with me scrambling to find someone, anyone, willing to review the latest SE-PostgreSQL patch, knowing it was a big job and few were likely to volunteer. Then schedules lined up just right, and last night I managed to get a great group of people all together to do perhaps the biggest single patch review ever, to work on just that. I gathered up a list of the biggest concerns about this feature and its associated implementation, we got a number of regular PostgreSQL hackers and two of the security guys you've seen on this list all in the same room, and we talked about little but SEPostgreSQL for hours. Minutes are at http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd suggest anyone interested in this feature (or in rejecting this feature) to take a look at what we covered. I just wanted to add some talking notes here. User base for the feature: While my goals for this feature line up with military/government users this is in no way the extent of the potential user base. The fact is most people won't know they want this feature until it is available. Why is that? Well, how many of you have written webapps and implemented policy logic in your application rather than the database level? Why do people currently feel the need to do this? Is it even possible to implement some complex policies (eg., PCI compliance) at the database level? If PostgreSQL version whatever suddenly had the ability to implement the policy logic in the database, would you move it there? I know I would.. Audit: In past conversations it sounded like some of the Postgres community was skeptical even about the design of the security model. For an even earlier look (September 2006) of KaiGai and the SELinux community talking about the object model and even high level design of the solution see http://marc.info/?l=selinuxm=115762285013528w=2 I've read through some of the prior patches, but haven't done an extensive audit, not only because of the size but because it became apparent relatively quickly that it was a waste of time and the community here wasn't going to accept it anyway. If this situation changes I think you'll find a few of us willing to donate time to the cause. Policy: The policy is easy once you have an object model that covers your use cases. You can see in the above discussion how we came to the object model we have now and why I've been comfortable with it since then. An interesting aside, we must have hit the object model pretty well since another RDBMS (Trusted Rubix) uses the same one as SEPostgreSQL. See http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf Works outside of SELinux: As Stephen already pointed out, Casey Schaufler (CC'd) who is the author of SMACK http://schaufler-ca.com/ believes that the abstractions provided by PGACE will allow integration of his security system as well. SMACK is already in the Linux kernel as an alternative LSM to SELinux. Further, not that I've seen the code or know how they did it, Trusted Rubix has support for multiple access control systems http://rubix.com/cms/features including Trusted Solaris, Solaris Trusted Extensions, SELinux and their own RBAC system. -- With all that said, I've very interested in seeing this work move along. In its current shape it has limited utility in my world (although I know of at least 2 solutions I've seen that run 20 Postgres servers on a single system just to have database separation). The main thing that prevents it from being used in that situation today is superuser access (eg., we can't have superusers that can go around and muck in data he's not cleared for). But I recognize that this is a first step to a potentially great system and I definitely want to see it moving forward. -- 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] SE-PostgreSQL/Lite Review
Joshua Brindle wrote: Greg Smith wrote: It's funny; we started out this CommitFest with me scrambling to find someone, anyone, willing to review the latest SE-PostgreSQL patch, knowing it was a big job and few were likely to volunteer. Then schedules lined up just right, and last night I managed to get a great group of people all together to do perhaps the biggest single patch review ever, to work on just that. I gathered up a list of the biggest concerns about this feature and its associated implementation, we got a number of regular PostgreSQL hackers and two of the security guys you've seen on this list all in the same room, and we talked about little but SEPostgreSQL for hours. Minutes are at http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd suggest anyone interested in this feature (or in rejecting this feature) to take a look at what we covered. I just wanted to add some talking notes here. User base for the feature: While my goals for this feature line up with military/government users this is in no way the extent of the potential user base. The fact is most people won't know they want this feature until it is available. Why is that? Well, how many of you have written webapps and implemented policy logic in your application rather than the database level? Why do people currently feel the need to do this? Is it even possible to implement some complex policies (eg., PCI compliance) at the database level? If PostgreSQL version whatever suddenly had the ability to implement the policy logic in the database, would you move it there? I know I would.. Audit: In past conversations it sounded like some of the Postgres community was skeptical even about the design of the security model. For an even earlier look (September 2006) of KaiGai and the SELinux community talking about the object model and even high level design of the solution see http://marc.info/?l=selinuxm=115762285013528w=2 I highly suggest a quick read of the above thread, it shows how we established an object model in fairly short order. The conversation also continues here: http://marc.info/?l=selinuxm=115786457722767w=2 and also here: http://marc.info/?l=selinuxm=117160445604805w=2 http://marc.info/?l=selinuxm=117160445611588w=2 http://marc.info/?l=selinuxm=117160445608517w=2 -- 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] SE-PostgreSQL/Lite Review
Stephen Frost wrote: KaiGai, snip I do think that, technically, there's no reason we couldn't allow for multiple only-more-restrictive models to be enabled and built in a single binary for systems which support it. As such, I would make those just #if defined() rather than #elif. Let it be decided at runtime which are actually used, otherwise it becomes a much bigger problem for packagers too. It isn't just a case of using #if and it magically working. You'd need a system to manage multiple labels on each object that can be addressed by different systems. So instead of having an object mapped only to system_u:object_r:mydb_t:s15 you'd also have to have it mapped to, eg., ^ for Smack. -- 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] [PATCH] SE-PgSQL/tiny rev.2193
Greg Stark wrote: On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindlemet...@manicmethod.com wrote: I am capable of speaking for Tresys in this matter. We are very interested in this work and our US DoD customers need the capabilities that this project adds (assuming row level access controls are a possibility). I'm kind of curious about how these features get used. What specific problems do they solve? Backing up from KaiGai's description a bit, basically what this is needed for is storing multilevel data in a single db instance. For example, you have people logging in from different classifications (unclass, secret, top secret, etc) and the data they put in is marked (labeled) with their classification label. Then for queries the policy is used to determine who can see what. An unclass user will only be able to see unclassified data. A top secret user, however, can see all the data from top secret, secret and unclassified. This is why the view model doesn't work, we need 'read down' support. This also implies that key constraints are held between data of differing levels. This has some information leak side effects (eg., if an unclass user inserts data then waits 5 minutes and inserts again and sees the key incremented greatly he knows lots of classified data is going into the database) but this is a small information leak compared to the gain in functionality of a read-down system. The alternative to having this built in to the system is having many instances of postgres (or something else) running and having to query the right one to get the data (or all of them) and manually collating and associating rows. Very non-ideal. I have seen this method used en luau of having a multilevel database. Another scenerio is that all the data being put in is of some classification (eg., radar data coming from a piece of equipment is all marked secret) but some of the data is top secret. For example a column that has precise coordinates of enemy soldiers is higher classification than the rest of the data. A secret user may be allowed to query the data with some 'fuzz', through a trusted stored procedure. So the secret user wouldn't have direct access to the coordinates but could call a stored procedure to get the information with precision removed. This is why column level, row level and stored procedure access controls are all really required for the applications we are looking at. -- 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] [PATCH] SE-PgSQL/tiny rev.2193
Greg Stark wrote: On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindlemet...@manicmethod.com wrote: Backing up from KaiGai's description a bit, basically what this is needed for is storing multilevel data in a single db instance. For example, you have people logging in from different classifications (unclass, secret, top secret, etc) and the data they put in is marked (labeled) with their classification label. I'm beginning to wonder if we haven't gone about this all wrong. Every time someone asks my question about use cases the only answers that come back are about row-level security. Perhaps that's the only case that really matters here. If we provide a way to control access to database objects through SELinux policies -- ie, one which is functionally equivalent to what we have today but just allows administrators to control it in the same place they control other SELinux system privileges, is that useful? Is that something SE administrators want? Or are they happy to use Postgres roles and grants and just want the finer row-level data access controls? No, for multiple reasons. First a single person (role) could be logging in at different levels (eg., running the same application as the same linux user with the same credentials) and would need to see different things from the database. The SELinux contexts would provide the differentiation in this case and the SELinux policy would enforce the multilevel policy. I also don't think your roles and grants could enforce a multilevel policy but that is something I'd have to look into deeper to know for sure. Also the objects need to be labeled based on how they were inserted, and 're-grading' applications need to be able to relabel them. You still need the 'read-down' behavior I talked about above. You also snipped the other scenario I had where row based access control isn't required but column level and stored procedure level are. I understand you already have column level access controls but it still goes back to how the user is accessing the data, as a top secret user who can read the column with full precision or as a secret user with precision removed via a trusted stored procedure. The SELinux policy would have to give the stored procedure the ability to read the column and trust it to remove the necessary amount of precision. -- 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] [PATCH] SE-PgSQL/tiny rev.2193
Greg Stark wrote: On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindlemet...@manicmethod.com wrote: You also snipped the other scenario I had where row based access control isn't required but column level and stored procedure level are. Well we already have column level and stored procedure privileges. I understand you already have column level access controls but it still goes back to how the user is accessing the data, as a top secret user who can read the column with full precision or as a secret user with precision removed via a trusted stored procedure. Sure, and people do this every day already with postgres roles and privileges. The SELinux policy would have to give the stored procedure the ability to read the column and trust it to remove the necessary amount of precision. Well the question is: Is the important feature of SEPostgres the unification of the privilege model with every other piece of the system in the SELinux policy? Or is that not the main thing and only the row-level access security is interesting. None of the use cases seem to put any emphasis on the unification of the security policy. I don't understand how you came to this conclusion. Quoting from my prior email: No, for multiple reasons. First a single person (role) could be logging in at different levels (eg., running the same application as the same linux user with the same credentials) and would need to see different things from the database. The SELinux contexts would provide the differentiation in this case and the SELinux policy would enforce the multilevel policy. In this case the selinux context (which specifies their MLS level) says the user is running at unclass and there should be no possible credentials or role or anything that gives him access to data above unclass in the database. This _is_ a unification of the policy because whether the unclass user is accessing files or rows in a mixed-level database or entire databases that are classified as such the SELinux policy is governing that. Its the same with selinux aware X. If a user is running 2 database clients, one at unclass and one at secret then each application would how the appropriate results. The policy also disallows that user from copying from the secret database client into the unclass client (in this case there are SELinux rules enforcing behavior of X apps, of the database clients and of the filesystem), unified indeed.
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
Robert Haas wrote: On Sat, Jul 18, 2009 at 7:10 AM, Martijn van Oosterhoutklep...@svana.org wrote: On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote: I'm starting to think that there's just no hope of this matching up well enough with the way PostgreSQL already works to have a chance of being accepted. What I'm understanding here is the apparent requirement that the SEPostgreSQL implementation be done in a way that a generic SELinux policy that has been written for an operating system and file system can be applied to PostgreSQL without change and do something useful. I can see merits for or against that. But in any case, this needs to be clarified, if I understand this requirement correctly anyway. Indeed. My impression was also that there are existing SELinux rules and permission concepts already in use and people would like to apply them to PostgreSQL, which puts the translation layer inside postgres. However, from the postgres side there appears to be a push to make unique postgresql SELinux rules and requiring every user of SELinux to do the mapping of rights to postgresql specific terms. I think this is only semi-accurate. My impression is that a supposedly generic policy has been written for database objects and merged into model SE-Linux policy, but I think that was done largely in the hops of implementing SE-PostgreSQL. It would be one think if KaiGai showed up and said, see, there are three other databases that do this, now we want you to do it too, that would be one thing. But I don't think that's the case: I believe that we are the first, which makes the argument that we have to conform to the standard ways of doing this a lot weaker. FYI Trusted RUBIX already has SELinux integration in their DBMS: http://www.nsa.gov/research/selinux/list-archive/0807/26900.shtml They are using the same SELinux object classes that KaiGai developed for SE-Postgres. Specifically, creating SELinux permissions for CREATE LANGUAGE seems particularly useless since that's not a data protection issue. The same with aggregates, operator classes, etc. ISTM the goal of SELinux is not primarily to restrict DDL but mostly to protect the data. I'd actually be willing to buy that. If KaiGai wants to take the list of objects for which SE-PostgreSQL supports grantable permissions and the list of objects for which $COMPETITOR supports permissions and implement only the intersection of the two, I think that would be reasonable. What I don't think is reasonable is trying to implement, in the first version of the patch, 50 types of permissions that we never had before, or on the other hand such a trivial percentage of what we already do that it's totally useless. The reason for comprehensively protecting objects isn't necessarily about protecting the data in the database but for limiting information flow between clients of differing security levels. Eg., if someone top secret can create language and use that to pass information down to someone unclassified then postgres could be used as an information downgrader illegitimately. Personally I find the idea that SELinux permissions need to meet parity with the existing permission structure crazy, since it's not going to replace the existing permissions, just supplement them. Maybe it is crazy, but here are my concerns... 1. If the permissions work in a way that is very different than the existing permissions, then they need lots and lots of hooks all over the code. And nobody except KaiGai understands why those hooks are where they are instead of somewhere else. That's going to make it difficult to maintain. 2. If we add a lot of new kinds of permission checks that PostgreSQL has never done before, using a framework that none of the committers understand, how do we verify that they are well-designed (correct, secure, etc)? I am fairly well convinced that the design for row-level security was a really bad design. Whether I'm right or not, I think something like that is far too large a feature to add by the wayside in the context of another patch. 3. As far as I can tell, there is a lot of resistance from the committers who have looked at this patch (Tom, Peter, and maybe Bruce, though I think his review was not quite so unfavorable) to the idea of committing it at all. I don't think they're going to be willing to work extra-hard to implement security features that are only going to be useful to people using SE-Linux. I've said it before but I have firsthand knowledge of people wanting/waiting for SELinux integration into Postgres (or any open source DBMS) For what it's worth, this problem is not confined to the committers: SE-PostgreSQL is the only patch that I had people specifically tell me they didn't want to review because they just didn't care about it. Frankly, I don't care about it much either: ordinarily, the first and last thing I do with SE-Linux is shut it off. What is making me care even less is the fact
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
Martijn van Oosterhout wrote: On Mon, Jul 20, 2009 at 10:52:44AM -0400, Joshua Brindle wrote: Specifically, creating SELinux permissions for CREATE LANGUAGE seems particularly useless since that's not a data protection issue. The same with aggregates, operator classes, etc. ISTM the goal of SELinux is not primarily to restrict DDL but mostly to protect the data. The reason for comprehensively protecting objects isn't necessarily about protecting the data in the database but for limiting information flow between clients of differing security levels. Eg., if someone top secret can create language and use that to pass information down to someone unclassified then postgres could be used as an information downgrader illegitimately. Consider the pl/pgsql language. The creation of the language must be protected, because it involves loading shared libraries and thus could be used to bypass the system. However, once loaded the language only uses the internal SQL interface and thus is subject to the restrictions imposed by the caller (except for setuid functions ofcourse). Would you agree if the language is transparent with respect to permissions that *usage* of the laguage doesn't need to be restricted. Using something is typically controlled because of information you may get from using it (for example, stat() on a file may not get you the data in the file but it gets you plenty of other information). I guess the question is, can the person creating the language leak information to people using the language and it sounds like they can. However, because language creation is controlled via superuser privilege (which is never ideal, we like to be able to break superusers up and give them only permission to do what they need to do, principle of least privilege) then it is probably a lot less important than many of the other things KaiGai is trying to get in. I'm asking because from my position it looks like KaiGai is being simultaneously told you patch is too big, make it smaller and your patch is not complete (with respect to some metric), make it bigger and we need to define a middle ground if we want to avoid the appearence of moving goalposts. Agreed, there are lots of mixed signals in this thread. For my uses the 'basic' support being pushed won't be enough to use this in secure applications, nothing less than full row-level access control would be. I'm all for the community taking smaller patches over time but if there is no intention of going all the way at the end then I'm not sure what you/we are gaining. -- 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] [PATCH] SE-PgSQL/tiny rev.2193
Tom Lane wrote: Martijn van Oosterhoutklep...@svana.org writes: I'm asking because from my position it looks like KaiGai is being simultaneously told you patch is too big, make it smaller and your patch is not complete (with respect to some metric), make it bigger and we need to define a middle ground if we want to avoid the appearence of moving goalposts. Well, the assumption behind the make it smaller advice was that followon patches might re-add (some of) the advanced functionality once we had a basic connection to SELinux up and running. So yes, there's an expectation of the goals changing over time, and I don't see a reason to apologize for that. But on the whole the problem is that the community just isn't interested in this topic. Every so often somebody pops up and tells us if you build it they will come, but there is a complete lack of hard evidence that there's significant interest out there. Without that, I don't think we'll ever get to the point of wanting to put in the work to make it happen and then support it over time. This is a huge project, and taking it seriously will mean draining resources away from other high-priority issues. We need way more evidence of interest than has been presented. How many people are you looking for? Is there a number or are you waiting for a good feeling? The unfortunate part is that many of the people that would use it are unable to publicly say so. -- 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] [PATCH] SE-PgSQL/tiny rev.2193
Peter Eisentraut wrote: On Monday 20 July 2009 21:05:38 Joshua Brindle wrote: How many people are you looking for? Is there a number or are you waiting for a good feeling? In my mind, the number of interested people is relatively uninteresting, as long as it is greater than, say, three. What is lacking here is a written specification. When it comes to larger features, this development group has a great deal of experience in implementing existing specifications, even relatively terrible ones like SQL or ODBC or Oracle compatibility. But the expected behavior has to be written down somewhere, endorsed by someone with authority. It can't just be someone's idea. Especially for features that are so complex, esoteric, invasive, and critical for security and performance. Who do you consider has authority? The security community has as many opinions as any other. There are papers written on mandatory access controls in rdbms's but they are mostly about multi-level security, which SELinux has but primarily uses type enforcement. The SELinux community are all on board with KaiGai's object model (the object classes and permissions and how they are enforced), there has been quite a bit of discussion about them over the years. Trusted RUBIX integrated SELinux using the object classes that KaiGai made for SEPostgres. So I think if you want to get anywhere with this, scrap the code, and start writing a specification. One with references. And then let's consider that one. Harsh. -- 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] [PATCH] SE-PgSQL/tiny rev.2193
Ron Mayer wrote: Joshua Brindle wrote: How many people are you looking for? Is there a number or are you waiting for a good feeling? snip Joshua - if you're still associated with Tresys - could someone who could speak for that company say what they think about this project? The seem quite in-the-loop on what SELinux customers want. I am capable of speaking for Tresys in this matter. We are very interested in this work and our US DoD customers need the capabilities that this project adds (assuming row level access controls are a possibility). -- 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] Updates of SE-PostgreSQL 8.4devel patches (r1530)
KaiGai Kohei wrote: KaiGai Kohei wrote: The series of SE-PostgreSQL patches are updated: [1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch [2/5] http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1530.patch [3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1530.patch [4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1530.patch [5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1530.patch BTW, what is the current status of revewing the patches? Is it necessary to wait for a few days more? If you have anything unclear, please feel free to ask me anything. Yes, what was the decision about 8.4? Is this going to make it in? Thanks, - List of updates: * These are rebased to the latest CVS HEAD because of conflictions. - The src/include/catalog/pg_proc.h got a confliction due to the newly added SQL functions. - The src/bin/pg_dump/pg_dump.c got a confliction due to the stuff to dump toast_reloptions. * bugfix: An incorrect procedure entry for sepgsql_server_getcon(). * cleanup: A strange error message in testcases. Rest of parts are unchanged. Please comment anything. Thanks, -- 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] How to get SE-PostgreSQL acceptable
Josh Berkus wrote: Joshua, Kohei-san, So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all features *except* row-level security, would it still be useful to the SELinux community? I think we're just not going to work out the headache-inducing issues around row-level security in time for 8.4, and it seems to me that integrated system-level security labels at the table-and-column level are still very useful, even without row-level security. Sorry for the delay in answering, I'm currently on vacation (I haven't been able to catch up on this thread yet either, I'll try to a little later). The answer is yes, at least to get people started using it and make sure there are no practical issues with the security model sans row access control. But as I said earlier row based access control is going to be the most compelling part so hopefully the issues everyone is having can get worked out and the community will agree on the path forward, sooner rather than later. -- 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] How to get SE-PostgreSQL acceptable
Bruce Momjian wrote: KaiGai Kohei wrote: Why an OID? We store acl items now without a lookup table; I think there will be at most the same number of SE-Linux entries. Also, by using text we avoid the problem of cleaning out unreferenced pg_security rows, improve performance (no lookups), and simplify the code. The reason why I concern about text formed security context is it has variable length, so it requires to deform/form a HeapTuple again when SE-PostgreSQL assigns a default security context. If a user inserts a new tuple into pg_ without explicit security context, it has to be labeled based on security context. We cannot estimate what string will be given prior to ExecInsert(), it needs to put a security label on the given HeapTuple. If is is a fixed length variable (like oid), it is not necessary to deform/form them. So, I prefer the security identifier. In addition, it also has performance gain. The current architecture does not need to look up pg_security in most cases. SE-PostgreSQL caches results of access controls in userspace to reduce the number of kernel invocation. (In generally, context switch is a heavy one.) All cached entries are tagged by its security identifier, so we can lookup the entry without string comparing. The text form is used only when it could not find the entry on the cache. In this case, SE-PostgreSQL translate security identifier into text form and ask for in-kernel SELinux. It requires a text form due to the protocol. That is an interesting optimization I had not thought of. Just as an FYI, SELinux does this in general. There is an access vector cache in the kernel that caches the access computations, and there is also a userspace implementation in libselinux that most apps use. KaiGai reimplemented the AVC because he wanted it to work in a shm and be shared by multiple postgres processes. There is also a sidtab which is just a hashtable that maps string contexts to sids. The sidtab is filled at runtime and not persistent across boots, which means the contexts are generally stored as text on the persistent medium (like the xattr's on the filesystem). It doesn't matter from a security perspective whether the contexts are stored as strings or sids, its just an optimization you guys need to work out. At least, we cannot apply this scheme on the next phase (row-level) due to the storage consumption and others. So, I don't think it is a preferable way to design the first step without ignoring upcoming expandability. The big problem is that the security value on system tables controls the _object_ represented by the row, while on user tables the security value represents access to the row. That is just an odd design, and why a regular system table security value makes sense, independent of the row-level security feature. I may not be understanding this but I don't see why. In SELinux everything is an object, and all objects have contexts. No access is specified on the object or in the context, that is all done in the policy currently loaded in the security server. system tables and user tables shouldn't be treated differently implementation wise, they should just have a context and defer the decision making to the policy. In practice the system tables (and rows within the tables) would have a context that restricts access tightly, but this is up to the policy, not the implementation. FYI, it is possible we might implement row-level security a different way in 8.5. -- 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] How to get SE-PostgreSQL acceptable
Bruce Momjian wrote: Tom Lane wrote: Gregory Stark st...@enterprisedb.com writes: I don't think partitioning is really the same thing as row-level security. Of course not, but it seems to me that it can be used to accomplish most of the same practical use-cases. The main gripe about doing it via partitioning is that the user's nose gets rubbed in the fact that there can't be an enormous number of different security classifications in the same table (since he has to explicitly make a partition for each one). But the proposed implementation of row-level security would poop out pretty darn quick for such a case, too, and frankly I'm not seeing an application that would demand it. OK, putting on my crazy idea hat, if we split the primary and foreign keys by partition, it would give us polyinstantiation: http://en.wikipedia.org/wiki/Polyinstantiation because our unique indexes do not apply across partitions. Polyinstantiation is a desirable security feature and one that would be tough to implement without partitions. Polyinstantiation in this manner won't do it I don't think (if I'm understanding you correctly). As KaiGai already said, SELinux policy is flexible so we'll have more than just BLP policy to worry about. Also a top secret user will need to see all rows when he selects, and they should still have unique keys. He won't be able to write to secret or unclass rows but he'll be able to see them. Further, a secret user may be able to see top secret rows, but not some of the columns, going back to my coordinates example. He'd have to use a trusted stored procedure that can do the necessary operations to fuzz the data. A flexible policy is really the crux of this. We aren't trying to reproduce what other DBMS's have done, we are trying to integrate with a completely flexible policy from the ground up. -- 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] How to get SE-PostgreSQL acceptable
KaiGai Kohei wrote: Stephen Frost wrote: * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: So, I cannot believe refactoring pg_xxx_aclcheck() is not acceptable. If vanilla PostgreSQL become to check ACLs on tables, independent from views, do you think it is acceptable? Well, just to be clear, ACLs are checked on tables under views, but they're checked using the privileges of the view owner rather than the privileges of the current user. I've run into that empirically because I've gotten 'permission denied' errors when using a view that I've clearly got full rights on but was owned by someone else (who didn't have rights on the table underneath). That being said, I'd think that if we do need different semantics from that for SE-PostgreSQL, we could implement it using a GUC or similar to keep the current behavior as well allow the SE-PostgreSQL behavior. I think it is not reasonable. If there are different philosophies, one for one seems to me straight forward approach, for security especially. When we talk about mandatory access control we are generally very clear that for it to be mandatory and for the policy to be analyzable you must identify objects unambiguously. For SE-Postgres this is an absolute necessity. At the same time, if view-based ACL's are there, and people want them and use them then that doesn't affect us (the people that want to use sepostgres). They must be orthogonal and sepostgres must have a way of unambiguously labeling objects. However, we have to make clear whether the PGACE architecture is incorrect, or not, at first. It really bothers me that it seems like these kinds of reviews of the larger patches don't happen until it's time to decide about the next release. Perhaps these issues were all brought up seperately in prior threads, or they weren't articulated as requirements or show-stoppers, and if so then I apologize for not following those more closely. As a new-comer to this discussion (and indeed this list/community) I find it baffling that a patchset that has been around this long is just now having basic architectural questions asked about it. If the approach Peter outlined is what core wants to see and is willing to go along with to get SE-PostgreSQL included then let's please decide that now and agree that unless some serious problem comes up we'll stick to it and not require the whole thing be rewritten again later. As I noted, PGACE is not my goal. I don't tremble to integrate SELinux related code into the core. Flask (from which SELinux is derived) has the basic architecture of separating enforcement from policy. This generally means that a security server (or backend) knows what the policy is and how to calculate access vectors and it passes those answers to the enforcement points. Flask itself is a framework. In Linux and Xorg a more general framework was built that interfaces to flask, because the flask security server wasn't seen as something that could implement any kind of security policy (whether that is correct or not is a point of contention, as the selinux security server already implements a kind of RBAC, type enforcement and multilevel security). PCACE is, architecturally, similar to LSM in the linux kernel and XACE in in Xorg but is not an absolute necessity for SELinux integration. I'm not sure about KaiGai's feelings on this, but it strikes me that adding SELinux support for the existing levels of access control in PG might be straight-forward and small enough to include for 8.4 and would show some commitment to this approach of do it for PG, add SELinux checks for it. Alternatively, maybe a progression-towards-SE-PostgreSQL wiki/webpage that outlines the plan, current work, what's been committed, etc, that everyone reviews and agrees to? If you look at the patches you'll see that the bulk of them are adding the SELinux infrastructure. An access vector cache, the label translation functions, the libselinux interface and so on. Over 2/3's of the patch is in src/backend/security. I'm not sure how much it would cut to remove row level access controls, but I do have some points here. To me, row level access controls are the most important part, this is the feature that lets us put secret and top secret data in the same table and use the clients selinux context to decide what they can see, transparently and without modification to the application. Without it you have to use seperate postgres instances, modify the application to select from different sets of tables depending on their label and so on. That said, SELinux didn't start out as fine grained as it is today. A fair number of object classes were present back in '99 when it started but more have been added over time, the policy infrastructure allows that to happen, in fact the policy allows object class/permissions to be added, removed and modified if the access controls were inadequate or unnecessary. Are you saying enlargement step-by-step,
Re: [HACKERS] How to get SE-PostgreSQL acceptable
Tom Lane wrote: Joshua Brindle met...@manicmethod.com writes: I'm not sure how much it would cut to remove row level access controls, but I do have some points here. To me, row level access controls are the most important part, this is the feature that lets us put secret and top secret data in the same table and use the clients selinux context to decide what they can see, For me, the row-level access controls are really the sticking point. There is absolutely nothing you can say that will convince me that they don't break SQL in fundamental ways, and I also don't believe that it's going to be possible to implement them without a constant stream of bugs of omission and commission. (Those two points are not unrelated.) This isn't going to be something that the vast majority of your users use. The people that need them understand the ramifications of row filtering and the absence of inaccessible rows won't be surprising. Now that you've admitted that you aren't trying to accomplish the equivalent sort of data hiding within the filesystem, the argument that We apply access controls on reading and writing files, this is equivalent (in my mind) to applying access controls on tuples, as they are the structured object holding data (just like files). you have to have them seems fairly weak, certainly not strong enough to justify the costs. We have already touched on some ways that you can The costs are nil for people who don't want this feature. accomplish similar goals with just table- and column-level access permissions, which are well understood and don't violate anyone's I've already pointed out how table and column level access control don't provide enough. Holding data of multiple classifications in a single table is something of great concern. Unmodified applications need to be able to query out of a table and get the data they are cleared to see. Column level access control doesn't help because those same applications, of course, will need access to the data in those columns. Splitting data into different tables isn't an option in many cases because applications aren't always configurable wrt to the database or tables they use. Further, clients of multiple clearances should be able to use the same application, and we can not trust the application to make the decision as to which database or table is correct. And even further, maintaining multiple sets of databases or tables that hold the same kinds of information (and therefore have the same schema) is a maintenance, backup and restoration issue. expectations. There's probably a need to twiddle our permissions rules for inheritance/partitioning cases, but that was already on the table anyway for other reasons. partitions don't help because, once again, the application would be making the determination about which partition to query. For mandatory access control that we need in the kind of environments to work the application doesn't get to make security relevant decisions, the database holds the data and needs to say who can access it. Further, partitioning isn't fine grained. I can't say user X can read secret rows and read/write top secret rows and get that data out in a transparent way (the applications would have to be aware of the partitions). Relabeling of data also looks like a challenge with partitions (if I correctly understand how they work). I could be persuaded to get behind a patch that does Peter's step #1 (ie, use SELinux permissions as an additional filter for existing SQL permission checks). I don't believe I will ever think that row-level checks are a good idea; as long as those are in the patch I will vote against applying it. We've already used postgresql in sensitive environments and had to make compromises because of the lack of fine grained access control. We've been telling customers for years that we hope postgresql will have said access controls in the future and that it will help them solve many of the problems they have. We've been enthusiastic about the work KaiGai has been doing with respect to the environments we operate in and it would be a shame for all that to be discarded. -- 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] How to get SE-PostgreSQL acceptable
Ron Mayer wrote: Stephen Frost wrote: And, just to go full circle, row-level access controls are exactly what the other enterprise RDBMSs have and is what is used in these security circles today. One of the major issues, as I understand it, is to be able to use stock applications with multiple security levels where the application doesn't know (or care about) the security level. Doing that through views and partitions and triggers and whatnot for each and every application that is run on these systems will be a big hurdle to those users, if it ends up being workable at all. That seems to me to be a shortcoming of the partition system and a good TODO for the future partitioning improvements. Why shouldn't be just as easy to make sure a row ends up in the right partition as opposed to making sure it's tagged with right row-level ACLs. In reality it isn't, unless postgres won't mind thousands of partitions being made. In the military/gov implementations BLP lets you have hierarchical levels and non-hierarchical categories. Since I linked to an article about it upthread I assumed everyone participating was familiar but perhaps not. Typically there are 3 levels, unclass, secret, top secret. In addition to those 3 levels there may be a few, hundreds or even thousands of categories. Those categories apply to each of the levels so if you are using 1000 categories you have 3*1000 possible BLP labels. On top of that SELinux has users, roles and types, which are all also multiplied. There is a reason we don't do things like have 3 filesystems, one for unclass, one for secret and one for top secret. Partitions/views may be a good way to implement row-level access control when there are a few different options but they won't necessarily be known ahead of time. We don't want to encode policy logic in to the database itself, that is why we have a separate security server that handles the policy. The system should scale to any number of contexts that are available on the system. Relabeling with partitions (that is, moving things from one partition to another) seems to be handled with triggers, which is inconvenient to the application developers but also devastating to the security system (unless you can map triggers back to who did the operation that caused them), and managing partitions on dozens or hundreds of tables and moving data between them in those tables seems at the very least challenging. I also have questions concerning partitions. Perhaps someone wants to use partitions for a functional purpose (eg., to split log entries by month/year). What would be the affect of concurrently using partitions to split security contexts out? Nonetheless, this conversation seems moot now that Tom has walled off and won't even discuss row-level access controls. Cheers. -- 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] How to get SE-PostgreSQL acceptable
Tom Lane wrote: Joshua Brindle met...@manicmethod.com writes: In reality it isn't, unless postgres won't mind thousands of partitions being made. In the military/gov implementations BLP lets you have hierarchical levels and non-hierarchical categories. Since I linked to an article about it upthread I assumed everyone participating was familiar but perhaps not. Typically there are 3 levels, unclass, secret, top secret. In addition to those 3 levels there may be a few, hundreds or even thousands of categories. Those categories apply to each of the levels so if you are using 1000 categories you have 3*1000 possible BLP labels. On top of that SELinux has users, roles and types, which are all also multiplied. Hmm. If that's the expected application environment then the patch as It's one application environment, maybe not a common one but one I've seen. proposed has fatal performance problems anyway, for lack of a way to get rid of no-longer-referenced pg_security rows. We had been led to understand that there wouldn't be all that many distinct labels in use, but this seems to imply that there are going to be $bignum of them. That changes pg_security leakage from a can-live-with-for-first-cut issue to a must-fix-to-be-credible issue. I see. SELinux handles this by dynamically filling a sidtab (context to security identifier table) at runtime. This can be done because the contexts are stored as strings in the xattr's. I understand KaiGai wanted to save space in the tables so he stored sids, which would require a persistent sid mapping. I'm not sure this is a deal breaker though, I still know people that would rather have it now that may have performance issues than wait for something that can prune the sid mappings. (Just for context, thousands of partitions isn't practical with our current implementation, but might be in the future.) There are still other unresolved issues with partitions that I pointed out upthread. Nonetheless, this conversation seems moot now that Tom has walled off and won't even discuss row-level access controls. You realize, I trust, that I don't have the only vote around here. But I am convinced that the row-level-security aspect of this proposal is far less than fully baked, and isn't going to become so in the time frame available for 8.4. I know, but I also know how opensource communities work :) I haven't seen any enthusiastic support from other commiters which means, at least for the time being, it's being tabled. I mean no disrespect, I also agree with your assessment about the maintenance burden. As an opensource developer myself I would be nervous about intrusive patches that I don't understand, and what that means for me when I write new patches. This brings up my next point. The purpose of pgace is to mitigate this issue. The core team only needs to know when/where/why data can be selected, updated, deleted, etc and maintain the pgace hooks. As long as your side of the boundary stays correct the security model shouldn't break. Granted if you add new things (a new loadable module system, new kinds of large objects, etc) those would need to have the hooks added from the get go. This is similar to how the Linux kernel works, and the Xorg's XACE works. We do watch for updates and sometimes people mess things up but it isn't hard to spot. Especially with a small core team like postgres I'd think you guys could successfully spot places access controls need to be added. -- 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] How to get SE-PostgreSQL acceptable
Robert Haas wrote: On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us wrote: Then you can write something which goes through and sets all the rows to false and then visits every row of every table in the database and forces OID lookups on the security ID of each. When you get done, any rows that still say false are unreferenced and can be killed. Also... even if there are thousands of contexts, it only matters to the extent that there is a lot of churn, and I'm not sure whether that's something that is expected. Josh Brindle, any thoughts? I wouldn't expect a whole lot of churn. Maybe when a project is archived you'd grab everything with a particular security context, save it off and remove it from the table. Constant relabels or removals based on context don't seem too likely though. -- 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] 8.4 release planning
Tom Lane wrote: Joshua Brindle met...@manicmethod.com writes: http://marc.info/?l=selinuxm=115762285013528w=2 Is the original discussion thread for the security model used in the sepostgresql work. Hopefully you'll see some of the evidence you speak of there. Thanks for the link. I took a look through that thread and saw a lot of discussion about issues like how to relate the database-side and client-side permissions, which is all good stuff but mostly outside my purview as a database geek. I didn't find anything about the stuff that is really bothering me, which I think can be broken down into two main categories: 1. Silently filtering out rows according to an arbitrary security policy can break a bunch of fundamental SQL semantics, the most obvious being foreign key constraints --- an application might be able to see a This is correct. Strange error conditions can happen when you are using mandatory access controls. The same thing happened in linux when selinux was introduced. There was plenty of code out there that assumed if it was running as root it could do anything. Lots of it didn't even check for error conditions. The existence of poorly written applications should never be an argument against adding security. dependent row that apparently has no referenced row, or might get an update or delete failure for a row that is unreferenced as far as it can see. Things get worse if an application can insert, update or delete rows that it can't select. The only answer I've been able to get about Because type enforcement (the primary mechanism behind selinux) is very flexible it is true that policy writers have plenty of rope to hang themselves with. We can only attempt to educate and document these issues, blocking out security is not a satisfactory answer. what SEPostgres will do about that is we really don't care that we're breaking SQL semantics. I don't find that to be a satisfactory answer. Plenty of people feel the same way about SELinux (or any mandatory access controls). That is why there are options, if you want this security and don't care if your applications puke then enable it, else disable it. Noone is going to force you to use this, right? The security-geek reason why not is that it represents a huge information leak. The database-geek reason why not is that this will The great thing about security is that, by itself, it actually doesn't mean anything. Security is where you are willing to balance between stopping people from getting something done and letting them get something done. In this case, removing all covert channels would not only be impossible but it would make an unusable database system. In SELinux we didn't worry about covert flows, (actually we ignored/documented plenty of overt flows as well). With something as complex as the Linux kernel or an enterprise rdbms it is nearly impossible to eliminate such things. People who need absolute separation of information already have options, multiple server processes, polyinstanciated views, etc. For people that don't care if someone can see that you've inserted a couple rows since the primary key got larger, or can tell that an associated row that isn't visible exists in another table a more flexible, yet still mandatory system like sepostgresql is the answer. The great thing about this work is that, in many cases, a well designed system (that is, well designed for the security policy it is going to be constrained under) should not be impacted greatly by these issues. If a client needs information where they can't see all of the associated rows you can have trusted stored procedures (which run in a different selinux context, as defined by a type transition from the client context) that do the work and return the appropriate results. I know you can't use stored procedures for everything but they'd go a long way in binding queries we trust to the data they expose (just like in SELinux we bind binary code on the filesystem to domains that code can be used to enter) permanently destroy our ability to do a lot of important optimizations, eg join removal on the basis of foreign key constraints. (There are probably other good reasons, but that one will do for starters.) Perhaps this is fixable by constraining what a security policy is allowed to do, or in some other way that I don't know about, but I've seen no serious discussion about that. 2. I don't understand where to draw the dividing line between database system accesses (which can't be security constrained, at least not without breaking things entirely --- eg it will do you little good to imagine that you can hide rows in pg_security from the security-enforcement code ;-)) and user accesses that should be security-constrained. I am certain that the line is muddied beyond usability in the current system; there are a lot of user-exposed functions that are making use of the same infrastructure that core system
Re: [HACKERS] 8.4 release planning
Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: SEPostgres seems qualitatively different to me, though. I think PG people have avoided reviewing it because (a) they weren't interested in it and (b) they knew they were unqualified to review it. Meanwhile it's emerging that the selinux people don't feel qualified to review it either. I'm not quite sure what to do about that. But throw it in there on faith doesn't sound like an appealing answer, and I've got no idea how long it will take to work out a non-faith-based answer. Erm, I have to say here that this strikes me as rather unfair. Perhaps I'm wrong, but I suspect KaiGai feels pretty good about the patch and his qualifications in both the PG realm and the SELinux realm. He's Not only that but he's had many discussions with us about sepostgres, from the security model to his reimplementation of the access vector cache. Just because we haven't been on this list doesn't mean we haven't been watching the work. asking the PG folks to review it because that's the process that the PG community (through the CommitFest, etc) has laid out for getting a patch included upstream. I'm confident KaiGai isn't going to just disappear into the ether if the patch is committed. He hasn't disappeared yet, that is probably a good sign :) Sure, it'd be nice if 4 or 5 other SELinux developers got in and understood the PG code well enough to implement such a patch, but I We aren't a huge community and because of the nature of SELinux we have people spread out over many different projects (X, dbus, NFS, distributions, ipsec/networking, solaris fmac), etc. I'm probably more familiar with databases than the others so I'm here to help (though my time is also spread over many other things). think the combination of KaiGai (overall), a seperate SELinux hacker (for the security design and SELinux side of it), and a PG committer (for where the hooks are placed and how), reviewing the patch and being comfortable with it is quite sufficient for a high quality result. That is all I asked for. No matter how familiar I become with the pgsql code I'll never be as qualified as you guys for identifying security hook call sites that are missing/misplaced. Assuming I think the security backend is correct then it shouldn't be hard for you guys to look at the docs, see that permissions x, y and z are required for operation foo, and know where the possible codepaths for operation foo are and check that the hooks for x, y and z are called. -- 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] 8.4 release planning
Josh Berkus wrote: Stephen Frost wrote: * Gregory Stark (st...@enterprisedb.com) wrote: It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). The idea is for the level of informations security we're talking about, someone with limited permissions not only isn't allowed to know certain data, they're not allowed to know certain data *exists*. Within the SELinux framework, this is accomplished by hiding files you don't have permission to see, not merely denying access to them. SELinux does not (and can not) hide the existence of files, as file names are part of the directory data and not part of the file data. We can restrict read on the directory so you can't see any of the file names but this is not a complete solution as anyone with search/create perms on the directory can enumerate the file name namespace to discover existence of files. We do not consider that a short coming, anyone who needs to hide existence of files needs to set up their directory structure to disallow read/search/create on the directories they aren't allowed to discover filenames in. Polyinstanciation can also address this issue. The presumption is that if you know the data exists but can't access it directly, you'll use indirect methods to derive what it is. But if you don't even know it exists, then you won't look for it. There are ways to mitigate this in the current security model of sepostgres, namely using trusted stored procedures to fetch data you are unwilling to let someone query against directly (or indirectly). Just as with SELinux anyone who needs this kind of capability would have to correctly design their tables and stored procedures to address their security goals. There's a level above that which I don't think SEPostgres implements, which is data substitution, in which you see different data according to what security level you are. While this may seem insane for a business application, for military-support applications it makes some sense. Trusted stored procedures can handle the above requirement, either by fuzzing data (consider coordinates x,y are in a table but below top secret you can't have access to the exact coordinates, the trusted stored procedure can fetch and fuzz them sufficiently before delivering them to the client). -- 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] 8.4 release planning
Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: Stephen Frost wrote: It does seem weird to simply omit records rather than throw an error The presumption is that if you know the data exists but can't access it directly, you'll use indirect methods to derive what it is. But if you don't even know it exists, then you won't look for it. Right, which is why it's bad for something like a foreign key constraint to expose the fact that the row does exist after all. Once again, this is not an issue for us. We would much rather have a database that allows you to hide data from unauthorized clients using a mandatory policy than one that does nothing because you couldn't close some covert channels. I'll repeat what I said in an earlier email, SELinux doesn't (and can't) address all covert channels in Linux, and that is fine as long as it is understood and documented (which is part of the evaluation process). There's a level above that which I don't think SEPostgres implements, which is data substitution, in which you see different data according to what security level you are. While this may seem insane for a business application, for military-support applications it makes some sense. I think it might be possible to build such a thing using views, but I agree that the patch doesn't give it to you for free. -- 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] 8.4 release planning
Josh Berkus wrote: Josh, We do not consider that a short coming, anyone who needs to hide existence of files needs to set up their directory structure to disallow read/search/create on the directories they aren't allowed to discover filenames in. Polyinstanciation can also address this issue. Hmmm. Why try to hide individual rows in tables then? That would seem not in keeping with the filesystem policies. Because rows have data in them. It is analogous to not allowing the contents of the file to be visible. However, the primary key is still known to exist through various means, which is more analogous to the filename. -- 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] 8.4 release planning
Tom Lane wrote: Joshua Brindle met...@manicmethod.com writes: Tom Lane wrote: Right, which is why it's bad for something like a foreign key constraint to expose the fact that the row does exist after all. Once again, this is not an issue for us. Yes it is an issue; claiming it isn't doesn't make it so. You just stated, in effect, that you don't implement data hiding in the filesystem because it would break standard Unix filesystem semantics. We break plenty of standard semantics. Applications generally expect to be able to unlink files they can write to, to truncate or append. They expect read()/write() calls to succeed after a successful open(). SELinux is more fine grained than POSIX/UNIX is so some of these fundamental assumptions got broken. In the end this created better/safer software, after some growing pains of course. How is that consistent with your opinion that it's okay to break standard SQL semantics in order to implement data hiding in a database? Please step me through how the SQL semantics are being broken. From my perspective (I've used databases, written applications for them, etc but never hacked on a database server directly) this seems pretty straightforward. There already exists the possibility that you won't be able to read/write one or more of the tables for which a foreign key constraint exists, how do you handle it now? Why isn't it appropriate to handle it the same way? The question of whether there is a covert channel is only a small part of my complaint here. If it's the judgement of security experts that that's an acceptable thing, that's fine, it's their turf. But SQL behavior is my turf, and I'm not happy with discarding fundamental semantic properties. Quoting from your other message: We do not consider that a short coming, anyone who needs to hide existence of files needs to set up their directory structure to disallow read/search/create on the directories they aren't allowed to discover filenames in. This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. It isn't parallel though, in applications using the filesystem specifying directories where files go is fairly common. In database applications you expect all the data to be in the same table, having multiple tables with the same schema to try and separate out data that should be visible to some and not others isn't acceptable to most people and certainly wouldn't be compatible with many existing applications. Further, we have the ability to use per-process namespaces/polyinstantiation on the filesystem. From what I've heard that is somewhere you are unwilling to go as a community for postgresql so the options are somewhat more limited. I'm not trying to pretend that SELinux and sepostgresql are the same thing and always have to be treated the same. The trusted X work uses the same infrastructure and security policy language as sepostgres and selinux itself but noone is comparing windows and pointers to tables and rows. Type enforcement is a flexible system. You identify the objects that are important to you in the object manager (postgresql in this case) and assign types to it and write policies around those types. The SELinux community came to a consensus quite a while back about what objects were important to us. I had assumed (perhaps foolishly) that this had been communicated and also agreed upon in the postgresql community. If that wasn't the case I hope we can sit down and talk about the model to determine what objects are important to everyone and talk about the implementation details afterward. -- 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] 8.4 release planning
Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. While also ignoring a feature that is available, and used by these same security communities, in other enterprise RDBMSs... http://www.securityfocus.com/infocus/1743 http://www.microsoft.com/technet/prodtechnol/sql/2005/multisec.mspx It's not codified in the SQL spec (yet..) that I saw, and maybe we could seperate out the SE bits from the row-level bits, but I'm really not sure I see the value in doing that.. They are separate. If you look at the patches you'll see a pgace part, this is where the core interfaces to the security backends, and you'll see a rowacl backend and an sepgsql backend. Personally I'd like to see all of the access control moved out to use pgace, including the standard DAC permissions but I doubt that would never happen. -- 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] 8.4 release planning
Ron Mayer wrote: Stephen Frost wrote: * Gregory Stark (st...@enterprisedb.com) wrote: It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). It is weird from an SQL perspective, I agree with you there. On the other hand, it's what the security community is looking for, and is what's implemented by other databases (Oracle, SQL Server...) that do row-level security and security labels. Requiring a where clause or you throw an error would certainly make porting applications that depend on that mechanism somewhat difficult, and doesn't really seem like it'd gain you all that much... It seems to me that there are two different standards to which this feature might be held. Is the goal a) SEPostgres can provide useful rules to add security to some specific applications so long as you're careful to avoid crafting policies that produce bizarre behaviors (like avoiding restricing access to foreign key data you might need). On the other hand it gives you enough rope to hang yourself and produce weird results that don't make sense from a SQL standard point of view if you aren't careful matching the SEPostgres rules with your apps. This is what we like to call a flexible mandatory access control system, such as type enforcement. Give everything a type, write rules around the types. If you mess up your system may not boot (or your database queries might be strange). In talking to KaiGai the rules should not allow you to create inconsistencies, however. If you delete a row with a foreign key constraint and you cannot delete the associated row in another table the whole operation should fail. We want to fail on the side of maintaining data integrity and consistency while still allowing you enough rope to have a fine grained, flexible access control system. or b) SEPostgreSQL should only give enough rope that you can not craft rules that produce unexpected behavior from a SQL point of view; and that it would be bad if one can produce SEPostgres policies that produce unexpected SQL behavior. SELinux (and associated security aware applications) tend to go the way of very fine grained and let the policy author decide how to use it. I've seen SELinux policies with as few as 3 types, to as many as 3000. It is up to the policy author to choose the granularity appropriate for their purpose. I'd hate to see arbitrary limits put on the policy because of applications that might now operate correctly if they get an unexpected error (the applications should be fixed, not the security policy crippled) It seems to me many of the security-enhanced products seem to do the former; while it seems some of the objections to this patch are more of the latter. Historically trusted systems were fairly course grained, with only Bell and LaPadula policies[1]. SELinux is probably the first fine grained mandatory access control system in the mainstream. 1 http://en.wikipedia.org/wiki/Bell-LaPadula_model -- 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] 8.4 release planning
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace part,
this is where the core interfaces to the security backends, and you'll
see a rowacl backend and an sepgsql backend.
Right, guess it wasn't clear to me that the PGACE bits for row-level
access control could be used independently of SELinux (and maybe even on
systems that don't have SELinux..?).
Sure, if you look at pgaceHooks.c you'll see:
bool
pgaceExecScan(Scan *scan, Relation rel, TupleTableSlot *slot)
{
/* Hardwired DAC checks */
if (!rowaclExecScan(scan, rel, slot))
return false;
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
return sepgsqlExecScan(scan, rel, slot);
break;
#endif
default:
break;
}
return true;
}
Notice the rowacl call outside of the HAVE_SELINUX ifdefs
--
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] 8.4 release planning
Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote: Josh Berkus wrote: Hmmm. Why try to hide individual rows in tables then? That would seem not in keeping with the filesystem policies. Because rows have data in them. It is analogous to not allowing the contents of the file to be visible. However, the primary key is still known to exist through various means, which is more analogous to the filename. Since most keys are likely to be non-meaningful IDs, its not going to help you much. Even more to the point: if the expectation is that you can hide a row's data payload but not its primary key, you can accomplish that with column-level permissions, without having to get into any non-standard or even faintly surprising SQL behavior, We aren't saying we want to hide the payload of the data in an entire column, just the data in some of the rows. For example, if you have top secret and secret data in the same table a secret user would be able to see the entire row for secret rows but maybe only some of the data on the top secret rows (or maybe not see the rows at all). Further, the top secret rows may have some fields that are inaccessible but are accessible through a trusted stored procedure that does fuzzing on the data (back to the coordinates example I used earlier) -- 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] 8.4 release planning
Tom Lane wrote:
Ron Mayer rm...@cheapcomplexdevices.com writes:
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
policies that produce bizarre behaviors (like avoiding restricing
access to foreign key data you might need). On the other hand it
gives you enough rope to hang yourself and produce weird results
that don't make sense from a SQL standard point of view if you
aren't careful matching the SEPostgres rules with your apps.
or
b) SEPostgreSQL should only give enough rope that you can not
craft rules that produce unexpected behavior from a SQL point
of view; and that it would be bad if one can produce SEPostgres
policies that produce unexpected SQL behavior.
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres. Right at the moment it seems
that the potential performance hit, for users who are *not using*
SEPostgres but merely have to use a build in which it is present,
might be bad enough to guarantee that that will never happen.
According to the comments in security/sepgsql/core.c:
/*
* sepgsqlIsEnabled
*
* This function returns the state of SE-PostgreSQL when PGACE hooks
* are invoked, to prevent to call sepgsql() functions when
* SE-PostgreSQL is disabled.
*
* We can config the state of SE-PostgreSQL in $PGDATA/postgresql.conf.
* The GUC option sepostgresql can have the following four parameter.
*
* - default: It always follows the in-kernel SELinux state. When it
*works in Enforcing mode, SE-PostgreSQL also works in
*Enforcing mode. Changes of in-kernel state are delivered
*to userspace SE-PostgreSQL soon, and SELinux state
*monitoring process updates it rapidly.
* - enforcing : It always works in Enforcing mode. In-kernel SELinux
*has to be enabled.
* - permissive : It always works in Permissive mode. In-kernel SELinux
*has to be enabled.
* - disabled : It disables SE-PostgreSQL feature. It works as if
*original PostgreSQL
*/
and in the hooks there is a pgace_feature that turns off the checks:
void
pgaceGramAlterRelation(Relation rel, HeapTuple tuple, DefElem *defel)
{
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
{
sepgsqlGramAlterRelation(rel, tuple, defel);
return;
}
break;
#endif
default:
break;
}
if (defel)
ereport(ERROR,
(errcode(ERRCODE_PGACE_ERROR),
errmsg(unable to set security attribute of
table
via ALTER TABLE)));
}
So the pgace_feature turns off the backend call, there is an extra function
call, and a branch but that shouldn't cause the kind of performance degradation
you are talking about.
--
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] 8.4 release planning
Tom Lane wrote: Stephen Frost sfr...@snowman.net writes: Personally, I think it'd be terrible to implement the suggestion that started this sub-thread since it breaks with what is currently done elsewhere and what the users of this feature would expect. Upthread we were being told that this patch breaks new ground and will offer capability available nowhere else. Now I'm hearing that it's just a me too patch to catch up with capability already available from N commercial vendors. Which is it? It is like the difference between Trusted Solaris (really all the old trusted OS's) and SELinux. They both implement mandatory access control and both implement Bell and LaPadula as needed by the government/military but SELinux, via type enforcement, goes further to provide a completely flexible mandatory access control system. SELinux is useful to meet all sorts of security goals, from system and application integrity to data pipelining and confidentiality. The SELinux community believes this sort of access control is important to not only the military but commercial and even small scale systems. Further, because sepostgresql integrates well with SELinux the same system wide access controls flow seamlessly into the database. Are you able to access secret data on the filesystem? If so you'll be able to access secret data in the database. Are you able to update accounting information in the filesystem? Then you'll be able to update accounting information in the database. This also integrates with KaiGai's other work to SELinux-ize apache so that an apache server can run a user script from a users home directory and a type transition occurs to run the script in the appropriate domain for that user, then when that script accesses the database they'll have only the access that users script should have. This kind of end-to-end integration with mandatory access control is certainly ground breaking and isn't just the same ol' same ol' that other database vendors are doing (and have been doing for quite some time). -- 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] 8.4 release planning
Devrim GÜNDÜZ wrote: On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote: With my other hat on (the red one) what I'm concerned about is whether this patch will ever produce a feature that I could turn on in the standard Red Hat/Fedora build of Postgres. FWIW, as you know, sepostgresql is already included in Fedora. You can continue shipping it as a seperate RPM set. That is non-ideal. Getting the capability in to the standard database shipped with RHEL is very important to me and my customers. Since you can turn this off with GUC I don't see why it makes sense to ship 2 databases (nevermind the maintenance issues) -- 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] 8.4 release planning
Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: So, some feedback to make this decision more difficult: Users: care about HS more than anything else in the world. I don't think this is correct. There are certainly a lot of users who would like an in-core replication solution, but HS by itself is not that --- you also need (near) real-time log shipping, which we have already decided to punt to 8.5. That being the case, I think the argument that HS is a must-have feature for 8.4 is actually rather weak. SE-Linux: this patch has effectively been in development for 2 years ourside the core process before putting it in; the forked SEPostgres is in use in production. KaiGai has been available for 20 hours a week (or more) to troubleshoot issues and change APIs. I really don't see what the problem is with committing it. The problem, in words of one syllable, is that we are not sure we want it. Do you see a user community clamoring for SEPostgres, or a hacker community that is willing or able to maintain it? If KaiGai-san got run over by a bus tomorrow, this patch would be a dead letter, because there just isn't anyone else who is taking sufficient (any?) interest in it. That doesn't bode well for its future viability. Compare the likely audience for it to previous patches of roughly similar complexity, such as integrated text search or the Windows port, and it's just not in the ballpark. The second problem is that we're not sure it's really the right thing, because we have no one who is competent to review the design from a security standpoint. But unless we get past the first problem the second one is moot. I've never posted to this list before, but I am an SELinux upstream maintainer. I'd just like to interject here, we (the SELinux community) are very interested in KaiGai's work and have been looking forward to it being upstreamed for quite some time. While we haven't been able to analyze the patches directly to determine whether the security goals are indeed being met we have had much discussion and eventually community agreement on the security model being implemented. This happened years ago and has since been merged into the SELinux reference policy that practically all SELinux users use (distributions start with the reference policy and add rules/modules suitable for them). So the security model has been looked at, though not the implementation and we do have a community of developers, users and customers interested in this work. Joshua Brindle -- 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] 8SEPostgres WAS: .4 release planning
Josh Berkus wrote: Joshua, So the security model has been looked at, though not the implementation and we do have a community of developers, users and customers interested in this work. Can you please take a look at it ASAP, then? In the next week, we will probably decide on whether or not to defer SEPostgres until 8.5. The fact that we haven't gotten a sign-off from any security expert anywhere is leaning the whole community towards defer. Yes, I will look at them to the extent I am able. As I am not familiar with the postgresql codebase I won't be able to assert the correctness of the hook placement (that is, where the security functions are called with respect to the data they are protecting being accessed). The postgresql community should be more familiar with the hook call sites and hopefully can assist there. I should be able to handle the security backend and determining whether it matches the security model we agreed on, but the hook placement is just as important since a misplaced or missing hook will allow access that should not be granted. Joshua Brindle -- 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] 8.4 release planning
Tom Lane wrote: Ron Mayer rm...@cheapcomplexdevices.com writes: Tom Lane wrote: The second problem is that we're not sure it's really the right thing, because we have no one who is competent to review the design from a security standpoint. Are we underestimating Kaigai Kohei? Perhaps he walks on water, but still I'd like to have more than one person who has confidence that this design and implementation are correct. and it seems his patches there related to postgresql were pretty widely discussed on the SELinux lists: http://www.nsa.gov/research/selinux/list-archive/0805/index.shtml#26163 Well, a quick look through that thread shows a lot of discussion of the selinux policy code that's in the patch, which is good as far as it goes because for sure there's no one in *this* list who understands a line of that stuff. But to be blunt there's no evidence there that anyone in that discussion has heard of a foreign key, much less understands why it might be an issue for this patch. I see a lot of reasoning by analogy to X servers, and little if any database-specific knowledge. http://marc.info/?l=selinuxm=115762285013528w=2 Is the original discussion thread for the security model used in the sepostgresql work. Hopefully you'll see some of the evidence you speak of there. For some additional resources there is a good chapter on database security (specifically multilevel databases) in Pfleeger's Security in Computing: http://www.amazon.com/Security-Computing-Second-Charles-Pfleeger/dp/0133374866/ref=si3_rdr_bb_product Mind you, I'd like nothing better than to have some NSA database security experts (I'm sure there are some) show up here and tell us that this design is good, secure, and useful --- and why. But right now we have no evidence for that proposition. And we really need to understand *why* it's a useful design and what the critical security issues are, because otherwise we are 100% certain to break it in future maintenance (even granting the improbable supposition that there are no bugs in the patch today). This capability puts PostgreSQL in a unique position. Not only is the security model more fine grained than any previous trusted database but it also allows interesting things like trusted stored procedures that can access data (and do any necessary fuzzing, modifying or filtering) that the client himself cannot read. It also integrates well with the labeled networking supplied by SELinux, as outlined on KaiGai's wiki page. There can be multiple clients running on one machine (such as a web server) that have different levels of database access, in a more fine grained and flexible way than using different database credentials allows. I'm happy to discuss this at length if it will help the patches get upstreamed. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
