August 2007 - Darwin-kernel

RE: printf logs are not getting printed properly on system.log
by Jernej Azarija 23 Aug '07

23 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha1; c=relaxed/simple; d=hermes-softlab.com; s=hsl2007; t=1187856894; bh=viAatDkVFEtV0DP2WyPfE8Ea2tE=; h=X-Virus-Scanned:Received:Received:X-MimeOLE:Content-class: MIME-Version:Content-Type:Subject:Date:Message-ID:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:References:From:To: Cc; b=T7FMMM5MV4NkM+aq7COaD3PjygO6RlwkZYOk+eQvRdExsrCMJirKNOfOBcij 7HPEbTAzqzcIux69jkFUpIcoe9cnIrryP7A2DJ1PN9L9XBLanKI/fUPZ91tERcWVKAR lSYWQ/wjWewGwSLWKn4X/e+Q3WlkHsRQ46FYx1dzt3P8= Thread-index: AcflWFUwhETVKpfAR6aUzhVJMqMSQQABJJEU Thread-topic: printf logs are not getting printed properly on system.log _______________________________________________ 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: printf logs are not getting printed properly on system.log
by Jeremy Pereira 23 Aug '07

23 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 23 Aug 2007, at 06:05, JanakiRam wrote: Hi ALL, -JanakiRam. _______________________________________________ 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/adc%40jeremyp.net _______________________________________________ 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'm newbie to this kernel prorgamming. Please clarify my following query. I'm using printf for logging messages from my kext. One observation is all my logs are not getting printed when i start my kext using kextload. Its not consitent , how many logs are going to get printed every time i load the kext. Please help me to solve this. Thanks in Advance. I've seen the same problem. I assumed it was because of overrunning some buffer somewhere i.e. producing too much output for the kernel logging system to cope with. This email sent to adc(a)jeremyp.net This email sent to site_archiver(a)lists.apple.com

1 0

printf logs are not getting printed properly on system.log
by JanakiRam 23 Aug '07

23 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Outb37hruXv8Vo4O4bbEsddk2OaPWWiwXwTjwWC+njN37d2bkqPB5wlsQ6Ge4VebBfZaybiTvlfbp1IKXtEouQ2/IhaWt68cu+16kG6iriSvbSRTFDVIkFmqDF+4tSf2+aYpOGZB42rBZeSJRYCzn/H0a8cpP+RdaM1woTdi0m4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=StHc2sqnXlf0qUEL94TPXIMWtIZH6xZlHKW5gBKVrrPvj3fNu3a7lyuztU0SZ7uiAlFqDy6cH4GrkbzM/9TX/LfgnivF04uphlF/dnivmhzKPqrV2l7BY4OQa9l7AK1KGZN00v3nTR++uqqtHuRtfQmfLmkSlXGARa+jbPrHG9Q= _______________________________________________ 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

Wait-Queue Panic with system level calls.
by JanakiRam 22 Aug '07

22 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=B632vxaleJiIdl1kE3mDg73fjfmaBK90F+o+NiSzxA+ty9qP7bX9lJe4VSl4joVUozkhZcLo8nvDQGmUaA0grTIOUO5AKYcqYX2BUdfP9EtZE5+9DDdsUMtgzPNZ1f0GtmNCLsT9n8XM7luTaPX434gsIDaQKwzxHxZH32iq2Ck= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HwGpQIpv+Ar3SFDRdioYT3xo/5gHzBHXtlZp7sbXQVgicpzxbh3ZyZ0GT/T9mjvOgTyUY/a639NJwVBLGxZp7ZROXYZTtbTPkolh5K1RmGwOhoSx2HLZpourtwJQgkvC7ZtgX5jgbfz+BM0PeqZCBX/9MwhSVCIICsbeq2C26Hs= _______________________________________________ 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: KUNCUserNotificationCallBack
by Terry Lambert 21 Aug '07

