postgresql policy

postgresql policy

[Ted Toth]

The ref policy contains a number of sepgsql_ types that are specific
to the sepgsql postgresql module. The sepgsql module was written to
support a postgresql security patch that was never accepted by the
upstream. Now postgresql has gone in a different direction security
wise adding row level security (RLS). I've been working on developing
RLS policy to label rows on insert and update and to check access
perms on select. I've tried using the sepgsql module in the RLS policy
but have come to the conclusion that because it was not designed for
this purpose it is not usable. So I'd like to suggest that these types
be moved out of the postgresql policy possibly into their own module
although I personally think they have little if any use.

Ted

Re: postgresql policy

[Stephen Smalley]

On 05/28/2015 12:52 PM, Ted Toth wrote:
> The ref policy contains a number of sepgsql_ types that are specific
> to the sepgsql postgresql module. The sepgsql module was written to
> support a postgresql security patch that was never accepted by the
> upstream. Now postgresql has gone in a different direction security
> wise adding row level security (RLS). I've been working on developing
> RLS policy to label rows on insert and update and to check access
> perms on select. I've tried using the sepgsql module in the RLS policy
> but have come to the conclusion that because it was not designed for
> this purpose it is not usable. So I'd like to suggest that these types
> be moved out of the postgresql policy possibly into their own module
> although I personally think they have little if any use.

Should probably post a rfc patch to refpolicy list.

On a different note, does this RLS implementation have any SELinux
integration or is it just the typical "let's implement our own custom
policy engine in the database manager and not link it in any way to the
OS security model" approach?  Pity if it is the latter.

Re: postgresql policy

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

Stephen,

* Stephen Smalley (sds@tycho.nsa.gov) wrote:
> On 05/28/2015 12:52 PM, Ted Toth wrote:
> > The ref policy contains a number of sepgsql_ types that are specific
> > to the sepgsql postgresql module. The sepgsql module was written to
> > support a postgresql security patch that was never accepted by the
> > upstream. Now postgresql has gone in a different direction security
> > wise adding row level security (RLS). I've been working on developing
> > RLS policy to label rows on insert and update and to check access
> > perms on select. I've tried using the sepgsql module in the RLS policy
> > but have come to the conclusion that because it was not designed for
> > this purpose it is not usable. So I'd like to suggest that these types
> > be moved out of the postgresql policy possibly into their own module
> > although I personally think they have little if any use.
> 
> Should probably post a rfc patch to refpolicy list.
> 
> On a different note, does this RLS implementation have any SELinux
> integration or is it just the typical "let's implement our own custom
> policy engine in the database manager and not link it in any way to the
> OS security model" approach?  Pity if it is the latter.

