util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] utility for SED management
@ 2019-06-11  6:30 Jakowski, Andrzej
  2019-06-12 13:40 ` Karel Zak
  0 siblings, 1 reply; 7+ messages in thread
From: Jakowski, Andrzej @ 2019-06-11  6:30 UTC (permalink / raw)
  To: util-linux

Hi,

As far as I know there is no good utility in open source allowing to manage
Self-Encrypting Drives (SED) for data center scale usages and client usages.

Let me first introduce example use cases for both scenarios: 
 * Data center usages (automatic): when disk is initially provisioned for
   security disk key could be created automatically on key manager and supplied
   to disk. On subsequent reboot of server, when disk is locked, corresponding
   disk key could be retrieved from key manager and used to unlock that disk. 
   Initial provisioning and unlock are example flows which could be automated 
   in the SW.
 * Client usages: manual disk provisioning for security, managing users and
   locking ranges, crypto erase, drive repurposing, etc.

We have built prototype code covering these functionalities and now we would
like to productize it. We are looking for the right place to publish our SW,
considering util-linux project as one of the options. The SW will likely
consist of:
 * Libsed - shared object exposing programmatic interface for security
   management (Opal) of disk
 * Sedcli - command line utility covering both client and data center flows.
   Sedcli will use libsed for interaction with the drive, libkmip for
   interaction with OASIS KMIP based key manager and tpm2-tss to interact with
   TPM2 key manager
 * Udev rules - will be used to invoke sedcli to auto-provision or auto-unlock
   when new device is added to the OS (e.g. hot insert)
 * System.d  scripts - will be used to invoke sedcli when key needs to be 
   retrieved from network attached key manager
 * Config file - will define policies for example on which disk should be 
   security managed or not

We would like to contribute that SW into util-linux project. What do you think
about adding this SW into util-linux?

Thx,
Andrzej


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] utility for SED management
  2019-06-11  6:30 [RFC] utility for SED management Jakowski, Andrzej
@ 2019-06-12 13:40 ` Karel Zak
  2019-06-13 13:51   ` Jakowski, Andrzej
  0 siblings, 1 reply; 7+ messages in thread
From: Karel Zak @ 2019-06-12 13:40 UTC (permalink / raw)
  To: Jakowski, Andrzej; +Cc: util-linux

On Tue, Jun 11, 2019 at 06:30:51AM +0000, Jakowski, Andrzej wrote:
> We have built prototype code covering these functionalities and now we would
> like to productize it. We are looking for the right place to publish our SW,
> considering util-linux project as one of the options. The SW will likely
> consist of:
>  * Libsed - shared object exposing programmatic interface for security
>    management (Opal) of disk
>  * Sedcli - command line utility covering both client and data center flows.
>    Sedcli will use libsed for interaction with the drive, libkmip for
>    interaction with OASIS KMIP based key manager and tpm2-tss to interact with
>    TPM2 key manager
>  * Udev rules - will be used to invoke sedcli to auto-provision or auto-unlock
>    when new device is added to the OS (e.g. hot insert)
>  * System.d  scripts - will be used to invoke sedcli when key needs to be 
>    retrieved from network attached key manager
>  * Config file - will define policies for example on which disk should be 
>    security managed or not
> 
> We would like to contribute that SW into util-linux project. What do you think
> about adding this SW into util-linux?

From my point of view (and maybe I'm wrong ;-)) it seems complex
enough to keep it as an independent stand-alone project ("sed-utils").
Not sure if it makes sense to push it to generic util-linux package.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [RFC] utility for SED management
  2019-06-12 13:40 ` Karel Zak
@ 2019-06-13 13:51   ` Jakowski, Andrzej
  2019-06-14  7:48     ` Karel Zak
  0 siblings, 1 reply; 7+ messages in thread
