May 2006 - Darwin-kernel - lists.apple.com

Re: loading kext from a daemon program
by Kevin Elliott 07 May '06

07 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Am 06.05.2006 um 11:51 schrieb Michael Smith: Just to make this COMPLETELY explicit. At 13:02 +0200 on 5/6/06, Markus Hitter wrote: why are the spawn family of interfaces so popular, if system(3) is so great? system(3) is a convenience function for the more common cases of spawning? I can't see a >stringent need to avoid this function either. If you call system, then the launching user environment (that is, the user and anyone who can alter his system) has complete control over what your launch command actually does: -He can point you at a different binary -He can probably screw with your arguments Yes, their is an argument that if the user enviroment can be modified then the person is already screwed. But why make it any easier? If fork/exec are a pain, then use one of the higher level API's! Cocoa has a very nice one, and I believe Carbon does as well. System is not the answer. -- ______________________________________________________ Arguing with an engineer is like wrestling with a pig in mud. After a while, you realize the pig is enjoying it. ______________________________________________________ Kevin Elliott <mailto:kelliott@mac.com> AIM/iChatAV: kelliott(a)mac.com (video chat available) ______________________________________________________ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Markus Hitter 06 May '06

06 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Am 06.05.2006 um 11:51 schrieb Michael Smith: Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… why are the spawn family of interfaces so popular, if system(3) is so great? system(3) is a convenience function for the more common cases of spawning? I can't see a stringent need to avoid this function either. This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Michael Smith 06 May '06

