public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "Stone, Joshua I" <joshua.i.stone@intel.com>
To: "Nathan DeBardeleben" <ndebard@lanl.gov>,
		<systemtap@sources.redhat.com>
Subject: RE: SystemTap / kprobes to watch for other probes?
Date: Thu, 21 Dec 2006 23:56:00 -0000	[thread overview]
Message-ID: <C56DB814FAA30B418C75310AC4BB279D011C01C0@scsmsx413.amr.corp.intel.com> (raw)

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

             reply	other threads:[~2006-12-21 19:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-21 23:56 Stone, Joshua I [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-12-21 19:47 Nathan DeBardeleben
2006-12-22 10:36 ` James Dickens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C56DB814FAA30B418C75310AC4BB279D011C01C0@scsmsx413.amr.corp.intel.com \
    --to=joshua.i.stone@intel.com \
    --cc=ndebard@lanl.gov \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).