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:
November 4: Social gathering
Next Installfest:
TBD
Latest News:
Oct. 24: LUGOD election season has begun!
Page last updated:
2010 Dec 17 11:45

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] Secure kernel panic
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Secure kernel panic



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?

> 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 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.

> 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.

Swap has similar problems BTW.  You could encrypt a filesystem or device if 
you want to protect from someone stealing your machine and then reading the 
filesystem/block device.
_______________________________________________
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!