Re: [v9.1] sepgsql - userspace access vector cache - Mailing list pgsql-hackers
From | Yeb Havinga |
---|---|
Subject | Re: [v9.1] sepgsql - userspace access vector cache |
Date | |
Msg-id | 4E2450C3.4030508@gmail.com Whole thread Raw |
In response to | Re: [v9.1] sepgsql - userspace access vector cache (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Responses |
Re: [v9.1] sepgsql - userspace access vector cache
|
List | pgsql-hackers |
Hello KaiGai-san,<br /><br /> I've been preparing to review this patch by reading both pgsql-hackers history on sepgsql,and also the RHEL 6 guide on SELinux this weekend, today I installed GIT HEAD with --with-selinux on Scientific Linux6, developer installation, so far almost everything looking good.<br /><br /> These things should probably be addedto the 9.1beta3 documentation branch:<br /><br /> 1) the line with for DBNAME in ... do postgres --single etc, lacksa -D argument and hence gives the error:<br /> postgres does not know where to find the server configuration file.<br/><br /> 2) there is a dependency to objects outside of the postgresql installation tree in /etc/selinux/targeted/contexts/sepgsql_contexts,and that file has an error that is thrown when contrib/sepgsql is executed:<br/> /etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid object type db_blobs<br /> (same fordb_language)<br /> I found your fix for the error on a forum on oss.tresys.com, but IMHO either the contrib/sepgsql shouldmention that the dependency exists and it might contain errors for (older) reference policies, or it should includea bugfree reference policy for sepgsql to replace the system installed refpolicy with (and mention that in the installdocumentation).<br /><br /> 3) sepgsql is currently a bit hard to find in the documentation. <a class="moz-txt-link-abbreviated"href="http://www.postgresql.org">www.postgresql.org</a> website search doesn't find sepgsqland selinux only refers to an old PostgreSQL redhat bug in 2005 on bugzilla.redhat.com. I had to manually rememberit was a contrib module. Also sepgsql isn't linked to at the SECURITY LABEL page. At the moment I'm unsure if I haveseen all sepgsql related sgml-based documentation.<br /><br /> After fixing the refpolicy I proceeded with the contrib/sepgsqlmanual, with the goal to get something easy done, like create a top secret table like 'thisyearsbonusses',and a single user 'boss' and configure sepgsql in such a way that only the boss can access the top secrettable. I've read the the contrib documentation, browsed links on the bottom of the page but until now I don't evenhave a clue how to proceed. Until I do so, I don't feel it's appropriate for me to review the avc patch.<br /><br />Would you be willing to help me getting a bit started? Specific questions are:<br /><br /> 1) The contrib doc under DMLpermissions talks about 'db_table:select' etc? What are these things? They are not labels since I do not see them listedin the output of 'select distinct label from pg_seclabel'.<br /><br /> 2) The regression test label.sql introduceslabels with types sepgsql_trusted_proc_exec_t, sepgsql_ro_table_t. My question is: where are these defined? Whatis their meaning? Can I define my own?<br /><br /> 3) In the examples so far I've seen unconfined_u and system_u? CanI define my own?<br /><br /> Thanks,<br /> Yeb Havinga<br /><br /><br /> On 2011-07-14 21:46, Kohei KaiGai wrote: <blockquotecite="mid:CADyhKSUUr9VrX6jUBPrd6nXRzNq+X8EAa1Y63HGreL8wgSUjJw@mail.gmail.com" type="cite"><pre wrap="">Sorry,the syscache part was mixed to contrib/sepgsql part in my previous post. Please see the attached revision. Although its functionality is enough simple (it just reduces number of system-call invocation), its performance improvement is obvious. So, I hope someone to volunteer to review these patches. Thanks, 2011/7/11 Kohei KaiGai <a class="moz-txt-link-rfc2396E" href="mailto:kaigai@kaigai.gr.jp"><kaigai@kaigai.gr.jp></a>: </pre><blockquote type="cite"><pre wrap="">I rebased the userspace access vector cache patch to the latest tree. I'll describe the background of this patch because this thread has not been active more than a week. The sepgsql asks in-kernel selinux when it needs to make its access control decison, so it always causes system call invocations. However, access control decision of selinux for a particular pair of security label is consistent as long as its security policy is not reloaded. Thus, it is a good idea to cache access control decisions recently used in userspace. In addition, current GetSecurityLabel() always open pg_seclabel catalog and scan to fetch security label of database objects, although it is a situation we can utilize syscache mechanism. The "uavc-syscache" patch adds a new SECLABELOID syscache. It also redefine pg_seclabel.provide as Name, instead of Text, according to the suggestion from Tom. (To avoid collation conscious datatype) The "uavc-selinux-cache" patch adds cache mechanism of contrib/sepgsql. Its internal api to communicate with selinux (sepgsql_check_perms) was replaced by newer sepgsql_avc_check_perms that checks cached access control decision at first, prior to system call invocations. The result of performance improvement is obvious. * Test 2. time to run 50,000 of SELECT from empty tables selinux | SECLABELOID syscache avc | without | with ---------+----------------------- without | 185.59[s] | 178.38[s] ---------+----------------------- with | 23.58[s] | 21.79[s] ---------+----------------------- I strongly hope this patch (and security label support on shared objects) to get unstreamed in this commit-fest, because it will perform as a basis of other upcoming features. Please volunteer the reviewing! Thanks, 2011/7/2 Kohei KaiGai <a class="moz-txt-link-rfc2396E" href="mailto:kaigai@kaigai.gr.jp"><kaigai@kaigai.gr.jp></a>: </pre><blockquote type="cite"><pre wrap="">The attached patch re-defines pg_seclabel.provider as NameData, instead of Text, and revert changes of catcache.c about collations; to keep consistency with the security label support on shared objects. All the format changes are hidden by (Get|Set)SecurityLabel(), so no need to change on the patch to contrib/sepgsql. Thanks, 2011/6/13 Kohei KaiGai <a class="moz-txt-link-rfc2396E" href="mailto:kaigai@kaigai.gr.jp"><kaigai@kaigai.gr.jp></a>: </pre><blockquote type="cite"><pre wrap="">2011/6/13 Robert Haas <a class="moz-txt-link-rfc2396E" href="mailto:robertmhaas@gmail.com"><robertmhaas@gmail.com></a>: </pre><blockquote type="cite"><pre wrap="">On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai <a class="moz-txt-link-rfc2396E"href="mailto:kaigai@kaigai.gr.jp"><kaigai@kaigai.gr.jp></a> wrote: </pre><blockquote type="cite"><pre wrap="">For syscache, length of a typical security label in selinux is less than 64 bytes. If we assume an entry consume 128bytes including Oid pairs or pointers, its consumption is 128KBytes per 1,000 of tables or others. (Do we have a way to confirm syscache status?) </pre></blockquote><pre wrap=""> I was thinking you might start a new session, SELECT pg_backendd_pid() to get the PID, use top/ps to get its memory usage; then do a bunch of stuff and see how much it's grown. The difference between how much it grows with and without the patch is the amount of additional memory the patch consumes. </pre></blockquote><pre wrap="">I checked memory consumption of the backend with / without patches. Because sepgsql_restorecon() tries to reset security label of all the schemas, relations, columns and procedures, an execution of this function is suitable to emphasize differences between two cases in maximum. The results shows us about 3MB of additional consumption in VmRSS, even if it caches all the security label of the objects being created in the default (3331 entries). * without patches before/after sepgsql_restorecon() VmPeak: 150812 kB -> 170864 kB VmSize: 150804 kB -> 154712 kB VmLck: 0 kB -> 0kB VmHWM: 3800 kB -> 22248 kB VmRSS: 3800 kB -> 10620 kB VmData: 1940 kB -> 5820 kB VmStk: 196 kB -> 196 kB VmExe: 5324 kB -> 5324 kB VmLib: 2468 kB -> 2468 kB VmPTE: 108 kB -> 120 kB VmSwap: 0 kB -> 0kB * with patches before/after sepgsql_restorecon() VmPeak: 150816 kB -> 175092 kB VmSize: 150808 kB -> 158804 kB VmLck: 0 kB -> 0 kB VmHWM: 3868 kB -> 25956 kB VmRSS: 3868 kB -> 13736 kB VmData: 1944 kB -> 9912 kB VmStk: 192 kB -> 192 kB VmExe: 5324 kB -> 5324 kB VmLib: 2472 kB -> 2472 kB VmPTE: 100 kB -> 124 kB VmSwap: 0 kB -> 0 kB Thanks, -- KaiGai Kohei <a class="moz-txt-link-rfc2396E" href="mailto:kaigai@kaigai.gr.jp"><kaigai@kaigai.gr.jp></a> </pre></blockquote><pre wrap=""> -- KaiGai Kohei <a class="moz-txt-link-rfc2396E" href="mailto:kaigai@kaigai.gr.jp"><kaigai@kaigai.gr.jp></a> </pre></blockquote><pre wrap=""> -- KaiGai Kohei <a class="moz-txt-link-rfc2396E" href="mailto:kaigai@kaigai.gr.jp"><kaigai@kaigai.gr.jp></a> </pre></blockquote><pre wrap=""> </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> </pre></blockquote><br /><br />
pgsql-hackers by date: