@@ -192,9 +192,9 @@ sepgsql-regtest 1.04
192192
193193 <para>
194194 Third, turn on <literal>sepgsql_regression_test_mode</>.
195- We don't enable all the rules in <filename>sepgsql-regtest</>
196- by default, for your system's safety.
197- The <literal>sepgsql_regression_test_mode</literal> parameter enables
195+ For security reasons, the rules in <filename>sepgsql-regtest</>
196+ are not enabled by default;
197+ the <literal>sepgsql_regression_test_mode</literal> parameter enables
198198 the rules needed to launch the regression tests.
199199 It can be turned on using the <command>setsebool</> command:
200200 </para>
@@ -415,43 +415,38 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
415415 <title>DDL Permissions</title>
416416 <para>
417417 <productname>SELinux</> defines several permissions to control common
418- operations for each objecttypes ; such as creation, alter, drop and
419- relabel of security label. In addition, several object typeshas its
420- special permissions to controlits characteristic operations; such as
421- addition or deletion of name entriesunderlying a particular schema.
418+ operations for each objecttype ; such as creation, alter, drop and
419+ relabel of security label. In addition, several object typeshave
420+ special permissions to controltheir characteristic operations; such as
421+ addition or deletion of name entrieswithin a particular schema.
422422 </para>
423423 <para>
424- When <literal>CREATE</> command is executed, <literal>create</> will
424+ Whena <literal>CREATE</> command is executed, <literal>create</> will
425425 be checked on the object being constructed for each object types.
426- A default security labelshall be assignedon the new database object,
427- and the <literal>create</> permissionneeds to beallowed on the pair
426+ A default security labelwill be assignedto the new database object,
427+ and the <literal>create</> permissionwill bechecked on the pair
428428 of security label of the client and the new object itself.
429- We consider <xref linkend="sql-createtable"> construct a table and
430- underlying columns at the same time, so it requires userspermission
431- to create bothof table and columns.
429+ We consider <xref linkend="sql-createtable">to construct a table and
430+ underlying columns at the same time, so it requiresthe usersto have
431+ permission to create boththe table and its columns.
432432 </para>
433433 <para>
434434 A few additional checks are applied depending on object types.
435435 On <xref linkend="sql-createdatabase">, <literal>getattr</> permission
436- shall be checked on the source or template database of the new database,
436+ will be checked on the source or template database of the new database,
437437 not only <literal>create</> on the new database.
438- On creation of objectsunderlying a particula schema (tables, views,
439- sequences and procedures), <literal>add_name</>shall be also chechked
438+ On creation of objectswithin a particula schema (tables, views,
439+ sequences and procedures), <literal>add_name</>will be also chechked
440440 on the schema, not only <literal>create</> on the new object itself.
441441 </para>
442442
443443 <para>
444444 When <literal>DROP</> command is executed, <literal>drop</> will be
445- checked on the object being removed for each object types.
446- Please note that it shall not be checked on the objects removed by
447- cascaded deletion according to the standard manner in SQL.
448- </para>
449- <para>
450- A few additional checks are applied depending on object types.
451- On deletion of objects underlying a particula schema (tables, views,
452- sequences and procedures), <literal>remove_name</> shall be also checked
453- on the schema, not only <literal>drop</> on the object being removed
454- itself.
445+ checked on the object being removed for each object types. Permissions
446+ will not be checked for objects dropped indirectly via <literal>CASCADE</>.
447+ Deletion of objects contained within a particular schema (tables, views,
448+ sequences and procedures) additionally requires
449+ <literal>remove_name</> on the schema.
455450 </para>
456451
457452 <para>
@@ -526,22 +521,22 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
526521 </sect3>
527522
528523 <sect3>
529- <title>Dynamicdomain transitions </title>
524+ <title>DynamicDomain Transitions </title>
530525 <para>
531526 It is possible to use SELinux's dynamic domain transition feature
532527 to switch the security label of the client process, the client domain,
533528 to a new context, if that is allowed by the security policy.
534- The client domain needs the' setcurrent' permission and also
535- ' dyntransaction' from the old to the new domain.
529+ The client domain needs the<literal> setcurrent</> permission and also
530+ <literal> dyntransaction</> from the old to the new domain.
536531 </para>
537532 <para>
538- Dynamic domain transitions should be considered carefully, becauseit
539- means we allows users to switch their label (also peforms a set of
540- privileges in SELinux model) inarbitrary way, unlike regular
541- mandatory way such as trusted procedures .
542- Thus,The dyntransition permission is only considered safe when used
543- to switch to a domain with a smaller set of privileges than the
544- original one, for example:
533+ Dynamic domain transitions should be considered carefully, becausethey
534+ allow users to switch their label, and therefore their privileges, in
535+ at their option, rather than (as inthe case of a trusted procedure)
536+ as mandated by the system .
537+ Thus,the <literal> dyntransition</literal> permission is only considered
538+ safe when used to switch to a domain with a smaller set of privileges than
539+ the original one. For example:
545540 </para>
546541<screen>
547542regression=# select sepgsql_getcon();
@@ -561,29 +556,29 @@ ERROR: SELinux: security policy violation
561556</screen>
562557 <para>
563558 In this example above we were allowed to switch from the larger MCS
564- range c1.c1023 to the smaller range c1.c4, but switching back was
565- denied.
559+ range<literal> c1.c1023</> to the smaller range<literal> c1.c4</> , but
560+ switching back was denied.
566561 </para>
567562 <para>
568563 A combination of dynamic domain transition and trusted procedure
569- enables an interesting use case that fits typical process life-
564+ enables an interesting use case that fitsthe typical process life-
570565 cycle of connection pooling software.
571566 Even if your connection pooling software is not allowed to run most
572- of SQL commands,it shall be available to switch the security label
573- of the client using <literal>sepgsql_setcon()</literal> function
574- to be invoked inside of the trusted procedure; that should take some
567+ of SQL commands,you can allow it to switch the security label
568+ of the client usingthe <literal>sepgsql_setcon()</literal> function
569+ from within a trusted procedure; that should take some
575570 credential to authorize the request to switch the client label.
576- After that, this sessionperforms with privileges of theuser being
577- switched, but it shall be unavailable to reference database objects
578- labeled as other user's one.
579- Then, it can revert the security label alsp using
580- <literal>sepgsql_setcon() </literal>with <literal>NULL</literal>
581- argument, unless the security policy prevent it .
582- Thepoints of this use case are the trusted procedureis only way
583- for theconnection pooling software to switch security label of
584- the clinet, and the trusted procedure does not work without
585- appropriate credentials. In addition, it is also a point that the
586- table to store credentials is only visible from trusted procedure .
571+ After that, this sessionwill have the privileges of thetarget user,
572+ rather than the connection pooler.
573+ The connection pooler can later revert the security label change by
574+ again using <literal>sepgsql_setcon()</literal> with
575+ <literal>NULL </literal>argument, again invoked from within a trusted
576+ procedure with appropriate permissions checks .
577+ Thepoint here is that only the trusted procedureactually has permission
578+ to change theeffective security label, and only does so when given proper
579+ credentials. Of course, for secure operation, the credential store must
580+ (table, procedure definition, or whatever) must be protected from
581+ unauthorized access .
587582 </para>
588583 </sect3>
589584
@@ -618,8 +613,8 @@ ERROR: SELinux: security policy violation
618613 <entry>
619614 Switches the client domain of the current session to the new domain,
620615 if allowed by the security policy.
621- It also accepts <literal>NULL</literal> input, and it shall be
622- considered as a transition to the originalone .
616+ It also accepts <literal>NULL</literal> input as a request to transition
617+ to theclient's originaldomain .
623618 </entry>
624619 </row>
625620 <row>
@@ -655,8 +650,8 @@ ERROR: SELinux: security policy violation
655650 <term>Data Definition Language (DDL) Permissions</term>
656651 <listitem>
657652 <para>
658- Due to implementation restrictions, someof DDLpermissions are not
659- checked .
653+ Due to implementation restrictions, some DDLoperations do not
654+ check permissions .
660655 </para>
661656 </listitem>
662657 </varlistentry>
@@ -665,7 +660,8 @@ ERROR: SELinux: security policy violation
665660 <term>Data Control Language (DCL) Permissions</term>
666661 <listitem>
667662 <para>
668- Due to implementation restrictions, DCL permissions are not checked.
663+ Due to implementation restrictions, DCL operations do not check
664+ permissions.
669665 </para>
670666 </listitem>
671667 </varlistentry>