Encrypted Filesystem

Encrypted Filesystem

[Michael A Halcrow]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have some time this year to work on an encrypted filesystem for
Linux.  I have surveyed various LUG's, tested and reviewed code for
currently existing implementations, and have started modifying some
of them.  I would like to settle on a single approach on which to
focus my efforts, and I am interested in getting feedback from the
LKML community as to which approach is the most feasible.

This is the feature wish-list that I have compiled, based on personal
experience and feedback I have received from other individuals and
groups:

 - Seamless application to the root filesystem
  - Layered over the entire root filesystem
  - Unencrypted pass-through mode with minimal overhead
  - Files are marked as  ``encrypted'' or ``unencrypted'' and treated
    accordingly by the encryption layer
 - Key->file association
  - As opposed to key->blkdev or key->directory granularity
  - No encryption metafiles in directories, instead placing that
    information into Extended Attributes
  - May break some backup utilities that are not EA-aware; may require
    another mode where encryption metadata is stored in a header block
    on the encrypted file
  - Directories can be flagged as ``encrypted-only'', where any new
    files created in that directory are, by default, encrypted, with
    the key and permissions defined in the directory's metadata
  - Processes may have encryption contexts, whereby any new files they
    create are encrypted by default according to the process'
    authentication
  - Make as much metadata about the file as confidential as possible
    (filesize, executable bit, etc.)
 - Pluggable encryption (I wouldn't mind using a block cipher in CTR
   mode)
 - Authentication via PAM
  - pam_usb
  - Bluetooth
  - Kerberos
  - PAM checks for group membership before allowing access to certain
    encrypted files
 - Rootplug-based LSM to provide key management (necessary to use
   LSM?)
 - Secret splitting and/or (m,n)-threshold support on the keys
 - Signatures on files flagged for auditing in order to detect
   attempts to circumvent the encryption layer (via direct
   modifications to the files themselves in the underlying filesystem)
 - Ad-hoc groups for access to decrypted versions of files
  - i.e., launch web browser, drop group membership by default (like
    capability inheritance masks) so that the browser does not have
    access to decrypted files by default; PAM module checks for group
    membership before allowing access (explicit user authorization on
    application access requests)
 - Userland utilities to support encrypted file management
 - Extensions to nautilus and konqueror to be able to use these
   utilities from a common interface (think: right-click, encrypted)
 - Distro installation integration
 - Transparent shredding, where the underlying filesystem supports it
 - Versioning and snapshots (CVS-ish behavior)
 - Design to work w/ SE Linux

These are features that have been requested, but are not necessarily
hard requirements for the encrypted filesystem.  They are just
suggestions that I have received, and I am not convinced that they are
all feasible.

There are several potential approaches to an encrypted filesystem with
these features, all with varying degrees of modification to the kernel
itself, each with its own set of advantages and disadvantages.

Options that I am aware of include:

 - NFS-based (CFS, TCFS)
  - CFS is mature
  - Performance issues
  - Violates UNIX semantics w/ hole behavior
  - Single-threaded

 - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
  - Newer solutions, not as well accepted or tested as CFS
  - KDE team is using SSHFS+FUSE

 - Loopback (cryptoloop) encrypted block device
  - Mature; in the kernel
  - Block device granularity; breaks most incremental backup
    applications

 - LSM-based
  - Is this even possible?  Are the hooks that we need there?

 - Modifications to VFS (stackable filesystem, like NCryptfs)
  - Very low overhead claimed by Erez Zadok
  - Full implementation not released
  - Key->directory granularity
  - Evicts cleartext pages from the cache on process death
  - Uses dcache to store attaches
  - Other niceties, but it's not released...

My goal is to develop an encrypted filesystem ``for the desktop'',
where a user can right-click on a file in konqueror or nautilus and
check the ``encrypted'' box, and all subsequent accesses by any
processes to that file will require authentication in order for the
file to be decrypted.  I have already made some modifications to CFS
to support this functionality, but I am not sure at this moment
whether or not CFS is the best route to go for this.

I have had requests to write a kernel module that, when loaded,
transparently starts acting as the encryption layer on top of whatever
root filesystem is mounted.  For example, an ext3 partition may have
encrypted files strewn about, which are accessible only after loading
the module (and authenticating, etc.).

Any advise or direction that the kernel community could provide would
be very much appreciated.

Thanks,
Mike
.___________________________________________________________________.
                         Michael A. Halcrow 
       Security Software Engineer, IBM Linux Technology Center 
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAFU9wLTz92j62YB0RAkOfAKClVMzKIhw6JtyGvKf8+iFp4e12AwCdFARU
uAhpA7wVjvPMdDQtKSnFzzI=
=TM5Y
-----END PGP SIGNATURE-----

Re: Encrypted Filesystem

[Mark Borgerding]

It sounds like you've got a nice methodical approach: gathering 
requirements and thinking about it before diving headlong into hacking.

Iterative development works well for a lot of things (obviously), but I 
think that crypto work requires a little bit of Cathedral-esque 
architecture in order to be secure.  It would pay off to think long and 
hard about feedback modes, IVs, key management, salting, etc. ;  before 
doing any coding. 
Posting explanations in sci.crypt would find a good deal more scrutiny 
(read: paranoia) than in lkml.  Bounce kernel & fs ideas off the kernel 
hackers. Bounce crypto ideas off the cryptographers.


Some random thoughts:

Have you given any thought to journalling? fscking? Can directory 
contents be encrypted?  If so, what does the dir look like to others 
(e.g. backup utils)

Per-file signatures will severely affect random access performance.  
Changing 1 byte in a 1 GB file would require the whole thing to be reread.

Why tackle versioning?   If you want encrypted cvs, you could run cvs in 
file mode with the repository and/or modules in encrypted files.

CTR mode (or any stream cipher) would be more susceptible to bit 
twiddling than CBC. If sigs are not integral to fs, this would be a problem.

Adding the functionality to a well known fs like ext3 or reiserfs might 
be a good path to faster acceptance. It would get a lot more people 
looking at the code.  It would also allow people to start using the new 
features on existing partitions just by patching the kernel.


I'd love to help out.  I have some exp with crypto, and a teensy bit of 
exp with linux filesystems.  How much time I may actually have to 
contribute depends on far too many factors to guess.


- Mark Borgerding





