This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: SystemTap / kprobes to watch for other probes?


On Thursday, December 21, 2006 10:56 AM, Nathan DeBardeleben wrote:
> Something I was wondering about is whether it would be possible to
> write a SystemTap script that watched for other kprobes to be
> inserted and to log them somehow.  I'm a bit concerned about the
> security implications of having kprobes turned on in the kernel and
> the fact that if someone were able to insert a probe they could
> basically hide themselves by hiding their module in the module list
> and doing assorted other nefarious things.  If there was a way to
> write a probe that was always inserted which just logged when a
> another probe was inserted I thought that might be a neat thing.
> 
> Any thoughts on this?

Seems like you would want a probe on register_kprobe (and the variants:
kretprobe, jprobe, etc.).  Currently most of the kprobes infrastructure
is blocked from being probed itself.  This was done in a rather
heavy-handed way, and there's a bugzilla addressing this:

bz #2003: permit kprobes on more kprobe infrastructure
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2003

Anil notes that the registration/unregistration control flows are
probably safe from recursion, so they're good candidates to have the
probing restriction lifted.


Now, IANASG (security-guru), but if you're on a machine where an
untrusted module is allowed to load into the kernel, haven't you already
lost the security battle?  Using kprobes might make it easier for
rootkits to hide themselves, but couldn't they also hide your logging
output?

Some other thoughts:

* You'd have to make sure that your monitoring kprobes were loaded
before the malicious ones -- what if someone set their module to load on
the next reboot?

* A particularly nasty author might find a way to unregister all
existing probes before inserting their own.

* Perhaps a more secure logger could be statically added to the
registration functions.  While you're changing the kernel, you can make
sure that your logging callpath isn't intercepted by adding the
'__kprobes' decorator.

* You could add the '__kprobes' decorator to functions that you don't
want nefarious modules to probe and circumvent, like module enumeration.


Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]