Re: SE-PgSQL patch review

>> * Can we use error messages that looks like existing privilege errors?
>> ERRCODE_INSUFFICIENT_PRIVILEGE:
>> => permission denied to rename database
>
> Here is a point that we should provide users a hint which enables
> to make clear the reason of access violations. So, I think we should
> contains a mark to show it come from SE-PgSQL.
>
> Currently, it raises an error on access violation in sepgsql_compute_perms().
> It always prints out "SELinux: security policy violation".

It is just for your information.

SELinux allows end-users to confirm what accesses are violated using audit logs.
In operating system, it is written on the /var/log/audit/audit.log.

See the result of:
% grep ^type=AVC /var/log/audit/audit.log
:
type=AVC msg=audit(1258412043.107:81): avc: denied { search } for pid=1750 comm="httpd" name="root" dev=sda5 ino=1062881 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
:

In SE-PgSQL, it writes out detailed information about access violations
on log files. Then, it can be used to revise security policy.

For example:
postgres=# UPDATE t1 SET a = 1;
ERROR: SELinux: security policy violation

It shall be logged as follows:
LOG: SELinux: denied { update } scontext=unconfined_u:unconfined_r:sepgsql_test_t:Unclassified tcontext=system_u:object_r:sepgsql_ro_table_t:Classified tclass=db_table name=t1
STATEMENT: UPDATE t1 SET a = 1;
ERROR: SELinux: security policy violation
STATEMENT: UPDATE t1 SET a = 1;

We can also provide these logs to analyzer programs to pop-up a hint for
trouble-shooting (setroubleshoot), to generate policy module automatically
from access violation logs (audit2allow), and so on.

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