[refpolicy] [PATCH] hadoop 1/10 -- unconfined

[domg472@gmail.com (Dominick Grift)]

On 09/23/2010 03:54 PM, Paul Nuzzi wrote:
> On 09/21/2010 01:08 PM, Dominick Grift wrote:
>> On 09/21/2010 06:34 PM, Paul Nuzzi wrote:
>>> On 09/21/2010 12:14 PM, Dominick Grift wrote:
>>>> On 09/21/2010 05:42 PM, Paul Nuzzi wrote:
>>>>> On 09/21/2010 05:02 AM, Dominick Grift wrote:
>>>>>> Well ive rewritten the policy as much as i ca with the information that i currently have.
>>>>>> Because of the use of the hadoop domain attributes i cannot determine whether it is the initrc script doing something or the application, and so i cannot currently finish the hadoop_domain_template policy.
>>>>>
>>>>> The hadoop_domain policy is basic stuff that most programs share, plus a few hadoop specific things.  I initially had separate functions for initrc and hadoop type policy.
>>>>> Since we are not exporting hadoop specific functionality to other modules I removed them from the .if file. 
>>>>
>>>> With that in mind, it looks like the policy has some duplicate rules.
>>>>
>>>>>> Also i have no clue what transitions to the hadoop_t domain. It does not own an initrc script so i gather it is no init daemon domain. Must be an application domain then?
>>>>>> A lot of other things that arent, clear and/ or make no sense.
>>>>>> I have also left out things that i think, should be handled differently.
>>>>>
>>>>> hadoop_t is for the hadoop executable which is /usr/bin/hadoop.  It does basic file system stuff, submits jobs and administers the cluster.
>>>>
>>>> And who what runs it? who or/and what transitions to the hadoop_t domain?
>>>
>>> All of the users run it.  Users and the sysadm need to transition to the hadoop_t domain.
>>
>> ok so you can transition to it by creating a custom module with the
>> following:
>>
>> hadoop_run(sysadm_t, sysadm_r)
>>
>> Can you confirm that this works?
> 
> They are transitioning correctly for sysadm_u.

Thanks
> 
>>>>>> It would be cool if someone could test this policy and provide feedback in the shape of avc denials.
>>>>>
>>>>> I was able to get zookeeper server and client to run.  Here is the audit2allow in permissive mode.  Ignore the networking avcs.  I didn't port the networking functions since it was built as a module.
>>>>> Zookeeper client doesn't domtrans into a domain.  There is an semodule insert error. hadoop_tasktracker_data_t needs to be modified.
>>>>
>>>> Thanks i fixed that file context specification now.
>>>>
>>>> Were you able to run the init script domains in permissive mode? Does it
>>>> work when you use run_init? Do the initrc domains properly transition to
>>>> the main domains in permissive mode?
>>>  
>>> None of the pseudo initrc domains transitioned to the target domain using run_init.  
>>
>> Any avc denials related to this? Because the domain transitions are
>> specified in policy (example: hadoop_datanode_initrc_t -> hadoop_exec_t
>> -> hadoop_datanode_t)
>>
>>>
>>>> Could you provides some avc denials of that?
>>
>>> There doesn't seem to be any denials for the domtrans.
>>
>> So the domain transition does not occur but no avc denials are showed?
>> that is strange.
>> maybe semodule -DB will expose some related information. Also check for
>> SELINUX_ERR (grep -i SELINUX_ERR /var/log/audit/audit.log)
>>
>> Are the executables properly labelled?
> 
> I don't know if you changed anything with the new patch but they seem to be transitioning correctly.
> I added a separate module with hadoop_run(sysadm_t, sysadm_r) and hadoop_run(unconfined_t, unconfined_r).
> To get it to compile you need to add a gen_require hadoop_exec_t to hadoop_domtrans.  

Thanks fixed the hadoop_exec_t requirement. I did change some trivial
things, not sure if they are related to it though.