As the one who committed RLS to PostgreSQL, I'm hopeful that what we
have is actually able to provide both.  There is a system inside of
PostgreSQL for creating policies, which was a requirement of the PG
community as we fully expect it to be used in non-SELinux environments,
but there are also hooks available where a module (such as the sepgsql
contrib module that's included with PG) could add its own restrictive
and/or permissive policies.

I'm certainly interested in the type changes being discussed here and
would love to work with someone from the SELinux community on improving
the sepgsql contrib module (or, perhaps, adding a different and simpler
module which is closer to a shim around SELinux than the existing
sepgsql module).

	Thanks!

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: postgresql policy

[Stephen Smalley]

On 05/28/2015 03:09 PM, Stephen Frost wrote:
> Stephen,
> 
> * Stephen Smalley (sds@tycho.nsa.gov) wrote:
>> On 05/28/2015 12:52 PM, Ted Toth wrote:
>>> The ref policy contains a number of sepgsql_ types that are specific
>>> to the sepgsql postgresql module. The sepgsql module was written to
>>> support a postgresql security patch that was never accepted by the
>>> upstream. Now postgresql has gone in a different direction security
>>> wise adding row level security (RLS). I've been working on developing
>>> RLS policy to label rows on insert and update and to check access
>>> perms on select. I've tried using the sepgsql module in the RLS policy
>>> but have come to the conclusion that because it was not designed for
>>> this purpose it is not usable. So I'd like to suggest that these types
>>> be moved out of the postgresql policy possibly into their own module
>>> although I personally think they have little if any use.
>>
>> Should probably post a rfc patch to refpolicy list.
>>
>> On a different note, does this RLS implementation have any SELinux
>> integration or is it just the typical "let's implement our own custom
>> policy engine in the database manager and not link it in any way to the
>> OS security model" approach?  Pity if it is the latter.
> 
> As the one who committed RLS to PostgreSQL, I'm hopeful that what we
> have is actually able to provide both.  There is a system inside of
> PostgreSQL for creating policies, which was a requirement of the PG
> community as we fully expect it to be used in non-SELinux environments,
> but there are also hooks available where a module (such as the sepgsql
> contrib module that's included with PG) could add its own restrictive
> and/or permissive policies.

Thanks, glad to hear that there are at least hooks available.

> I'm certainly interested in the type changes being discussed here and
> would love to work with someone from the SELinux community on improving
> the sepgsql contrib module (or, perhaps, adding a different and simpler
> module which is closer to a shim around SELinux than the existing
> sepgsql module).

Yes, the latter might be the best path.  It could use the newer
selinux_check_access() interface in libselinux for checking whether a
given permission is granted and avoid having to replicate or directly
use the lower level interfaces.

Re: postgresql policy

[Ted Toth]

In fact I'm using a variant of selinux_check_access in my
sepostgres_check_row_perm function that I called
selinux_check_access_noaudit since the select policy may naturally
fail perm checks on rows that are above the callers level and I don't
want generate audit storms.

On Thu, May 28, 2015 at 2:27 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 05/28/2015 03:09 PM, Stephen Frost wrote:
>> Stephen,
>>
>> * Stephen Smalley (sds@tycho.nsa.gov) wrote:
>>> On 05/28/2015 12:52 PM, Ted Toth wrote:
>>>> The ref policy contains a number of sepgsql_ types that are specific
>>>> to the sepgsql postgresql module. The sepgsql module was written to
>>>> support a postgresql security patch that was never accepted by the
>>>> upstream. Now postgresql has gone in a different direction security
>>>> wise adding row level security (RLS). I've been working on developing
>>>> RLS policy to label rows on insert and update and to check access
>>>> perms on select. I've tried using the sepgsql module in the RLS policy
>>>> but have come to the conclusion that because it was not designed for
>>>> this purpose it is not usable. So I'd like to suggest that these types
>>>> be moved out of the postgresql policy possibly into their own module
>>>> although I personally think they have little if any use.
>>>
>>> Should probably post a rfc patch to refpolicy list.
>>>
>>> On a different note, does this RLS implementation have any SELinux
>>> integration or is it just the typical "let's implement our own custom
>>> policy engine in the database manager and not link it in any way to the
>>> OS security model" approach?  Pity if it is the latter.
>>
>> As the one who committed RLS to PostgreSQL, I'm hopeful that what we
>> have is actually able to provide both.  There is a system inside of
>> PostgreSQL for creating policies, which was a requirement of the PG
>> community as we fully expect it to be used in non-SELinux environments,
>> but there are also hooks available where a module (such as the sepgsql
>> contrib module that's included with PG) could add its own restrictive
>> and/or permissive policies.
>
> Thanks, glad to hear that there are at least hooks available.
>
>> I'm certainly interested in the type changes being discussed here and
>> would love to work with someone from the SELinux community on improving
>> the sepgsql contrib module (or, perhaps, adding a different and simpler
>> module which is closer to a shim around SELinux than the existing
>> sepgsql module).
>
> Yes, the latter might be the best path.  It could use the newer
> selinux_check_access() interface in libselinux for checking whether a
> given permission is granted and avoid having to replicate or directly
> use the lower level interfaces.
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: postgresql policy

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]

Ted,

That certainly sounds like it makes a lot of sense.

Is that function available under RHEL 6.5, or just later versions?  I
know there has been a fair bit of work in this area.

Thanks!

* Ted Toth (txtoth@gmail.com) wrote:
> In fact I'm using a variant of selinux_check_access in my
> sepostgres_check_row_perm function that I called
> selinux_check_access_noaudit since the select policy may naturally
> fail perm checks on rows that are above the callers level and I don't
> want generate audit storms.
> 
> On Thu, May 28, 2015 at 2:27 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On 05/28/2015 03:09 PM, Stephen Frost wrote:
> >> Stephen,
> >>
> >> * Stephen Smalley (sds@tycho.nsa.gov) wrote:
> >>> On 05/28/2015 12:52 PM, Ted Toth wrote:
> >>>> The ref policy contains a number of sepgsql_ types that are specific
> >>>> to the sepgsql postgresql module. The sepgsql module was written to
> >>>> support a postgresql security patch that was never accepted by the
> >>>> upstream. Now postgresql has gone in a different direction security
> >>>> wise adding row level security (RLS). I've been working on developing
> >>>> RLS policy to label rows on insert and update and to check access
> >>>> perms on select. I've tried using the sepgsql module in the RLS policy
> >>>> but have come to the conclusion that because it was not designed for
> >>>> this purpose it is not usable. So I'd like to suggest that these types
> >>>> be moved out of the postgresql policy possibly into their own module
> >>>> although I personally think they have little if any use.
> >>>
> >>> Should probably post a rfc patch to refpolicy list.
> >>>
> >>> On a different note, does this RLS implementation have any SELinux
> >>> integration or is it just the typical "let's implement our own custom
> >>> policy engine in the database manager and not link it in any way to the
> >>> OS security model" approach?  Pity if it is the latter.
> >>
> >> As the one who committed RLS to PostgreSQL, I'm hopeful that what we
> >> have is actually able to provide both.  There is a system inside of
> >> PostgreSQL for creating policies, which was a requirement of the PG
> >> community as we fully expect it to be used in non-SELinux environments,
> >> but there are also hooks available where a module (such as the sepgsql
> >> contrib module that's included with PG) could add its own restrictive
> >> and/or permissive policies.
> >
> > Thanks, glad to hear that there are at least hooks available.
> >
> >> I'm certainly interested in the type changes being discussed here and
> >> would love to work with someone from the SELinux community on improving
> >> the sepgsql contrib module (or, perhaps, adding a different and simpler
> >> module which is closer to a shim around SELinux than the existing
> >> sepgsql module).
> >
> > Yes, the latter might be the best path.  It could use the newer
> > selinux_check_access() interface in libselinux for checking whether a
> > given permission is granted and avoid having to replicate or directly
> > use the lower level interfaces.
> >
> >
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: postgresql policy

[Ted Toth]

As per Mr. Smalleys suggestion I looked a back porting
selinux_check_access to the RHEL6 libselinux but I haven't done it yet
:(

On Thu, May 28, 2015 at 2:43 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Ted,
>
> That certainly sounds like it makes a lot of sense.
>
> Is that function available under RHEL 6.5, or just later versions?  I
> know there has been a fair bit of work in this area.
>
> Thanks!
>
> * Ted Toth (txtoth@gmail.com) wrote:
>> In fact I'm using a variant of selinux_check_access in my
>> sepostgres_check_row_perm function that I called
>> selinux_check_access_noaudit since the select policy may naturally
>> fail perm checks on rows that are above the callers level and I don't
>> want generate audit storms.
>>
>> On Thu, May 28, 2015 at 2:27 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > On 05/28/2015 03:09 PM, Stephen Frost wrote:
>> >> Stephen,
>> >>
>> >> * Stephen Smalley (sds@tycho.nsa.gov) wrote:
>> >>> On 05/28/2015 12:52 PM, Ted Toth wrote:
>> >>>> The ref policy contains a number of sepgsql_ types that are specific
>> >>>> to the sepgsql postgresql module. The sepgsql module was written to
>> >>>> support a postgresql security patch that was never accepted by the
>> >>>> upstream. Now postgresql has gone in a different direction security
>> >>>> wise adding row level security (RLS). I've been working on developing
>> >>>> RLS policy to label rows on insert and update and to check access
>> >>>> perms on select. I've tried using the sepgsql module in the RLS policy
>> >>>> but have come to the conclusion that because it was not designed for
>> >>>> this purpose it is not usable. So I'd like to suggest that these types
>> >>>> be moved out of the postgresql policy possibly into their own module
>> >>>> although I personally think they have little if any use.
>> >>>
>> >>> Should probably post a rfc patch to refpolicy list.
>> >>>
>> >>> On a different note, does this RLS implementation have any SELinux
>> >>> integration or is it just the typical "let's implement our own custom
>> >>> policy engine in the database manager and not link it in any way to the
>> >>> OS security model" approach?  Pity if it is the latter.
>> >>
>> >> As the one who committed RLS to PostgreSQL, I'm hopeful that what we
>> >> have is actually able to provide both.  There is a system inside of
>> >> PostgreSQL for creating policies, which was a requirement of the PG
>> >> community as we fully expect it to be used in non-SELinux environments,
>> >> but there are also hooks available where a module (such as the sepgsql
>> >> contrib module that's included with PG) could add its own restrictive
>> >> and/or permissive policies.
>> >
>> > Thanks, glad to hear that there are at least hooks available.
>> >
>> >> I'm certainly interested in the type changes being discussed here and
>> >> would love to work with someone from the SELinux community on improving
>> >> the sepgsql contrib module (or, perhaps, adding a different and simpler
>> >> module which is closer to a shim around SELinux than the existing
>> >> sepgsql module).
>> >
>> > Yes, the latter might be the best path.  It could use the newer
>> > selinux_check_access() interface in libselinux for checking whether a
>> > given permission is granted and avoid having to replicate or directly
>> > use the lower level interfaces.
>> >
>> >
>> > _______________________________________________
>> > Selinux mailing list
>> > Selinux@tycho.nsa.gov
>> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: postgresql policy

[Ted Toth]

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.

On Thu, May 28, 2015 at 1:54 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 05/28/2015 12:52 PM, Ted Toth wrote:
>> The ref policy contains a number of sepgsql_ types that are specific
>> to the sepgsql postgresql module. The sepgsql module was written to
>> support a postgresql security patch that was never accepted by the
>> upstream. Now postgresql has gone in a different direction security
>> wise adding row level security (RLS). I've been working on developing
>> RLS policy to label rows on insert and update and to check access
>> perms on select. I've tried using the sepgsql module in the RLS policy
>> but have come to the conclusion that because it was not designed for
>> this purpose it is not usable. So I'd like to suggest that these types
>> be moved out of the postgresql policy possibly into their own module
>> although I personally think they have little if any use.
>
> Should probably post a rfc patch to refpolicy list.
>
> On a different note, does this RLS implementation have any SELinux
> integration or is it just the typical "let's implement our own custom
> policy engine in the database manager and not link it in any way to the
> OS security model" approach?  Pity if it is the latter.
>
>

Re: postgresql policy

[Stephen Smalley]

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?

Re: postgresql policy

[Ted Toth]

Sorry these are in a module I've developed.

Ted

On Thu, May 28, 2015 at 2:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 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?

Re: postgresql policy

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]

Ted,

Any chance that module will be released under the PostgreSQL license
(BSD-like)?  We'd certainly like to see what those are doing and I do
wonder if we could use the hooks instead, if the SELinux community feels
that's a worthwhile approach.

Thanks!

* Ted Toth (txtoth@gmail.com) wrote:
> Sorry these are in a module I've developed.
> 
> Ted
> 
> On Thu, May 28, 2015 at 2:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > 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@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: postgresql policy

[Ted Toth]

Absolutely I'll share it when I'm happy with it.

Ted

On Thu, May 28, 2015 at 2:41 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Ted,
>
> Any chance that module will be released under the PostgreSQL license
> (BSD-like)?  We'd certainly like to see what those are doing and I do
> wonder if we could use the hooks instead, if the SELinux community feels
> that's a worthwhile approach.
>
> Thanks!
>
> * Ted Toth (txtoth@gmail.com) wrote:
>> Sorry these are in a module I've developed.
>>
>> Ted
>>
>> On Thu, May 28, 2015 at 2:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > 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@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: postgresql policy

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

Ted,

Fantastic, and certainly, makes sense.

Please let me know if there's anything I can do to help.

Thanks!

* Ted Toth (txtoth@gmail.com) wrote:
> Absolutely I'll share it when I'm happy with it.
> 
> Ted
> 
> On Thu, May 28, 2015 at 2:41 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > Ted,
> >
> > Any chance that module will be released under the PostgreSQL license
> > (BSD-like)?  We'd certainly like to see what those are doing and I do
> > wonder if we could use the hooks instead, if the SELinux community feels
> > that's a worthwhile approach.
> >
> > Thanks!
> >
> > * Ted Toth (txtoth@gmail.com) wrote:
> >> Sorry these are in a module I've developed.
> >>
> >> Ted
> >>
> >> On Thu, May 28, 2015 at 2:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >> > 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@tycho.nsa.gov
> >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: postgresql policy

[Christopher J. PeBenito]

On 5/28/2015 2:54 PM, Stephen Smalley wrote:
> On 05/28/2015 12:52 PM, Ted Toth wrote:
>> The ref policy contains a number of sepgsql_ types that are specific
>> to the sepgsql postgresql module. The sepgsql module was written to
>> support a postgresql security patch that was never accepted by the
>> upstream. Now postgresql has gone in a different direction security
>> wise adding row level security (RLS). I've been working on developing
>> RLS policy to label rows on insert and update and to check access
>> perms on select. I've tried using the sepgsql module in the RLS policy
>> but have come to the conclusion that because it was not designed for
>> this purpose it is not usable. So I'd like to suggest that these types
>> be moved out of the postgresql policy possibly into their own module
>> although I personally think they have little if any use.
> 
> Should probably post a rfc patch to refpolicy list.

Yes, it should be posted on the refpolicy list.  The short answer is
that I'd prefer to remove policy known to be unusable.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com