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>