> 
>>>
>>>> You should also specify file contexts for the pid files and lock files.
>>>
>>> system_u:system_r:hadoop_datanode_initrc_t:s0 0 S 489 3125 1  1 80 0 - 579640 futex_ ?   00:00:02 java
>>> system_u:system_r:hadoop_namenode_initrc_t:s0 0 S 489 3376 1  2 80 0 - 581189 futex_ ?   00:00:02 java
>>> system_u:system_r:zookeeper_server_t:s0 0 S 488 3598 1  0 80   0 - 496167 futex_ ?       00:00:00 java
>>>
>>> -rw-r--r--. hadoop hadoop system_u:object_r:hadoop_datanode_var_run_t:s0 hadoop-hadoop-datanode.pid
>>> -rw-r--r--. hadoop hadoop system_u:object_r:hadoop_namenode_var_run_t:s0 hadoop-hadoop-namenode.pid
>>
>>>
>>> -rw-r--r--. root root system_u:object_r:hadoop_datanode_initrc_lock_t:s0 /var/lock/subsys/hadoop-datanode
>>> -rw-r--r--. root root system_u:object_r:hadoop_namenode_initrc_lock_t:s0 /var/lock/subsys/hadoop-namenode
>>>
>>>>>
>>>>> #============= zookeeper_server_t ==============
>>>>> allow zookeeper_server_t java_exec_t:file { read getattr open execute execute_no_trans };
>>>>> allow zookeeper_server_t net_conf_t:file { read getattr open };
>>>>> allow zookeeper_server_t port_t:tcp_socket { name_bind name_connect };
>>>>
>>>> What port is it connecting and binding sockets to? Why are they not
>>>> labelled?
>>>
>>> I left out the networking since I built it as a module.  I haven't had luck running refpolicy on Fedora.  The corenet_* functions might need to be written if refpolicy doesn't want all the ports permanently defined.
>>
>> You could patch fedoras selinux-policy rpm that is what i usually do.
>> Anyways i will just assume its the ports we declared.
>>>
>>>>> allow zookeeper_server_t self:process execmem;
>>>>> allow zookeeper_server_t self:tcp_socket { setopt read bind create accept write getattr connect shutdown listen };
>>>>>
>>>>
>>>> I will add the above rules to the policy that i have, except for the
>>>> bind/connect to generic port types as this seems like a bad idea to me.
>>>
>>> I think I left out binding to generic ports in my policy.
>>>
>>>> Were there no denials left for the zookeeper client? Did you use
>>>> zookeeper_run_client() to transition to the zookeeper_t domain?
>>>
>>> zookeeper_client transitioned to the unconfined_java_t domain so there were no denials. I ran your patched policy without any modifications.  
>>>
>>
>> Because you probably ran is in the unconfined domain. You should use the
>> zookeeper_run_client() that my patch provides, so that you can
>> transition to the confined domain.
> 
> Looks like that transitions correctly when I add zookeeper_run_client(unconfined_t, unconfined_r).
> Thanks for taking an interest in the patch.  How do we want to merge your changes with mine?

Honestly i think there are some mistakes in your version, and i suspect
that i adopted some of those mistakes into my patch.

For example. in my patch i allow the hadoop rc scripts to create pid
files. but from your feedback i strongly suspect that the rc scripts do
not create the pid files:

>>> -rw-r--r--. hadoop hadoop
system_u:object_r:hadoop_datanode_var_run_t:s0 hadoop-hadoop-datanode.pid

This shows that a process running as the hadoop user created the hadoop
datanode pid file. If the rc script would have created it , it wouldnt
be hadoop but root i suspect.

My opinion is that it is best to start over and use my patch as a clean
base.

Then we can extend my patch with any raw AVC denials.

I will post a new patch soon with the hadoop_domtrans fix and with the
pid filetrans removed for rc script domains (and maybe remove some other
things that i dont fully trust.)

Just so you know, we also hang out on IRC. That medium is a bit better
for collaboration/ interactivity than maillists, especially with the
larger projects.

>  
>> I will add file context specifications for the locks and pids you have
>> reported.
>>
>>>>>> Some properties of this policy:
>>>>>>
>>>>>> The hadoop init script domains must be started by the system, or by unconfined or sysadm_t by using run_init server <hadoop service>
>>>>>> To use the zookeeper client domain, the zookeeper_run_client domain must be called for a domain. (for example if you wish to run it as unconfined_t, you would call zookeeper_run_client(unconfined_t, unconfined_r)
>>>>>> The zookeeper server seems to be an ordinary init daemon domain.
>>>>>> Since i do not know what kind of dommain hadoop_t is, it is currently pretty much unreachable. I have created an hadoop_domtrans interface that can be called but currently no role is allowed the hadoop_t domain.
>>>>>>
>>>>>> Signed-off-by: Dominick Grift <domg472@gmail.com>
>>>>>> _______________________________________________
>>>>>> refpolicy mailing list
>>>>>> refpolicy at oss.tresys.com
>>>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100923/287ad29b/attachment.bin