Michael A Halcrow wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I have some time this year to work on an encrypted filesystem for
>Linux.  I have surveyed various LUG's, tested and reviewed code for
>currently existing implementations, and have started modifying some
>of them.  I would like to settle on a single approach on which to
>focus my efforts, and I am interested in getting feedback from the
>LKML community as to which approach is the most feasible.
>
>This is the feature wish-list that I have compiled, based on personal
>experience and feedback I have received from other individuals and
>groups:
>
> - Seamless application to the root filesystem
>  - Layered over the entire root filesystem
>  - Unencrypted pass-through mode with minimal overhead
>  - Files are marked as  ``encrypted'' or ``unencrypted'' and treated
>    accordingly by the encryption layer
> - Key->file association
>  - As opposed to key->blkdev or key->directory granularity
>  - No encryption metafiles in directories, instead placing that
>    information into Extended Attributes
>  - May break some backup utilities that are not EA-aware; may require
>    another mode where encryption metadata is stored in a header block
>    on the encrypted file
>  - Directories can be flagged as ``encrypted-only'', where any new
>    files created in that directory are, by default, encrypted, with
>    the key and permissions defined in the directory's metadata
>  - Processes may have encryption contexts, whereby any new files they
>    create are encrypted by default according to the process'
>    authentication
>  - Make as much metadata about the file as confidential as possible
>    (filesize, executable bit, etc.)
> - Pluggable encryption (I wouldn't mind using a block cipher in CTR
>   mode)
> - Authentication via PAM
>  - pam_usb
>  - Bluetooth
>  - Kerberos
>  - PAM checks for group membership before allowing access to certain
>    encrypted files
> - Rootplug-based LSM to provide key management (necessary to use
>   LSM?)
> - Secret splitting and/or (m,n)-threshold support on the keys
> - Signatures on files flagged for auditing in order to detect
>   attempts to circumvent the encryption layer (via direct
>   modifications to the files themselves in the underlying filesystem)
> - Ad-hoc groups for access to decrypted versions of files
>  - i.e., launch web browser, drop group membership by default (like
>    capability inheritance masks) so that the browser does not have
>    access to decrypted files by default; PAM module checks for group
>    membership before allowing access (explicit user authorization on
>    application access requests)
> - Userland utilities to support encrypted file management
> - Extensions to nautilus and konqueror to be able to use these
>   utilities from a common interface (think: right-click, encrypted)
> - Distro installation integration
> - Transparent shredding, where the underlying filesystem supports it
> - Versioning and snapshots (CVS-ish behavior)
> - Design to work w/ SE Linux
>
>These are features that have been requested, but are not necessarily
>hard requirements for the encrypted filesystem.  They are just
>suggestions that I have received, and I am not convinced that they are
>all feasible.
>
>There are several potential approaches to an encrypted filesystem with
>these features, all with varying degrees of modification to the kernel
>itself, each with its own set of advantages and disadvantages.
>
>Options that I am aware of include:
>
> - NFS-based (CFS, TCFS)
>  - CFS is mature
>  - Performance issues
>  - Violates UNIX semantics w/ hole behavior
>  - Single-threaded
>
> - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
>  - Newer solutions, not as well accepted or tested as CFS
>  - KDE team is using SSHFS+FUSE
>
> - Loopback (cryptoloop) encrypted block device
>  - Mature; in the kernel
>  - Block device granularity; breaks most incremental backup
>    applications
>
> - LSM-based
>  - Is this even possible?  Are the hooks that we need there?
>
> - Modifications to VFS (stackable filesystem, like NCryptfs)
>  - Very low overhead claimed by Erez Zadok
>  - Full implementation not released
>  - Key->directory granularity
>  - Evicts cleartext pages from the cache on process death
>  - Uses dcache to store attaches
>  - Other niceties, but it's not released...
>
>My goal is to develop an encrypted filesystem ``for the desktop'',
>where a user can right-click on a file in konqueror or nautilus and
>check the ``encrypted'' box, and all subsequent accesses by any
>processes to that file will require authentication in order for the
>file to be decrypted.  I have already made some modifications to CFS
>to support this functionality, but I am not sure at this moment
>whether or not CFS is the best route to go for this.
>
>I have had requests to write a kernel module that, when loaded,
>transparently starts acting as the encryption layer on top of whatever
>root filesystem is mounted.  For example, an ext3 partition may have
>encrypted files strewn about, which are accessible only after loading
>the module (and authenticating, etc.).
>
>Any advise or direction that the kernel community could provide would
>be very much appreciated.
>
>Thanks,
>Mike
>.___________________________________________________________________.
>                         Michael A. Halcrow 
>       Security Software Engineer, IBM Linux Technology Center 
>GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQFAFU9wLTz92j62YB0RAkOfAKClVMzKIhw6JtyGvKf8+iFp4e12AwCdFARU
>uAhpA7wVjvPMdDQtKSnFzzI=
>=TM5Y
>-----END PGP SIGNATURE-----
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>

Re: Encrypted Filesystem

[Felipe Alfaro Solana]

On Mon, 2004-01-26 at 20:06, Mark Borgerding wrote:

> Have you given any thought to journalling? fscking? Can directory 
> contents be encrypted?  If so, what does the dir look like to others 
> (e.g. backup utils)
> 
> Per-file signatures will severely affect random access performance.  
> Changing 1 byte in a 1 GB file would require the whole thing to be reread.

What about calculating signatures on a per-block basis instead?

Re: Encrypted Filesystem

[Pavel Machek]

Hi!

> > Have you given any thought to journalling? fscking? Can directory 
> > contents be encrypted?  If so, what does the dir look like to others 
> > (e.g. backup utils)
> > 
> > Per-file signatures will severely affect random access performance.  
> > Changing 1 byte in a 1 GB file would require the whole thing to be reread.
> 
> What about calculating signatures on a per-block basis instead?

Hmm, having md5's in indirect blocks would be very nice for detecting
cable problems ;-). That's usefull even without encryption.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Encrypted Filesystem

[jw schultz]

On Mon, Jan 26, 2004 at 11:46:29AM -0600, Michael A Halcrow wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I have some time this year to work on an encrypted filesystem for
> Linux.  I have surveyed various LUG's, tested and reviewed code for
> currently existing implementations, and have started modifying some
> of them.  I would like to settle on a single approach on which to
> focus my efforts, and I am interested in getting feedback from the
> LKML community as to which approach is the most feasible.
> 
> This is the feature wish-list that I have compiled, based on personal
> experience and feedback I have received from other individuals and
> groups:

This sounds more like transparent (in-kernel?) file encryption 
than an encrypted filesystem.  I think there is value in
having both, or all three if you add encrypted block devices.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Encrypted Filesystem

[Adam Sampson]

Michael A Halcrow <mahalcro@us.ibm.com> writes:

>  - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)