From: Jakowski, Andrzej @ 2019-06-13 13:51 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On Wed, Jun 12, 2019 at 01:40:08PM +0000, Karel Zak wrote:
> From my point of view (and maybe I'm wrong ;-)) it seems complex enough to keep it as an independent stand-alone project ("sed-utils").
> Not sure if it makes sense to push it to generic util-linux package.

It sounds to me that your major concern for inclusion sedcli into util-linux is
its complexity. What would be the best method to understand if sedcli fits into
util-linux?

Thx,
Andrzej

-----Original Message-----
From: util-linux-owner@vger.kernel.org [mailto:util-linux-owner@vger.kernel.org] On Behalf Of Karel Zak
Sent: Wednesday, June 12, 2019 3:40 PM
To: Jakowski, Andrzej <andrzej.jakowski@intel.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [RFC] utility for SED management

On Tue, Jun 11, 2019 at 06:30:51AM +0000, Jakowski, Andrzej wrote:
> We have built prototype code covering these functionalities and now we 
> would like to productize it. We are looking for the right place to 
> publish our SW, considering util-linux project as one of the options. 
> The SW will likely consist of:
>  * Libsed - shared object exposing programmatic interface for security
>    management (Opal) of disk
>  * Sedcli - command line utility covering both client and data center flows.
>    Sedcli will use libsed for interaction with the drive, libkmip for
>    interaction with OASIS KMIP based key manager and tpm2-tss to interact with
>    TPM2 key manager
>  * Udev rules - will be used to invoke sedcli to auto-provision or auto-unlock
>    when new device is added to the OS (e.g. hot insert)
>  * System.d  scripts - will be used to invoke sedcli when key needs to be 
>    retrieved from network attached key manager
>  * Config file - will define policies for example on which disk should be 
>    security managed or not
> 
> We would like to contribute that SW into util-linux project. What do 
> you think about adding this SW into util-linux?

From my point of view (and maybe I'm wrong ;-)) it seems complex enough to keep it as an independent stand-alone project ("sed-utils").
Not sure if it makes sense to push it to generic util-linux package.

    Karel

--
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] utility for SED management
  2019-06-13 13:51   ` Jakowski, Andrzej
@ 2019-06-14  7:48     ` Karel Zak
  2019-06-14  9:01       ` Andrzej Jakowski
  0 siblings, 1 reply; 7+ messages in thread
From: Karel Zak @ 2019-06-14  7:48 UTC (permalink / raw)
  To: Jakowski, Andrzej; +Cc: util-linux

On Thu, Jun 13, 2019 at 01:51:12PM +0000, Jakowski, Andrzej wrote:
> On Wed, Jun 12, 2019 at 01:40:08PM +0000, Karel Zak wrote:
> > From my point of view (and maybe I'm wrong ;-)) it seems complex enough to keep it as an independent stand-alone project ("sed-utils").
> > Not sure if it makes sense to push it to generic util-linux package.
> 
> It sounds to me that your major concern for inclusion sedcli into util-linux is
> its complexity. What would be the best method to understand if sedcli fits into
> util-linux?

Do you have the current code/repo with sedcli accessible anywhere? It
would be nice to see it.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] utility for SED management
  2019-06-14  7:48     ` Karel Zak
@ 2019-06-14  9:01       ` Andrzej Jakowski
  2019-06-14 10:04         ` Karel Zak
  0 siblings, 1 reply; 7+ messages in thread
From: Andrzej Jakowski @ 2019-06-14  9:01 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On 6/14/19 9:48 AM, Karel Zak wrote:
> Do you have the current code/repo with sedcli accessible anywhere? It
> would be nice to see it.
> 
>      Karel

Code is still work-in-progress on non-public repo. I will let you know 
once available.


Andrzej

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] utility for SED management
  2019-06-14  9:01       ` Andrzej Jakowski
@ 2019-06-14 10:04         ` Karel Zak
  2019-06-14 10:35           ` Andrzej Jakowski
  0 siblings, 1 reply; 7+ messages in thread
From: Karel Zak @ 2019-06-14 10:04 UTC (permalink / raw)
  To: Andrzej Jakowski; +Cc: util-linux

On Fri, Jun 14, 2019 at 11:01:15AM +0200, Andrzej Jakowski wrote:
> On 6/14/19 9:48 AM, Karel Zak wrote:
> > Do you have the current code/repo with sedcli accessible anywhere? It
> > would be nice to see it.
> > 
> >      Karel
> 
> Code is still work-in-progress on non-public repo. I will let you know once
> available.

BTW, I found https://github.com/Drive-Trust-Alliance/sedutil, this is
probably obsolete, right? (Oh, ... C++ ;-).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] utility for SED management
  2019-06-14 10:04         ` Karel Zak
@ 2019-06-14 10:35           ` Andrzej Jakowski
  0 siblings, 0 replies; 7+ messages in thread
From: Andrzej Jakowski @ 2019-06-14 10:35 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On 6/14/19 12:04 PM, Karel Zak wrote:
> BTW, I foundhttps://github.com/Drive-Trust-Alliance/sedutil, this is
> probably obsolete, right? (Oh, ... C++;-).

Yes, it looks abandoned.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-06-14 10:35 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-11  6:30 [RFC] utility for SED management Jakowski, Andrzej
2019-06-12 13:40 ` Karel Zak
2019-06-13 13:51   ` Jakowski, Andrzej
2019-06-14  7:48     ` Karel Zak
2019-06-14  9:01       ` Andrzej Jakowski
2019-06-14 10:04         ` Karel Zak
2019-06-14 10:35           ` Andrzej Jakowski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).