>> * 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 <[email protected]>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers