KaiGai Kohei wrote:
Andy Warner wrote:
KaiGai Kohei wrote:
The attached patch is the first one in the series of reworks for
the SE-PostgreSQL security policy.
It updates the following items.
* Changes in the definition of object classes
This patch add new three object classes and modifies the definition
of a few object classes.
- db_database:{get_param set_param} is removed due to nonsense.
- db_database:{superuser} is added to restrict privileges of
database superuser.
- db_table/db_column/db_tuple:{use} is removed due to nonsense.
- New object classes: db_catalog, db_schema and db_sequence are added.
I guess I should have asked before, is there is any proposed permission
set for the three new object classes mentioned above?
In the RUBIX policy I used the db_table use permission (could be called
open) to have a simple way to control access to the table as a whole,
much like a file open permission. While not absolutely necessary, I
think it is valuable. The other uses of the use permission I did not
use. Also, see my related comment below on the catalog/schema object
permissions.
It is incorrect use of use permission.
The use permission was used when we refer the table, but its contents
were not read directly, like:
SELECT count(*) FROM t WHERE x > 0;
This query refers the table t and column t.x, but its contents are
consumed by backend internally. But it was pointed out such kind of
discrimination is nonsense in pgsql-hackers.
If you need something like "open" permission on the db_table class,
what you should do is submitting a proposition for a new permission.
It is not a right way to apply existing one for another purpose.
If SE-PostgreSQL does not care about, it simply ignore the permission
like as db_catalog class.
I understand now and then the intent of the use permission. If I need
functionality from the database object classes that is not provided,
then I have little option other than use something in a way that is not
"correct". Such as my use of the dir object class to account for not
having object classes for schemata and catalog. And, from a user's
point of view, a permission called "use" works well with being to (or
not) use a table. So, I think it was quite reasonable to use it for my
purposes. I'm not sure what the official means of proposing a new
permission is, but I thought this thread was a discussion of any
changes that may need to made to the database policy, and since you are
removing the use permission, I thought it relevant. Call the permission
"use" or call if "open", the intent of my comment was to suggest that
policy support for the semantics of how I used the use permission would
be good.
In the previous design, we have the following object hierarchy:
[db_database]
+ [db_table]
| + [db_column]
| + [db_tuple]
+ [db_procedure]
+ [db_blob]
The newly added db_schema should be placed between the db_database and
the db_table and others. TYPE_TRANSITION rules follows the revised design.
[db_database]
+ [db_schema]
| + [db_table]
| | + [db_column]
| | + [db_tuple]
| + [db_procedure]
| + [db_sequence] (newly added object class)
+ [db_blob]
(*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
although it can be used to communicate channel between multiple
domains. So, it needs to be placed under the database.
Currently, SE-PostgreSQL does not use db_catalog class, but it can be
used for other DBMS's.
In addition, this patch changes something.
o The trusted procedure (sepgsql_trusted_proc_t) lost the
db_database:{superuser} privilege, because it is invoked by
unprived users to over the MAC restriction for a certain
purpose, but it does not need to allow superpower in DAC.
Is it intended that the superuser privilege give only DAC override or
both MAC and DAC? Specifically, is it intended to override MLS or Type
enforcement?
If the client does not have db_database:{superuser} privilege,
he cannot perform as database superuser, even if the DAC policy
allows. Please note that MAC stuff does not have a concept of
superuser. All the player need to be checked by the reference
monitor and its security policy.
o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
db_procedure:{install} privilege, because once installed procedure
as a system internal entity can be invoked implicitly.
We should not install trusted procedures for the purpose.
o The db_schema:{add_object remove_object} newly added are controled
via the "sepgsql_enable_users_ddl" boolean.
Now we control user's DDLs on uncategorized objects as row-level
checks on sepgsql_sysobj_t, but it can be revised with adding
db_schema object class.
I think this also needs the equivalent of a "search" permission (or
open, or use). This gives a nice way to control some access to an entire
schema. That is, we want to use the schema (and catalog) as a mechanism
to cut off users from entire subtrees. This helps to ensure that a user
does not gain access to a newly created subordinate object. So, if a
user does not have search for a schema (or catalog), there is no way
they can access any present or future object in that schema (or
catalog). Analogous to a directory. Without this search control I would
continue to use the dir object class.
This boolean controls the capability of DDL statement from unpriv
users. They should access existing objects via DML, even if they
cannot modify the definition of tables and so on.
I don't think your suggestion is correct one.
I think you misunderstood me. I was not commenting on the boolean at
all. I was commenting on the reference to "db_schema:{add_object
remove_object}" thinking (assuming) that add_object and remove_object
were the only two permission given to the db_schema object class. Is
this the intent? I did not see anywhere in the email that defined the
set of permissions the db_schema (or db_catalog) would have.
o type_transition for user_sepgsql_XXXX_t is moved to outside of
tunable_policy(`...'). IIRC, I said these should be inside of
the tunable, but unprive ones cannot create/drop tables labeled
as sepgsql_XXX_t anyway when the boolean is disabled.
So, I reconsidered it should be placed out of the tunable.
o {create drop setattr} permission for user_sepgsql_XXX is moved
to inside of the tunable_policy, even if it is db_procedure
class. I wonder why we didn't control CREATE FUNCTION statement
by unpriv domains.
o db_blob:{import export} on user_sepgsql_blob_t is allowed to
unpriv domains. It seems to me a strange behavior that it is
not allowed on the object created by unpriv domain itself.
* Remaining items
o When we allows an unpriv domain to access SE-PostgreSQL using
postgresql_unpriv_client(), its default labeling behavior is
same as unconfined domains. For example, functions created by
them are labeled as "sepgsql_proc_t".
Now I'm considering it should be user_sepgsql_XXXX_t, because
I would like to handle unprefixed types as an object created
by database administrator (unconfined domains).
It helps correctness of db_procedure:{install} permission.
o Because of db_schema object class, we can control user's DDLs
without ad-hoc using row-level security on sepgsql_sysobj_t
class. Now I think its purpose should be changed to prevent
users accesses system catalogs directly.
Are you implying here the need for something like a search or open
permissions as I suggested above? If so, please disregard my previous
comment:-)
Thanks,
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
|