21 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I understand why a GUI agent cannot run as root and I accept that. This should actually be enough to avoid an attacker subverting it. The only way that I can think of to get GUI displayed in a way that can't be interfered with by a user (this is, without them explicitly authenticating as admin) is via an authorisation plug-in. Authorisation plug-ins are hosted by a process ("SecurityAgent") that can display GUI but is run by a user that's distinct from all logged in users ("securityagent"). And it's no coincidence that Mac OS X's passwords dialogs are brought up by this process. You mentioned this earlier. I'm a little fuzzy on the premise. -- 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 Aug 21, 2007, at 8:44 AM, Eric Long wrote: My software protects a user's data from being copied, while at the same time permitting an authorized user to have the privilege. If the agent is picked off and I can't communicate, I can't authorize. If I can't authorize, I can't allow privileges, nor can I explain why things are in this state to the user. It's possible the "bad guy" might be smart enough to re-launch the agent to avoid obvious detection, before the user returns, but if not, things will just be silently locked down when the user returns. You probably need to start here; there's also sample code on getting authorized to run with root privileges or as a member of the "admin" group: <http://developer.apple.com/referencelibrary/Security/index.html#//apple_ref… > In the initial email on this topic, I was hoping I could actually authorize from the kernel to end the lockdown, but it was quickly pointed out that I can't do that. I then turned the discussion towards posting any kind of alert from the kernel. Correct; the kernel doesn't know from authorization; it only knows from initial privilege, inherited privilege, and privilege escalation (which should only ever be used rarely, and mostly belongs in programs like /bin/login). When the kernel makes a decision based on a user policy, it does it by comparing 32 bit integers shoved down into the kernel from user space at login time by calling setgroups/initgroups/setegid/setregid/setuid/ setreuid/etc. family of functions to establish a credential and to either opt in or out of external group resolution participation (external group resolution for support more than 16 groups by answering the question "Is user X a member of group Y?"). External resolution is only meaning for a user who is a member of more than 16 groups (otherwise, the kernel has the information in hand already), and for when you are a member of a security association (e.g. a corporate KDC, LDAP server, Microsoft Active Directory, etc.). Everything having to do with GUIDs, UUIDs, and other things, ends up going to the user space external resolver -- the kernels way of saying "I don't know from GUIDs and UUIDs and so on; please give me a 32 bit integer that I can use, in exchange for these fine, but confusing things I don't care about". In the end, it's all about comparing integers from the kernels point of view: authorization never really happens in the kernel at all: it only every happens in user space by a process with initial or escalated privileges starting a child process on your behalf (the system wide launchd, loginWindow, /bin/login, sshd, ftpd, and a few others - usually disabled by default - can do this). My thinking was to log all anomalies, so there's a record of events, and post periodic timed alerts until the problem is dealt with, so we can inform the user how to end the lockdown. But apparently I can't do that either. The best you are going to get is an app that launchd keeps running in the user's workspace that can put up UI, and a protocol that makes sure it's doing its job of managing the UI properly by responding to requests for information from the kernel via a Mach port, socket, or one of the other user/kernel IPC facilities documents at <http://developer.apple.com/ >. Are you suggesting that my daemon, which is run as root, could interact with this to get GUI to display indirectly in the current user's log-in session? That's basically it. See the security link I posted above for sample code how to talk to securityd. This email sent to site_archiver(a)lists.apple.com

1 0

Re: KUNCUserNotificationCallBack
by Eric Long 21 Aug '07

21 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcfkCjQ0crSqYk/9EdyxYgAX8si2KA== Thread-topic: KUNCUserNotificationCallBack User-agent: Microsoft-Entourage/11.3.6.070618 > aunchd agents are run by a per-user launchd. > That per-user launchd is owned by the user. Thus, the user can muck > with that instance of launchd as much as they like. Ok. My misunderstanding. > From looking at the rest of your post, it seems that you're at a > fundamental impasse: > > A. You want your agent to run as root so that the user can't kill it. > > B. Your agent must display GUI. > > C. Apple does not want GUI programs running as root because it's a > security hole. We don't do this on our system, and we recommend that > you not do it either. I understand why a GUI agent cannot run as root and I accept that. My software protects a user's data from being copied, while at the same time permitting an authorized user to have the privilege. If the agent is picked off and I can't communicate, I can't authorize. If I can't authorize, I can't allow privileges, nor can I explain why things are in this state to the user. It's possible the "bad guy" might be smart enough to re-launch the agent to avoid obvious detection, before the user returns, but if not, things will just be silently locked down when the user returns. In the initial email on this topic, I was hoping I could actually authorize from the kernel to end the lockdown, but it was quickly pointed out that I can't do that. I then turned the discussion towards posting any kind of alert from the kernel. My thinking was to log all anomalies, so there's a record of events, and post periodic timed alerts until the problem is dealt with, so we can inform the user how to end the lockdown. But apparently I can't do that either. > The only way that I can think of to get GUI displayed in a way that > can't be interfered with by a user (this is, without them explicitly > authenticating as admin) is via an authorisation plug-in. > Authorisation plug-ins are hosted by a process ("SecurityAgent") that > can display GUI but is run by a user that's distinct from all logged > in users ("securityagent"). And it's no coincidence that Mac OS X's > passwords dialogs are brought up by this process. You mentioned this earlier. I'm a little fuzzy on the premise. Are you suggesting that my daemon, which is run as root, could interact with this to get GUI to display indirectly in the current user's log-in session? Eric _______________________________________________ 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: KUNCUserNotificationCallBack
by Quinn 21 Aug '07

