01:08:22 rayh has quit 01:32:46 cradek: on the subject of security and run-in-place: I think they are mutually incompatible 01:33:21 if you can compile without root privliges (a neccessity IMO, in keeping with linux tradition) then you can replace the source for one of the kernel modules with a trojan 01:33:40 then compile, and run in place, and presto, you have a trojan kernel module - the system is cracked 01:33:51 but I'm not willing to give up run-in-place 01:34:11 mostly because as a developer it saves a crapload of time and lets me have multiple versions 01:34:54 with most programs it is the "make install" step that provides security. You need to be root to do that, and as root you should know what you are installing 01:42:21 jepler has joined #emc-devel 01:42:30 hi 01:42:50 steves_logging has joined #emc-devel 01:43:09 run-in-place and security are mutually incompatible 01:43:19 (unfortunately) 01:43:45 I want to keep run-in-place, for one thing it lets me have multiple versions at once 01:44:37 but if you can compile without being root (a must IMO) then you could replace the source for some module with a trojan, compile, and run in place, and presto, you have a cracked system 01:45:38 so run-in-place should require sudo (or su -c) 01:46:02 that way, security of run-in-place depends on the system's sudo policy. If you have crappy sudo security, then so be it 01:50:26 if run-in-place is for developers only, that sounds fine to me 01:50:50 but can we make it work 01:51:31 "sudo emc" lets the run script run as root, I guess that will pass on to module-helper (because it won't be setuid when doing run-in-place) 01:51:35 though you should also be able to ./configure --prefix=/usr/emc-20060129 too 01:52:32 then make, and sudo make install? 01:52:54 yes 01:53:26 and then you need to explicitly give a path when you run it? (to run the one you want)... 01:53:33 yes 01:54:17 and the installer might make icons for multiple versions... 01:54:18 ./configure --prefix=`pwd` --bindir=`pwd` && make && sudo make install ? 01:54:37 or else run in place could require 'sudo make set-permissions'? 01:54:52 ahh, now that I like 01:55:14 it would make halcmd and module-helper setuid, right? 01:55:50 btw, I think I like the idea of having halcmd invoke module-helper, so halcmd no longer needs to be setuid 01:57:20 putting all insmod security in one place seems like a good idea 02:00:34 yes, yes 02:01:18 you ever see this before: 02:01:20 cvs update: move away `include/.cvsignore'; it is in the way 02:01:21 C include/.cvsignore 02:02:27 got that for half a dozen directories 02:03:53 oh, I see - you added the .cvsignore files 02:04:02 and they conflict with ones that I already created here 02:04:34 nefs 02:07:20 you wrote some .cvsignore files but didn't add them? I wonder if everyone had done that .. 02:07:26 did I break a rule by adding the .cvsignores or something? 02:07:41 I'm unaware of any rule 02:07:55 I had some local cvsignores 02:08:18 but in hindsight it makes sense to commit them 02:09:47 I'll delete my local ones and cvs up again, should solve the problem 02:29:20 fenn has joined #emc-devel 02:29:39 * fenn pokes his head in and looks around. 02:29:54 logger_devel: bookmark 02:29:54 See http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-01-30#T02-29-54 02:39:07 darn, I missed everyone. 02:39:49 obviously you guys are right about how compiling should not require sudo 02:40:03 I don't know what I was thinking 02:40:19 usually it takes two passes for me to do something reasonable, the first turns out goofy 02:41:32 I think we need to be watching for whether run-in-place is more trouble than it's worth... I'm not sure it is yet, but those scripts really are complicated. 02:42:24 for instance look at "realtime" 02:42:35 it has to guess where several things are. 02:42:48 run-in-place might be bogus already (if you also have an installed version). 02:43:31 as for module_helper, why not drop root completely at the top of error(), just so I can worry about less code. 02:44:05 yeah that sure is more complex than I wanted, but I think all the output is needed. 02:44:50 is that setuid(getuid())? 02:45:23 yes, I think so 02:47:35 "dot" isn't used for anything anymore 02:48:34 right 02:49:18 I can attempt to insert rtapicheese.ko 02:49:44 I thought I fixed that 02:49:54 no, I fixed the "shorter" case 02:49:56 crap 02:50:45 SWP_Away is now known as SWPadnos 02:50:54 do the modules ever end with something besides .ko? 02:51:00 .o 02:51:01 yes 02:52:10 this program is supposed to validate that any module to be loaded is of the form {acecptablePathName}/{acceptableModuleName}.{o,ko} right? 02:52:35 no 02:52:38 oh ;) 02:53:20 {whitelisted path}{more stuff not including ..}/{whitelisted module}.extension 02:53:32 so whitelisted path = /usr/realtime 02:53:44 my system has /usr/realtime-2.6.12-magma/... which is fine 02:54:23 ok. would a symlink on install make things easier? 02:54:48 not really, I don't think 02:54:49 /usr/realtime-2.6.12-magma/ -> /usr/realtime 02:55:03 or hte other way around 02:55:11 no, that defeats the purpose of naming it realtime-kernelversion 02:55:20 ok 02:55:20 /lib/modules has the same problem 02:55:27 true 02:55:51 if there is a symlink, it should point to realtime 02:55:54 jepler: how do I fix rtapicheese? can you do it? I'm trying to figure out my ssh keys 02:56:11 that would be a runscript possibility 02:56:14 jmk_away: some distribs used to do that for /lib/modules 02:56:25 SWPadnos: no, the script can't make symlinks in /usr!! 02:56:30 cradek - try staring from the tail of the module name 02:56:37 true - good idea ;) 02:57:06 cradek: I'm looking at it 02:57:11 thanks 02:57:19 seems I write a bug for every one I fix 02:58:13 heh - you could get weird with strrev :) 02:58:47 SWPadnos: the goal is not "weird" here 02:58:52 heh 02:59:00 it's to write a simple program with no bugs, which seems nearly impossible 02:59:21 reverse the string, look for a leading "ok." or "o." - if not found error, else strip it off and continue 02:59:34 that's very lispy 02:59:40 I don't understand the problem with names 02:59:48 split the string at the last / and the last . 02:59:56 after the . must be either o or ko 03:00:05 between the slash and the dot must exactly match a whitelist name 03:00:31 before the slash has no "..". and begins with a whitelisted path 03:00:36 yes, I think I agree that's the algorithm 03:01:29 since /usr/realtime is not under the control of the user, do we actually care that 'rtapicheese.ko' can be inserted? 03:01:43 jepler: yes, I think so 03:01:47 my thoughts exactly 03:01:53 I agree 03:01:56 jepler: I think I want a real whitelist 03:02:15 that means anyone writing a new HAL module will need to edit the whitelist 03:02:24 jmk_away: yep 03:02:37 I have mixed feelings about that 03:03:31 if an attacker has write access to the directory, he can rename his trojan module to match a whitelisted name 03:03:39 so what does it get you? 03:03:50 the directory must be secure anyway, so trust the directory 03:03:51 if we don't have a whitelist, we're allowing the user to insert any module in /lib/modules or /usr/realtime... 03:04:18 even one that might take down the machine 03:04:35 oh, you are talking about a legit module, but not one that is emc related 03:04:35 just take out the n in the comparison - do a strcmp instead of strncmp 03:04:53 jmk_away: exactly 03:05:03 (on line 94) 03:05:07 SWPadnos: that will compare the extension too 03:05:18 strip off the extension - you can put it back later 03:05:18 SWPadnos: I'm sure jepler can get it right :-) 03:05:18 how about this: 03:05:26 cradek: you have too much faith in me 03:05:32 all HAL modules are in /hal 03:05:53 store a '\0' at the '.', then put it back after the comparison (or compare strlen as well as strncmp) 03:05:58 any module in /hal can be installed, as well as whitelisted modules in 03:06:06 the former handles HAL modules, and allows new ones 03:06:21 the latter handles rtapi.ko, and hal_lib.ko and the rtai modules 03:06:37 jmk_away: it has to insert all the rtai modules too 03:06:59 the latter handles rtapi.ko, and hal_lib.ko and the rtai modules ;-) 03:07:23 jmk_away: I do not think someone savvy enough to write a hal module is going to stumble over this whitelist for long. I don't see why we should compromise on the whitelist. 03:08:06 how about this: (replacing line 94): 03:08:14 if((strlen(module_whitelist[i]) == strlen(last_slash+1)) 03:08:16 && (!strncmp(last_slash+1, module_whitelist[i], 03:08:17 strlen(module_whitelist[i])))) 03:08:21 I just like stuff to be self contained 03:08:34 examples: 03:08:47 (or replace the last strlen with max(the two strlens)) 03:08:50 writing new module = write code, add a line to the make file GOOD 03:09:07 add an NML message = write new code in 12 different files BAD 03:09:16 I know jmk 03:09:36 I normally agree 03:09:40 but I can live with the whitelist, its not worth arguing over 03:09:52 we should have a filter that can pull the required names out of the makefile (or as an ls modules/*.{o,ko}) 03:09:57 but setuid programs make the writer and the installer rightfully nervous 03:09:58 during make 03:10:36 thinking about the directory that will contain the HAL module reminds me... 03:10:56 among the cruftiest code in halcmd is the code that finds the HAL module directory :-( 03:11:07 yeah 03:11:16 probably because of run-in-place 03:11:28 I had to add more similar crap to /etc/init.d/realtime 03:11:29 partly 03:11:46 but even installed, there are usually hooks that let the user install in non-standard places 03:12:33 I'm this close -><- to recommending we ditch run-in-place and use --prefix for separate versions like jepler says. 03:13:01 I will throw things at you 03:13:01 but I know people will scream bloody murder 03:13:07 and throw things at me 03:13:30 ./configure --with-fscking-run-in-place=`pwd` 03:13:56 jepler mentioned the possiblility of "sudo make set-permissions" to set the setuid bits for run-in-place 03:14:44 perhaps "sudo make run-in-place" would be better? it would set setuid bits, as well as configure directories 03:14:56 basically an install that doesn't install, but does prep for running 03:16:46 what confuses me is that run-in-place should be easier, not harder, than run-installed 03:17:01 run-in-place always has the same directory layout, only the root changes 03:17:01 either is easy; supporting both is what's hard 03:17:18 run-installed can be overridden and re-arranged by the user 03:18:53 chris@buster2:/usr/src/emc2/src$ sudo make setuid 03:18:53 Password: 03:18:53 sudo chown root module_helper/emc_module_helper ../bin/halcmd 03:18:54 sudo chmod 4755 module_helper/emc_module_helper ../bin/halcmd 03:21:04 chmod 4750, so that it is not setuid for everyone, just users in my own primary group (maybe only me)? 03:21:44 seems reasonable 03:22:03 a run-in-place compile is probably in someone's home directory tree 03:22:10 only they are gonna run it in place 03:22:13 done 03:23:12 jepler: I like the splash screen changes 03:23:17 all of this depends on a good sudo setup, right? 03:23:25 make setuid? yes 03:23:46 even without it, it'll be obvious what the command is supposed to do 03:23:54 sudo isn't required for running emc anymore 03:25:02 src/Makefile: cvs update: move away `include/.cvsignore'; it is in the way 03:25:03 C include/.cvsignore 03:25:05 oops 03:25:11 cvs update: move away `include/.cvsignore'; it is in the way 03:25:11 C include/.cvsignore 03:25:15 oops again 03:25:22 cut/paste with KDE sucks 03:25:35 src/makefile: sudo chmod 4750 module_helper/emc_module_helper ../bin/halcmd 03:26:18 there is a sudo in the makefile, so if sudo doesn't work, you can't do the "make setuid" 03:26:34 why not drop the sudo, and let the user say "sudo make setuid" 03:26:38 true enough 03:26:51 or "su -c 'make setuid'" 03:27:31 or on a real multi-user system, call the sysadmin who logs in and does "make setuid" or "make install" 03:27:51 I feel bad for all the people wading through my one-line commit emails 03:27:59 why 03:28:08 because 03:28:10 there 03:28:12 are 03:28:12 the cvs browser will let them see exactly what changes do what 03:28:13 a 03:28:15 lot 03:28:15 [wade wade wade] 03:28:16 of 03:28:18 them 03:28:33 jmk_away: I was only half serious 03:28:41 I know 03:28:42 but even a bonehead can read them (trust me ;) ) 03:28:48 haha 03:28:54 so has anyone tried run-in-place tonight? 03:29:14 I have a deb installed so I can't be sure it's working right 03:29:16 I will 03:29:22 cd src 03:29:24 oops 03:29:25 * cradek hides 03:29:52 you have a few mins, I'm doing a make clean/make 03:30:17 first I'll try without doing make setuid 03:30:25 (test the error handling ;-) 03:30:49 well I've made a bunch of changes to module_helper. should I check it in? 03:30:50 dammit jepler, now I have to cvs up again 03:30:56 jepler: sure 03:31:01 you just did didn't you? 03:31:15 oh, sorry, I saw the /tests commit 03:33:17 so - is it safe to cvs up now? :) 03:33:34 I haven't seen the helper changes yet 03:33:58 me either - the latest message I have is the cvsignore 03:33:59 why does emc_module_helper (executable) wind up in the src tree instead of emc2/bin? 03:34:25 good question 03:34:43 I'm waffling about whether to check in these changes, that's all 03:35:03 do they help? 03:35:11 I waffled bigtime about this whole deal, but the team convinced me this morning that it's the way to progress, even if it's momentarily broken 03:35:31 so jump with both feet 03:35:47 yes - before I start compiling 03:35:55 ditto 03:36:16 Starting emc... 03:36:16 Cannot find emc_module_helper or it is not installed properly (setuid root.) 03:36:33 run-in-place is broken with the default ./configure 03:36:50 you ran make setuid? 03:37:17 no, I forgot, but that doesn't help :-) 03:38:39 but for all that, my extension test doesn't seem to work. wth 03:38:57 wtf?! I keep getting these 03:38:59 cvs update: move away `rtlib/.cvsignore'; it is in the way 03:39:00 C rtlib/.cvsignore 03:39:10 I deleted my local .cvsignore files 03:39:48 got them for bin, include and rtlib 03:40:25 cd src 03:40:29 dammit 03:41:04 gah - fonts need to clearly demark the lowercase 'L' and the numeral 'one' 03:41:30 I'm looking at that last checkin, and I see "return target + 1" 03:41:44 SWPadnos: I can't control the font you use 03:41:53 no, and it's a good thing, too 03:42:04 l1l1l1l1 03:42:12 that I can see - you see 03:43:05 ok module_helper isn't going to install these modules since they're not in a whitelisted path 03:43:20 so for run-in-place, what do we do? 03:43:29 funny - thanks (I think) 03:44:02 the whitelisted path is screwed anyway I think... what if the system uses a non-conventional path for modules? 03:44:57 for instance, /usr/local/realtime 03:44:58 perhaps the path should come from config.h? 03:45:16 well rtai really wants to use /usr/realtime 03:45:20 let configure figure out where they will be (in the installed and run-in-place cases) 03:45:21 others can use run-in-place 03:46:23 /lib/modules has been standard on every distribution since there were kernel modules 03:46:47 cradek: you're envisioning that .. run-in-place will use sudo, not module_helper ? 03:47:02 both should use module_helper 03:47:24 jepler: I was, yes, but maybe jmk is right 03:47:36 char *path_whitelist[] = { "/lib/modules", "/usr/realtime", 03:47:37 #ifdef EXTRA_WHITELIST_PATHS EXTRA_WHITELIST_PATHS, 03:47:37 #endif NULL 03:47:40 argh that's a terrible past 03:47:41 e 03:48:13 basically, arrange to -DEXTRA_WHITE_LIST_PATHS=\"...\" when you're configuring to run in place 03:48:13 I get the idea 03:48:39 "configuring to run in place"?? 03:48:58 I'm getting more and more sick to my stomach about this 03:49:07 you mean run config and explicitly tell it you want to run in place, then make, run, then config again, make again, install? 03:49:29 eww 03:49:55 jmk_away: Always having another path whitelisted by module_helper (one that depends on where you ran configure) seems like a security problem 03:50:02 jmk_away: it's either that or you have your scripts guessing where things are 03:50:08 yeah, I know 03:50:19 its starting to make me sick too 03:50:19 jmk_away: just a minute ago you said we should have configure write these scripts properly 03:50:37 I was visualizing lines in config.h like: 03:50:43 it's my bedtime .. you guys figure this out 03:51:19 #define INSTALLED_MODULES_PATH "/lib/modules", "/usr/realtime" 03:51:47 #define RUNINPLACE_MODULES_PATH "/home/John/emcdev/emc2head/rtlib" 03:52:17 but I agree that you would want the second one disabled once installed 03:52:48 ok, I agree with you guys, run-in-place is becoming a royal pain 03:53:04 yeah. again I say we need to be careful to recognize when it's more trouble than it's worth. 03:53:15 loading modules directly from an individual user's directory is inherently insecure 03:53:27 but we MUST be able to have multiple versions on a box 03:53:38 and that means managing multiple sets of modules! 03:53:52 yeah. 03:54:04 you can't stick them all in usr/realtime or /lib/modules and expect it to pick the right ones 03:54:43 any developer has to have the ability to install/remove modules, so as long as sudo 'whatever' works, it's OK 03:54:49 (sudo emc, sudo module_helper, etc) 03:55:06 what mechanism is used by the kernel guys? you can certainly have two kernels on one box, and each kernel insmods the appropriate modules 03:55:18 /lib/modules/kernel-version/... 03:55:36 certainly they're not loaded from the source tree. 03:55:42 right 03:56:01 I was just asking, because their methods might (or might not) be applicable to us 03:56:24 they're loaded from the development dir 03:56:28 for one thing, when we do an install, we should install into the kernel-version tree 03:57:08 yes, currently in my setup it's /usr/realtime-kernelversion/... 03:57:19 the realtime modules must be different for different kernel versions too. 03:57:20 if you have two kernels on a box and compile emc2 while running kernel 1, the modules will match kernel 1... if you are later running kernel 2, you don't want to use the kernel 1 compatible modules 03:57:31 jepler has quit 03:57:32 jmk_away: yes, I actually got that right already. 03:57:41 ok, I didn't know 03:58:08 sorry, I didn't mean that to sound snippy 03:58:17 you didn't 03:58:24 but I am finding most of what I've done isn't 100% yet 03:58:24 anyway 03:58:46 this is brain twistin stuff, at least for me 03:58:51 but my f-ing debs work when I pick EMC on the applications menu 03:59:02 lol 03:59:09 that was my goal, and it works, but I steamrollered over everything else 03:59:28 we load three kinds of modules with module-helper 03:59:36 1) ones we didn't compile: rtai stuff 03:59:56 2) ones we did compile, but not HAL modules: rtapi.ko, hal_lib.ko 04:00:00 3) hal modules 04:00:15 4) kernel modules (adeos) 04:00:26 that is under #1 04:00:37 #1 is in /usr/realtime, #4 is in /lib/modules 04:00:51 isa deos available as a module? 04:00:52 adeos is installed with the kernel, not rtai 04:01:01 we didn't compile either one tho ;-) 04:01:02 SWPadnos: yes 04:01:03 I think it's compiled in, isn't it 04:01:12 SWPadnos: can be either 04:01:17 1a: ones we didn't compile that are in /lib/modules: adeos 04:01:25 ok - I haven't gotten anything recent to work anyway 04:01:27 1b: ones we didn't compile that are in /usr/realtime 04:01:35 ok 04:01:46 I didn't want to argue a pedantic point, I thought it might be relevant. 04:01:48 anyway, 1 (a and b) is exactly the same for run-in-place and installed 04:01:56 ok right 04:02:13 2 is a bit of a prick, they are "ordinary" kernel modules 04:02:31 3 IMO should be in a subdir of their own, and halcmd should take modules only from that subdir 04:03:04 I don't want people to do "loadrt usb_camera_driver" 04:03:36 is it terribly icky to recompile module_helper when make install is run, and have it use a different set of hardcoded paths? 04:03:51 since you wouldn't awnt an installed version to be able to load from /home/me/... 04:04:00 SWPadnos: it would have to be recompiled... 04:04:01 want 04:04:05 its icky... terribly depends on the alternatives, it might be less icky than other choices ;-/ 04:04:29 I think it's necessary, or the user directory is in the installed whitelist 04:04:44 or the user can't use it as run-in-place 04:05:01 or you compile two versions, install one, keep the other in home/me/emc2/bin 04:05:19 can we pause for just a second 04:05:22 sure 04:05:29 sure, but that's at least a 1 on the ickymeter 04:05:29 * jmk_away takes a leak 04:05:30 ok 04:05:35 tonight, run-in-place is borken 04:05:42 most people who track cvs run-in-place 04:05:53 what should we do tonight? It's already 10pm here. 04:06:04 it could be as simple as an email to -dev 04:06:46 I wonder if I should have put this on a branch. 04:07:26 I think run-in=place is more important at this point than installed 04:07:44 install is more or less an experimental target for most of us, I think 04:08:36 that may be true for a couple days, but install is required for the release 04:09:13 yes, and either both need to work then, or there needs to be a mail to the devlist telling people *before* run in place is broken 04:11:02 ideally run-in-place would be working when we go to sleep, even if installed isn't 04:11:13 that was my thought 04:11:23 the fix can be ugly and temporary 04:12:07 for instance, temporarily whitelist /emc2/rtlib as well as the other two paths 04:12:23 in the long run that is insecure, but tonight it makes things work (maybe) 04:12:45 only if you ./configure --the-right-way 04:13:00 or disable path checking altogether, for now 04:13:15 disabling the path altogether might be better 04:14:49 let me see if that fixes it 04:15:38 can you make it alpha blend those images, please :) 04:15:51 I may want a logo on the wizard, after all 04:17:08 ok, tonights mission is apparently just to get it working, even if a bit insecure 04:17:23 later (soon) we think/talk it thru and refine 04:17:57 one of the things to think/talk about (related to the module path stuff) is how halcmd loadrt knows where the modules are 04:18:47 modules can vary based on kernel config (already handled in the installed case) and based on emc version (not handled at present, we use run-in-place and only allow one installed version) 04:19:13 is that a fair summary of the problem? 04:20:02 would modprobe be better here? (for any installed version) 04:20:23 * jmk_away is scared of modprobe 04:20:25 hmmm - except that it may silently load some other stuff you don't know about 04:20:34 (we fear that which we don't understand) 04:20:54 well, it automatically loads from the correct /lib/modules-XXX dir 04:20:56 getting back to the three (or four) classes of modules 04:21:01 sometimes I feel like we've rewritten modprobe very, very clumsily 04:21:06 yes 04:21:15 modprobe might be appropriate for 1a, 1b, and 2 04:21:20 3 (hal modules) not so 04:21:21 but with extra dirs, I think 04:21:39 hal modules should never be loaded except by HAL 04:21:42 I think you can modprobe a module in the current dir, but I'm not sure how that works 04:22:11