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
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)
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)
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
[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
| 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
