On Wed, Jan 25, 2006 at 11:21:32AM +1030, Brett Lymn wrote:
> On Wed, Jan 25, 2006 at 09:34:01AM +0900, Curt Sampson wrote:
> > What advantages do you see to making it depend on kern.securelevel? What
> > threat model do you have here?
> 
> That someone could tweak the knobs up and be able to harvest private
> information from set*id cores.

Private information harvesting is also a potential threat model for
non-set*id cores.

It seems to me that, rather than not allowing the creation of cores
that might be vital to debugging a problem, it makes more sense to
directly address this threat model.

How about a sysctl node which specifies a public key to encrypt all
cores with.  Allow it to be set anytime, but changed or removed only
at securelevel <= 0.  Then, if facing a debugging situation like those
mentioned earlier in this thread (e.g. a vendor needs a core file),
you can set the key, enable set*id cores, and take the resulting core
dump to a secured machine elsewhere to decrypt it, without having to
take the server down even briefly to enable the core dumps.  (Given
both service expectations and the potential for leak-related problems
that only crop up after a long running time, not having to down the
server is a major plus.)

With this sort of scheme, even if an intruder does manage to get on
as root and grab a copy of a core, they're faced with a big
encrypted blob.

(You could potentially even have this be a per-user setting, but that
would probably be overkill.)

The SOC work on libbpg could provide a good chunk of the necessary
code for implementing a mechanism like this.

jdarrow