From ea2c2641f908cde198a9999100d847078a05385b Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Mon, 24 Jan 2011 08:42:44 -0500 Subject: [PATCH] More documentation cleanup for sepgsql. Thom Brown and Robert Haas --- doc/src/sgml/sepgsql.sgml | 96 +++++++++++++++++++-------------------- 1 file changed, 46 insertions(+), 50 deletions(-) diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml index d95d121f4b..7b56506195 100644 --- a/doc/src/sgml/sepgsql.sgml +++ b/doc/src/sgml/sepgsql.sgml @@ -307,14 +307,14 @@ $ restorecon -R /usr/local/pgsql/ Currently, sepgsql allows security labels to be assigned to schemas, tables, columns, sequences, views, and functions. When sepgsql is in use, security labels are - automatically assigned to suppoted database objects at creation time. + automatically assigned to supported database objects at creation time. This label is called as a default security label, being decided according to the system security policy, which takes as input the creator's label and the label assigned to the new object's parent object. - A new database object basically inherits security label of the parent + A new database object basically inherits the security label of the parent object, except when the security policy has special rules known as type-transition rules, in which case a different label may be applied. The meaning of the term "parent object" varies by object class, as follows. @@ -365,7 +365,7 @@ $ restorecon -R /usr/local/pgsql/ function - Its parent object is the containing schema. + The parent object is the containing schema. @@ -383,7 +383,7 @@ $ restorecon -R /usr/local/pgsql/ DML statements are used to reference or modify contents within the specified database objects; such as tables or columns. - We basically checks access rights of the client on all the objects + The access rights of the client are checked on all the objects mentioned in the given statement, and the kind of privileges checked depend on the class of the object and the type of access. @@ -391,10 +391,10 @@ $ restorecon -R /usr/local/pgsql/ For tables, db_table:select, db_table:insert, db_table:update or db_table:delete is - checked for all the appeared target tables depending on the sort of + checked for all the referenced target tables depending on the sort of statement; in addition, db_table:select is also checked for - all the tables that containin the columns to be referenced in + all the tables that contain the columns referenced in the WHERE or RETURNING clause, as a data source of UPDATE, and so on. @@ -404,23 +404,23 @@ $ restorecon -R /usr/local/pgsql/ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; - In this case, we must have db_table:select, not only + In this case, we must have db_table:select in addition to db_table:update, because t1.a is referenced - within WHERE clause. Column-level permissions will be - checked as well, for each referenced column. + within the WHERE clause. Column-level permissions will also be + checked for each referenced column. - The client must be allowed to reference all the appeared tables and - columns, even if they are originated from views then expanded, because we - intend to apply consistent access control rules independent from the - manner in which the table contents are referenced. + The client must be allowed to access all referenced tables and + columns, even if they originated from views which were then expanded, + so that we apply consistent access control rules independent of the manner + in which the table contents are referenced. For columns, db_column:select is checked on not only the columns being read using SELECT, but being - referenced in other DML statement. + referenced in other DML statements. @@ -438,16 +438,15 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; on the t1.y being updated and referenced, and db_column:select on the t1.z being only referenced in the WHERE clause. - Also note that db_table:{select update} shall be checked - in the table-level granularity. + db_table:{select update} will also be checked + at the table level. - For sequences, db_sequence:get_value when we reference - a sequence object using SELECT; however, note that we - cannot check permissions on execution of corresponding functions - such as lastval() right now, although they performs same - job, because here is no object access hook to acquire controls. + For sequences, db_sequence:get_value is checked when we + reference a sequence object using SELECT; however, note that we + do not currently check permissions on execution of corresponding functions + such as lastval(). @@ -462,7 +461,7 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; - Here is a few more corner cases. + Here are a few more corner cases. The default database privilege system allows database superusers to modify system catalogs using DML commands, and reference or modify toast tables. These operations are prohibited when @@ -480,30 +479,24 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; - In a case when multiple label providers are installed and user tries + In the case where multiple label providers are installed and the user tries to set a security label, but is not managed by SELinux, only setattr should be checked here. - This is currently not done due to implementation restrictions. + This is currently not checked due to implementation restrictions. Trusted Procedure - It is a similar idea to security definer functions or set-uid commands - on operating systems. SELinux provides a feature to - switch privilege of the client (that is a security label of the client - for more correctness) during execution of certain functions; being - called as trusted procedures. - - - - A trusted function is a function with a special security label being - set up as a trusted procedure. - So, we need to assign the special security label on the function that - we hope it to perform as a trusted procedure, by administrative users. - The default security policy also provides this special security label. - See the following example. + Trusted procedures are similar to security definer functions or set-uid + commands. SELinux provides a feature to allow trusted + code to run using a security label different from that of the client, + generally for the purpose of providing highly controlled access to + sensitive data (e.g. rows might be omitted, or the precision of stored + values might be reduced). Whether or not a function acts as a trusted + procedure is controlled by its security label and the operating system + security policy. For example: @@ -527,7 +520,7 @@ SECURITY LABEL - Above operations shall be done by administrative users. + The above operations should be performed by an administrative user. @@ -544,14 +537,15 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; In this case, a regular user cannot reference customer.credit directly, but a trusted procedure show_credit enables us - to print credit number of customers with a bit modification. + to print the credit card number of customers with some of the digits masked + out. Miscellaneous - In this version, we reject command across + In this version, we reject the command across the board, because any module loaded could easily circumvent security policy enforcement. @@ -605,10 +599,12 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; sepgsql never tries to hide existence of - a certain object, even if user is not allowed to reference. - For example, we can infer an existence of invisible object using - primary-key confliction, foreign-key violation, and so on, even if - we cannot reference contents of these objects. + a certain object, even if the user is not allowed to the reference. + For example, we can infer the existence of an invisible object as + a result of primary key conflicts, foreign key violations, and so on, + even if we cannot reference contents of these objects. The existence + of a top secret table cannot be hidden; we only hope to conceal its + contents. @@ -623,7 +619,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; This wiki page provides a brief-overview, security design, architecture, - administration and upcoming feature for more details. + administration and upcoming features. @@ -631,9 +627,9 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; Fedora SELinux User Guide - This document provides wide spectrum of knowledge to administer + This document provides a wide spectrum of knowledge to administer SELinux on your systems. - It primary focuses on Fedora, but is not limited to Fedora. + It focuses primarily on Fedora, but is not limited to Fedora. @@ -641,9 +637,9 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; Fedora SELinux FAQ - This document answers frequently asked questins about + This document answers frequently asked questions about SELinux. - It primary focuses on Fedora, but is not limited to Fedora. + It focuses primarily on Fedora, but is not limited to Fedora. -- GitLab