Re: Hooking mount events from within kernel.
Re: Hooking mount events from within kernel.
- Subject: Re: Hooking mount events from within kernel.
- From: Terry Lambert <email@hidden>
- Date: Tue, 26 Aug 2008 09:59:08 -0700
On Aug 26, 2008, at 2:50 AM, Maxim Zhuravlev
<email@hidden> wrote:
Thanks, Terry.
There are no kauth hooks for mount/unmount notification,
I'm aware of it, that's why I'm asking.
as the permissions
are vetted before you get there, and so there are no allow/deny
hooks in
kernel space.
Well, all this doesn't deny kauth's file operation scope.
This is the meat of it, I think. It's the difference between VNOP -
a file scope operation - vs. A VFSOP - a filesystem scope operation.
Since mounts are privileged operations performed by privileged
programs on behalf of someone else, the betting happens at the point
you talk to the privileged program, rather than that information being
proxied. Some information on the actor is passed in, but enforcement
is higher up, or the identity information is passed on a per-FS basis
for things like connection oriented remote FS's (in that case,
enforcement is at the server process and non-local). But realize it's
not session complete.
You can get notification through disk arbitration in user space,
and then
call down into your KEXT to tell it about the events. This is
typically
done with DARegisterDiskMountApprovalCallback and
DARegisterDiskUnmountApprovalCallback, which would allow you to
ensure
mostly synchronous operation.
I'm aware about the opportunity either. And still, I would appreciate,
if you give me a hint, how do I do it from within kernel, i.e.
*observe* mount/umount events, if there is any way. That would fit my
needs perfectly.
Which are still unclear, which is why we keep asking about the problem
you are trying to solve.
If this is for an academic project, I would suggest using the SEDarwin
sources and building your own kernel, since the MACF hooks for mount
and unmount exist there. At that point your job becomes writing a
loadable policy module, which cold just observe, if that's all it
wanted to do. Alternately you could supply a replacement FS
implementation for an FS of interest, and have it have integral hooks;
this would not work across the board, but it might be enough for your
project. Or you could add your own hooks, or even go as far as adding
an FSOP scope to kauth. I don't know how useful this last would end up
being, given you would be operating on proxied information likely not
in the currently in effect security association, as noted earlier.
If this is for a commercial project, then I am afraid you are going to
have to find a way to live with doing the code in user space instead
of kernel space.
-- 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