Going off on a tangent...

There are all sorts of potentially-interesting things that could be
done if Linux had a userspace filesystem mechanism included in the
standard kernel -- as well as encryption, there's also network
filesystems, various sorts of specialised caching (such as Zero
Install), automounter-like systems, prototyping and so on.

Is there a technical reason that none of the userspace filesystem
layers have been included in the stock kernel, or is it just that
nobody's submitted any of them for inclusion yet?

-- 
Adam Sampson <azz@us-lot.org>                        <http://offog.org/>

Re: Encrypted Filesystem

[Andy Isaacson]

On Tue, Jan 27, 2004 at 12:43:21AM +0000, Adam Sampson wrote:
> Michael A Halcrow <mahalcro@us.ibm.com> writes:
> >  - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
> 
> Going off on a tangent...
> 
> There are all sorts of potentially-interesting things that could be
> done if Linux had a userspace filesystem mechanism included in the
> standard kernel -- as well as encryption, there's also network
> filesystems, various sorts of specialised caching (such as Zero
> Install), automounter-like systems, prototyping and so on.
> 
> Is there a technical reason that none of the userspace filesystem
> layers have been included in the stock kernel, or is it just that
> nobody's submitted any of them for inclusion yet?

There are a lot of subtle and not-so-subtle problems in this space.
For example, I really liked the paging example given in section 3.1 of
[Mazi2001].

[Mazi2001] "A toolkit for user-level file systems", David Mazieres,
    Proceedings of the 2001 USENIX Technical Conference
    available at http://www.fs.net/sfswww/pubs.html

-andy

Re: Encrypted Filesystem

[Jan Harkes]

On Tue, Jan 27, 2004 at 12:43:21AM +0000, Adam Sampson wrote:
> Michael A Halcrow <mahalcro@us.ibm.com> writes:
> 
> >  - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
> 
> Going off on a tangent...
> 
> There are all sorts of potentially-interesting things that could be
> done if Linux had a userspace filesystem mechanism included in the
> standard kernel -- as well as encryption, there's also network
> filesystems, various sorts of specialised caching (such as Zero
> Install), automounter-like systems, prototyping and so on.
> 
> Is there a technical reason that none of the userspace filesystem
> layers have been included in the stock kernel, or is it just that
> nobody's submitted any of them for inclusion yet?

Ehh, Coda's kernel module does just that. It is used by the userspace
cache manager of the Coda Distributed File System.

    http://www.coda.cs.cmu.edu/

But several other projects seem to be using it,

    http://uservfs.sourceforge.net/
    http://dav.sourceforge.net/

The interface to userspace a bit clumsy to work with, but there are
kernel modules for FreeBSD/NetBSD/Solaris and an experimental one for
Windows 2000/NT/XP, which makes any significant changes a bit of a pain.

It does have it's pecularities, reads and writes are not passed up to
userspace, only the open and close VFS calls. This makes the module
reasonably quite simple as it doesn't have to deal with VM issues and it
isn't susceptible to deadlocks,

   app wants to read data from a file ->
   userspace application requires memory allocation to provide this data ->
   VM tries to write out dirty data associated with the Coda mountpoint ==
   deadlock

So whole file caching keeps the kernel module more portable and
simplifies the userspace code. But it makes things like streaming
reads/writes or quotas impossible. If you want to provide encryption
there you would have to store an unencrypted copy of every open file
somewhere on disk or in ramfs/tmpfs and incur the cost of (de)crypting
(and (de)compressing) whenever it is opened or closed.

Jan

Re: Encrypted Filesystem

[Jean-Luc Cooke]

Ah, can someone explain why encrypted loopback doesn't solve this?

JLC

On Tue, Jan 27, 2004 at 05:01:54PM -0500, Jan Harkes wrote:
> On Tue, Jan 27, 2004 at 12:43:21AM +0000, Adam Sampson wrote:
> > Michael A Halcrow <mahalcro@us.ibm.com> writes:
> > 
> > >  - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
> > 
> > Going off on a tangent...
> > 
> > There are all sorts of potentially-interesting things that could be
> > done if Linux had a userspace filesystem mechanism included in the
> > standard kernel -- as well as encryption, there's also network
> > filesystems, various sorts of specialised caching (such as Zero
> > Install), automounter-like systems, prototyping and so on.
> > 
> > Is there a technical reason that none of the userspace filesystem
> > layers have been included in the stock kernel, or is it just that
> > nobody's submitted any of them for inclusion yet?
> 
> Ehh, Coda's kernel module does just that. It is used by the userspace
> cache manager of the Coda Distributed File System.
> 
>     http://www.coda.cs.cmu.edu/
> 
> But several other projects seem to be using it,
> 
>     http://uservfs.sourceforge.net/
>     http://dav.sourceforge.net/
> 
> The interface to userspace a bit clumsy to work with, but there are
> kernel modules for FreeBSD/NetBSD/Solaris and an experimental one for
> Windows 2000/NT/XP, which makes any significant changes a bit of a pain.
> 
> It does have it's pecularities, reads and writes are not passed up to
> userspace, only the open and close VFS calls. This makes the module
> reasonably quite simple as it doesn't have to deal with VM issues and it
> isn't susceptible to deadlocks,
> 
>    app wants to read data from a file ->
>    userspace application requires memory allocation to provide this data ->
>    VM tries to write out dirty data associated with the Coda mountpoint ==
>    deadlock
> 
> So whole file caching keeps the kernel module more portable and
> simplifies the userspace code. But it makes things like streaming
> reads/writes or quotas impossible. If you want to provide encryption
> there you would have to store an unencrypted copy of every open file
> somewhere on disk or in ramfs/tmpfs and incur the cost of (de)crypting
> (and (de)compressing) whenever it is opened or closed.
> 
> Jan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Userspace filesystems (WAS: Encrypted Filesystem)

[Miklos Szeredi]

Adam Sampson <azz@us-lot.org> wrote:

> Is there a technical reason that none of the userspace filesystem
> layers have been included in the stock kernel, or is it just that
> nobody's submitted any of them for inclusion yet?

I'm planning on submitting FUSE for inclusion into 2.7 (and maybe 2.6
if that is acceptable).  I feel that FUSE has been maturing lately
with some very interesting applications [1].

Here are the reasons for _not_ including it:

 1) There are already two filesystems in kernel that are perfectly
    usable for this purpose: NFS and CODA

 2) There are currently two competing userspace filesystem layers that
    have about the same "market share": LUFS and FUSE.  Why should we
    prefer one over the other

