mbox series

[0/2] Secure deletion under JFFS2

Message ID cover.1532043059.git.theuns.verwoerd@alliedtelesis.co.nz
Headers show
Series Secure deletion under JFFS2 | expand

Message

Theuns Verwoerd July 19, 2018, 11:50 p.m. UTC 
Security certifications such as FIPS require the capability to securely 
delete files, which is problematic under JFFS2's log-based model.  We can
ensure that all dirty or obsolete data has been cleared at the conclusion 
of secure deletion by forcibly driving the existing garbage collection 
system however.

To that end, these patches provide two pieces of functionality:
1. -POLL signal handling in jffs2_gc to force complete collection of 
   dirty blocks up to the time it was started.
2. Synchronisation with userspace (via debugfs files) to allow 
   secure deletion to wait until that process has completed.

Theuns Verwoerd (2):
  jffs2: Provide forced dirty node cleanup via POLL signal
  jffs2: Provide jffs2_sync files to track gc POLL progress

 fs/jffs2/Kconfig       |  8 ++++++++
 fs/jffs2/background.c  | 31 ++++++++++++++++++++++++++++++-
 fs/jffs2/build.c       |  1 +
 fs/jffs2/jffs2_fs_sb.h |  2 ++
 fs/jffs2/nodelist.h    |  1 +
 fs/jffs2/nodemgmt.c    |  6 +++++-
 fs/jffs2/super.c       | 40 ++++++++++++++++++++++++++++++++++++++++
 7 files changed, 87 insertions(+), 2 deletions(-)

Comments

Richard Weinberger July 22, 2018, 7:06 p.m. UTC | #1 
On Fri, Jul 20, 2018 at 1:50 AM, Theuns Verwoerd
<theuns.verwoerd@alliedtelesis.co.nz> wrote:
> Security certifications such as FIPS require the capability to securely
> delete files, which is problematic under JFFS2's log-based model.  We can

Can you please be a little more specific about the certifications?

These days secure deletion at file system level is almost impossible to achieve
since you don't have full control of the storage stack.
I know, I know, In the raw flash case we have, but still. It makes
things very complicated.

A common approach do delete a file in a secure way is having it
encrypted and upon deletion
you forget the key.
Wouldn't that work for you too?
Theuns Verwoerd July 22, 2018, 10:29 p.m. UTC | #2 
On 07/23/2018 07:06 AM, Richard Weinberger wrote:
> On Fri, Jul 20, 2018 at 1:50 AM, Theuns Verwoerd
> <theuns.verwoerd@alliedtelesis.co.nz> wrote:
>> Security certifications such as FIPS require the capability to securely
>> delete files, which is problematic under JFFS2's log-based model.  We can
> Can you please be a little more specific about the certifications?
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=133

gives some level of context.  I believe both FIPS and CC have similar 
expectations around key deletion.
> These days secure deletion at file system level is almost impossible to achieve
> since you don't have full control of the storage stack.
> I know, I know, In the raw flash case we have, but still. It makes
> things very complicated.
>
> A common approach do delete a file in a secure way is having it
> encrypted and upon deletion
> you forget the key.
> Wouldn't that work for you too?
To retain granularity for managing individual keys, you'd require a 1:1 
key-to-access-key (ktak).  Because keys are expected to be persistent, 
so must the ktak be - at which point we've replaced the requirement for 
securely deleting a key with one to securely delete a ktak.
(In addition, since this approach falls outside the specific language 
used in the certification guidance documents, it'd need to be justified 
in detail, which adds risk.)

Regards,

Theuns
KRN