Re: KAuth and switching nodes
Re: KAuth and switching nodes
- Subject: Re: KAuth and switching nodes
- From: Mike Smith <email@hidden>
- Date: Sun, 29 Jan 2006 13:32:18 -0800
On Jan 29, 2006, at 12:11 AM, David Allouch wrote:
Would be safer for me to hijack the sysent entry than play with the
vmspace.
David,
None of what you're talking about so far is "safe". Perhaps if you
would
condescend to tell us what you're actually trying to do, you could
get some
better advice.
Now I 'only' need to find a way to get the sysent symbol from the
kmem.
This is not supported/permitted.
If anyone tried that before, and has some hints on the best way to
do it...
Most welcome...
There is no "best" way to do it; a number of changes were made in 10.4
specifically to provide supportable alternatives to folks that felt
the need
to intercept system calls.
By being all dark and mysterious, you're directly preventing us from
helping you do what you're trying to do in a legitimate fashion.
= Mike
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