Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
On Monday 20 July 2009 17:52:44 Joshua Brindle wrote: That is your (and the communities) prerogative. Linus wasn't very supportive of SELinux in the kernel either but it is the only way Linux got an EAL4+ LSPP evaluation for use in certain government systems. I personally would love to see an open source DBMS evaluated for systems like this because the current state of the art is fairly sad. This would actually be a reasonable baseline to work against, if we define a project goal to be satisfying this standard. This is presumably the web site that describes this standard: http://www.niap- ccevs.org/cc-scheme/pp/pp_os_ls_v1.b/ There I see Succeeded By: pp_os_ml_mr2.0_v1.91 Sunset Date: 16 September 2007 And the successor document is vastly more comprehensive than implementing a MAC scheme. So how do we realistically get from here to there (and where is there)? -- 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 17:52:44 Joshua Brindle wrote: That is your (and the communities) prerogative. Linus wasn't very supportive of SELinux in the kernel either but it is the only way Linux got an EAL4+ LSPP evaluation for use in certain government systems. I personally would love to see an open source DBMS evaluated for systems like this because the current state of the art is fairly sad. This would actually be a reasonable baseline to work against, if we define a project goal to be satisfying this standard. This is presumably the web site that describes this standard: http://www.niap- ccevs.org/cc-scheme/pp/pp_os_ls_v1.b/ There I see Succeeded By: pp_os_ml_mr2.0_v1.91 Sunset Date: 16 September 2007 And the successor document is vastly more comprehensive than implementing a MAC scheme. The target of this protection profile is operating system, so it is a bit mismatch. Referring to the prior case, Oracle Label Security (it also provides label based access controls, but no collaboration with OS) is cerfified with the BR-DBMSPP (U.S.Government Protection Profile Database Management Systems For Basic Robustness Environments) and additional functional components (such as FDP_IFC.1: Subset Information Flow Control, FDP_IFF.2: Hierarchical Security Attributes, and so on). http://www.commoncriteriaportal.org/products_DB.html#DB * ST for Oracle Label Security for Oracle Database 10g Release 2 http://www.commoncriteriaportal.org/files/epfiles/20080306_0402b.pdf So how do we realistically get from here to there (and where is there)? Security functionality is a factor to get ISO/IEC15408 certification, but not all. (For example, who can defray the cost for evaluation?) However, it is important to pull up the baseline functionality to satisfy these security functional components. If certification is only valid on the patched version, rest of people will not be happy. -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- 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
Robert Haas wrote:
2009/7/20 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
- row-level security
- complex DDL permissions
Is the complex DDL permissions mean something like db_xxx:{create},
db_xxx:{relabelfrom relabelto} and others?
If so, I can agree to implement these checks at the later patch.
However, please note that the initial patch cannot achieve actual
security in this case, because it means anyone can change security
label of objects.
I'm not qualified to answer this question, and that's exactly why we
need more documentation of what this patch tries to do and why (i.e. a
spec).
Agreed,
What I was specifically referring to is things like
db_column:{drop}, which are much more specific than anything
PostgreSQL currently offers to control DDL. I think we should make an
attempt to get objects labelled in a reasonable way (I did not like
the approach your latest patch took of just assigning everything a
default label), which might include relabelling also, but certainly
doesn't include things like distinguishing between different kinds of
DDL operations. I'm not really up on SELinux terminology (this is
another thing that needs to be covered in the documentation, and
isn't) but maybe something like db_table:{owner}.
It also should be described in the documentation again...
The current design reflects a fundamental principle in SELinux.
It requires how objects are labeled and what permission should
be checked on the creation/deletion time.
It seems to me you misunderstand the default security context is
uniform for all the clients, but it's incorrect.
The default security context depends on client's security context
and parent object's security context (if exists).
For example, when a user with classified security context creates
a table under the regular schema, the new table will be also labeled
as classified to prevent accesses from unclassified users.
All the object classes that we can create or delete (such as files,
sockets, ipc objects, x-windows, ...) have their permissions to be
checked on creation or deletion time. These permissions are defined
on the relationship between user's security context and object's
security context. If only database objects ignore the design, it
breaks consistency in the security policy.
Again, the fact I needed to introduce such a fundamental design in
SELinux shows the current documents are poor for native English
users and database experts but not for security.
I also agree with Peter's contention that a spec would be useful. If
you could read a clear description of what the patch was going to do,
then you could separate the problem of figuring out whether that was
the right thing from the question of whether the patch actually did
it.
I can also agree with the suggestion.
The specifications (from viewpoint of the developer) will introduces
the fundamental principles to be implemented, and it will figure out
what implementation is better.
As I noted before, I've been flexible about how SE-PgSQL is implemented
as far as it can perform SELinux's security model correctly.
Please for a several days. I'll describe it.
I really, really think you need to find someone to help you with the
documentation. As I've said before, your English is a lot better than
my Japanese, but the current documentation is just hard to read. More
than that, writing good documentation is HARD, and there are not a ton
of people who can do it well. It seems to me that the documentation
for this project could require as much work as the actual code.
Agreed,
If possible, I would like to know what is the easy-understandable
documentation from the viewpoint of non-security-experts also.
What I want for documentation of this feature is something like the
Database Roles and Privileges chapter of the current documentation.
You can read this chapter from beginning to end and have a pretty good
idea how to manage permissions in PostgreSQL. SE-Linux is complex
enough that you might have to refer to other sources of information
for certain topics (e.g. policy writing), because a full overview of
those topics might exceed the scope of our documentation. But it
should still be possible to start knowing nothing, read the chapter,
and have a pretty good idea how all the pieces fit together, at least
as far as PostgreSQL is concerned.
Indeed, I've learned before it is a good composition of documentations
to compare similar two different features (one is well-known, the other
is new) to introduce a new concept.
Here is one idea. I'll upload the draft of the documentation on the
wikipage shorter than the current one.
Is somebody available to check it from the viewpoint of native English
user or database users?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
KaiGai Kohei asked: ... Here is one idea. I'll upload the draft of the documentation on the wikipage shorter than the current one. Is somebody available to check it from the viewpoint of native English user or database users? I'll give a shot ... native english speaker, some experience with documentation, and I'm fond of postgres, but not really deserving of being on this alias (not a hacker in the useful sense of the word). Greg Williamson -- 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 Williamson wrote: KaiGai Kohei asked: ... Here is one idea. I'll upload the draft of the documentation on the wikipage shorter than the current one. Is somebody available to check it from the viewpoint of native English user or database users? I'll give a shot ... native english speaker, some experience with documentation, and I'm fond of postgres, but not really deserving of being on this alias (not a hacker in the useful sense of the word). Greg Williamson Thanks for your help. I'm now under writing the initial draft, seeing the Database Roles and Privileges chapter. Please wait for a few days. -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- 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
On Tue, Jul 21, 2009 at 5:51 AM, Robert Haasrobertmh...@gmail.com wrote: I really, really think you need to find someone to help you with the documentation. As I've said before, your English is a lot better than my Japanese, but the current documentation is just hard to read. In general we're very generous with English writing quality. I wouldn't worry too much about the language barrier as far as writing documentation. However the snippets Robert posted of the documentation had a more fundamental problem unrelated to language. The problem is that it explained what an option did in terms of what that option did -- ie, the documentation only made sense if you already knew what it was trying to say. That's not an unusual trap to get into when writing documentation regardless of what language you're writing in. -- greg http://mit.edu/~gsstark/resume.pdf -- 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
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? -- greg http://mit.edu/~gsstark/resume.pdf -- 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
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. -- greg http://mit.edu/~gsstark/resume.pdf -- 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. It is the most significant feature of SE-PostgreSQL to enforce the centralized security policy, as if SELinux enforces its policy to the accesses on objects manged by operating system. Indeed, SELinux can control accesses on user's data stored within filesystems (operating system feature) based on its security policy. However, nowadays, filesystem is not only piece to store user's data with variable credentials (ie; secret, unclassified, ...). Needless to say, database is a significant pieces to store variable user's data, but it is not invisible from the operating system how does it controled, because all the database objects are managed in userspace. It means SELinux cannot control data flows via databases, although it occupies an important place in our information system. Granularity in access controls is an independent issue. Integration of the access control policy is an issue how to decide whether the required accesses to be allowed, or not. On the other hand, table/column/row level access control is an issue what objects to be controled. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- 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
Greg Stark wrote: On Tue, Jul 21, 2009 at 5:51 AM, Robert Haasrobertmh...@gmail.com wrote: I really, really think you need to find someone to help you with the documentation. As I've said before, your English is a lot better than my Japanese, but the current documentation is just hard to read. In general we're very generous with English writing quality. I wouldn't worry too much about the language barrier as far as writing documentation. However the snippets Robert posted of the documentation had a more fundamental problem unrelated to language. The problem is that it explained what an option did in terms of what that option did -- ie, the documentation only made sense if you already knew what it was trying to say. That's not an unusual trap to get into when writing documentation regardless of what language you're writing in. Indeed, language quality is a causality, but not all. The matter is we've not been able to share what does it try to achieve correctly, what is identicals or differences between database privileges and SELinux's security model, and so on. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- 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
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
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. 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. Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
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
Martijn van Oosterhout klep...@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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [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
Joshua Brindle escribió: The unfortunate part is that many of the people that would use it are unable to publicly say so. So they will be similarly unable to help with it. Such a black hole is not of much use, is it? Or are they getting a contract with some PG support company to which they'll shell out the bucks under NDA to ensure that the thing is delivered and maintained? I think that if this looked less like a one-man project it could have better support around here. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
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. 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. -- 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
Joshua Brindle wrote: How many people are you looking for? Is there a number or are you waiting for a good feeling? Is it individuals or organizations people are looking for? I see KaiGai wrote In addition, I (and NEC) can provide our capability to the PostgreSQL community to keep these security features work correctly. Does that imply that a larger part of NEC is interested? The unfortunate part is that many of the people that would use it are unable to publicly say so. Could they publicly say something softer. I see SELinux had a number of large organizations (NSA) and publicly traded companies (Secure Computing Corp, Network Associates, etc) pushing it and contributing to it. If people who could speak for those organizations were here saying ooh, and such features in a F/OSS database would be interesting too, that would probably convince a lot of people. 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. -- 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] [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. 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. At least, what is important is that SE-PgSQL performs with its security model correctly, not how it is implemented. In fast, I have modified its implementation and separated some of non-primary features several times. As I said before, its implementation is flexible as far as it can implement SELinux's security model correctly. If PostgreSQL community requires its design specifications from the viewpoints of developers, I don't have any reason not to provide it. One question is what items should be described in the specifications? I already provide a reference including a list of object classes and permissions. http://wiki.postgresql.org/wiki/SEPostgreSQL_References I guess you would like to see when/where/how SE-PgSQL checks what permissions, what criteria to make its decision should be used, and so on. -- KaiGai Kohei kai...@kaigai.gr.jp -- 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
Joshua Brindle wrote: Peter Eisentraut wrote: 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. Then document those in a reasonably formal sense. I don't think you can just say that the implementation is the spec. I should have thought that such a spec would actually appeal to the security community. 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. Yeah, it is a bit. But we're being asked to swallow a fairly large lump, so don't be surprised if we gag a bit. I haven't followed the entire history of this patch set closely, but we have over and over again emphasized the importance of getting community buyin before you start coding a large feature, and this is a *very* large feature. Reviewing the history briefly, it appears that KaiGai prepared an initial set of patches before ever approaching the Postgres community with it about 2 years ago. That is to some extent the source of the friction, I suspect. I'm also slightly surprised that some of the government and commercial players in this space aren't speaking up much. I should have thought this would generate some interest from players as disparate as RedHat and the NSA. cheers andrew -- 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
On Mon, Jul 20, 2009 at 3:44 PM, Joshua Brindlemet...@manicmethod.com wrote: 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). This is very interesting, if by interested you mean that you are willing to commit time, money, and development resources to make it happen. If by interested you mean that you will use it if someone else does the work of implementing it, that's nice, but fundamentally doesn't help us very much. At least in my view, the problem with this patch set is that it's not committable, and it's not measurably closer to being committable than it was a year ago. I am not saying (and I don't necessarily think ANYONE is saying) this is a great patch, but I don't want to commit it because I hate SE-Linux. What I at least am saying is that this patch has serious problems that need to be fixed in order for it to be committed, and because KaiGai has not been able to fix those problems after over a year of back and forth, a new approach is needed here or we are dead in the water. I have attempted, on the relevant threads, to enumerate those problems as I see them. Mainly they have to do with hooks all over the code in strange and unmaintainable places, documentation that is written in poor English and is not easily understandable by people who are not already experts in SE-Linux, and a complete inability to get a patch that implements a useful subset of the total realm of SE-Linux desiderata that more or less matches up with what the existing PostgreSQL permissions structure already does. What we've established so far is that the following things should NOT be in the list of permissions that we attempt in the initial patch: - row-level security - complex DDL permissions But I think the following things probably should be: - tables - columns - sequences - functions - schemas - databases - tablespaces I'd be willing to negotiate on all but the first. I also agree with Peter's contention that a spec would be useful. If you could read a clear description of what the patch was going to do, then you could separate the problem of figuring out whether that was the right thing from the question of whether the patch actually did it. To restate my basic point: The problem with this patch is that there are plenty of people who are interested in *having* it, but the only person who seems to be interested in *writing* it is KaiGai, and that isn't working. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
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? -- greg http://mit.edu/~gsstark/resume.pdf -- 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? I would like to introduce a key word: data flow control (DFC). Most of mandatory access control system focuses on the direction of data, and tries to control it when user/client gives a request to object manager (such as OS-kernel, RDBMS, ...). MAC system assigns a security label on all the objects managed to identify its sensitivity level. It typically has hierarchical relationship, such as secret is more sensitive than classified, and classified is more than unclassified, for example. secret classified unclassified When user requires the object manager to read a certain object with a security label being equal or lower than user's security label, MAC system within the object manager allows it. In this case, the direction of data is from object to subject. (Object) ---(read)--- (Subject) When user requires the object manager to write a certain object with a security label being equal to user's security label, MAC system allows it. In this case, the direction of data is from subject to object. (Subject) ---(write)--- (Object) This constraint enables to prevent to leak a sensitive data to others with lower sensitive level. Note that subject never has data with higher than himself, and he cannot write his data to objects lower than himself (to prevent information leaks, by malicious internals) and higher than himself (to prevent manipulation). The security certification (ISO/IEC15408) also contains DFC as a part of functional requirements. (Please note that it does not requires DFC all the producets; it depends on the environment to be used.) Oracle Label Security is a product which provides DFC mechanism using row-level access controls based on security labels, and its security certification report mentions its DFC features and access control rules in the FDP_IFF section. SE-PostgreSQL also tries to apply such kind of DFC policies. In addition, its security policy is integrated with operating system. It enables to handle multiple object manager seamlessly. For example, we cannot prevent a user with classified security label to insert a sensitive information into database and unclassified user to see them later, without SE-PgSQL. BTW, Oracle Label Security is priced at about $13,000/CPU in Japan. I believe security sensitive customers feel it fair for their purpose. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- 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
How many people are you looking for? Is there a number or are you waiting for a good feeling? The problem is not the number of people who like the patch, but the number of people who are willing to refactor and maintain it. Right now, if NEC decided to abandon Postgres, or if they decided that they don't like the changes we make in order to merge it, we'd have nobody to maintain it. Given the amount of money which the security community represents, it seems like at least a few of these people could become, or sponsor, code maintainers. I was hoping to support some of this effort through Sun when SEPostgres was introduced, but that didn't happen. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- 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
Robert Haas wrote:
I have attempted, on the relevant threads, to enumerate those problems
as I see them. Mainly they have to do with hooks all over the code in
strange and unmaintainable places, documentation that is written in
poor English and is not easily understandable by people who are not
already experts in SE-Linux, and a complete inability to get a patch
that implements a useful subset of the total realm of SE-Linux
desiderata that more or less matches up with what the existing
PostgreSQL permissions structure already does. What we've established
so far is that the following things should NOT be in the list of
permissions that we attempt in the initial patch:
- row-level security
- complex DDL permissions
Is the complex DDL permissions mean something like db_xxx:{create},
db_xxx:{relabelfrom relabelto} and others?
If so, I can agree to implement these checks at the later patch.
However, please note that the initial patch cannot achieve actual
security in this case, because it means anyone can change security
label of objects.
But I think the following things probably should be:
- tables
- columns
- sequences
- functions
- schemas
- databases
- tablespaces
I also think it is reasonable to apply access controls on the types
of object classes at the initial pach.
I'd be willing to negotiate on all but the first.
I also agree with Peter's contention that a spec would be useful. If
you could read a clear description of what the patch was going to do,
then you could separate the problem of figuring out whether that was
the right thing from the question of whether the patch actually did
it.
I can also agree with the suggestion.
The specifications (from viewpoint of the developer) will introduces
the fundamental principles to be implemented, and it will figure out
what implementation is better.
As I noted before, I've been flexible about how SE-PgSQL is implemented
as far as it can perform SELinux's security model correctly.
Please for a several days. I'll describe it.
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
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
2009/7/20 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
- row-level security
- complex DDL permissions
Is the complex DDL permissions mean something like db_xxx:{create},
db_xxx:{relabelfrom relabelto} and others?
If so, I can agree to implement these checks at the later patch.
However, please note that the initial patch cannot achieve actual
security in this case, because it means anyone can change security
label of objects.
I'm not qualified to answer this question, and that's exactly why we
need more documentation of what this patch tries to do and why (i.e. a
spec). What I was specifically referring to is things like
db_column:{drop}, which are much more specific than anything
PostgreSQL currently offers to control DDL. I think we should make an
attempt to get objects labelled in a reasonable way (I did not like
the approach your latest patch took of just assigning everything a
default label), which might include relabelling also, but certainly
doesn't include things like distinguishing between different kinds of
DDL operations. I'm not really up on SELinux terminology (this is
another thing that needs to be covered in the documentation, and
isn't) but maybe something like db_table:{owner}.
I also agree with Peter's contention that a spec would be useful. If
you could read a clear description of what the patch was going to do,
then you could separate the problem of figuring out whether that was
the right thing from the question of whether the patch actually did
it.
I can also agree with the suggestion.
The specifications (from viewpoint of the developer) will introduces
the fundamental principles to be implemented, and it will figure out
what implementation is better.
As I noted before, I've been flexible about how SE-PgSQL is implemented
as far as it can perform SELinux's security model correctly.
Please for a several days. I'll describe it.
I really, really think you need to find someone to help you with the
documentation. As I've said before, your English is a lot better than
my Japanese, but the current documentation is just hard to read. More
than that, writing good documentation is HARD, and there are not a ton
of people who can do it well. It seems to me that the documentation
for this project could require as much work as the actual code.
And this is an excellent time to bring up the whole issue of community
involvement again. Many advocacy-type folks and end-users and
security folks have written in over the last year to say how much they
want this feature, but as far as anyone can tell KaiGai is the only
one doing any actual development to make it happen. Considering how
the alternative is, or so we're told, to spend $13,000/year (per CPU?)
for a similar Oracle feature, one might suppose that there would be
developers lining up to volunteer to help make this happen, and
companies making sponsorship dollars available to fund work by major
PostgreSQL contributors to get this whipped into shape. No? Well, at
the very least, one would hope that some of the people who say what
they want this feature to do could help document it, since they
presumably understand what it's supposed to do (if not, why are they
so sure they want it?). But so far the only person who has done
anything like this, as far as I'm aware, is me. And that's pretty
funny when you consider that I've learned enough about SE-Linux to do
exactly one thing: shut it off.
What I want for documentation of this feature is something like the
Database Roles and Privileges chapter of the current documentation.
You can read this chapter from beginning to end and have a pretty good
idea how to manage permissions in PostgreSQL. SE-Linux is complex
enough that you might have to refer to other sources of information
for certain topics (e.g. policy writing), because a full overview of
those topics might exceed the scope of our documentation. But it
should still be possible to start knowing nothing, read the chapter,
and have a pretty good idea how all the pieces fit together, at least
as far as PostgreSQL is concerned.
I would go so far as to suggest that we use the willingness of someone
from the community to volunteer to help KaiGai get this put together
as a litmus test for support for this patch. If someone sent in a
patch for Hot Standby or Streaming Rep tomorrow that was done except
for the documentation, how long do you think it would take them to get
some volunteers to help finish the docs? I'd bet less than a day. On
the other hand, it appears to me that we have had more people put more
time into __builtin_clz() over the last three months than
SE-PostgreSQL. __builtin_clz() has had multiple people benchmarking
it and testing it, giving feedback on the patch, etc. More often than
not, nobody even responds to KaiGai's patch set; it looks to me like
the last response that he got prior to when I started reviewing this
for CommitFest 2009-07 was a note from David Wheeler admiring
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. My representation might be confusable. What I would like to say was that it is unclear whether the security policy maintainer can accept definitions of object classes and permissions as-is we discussed here, so I would like to implement them at the second or later phase. It never means SELinux does not accept PostgreSQL specific permissions due to the its characteristic features. In fact, SELinux already provides db_blob object class and corresponding permissions to describe access control policies on largeobjects. As you said bellow, SELinux have several db_xxx object classes (it neans object classes for various kind of database objects) and allows DBMSs to choose a part of them. In addition, the security policy developer understand each RDBMS's have its characteristics, such as largeobjects and loadable C-libraries, so their security policy also should be developed for each object manager, although definitions of object classes and permissions can/cannot be shared. 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. I also think the SE-PostgreSQL should support its object classes and permissions on its characteristic features and the intersection of the two RDBMSs. The reason why I dropped most of permission checks was that SE-PgSQL has been pointed out its patch scale several times in the v8.4 development cycle, and suggested to drop all the permission check which does not have 1:1 relationship with the existing pg_xxx_aclcheck(). If we can make clear what should be/should not be implement at the first patch, I'll modify my patch set again. 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. Linux is a former case example in success. It puts various kind of security hooks (called LSM; Linux Security Module) rather than existing permissions. All the interfaces are designed not to give any side effects when security module (such as SELinux) is disabled, and source code comments explicitly introduce where/when the hooks should be invoked and what arguments should be given and what results should be returned.
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
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. 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. 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. Merely my opinion ofcourse, which doesn't count for much :) Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
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. 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. 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. 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 that after many revisions we still don't have anything that can be reviewed with any seriousness. The initial versions had so many extra bells and whistles (row-level security, complex DDL permissions) that they went way beyond basic SE-Linux support, and now we have a version that is stripped down to the point where it does barely anything. I feel like I'm spinning my wheels on a patch that nobody in the PostgreSQL community really wants anyway. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
On Friday 17 July 2009 06:10:12 Robert Haas wrote: 2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com: Yes, the tiny version will not give any advantages in security without future enhancements. It is not difficult to add object classes and permissions. If necessary, I'll add checks them with corresponding permissions. One anxiety is PostgreSQL specific object class, such as LANGUAGE. It's not clear for me whether the maintainer of the SELinux security policy accept these kind of object classes, or not. I would like to implement them except for PostgreSQL specific object class in this phase. 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. -- 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
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com: Updated SE-PgSQL patch is here: http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz Unused definitions of SELinux's permissions are ripped out from the permission table. OK, I'm looking at this version of the patch, and my first reaction is that it appears to be completely useless. Standard PostgreSQL has grantable privileges on 10 classes of objects: TABLE, COLUMN, SEQUENCE, DATABASE, FOREIGN DATA WRAPPER, FOREIGN SERVER, FUNCTION, LANGUAGE, SCHEMA, and TABLESPACE. This patch, on the other hand, implements SE-pgsql privileges for 3 classes of objects: DATABASE, NAMESPACE, and FUNCTION. That doesn't seem to jive in any conceivable way with the advice that has been given repeatedly and in every single review of this patch, which is to make the scope of SE-pgsql line up exactly with the standard permissions that PostgreSQL already implements. In earlier versions, there were checks on all sorts of extra things (like rows, and various DDL operations) that invented whole new classes of permission checks. Now you've gone to the opposite extreme of checking almost nothing. The goal here is not to pare this patch down to nothing: it's to implement a coherent feature set that matches what PostgreSQL already does. Here is what I wrote 4 days ago: Another problem that I have with this patch set is that it STILL doesn't have parity with the DAC permissions scheme (despite previous requests to make it have parity) Here is what I wrote 3 days ago: Yes: to repeat what has been said multiple times previously, you should postpone everything that isn't a mirror of the current security model: there should only be permission checks in places where there are permissions checks now, and they should be mirror images of the current DAC checks. Here is what I wrote yesterday: So the point we keep repeating here is that SEPostgreSQL should be doing the same kinds of permissions checks as regular PostgreSQL using the same names, code paths, etc. I don't know how to say it any more clearly than that. And just for reference, here is what Peter wrote 5 months ago, which is basically saying the same thing: If I had to do this, I would first write a patch for #1: A patch that additionally executes existing privilege checks against an SELinux policy. Existing privilege checks are a well-defined set: they mostly happen through pg_xxx_aclcheck() functions. Hook your checks in there. I really don't understand why this is so difficult. But I don't think you should bother resubmitting this patch until you've taken this advice. I am kind of running out patience here. I've reviewed this patch 3 times and found the exact same issue each time. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
Robert Haas wrote:
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
Updated SE-PgSQL patch is here:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
Unused definitions of SELinux's permissions are ripped out from
the permission table.
OK, I'm looking at this version of the patch, and my first reaction is
that it appears to be completely useless. Standard PostgreSQL has
grantable privileges on 10 classes of objects: TABLE, COLUMN,
SEQUENCE, DATABASE, FOREIGN DATA WRAPPER, FOREIGN SERVER, FUNCTION,
LANGUAGE, SCHEMA, and TABLESPACE. This patch, on the other hand,
implements SE-pgsql privileges for 3 classes of objects: DATABASE,
NAMESPACE, and FUNCTION. That doesn't seem to jive in any conceivable
way with the advice that has been given repeatedly and in every single
review of this patch, which is to make the scope of SE-pgsql line up
exactly with the standard permissions that PostgreSQL already
implements. In earlier versions, there were checks on all sorts of
extra things (like rows, and various DDL operations) that invented
whole new classes of permission checks. Now you've gone to the
opposite extreme of checking almost nothing.
Yes, the tiny version will not give any advantages in security without
future enhancements.
It is not difficult to add object classes and permissions.
If necessary, I'll add checks them with corresponding permissions.
One anxiety is PostgreSQL specific object class, such as LANGUAGE.
It's not clear for me whether the maintainer of the SELinux security
policy accept these kind of object classes, or not.
I would like to implement them except for PostgreSQL specific object
class in this phase.
The goal here is not to pare this patch down to nothing: it's to
implement a coherent feature set that matches what PostgreSQL already
does. Here is what I wrote 4 days ago:
Another problem that I have with this patch set is that it STILL
doesn't have parity with the DAC permissions scheme (despite previous
requests to make it have parity)
Here is what I wrote 3 days ago:
Yes: to repeat what has been said multiple times previously, you
should postpone everything that isn't a mirror of the current security
model: there should only be permission checks in places where there
are permissions checks now, and they should be mirror images of the
current DAC checks.
Here is what I wrote yesterday:
So the point we keep repeating here is that SEPostgreSQL should be
doing the same kinds of permissions checks as regular PostgreSQL using
the same names, code paths, etc. I don't know how to say it any more
clearly than that.
And just for reference, here is what Peter wrote 5 months ago, which
is basically saying the same thing:
If I had to do this, I would first write a patch for #1: A patch that
additionally executes existing privilege checks against an SELinux
policy. Existing privilege checks are a well-defined set: they mostly
happen through pg_xxx_aclcheck() functions. Hook your checks in
there.
I really don't understand why this is so difficult. But I don't think
you should bother resubmitting this patch until you've taken this
advice. I am kind of running out patience here. I've reviewed this
patch 3 times and found the exact same issue each time.
Here is a few differences in access control model between PostgreSQL and
SELinux, so I could not map all the SELinux permissions on the pg_xxx_aclcheck()
mechanism.
For example, ExecCheckRTEPerms() checks permissions on the tables and
columns appeared in the user given query. When the user have SELECT
permission on the required table, it bypasses to check permissions on
the columns.
SELinux's security model needs to check permissions on all the required
objects. For example, SELECT A,B FROM T requires the client to have
db_table:{select} on T and db_column:{select} on A and B.
For other example, some of pg_xxx_aclcheck() is bypassed when the client
has superuser privilege. In this case, SELinux requires the client to
have both of db_database:{superuser} and a certain permission.
If we deploy security hooks at the pg_xxx_aclcheck() or related stuff
at the first version, it is necessary to move them more appropriate
points later.
I can agree to deploy security hooks on pg_xxx_aclcheck(), if we can
move them to other points which can implement security model correctly
in the later version.
Sorry, I could not read it from the previous suggestions.
If you have been suggesting it repeatedly, I'm sorry so much.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
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
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
Yes, the tiny version will not give any advantages in security without
future enhancements.
It is not difficult to add object classes and permissions.
If necessary, I'll add checks them with corresponding permissions.
One anxiety is PostgreSQL specific object class, such as LANGUAGE.
It's not clear for me whether the maintainer of the SELinux security
policy accept these kind of object classes, or not.
I would like to implement them except for PostgreSQL specific object
class in this phase.
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.
Here is a few differences in access control model between PostgreSQL and
SELinux, so I could not map all the SELinux permissions on the
pg_xxx_aclcheck()
mechanism.
For example, ExecCheckRTEPerms() checks permissions on the tables and
columns appeared in the user given query. When the user have SELECT
permission on the required table, it bypasses to check permissions on
the columns.
SELinux's security model needs to check permissions on all the required
objects. For example, SELECT A,B FROM T requires the client to have
db_table:{select} on T and db_column:{select} on A and B.
Isn't this a purely arbitrary decision on your part to implement
incompatible semantics? I don't see why it can't check for
db_table:{select} and if that fails then check for db_column:[select}
on each column? Maybe that's not legit, I don't understand SE-Linux
well enough to know. But I think we need to get someone from the
SE-Linux community involved to help review and consider these kinds of
issues, because it is obvious that we don't have the expertise in the
PostgreSQL community.
For other example, some of pg_xxx_aclcheck() is bypassed when the client
has superuser privilege. In this case, SELinux requires the client to
have both of db_database:{superuser} and a certain permission.
Surely you can't just transform (A OR B) into (A AND B) and pretend
that's the same thing...
Sorry, I could not read it from the previous suggestions.
If you have been suggesting it repeatedly, I'm sorry so much.
I think the language barrier is part of what is making this a very
difficult process. Your English is surely better than my Japanese,
but we are definitely going around in circles.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
Robert Haas wrote:
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
Yes, the tiny version will not give any advantages in security without
future enhancements.
It is not difficult to add object classes and permissions.
If necessary, I'll add checks them with corresponding permissions.
One anxiety is PostgreSQL specific object class, such as LANGUAGE.
It's not clear for me whether the maintainer of the SELinux security
policy accept these kind of object classes, or not.
I would like to implement them except for PostgreSQL specific object
class in this phase.
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.
I believe different security mechanisms can have different viewpoints,
security models, criteria to make its access control decision and so on.
Some of SELinux part can match with PostgreSQL's permission with one-to-one,
such as db_database:{connect} and ACL_CONNECT.
But, we don't need to mind different security mechanism has different stuffs.
For example, Linux applies its DAC permission checks at inode_permission()
which also calls selinux_inode_permission(). It is the one-to-one mapping
part. But SELinux (LSM in actually) also put its security hooks in other
points, such as selinux_inode_rename() to check file renaming permissions,
selinux_socket_accept() to check accept connections permissions although
vanilla OS does not have corresponding permissions.
What I would like to say is that it is quite natural different security
mechanism has not-identical security models and so on.
Here is a few differences in access control model between PostgreSQL and
SELinux, so I could not map all the SELinux permissions on the
pg_xxx_aclcheck()
mechanism.
For example, ExecCheckRTEPerms() checks permissions on the tables and
columns appeared in the user given query. When the user have SELECT
permission on the required table, it bypasses to check permissions on
the columns.
SELinux's security model needs to check permissions on all the required
objects. For example, SELECT A,B FROM T requires the client to have
db_table:{select} on T and db_column:{select} on A and B.
Isn't this a purely arbitrary decision on your part to implement
incompatible semantics? I don't see why it can't check for
db_table:{select} and if that fails then check for db_column:[select}
on each column? Maybe that's not legit, I don't understand SE-Linux
well enough to know. But I think we need to get someone from the
SE-Linux community involved to help review and consider these kinds of
issues, because it is obvious that we don't have the expertise in the
PostgreSQL community.
Indeed, operating system does not have well analogy, such as a relationship
between tables and columns. However, SELinux's rule is simple.
Please imagine a situation when we write a security policy module.
When we would like to control accesses a certain object (such as column),
all we need to focus on is users' privileges on the column only.
If checks on columns are bypassed when he is allowed to access to the
table, we need to focus on both of the table and the column.
It seems to me it goes against to the principle in SELinux.
(Note that I never say database ACL model is bad. Both models have
their philosophies, and I believe both are worth each other.)
If you need any more comments from other persons in SELinux community,
I try to call Joshua Brindle who had been invoked in pgsql-hackers
several months ago.
For other example, some of pg_xxx_aclcheck() is bypassed when the client
has superuser privilege. In this case, SELinux requires the client to
have both of db_database:{superuser} and a certain permission.
Surely you can't just transform (A OR B) into (A AND B) and pretend
that's the same thing...
It needs to change code path but it is not reasonable when user
disables SE-PgSQL. So, I thought separated security hooks are
reasonable, because it is replaced by empty macro if disabled.
Sorry, I could not read it from the previous suggestions.
If you have been suggesting it repeatedly, I'm sorry so much.
I think the language barrier is part of what is making this a very
difficult process. Your English is surely better than my Japanese,
but we are definitely going around in circles.
...Robert
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
The following patch is the tiny version of SE-PostgreSQL:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2193.patch.gz
In this version, all the security hooks (to make decision) invoked from
outside of the pg_xxx_aclcheck() and superuser_arg() were separated.
So, SE-PgSQL/tiny only checks the following only four permissions:
- db_database:{connect} ... equivalent to ACL_CONNECT on the database
- db_database:{superuser} ... equivalent to the superuser privilege
- db_schema:{usage} ... equivalent to ACL_USAGE on the namespace
- db_procedure:{execute} ... equivalent to ACL_EXECUTE on the procedure
All the database objects to be labeled are databases, namespaces and
procedures, so I modified system column definitions.
- db_database.datseclabel (text)
- db_namespace.nspseclabel (text)
- db_procedure.proseclabel (text)
When we create a new one, a default security label shall be assigned
as far as we don't give any explicit security label.
(In the current version, it only checks sanity check of security label,
no any permission checks.)
The following features were separated.
- Facility to cache access control decisions
- Table/column level access controls
- Trusted procedures
FYI, It is the scale of patch.
It may seem you the tiny is larger than the lite.
But, 50% of changeset is at include/catalog/pg_proc.h, because we separate
the pg_security facility, so it was necessary to add a new regular attribute
into pg_proc system catalog. The pg_proc.h has 2000 of definitions for built
in functions, using DATA(...) macro. I updates them by sed secript.
It is the reason for the big changeset.
This patch also contains 570L of documentation changes, and 442L of testcases.
So, actual code changeset is about 2700L.
[kai...@saba]$ diffstat
/home/kaigai/RPMS/SOURCES/sepgsql-01-tiny-8.5devel-r2193.patch.gz
configure | 112
configure.in | 13
doc/src/sgml/catalogs.sgml | 21
doc/src/sgml/config.sgml | 42
doc/src/sgml/errcodes.sgml | 21
doc/src/sgml/filelist.sgml |1
doc/src/sgml/postgres.sgml |1
doc/src/sgml/ref/alter_database.sgml | 12
doc/src/sgml/ref/alter_function.sgml | 13
doc/src/sgml/ref/alter_schema.sgml | 11
doc/src/sgml/ref/create_database.sgml | 14
doc/src/sgml/ref/create_function.sgml | 12
doc/src/sgml/ref/create_schema.sgml| 16
doc/src/sgml/ref/initdb.sgml | 11
doc/src/sgml/sepgsql.sgml | 395
src/Makefile.global.in |1
src/backend/Makefile |7
src/backend/bootstrap/bootstrap.c |4
src/backend/catalog/aclchk.c | 22
src/backend/catalog/namespace.c| 17
src/backend/catalog/pg_aggregate.c |3
src/backend/catalog/pg_namespace.c |6
src/backend/catalog/pg_proc.c | 29
src/backend/commands/alter.c | 31
src/backend/commands/dbcommands.c | 86
src/backend/commands/functioncmds.c| 82
src/backend/commands/proclang.c|6
src/backend/commands/schemacmds.c | 69
src/backend/nodes/copyfuncs.c | 19
src/backend/nodes/equalfuncs.c | 17
src/backend/parser/gram.y | 68
src/backend/security/Makefile | 11
src/backend/security/sepgsql/Makefile | 16
src/backend/security/sepgsql/avc.c | 331
src/backend/security/sepgsql/dummy.c | 31
src/backend/security/sepgsql/hooks.c | 167
src/backend/security/sepgsql/label.c | 523 +
src/backend/security/sepgsql/misc.c| 152
src/backend/security/sepgsql/perms.c | 353
src/backend/security/sepgsql/policy/Makefile | 28
src/backend/security/sepgsql/policy/sepostgresql-devel.fc.template | 12
src/backend/security/sepgsql/policy/sepostgresql-devel.te
Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193
Updated SE-PgSQL patch is here:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
Unused definitions of SELinux's permissions are ripped out from
the permission table.
KaiGai Kohei wrote:
The following patch is the tiny version of SE-PostgreSQL:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2193.patch.gz
In this version, all the security hooks (to make decision) invoked from
outside of the pg_xxx_aclcheck() and superuser_arg() were separated.
So, SE-PgSQL/tiny only checks the following only four permissions:
- db_database:{connect} ... equivalent to ACL_CONNECT on the database
- db_database:{superuser} ... equivalent to the superuser privilege
- db_schema:{usage} ... equivalent to ACL_USAGE on the namespace
- db_procedure:{execute} ... equivalent to ACL_EXECUTE on the procedure
All the database objects to be labeled are databases, namespaces and
procedures, so I modified system column definitions.
- db_database.datseclabel (text)
- db_namespace.nspseclabel (text)
- db_procedure.proseclabel (text)
When we create a new one, a default security label shall be assigned
as far as we don't give any explicit security label.
(In the current version, it only checks sanity check of security label,
no any permission checks.)
The following features were separated.
- Facility to cache access control decisions
- Table/column level access controls
- Trusted procedures
FYI, It is the scale of patch.
It may seem you the tiny is larger than the lite.
But, 50% of changeset is at include/catalog/pg_proc.h, because we separate
the pg_security facility, so it was necessary to add a new regular attribute
into pg_proc system catalog. The pg_proc.h has 2000 of definitions for built
in functions, using DATA(...) macro. I updates them by sed secript.
It is the reason for the big changeset.
This patch also contains 570L of documentation changes, and 442L of testcases.
So, actual code changeset is about 2700L.
[kai...@saba]$ diffstat
/home/kaigai/RPMS/SOURCES/sepgsql-01-tiny-8.5devel-r2193.patch.gz
configure | 112
configure.in | 13
doc/src/sgml/catalogs.sgml | 21
doc/src/sgml/config.sgml | 42
doc/src/sgml/errcodes.sgml | 21
doc/src/sgml/filelist.sgml |1
doc/src/sgml/postgres.sgml |1
doc/src/sgml/ref/alter_database.sgml | 12
doc/src/sgml/ref/alter_function.sgml | 13
doc/src/sgml/ref/alter_schema.sgml | 11
doc/src/sgml/ref/create_database.sgml | 14
doc/src/sgml/ref/create_function.sgml | 12
doc/src/sgml/ref/create_schema.sgml| 16
doc/src/sgml/ref/initdb.sgml | 11
doc/src/sgml/sepgsql.sgml | 395
src/Makefile.global.in |1
src/backend/Makefile |7
src/backend/bootstrap/bootstrap.c |4
src/backend/catalog/aclchk.c | 22
src/backend/catalog/namespace.c| 17
src/backend/catalog/pg_aggregate.c |3
src/backend/catalog/pg_namespace.c |6
src/backend/catalog/pg_proc.c | 29
src/backend/commands/alter.c | 31
src/backend/commands/dbcommands.c | 86
src/backend/commands/functioncmds.c| 82
src/backend/commands/proclang.c|6
src/backend/commands/schemacmds.c | 69
src/backend/nodes/copyfuncs.c | 19
src/backend/nodes/equalfuncs.c | 17
src/backend/parser/gram.y | 68
src/backend/security/Makefile | 11
src/backend/security/sepgsql/Makefile | 16
src/backend/security/sepgsql/avc.c | 331
src/backend/security/sepgsql/dummy.c | 31
src/backend/security/sepgsql/hooks.c | 167
src/backend/security/sepgsql/label.c | 523 +
src/backend/security/sepgsql/misc.c
