Andy Warner wrote:
>
>
> KaiGai Kohei wrote:
>> As I noted in the previous message, SE-PostgreSQL is postponed to
>> the PostgreSQL v8.5 after the long discussion in the pgsql-hackers
>> list, unfortunately.
>> However, it also mean a good chance to revise its design because
>> we have a few months before v8.5 development cycle launched.
>>
>> 1. Changes in object classes and access vectors
>> - add db_database:{superuser} permission
>>
>> - remove db_database:{get_param set_param} permission
>> - remove db_table/db_column/db_tuple:{use} permission
>>
>> Please refer the previous messages for them.
>>
>> - add new object class "db_schema"
>> As Andy noted, we directly put database objects under the
>> db_database class directly. But, some of database objects
>> are created under a schema object.
>> In other word, RDBMS's design has three level hierachy as:
>> <database> (<-- some DBMSs calls it as <catalog>)
>> + <schema>
>> + <tables>, <procedures>, ...
>>
>> Now, we control user's DDL statement via permissions on
>> the sepgsql_sysobj_t type as row-level controls.
>> But I think db_schema object class here is meaningful
>> to match SQL's design and analogy to the dir class.
>>
>> The new db_schema object class inherits six permissions
>> from common database objects, and defines three its own
>> permissions: add_object, remove_object, usage
>>
> I would suggest that the SQL catalog object should also be supported.
> Though not common in implementation, it is part of the SQL spec. Our
> DBMS (Trusted RUBIX) supports it, and for us it is basically another
> level in the naming. (database.catalog.schema.table). I would suggest
> that a db_catalog object be included with the same basic semantics as
> the db_schema object.
I wonder you are talking about same object in another name.
The "database" is the most gross level separation in PostgreSQL,
similar to catalog in your explanation.
When a user logs in PostgreSQL, he has to choose a "database" and
he cannot access any database object stored within another "database".
NOTE: PostgreSQL can handle several databases concurrently, but
a user can only one database in a database session.
> In our selinux policy, we encourage users to partition the database
> space up by catalog, where each catalog is "owned" by an selinux domain.
It is not correct design to port an idea of ownership in SELinux.
> Rules are then setup so that domain may create schemata, tables, etc.
> under that catalog.
The create permission should be checked on the newly created object
itself. For example, when a table is created with a security context
X_t, the client has to be allowed db_table:{create} on X_t.
> It provides a MAC security partitioning by catalog
> subtree, and allows the user to be able to logically create their own
> DBMS schema subtree according to personal needs, such as one schema per
> linux logon user, protected using the DAC policy. Of course, other
> security architectures are possible. But, my point is that the catalog
> object allows us to the this in a nice, modular way. Where, if we only
> had the schema to work with this would not be possible.
Is is not still possible, if you handle db_database class as the
object class to represent the catalog in RUBIX?
Thanks,
>> The former two permissions are checked when we create
>> or drop database object within the given schema.
>> The usage permission is checked when we use database
>> objects under the schema.
>>
>> - add new object class "db_sequence"
>> A secuence object enables to generate a set of sequencial
>> numbers to avoid confliction of key value.
>> We can set a value on the sequence, and others can fetch it.
>> It can be used as an information flow channel.
>>
>> The new db_sequence object class inherits six permissions
>> from common database objects, and defines two its own
>> permissions: get_value and set_value.
>>
>>
>> 2. System audit integration
>>
>> Now, SE-PostgreSQL writes out its access denied message into
>> the logfile of PostgreSQL (/var/log/sepostgresql.log).
>> But it is more desirable approach to write out them into system
>> audit mechanism, because any other SELinux related messages
>> are collected here and utilities like audit2allow is available.
>>
>> TODO:
>> - changes in the security policy:
>> We need to allow postgresql_t to write audit messages.
>> In addition, the backend process need to run with cap_audit_write.
>>
>> - a new interface in audit-libs:
>> The current audit-libs has the following interface.
>>
>> extern int audit_log_user_avc_message(int audit_fd, int type,
>> const char *message, const char *hostname, const char *addr,
>> const char *tty, uid_t uid);
>>
>> But some arguments are not meaningful in SE-PostgreSQL.
>> I would like to write out database role here, instead of tty and uid.
>>
>>
>> 3. Simplifies netlink loops
>>
>> SE-PostgreSQL needs to implement its own userspace AVC due to
>> some reasons. When the backend started up, it creates a worker
>> process to receive messages from in-kernel SELinux via netlink
>> socket. The worker process invalidates the userspace AVC of
>> all the instance of PostgreSQL backend process when the state
>> of SELinux is changed.
>>
>> However, I think the following loop to receive messages from
>> netlink socket should be provided via libselinux.
>>
>> http://code.google.com/p/sepgsql/source/browse/trunk/core/src/backend/security/sepgsql/avc.c#647
>>
>> If avc_netlink_loop() provided a callback function, I could push
>> the code into the libselinux.
>>
>> TODO:
>> - a set of new interface on libselinux:
>> I would like to add a few new interfaces to handle netlink socket
>> in libselinux, and expose them to application. I guess we can
>> write the existing standard avc with the interfaces.
>>
>>
>> 4. Permissive domain in userspace
>>
>> It is an issue got sleep for a few months.
>> http://marc.info/?l=selinux&m=122337314619667&w=2
>>
>>
>> 5. Handle unsupported object classes/access vectors
>>
>> What is the correct behavior for userspace object managers,
>> when it tries to check undefined object classes or access
>> vectors?
>>
>> For example, we don't define db_database:{superuser} in the
>> security policy. We cannot decide whether it is denied, or not.
>> How the SE-PostgreSQL should perform for this?
>>
>> In the current implementation, it simply ignores undefined
>> permissions because string_to_av_perm() cannot return a valid
>> access vector.
>>
>> One possible idea is it performs according to /selinux/deny_unknown.
>> If so, a new interface on libselinux is desirable.
>>
>>
>> Any comments are welcome.
>>
>> Thanks,
>>
>>
>> KaiGai Kohei wrote:
>>
>>> Andy Warner wrote:
>>>
>>>> Just a thought from working with the DBMS functionality within the
>>>> SELinux policy. Has there been any thought or talks about adding support
>>>> for catalog or schema objects? When I integrated the SELinux policy into
>>>> our DBMS I found them lacking and ended up using the dir object class,
>>>> as that closely mimicked our use of catalogs and schemata.
>>>>
>>>> Andy
>>>>
>>> Yes, I initially considered whether we should have "db_schema" object
>>> class or not, but concluded it is not needed strongly because of
>>> differences between two security models.
>>>
>>> When we create a new database object (like a table), PostgreSQL checks
>>> "create" privilege on the schema on which the table is placed.
>>> Meanwhile, SELinux checks "db_table:{create}" privilege on the table
>>> itself which has a security context. In other word, the schema works
>>> just a namespace from viewpoint of the SELinux design.
>>>
>>> However, I can understand the analogy which you pointed out.
>>> The "dir" object class has "add_name", "remove_name" and
>>> "search" permissions, similar to what the schema doing.
>>>
>>> Because the SE-PostgreSQL is postponed to get merged, we can fix
>>> its fundamental design in other words.
>>>
>>> Thanks,
>>>
>>>
>>>> KaiGai Kohei wrote:
>>>>
>>>>> Here is a bad news.
>>>>>
>>>>> I've had a discussion in pgsql-hackers list for a long time, but
>>>>> we cannot get a conclusion that SE-PostgreSQL should be merged
>>>>> in the PostgreSQL v8.4 which is the next major release, and it
>>>>> was postponed to the v8.5 development cycle due to lack of time
>>>>> for enough reviewing the feature.
>>>>>
>>>>> If it can be released on schedule, the v8.4 is released on the
>>>>> second quarter of 2009, and the v8.5 will be relased on a year
>>>>> later (but it tend to delay a few months).
>>>>> So, it is necessary to apply SE-PostgreSQL patches or install
>>>>> it from RPM package distributed via Fedora project. :(
>>>>>
>>>>> Under the discussion, I got a few suggestions in its security
>>>>> design, and it seems to me fair enough. Some of them needs to
>>>>> change definitions in the default policy.
>>>>>
>>>>> See the following items,
>>>>>
>>>>> * new permission: db_database:{superuser}
>>>>>
>>>>> They required a new permission to control database superuser
>>>>> privileges similar to "root" capability in operating system.
>>>>> The concept of superuser is common for some of major DBMSs,
>>>>> not only PostgreSQL. In addition, it seems to me well symmetric
>>>>> with operating system.
>>>>>
>>>>> The db_database:{superuser} controls whether the client can
>>>>> perform as database superuser on the given database, or not.
>>>>>
>>>>> * undesired permission: db_database:{set_param get_param}
>>>>>
>>>>> They wondered the necessity of these checks, because SQL spec
>>>>> does not require checks in set/get database parameters.
>>>>> I didn't think it is necessary the security design of SELinux
>>>>> should be symmetric with SQL, but I also thought these might
>>>>> be unnecessary due to another reason.
>>>>> In PostgreSQL, the scope of database parameters are session
>>>>> local and initialized on the connection startup, so we cannot
>>>>> use it as a pass to communicate between different two or more
>>>>> domains.
>>>>>
>>>>> * undesired permission: db_table/db_column/db_tuple:{use}
>>>>>
>>>>> I originally proposed the {use} permission to set up write-only
>>>>> tables, but it might be a misdesign.
>>>>> (Sorry, a bit long description.)
>>>>>
>>>>> At the initial design, SE-PostgreSQL applied {select} permission
>>>>> for all the refered tables, columns and tuples. But, it also means
>>>>> {select} permission is necessary for conditional DELETE or UPDATE
>>>>> even if its content is not exposed to the client.
>>>>> So, I proposed the privilege into two different permission: {select}
>>>>> and {use}. The {select} allows the client to refer the object and
>>>>> its content can be returned to him. The {use} also allows the client
>>>>> to refer the object but its content has to be consumed internally.
>>>>>
>>>>> Example)
>>>>> SELECT a, b FROM t WHERE c = 5;
>>>>> In this case, we need {select} on column t.a and t.b, but {use}
>>>>> is required on column t.c because its content is consumed by
>>>>> SE-PostgreSQL itself and not returned to the client.
>>>>>
>>>>> Example)
>>>>> UPDATE t SET x = 20 WHERE y = 'aaa';
>>>>> In this case, we need {update} on column t.x, and {use} on t.y,
>>>>> but {select} is not necessary.
>>>>>
>>>>> However, we can break it rapidly with a clever condition clause.
>>>>> For example, we can get a result from the first trial:
>>>>> DELETE FROM account WHERE userid = 100 and creditno like '1%';
>>>>>
>>>>> If this query removes a tuple, it means the first character of
>>>>> credit card number is '1'. If not so, he can try it 9 times.
>>>>> Then, he can get the information without {select} permission,
>>>>> with enough small number of trials.
>>>>>
>>>>> They concluded the "{use}" permission cannot work correctly, and
>>>>> danger to expect it does not allow to leak contexnt to the outside.
>>>>> I can agree this opinion.
>>>>>
>>>>>
>>>>> The attached patch add/remove these permissions.
>>>>> Any comments please.
>>>>>
>>>>> Thanks,
>>>>>
>>
>>
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
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.
