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. > 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. > 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. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.
