Re: KAuth and switching nodes
Re: KAuth and switching nodes
- Subject: Re: KAuth and switching nodes
- From: David Allouch <email@hidden>
- Date: Sun, 29 Jan 2006 21:11:35 +1300
- Thread-topic: KAuth and switching nodes
Would be safer for me to hijack the sysent entry than play with the vmspace.
Now I 'only' need to find a way to get the sysent symbol from the kmem.
If anyone tried that before, and has some hints on the best way to do it...
Most welcome...
Going to take me a day or two but the result should be more stable than
anything using procfs.
D.
On 1/28/06 10:57 AM, "Terry Lambert" <email@hidden> wrote:
> 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
| David Allouch | email@hidden |
Benjamin Franklin said, "Up sluggard and waste not life; In the grave will
be sleeping enough.²
_______________________________________________
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