Christopher J. PeBenito wrote: > On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote: >> Christopher J. PeBenito wrote: >>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote: >>>> Christopher J. PeBenito wrote: >>>>> I'm out of arguments; clearly I'm in the minority on this issue. I >>>>> already said I wouldn't block the policy over this, so KaiGai, if you >>>>> would send a last patch based on the revisions I made [1], let see if we >>>>> can finally get this merged. >>>>> >>>>> [1] http://marc.info/?l=selinux&m=120999566809541&w=2 >>>> I'll submit a revised version later. >>>> (Now we cannot update SVN repository, due to server maintenance.) >>>> >>>> Before this, I want to modify the following points: > >>>> - postgresql_unconfined() interface should also associate a domin >>>> with sepgsql_client_type, not only sepgsql_unconfined_type. >>>> dontaudit rules on row-level logs are not disabled for unconfined >>>> clients. And, it's not useful to write additional policy module. >>> I don't understand what you mean about the dontaudits. Otherwise, you >>> should recheck the unconfined rules. I'm fairly sure I copied anything >>> relevant from the client rules into unconfined so I didn't have to add >>> both attributes in postgresql_unconfined(). >> A table can contain massive tuples in generally. If 50% of 1,000,000 tuples >> are labaled as "Classified" and hidden from clients (includes unconfined >> domain), tuple-level access denied log will make a flood of logs. >> The dontaudit rule enables to restain the problem. >> >> I intended sepgsql_client_type means all domains connectable to SE-PostgreSQL. >> If it dosen't contain unconfined domains, I think its name is a bit confusable >> and something like "sepgsql_unpriv_type" is better for its name. > > The fact is that we need an interface for unconfined access. If the > privileged client access is equivalent to unconfined access, then I feel > that the unconfined interface is clearer. OK, it is clear enough for me. >> Then, the above dontaudit rule should be rewritten as follows: >> >> dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \ >> { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *; >> >> At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off >> tuple-level access logs, but you suggested it is unnecessary, so I removed it. > > I don't agree because of: > > +allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *; > +allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *; > > so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do > anything since the access is allowed. It is correct in type enforcement. But MCS/MLS can prevent to access by unconfined domains, and make flood of access denied logs. >> In addition, I found an unclear point which came from my original policy. :( >> >> allow sepgsql_unconfined_type postgresql_t:db_blob { import export }; >> >> A blob import interface enables to read a file on a server host by the server >> process (postgresql_t), and import to database as several frames of largeobject. >> A export interface works for inversed direction. >> >> In the previous discussion, the meaning of these permission is to indicate >> server process to start importing or exporting. >> However, I'm now considering the following rules are more sensefull: >> >> 1. SE-PostgreSQL checks whether the client has db_blob:{import} for >> the target large object. >> 2. SE-PostgreSQL checks whether the client has file:{read} for >> the target file. >> 3. SELinux (kernel) checks whether postgresql_t has file:{read} for the >> target file, because it uses read(2) system call. >> >> Could you tell me your opinion? > > I'll defer to Josh on this one since he knows much more about databases > than I do. -- 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.
