Garrett, unfortunately, a lot of your points here are--sorry to be blunt
here--so weak as to be cavils.

On Tue, 24 Jan 2006, Garrett D'Amore wrote:

> * symmetric key must be randomly generated, otherwise data is far, far too 
> large for public key crypto  (use symmetric key and encrypt only it under 
> public key)

Err....yes, of course. "If we implemented it very badly, it would suck."
A parallel argument is that if we hardcoded a single key for IPSec, it
wouldn't be secure.

> * I guess this only solves off-line attack, since on-line root user can just 
> examine memory directly without generating core file

Indeed. But we're not discussing any other solution that would solve
that, nor is that even in the class of attacks we're attempting to
defend against. We're discussing under what circumstances you should be
able to enable suid programs to core dump.

> * even using fast symmetric crypto, each data byte in the core must
> be encrypted. The fastest crypto algs I know of take at least a
> couple of cycles *per byte* on typical hardware (RC4 falls into the
> "fastest" case I know). This will have a huge impact on the time it
> takes to dump core. (At least on machines without good hardware crypto
> acceleration.)

You're forgetting that the core has to be written to disk. On modern
machines that will far overshadow the encryption time. In addition, the
feature was proposed to be optional, allowing admins to deal with the
cases where the encryption would be a problem.

> * large core files (think gigabytes potentially here) now have to be 
> decrypted to be used -- double the disk space.  This could get to be 
> problematic on some systems with limited disk storage.

Any code we would be likely to use, e.g., bgp, compresses the data
before encryption, and given that this is targeted at production
machines, where the likely case is that you would be moving the dump off
of the machine before decrypting it, you'd actually use less disk space
on machines with this enabled. And again, optional.

> In the oddball case of a crashing program, the site admin may have to choose 
> between taking down a server later to enable sguid core dumps, or leaving the 
> security level lax.

Which is exactly the issue we're tyring to fix.

> I think we're going overboard here.  Realistically, most sites are going to 
> lock down core files altogether if this is a problem.  (Individual users can 
> also do it using ulimit for their own non-setid processes, right?)
> Folks, lets remember, you can't get *any* core file from a sguid process 
> right now.

I disagree. I think this is actually a fairly brilliant option, though
of course it probably--as with many features--requires some further
thought about implementation beyond the first post stating the idea
alone.

> By adding this feature, we're adding value.  I believe we should 
> add the feature in a security safe way now (along with leaving it disabled by 
> default, at least for now), and wait until we get some operational experience 
> with it before we start trying to solve the final .5% of the world's 
> problems.

Ok, finally something I think is not an unreasonable approach, though I
do find the encryption idea attractive in that it may make some of the
issues we're grappling with now simply disappear.

cjs
-- 
Curt Sampson            <cjs@cynic.net>             +81 90 7737 2974
   The power of accurate observation is commonly called cynicism
   by those who have not got it.    --George Bernard Shaw