From: Linda K. <lin...@hp...> - 2011-04-22 02:43:38
|
Hi Jim, In our meeting today you mentioned that you had to disable a bind in order to get the network test daemon to run. Can you say a little more about that? What bind did you have to disable? What I'm seeing is that xinetd can't bind to the ports (EPERM) for the 2 lblnet_tst services so it disables them. I don't understand why the bind is failing though. It works in permissive mode so you'd think I'd find some AVCs but there aren't any. That makes me think there's a dontaudit rule that's hiding it. What problem did you see and how did you get around it? -- ljk |
From: Joe N. <jo...@na...> - 2011-04-22 03:11:38
|
On Apr 21, 2011, at 9:43 PM, Linda Knippers wrote: > Hi Jim, > > In our meeting today you mentioned that you had to disable a bind in order > to get the network test daemon to run. Can you say a little more about > that? What bind did you have to disable? > > What I'm seeing is that xinetd can't bind to the ports (EPERM) for the 2 > lblnet_tst services so it disables them. I don't understand why the bind > is failing though. It works in permissive mode so you'd think I'd find some > AVCs but there aren't any. That makes me think there's a dontaudit rule > that's hiding it. > > What problem did you see and how did you get around it? Are you sure you are not using ports that have been assigned types already? seinfo --portcon joe |
From: Linda K. <lin...@hp...> - 2011-04-22 03:44:54
|
Hi Joe, Joe Nall wrote: > On Apr 21, 2011, at 9:43 PM, Linda Knippers wrote: > >> Hi Jim, >> >> In our meeting today you mentioned that you had to disable a bind in order >> to get the network test daemon to run. Can you say a little more about >> that? What bind did you have to disable? >> >> What I'm seeing is that xinetd can't bind to the ports (EPERM) for the 2 >> lblnet_tst services so it disables them. I don't understand why the bind >> is failing though. It works in permissive mode so you'd think I'd find some >> AVCs but there aren't any. That makes me think there's a dontaudit rule >> that's hiding it. >> >> What problem did you see and how did you get around it? > > Are you sure you are not using ports that have been assigned types already? > > seinfo --portcon Wow, that was it. Thanks! I had tried picking different ports but managed to pick other ports the selinux cared about. I didn't know about that command and I didn't know that selinux would even enforce port assignments. There was no AVC either. :-( Thanks again Joe. You saved me a bunch of time. I hope you're doing well. -- ljk > > joe > > |
From: James C. <cz...@us...> - 2011-04-22 14:22:49
|
Hi Linda I'm afraid what I have done will not be particularly useful for testing anything other than unlabelled packets. Which was fine for me as my requirements are for testing the filtering capabilities of iptables, ip6tables, and ebtables. The problem I ran into was on the lblnet_tst_server although I'm sure it is related to all the policy issues we are going through (and I don't have the latest git tree so it's possible when I pick that up in the next day or two that if there have been lspp_test.te changes or the lblnet_tst_server that was in the released Source Forge tar bundle is significantly different from what is in the git tree that some of the problems I see will go away). So first let me explain the environment I run in. In an effort to test the filtering tables I decided to use the approach the network tests use. 1. Run all the tests out of the run.conf file. Reset the filtering tables before each test so they are in a known state, add a rule to the tables and run the test. Needing both a local and remote application to generate traffic I thought it would be nice to utilize the lblnet_tst_server for this task and then also use the remaining framework of the network run.conf file. Since I need to check my own audit records generated from the audit chains available for the filtering tables I eliminated the syscall audit code in my run.conf and added my own using ausearch (The audit records produced from the filtering table chains are not as inclusive of information as the system calls). In using the network run.conf as a base I still needed to setup a call to the lblnet_tst_server. In the setup_default subroutine it builds a command string that looks like "sockcon:full,system_u:system_r:$(get_test_domain $type $host):$remote_obj;" and then the actual operation gets tacked on depending upon which test is being run. For my tests and in order to use the same framework all my tests ran unlabelled with an mlsop_arg of eq. Both the network server and the TOE have been installed running mls policy and the lspp_test.pp was built from an lspp_test.te that Ramon had passed me that I believe both of you had collaborated on earlier. (I may not have changes that are newer than 3 weeks ago). The lspp_test.pp were loaded on both servers. What I first noticed (that happens when running mls policy only) was that the lblnet_tst_server was failing to bind the control socket, however this results from the problem that the setsockcreatecon in the ctl_sockcon subroutine is failing. I tried playing with different contexts to be sent from the TOE to see if I could hit on something it liked for the unlabelled case to no avail. I thought based on the policy it should probably be lspp_harness_t but that did not work, it used to be lspp_test_generic_t (which also doesn't work). I tried several others also but they did not work either. I have not tried any of these in either a labelled or ipsec case as for my purposes I really had no need. So finally just so I could verify that the code in my run.conf was operating correctly I commented out the portion in the lblnet_tst_server in ctl_sockcon that does the setsockcreatecon, and I was able to run my tests in the unlabelled case. Sorry this is probably not much help. Jim James Czyzak Linux Security Team Linux Technology Center (830) 839-4826 cz...@us... From: Linda Knippers <lin...@hp...> To: James Czyzak/Beaverton/IBM@IBMUS Cc: aud...@li... Date: 04/21/2011 09:43 PM Subject: lblnet_tst-tcp troubles Hi Jim, In our meeting today you mentioned that you had to disable a bind in order to get the network test daemon to run. Can you say a little more about that? What bind did you have to disable? What I'm seeing is that xinetd can't bind to the ports (EPERM) for the 2 lblnet_tst services so it disables them. I don't understand why the bind is failing though. It works in permissive mode so you'd think I'd find some AVCs but there aren't any. That makes me think there's a dontaudit rule that's hiding it. What problem did you see and how did you get around it? -- ljk |