Andy Warner wrote: >>> So, based upon the above I would say that PostgreSQL's database object >>> (as well as RUBIX's) is analogous to the cluster. I think database is a >>> much more common term. Based upon the fact that SQL and ODBC (JDBC?) >>> provide support for directly accessing DBMS objects (e.g., in a select >>> statement) using the catalog and schema (but not database), I would >>> still propose that both db_catalog and db_schema support are needed in >>> SELinux. Obviously, the db_database also needs to be provided, as it is. >>> >>> From my rather limited understanding of SELinux I do not believe that >>> is a technical problem with having an object class, such as db_catalog, >>> that a particular DBMS does not use. Correct? >>> >> >> At least, I don't oppose to db_catalog class as far as we can make >> clear the differences between databases, catalogs and schemas. >> In PostgreSQL, it does not have an idea of catalog as a namespace >> upper than schema, so we cannot handle these object obviously, >> even if it is defined in the security policy. >> >> I have still a question. Is there any functional differences between >> a catalog and a schema? If both of them works just a namespace, we >> can apply db_schema class and its permission on both of catalogs and >> schema. >> In other word, when we accesses /var/log/messages, we need to have >> privileges for /var and /var/log on dir class and /var/log/message >> on file class. The reason why dir class is applied both of /var >> and /var/log is these are same kind of object. >> (Perhaps, this suggestion might be a misdesign.) >> > Actually, I think using one object class to represent both schemata and > catalogs is a possibility. As I said before, we currently use the dir > object class to represent both, and it provides all of the SELinux > function we require, at this time. However, I think it may produce a bit > of confusion for the user (to use dir), as to why we use what appears to > be an OS object class within the database. Also, it would seem a bit odd > and possibly confusing to use an object class named db_schema on a > catalog object, when the DBMS has distinct objects called schema and > catalog. > > From an SQL perspective, the general difference between a schema and a > catalog is that a catalog may only hold schemata. A schema may only hold > tables, views, etc. Also, according to the spec there should be an > Information Schema (which describes objects from all catalogs and > schemata) within each catalog. Though, we do not support this. There may > be other distinguishing factors, but I am not aware of them right now. > Note that a catalog may not hold catalogs and a schema may not hold > catalogs or schemata. So, in that sense there is a distinction between > them, where in your /var/log directory comparison there is no such > distinction. Both the /var and /var/log may each hold files and directories. > > So, using one object class to represent both objects could create > confusion, in my opinion. Also, if in the future it becomes attractive > to have some distinct SELinux permission for catalogs and schemata, this > will not be an option if the same object class is chosen for both. > > So, the bottom line for me is that I slightly would prefer having both > the db_catalog and db_schema object classes. If we have a single db > object class for both catalog and schema, I would suggest using some > generic name (e.g., db_dir) and not db_schema, to avoid confusion. I > more strongly prefer using one of the previous two options and have some > db_ class to cover the catalog and schema. Using the dir object class as > I have been seems a bit "hackish" to me. I would preface my opinion with > the fact that I know very little of the impact on the SELinux code of > having one extra object class or two extra object classes (or none). OK, indeed, the namespaces in database (catalog and schema) has a restriction about what kind of objects to be stored under them. At least, I can agree the selinux policy have two new different object classes, even if SE-PostgreSQL does not use db_catalog class. I have one more point interested in. Could you make clear how does the Trusted RUBIX assigns a security context on the newly created database objects on the modified design? We can obtain a security context for a new object using security_compute_create() which provides us a result of TYPE_TRANSITION rules, if configured. In SE-PostgreSQL: A new database object is labeled based only subject's context. A new schema object will inherit the context of database, or be labeled using TYPE_TRANSITION rules on db_schema class and the database. A new table, procedure ans sequence will inherit the context of database, or be labeled using TYPE_TRANSITION rules on its class and the schema. A new column and tuple will inherit the context of table, or be labeled using TYPE_TRANSITION rules on its class and the table. A new largeobject is a headache for me. It does not belong to any schema. Currently, it inherits the context of database, or be labeled using TYPE_TRANSITION rules on its class and the database. One considerable idea is to propose a facility to store largeobjects under certain schema, but it is not an issue in SELinux. 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.
