(2010/03/11 3:04), Andy Warner wrote: > > > On 3/10/2010 12:11 PM, Eamon Walsh wrote: >> On 03/09/2010 05:16 PM, KaiGai Kohei wrote: >> >>> (2010/03/10 5:08), Eamon Walsh wrote: >>> >>> >>>> What is the meaning of the fourth "temp" argument here. Aren't lines >>>> only supposed to have three entries? Please remove this if it is not needed. >>>> >>>> >>> If the line has four or more elements, we want to raise an error, rather than >>> ignoring it. >>> If here is not the fourth %as, sscanf() does not return 4, does it? >>> >>> Thanks, >>> >>> >> >> OK, that makes sense. >> >> I don't see any other issues with the patches. Unless Andy has any >> concerns, I will push them later today or tomorrow. >> > > What is implemented looks fine to me. Just a few comments and questions. > > Only thing that may keep us from fully using this functionality is that > because there is not support for db_schema and db_catalog objects, it > can't fully cover our labeled objects (correct?). Our naming scheme is > database.catalog.schema.table, so I am guessing only the database and > table could be labeled explicitly through the *_contexts file. It would > probably confuse our customers to be able to assign contexts to some > objects but not others. This might delay our use of it until the new DB > object classes come out. The purpose of this functionality is to provide dbms hints what label should be assigned on database objects when we initialize the database, like /sbin/restorecon on filesystem. We still need definitions of db_schema and db_catalog object class for the correct access controls. If we ask SELinux any required permissions within undefined object class, it returns either allowed or denied depending on /selinux/deny_unknown. I want to use this functionality to assign preferable security context on all the database objects on global initialization. PostgreSQL set up an empty database using /usr/bin/initdb command. It inserts various kind of tuples into system catalogs which mean schemas, tables, columns... Unfortunatelly, when initdb insert tuples of system tables, tuples of schema and databases are not inserted yet. So, it needs to insert tuples without any labels, then they need to be relabeled, like /sbin/restorecon. Of course, it can be used to give a hint of the default security context to be assigned on the database, but it is not the only purpose. BTW, rubix has four layers of its namespace. It seems to me you worry about it, but don't need to worry about. Its pattern matching logic is just using fnmatch(). So, if you describe your configuration file with four layers namespace, we don't need to modify libselinux anything. example) db_table *.my_catalog.my_schema.* system_u:object_r:my_rubix_table_t:s0 > We currently overload the dir object class to cover our catalog and > schema objects. This is not great, but the best choice we have to cover > those objects. KaiGai, is it possible to actually use a dir object class > within the *_contexts file? I acknowledge overloading/mixing these > object classes (db and OS) is controversial and not the best solution, > but I am curious if it would be technically possible under this patch. > Or, does it restrict its functionality to only db objects? It is not possible, because selabel_lookup() takes the 'key' argument which is one of the SELABEL_DB_*. If you abuse db_schema/db_catalog object class until upstream policy does not have these definitions, you can lookup a matched entry with SELABEL_DB_SCHEMA for abused dir class. > Lastly, regarding tuples, I noticed the ability to label tuples was > removed because tuples are not named. Would it be useful to label all > tuples under an object (e.g., table) as follows. I am sure you > considered this, just curious of your thoughts: > > db_tuple *.pg_catalog.pg_table.* system_u:object_r:sepgsql_tuple_t:s0 > > So that all tuples under the *.pg_catalog.pg_table table would have a > context of system_u:object_r:sepgsql_tuple_t:s0. Or, is the fact that > you are not able to use anything other than * as the tuple's name simply > make things too messy? I would assume there would be a similar issue in > constructing a key value for a tuple in the call to selabel_lookup. Hmm. Indeed, it makes sense. I'll add db_tuple again. Please wait for a while. Thanks, -- 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.
