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@xxxxxxxxx) 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@xxxxxxxxxxxxx> wrote: > > On 05/28/2015 03:09 PM, Stephen Frost wrote: > >> Stephen, > >> > >> * Stephen Smalley (sds@xxxxxxxxxxxxx) 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@xxxxxxxxxxxxx > > To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. > > To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ 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.
