SE-PostgreSQL Updated Revision (r1460) - Mailing list pgsql-hackers

The patch set of SE-PostgreSQL and related stuff were updated (r1460).

[1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1460.patch
[2/5] http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1460.patch
[3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1460.patch
[4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1460.patch
[5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1460.patch

I reviewed the patch set by myself, and updated the following items.
However, I would like other hackers to review the code in honesty.

SE-PostgreSQL need any volunteers to review and comment the patch set.
Please give us your support!

List of updates:
- Rebased to the latest CVS HEAD, which includes the column-level privileges based on the SQL-standard. (The previous
r1425conflicts in some points.)
 

- Security policy (sepostgresql-devel.pp) was updated to fit both of Fedora 10 and rawhide. Test cases are also
modifiedto care the new security policy.
 

- Cleanup: NUM_SELINUX_CATALOG was replaced by lengthof() macro to avoid code duplications.

- Cleanup: sepgsqlCheckEmbeddedProcedure() is renamed to sepgsqlCheckProcedureInstall() due to its confusable naming.

- Add a new permission: db_procedure:{install} It enables to prevent malicious user-defined functions are installed as
apart of operators, conversions, types and so on. The default policy allows to install functions labeled as
"sepgsql_proc_t"only, as an implementation of these facilities. Meanwhile, functions defined by unprivileged users are
labeledas "user_sepgsql_proc_t" in default, and it is not allowed to install as an operator and so on. If DBA want to
installuser-defined functions for the purpose, he has to confirm its harmless and relabel it to "sepgsql_proc_t" at
first.In the previous revision, it checked "db_procedure:{execute}" here, but it is not enough actually, because
unprivilgeduser is allowed to execute self defined function.
 

- Code revising: The previous revision always denied required permissions, when the kernel does not define them within
itssecurity policy. But it can make unexpected behavior when we work SE-PostgreSQL on a system with legacy security
policywhich lacks a part of newly added permissions. The revised one simply allows actions when these are undefined.
 

- Fixbug: It required superfluous permissions when we try to update "security_label" system column but it does not
changeanything actually.   For example:     UPDATE t SET security_label = security_label; This query does not change
security_label,so we don't need to check "db_tuple:{relabelfrom}" permission here. It is obvious we cannot know what
tuplesare actually relabeled on sepgsqlExecScan(), so any permission checks for write-operations are moved to
sepgsqlHeapTuple(Insert|Update|Delete)hooks.
 

- Fixbug: when we update pg_largeobject system catalog by hand, it has a possibility to create/drop specific
largeobject,so we add a check on "db_blob:{create drop}" when pg_largeobject.loid is modified by UPDATE statement.
Forexample:     UPDATE pg_largeobject SET loid = loid::int + 10 WHERE loid = 1234; It is theoretically same as dropping
alargeobject with loid:1234 and creating a largeobject with loid:1244.
 

- Fixbug: Tome Lane pointed out a matter when a whole-row-reference on the relation with RTE_JOIN makes crash at the
"Column-LevelPrivileges" thread. This revision added a special care for the situation. It recursively walks on refered
JoinExprand picks up its sources to check permission to them.
 

- Code revising: T_SEvalItemRelation and T_SEvalItemAttribute nodes are integrated into T_SelinuxEvalItem node. In the
previousrevision, it simply chains all appeared tables and columns as a list of obsoleted node on Query->pgaceItem. But
ithas a trend the length of list grows long. T_SelinuxEvalItem contains required permissions on a table and an array of
permissionsfor columns. It enables to keep the length of the list minimum. Related stuffs in sepgsql/proxy.c is also
revised. - addEvalRelation() / addEvalAttribute() enhanced to handle T_SelinuxEvalItem.  - Functions to handle
inheritancetables and whole-row-reference are clearly    sorted out. expandEvalItemInheritance() handles inheritance
tables,and    expandEvalItemWholeRowRefs() handles whole-row-reference.
 

- Add a hook: pgaceExecuteTruncate() The previous revision checks permissions on truncated tables and tuples on
pgaceProcessUtility(),but this approach need to extract all the target including cascaded ones, so it made code
duplication.The new hook is deployed on ExecuteTruncate() and delivers a list of already opened relations with
AccessExclusiveLock.A new sepgsqlExecuteTruncate() checks needed permission on the hook.
 

- Cleanup: sepgsqlTupleName() always copied an identifier of tuple for audit record into its internal buffer, and
returnsits pointer to caller. But it is not necessary for most cases. It is revised to return a pointer within given
tupleto avoid useless strcpy(), if possible. So, its valid duration is limited to the duration of tuple, but there is
noreal matter. In addition, callers of sepgsqlTupleName() are cleaned up, because its length of line tend to grow a bit
long.

- Add a check: CREATE/ALTER FOREIGN DATA WRAPPER has a capability to load a discretional shared library module, so it
isnecessary to check db_database:{install_module} permission.
 

- Add source code comments: src/backend/security/sepgsql/avc.c

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>