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@xxxxxxxxxxx> 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@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. _______________________________________________ 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.