I'll try to refute myself on these points:

 1) Both NFS and CODA were designed for something different.  IOW they
    are not optimized for the purpose of supporting userspace
    filesystems.  NFS is slow and there are problems with coherency of
    the underlying and the mounted filesystem.  CODA does not support
    random file access (or even streaming), only reading whole files.
    It also has a miriad of small problems when used for exporting a
    userspace fs (I've been personally burned many times while doing
    AVFS over CODA).

 2) This one is harder to get rid of, especially because I don't want
    to delve into the technical merits of one or the other (I'd be a
    bit biased).  But I have compared both the kernel interface and
    the library API of LUFS and FUSE and they are very similar.  And
    that is a good thing, because it makes possible to support LUFS
    filesystems with the FUSE kernel module and vica versa.


Miklos

[1] For a list of applications using FUSE see:

   <http://www.inf.bme.hu/~mszeredi/fuse/Filesystems>

Re: Userspace filesystems (WAS: Encrypted Filesystem)

[Pavel Machek]

Hi!

>  2) This one is harder to get rid of, especially because I don't want
>     to delve into the technical merits of one or the other (I'd be a
>     bit biased).  But I have compared both the kernel interface and
>     the library API of LUFS and FUSE and they are very similar.  And
>     that is a good thing, because it makes possible to support LUFS
>     filesystems with the FUSE kernel module and vica versa.

Jean-Luc wrote:
>    app wants to read data from a file ->
>    userspace application requires memory allocation to provide this data ->
>    VM tries to write out dirty data associated with the Coda mountpoint ==
>    deadlock

How do you solve this one?
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Userspace filesystems (WAS: Encrypted Filesystem)

[Miklos Szeredi]

> Jean-Luc wrote:
> >    app wants to read data from a file ->
> >    userspace application requires memory allocation to provide this data ->
> >    VM tries to write out dirty data associated with the Coda mountpoint ==
> >    deadlock
> 
> How do you solve this one?

1) In FUSE normal writes go through the cache, so no dirty pages are
   created.  The only possibility to create dirty pages is with shared
   writable mapping, and this is rare

2) Userspace filesystem app can be multithreaded, so probably write
   can be satisfied even if read is pending.

3) The 2.6 kernel provides asynchronous page writeback, so even if a
   writeback is blocking forever the VM will continue to try to free
   up memory.

4) If no memory can be freed, then the allocation will fail, so the
   read will fail: no deadlock.

5) Even if the memory allocation was caused by a page fault, which
   cannot fail, the worst case is that the OOM killer is invoked, and
   memory is freed up: no deadlock.

So with the asynchronous page writeback mechanism the 2.6 kernel is
very immune to this kind of deadlock.  I have tested this with a
little program which behaves very nastily in this respect (I can send
you this if you're interested).  And I was able to invoke the OOM
killer if there was no swap, but there was never a deadlock.

Miklos

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: Userspace filesystems (WAS: Encrypted Filesystem)

[Pavel Machek]

Hi!

> > >    app wants to read data from a file ->
> > >    userspace application requires memory allocation to provide this data ->
> > >    VM tries to write out dirty data associated with the Coda mountpoint ==
> > >    deadlock
> > 
> > How do you solve this one?
> 
> 1) In FUSE normal writes go through the cache, so no dirty pages are
>    created.  The only possibility to create dirty pages is with shared
>    writable mapping, and this is rare
> 
> 2) Userspace filesystem app can be multithreaded, so probably write
>    can be satisfied even if read is pending.
> 
> 3) The 2.6 kernel provides asynchronous page writeback, so even if a
>    writeback is blocking forever the VM will continue to try to free
>    up memory.
> 
> 4) If no memory can be freed, then the allocation will fail, so the
>    read will fail: no deadlock.

