Re: [v9.1] sepgsql - userspace access vector cache

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 />