Sorry for late reply due to the spring vacation season in Japan. >>> But let's step back and take a look at how the file system uses file >>> contexts. Files are labeled in three ways: >>> >>> 1. The normal, preferred way, through a type transition on a subject >>> (domain) and target (parent directory). The database analog to this: >>> through a type transition on a subject (domain) and target (parent >>> table, schema, or other object). >>> >> Yes, we can basically cover all the database object which have its >> parent object. But the root database obejct does not have its parent. >> It is the first issue. >> > > How are databases stored on disk? Is there a file or directory that > could serve as the parent object? In PostgreSQL, all the database files are indeed stored in a single root directory ($PGDATA), however, it depends on the current implementation. >>> 2. For files that are NOT persistent, such as /proc and /sys, by >>> genfscon rules, which are basically the same as file_contexts. So if >>> there are non-persistent database objects (such as the pg_temp >>> mentioned) and there really is no parent object to label from in a type >>> transition, using selabel lookups could make sense. >>> >> I think the setfscreatecon is better analogy than the genfscon. >> > > I don't agree here - setfscreatecon is analogous to SECURITY_LABEL=xxx, > where the client (not the object manager) can override the default > context for its own purposes. Label lookups, on the other hand, come > from a fixed configuration file in /etc/selinux and they are done by the > object manager, not the client. It's more like a matchpathcon() or a > genfscon. > > That said, I don't have a strong objection to this and I do think the > selabel support has some valid uses for Postgres. Hmm... it seems to me you are correct. This behavior of selbalel_lookup() may not have appropriate analogy in filesystem. >> A schema object is deployed under a database object, so we can compute >> a default security context using type transition rules, but I also want >> to set a characteristic default on pg_temp due to its feature. >> It is the second issue how individual security contexts can be set on >> objects within same object class. >> > > SE-Postgres should be able to detect when a temp table is being created > and only do the selabel lookup in that case. > > Actually, if the temp tables are visible to other clients you may need > to do an selabel lookup followed by a type transition. Such as > temp_schema_t (from lookup) -> type transition -> user_temp_schema_t. > Otherwise the temp table could be accessible to other domains. Another > alternative would be to use UBAC. If the temp table is not shared > between sessions then it doesn't matter. It seems to me this kind of special case handling can give us confusion... >> (Or, defines db_schema_temp class? I'm not sure whether other DBMSs >> shares the concept of schamas to store temporary objects.) >> > > This may work. Whether to define a separate object class depends on the > complexity it would add to the policy writing and object manager code, > versus looking it up in selabel. I wouldn't worry about whether other > DBMS would use the class. If they don't need it they can simply ignore it. Indeed, we discussed about differences between SE-PostgreSQL and RUBIX before, and agreed to ignore db_catalog class in SE-PostgreSQL. At least, it has a benefit compared to selabel in UBAC handling, so it might be necessary to consider the option. >> The selabel_lookup(3) for database tries to solve two issues in same time. >> The one is the default to the root of database objects which does not have >> any parent object. The other is also the default to certain characteristic >> objects. >> If we can consider the selabel as analogy of setfscreatecon (automatically >> set up) for the second issue, I don't think its priority should be moved >> to the behind of type transition. >> >> An aside, the pg_temp schema is implicitly created when CREATE TEMP TABLE >> statement is given, so we cannot apply SECURITY_LABEL=xxx here. :( >> > > Understood. > > I'll probably push the patch next week sometime, unless I hear otherwise. Please wait for a while. As I noted before, the selabel patch tries to solve two matters. - The default label for db_database class. - The default label for temporary schame. If we can have db_schema_temp class, the only remaining matter is the default in db_database class. It can be solved using a file which store a default label for SE-PostgreSQL's db_database objects, as if run_init uses initrc_context. It makes sense for me, and clear its behavior from the viewpoint of the analogy. 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.