Transient real failure looks pretty ugly. I'd not expect
read(/etc/passwd) to return -ENOMEM, and read(/#ftp:somewhere/passwd)
should be the same, but as this is basically "can not happen"... I
guess that's enough.
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Userspace filesystems (WAS: Encrypted Filesystem)

[Nikita Danilov]

Pavel Machek writes:
 > Hi!
 > 

[...]

 > 
 > Transient real failure looks pretty ugly. I'd not expect
 > read(/etc/passwd) to return -ENOMEM, and read(/#ftp:somewhere/passwd)

read(/etc/passwd) can fail with -ENOMEM while allocating a page in the
page cache.

 > should be the same, but as this is basically "can not happen"... I
 > guess that's enough.
 > 								Pavel

Nikita.

Encrypted Filesystem

[Hans Reiser]

I would encourage you to look at reiser4's encryption plugin.  It is 
currently able to perform most of the actions required to compile a 
kernel without crashing.;-)  Edward can provide more details.  Note that 
we encrypt and compress not with every write, but with every flush to 
disk, and this makes it reasonable to compress and encrypt everything 
routinely.

Probably it will be working soon, and definitely it could use another 
person working on it.  Note that the same framework also provides file 
compression, and we are hoping that on machines with a good ratio of CPU 
power to disk bandwidth we can actually increase performance as a result 
of using it.

Current reiser4 benchmarks without it are at 
www.namesys.com/benchmarks.html, and reiser4 is described at www.namesys.com

Hans

Nikita Danilov wrote:

 >
 > -------------------------
 >
 > Subject:
 > Encrypted Filesystem
 > From:
 > Michael A Halcrow <mahalcro@us.ibm.com>
 > Date:
 > Mon, 26 Jan 2004 11:46:29 -0600
 > To:
 > linux-kernel@vger.kernel.org
 >
 >

> I have some time this year to work on an encrypted filesystem for
> Linux.  I have surveyed various LUG's, tested and reviewed code for
> currently existing implementations, and have started modifying some
> of them.  I would like to settle on a single approach on which to
> focus my efforts, and I am interested in getting feedback from the
> LKML community as to which approach is the most feasible.
>
> This is the feature wish-list that I have compiled, based on personal
> experience and feedback I have received from other individuals and
> groups:
>
>  - Seamless application to the root filesystem
>   - Layered over the entire root filesystem
>   - Unencrypted pass-through mode with minimal overhead
>   - Files are marked as  ``encrypted'' or ``unencrypted'' and treated
>     accordingly by the encryption layer
>  - Key->file association
>   - As opposed to key->blkdev or key->directory granularity
>   - No encryption metafiles in directories, instead placing that
>     information into Extended Attributes
>   - May break some backup utilities that are not EA-aware; may require
>     another mode where encryption metadata is stored in a header block
>     on the encrypted file
>   - Directories can be flagged as ``encrypted-only'', where any new
>     files created in that directory are, by default, encrypted, with
>     the key and permissions defined in the directory's metadata
>   - Processes may have encryption contexts, whereby any new files they
>     create are encrypted by default according to the process'
>     authentication
>   - Make as much metadata about the file as confidential as possible
>     (filesize, executable bit, etc.)
>  - Pluggable encryption (I wouldn't mind using a block cipher in CTR
>    mode)
>  - Authentication via PAM
>   - pam_usb
>   - Bluetooth
>   - Kerberos
>   - PAM checks for group membership before allowing access to certain
>     encrypted files
>  - Rootplug-based LSM to provide key management (necessary to use
>    LSM?)
>  - Secret splitting and/or (m,n)-threshold support on the keys
>  - Signatures on files flagged for auditing in order to detect
>    attempts to circumvent the encryption layer (via direct
>    modifications to the files themselves in the underlying filesystem)
>  - Ad-hoc groups for access to decrypted versions of files
>   - i.e., launch web browser, drop group membership by default (like
>     capability inheritance masks) so that the browser does not have
>     access to decrypted files by default; PAM module checks for group
>     membership before allowing access (explicit user authorization on
>     application access requests)
>  - Userland utilities to support encrypted file management
>  - Extensions to nautilus and konqueror to be able to use these
>    utilities from a common interface (think: right-click, encrypted)
>  - Distro installation integration
>  - Transparent shredding, where the underlying filesystem supports it
>  - Versioning and snapshots (CVS-ish behavior)
>  - Design to work w/ SE Linux
>
> These are features that have been requested, but are not necessarily
> hard requirements for the encrypted filesystem.  They are just
> suggestions that I have received, and I am not convinced that they are
> all feasible.
>
> There are several potential approaches to an encrypted filesystem with
> these features, all with varying degrees of modification to the kernel
> itself, each with its own set of advantages and disadvantages.
>
> Options that I am aware of include:
>
>  - NFS-based (CFS, TCFS)
>   - CFS is mature
>   - Performance issues
>   - Violates UNIX semantics w/ hole behavior
>   - Single-threaded
>
>  - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
>   - Newer solutions, not as well accepted or tested as CFS
>   - KDE team is using SSHFS+FUSE
>
>  - Loopback (cryptoloop) encrypted block device
>   - Mature; in the kernel
>   - Block device granularity; breaks most incremental backup
>     applications
>
>  - LSM-based
>   - Is this even possible?  Are the hooks that we need there?
>
>  - Modifications to VFS (stackable filesystem, like NCryptfs)
>   - Very low overhead claimed by Erez Zadok
>   - Full implementation not released
>   - Key->directory granularity
>   - Evicts cleartext pages from the cache on process death
>   - Uses dcache to store attaches
>   - Other niceties, but it's not released...
>
> My goal is to develop an encrypted filesystem ``for the desktop'',
> where a user can right-click on a file in konqueror or nautilus and
> check the ``encrypted'' box, and all subsequent accesses by any
> processes to that file will require authentication in order for the
> file to be decrypted.  I have already made some modifications to CFS
> to support this functionality, but I am not sure at this moment
> whether or not CFS is the best route to go for this.
>
> I have had requests to write a kernel module that, when loaded,
> transparently starts acting as the encryption layer on top of whatever
> root filesystem is mounted.  For example, an ext3 partition may have
> encrypted files strewn about, which are accessible only after loading
> the module (and authenticating, etc.).
>
> Any advise or direction that the kernel community could provide would
> be very much appreciated.
>
> Thanks,
> Mike
> .___________________________________________________________________.
>                          Michael A. Halcrow
>        Security Software Engineer, IBM Linux Technology Center
> GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Encrypted Filesystem

[Edward Shishkin]

Hans Reiser wrote:
> 
> I would encourage you to look at reiser4's encryption plugin.  It is
> currently able to perform most of the actions required to compile a
> kernel without crashing.;-)  Edward can provide more details.  Note that
> we encrypt and compress not with every write, but with every flush to
> disk, and this makes it reasonable to compress and encrypt everything
> routinely.
> 
> Probably it will be working soon, and definitely it could use another
> person working on it.  Note that the same framework also provides file
> compression, and we are hoping that on machines with a good ratio of CPU
> power to disk bandwidth we can actually increase performance as a result
> of using it.

Yes. Also IBM's laptop hard disk space is too expensive, so I have presented
to myself T41 with only 40GB (5400rpm) HDD, keeping a great hope that it will
look like 60GB (7200!) after enabling transparent compression in reiser4  ;)

Seriously:
Transparent compression and(or) encryption (optionally) in reiser4 are
implemented via cryptcompress object plugin. Whats hot:

- Support of variable cluster size ((1, 2, 4, 8,..) * PAGE_SIZE)
via copy on clustering. The last means that page cluster will be
assembled into united flow before compression, and output stream of
decompression algorithm will be split into pages. Cluster size is an
attribute of cryptcompress files which means a size of maximal chunk
of data that can be passed to compression algorithm. This is required
attribute for each cryptcompress object, each cluster is compressed
and (or) encrypted independently. This allows to apply per cluster
various stream modes for encryption, which are also represented by
reiser4 stream plugins.

- High actual compression ratio which is close to ideal one that can
be provided by the compression algorithm for used cluster size. This is a
property of ctail items (aka fragments) that are used to store data of
cryptcompress objects.

> 
> Current reiser4 benchmarks without it are at
> www.namesys.com/benchmarks.html, and reiser4 is described at www.namesys.com
> 
> Hans
> 
>  >
>  > -------------------------
>  >
>  > From:>  > Michael A Halcrow <mahalcro@us.ibm.com>
>  > Date:
>  > Mon, 26 Jan 2004 11:46:29 -0600
>  > To:
>  > linux-kernel@vger.kernel.org
>  >
>  >
> 
> > I have some time this year to work on an encrypted filesystem for
> > Linux.  I have surveyed various LUG's, tested and reviewed code for
> > currently existing implementations, and have started modifying some
> > of them.  I would like to settle on a single approach on which to
> > focus my efforts, and I am interested in getting feedback from the
> > LKML community as to which approach is the most feasible.
> >
> > This is the feature wish-list that I have compiled, based on personal
> > experience and feedback I have received from other individuals and
> > groups:
> >
> >  - Seamless application to the root filesystem
> >   - Layered over the entire root filesystem
> >   - Unencrypted pass-through mode with minimal overhead

Would you comment this? 

> >   - Files are marked as  ``encrypted'' or ``unencrypted'' and treated
> >     accordingly by the encryption layer