21 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com What I'm saying is, launchd runs as root. You cannot kill launchd without authenticating. I have an agent that runs as it should in each user session, not as root. Someone could maliciously kill my agent to circumvent the protection system it is a part of. launchd is extremely fast at relaunching it. I know it will get relaunched if I can use launchd, unless someone with root access gets involved trying to kill it. So, I expect to be able to post UI through it at some instance. A. You want your agent to run as root so that the user can't kill it. B. Your agent must display GUI. Let's take a step back and look at your original request: I see a documented example of using KUNCUserNotificationDisplayFromBundle to display an authentication dialog from a kext. I want to use this functionality in case my daemon or agent gets into trouble somehow, and I need to give the user some options. In my KUNCUserNotificationCallBack, after I get the user's name/password, how do I validate that this is a user name and password for a user with admin privileges? I haven't been able to find the way to do this in the kernel. $ killall UserNotificationCenter 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 8:28 -0700 20/8/07, Eric Long wrote: OK, the above shows a misunderstanding that I need to correct before going any further. launchd agents are run by a per-user launchd. That per-user launchd is owned by the user. Thus, the user can muck with that instance of launchd as much as they like. The root launchd /is/ owned by root, but it is not involved in launching agents. The above is true on Mac OS X 10.4.x and future system software. The design goal is to reduce the risk of privileges leaking from the root launchd into an agent. >From looking at the rest of your post, it seems that you're at a fundamental impasse: C. Apple does not want GUI programs running as root because it's a security hole. We don't do this on our system, and we recommend that you not do it either. At 11:45 -0700 17/8/07, Eric Long wrote: How do you think KUNCUserNotificationDisplayFromBundle is implemented? Well, it turns out that the GUI is displayed by an agent. The actual implementation is very scary and likely to change in the future, but the take home point is that the program displaying the dialogs is run as the user who is currently logged in on the console. You can see this by posting a notification and then running Quartz Debug to see which process opened that window. You'll see that it's "UserNotificationCenter". You can then run: $ ps -o uid,ruid,gid,rgid,ucomm -p `killall -s UserNotificationCenter | cut -d ' ' -f 3` UID RUID GID RGID UCOMM 2000 2000 2000 2000 UserNotification to see the EUID, RUID, EGID, and RGID of the process. Lo, it's you! And if you want the notification to go away, just kill it. The only way that I can think of to get GUI displayed in a way that can't be interfered with by a user (this is, without them explicitly authenticating as admin) is via an authorisation plug-in. Authorisation plug-ins are hosted by a process ("SecurityAgent") that can display GUI but is run by a user that's distinct from all logged in users ("securityagent"). And it's no coincidence that Mac OS X's passwords dialogs are brought up by this process. It's possible that you could construct a fully bulletproof solution using this mechanism, but I can't be sure without evaluating the issue in a lot more detail. This email sent to site_archiver(a)lists.apple.com

1 0

Re: KUNCUserNotificationCallBack
by Jeremy Pereira 21 Aug '07

