On 05/28/2015 03:10 PM, Ted Toth wrote: > Unfortunately it is the latter. Here's an example of what you can do: > > CREATE TABLE reports ( > id integer NOT NULL, > report json, > message_id integer NOT NULL, > location geometry(Point), > security_label text DEFAULT sepostgres_getpeercon() > ); > > CREATE POLICY > check_report_insert_selinux ON reports FOR INSERT > WITH CHECK (sepostgres_check_row_perm(reports.security_label, > sepostgres_getpeercon(), 'insert')); > > CREATE POLICY > check_report_delete_selinux ON reports FOR DELETE > USING (sepostgres_check_row_perm(reports.security_label, > sepostgres_getpeercon(), 'delete')); > > CREATE POLICY > check_report_update_selinux ON reports FOR UPDATE > USING (sepostgres_check_row_perm(reports.security_label, > sepostgres_getpeercon(), 'update')) > WITH CHECK (sepostgres_check_row_perm(reports.security_label, > sepostgres_getpeercon(), 'update')); > > CREATE POLICY > check_report_select_selinux ON reports FOR SELECT > USING (sepostgres_check_row_perm(sepostgres_getpeercon(), > reports.security_label, 'select')); > > I'm hoping that between DAC, postgresql DAC, selinux policy and RLS > policy we can get something that's secure enough for our purposes. Pardon my ignorance, but are the sepostgres_*() functions something you have implemented or something in the existing sepgsl or postgres code? _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
