Skip site navigation (1) Skip section navigation (2)

SE-PostgreSQL Updated Revision (r1460)

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, tgl(at)sss(dot)pgh(dot)pa(dot)us, bruce(at)momjian(dot)us, simon(at)2ndQuadrant(dot)com, alvherre(at)commandprompt(dot)com
Subject: SE-PostgreSQL Updated Revision (r1460)
Date: 2009-01-23 05:30:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
The patch set of SE-PostgreSQL and related stuff were updated (r1460).


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 r1425 conflicts in some points.)

- Security policy (sepostgresql-devel.pp) was updated to fit both of
  Fedora 10 and rawhide. Test cases are also modified to 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 a part 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 labeled as
  "user_sepgsql_proc_t" in default, and it is not allowed to install as
  an operator and so on.
  If DBA want to install user-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 unprivilged user is allowed to
  execute self defined function.

- Code revising: The previous revision always denied required permissions,
  when the kernel does not define them within its security policy.
  But it can make unexpected behavior when we work SE-PostgreSQL on
  a system with legacy security policy which 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 change anything 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 tuples are 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.
    For example:
      UPDATE pg_largeobject SET loid = loid::int + 10 WHERE loid = 1234;
  It is theoretically same as dropping a largeobject 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-Level Privileges"
  thread. This revision added a special care for the situation.
  It recursively walks on refered JoinExpr and 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 previous revision,
  it simply chains all appeared tables and columns as a list of obsoleted
  node on Query->pgaceItem. But it has a trend the length of list grows long.
  T_SelinuxEvalItem contains required permissions on a table and an array of
  permissions for 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 inheritance tables 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 returns its pointer to caller.
  But it is not necessary for most cases. It is revised to return a pointer
  within given tuple to avoid useless strcpy(), if possible. So, its valid
  duration is limited to the duration of tuple, but there is no real 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 is necessary to check
  db_database:{install_module} permission.

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

OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to


pgsql-hackers by date

Next:From: Albe LaurenzDate: 2009-01-23 07:20:35
Subject: Re: problem with archive_command as suggested by documentation
Previous:From: Tom LaneDate: 2009-01-23 04:58:41
Subject: Re: reducing statistics write overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group