21 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 20 Aug 2007, at 16:28, Eric Long wrote: I think you're mixing up what launchd will do. By definition an agent is running on behalf of a particular user, and thus doesn't run as root. o Running a GUI program as root is /strongly/ discouraged. o Vulnerable to what, exactly? o Authorization Services already has an architecture for running GUI-oriented security code as a trusted user that is not run (uid 92, "securityagent"). This is the user that displays the standard authorisation dialogs, and that's one of the many reasons we recommend that you do authorisation via Authorization Services. Eric _______________________________________________ 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/adc%40jeremyp.net This email sent to adc(a)jeremyp.net _______________________________________________ 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.… If I can't use launchd, I must create my own launch app to keep up my agent and add a log-in item for it, my "keep it up" app is being run with the log-in user's privileges. Anyone can kill it, then kill the agent, then I have no UI to tell the user something is wrong. No. Only the user that owns the process or a user with admin privileges. In the former case, see my comments below, in the latter case you've already lost. Now, granted, the person killing things off isn't the beneficiary of the UI I might present, pre-supposing that this is someone sneaking his attack while the user has stepped away and the machine was not locked it in screensaver mode, or something similar. I think the ability to subvert your UI agent is the least of the security issues in this circumstance. The attacker already has access to all of the logged in person's files including, incidentally, the ~/Library/LaunchAgents directory. But, the actual user, on return, will go on thinking things are normal, if I can't display something to indicate what happened. I can log the events, sure, but that's not exactly the siren I'd like. This is an ongoing protection and I'd like to be able to periodically notify the user of the problem until it is corrected. I could take extreme action and lock everything down to ensure the user is protected, but that will lead to confusion unless I can also make the user aware of why things are locked down. Given that the problems with launchd and gui agents is limited to 10.4.x, I could use the KUNC API still present in 10.4.x to address this problem only on those systems. But is that the right thing to do? Is there a better way? This email sent to site_archiver(a)lists.apple.com

1 0

Re: KUNCUserNotificationCallBack
by Eric Long 20 Aug '07

20 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcfjPru0+ixFHk8xEdyJjAAX8si2KA== Thread-topic: KUNCUserNotificationCallBack User-agent: Microsoft-Entourage/11.3.6.070618 > I think you're mixing up what launchd will do. By definition an > agent is running on behalf of a particular user, and thus doesn't run > as root. > o Running a GUI program as root is /strongly/ discouraged. > > o Vulnerable to what, exactly? > > o Authorization Services already has an architecture for running > GUI-oriented security code as a trusted user that is not run (uid 92, > "securityagent"). This is the user that displays the standard > authorisation dialogs, and that's one of the many reasons we > recommend that you do authorisation via Authorization Services. I get the limitation of not being able to authorize in the kernel. I also understand that my agent should run in a user session and not as root. I accept both limitations. But having no ability to even get an alert message out is a problem for me. What I'm saying is, launchd runs as root. You cannot kill launchd without authenticating. I have an agent that runs as it should in each user session, not as root. Someone could maliciously kill my agent to circumvent the protection system it is a part of. launchd is extremely fast at relaunching it. I know it will get relaunched if I can use launchd, unless someone with root access gets involved trying to kill it. So, I expect to be able to post UI through it at some instance. If I can't use launchd, I must create my own launch app to keep up my agent and add a log-in item for it, my "keep it up" app is being run with the log-in user's privileges. Anyone can kill it, then kill the agent, then I have no UI to tell the user something is wrong. Now, granted, the person killing things off isn't the beneficiary of the UI I might present, pre-supposing that this is someone sneaking his attack while the user has stepped away and the machine was not locked it in screensaver mode, or something similar. But, the actual user, on return, will go on thinking things are normal, if I can't display something to indicate what happened. I can log the events, sure, but that's not exactly the siren I'd like. This is an ongoing protection and I'd like to be able to periodically notify the user of the problem until it is corrected. I could take extreme action and lock everything down to ensure the user is protected, but that will lead to confusion unless I can also make the user aware of why things are locked down. Given that the problems with launchd and gui agents is limited to 10.4.x, I could use the KUNC API still present in 10.4.x to address this problem only on those systems. But is that the right thing to do? Is there a better way? Eric _______________________________________________ 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

Decreasing MTU size for stack and upper NKE's but not for the driver itself
by Platon Fomichev 20 Aug '07

20 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Gentlemen, good day to you. Best regards, Stauff__ _______________________________________________ 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 am creating a port of a Win32 NDIS intermediate driver. The main task I am currently working on is bytes reservation. Consider the following task - I need to reserve some bytes in every packet - even when it's filled up to MTU so I can insert additional special bytes from the driver. In Windows I do so by changing MTU for all upper layer drivers so they see driver MTU minus let's say 28 bytes which I grab for myself. I need to solve the same task on Mac, however I see that there is no special means to switch MTU per-layer but only globally. However still I need somehow to force all upper NKE's and stack to believe that MTU is 28 bytes less but network card driver itself should treat such packets as O.K. I will dig into the kernel but may be there is a known way to do so. Thanks in advance. Just in case NKE I am working on is an interface filter - I need to work on packets after fragmentation and I need to access link layer info. This email sent to site_archiver(a)lists.apple.com

1 0