06 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 5, 2006, at 2:44 AM, Quinn wrote: Alternately, the fork()/exec()/wait() is encapsulated for you as well, if you use the system() library routine. Although I'm always leery of using "system" from a privileged program, like a daemon. This is mostly relevant when the program is setuid (where a potentially malicious caller can set up a specific environment to cause problems), but I take the overly cautious route and avoid it in any privileged program. I'm with Quinn here. System(3) belongs with gets(3) in that pile of tools that you never, ever use. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On May 5, 2006, at 2:23 PM, David Gatwood wrote: On May 5, 2006, at 12:02 PM, Michael Smith wrote: At 13:33 -0700 4/5/06, Terry Lambert wrote: I disagree. If you use full paths and properly vet the arguments for shell escapes (or if the paths and arguments are not extracted from user input in such a way that embedded shell escapes would be possible), the system(3) call is not substantially less safe than fork and exec. This is rather like saying that if you declaw, de-fang and hogtie a tiger, it's a perfectly safe housepet. Then later some other poor soul discovers that tigers are heavy when it rolls over and crushes them. For that matter, the security difference between system(3) and popen (3) is zero, and the alternative to that involves some really, really ugly code (dup2 over top of STDERR_FILENO or whatever). That's just not something that most people will want to do if they can help it. :-) popen(3) belongs in the same pile. And if socketpair(2) is too hard for you, you should not be playing this game. Thus, I don't think it makes sense to suggest avoiding these at all costs. You should, however, be careful when using them. Always use absolute paths. (This is important for some variants of exec(3) as well.) Avoid passing user input in as part of the argument list. If it is necessary to pass user input in as an argument, make sure it doesn't contain anything but letters, numbers, and spaces unless you -know- how to properly quote shell commands. And so on. ... don't forget to write your code in such a fashion that it will never, ever be reused, because you can't enforce these constraints when it is. ... don't ever use this code when performance matters, because the shell is typically a pig to start even when all it is going to do is the fork/exec that you should have done yourself. ... don't get too cocky about "absolute paths". / is relative (think chroot(2)). Ask yourself... why are the spawn family of interfaces so popular, if system(3) is so great? This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Jim Thompson 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 5, 2006, at 11:23 AM, David Gatwood wrote: I'm with Quinn here. System(3) belongs with gets(3) in that pile of tools that you never, ever use. Please, we've been doing this for years. Consider your life if the shell took this approach... _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On May 5, 2006, at 12:02 PM, Michael Smith wrote: I disagree. If you use full paths and properly vet the arguments for shell escapes (or if the paths and arguments are not extracted from user input in such a way that embedded shell escapes would be possible), the system(3) call is not substantially less safe than fork and exec. Of course, by that point, you've written at least as much code as a safe fork()+exec() implementation. For that matter, the security difference between system(3) and popen (3) is zero, and the alternative to that involves some really, really ugly code (dup2 over top of STDERR_FILENO or whatever). That's just not something that most people will want to do if they can help it. :-) Thus, I don't think it makes sense to suggest avoiding these at all costs. You should, however, be careful when using them. Always use absolute paths. (This is important for some variants of exec(3) as well.) This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by David Gatwood 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 5, 2006, at 2:44 AM, Quinn wrote: Alternately, the fork()/exec()/wait() is encapsulated for you as well, if you use the system() library routine. Although I'm always leery of using "system" from a privileged program, like a daemon. This is mostly relevant when the program is setuid (where a potentially malicious caller can set up a specific environment to cause problems), but I take the overly cautious route and avoid it in any privileged program. I'm with Quinn here. System(3) belongs with gets(3) in that pile of tools that you never, ever use. Just my $0.01999999999. David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On May 5, 2006, at 12:02 PM, Michael Smith wrote: At 13:33 -0700 4/5/06, Terry Lambert wrote: I disagree. If you use full paths and properly vet the arguments for shell escapes (or if the paths and arguments are not extracted from user input in such a way that embedded shell escapes would be possible), the system(3) call is not substantially less safe than fork and exec. For that matter, the security difference between system(3) and popen (3) is zero, and the alternative to that involves some really, really ugly code (dup2 over top of STDERR_FILENO or whatever). That's just not something that most people will want to do if they can help it. :-) Thus, I don't think it makes sense to suggest avoiding these at all costs. You should, however, be careful when using them. Always use absolute paths. (This is important for some variants of exec(3) as well.) Avoid passing user input in as part of the argument list. If it is necessary to pass user input in as an argument, make sure it doesn't contain anything but letters, numbers, and spaces unless you -know- how to properly quote shell commands. And so on. This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Michael Smith 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 5, 2006, at 2:44 AM, Quinn wrote: = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 13:33 -0700 4/5/06, Terry Lambert wrote: Alternately, the fork()/exec()/wait() is encapsulated for you as well, if you use the system() library routine. Although I'm always leery of using "system" from a privileged program, like a daemon. This is mostly relevant when the program is setuid (where a potentially malicious caller can set up a specific environment to cause problems), but I take the overly cautious route and avoid it in any privileged program. I'm with Quinn here. System(3) belongs with gets(3) in that pile of tools that you never, ever use. This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Kevin Elliott 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com NSArray* argArray= [NSArray arrayWithObjects: /*List of args*/, NULL; NSString* kextLoatPath= @"/sbin/kextload"; NSTask* taskObj= [NSTask launchedTaskWithLaunchPath: kextLoatPath arguments: argArray]; if(taskObj!= NULL) { [taskObj waitUntilExit]; int termStatus= [taskObj terminationStatus]; } For the archives and completeness, here is what the cocoa version would look like... If your app was crashing with this my first guess was you were releasing one or more of the created objects, which would be wrong. If nothing else jumps out, send me your code snippet off list and I'll take a look. -- ______________________________________________________ Arguing with an engineer is like wrestling with a pig in mud. After a while, you realize the pig is enjoying it. ______________________________________________________ Kevin Elliott <mailto:kelliott@mac.com> AIM/iChatAV: kelliott(a)mac.com (video chat available) ______________________________________________________ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Quinn 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 13:33 -0700 4/5/06, Terry Lambert wrote: Alternately, the fork()/exec()/wait() is encapsulated for you as well, if you use the system() library routine. Although I'm always leery of using "system" from a privileged program, like a daemon. This is mostly relevant when the program is setuid (where a potentially malicious caller can set up a specific environment to cause problems), but I take the overly cautious route and avoid it in any privileged program. This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Rob Crawford 04 May '06

04 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com thank you all, that seemed to do the trick. thanks, Rob On May 4, 2006, at 4:33 PM, Terry Lambert wrote: On May 4, 2006, at 1:04 PM, Matt Ginzton wrote: #include <sys/wait.h> #define PATH_TO_KEXT "/usrlocal/bin/mykext" /* or wherever... */ ... int status; status = system("/sbin/kextload " PATH_TO_KEXT); if (WIFEXITED(status)) { /* kextload exited normally */ if (WEXITSTATUS(status) == 0) { /* and the KEXT was successfully loaded */ .... } else { /* handle the error and quit */ } } else { /* handle the error and quit */ } /* Do my success thing here... */ ... _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… int result = execlp("kextload", "kextload", "<path to my kext>" (char *)0); this does load the kext but exists my daemon program, I am guessing because of what the documentation says that it replaces the current process image with the new process image. The normal Unix way of doing this is a combination of fork, exec, and wait. Fork creates a separate process, in which you can exec kextload, and then the parent process waits for the child to exit. Alternately, the fork()/exec()/wait() is encapsulated for you as well, if you use the system() library routine. Using execlp() is not necessarily the best approach: it exec's a binary using the PATH lookup, which means someone could force your application to run malicious code as root by changing the PATH environment variable so that their trojan, also named "kextload", is the first "kextload" it sees and executes. If you have to do this, for simplicity (safety) sake, I would recommend using an absolute path, and the simplest method that would let you check the failure of the kextload command, e.g.: NB: You can be marginally faster by unrolling the function to avoid the use of the shell interpreter by system(); however safety should not be impacted by this, since the path to the shell is hard-coded in libc, and the "-c" argument makes it ignore the circumvention points that would otherwise be in effect if you did it yourself and forgot the "-c". -- Terry This email sent to site_archiver(a)lists.apple.com

1 0

Re: loading kext from a daemon program
by Terry Lambert 04 May '06

04 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 4, 2006, at 1:04 PM, Matt Ginzton wrote: #include <sys/wait.h> #define PATH_TO_KEXT "/usrlocal/bin/mykext" /* or wherever... */ ... int status; status = system("/sbin/kextload " PATH_TO_KEXT); if (WIFEXITED(status)) { /* kextload exited normally */ if (WEXITSTATUS(status) == 0) { /* and the KEXT was successfully loaded */ .... } else { /* handle the error and quit */ } } else { /* handle the error and quit */ } /* Do my success thing here... */ ... -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… int result = execlp("kextload", "kextload", "<path to my kext>" (char *)0); this does load the kext but exists my daemon program, I am guessing because of what the documentation says that it replaces the current process image with the new process image. The normal Unix way of doing this is a combination of fork, exec, and wait. Fork creates a separate process, in which you can exec kextload, and then the parent process waits for the child to exit. Alternately, the fork()/exec()/wait() is encapsulated for you as well, if you use the system() library routine. Using execlp() is not necessarily the best approach: it exec's a binary using the PATH lookup, which means someone could force your application to run malicious code as root by changing the PATH environment variable so that their trojan, also named "kextload", is the first "kextload" it sees and executes. If you have to do this, for simplicity (safety) sake, I would recommend using an absolute path, and the simplest method that would let you check the failure of the kextload command, e.g.: NB: You can be marginally faster by unrolling the function to avoid the use of the shell interpreter by system(); however safety should not be impacted by this, since the path to the shell is hard-coded in libc, and the "-c" argument makes it ignore the circumvention points that would otherwise be in effect if you did it yourself and forgot the "-c". This email sent to site_archiver(a)lists.apple.com

1 0