10
10
<para>
11
11
<filename>sepgsql</> is a loadable module which supports label-based
12
12
mandatory access control (MAC) based on <productname>SELinux</> security
13
- policy. This implementation is not complete, and primarily provides
14
- protection for Data Manipulation Language statements (DML). Support for
15
- fine-grained access control of Data Definition Language (DDL) and Data
16
- Control Language (DCL) statements may be added in a future release.
17
- </para>
18
- <para>
19
- This extension won't build at all unless the installation was configured
20
- with <literal>--with-selinux</>.
13
+ policy.
21
14
</para>
22
15
16
+ <warning>
17
+ <para>
18
+ This implementation has signification limitations, and does not enforce
19
+ mandatory access control for all actions. See
20
+ <xref linkend="sepgsql-limitations">.
21
+ </para>
22
+ </warning>
23
+
23
24
<sect2 id="sepgsql-overview">
24
25
<title>Overview</title>
25
26
59
60
<title>Installation</title>
60
61
61
62
<para>
62
- This module has several prerequisites.
63
+ This module can only be used on <productname>Linux</productname> 2.6.28
64
+ or higher with <productname>SELinux</productname> enabled. It is not
65
+ available on any other platform, and must be explicitly enabled using
66
+ <literal>--with-selinux</>. You will also need <productname>libselinux</>
67
+ 2.0.93 or higher and <productname>selinux-policy</> 3.9.13 or higher
68
+ (some distributions may backport the necessary rules into older policy
69
+ versions).
63
70
</para>
64
71
65
- <variablelist>
66
- <varlistentry>
67
- <term><productname>Linux kernel</productname></term>
68
- <listitem>
69
- <para>
70
- v2.6.28 or later with built with SELinux enabled
71
- </para>
72
- </listitem>
73
- </varlistentry>
74
- <varlistentry>
75
- <term><productname>libselinux</productname></term>
76
- <listitem>
77
- <para>
78
- v2.0.93 or later
79
- </para>
80
- <para>
81
- This library provides a set of APIs to communicate with
82
- <productname>SELinux</> in kernel.
83
- </para>
84
- </listitem>
85
- </varlistentry>
86
- <varlistentry>
87
- <term><productname>selinux-policy</productname></term>
88
- <listitem>
89
- <para>
90
- v3.9.13 or later
91
- </para>
92
- <para>
93
- The default security policy provides a set of access control rules.
94
- Some distributions may backport necessary rules to older policy versions.
95
- </para>
96
- </listitem>
97
- </varlistentry>
98
- </variablelist>
99
72
<para>
100
-
101
- <productname>sepgsql</> needs <productname>SELinux</> being
102
- available on the platform. You can check the current setting using
103
- <command>sestatus</>.
73
+ The <command>sestatus</> command allows you to check the status of
74
+ <productname>SELinux</productname>.
104
75
<screen>
105
76
$ sestatus
106
77
SELinux status: enabled
@@ -115,41 +86,25 @@ Policy from config file: targeted
115
86
</para>
116
87
117
88
<para>
118
- At compile time, pass the <literal>--with-selinux</> option to
119
- the <command>configure</> script to enable this module.
120
-
121
- <screen>
122
- $ ./configure --enable-debug --enable-cassert --with-selinux
123
- $ make
124
- $ make install
125
- </screen>
126
- </para>
127
-
128
- <para>
129
- Following <command>initdb</>, add <literal>'$libdir/sepgsql'</>
130
- to <xref linkend="guc-shared-preload-libraries"> in
131
- the <filename>postgresql.conf</>. Note that <productname>sepgsql</>
132
- must be loaded at server startup.
89
+ To use this module, you must add include <literal>sepgsql</>
90
+ in <xref linkend="guc-shared-preload-libraries">. The module will not
91
+ function if loaded in any other manner. Once the module is loaded, you
92
+ should execute <filename>sepgsql.sql</filename> in each database.
93
+ This will install functions needed for security label management, and
94
+ assign initial security labels.
133
95
</para>
134
96
135
97
<para>
136
- Next, load the <filename>sepgsql.sql</filename> script for each database.
137
- It installs functions for security label management, and attempts to assign
138
- initial labels to the target objects.
139
- </para>
140
-
141
- <para>
142
- The following instruction assumes your installation is under the
143
- <filename>/usr/local/pgsql</> directory, and the database cluster is in
144
- <filename>/usr/local/pgsql/data</>. Adjust the paths shown below as
98
+ The following instructions that assume your installation is under the
99
+ <filename>/usr/local/pgsql</> directory. Adjust the paths shown below as
145
100
appropriate for your installaton.
146
101
</para>
147
102
148
103
<screen>
149
- $ initdb -D $PGDATA
104
+ $ initdb
150
105
$ vi $PGDATA/postgresql.conf
151
106
$ for DBNAME in template0 template1 postgres; do
152
- postgres --single -F -O -c exit_on_error=true -D $PGDATA $DBNAME \
107
+ postgres --single -F -O -c exit_on_error=true $DBNAME \
153
108
< /usr/local/pgsql/share/contrib/sepgsql.sql > /dev/null
154
109
done
155
110
</screen>
@@ -317,77 +272,15 @@ $ restorecon -R /usr/local/pgsql/
317
272
A new database object basically inherits the security label of the parent
318
273
object, except when the security policy has special rules known as
319
274
type-transition rules, in which case a different label may be applied.
320
- The meaning of the term "parent object" varies by object class, as follows.
275
+ For schemas, the parent object is the current database; for columns, it
276
+ is the corresponding table; for tables, sequences, views, and functions,
277
+ it is the containing schema.
321
278
</para>
322
-
323
- <variablelist>
324
- <varlistentry>
325
- <term>schema</term>
326
- <listitem>
327
- <para>
328
- The parent object is the current database.
329
- </para>
330
- </listitem>
331
- </varlistentry>
332
- <varlistentry>
333
- <term>table</term>
334
- <listitem>
335
- <para>
336
- The parent object is the containing schema.
337
- </para>
338
- </listitem>
339
- </varlistentry>
340
- <varlistentry>
341
- <term>column</term>
342
- <listitem>
343
- <para>
344
- The parent object is the table.
345
- </para>
346
- </listitem>
347
- </varlistentry>
348
- <varlistentry>
349
- <term>sequence</term>
350
- <listitem>
351
- <para>
352
- The parent object is the containing schema.
353
- </para>
354
- </listitem>
355
- </varlistentry>
356
- <varlistentry>
357
- <term>view</term>
358
- <listitem>
359
- <para>
360
- The parent object is the containing schema.
361
- </para>
362
- </listitem>
363
- </varlistentry>
364
- <varlistentry>
365
- <term>function</term>
366
- <listitem>
367
- <para>
368
- The parent object is the containing schema.
369
- </para>
370
- </listitem>
371
- </varlistentry>
372
- </variablelist>
373
279
</sect3>
280
+
374
281
<sect3>
375
282
<title>DML Permissions</title>
376
283
377
- <para>
378
- This section introduces what permissions shall be checked on DML;
379
- <literal>SELECT</>, <literal>INSERT</>, <literal>UPDATE</> and
380
- <literal>DELETE</>.
381
- </para>
382
-
383
- <para>
384
- DML statements are used to reference or modify contents within
385
- the specified database objects; such as tables or columns.
386
- The access rights of the client are checked on all the objects
387
- mentioned in the given statement, and the kind of privileges checked
388
- depend on the class of the object and the type of access.
389
- </para>
390
-
391
284
<para>
392
285
For tables, <literal>db_table:select</>, <literal>db_table:insert</>,
393
286
<literal>db_table:update</> or <literal>db_table:delete</> is
@@ -461,7 +354,6 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
461
354
</para>
462
355
463
356
<para>
464
- Here are a few more corner cases.
465
357
The default database privilege system allows database superusers to
466
358
modify system catalogs using DML commands, and reference or modify
467
359
toast tables. These operations are prohibited when
@@ -545,13 +437,13 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
545
437
<sect3>
546
438
<title>Miscellaneous</title>
547
439
<para>
548
- In this version, we reject the <xref linkend="sql-load"> command across
549
- the board, because any module loaded could easily circumvent security
550
- policy enforcement.
440
+ We reject the <xref linkend="sql-load"> command across the board, because
441
+ any module loaded could easily circumvent security policy enforcement.
551
442
</para>
552
443
553
444
</sect3>
554
445
</sect2>
446
+
555
447
<sect2 id="sepgsql-limitations">
556
448
<title>Limitations</title>
557
449
@@ -649,7 +541,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
649
541
<sect2 id="sepgsql-author">
650
542
<title>Author</title>
651
543
<para>
652
- KaiGai Kohei ( <email>kaigai@ak.jp.nec.com</email>)
544
+ KaiGai Kohei <email>kaigai@ak.jp.nec.com</email>
653
545
</para>
654
546
</sect2>
655
547
</sect1>
0 commit comments