Re: KUNCUserNotificationCallBack
Re: KUNCUserNotificationCallBack
- Subject: Re: KUNCUserNotificationCallBack
- From: Terry Lambert <email@hidden>
- Date: Tue, 21 Aug 2007 16:11:30 -0700
On Aug 21, 2007, at 8:44 AM, Eric Long wrote:
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.
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/doc/uid/TP30000943-TP30000434
>
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/
>.
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.
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden