>> * 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:s0tclass=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:Unclassifiedtcontext=system_u:object_r:sepgsql_ro_table_t:Classified
tclass=db_tablename=t1 STATEMENT: UPDATE t1 SET a = 1; ERROR: SELinux: security policy violation STATEMENT: UPDATE
t1SET 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@ak.jp.nec.com>
