Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
Tom Lane wrote: > KaiGai Kohei <[EMAIL PROTECTED]> writes: >>>> There are also >>>> some interesting questions about SQL spec compliance and whether a >>>> database that silently hides some rows from you will give semantically >>>> consistent results. >>> Yeah -- that's a potentially serious issue; KaiGai, have you looked into >>> it? > >> Yes, I consider the policy to filter any violated tuple looks consistently. >> The policy enforces any tuple has to be filtered before using them, and >> it helps that computational processes don't get any effect from them. > >> But proving innocence is generally hard task. >> At first, I want to know what points are you worried about the most. > > Unique constraints and foreign-key constraints seem the most pressing > problems. What will you do to avoid having different viewers have > different opinions about whether a constraint is violated? The behavior of unique constraints are kept as is. Thus, a client with some hidden tuples may not be able to insert a new tuple, though the tuple seems to him containing unique values. >From strict security viewpoint, this behavior has a possibility to leak the existence of hidden tuples to clients without enough permissions. To resolve them, polyinstantiation table support will be required ultimately. When a client tries to insert a new tuple into a table in which foreign-key constraints are configured, the foreign-key values have to be included in his scope. If not so, the current transaction will be aborted. If the constraint has CASCADE rule, all the foreign-keys have to be updated when the value of primary key is changed. It is an exception for the policy to filter. If the client have any violated tuple, whole the process will be aborted. In normal cases, those tuples are merely excluded from the target of updating, although. As the conclusion, we intend to keep the consistency of any constrains. But some issues are remained from strict security viewpoint. Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
... which presumably wouldn't involve any added dependency on outside code. For people who are already using SELinux or Trusted Solaris, making the database dependent on that infrastructure might be seen as a plus, but I'm not sure the rest of the world would be pleased. Yes, I was thinking that this should be a compile-time option with a lot of warnings in the Docs. Yes, those facilities are not enabled without '--enable-selinux' compile-time option. It's a bit unclear for me what means the "a lot of warnings the Docs". Give the team some credit, though; they've managed to come up with a system that integrates OS-level ACLs for both SElinux and TxSol, are not asking us to incorporate two different sets, and are coming to us with a serious proposal that has a lot of work behind it. Please don't blow them off like they were undergrads submitting a semester project. If they need to come back after 8.3 beta so we can properly pay attention to the proposal, then say so. I don't hurry to merge those facilities regardless. (8.3 is already feature frozen, as announced earlier.) As I mentioned at first, the purpose of this discussion is to obtain any feedbacks from PostgreSQL community, for our development. I believe it also helps SE- stuff to be merged in the later version of PostgreSQL. There are also some interesting questions about SQL spec compliance and whether a database that silently hides some rows from you will give semantically consistent results. Yeah -- that's a potentially serious issue; KaiGai, have you looked into it? Yes, I consider the policy to filter any violated tuple looks consistently. The policy enforces any tuple has to be filtered before using them, and it helps that computational processes don't get any effect from them. But proving innocence is generally hard task. At first, I want to know what points are you worried about the most. Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
For people who are already using SELinux or Trusted Solaris, making the database dependent on that infrastructure might be seen as a plus, but I'm not sure the rest of the world would be pleased. Even where SELinux is available it has had mixed reviews - I habitually disable it. The relationship between your works and SE-PostgreSQL effort is similar to the relationship between UNIX-DAC/Posix-ACL and SELinux on operating systems. I believe those are not conflicted efforts. Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
Tom Lane wrote: > "Andrew Dunstan" <[EMAIL PROTECTED]> writes: >> What's more, we have a SoC project for column level access controls. > > ... which presumably wouldn't involve any added dependency on outside code. > For people who are already using SELinux or Trusted Solaris, making the > database dependent on that infrastructure might be seen as a plus, but > I'm not sure the rest of the world would be pleased. The most significant purpose of PGACE and SE-PostgreSQL is integration between database and operating system security policy, on mandatory access controlled (MAC) system especially. Thus, not to provide any regression is the most desired behavior of PGACE on non-MAC system like SELinux disabled Linux, I think. PGACE without using SELinux or Trusted Solaris does not give any effect, because it is defined as static inline function with no operation mostly. > There are also > some interesting questions about SQL spec compliance and whether a > database that silently hides some rows from you will give semantically > consistent results. Any violated tuples are always filtered from result set, before using them, as if an additional condition is appended onto WHERE or JOIN ON clause. The condition means whether client has enough permission on this tuple, or not. All those processes are done after rewriting phase, so result set is constant even if a table is referred via views. Thus, client can deal a table as if it does not contain any violated tuples. # If a result set contains any violated tuple, it's a bug of SE-PostgreSQL. An exception is foreign key implementation. It internally uses UPDATE query to support 'ON UPDATE CASCADE' rule and so on. If violated tuples are filtered, the FK constraint is not kept. For example, when there are five tuples to be cascaded but client does not have enough permission onto two of them, the two tuple will be remained without cascading. In SE-PostgreSQL, whole of transaction will be aborted, if client does not have enough permissions on all the tuples cascaded under FK processing. One more exception is TRUNCATE statement. In SE-PostgreSQL, TRUNCATE statement is nonsense, because it is translated into unconditional DELETE statement to avoid removing tuples without enough permission. Currently, I have not gotten any inconsistency in the access control model. But any pointed out is welcome. Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
Tom Lane wrote: > Josh Berkus <[EMAIL PROTECTED]> writes: >> Column level? We don't currently support that, except through VIEWs. >> How is it implemented? > > It wasn't clear to me how much of this is actually working today and how > much is a paper design --- one thing in particular that stood out as > probable handwaving was the bit about being able to assign to a system > column in INSERT or UPDATE. I'm fairly sure that that would take some > *significant* redesign of querytree and plan targetlist representation > :-( ... I looked at it once for OIDs and decided it wasn't worth the > trouble. Currently, writable system column support is already included as a part of PGACE, and it works fine to make setting up SE-PostgreSQL. The implementation uses TargetEntry->resjunk effectively to make it simplified. When a targetlist contains "security_context" column in a UPDATE or INSERT query, SE-PostgreSQL marks the TargetEntry as a junk. Then, the value explicitly given as "security_context" is computed in the normal way. It is fetched at ExecutePlan() just before calling ExecUpdate() or ExecInsert(), and stored into HeapTupleHeader->t_security. Maybe, a part of the patch to implement them is less than 100L, without any significant redesign, Is there any oversight? If so, please tell me. Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
Josh Berkus wrote: > KaiGai, > >> It provides database users fine grained mandatory access control >> including row and column level one, and integration with operating >> system security policy. > > Column level? We don't currently support that, except through VIEWs. > How is it implemented? PGACE provides a hook just after query rewriting phase. SE-PostgreSQL walks on the query tree to check any required references onto columns, as the implementation of the hook. If a client does not have enough permissions onto the column, SE-PostgreSQL abort the current transaction via ereport(). Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
As I announced alpha version of SE-PostgreSQL about one month ago, I'm working for development of a security facility integrated with secure operating system. It provides database users fine grained mandatory access control including row and column level one, and integration with operating system security policy. This concept may have applicability to other secure operating system such as Trusted Solaris. Just after the announcement, Sun.com's people were interested in SE-PostgreSQL works, and contacted me. They also want to implement a similar functionality on their operating system using Trusted Extension (TX). We got an agreement that a common framework like LSM will be useful to implement and maintain those secure facilities. I want to have a discussion and get feedbacks about this idea from PostgreSQL developers. -- The framework named PGACE(PostgreSQL Access Control Extension). It provides two major facilities. One is hooks on some strategic points. The other is a functionality to associate a tuple with its security attribute. Any hooks is defined as a static inline functions in "security/pgace.h". They give no effect, if no security facilities are configured. If SELinux support is enabled via configure script, those definitions are overwritten by "security/sepgsql.h", and the hooks calls actual SE-PostgreSQL implementation to provide MAC(mandatory access control). Those hooks are deployed on the some strategic points of PostgreSQL such as simple_heap_insert(), PortalStart() and so on. You can get all the definition of pgace.h and sepgsql.h from the following URL: http://sepgsql.googlecode.com/svn/trunk/src/include/security/ The later functionality enables to associate a tuple with security attribute. It adds a new field (t_security) with Oid type into HeapTupleHeaderData structure. The t_security can persistently hold a Oid of pg_security new system catalog. The pg_security has a combination of Oid value and security attribute with text representation. Database users can refer the attribute via new system column. When SQL query tries to refer this attribute via the system column, PGACE lookups pg_security system column to get a tuple which has same oid compared to t_security value of its HeapTupleHeaderData. It's implemented as input/output handler of new security_label type. The name of system column is defined in pg_config.h.in. In SELinux case, it's named "security_context". This system column is writable via UPDATE or INSERT statement, to enables relabeling. Because most of security attribute shares same text representation, this implementation works effectively and economically. As you know, PostgreSQL handles any database object as a tuple stored in system catalogs. So, this concept may have applicability to any kind of database object like table, column and procedure. -- I hope that SE-PostgreSQL and PGACE are merged into future upstreamed PostgreSQL and we can turn on/off by configure option without any patch. I believe any comments and feedbacks are so helpful to indicate the direction of our development with an approach which is acceptable by PostgreSQL development community. Thanks, * Reference The full set of patch is a bit large to post the list directly. (6.7KL) You can checkout the source code from the following URL: http://code.google.com/p/sepgsql/source You can get the patch for SE-PostgreSQL based on PGACE from the following URL: http://sepgsql.googlecode.com/files/sepostgresql-8.2.3-226.patch (against to the stable postgresql-8.2.3) -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release
t | 20 3 | milk |130 | t | 5 4 | water |100 | t | 10 5 | beer |240 | f | 15 6 | wine |380 | f | 0 (6 rows) ## The security context of each tuples are stored in 'security_context' ## system column. kaigai=# select security_context,* from drink; security_context | did | dname | dprice | dsoft | dstock -+-+---++---+ user_u:object_r:sepgsql_table_t | 1 | juice |110 | t | 35 user_u:object_r:sepgsql_table_t | 2 | coke |110 | t | 20 user_u:object_r:sepgsql_table_t | 3 | milk |130 | t | 5 user_u:object_r:sepgsql_table_t | 4 | water |100 | t | 10 user_u:object_r:sepgsql_table_t | 5 | beer |240 | f | 15 user_u:object_r:sepgsql_table_t | 6 | wine |380 | f | 0 (6 rows) kaigai=# ## A example of execution under lower authority: ## The two tuples which have 'SystemHigh' were filtered. $ runcon -l s0 -- bash $ id -Z root:system_r:unconfined_t $ psql -q kaigai=# select sepgsql_getcon(); sepgsql_getcon root:system_r:unconfined_t (1 row) kaigai=# select * from drink; NOTICE: SELinux: denied { select } scontext=root:system_r:unconfined_t tcontext=user_u:object_r:sepgsql_table_t:SystemHigh tclass=tuple NOTICE: SELinux: denied { select } scontext=root:system_r:unconfined_t tcontext=user_u:object_r:sepgsql_table_t:SystemHigh tclass=tuple did | dname | dprice | dsoft | dstock -+---++---+ 1 | juice |110 | t | 35 2 | coke |110 | t | 20 3 | milk |130 | t | 5 4 | water |100 | t | 10 (4 rows) kaigai=# $ exit ## We tried to connect from a domain which cannot access 'sepgsql_secret_table_t' $ runcon -t initrc_t -- bash $ id -Z root:system_r:initrc_t:SystemLow-SystemHigh $ psql -q kaigai=# select * from drink; ERROR: SELinux: denied { select } scontext=root:system_r:initrc_t:SystemLow-SystemHigh tcontext=user_u:object_r:sepgsql_secret_table_t tclass=column name=dstock ## The client in initrc_t domain cannot access dstock column which has ## sepgsql_table_t type, but we cann access the column via trusted ## procedure only. kaigai=# select did, dname, dprice, drink_stock_exist(did) from drink; did | dname | dprice | drink_stock_exist -+---++--- 1 | juice |110 | t 2 | coke |110 | t 3 | milk |130 | t 4 | water |100 | t 5 | beer |240 | t 6 | wine |380 | f (6 rows) kaigai=# == [Hint] * There is no compatibility between SE-PostgreSQL and PostgreSQL. You have to pay attention not to destroy your database files for native PostgreSQL. * You can enable/disable access allowed/denied messages by using boolean stuff of SELinux. Set the following booleans by setsebool command. sepgsql_enable_auditallow sepgsql_enable_auditdeny sepgsql_enable_audittuple * initrc_t is defined as a less power domain for test purpose. We cannot use DDL statement from initrc_t domain, and cannot access tables, columns and tuples with sepgsql_secret_table_t type. * The security policy for SE-PostgreSQL under the strict policy is now under development. You have to switch to the targeted policy, if you try to use this version. -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SE-Linux/PostgreSQL work?
Hello, Josh Berkus wrote: Folks, I'm chasing a rumor that someone is working on integrating PostgreSQL with the SELinux security framework. Anyone know anything about this? I'm currently working on integration PostgreSQL with SELinux security framework. It was named as SE-PostgreSQL. Thanks for your interest. It will provide finer grained mandatory access control on the various kinds of database objects including columns, tuples and binary large objects, based on the security policy of SELinux. Any clients cannot bypass this access control, even if they are privileged database users. Now, I have a plan to release the first alpha version of SE-PostgreSQL within this week, to get any feedbacks from PostgreSQL/SELinux community. Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq