Re: KAuth and switching nodes
Re: KAuth and switching nodes
- Subject: Re: KAuth and switching nodes
- From: Terry Lambert <email@hidden>
- Date: Fri, 27 Jan 2006 13:57:49 -0800
On Jan 27, 2006, at 10:26 AM, Mike Smith wrote:
On Jan 27, 2006, at 5:10 AM, David Allouch wrote:
Ok, so I went through the KAuth and I am really impressed.
This is going to be really useful for anti-viruses and auth. Not
talking about the blocking of traced calls.
Now there is one thing I am missing in my kext. I am going to spend
the week on it so I was wondering if anyone could point me to the
right direction.
Kauth pass a vnode to the listener which is fine for allow/deny
functionality.
What I have in the code I am porting (on top of allow/deny) is the
additional functionality of replacing the vnode with a different
pointer. (Don’t ask why, too long to explain)
This is not permitted.
Don't ask why, it would take too long to explain.(1)
The direction I am heading to right now is to look at the process
structure and compare/replace the vnode. Ugly but actually may work.
No, it won't work. The proc structure is opaque to loaded kauth
modules, and assuming you are referring to the text vnode for a
newly-starting process, it's not in there anyway.
A neat bonus to us not relying on it being there is that it's
impossible to spoof it; the vp reference in question is held by the VM
system, and there's no way for anyone to change it on us without
walking all the VM structures. It also means that anyone who copies
or modifies the backing file for a running program triggers a copy-on-
write, so that the running program won't crash, and won't run the
modified code. This has obvious security benefits, and it also has
the benefit of allowing you to, for example, untar a new copy of tar
on top of the running copy of tar, without breaking your system (think
software update).
= Mike
(1) I would consider an exchange of hostages. Show me yours and
I'll show you mine; that sort of thing...
Sounds eminently fair to me... 8-).
-- 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