Re: getting the application path in VnodeScopeListener
Re: getting the application path in VnodeScopeListener
- Subject: Re: getting the application path in VnodeScopeListener
- From: Terry Lambert <email@hidden>
- Date: Fri, 14 Oct 2005 13:46:15 -0700
There is potentially a convoluted way for you to do this convoluted
thing you wish to do...
In order to exec, you have to have a pid. This pid is assigned at
the time you fork or vfork, so it's active for the active process
being exec'ed.
The execve() function, as *part* of the exec process calls
exec_check_permissions() to verify that you have permission to
execute the binary you are trying to execute.
When this happens, there is a vnode_authorize() callback with an
action bit containing KAUTH_VNODE_EXECUTE on the vp in question, with
a vfs_context for the process calling the execve().
Calling vfs_context_pid() on the context in a listener registered for
this authorization callback will get the pid of the process calling
the execve(), and the vp will be the thing it is *trying* to exec.
Listen very, very carefully: this should not *necessarily* change
your cached idea of the process file path, because you do not know
whether or not the exec was successful: this is an authorization
check, which means it is a *necessary*, but not a *sufficient*
condition for the exec to succeed. The exec can fail for other
reasons, subsequent to the check, so an attacker against a system
trusting the check alone to indicate a successful exec could
potentially misdirect you to log another path.
What it *will* do is let you create a name/pid association with the
proc_name() return on the *parent* before the fork() -- the p_comm
field is updated after it is too late to recover from a catastrophic
exec failure - any failure after it's changed is fatal to the process
calling execve() because the previous process address space has been
replaced (execve after vfork) or destroyed (execve after fork).
From the vp, you obtain the value that *would* be set on a
successful exec into the p_comm field (this is the terminal name
component for the vnode). You need to also note whether these are
the same or different. If they are the same, you might also want to
save off the vfs_context_proc() information, so that an exec of the
same executable, or one with the same name in a different location,
can be detected.
The *very next* operation by a matching process ID (you *must* listen
to all events!), you can compare the p_comm field from the process
from the vfs_context vs. the one in the association (and the other
uniquifiers for instances of the same name, different file which you
have saved; look around, there are KPI's to get information
containing pointers out of the proc structure that *will* change on
exec, but I'm not going to commit to supporting them; there are also
*very* ugly ways to do it that I will not go into on a public mailing
list, except to say you would need to change every time we made a
software update to be safe -- or you could simply disallow the exec
in the KAUTH_VNODE_EXECUTE listener, which might break some third
party applications that depend on being able to do this, for example
to provide GUI wrappers for non-GUI applications: not a recommended
approach).
At this point, you can create the "real" PID/file name association,
and use that as the name.
Let me reiterate that this is probably not something you want to do.
It's very fragile, in that we could change the uniqueifier data you
decide rely on at some later date: at that point, you may start
getting false negatives, and lose the location of the file. It's
also possible we could change the exec code, which would result in a
race window opening in your correlation checking. We wouldn't know
not to do this, not knowing what you are relying on or why.
I understand your NDA situation; however, if you were to file a bug
indicating the information you needed and the circumstances under
which it was required, we could probably provide a kauth listener
callback to give the information to you reliably, without you needing
to close the race windows on your own - assuming it's information we
have.
-- Terry
On Oct 14, 2005, at 12:53 AM, Ben wrote:
it is for logging or display indeed. Asking a daemon does not seem
suitable for this though, considering the function I'm in executes
on every file open globally (so there'd be too much overhead /
speed decrease). Do you know of any way to get the name within the
kext? aside from proc_name of course...
On 14/10/2005, at 7:58 PM, Mike Smith wrote:
Understood.
If what you need is strictly an *application* name, i.e. something
that the user actually launched, then if you have a userland
component you could ask Launch Services for the proper displayable
name of the process. I can't see any good reason for a kernel
component to need the name of an app, so I'm assuming that this is
for logging or display purposes.
= Mike
On Oct 13, 2005, at 8:43 PM, Ben wrote:
I cant explain my goal because I'm under NDA
On 14/10/2005, at 4:35 PM, Mike Smith wrote:
Ben,
How about you respond to my original question, then, and explain
just what it is that you're trying to achieve...
= Mike
On Oct 13, 2005, at 8:10 PM, Ben wrote:
yes, just the full application name is not perfect but it would
do. I'd be grateful for any help on that
On 14/10/2005, at 4:04 PM, Mike Smith wrote:
On Oct 13, 2005, at 4:01 PM, Ben wrote:
my current mechanism is to use vfs_context_pid then proc_name
to get the name. The main issue with this is proc_name will
only provide the first 16 bytes of the process name.
Ben,
So is it just that what you're looking for is the full name of
the application? There are other ways that you can get this.
= Mike
if I could either find a way to get the full application
name, or (this is the preferable solution) to get a vnode
from a vfs_context_t, that would satisfy this.
any function to get a path from a pid would also be suitable
On 13/10/2005, at 3:33 PM, Terry Lambert wrote:
vfs_context_pid(), which is exported in BSDKernel.exports,
will tell you the pid.
proc_name(), which is exported in BSDKernel.exports, will
convert the pid into a name and copy it into a buffer you
supply and give a length for.
This won't necessarily be the application path if the
application was launched via finder; it might also be a
volfs path, so it should not be relied on as a credential
for authorization or authentication purposes or for the
granting of some other type of trust, if you are trying to
establish a security association.
Note that you should not use file I/O in the kernel, either,
so if you are intending to use this information to get a
bundle ID from which to optain some other file path and read
it in the kernel - don't do that.
-- Terry
On Oct 12, 2005, at 3:39 PM, Ben wrote:
I am doing some work in the kauth KPI and I need to get the
application path (of the application performing the action
causing this function to get called) from within
VnodeScopeListener.
I think this will be available because VnodeScopeListener
gets passed in a vfs_context_t for the application in
question, however most of the accessor functions for this
opaque object are undocumented, so my hope is someone can
point me to which one to use to obtain a vnode from the
vfs_context_t, which I can then get a path from, or some
other way of getting the path.
I am okay if the path cannot be obtained all of the time,
just some of the time (I'm aware of the issues of trying to
use paths, so I'm not relying on them, but when they are
there they do make things easier)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-
email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mu.org
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mu.org
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
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