Description of problem: Missing htt_server policy for SELinux Version-Release number of selected component (if applicable): FC2 Test 2 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Dont have a policy available. Expected results: 1)htt_server.te 2)htt_server.fc 3)an update to net_contexts file Additional info: I'll prepare the first draft and send it to dwalsh and cc to tagoh.
Hi Russell, I have create an initial version of security policy for the Input Method (htt_server). Could you please review it and give me some comment whether it is good or crap. :) I have applied the policy on my test machine and a normal user is now able to use Input Method under enforce mode. But I am a bit worried that applying the policy could result in security expolit in some other area. So I would really appreciate your feedback. Thanks, Lawrence --- # htt_server.te # Security Policy for IIIMF htt server # # Date: 2004, 12th April (Monday) # Types for server port type htt_server_port_t, port_type; type htt_server_usr_lib_im_t, file_type; # Establish htt_server as a daemon daemon_domain(htt_server) # allow user domains to have read access to the LE in /var/lib/im r_dir_file(htt_server_t, {shlib_t htt_server_usr_lib_im_t}) #can_exec(initrc_t, htt_server_etc_t) can_exec(htt_server_t, htt_server_exec_t) can_network(htt_server_t) ## # No Unix Socket Connection at the moment ## # can_unix_send( { htt_server_t sysadm_t }, { htt_server_t sysadm_t } ) # allow htt_server_t self:unix_dgram_socket create_socket_perms; # allow htt_server_t self:unix_stream_socket create_stream_socket_perms; # can_unix_connect(htt_server_t, self) can_tcp_connect(domain, htt_server_t) allow htt_server_t self:fifo_file rw_file_perms; allow htt_server_t htt_server_port_t:tcp_socket name_bind; allow htt_server_t self:capability { dac_override kill setgid setuid net_bind_service }; allow htt_server_t self:process setsched; allow htt_server_t { bin_t sbin_t }: dir search; -- /usr/sbin/htt -- system_u:object_r:htt_server_exec_t /usr/sbin/htt_server -- system_u:object_r:htt_server_exec_t /usr/bin/httx -- system_u:object_r:htt_server_exec_t /usr/bin/htt_xbe -- system_u:object_r:htt_server_exec_t /usr/lib(64)?/im/.*\.so.* -- system_u:object_r:shlib_t /usr/lib(64)?/im(/.*)? system_u:object_r:htt_server_usr_lib_im_t --
Any domain can connect to this server? Shouldn't that be userdomain? What package is htt_server in?
htt_server is included in iiimf-server. and it provides the framework to allow to input their native languages on the their environments. htt_server will be connected from the gtk2 immodules, which is provided by iiimf-gtk package, and the XIM client (to bridge IIIMF), wihch is provided by iiimf-x. so in other words, htt_server will be connected from userdomain, apparently. Also, if the Input Method server is implemented as the server/client model, htt_server (actually the language engine does) will connects to their the IM server like Canna, otherwise the language engines processes itself and/or uses the IM libraries. Since IIIMF uses tcp/unix domain socket, it has possibility of security issue. making the SELinux policy is needed to avoid a lot of damage IMHO.
currently we have had i18n_input.{fc,te} in SELinux's policy. but even if htt_server is running, no changes the role and htt_server is still running as user_u:user_r:user_t.
updated the summary. im-sdk works on the enforcing mode with the targeted policy. but it doesn't work on the enforcing mode with the strict policy.
What AVC messages are you seeing? Dan
Sorry for delay. this happened on even targetted policy. here is the AVC logs: Apr 27 21:54:44 devel02 kernel: audit(1114606484.567:0): avc: denied { read } for pid=4203 exe=/usr/bin/iiimd name=default.cbp dev=hda5 ino=803749 scontext=root:system_r:i18n_input_t tcontext=system_u:object_r:usr_t tclass=file Apr 27 21:54:44 devel02 kernel: audit(1114606484.568:0): avc: denied { write } for pid=4203 exe=/usr/bin/iiimd name=IROHA dev=hda5 ino=3261720 scontext=root:system_r:i18n_input_t tcontext=root:object_r:var_run_t tclass=sock_file Apr 27 21:54:44 devel02 kernel: audit(1114606484.568:0): avc: denied { search } for pid=4203 exe=/usr/bin/iiimd name=tmp dev=hda5 ino=2310145 scontext=root:system_r:i18n_input_t tcontext=system_u:object_r:tmp_t tclass=dir default.cbp is placed under /usr/share/canna and iiimd may reads any files from there. so assuming it's only default.cbp isn't a good idea.
Created attachment 113714 [details] proposed patch it looks good after modifying i18n_input.fc and make reload and setfiles file_contexts/file_contexts /usr for the targetted policy.
Added patch in selinux-policy-* 1.23.13-4
Hmm, sorry those AVC messages are still output. and after upgrading -4. BTW I just noticed that canna.te was removed from the source. why/when was it removed?
erm, I mean those AVC messages are still output after even upgrading -4 and still doesn't work properly.
I just added the below line to i18n_input.fc for allowing iiimd to connect to cannaserver. /var/run/\.iroha_unix(/.*)? system_u:object_r:i18n_input_var_run_t added to i18n_input.te for allowing to read the canna's files: allow i18n_input_t usr_t:file read; and after this, I got these AVC messages and still doesn't work. Apr 28 22:17:04 devel02 kernel: audit(1114694224.884:0): avc: denied { connectto } for pid=24587 exe=/usr/bin/iiimd path=/var/run/.iroha_unix/IROHA scontext=root:system_r:i18n_input_t tcontext=root:system_r:initrc_t tclass=unix_stream_socket Apr 28 22:17:04 devel02 kernel: audit(1114694224.887:0): avc: denied { search } for pid=24587 exe=/usr/bin/iiimd name=tmp dev=hda5 ino=2310145 scontext=root:system_r:i18n_input_t tcontext=system_u:object_r:tmp_t tclass=dir Apr 28 22:17:04 devel02 kernel: audit(1114694224.890:0): avc: denied { search } for pid=24587 exe=/usr/bin/iiimd name=/ dev=hda6 ino=2 scontext=root:system_r:i18n_input_t tcontext=system_u:object_r:default_t tclass=dir The reason why it doesn't work is because of first AVC message. iiimd needs to be allowed to connect to /var/run/.iroha_unix/IROHA which is a socket file which is made by cannaserver.
For another problem, iiimd is going to read some user-specific information from $HOME/.iiim/ but i18n_input_t looks like not allowing to do it.
Created attachment 113786 [details] another patch for i18n_input.fc
Created attachment 113787 [details] patch for i18n_input.te
I'm not sure if these patches are on the right way. so please review them. Thanks
Why is a daemon reading users home directories? What process is iimd trying to communicate with that is running initrc_t? The FC patch is fine.
Because iiimd is designed to be connected from multiple users and needs to handle the user-specific data too. /var/run/.iroha_unix/IROHA is created by cannaserver which is running from /etc/init.d/canna. which is denied for connectto. I thought we had canna.te for taking care of cannaserver. but I couldn't find any but only canna.fc is there, but anyway.
just tested on the latest tree, including 1.23.14-2. it looks good to me.