Re: System call dispatch table
Re: System call dispatch table
- Subject: Re: System call dispatch table
- From: Terry Lambert <email@hidden>
- Date: Tue, 25 Oct 2005 22:46:19 -0700
On Oct 25, 2005, at 10:43 AM, Timothy Weiand wrote:
On Oct 24, 2005, at 11:38 AM, Mike Smith wrote:
On Oct 24, 2005, at 10:32 AM, Timothy Weiand wrote:
On Oct 21, 2005, Terry Lambert replied and on Oct 24, 2005
Timothy Weiand continued :
3b) Consider describing the problem you are trying to solve so
that people on this list can suggest approaches
I would like to detect all file interaction for a given process.
I would like to sandbox some programs before they are used by my
team. My first approach was to try and create a dynlib that will
do this redirection on a process by process basis (this is the
process that InstallWatch uses on linux systems). Modifying the
kernel to audit file interaction seemed much easier.
It's not.
1) There is no k_open in sysent[]; you are probably thinking of
something else
Very sorry about the loose terminology. To be very specific,
this code used to work for me (code Copyright by Amit Singh from
www.kernelthread.com):
kern_return_t SyscallExt_start (kmod_info_t * ki, void * d) {
k_open = sysent[SYS_open].sy_call;
sysent[SYS_open].sy_call = r_open;
printf("open() rerouted.\n");
return KERN_SUCCESS;
}
Please don't do this.
2) Use the KPIs instead
10-4, I will research this today.
Is there a better technique for this?
It depends on what you mean by 'sandbox'. Is there any reason a
chroot environment won't work for you?
The shared-library approach is going to be your best option; you
should be able to override the relevant functions of interest out
of libSystem to achieve your goals if chroot won't do what you want.
= Mike
Thank you very much for you guidance Mike/Terry. I am in the
process of porting installwatch to osx.
-Timothy
If you can use any other method, such as library interposition
instead, please do. I agree with Mike that the shared library
approach will be your best option.
The reason for this is that we define our system call API as being at
the top of Libc/Libsystem, and not at the user/kernel boundary. This
lets us do things like change implementation details between software
updates in order to address customer issues, without breaking any
user space applications.
This works because everything that makes system calls is dynamically
linked.
-
If you still think you need to do this in the kernel, it'll be a
little hard; you're likely looking for:
http://developer.apple.com/technotes/tn2005/tn2127.html
which describes how the kauth subsystem operates, and how you can
create a listener in the scopes you are interested in being informed
of events that happen.
In your particular case, if you go this route, you will likely need
to do several moderately complex things to get to where you want to
be; any coding mistakes could result in kernel panics or a deadlock,
so you will need to not make any mistakes:
1) Create a kext that implements a kauth listener for the scope(s)
you intend to monitor/intervene.
2) Utilize a pseudo-device or a mach port or a socket listener to
create a kernel/user communications channel.
3) Start a user space process (daemon) that contacts the kext via
this channel; it will need to have a number of capabilities, the
first of which is to make itself immune to intervention by the kext
when it is the processs making the request; if you don't do this, the
process can potentially deadlock against itself. Conventional wisdom
is that this daemon should be started and maintained by launchd for
as long as the service it's going to provide is enabled.
4) When a kauth event you want to monitor occurs, report it to the
daemon; if it's an interposition event, i.e.: one you want to be able
to have the daemon make a decision about and potentially abort the
operation by returning KAUTH_RESULT_DENY instead of
KAUTH_RESULT_DEFER, get the decision from the daemon, and act on it.
5) Because installwatch intends to save off old files before
opening/creating new ones, you will mostly want your listener to
return the KAUTH_RESULT_DEFER answer, after the user space daemon
acts on behalf of the installwatch "normal procedure".
6) Because this is a daemon, it can potentially take a *long* time
to do its work; be *very* sure that what you are trying to watch in
this case is something that *needs* to be watched; even with fast
Mach messages as your communications channel, this could
*SIGNIFICANTLY* impact your system performance because of the round
trip to user space for the operations being observed. WAtch ONLY*
what you *MUST* to accomplish the job.
7) *Ideally* you would turn this facility *OFF* by default, turn
it on *ONLY* immediately before beginning an installation process,
and *IMMEDIATELY* turn it back *OFF*. This would be done by having
the user space process deregister an interest in events --
potentially, it would go so far as to unload the kext so that there
was not an additional performance load in the normal authorization path.
8) Take as little time to make your decisions and answer the
kernel as possible; there are other listeners potentially listening
on the same events (this is also why you only want to DENY in the
most dire circumstances). The list of listeners includes antivirus,
personal firewall, antispyware, and other software that doesn't need
user space cooperation except for quarantine and similar situations
(and they can make this decisions without needing to round-trip to
user space, and they can always DENY in the case that this is
necessary).
This isn't an exhaustive list, it's more of a "10,000 foot view", and
there will be a lot of work involved to identify the events you need,
and you may find you need to cache off filename information at first
event, or you won't have it available later. What you are trying to
do here is generally a lot more difficult than writing a virus
scanner, since it needs to manipulate the system out from under the
system calls, while still allowing the calls to proceed.
Finally, I'll recommend one more time that you take Mike's advice,
and do this with a library interposition, entirely in user space;
there is effectively only once static binary in the system, which is
part of build tools, so you will catch everything of interest with
the library interposition.
-- 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