[vox-tech] vox-tech Digest, Vol 79, Issue 10

[Nicole Carlson]

On Fri, Dec 17, 2010 at 12:00 PM,  <vox-tech-request at lists.lugod.org> wrote:
> Message: 2
> Date: Fri, 17 Dec 2010 11:28:04 -0800
> From: Bill Broadley <bill at broadley.org>
> Subject: Re: [vox-tech] Secure kernel panic
> To: vox-tech at lists.lugod.org
> Message-ID: <4D0BB9C4.7090209 at broadley.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 12/17/2010 09:39 AM, Nicole Carlson wrote:
>> Hello, beautiful people!  How I have missed you.
>>
>> A question for your enormous brains.  Suppose that the kernel panics.
>> Further suppose that I do NOT want it to dump core.
>
> I don't believe it's the default.  Are you worried about it dumping core
> without you asking?  Or are you worried that someone with physical access to
> the machine could force it to dump core?

Not physical access--it's hanging out 25,000 miles up in the air--so
much as information leakage.  The threat has to do with possibly
classified information leaking out.  Suppose that our hypothetical
Linux-running satellite processes classified information.  Now suppose
that something makes its kernel panic.  My understanding is that when
the core is dumped, including whatever possibly sensitive information
is in memory at the time, it becomes readable to anyone who can snarf
the coredump file and apply kernel debugging tools to it.  This would
be bad.  The easiest way I can think of to stop this would be to stop
the kernel from dumping core.

>
>> Can I set up the
>> system to do this?  Can I set up the system to perform any arbitrary
>> commands when the kernel panics?  If so, how?
>
> I believe it's a compile time option for the kernel side, and user space
> tools.  The trick is that in a panic you need to trust as little of the kernel
> as possible to avoid trashing a filesystem.  So you'll need diskdump (write to
> disk), netdump (dump to net), and/or kdump.  Source for these tools will give
> you an idea of what is necessary to handle a kernel dump.  Because it's unsafe
> to trust the filesystem code typically if you are writing to disk you either
> give it a device, a partition, or a swap partition.

If I can set where it dumps, then I think there's no problem.

> If you don't have dmesg on boot mentioning the dump utility you are using
> (kdump, netdump, or diskdump) or a /proc/diskdump (or related) then you likely
> don't have it enabled.   Which might be what you want.
>
>> The motivation behind all this: I'm trying to figure out how to get
>> Linux on satellites.
>
> Cool.

Trust me--it is DEAD SEXY.  If I could give y'all a talk on it, I
would.  (Actually, I'm in Davis on 1/12, if you guys want me.)

>> One of the barriers is paperwork: the gub'mint
>> says "You must do X, Y, and Z".  One of those requirements is that all
>> system startups, shutdowns, and aborts keep the system in a secure
>> state.  Secure aborts is the one I'm having trouble proving--I think
>> that dumping core is a problem, because it preserves possibly
>> sensitive information (internal state at the time of panic) in a place
>> that isn't supposed to hold it (namely, wherever the core is dumped,
>> which appears to be in the swap space.)
>
> Swap is one of the choices, but the dumps are optional.
>
>> If I'm wildly off-base, please advise.
>
> I'm a bit fuzzy on the threat.  Not like a normal user can read blocks from
> the swap device.   Not like linux doesn't zero fill pages you ask the OS for.
>  You are trying to protect against root user?  From someone injecting errors
> into the kernel and then stealing the disk drive?   Or just satisfying some
> arbitrary piece of bureaucrat security policy?  Disabling kernel dumps seems
> rather straight forward and depending on your OS/Distro might even be disabled
> by default.

The threat is mostly paperwork (the standard that governs satellite
requirements is not very well adapted to satellites) but there's an
actual threat in there: namely, the idea that classified information
might leak out if it's in memory when the kernel dumps core.

Clear as mud?

Thanks again

--nicole

-- 
http://ellipticcurve.livejournal.com