site_archiver@lists.apple.com Delivered-To: darwin-kernel@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@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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@lists.apple.com