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.