Cryptcompress objects have special file attribute which is an ID of
reiser4 crypto plugin. If this attribute is zero, then file won't be
ciphered. Actually crypto plugin represents a crypto algorithm
supported by reiser4 and includes encrypt(), decrypt() and other
methods specific for this algorithm like setting a pointer of reiser4
specific inode data to cpu key, aligning flow before encryption,
etc.. The same for compression plugins.

> >  - Key->file association
> >   - As opposed to key->blkdev or key->directory granularity

Also cryptcompress file has the following extended attributes (I think
it will be useful to resolve some listed issues):
- digest plugin id (which represents digest algorithm supported by
reiser4: md5, sha1, etc..)
- key id (fingerprint of special randomly generated string, this string
is a part of a secret key, and this 'public' fingerprint is created
by appropriate digest plugin. 'Public' means that all EA should be
stored in disk stat-data. This key id allows to check authorization
every time when file is opened. Authorization is granted only by a
secret key (not by root password)

> >   - No encryption metafiles in directories, instead placing that
> >     information into Extended Attributes
> >   - May break some backup utilities that are not EA-aware; may require
> >     another mode where encryption metadata is stored in a header block
> >     on the encrypted file
> >   - Directories can be flagged as ``encrypted-only'', where any new
> >     files created in that directory are, by default, encrypted, with
> >     the key and permissions defined in the directory's metadata
> >   - Processes may have encryption contexts, whereby any new files they
> >     create are encrypted by default according to the process'
> >     authentication
> >   - Make as much metadata about the file as confidential as possible
> >     (filesize, executable bit, etc.)
> >  - Pluggable encryption (I wouldn't mind using a block cipher in CTR
> >    mode)

Reiser4 allows to support any compression algorithm of Ziv-Lempel
family, and any (symmetric or asymmetric) crypto algorithm (of course,
asymmetric ones are very slowly and may inflate data, but enabling of
short files encrypted by public/private keys can be useful for various
management purposes.

> >  - Authentication via PAM
> >   - pam_usb
> >   - Bluetooth
> >   - Kerberos
> >   - PAM checks for group membership before allowing access to certain
> >     encrypted files
> >  - Rootplug-based LSM to provide key management (necessary to use
> >    LSM?)
> >  - Secret splitting and/or (m,n)-threshold support on the keys
> >  - Signatures on files flagged for auditing in order to detect
> >    attempts to circumvent the encryption layer (via direct
> >    modifications to the files themselves in the underlying filesystem)
> >  - Ad-hoc groups for access to decrypted versions of files
> >   - i.e., launch web browser, drop group membership by default (like
> >     capability inheritance masks) so that the browser does not have
> >     access to decrypted files by default; PAM module checks for group
> >     membership before allowing access (explicit user authorization on
> >     application access requests)
> >  - Userland utilities to support encrypted file management
> >  - Extensions to nautilus and konqueror to be able to use these
> >    utilities from a common interface (think: right-click, encrypted)
> >  - Distro installation integration
> >  - Transparent shredding, where the underlying filesystem supports it
> >  - Versioning and snapshots (CVS-ish behavior)
> >  - Design to work w/ SE Linux
> >
> > These are features that have been requested, but are not necessarily
> > hard requirements for the encrypted filesystem.  They are just
> > suggestions that I have received, and I am not convinced that they are
> >
> > There are several potential approaches to an encrypted filesystem with
> > these features, all with varying degrees of modification to the kernel
> > itself, each with its own set of advantages and disadvantages.
> >
> > Options that I am aware of include:
> >
> >  - NFS-based (CFS, TCFS)
> >   - CFS is mature
> >   - Performance issues
> >   - Violates UNIX semantics w/ hole behavior
> >   - Single-threaded
> >
> >  - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
> >   - Newer solutions, not as well accepted or tested as CFS
> >   - KDE team is using SSHFS+FUSE
> >
> >  - Loopback (cryptoloop) encrypted block device
> >   - Mature; in the kernel
> >   - Block device granularity; breaks most incremental backup
> >     applications
> >
> >  - LSM-based
> >   - Is this even possible?  Are the hooks that we need there?
> >
> >  - Modifications to VFS (stackable filesystem, like NCryptfs)
> >   - Very low overhead claimed by Erez Zadok
> >   - Full implementation not released
> >   - Key->directory granularity
> >   - Evicts cleartext pages from the cache on process death
> >   - Uses dcache to store attaches
> >   - Other niceties, but it's not released...
> >
> > My goal is to develop an encrypted filesystem ``for the desktop'',
> > where a user can right-click on a file in konqueror or nautilus and
> > check the ``encrypted'' box, and all subsequent accesses by any
> > processes to that file will require authentication in order for the
> > file to be decrypted.  I have already made some modifications to CFS
> > to support this functionality, but I am not sure at this moment
> > whether or not CFS is the best route to go for this.
> >
> > I have had requests to write a kernel module that, when loaded,
> > transparently starts acting as the encryption layer on top of whatever
> > root filesystem is mounted.  For example, an ext3 partition may have
> > encrypted files strewn about, which are accessible only after loading
> > the module (and authenticating, etc.).
> >
> > Any advise or direction that the kernel community could provide would
> > be very much appreciated.
> >
> > Thanks,
> > Mike

Thanks for the list, 
Edward.

Re: Encrypted Filesystem

[Michael Halcrow]

[-- Attachment #1: Type: text/plain, Size: 4587 bytes --]

On Tue, Jan 27, 2004 at 09:56:04PM +0300, Edward Shishkin wrote:
> > >   - Unencrypted pass-through mode with minimal overhead
> Would you comment this? 

Allow me to clarify.  A transparent encryption layer like CFS will
encrypt anything written out to a CFS mount and decrypt anything read
from a CFS mount, using the metadata associated with the source
directory.  One potential modification to something like CFS would be
to make the encryption optional; a file behind a CFS mount may or may
not be encrypted, depending on an EA set in the file in the source
directory.  If this were to apply to an entire root filesystem, then
one would want to minimize the overhead imposed by the CFS layer when
dealing with files that are not flagged as encrypted.

I have had a discussion with Steve French[1] on this topic, who has
given me some interesting insights.  In general, one of my design
goals in an encrypted filesystem is to minimize overhead for the
default (unencrypted) case.  In fs/jfs/file.c:106, the fileop read
pointer is set to generic_file_read.  This is passed the file struct,
which can contain the encrypted status of file.  If the file is marked
as encrypted, then the block can be assumed to be encrypted.  The
pages in the blocks that are read can then be placed in a scatterlist
and decrypted with the crypto code in the kernel, according to further
metadata pointed to by the file struct (cipher id, key, etc.) and
according to the credentials in the task structure.  Perhaps this
logic can be placed in a new jfs_file_read and the fileop read pointer
can point there instead; the jfs_file_read will check
filp->f_encryption->encrypted, and if it is set (unlikely()), then it
will continue with a read-and-decrypt, else it will just call
generic_file_read.  This pointer will need to get set for each
relevant function in each filesystem that supports file encryption in
this manner.

> Also cryptcompress file has the following extended attributes (I think
> it will be useful to resolve some listed issues):
> - digest plugin id (which represents digest algorithm supported by
> reiser4: md5, sha1, etc..)
> - key id (fingerprint of special randomly generated string, this string
> is a part of a secret key, and this 'public' fingerprint is created
> by appropriate digest plugin. 'Public' means that all EA should be
> stored in disk stat-data. This key id allows to check authorization
> every time when file is opened. Authorization is granted only by a
> secret key (not by root password)
> ...
> Reiser4 allows to support any compression algorithm of Ziv-Lempel
> family, and any (symmetric or asymmetric) crypto algorithm (of course,
> asymmetric ones are very slowly and may inflate data, but enabling of
> short files encrypted by public/private keys can be useful for various
> management purposes.

Hans has been doing some very interesting work in this area.  I am
aware of reiser4; Hans may remember having lunch with me at the
DISCEX-III conference in Washington, D.C. last year.  My booth (the
BYU Internet Security Research Lab; Trust Negotiation) was right
across from his:

http://csdl.computer.org/comp/proceedings/discex/2003/1897/02/1897toc.htm

He had a lengthy discussion with Jason Holt[2] on the implementation
of crypto in reiser4.

While I appreciate the security features that are part of reiser4, my
efforts toward filesystem encryption are aimed at a more general
level, to provide an encryption layer that will work across several
filesystems.  Perhaps we can look into unifying and abstracting the
key management, authentication, and other aspects involved in a
comprehensive filesystem encryption system, extending and using kernel
structures (struct file, kobject/sysfs, etc.) to maintain that data,
so whether someone is using reiser4, Security Enhanced ext3 (SEext3),
or Security Enhanced jfs (SEjfs)[3], the interface to userland will be
the same.

Mike

[1] Steve works on the Samba team down the hall from me; he's working
on CFIS at the moment

[2] Hans: Jason was a co-worker of mine in the ISRL, skinny and tall
with curly red hair (he's hard to forget once you've met him:
<http://isrl.cs.byu.edu/images/Dcp02290.jpg>)

[3] That was meant to be funny...
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Encrypted Filesystem

[Hans Reiser]

Michael Halcrow wrote:

>
>  I am
>aware of reiser4; Hans may remember having lunch with me at the
>DISCEX-III conference in Washington, D.C. last year.  My booth (the
>BYU Internet Security Research Lab; Trust Negotiation) was right
>across from his:
>
>http://csdl.computer.org/comp/proceedings/discex/2003/1897/02/1897toc.htm
>
>He had a lengthy discussion with Jason Holt[2] on the implementation
>of crypto in reiser4.
>
>While I appreciate the security features that are part of reiser4, my
>efforts toward filesystem encryption are aimed at a more general
>level, to provide an encryption layer that will work across several
>filesystems.  Perhaps we can look into unifying and abstracting the
>key management, authentication, and other aspects involved in a
>comprehensive filesystem encryption system, extending and using kernel
>structures (struct file, kobject/sysfs, etc.) to maintain that data,
>so whether someone is using reiser4, Security Enhanced ext3 (SEext3),
>or Security Enhanced jfs (SEjfs)[3], the interface to userland will be
>the same.
>  
>
I am in principle interested in doing this, especially since the area of 
our inspiration is not in key management but in performance.

>
>[2] Hans: Jason was a co-worker of mine in the ISRL, skinny and tall
>with curly red hair (he's hard to forget once you've met him:
><http://isrl.cs.byu.edu/images/Dcp02290.jpg>)
>  
>
Jason is working on a write only plugin (or at least he said so a few 
months ago) for reiser4.  You probably remember him discussing it then.  
Where is your photo, or are you a CIA spy who needs to keep it 
secret....;-)  I remember three interesting people talked to me all at 
once at that conference about reiser4 crypto and other things that crept 
into that conversation, if you send your photo I can know if I remember 
correctly which one other than Jason you were.

>[3] That was meant to be funny...
>.___________________________________________________________________.
>                         Michael A. Halcrow                          
>       Security Software Engineer, IBM Linux Technology Center       
>GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D
>  
>

Re: Encrypted Filesystem

[Andi Kleen]

Michael A Halcrow <mahalcro@us.ibm.com> writes:

Hi,

First thanks for attempting this work. The state of art of encrypted 
file systems in Linux currently is really not satisfying and can need
some improvements.

Here are some thoughts about it:

I wrote my own crypto loop implementation at some point because I 
wasn't satisfied with the existing ones for my own needs. From that
experience I think first going over crypto loop is not a good idea
because a block device is not a good unit of encryption.
Better use a stacking file system or somesuch. Technically this 
has the advantage that you don't need to cache the data twice (crypto 
loop keeps both unencrypted and crypted data in the page cache) 
and the disadvantage that you need to encrypt on every write instead of
every cache flush (that's quite reasonable with fast encryption algorithms) 

The biggest shortcomming in crypto loop is that you cannot change the
password easily. Doing so would require reencryption of the whole
volume and it is hard to do so in a crash safe way (or you risk loss
of the volume when the machine crashes during reencryption) Another
problem is that using the user key makes it easy to use dictionary
attacks using known plain text. For example the first block on a ext2
file system is always zero and can be easily used to do a dictionary
attack based on a weak user password.  The standard crypto loop uses
fixed IVs too which do not help against this.  

I fixed this for my private implementation by using a different
encrypted keyfile and a session key for the actual implementation. And
the IV for each block is generated by a hash with another
secret. Disadvantage is of course that you have to store the keyfile
somewhere (with loop it is not practical to put any metadata into the
encrypted volume) and not lose it. With an stacking file system that
would be easier because you can just store it directly into underlying
fs.

One problem with this approach for a stacking file system is that you
need a new session key for each file if you encrypt them separately.
I'm not quite sure /dev/random can supply that many good secrets.
On a normal user system there is plenty of entropy from the keyboard
and mouse, but on a headless server it can be quite difficult.
For a loop device you only need the session key once so it's not a big
issue. For any session keys you may need to store secret state separately and
use a different method to generate them based on the state (e.g. using
a counter and a secure hash) 

Another problem with stacking file systems is that they're not really
tried in the Linux VFS and there may be problems with it. Still they're
probably solvable. Please when you encounter any problems report them
to the Linux developers to fix them cleanly, not work around them in ugly ways
in your own code.

Not directly related to the file system, but in a bigger picture the
biggest problem with using cryptography regularly in Linux is that
there is no nice way for users to prevent pages from being swapped out
to disk.  Always when you decrypt a file you risk it ending up
unencrypted on the swap partition.  This means even when your file
system encrypts great you still risk your data when reading it.

While it would be possible to encrypt swap too I'm not sure this is a
good idea: e.g. it requires global key management, which is probably
bad. And it could cause performance problems. One idea that has been
around forever for it was to give each uid a global quota for
mlock()ed pages. This would at least allow to keep the keys secure.
One a bit more far fetched idea I was thinking about was to make the
mlock quota quite big (let's say for the currently logged in X user
1/2 of memory or less for a multi user system) and add a "crypto
tainted" flag to the processes. This means every process that accesses
the crypto file system is tainted this way and is prevented from
writing out any dirty pages up to the quota. Other swapping that
doesn't involve writing dirty pages like discarding of read only
program text is fine.  When you exceed the quota you could warn 
the user or prevent the process from growing in a more security 
paranoid setting. This is not 100% fool proof - it could somehow
leak the secret data to other not tained processes, but would probably
still do much better than the current "I don't care" state.

Back from the far fetched ideas. I think using a stacked file system
is the best way to go.  Loop is just too dumb. NFS loopback or FUSE
are too slow. The biggest challenge is probably good key management
(both session and user keys). The Linux interface will be probably
simple compared to that.

-Andi

Re: Encrypted Filesystem

[Jari Ruusu]

Andi Kleen wrote:
> Better use a stacking file system or somesuch. Technically this
> has the advantage that you don't need to cache the data twice (crypto
> loop keeps both unencrypted and crypted data in the page cache)

Not true for device backed loops. At least on device backed loops on
loop-AES implementation encrypted data in not stored in page cache.

> The biggest shortcomming in crypto loop is that you cannot change the
> password easily. Doing so would require reencryption of the whole
> volume and it is hard to do so in a crash safe way (or you risk loss
> of the volume when the machine crashes during reencryption)

Not true with loop-AES where changing password is either:

  gpg --decrypt </root/fskey1.gpg | ( sleep 60; gpg --symmetric >/etc/fskey2.gpg )
  mv /etc/fskey2.gpg /etc/fskey1.gpg

or:

  gpg --edit-key "myname"
  Command> passwd

depending on how gpg key file was encrypted.

> Another
> problem is that using the user key makes it easy to use dictionary
> attacks using known plain text. For example the first block on a ext2
> file system is always zero and can be easily used to do a dictionary
> attack based on a weak user password.

Not true. loop-AES solved this dictionary attack problem in 2001. Mainline
and kerneli.org versions are vulnerable as always.

> The standard crypto loop uses
> fixed IVs too which do not help against this.

Not true. Mainline uses simple sector IV. SuSE twofish uses fixed IV which
is even more vulnerable than mainline. Loop-AES 2.x versions use more secure
MD5 IV, but they are also compatible with old setups for backward
compatibility sake.

> Not directly related to the file system, but in a bigger picture the
> biggest problem with using cryptography regularly in Linux is that
> there is no nice way for users to prevent pages from being swapped out
> to disk.  Always when you decrypt a file you risk it ending up
> unencrypted on the swap partition.  This means even when your file
> system encrypts great you still risk your data when reading it.

That is what encrypted swap is for. Loop-AES version of loop was rewritten
in 2001 to be compatible with encrypted swap. That work included removing
all runtime memory allocations from device backed loops.

Quote from loop-AES README file:

First, run "swapoff -a" to turn off swap devices in your /etc/fstab file.
Second, add "loop=/dev/loop?" and "encryption=AES128" options to swap lines 
in your /etc/fstab file. Example:

 /dev/hda666   none   swap   sw,loop=/dev/loop6,encryption=AES128   0   0
                                ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
Third, there may be old unencrypted data on your swap devices, in which case
you can try to overwrite that data with command like this:

    dd if=/dev/zero of=/dev/hda666 bs=64k conv=notrunc
    mkswap /dev/hda666

Fourth, run "swapon -a" and "rm -rf /var/log/ksymoops" and you are done.

> While it would be possible to encrypt swap too I'm not sure this is a
> good idea: e.g. it requires global key management, which is probably
> bad.

"swapon -a" reads some random bits from /dev/urandom and recycles old
encrypted swap data while it generates 64 new random swap keys for each loop
device that it uses to encrypt swap partitions. No 'global key management'
problem whatsoever. Encrypted swap has worked fine since 2001.

> And it could cause performance problems.

Optimized assembler implementation of AES cipher works fast enough here.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: Encrypted Filesystem

[Andi Kleen]

On Tue, 27 Jan 2004 20:17:03 +0200
Jari Ruusu <jariruusu@users.sourceforge.net> wrote:
> > The biggest shortcomming in crypto loop is that you cannot change the
> > password easily. Doing so would require reencryption of the whole
> > volume and it is hard to do so in a crash safe way (or you risk loss
> > of the volume when the machine crashes during reencryption)
> 
> Not true with loop-AES where changing password is either:

[...] My version of the loop tools also do all this correctly too. But the loop
most people seem to be using is as insecure as always.  Congratulations
that you fixed it too.

Still considering the other points I think a stacked file system would
be far better  (integrated meta data, separate keys for different files etc.)
Even though I invested quite some work into fixing loop I still think it's a bad
hack, not a real design.

> > The standard crypto loop uses
> > fixed IVs too which do not help against this.
> 
> Not true. Mainline uses simple sector IV. SuSE twofish uses fixed IV which
> is even more vulnerable than mainline. 

It's as as vunerable, but more stable. The mainline IVs are basically useless
for security purposes but broke  on disk format compatibility all the time when 
someone misguided decided again to "improve" the IV format in loop.c (happened far too 
often in the past). In my own loop tools I used them with an hashed IV, added some 
hacks for different IV versions as far as they were fixable and grumbingly converted
the disk format in one case.

[... encrypted swap using a random key for each session...]

Good point. I didn't think of that. Still it's a lot of overhead if you
only use crypto occassionally. With the tainted bit it would be possible to only encrypt 
pages of processes that have been tainted or better not page them out at all.

-Andi