From: Daniel F. <kr...@gm...> - 2005-09-11 13:03:33
|
2005/9/10, Bernhard Kraft <kra...@kr...>: > Sebastian Biallas wrote: > > Compile it as 32 bit x86-code. I don't know how this works. >=20 > I also noted you were talking about this "String to char*" conversion pro= blem (Which you most > probably know about). I have made a fix for the only occurence of this pr= oblem I came about when > compiling. It is in the SDL sysdisplay.cc file. >=20 > This patch is located at: > http://www.think-open.org/kraftb/pearpc/02_pearPC_SDLSetCaption_patch.dif= f Is this still a problem with the current CVS? I've built it since the matter was resolved, and I don't recall any problems like this. Of course, I'm also not building the SDL code path. > Then there is another "annoying" bug that "ifconfig" can't get executed. = I don't know about your > test environments but normally I do not execute programs as root and as a= result of that "ifconfig" > wont be in the PATH variable. >=20 > So I made a patch for the call to "ifconfig" to bring the tun device up. = It's located at: > http://www.think-open.org/kraftb/pearpc/01_pearPC_ifconfig_patch.diff Two things. First, am I the only one who puts /sbin/ and /usr/sbin/ in their regular user path? Because, you know. Even though ifconfig is in the /sbin path, a lot of things that it does, do not require being root. Such as "ifconfig -a" which I use fairly often anytime I need my IP address, or diagnose network problems or anything like that. ON THE OTHER HAND, before you say I'm a dirty rotten bastard, and that I'm just trying to dismiss your patch as unnecessary, I also run su as /bin/su because there's this nasty tendancy for people to put trojan horses in your execution path. Come to think of it, I should be doing the same with /bin/sudo (and yes, they can be in /usr/bin, but on systems where they are, I'd place a symlink so I didn't have to type so much) So, considering that this opens up a security flaw for anyone to execute arbitrary code so long as they can make an executable file "ifconfig" in the execution path environment while running PearPPC, that would be a bad thing. We should take the patch. > And the last one is a little less worse ... It's just that the MASQUERADE= entry in the iptables get's > just created in script/ifppc_up but never removed. So if you start ppc mo= re than once those entries will > pile up (I don't know if that hurts linux somehow). I had to move the PPC= _ setting to the settings file > so they are available for the up and down scripts ... >=20 > I noted also that you bring the interface up as NATed one but close it as= bridged. This is a result of > commenting out the bridge code in the up script but not in the down scrip= t. I think this nuisance should > get cleared. >=20 > The patch for properly removing the MASQUERADE entry is in the last patch= at: > http://www.think-open.org/kraftb/pearpc/03_pearPC_ifppc_down_iptables_pat= ch.diff Well, there's a bunch of sticky problems here. First of all, as it is designed, PearPC will not clean up after itself if it crashes. This is because in the beginning it calls the ifppc_up, then it say, receives a SEGV, then it never calls the ifppc_down. That's a bad thing. In all honesty, the entire PearPC networking under Linux is hacked up pretty poorly (not to say that it doesn't work. Just from a security point of view, it's just not the best.) What should ideally be designed is an approach that would take care of these security issues. First, the best place to put the configuration file is in /etc. Since this file should only be accessible to the setuid programs, that should not be a problem. Since you can only use the networking in a setuid environment, the best place for the ifppc_up/down scripts would be in either /usr/bin or /usr/local/bin. Or s/bin/sbin/ if you think it's a good idea to keep these tools out of the hands of the average user. Next up, it should all be automatic. the ifppc_up/down should be replaced with say, ifppc_wrapper which handles the up, then calls a "call-back program", then handles the down. That way, if PearPC crashes, the wrapper script is still there running so as to clean up after itself. Again, this should be tucked somewhere safe and/or accessible. More safe /usr/sbin, more accessible /usr/bin. But either way, having it in a root owned directory is a good thing. This presents a problem as it requires people to run pearpc with effectively a command line like this: "ifppc_wrapper /path/to/pearpc/exec/ppc" (We want the full path, or else someone could highjack it, and potentially use the ifppc_wrapper for suid arbitrary code execution) This could easily be solved with a PearPC execution script (which Mozilla uses) where the users types: "PearPC" or "pearpc" (depending on if you like capitals in your filename... I'm not much of a fan myself) which references a script which exec()s into ifppc_wrapper (for speed, no new process creation required) with the sufficiently altered command-line arguments to point it directly to the pearpc executable, allowing for as much or as little security as the maintainer desires. I honestly couldn't see any major distribution including PearPC until such an issue would be addressed, because of the gaping security holes in our networking code for Linux. Of course, I imagine that most people are still working with the typical method of ./configure && make; then running ppc directly from the directory that you compiled it in. If we can break away from that, it'd be good. Expect people, (heck, require this) to do a "make install", that's how well behaved Linux programs work. Plus, we could put our scripts in ${prefix}/share/pearpc which is a nice convenient place to stuff our sensitive files to be safe and secure, and in fact, out of almost everyone's execution paths (unless they're nuts.) --=20 Daniel Foesch |