public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Dave Brolley <brolley@redhat.com>
Cc: systemtap <systemtap@sources.redhat.com>
Subject: Re: Network Security for the Systemtap Client/Server
Date: Thu, 06 Nov 2008 18:06:00 -0000	[thread overview]
Message-ID: <20081106180556.GD32565@redhat.com> (raw)
In-Reply-To: <491215D5.1060202@redhat.com>

Hi -

On Wed, Nov 05, 2008 at 04:53:25PM -0500, Dave Brolley wrote:

> >>Wire Level Security
> [...]
> If I understand correctly, the only way to ensure that the script has 
> not been modified on route is to have the client sign it with its own 
> certificate and private key. This can be easily done using the same 
> techniques used by the server to sign its response. [...]

That could well be an overkill.  Standard wire-level security like
TLS/SSL, without extra explicit signatures, should be sufficient for
protection against a hostile network.


> [...]
> Note that stap-client makes use of more than just the returned
> module. Output from stap on the server side is also used and this is
> why I'm proposing that the entire server response be
> signed. stap-client needs to know that no part of the server
> response has been tampered with.

That's a good point, but that's adequately addressed by wire-level
security.  It may help to consider the wire-level stuff orthogonal -
as indeed it is since we can theoretically connect stap-client and
stap-server with a local unix pipe.


> Some possibilities for verification of the module by staprun on the 
> client side are:
> 
> 1) Separately sign the module within the signed server response, which 
> seems a bit redundant to me given that the entire server response is 
> already signed by the server and verified by the client. [...]

Yes, but the client (stap-client) cannot be trusted by staprun.
staprun need only care that the final module is built correctly.


> >[...]
> >All that must be automatable to death.  The wire protocol part's user
> >interface should be no clumsier than, say, svn talking to a https:
> >server.
>
> Right. Bear in mind that these are sysadmin tasks performed once for 
> each client/server on the network. These tasks are analogous to using 
> ssh-keygen to generate key pairs for ssh and adding the public 
> identities to each machine one wants to access.

I don't see a need yet for client-side *authentication* that might
necessitate signing keys there, so that leaves only the ssh-keygen
part.

So, for module-signing purposes, sshd's host key is analogous to
stap-server's signing key, and ssh's $HOME/.ssh/known_keys (treated
more like authorized_keys) is analogous to the staprun's approved keys
list.


- FChE

  reply	other threads:[~2008-11-06 18:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23 21:13 Dave Brolley
2008-10-30 21:23 ` Frank Ch. Eigler
2008-11-05 21:54   ` Dave Brolley
2008-11-06 18:06     ` Frank Ch. Eigler [this message]
2008-11-06 18:34       ` Dave Brolley
2008-11-06 21:07         ` Frank Ch. Eigler
2008-11-07 16:37           ` Dave Brolley
2008-11-07 16:43             ` Frank Ch. Eigler
2008-12-04  0:54   ` Roland McGrath
2008-12-04  0:54 ` Roland McGrath

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=20081106180556.GD32565@redhat.com \
    --to=fche@redhat.com \
    --cc=brolley@redhat.com \
    --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).