[illumos-Developer] Proposal: Add memory clearing allocator to libnvpair

[Jason King]

On Wed, Jan 26, 2011 at 8:48 PM, Bill Sommerfeld <sommerfeld at hamachi.org> wrote:
> On 01/26/11 18:11, Samuel Younge wrote:
>>
>> Is there an easy way to keep referenced memory that affects the internals
>> of IKE in a more protected space?
>
> not an easy one.
>
> approaches to consider:
>
> 0) use umem/vmem in the nvlist allocator and allocate the IKE secrets in
> pages which are locked in core (won't end up in swap space by accident?  or
> will they?)

It appears if you lock the pages, they won't be paged out (according
to mlock(3c)) unless an application explicitly tells the system to do
so.

It looks like this could be done within the ctor/dtor of a umem cache.
 I might look into this for key data (since a lot of the existing code
uses umem caches already) or make it a configuration option.  The
specific use of nv_alloc_zero is more for things like token pins which
if used are likely to be read in from a configuration file upon
startup as well as when dealing with configuration changes from an
administrator (which might include key data).  The use is prevent any
accidental leakage into other structures through memory reuse in
malloc/free and friends.  It was trivial enough to do and small enough
that it can't hurt.

> 1) privilege separation (some ssh implementations do this); reduce the
> attack surface by partitioning the code into multiple processes running with
> limited privileges.
>
> 2) careful cryptographic interface design.  the solaris crypto framework is
> built on top of pkcs#11, which allows for cryptographic tokens which keep
> secrets inside a boundary.  your initial implementation may have this
> boundary be a line in the sand rather than anything real, but if need
> allows, you can make this tougher.  (you could, for instance, leave the keys
> in the kernel, out of reach of iked)

My understanding is that the spec doesn't deal with this very well, so
there tends to be a lot of variation to actually achieve this.  I
could be wrong though.  My experience with the specs from RSA is less
than positive to put it nicely (I think the profanities still linger
in my apartment from the last time I had to deal with pkcs#11 -- in
terms of _usability by a developer_, openssl for all it's warts wins
hands down IMO).

> 3) some sort of cross-zone separation.   figure out how to plumb things
> under the covers in PF_KEY such that you can have IKE running in one zone
> managing the keys of another zone.  I always wanted to try to set this up
> but ENOTIME....

An interesting (if not somewhat complex) idea... maybe for version + 2
(unless others wish to volunteer) :)  At this point I want to get
something working out there for testing first though.