Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Oct 2013 16:25:42 -0700
From:      Colin Percival <cperciva@freebsd.org>
To:        Adam McDougall <mcdouga9@egr.msu.edu>, freebsd-hackers@freebsd.org
Subject:   Re: Automated submission of kernel panic reports
Message-ID:  <527043F6.7070802@freebsd.org>
In-Reply-To: <526FE7ED.5000903@egr.msu.edu>
References:  <526F8EB3.1040205@freebsd.org> <526FE7ED.5000903@egr.msu.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10/29/13 09:53, Adam McDougall wrote:
> On 10/29/2013 06:32, Colin Percival wrote:
>> If ${panicmail_autosubmit} is set to NO, an email is sent to root containing
>> the panic data in both decrypted and encrypted forms.  The system administrator
>> can then review the information and decide whether to allow it to be submitted.
>> Such emails look like this:
>>   http://pastebin.com/w18pXah8
>>
>> Comments?
> 
> The first thing that comes to mind is privacy so I looked at the
> information being submitted.  Would it be possible to replace the
> hostname(s) and kernel config paths in the report with a hash by
> default?  That way a site could still match up reports to internal
> hostnames without revealing anything specific about the source system.
> The hostname is only needed to differentiate sources and is not
> guaranteed to be unique anyway.  Just thinking ahead about the
> information being obtained and reducing what is transmitted/stored in
> case it somehow falls into the wrong hands at some point in the future.
> Aside from that, I like it and would consider running it myself as long
> as I have appropriate control over the content.  Thanks.

The hostname could be filtered, but depending on how the panic report is
submitted there's a good chance that it would be leaked anyway via email
headers, so I figured it was better to make it obvious that it was being
sent.

The kernel config path I think will be very useful to have when it comes
to tracking down the cause of a panic -- if there's a panic which keeps on
happening with kernels named "DTRACE" but not kernels named "GENERIC", it
give us a hint of where to look.  I considered including the entire output
of `sysctl -n kern.conftxt` but decided that might be too intrusive.

Note: The purpose of the encryption is to protect "private" information in
these reports from becoming public -- my intention is that access to the
raw reports would be limited to a select group within the project.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?527043F6.7070802>