l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
July 21: Defensive computing: Information security for individuals
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2010 Dec 27 09:34

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] vox-tech Digest, Vol 79, Issue 10
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Dec 17, 2010 at 12:00 PM,  <vox-tech-request@lists.lugod.org> wrote:
> Message: 2
> Date: Fri, 17 Dec 2010 11:28:04 -0800
> From: Bill Broadley <bill@broadley.org>
> Subject: Re: [vox-tech] Secure kernel panic
> To: vox-tech@lists.lugod.org
> Message-ID: <4D0BB9C4.7090209@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
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!