January 2006 - Darwin-kernel

Re: Kernel NKE projects user space daemon.
by Mike Smith 04 Jan '06

04 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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: Kernel NKE projects user space daemon.
by Rohan Lloyd 04 Jan '06

04 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 4 Jan 2006, at 11:31 AM, Terry Lambert wrote: something like: main() { // relinquish suid until it is required seteuid(getuid()); ... // this bit of code requires suid seteuid(0); ... // no longer needed revert back to real uid seteuid(getuid()); } -- Rohan Lloyd _______________________________________________ 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.… To answer your original question, though, the security guys generally frown on SUID/SGID anything, even if it's an ordinary user the thing impersonates. I agree with the above. But if you *do* find yourself using suid/ sgid, make sure you don't run the whole process as root. You should use seteuid() to toggle between the real uid and the setuid. Typically the very first thing you should do is revert back to the real uid. Then call seteuid() when you need root permission, and revert back immediately afterwards. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel NKE projects user space daemon.
by Terry Lambert 04 Jan '06

04 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 3, 2006, at 2:09 PM, Brian Bergstrand wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 3, 2006, at 3:47 PM, Mike Smith wrote: On Jan 3, 2006, at 12:40 PM, Brian Bergstrand wrote: On Jan 3, 2006, at 8:31 AM, matt jaffa wrote: = Mike -- 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.… I have a NKE project that needs a user space daemon to be running to get information back from the user. I have this working and everything, and have a daemon launched for each individual user that runs the program. I have my user space daemon with these privileges, 4755, which means the setuid bit is set for my daemon executable so that it can elevate itself to perform a process id lookup. My question is what does Apple/Security feel about my application having the setuid bit set? I'm a little confused about "perform a process id lookup" though. What are you trying to do, and what specific interface (s) are you using that require privilege? I think he means that KERN_PROCARGS returns an error when you try to get info about processes running with a different uid than the calling application (unless you are root). In my case I only care about the full exec path and not the program args. You should not depend on any path information associated with a running process. However, KERN_PROC_PID can be used to get the process struct of any process from a non-root app and the kp_proc.p_comm member will give you a limited name (16 bytes and not the full path). The full path is very useful for use as an arg to LSCopyDisplayNameForURL (), but pcomm suffices as a fall back. Is there some other way for a non-root process to get the full exec path of any other process (including root owned)? No. In addition, there is no guarantee that the path is correct, that the file that is present at that path is the one being executed, that the path is acccessible or even valid for your context, or that there even was a path to begin with. Any information you get from p_comm or the KERN_PROCARGS sysctl is purely informative, and you should not depend on it in any fashion whatsoever. If you need a guaranteed association between running processes and filesystem identities you need to look at a higher level, and accept that there are processes and tasks which will fall outside the scope of the information available at that level. I know and accept all of that - for my app, the information is purely informative to the user. There are no permanent associations/ assumptions made about the path. It's that pcomm can contain a truncated name and the user (not my app) may not be able to associate the truncated name with an actual application. Most of the time, pcomm suffices so it's not a big problem. Brian Bergstrand When a process is started after a vfork or fork plus an execve, the kauth subsystem gets a callback for KAUTH_FILEOP_EXEC with the vp to kauth_scope_fileop listeners. There is a small performance penalty on a number of paths for having any listeners in this scope (this is documented in the source code for kern_authorization.c, which I suggest you understand if you are going to attempt to use this to solve your problem). This would let you associate the path (obtained via the KPI vn_getpath () on the vnode) that was used to look up with a PID (using proc_pid() on the current process). You'd then communicate this association to your daemon, for it to cache. The vn_getpath is a tricky KPI; it's final argument is both an in and an out value, so you will need to reset it to your buffer size on each call (which should be PATH_MAX from <sys/syslimits.h>). You would not get any notification via kauth when the process went away (for complex reasons having to do with the inability of some network FS's to rename open files, without non-standard extensions to their protocols), so you would need to either keep a potentially pretty big cache of the information, or occasionally poll in user space using the kill(pid, 0) existence test for processes (-1 & ENOENT=no process, -1 & EPERM=process exists, but you can't signal it, 0=process exists and you can signal it, but no signal was actually sent) to clean out the stale cache entries. As Mike pointed out though, this would only get you to the point of you knowing what the file that was there was named before the attempt to contact the network, so what file's there at the time you want to check and looks "mostly harmless" is not necessarily actually the code that's running. To answer your original question, though, the security guys generally frown on SUID/SGID anything, even if it's an ordinary user the thing impersonates. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel NKE projects user space daemon.
by Brian Bergstrand 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 3, 2006, at 3:47 PM, Mike Smith wrote: On Jan 3, 2006, at 12:40 PM, Brian Bergstrand wrote: On Jan 3, 2006, at 8:31 AM, matt jaffa wrote: = Mike Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDuvYRedHYW7bHtqIRArrSAJsH/QHXcEbDEy7eBj6ef1COeN3H7gCeKqK5 /X8vro2VcXhPjgZqso2umlE= =y86Y -----END PGP SIGNATURE----- _______________________________________________ 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.… I have a NKE project that needs a user space daemon to be running to get information back from the user. I have this working and everything, and have a daemon launched for each individual user that runs the program. I have my user space daemon with these privileges, 4755, which means the setuid bit is set for my daemon executable so that it can elevate itself to perform a process id lookup. My question is what does Apple/Security feel about my application having the setuid bit set? I'm a little confused about "perform a process id lookup" though. What are you trying to do, and what specific interface (s) are you using that require privilege? I think he means that KERN_PROCARGS returns an error when you try to get info about processes running with a different uid than the calling application (unless you are root). In my case I only care about the full exec path and not the program args. You should not depend on any path information associated with a running process. However, KERN_PROC_PID can be used to get the process struct of any process from a non-root app and the kp_proc.p_comm member will give you a limited name (16 bytes and not the full path). The full path is very useful for use as an arg to LSCopyDisplayNameForURL (), but pcomm suffices as a fall back. Is there some other way for a non-root process to get the full exec path of any other process (including root owned)? No. In addition, there is no guarantee that the path is correct, that the file that is present at that path is the one being executed, that the path is acccessible or even valid for your context, or that there even was a path to begin with. Any information you get from p_comm or the KERN_PROCARGS sysctl is purely informative, and you should not depend on it in any fashion whatsoever. If you need a guaranteed association between running processes and filesystem identities you need to look at a higher level, and accept that there are processes and tasks which will fall outside the scope of the information available at that level. I know and accept all of that - for my app, the information is purely informative to the user. There are no permanent associations/ assumptions made about the path. It's that pcomm can contain a truncated name and the user (not my app) may not be able to associate the truncated name with an actual application. Most of the time, pcomm suffices so it's not a big problem. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel NKE projects user space daemon.
by Mike Smith 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 3, 2006, at 12:40 PM, Brian Bergstrand wrote: On Jan 3, 2006, at 8:31 AM, matt jaffa 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.… I have a NKE project that needs a user space daemon to be running to get information back from the user. I have this working and everything, and have a daemon launched for each individual user that runs the program. I have my user space daemon with these privileges, 4755, which means the setuid bit is set for my daemon executable so that it can elevate itself to perform a process id lookup. My question is what does Apple/Security feel about my application having the setuid bit set? I'm a little confused about "perform a process id lookup" though. What are you trying to do, and what specific interface(s) are you using that require privilege? I think he means that KERN_PROCARGS returns an error when you try to get info about processes running with a different uid than the calling application (unless you are root). In my case I only care about the full exec path and not the program args. You should not depend on any path information associated with a running process. However, KERN_PROC_PID can be used to get the process struct of any process from a non-root app and the kp_proc.p_comm member will give you a limited name (16 bytes and not the full path). The full path is very useful for use as an arg to LSCopyDisplayNameForURL(), but pcomm suffices as a fall back. Is there some other way for a non-root process to get the full exec path of any other process (including root owned)? No. In addition, there is no guarantee that the path is correct, that the file that is present at that path is the one being executed, that the path is acccessible or even valid for your context, or that there even was a path to begin with. Any information you get from p_comm or the KERN_PROCARGS sysctl is purely informative, and you should not depend on it in any fashion whatsoever. If you need a guaranteed association between running processes and filesystem identities you need to look at a higher level, and accept that there are processes and tasks which will fall outside the scope of the information available at that level. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel NKE projects user space daemon.
by matt jaffa 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EzzlC4O4VOiGB7+YRxOfm1jtXF8+ifLp7u7wDekOk5KiXC5g7YxO+yOQ0mLEjYgG+muICiEI/YDD7pPKukROklE8FX+7wBdDMNuguMtuSqil+kdvkYVuq4Ru9KiL9Qbvzvtq7CIQb0cWGcwHvoE/h+TRPbtze6DbNSimVlj+bgA= _______________________________________________ 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: Kernel NKE projects user space daemon.
by matt jaffa 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fx4/eF5UfaMsWxqzpYDZdJQ+mMs85pbMBhzC7gV09br5D9pT1y+uvzLnr2kbaxFUgOwPwsiGw7W9r4CXgyiuI8Ul8dfzjTQvFacctVdaMc3PkG6bL7C6hNRzMtHu0u5g0o8unQeVnEJqttuckJ1/vYs3XehNUFkwIKZrEdrec+c= _______________________________________________ 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: Kernel NKE projects user space daemon.
by Mike Smith 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 3, 2006, at 8:31 AM, matt jaffa wrote: Matt, = 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.… I have a NKE project that needs a user space daemon to be running to get information back from the user. I have this working and everything, and have a daemon launched for each individual user that runs the program. I have my user space daemon with these privileges, 4755, which means the setuid bit is set for my daemon executable so that it can elevate itself to perform a process id lookup. My question is what does Apple/Security feel about my application having the setuid bit set? Firstly, many thanks for picking a sensible architecture for your application. I'm a little confused about "perform a process id lookup" though. What are you trying to do, and what specific interface(s) are you using that require privilege? As a general rule, having your daemon run setuid inside the user's environment is discouraged. This email sent to site_archiver(a)lists.apple.com

1 0

Kernel NKE projects user space daemon.
by matt jaffa 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=RI73qNnROrdsiOSc6M3UNSNEcv2x30KGsxt75yiBjs008fImliMjuwGbapV1TUqgJqZBSPW2ZWXR0mHDEOE4rIfDYW0Y/cmml2Ul/3QZxRzEbWlyPjz5wWNxHTSbIt+DtYMBEolOE7aOJnn+WyhGch8HNhclFxxdjAMpEFNtjIA= _______________________________________________ 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: OSMalloc Fails (returns 0)
by Terry Lambert 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- 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.… On Dec 25, 2005, at 2:22 PM, Russ Seehafer wrote: I have a socket filter nke based on the tcplognke sample. I make a call to OSMalloc with the gOSMallocTag to malloc some space for a struct inside the nke's tl_attach_fn function. Usually this works great, but every now and then the malloc fails, usually after the system has been running for a while. Anyone know why this would happen? I couldn't find any documentation on it. In general, this shouldn't happen unless you are leaking memory (e.g. not freeing the memory on detach, attaching too many times, etc.). You can use the command "zprint" to display memory usage by zone on the system; I suspect you will see one of the kalloc.# zones that is the size of your structure (or larger, if your structure is not an even power of 2 in size) has hit its maximum number of elements. If you need a lot of memory and are willing to manage it yourself, you should alloc a page at a time; then you will also allocate pageable memory instead of wired memory (internally OSMalloc will call either kalloc() or kmem_alloc_pageable()). This email sent to site_archiver(a)lists.apple.com

1 0