[dm-crypt] Can SED/FDE limit access to a particular user?

[dm-crypt] Can SED/FDE limit access to a particular user?

[helices]

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

We have to protect sensitive files and keep them available for use by a
particular user for 7+ years

We prefer self encrypted disk (SED), but, it's being too difficult to get a
straight answer regarding do-ability of our application. We are currently
using LUKS filesystems on several servers - so we know how good this is. We
do not, however, know whether or not we can do what we want with it.

We understand how full disk encryption (FDE) normally works: once the drive
is decrypted (via key/password, etc.) then the whole drive is visible to
whomever has system access

We do NOT want that.

Ideally, the drive will be unreadable to everybody. During a brief period
of time when a new file is to be written to the drive and also a brief
period of time when a particular file is to be read from disk, a specific
user would "unlock" the drive for this specific task, after which the whole
drive will be unreadable to everybody.

We would consider other scnearios; but, it is essential that all of the
contents of this disk are unreadable to everybody, except one particular
user.

Furthermore, as a file server application serving enterprise critical
files, redundancy is also a high priority. Currently, we run several SANs
with RAID 6 and prefer similar redundancy for this application.

Almost all of our servers are Linux based and we prefer the same here.

We do a high volume of PGP/GPG file encryption for file transfer; but, we
prefer FDE for static files

How can we accomplish this?

Please, advise. Thank you.

~ helices

[-- Attachment #2: Type: text/html, Size: 1843 bytes --]

Re: [dm-crypt] Can SED/FDE limit access to a particular user?

[Matthias Schniedermeyer]

On 12.12.2013 09:18, helices wrote:
> We have to protect sensitive files and keep them available for use by a
> particular user for 7+ years
> 
> We prefer self encrypted disk (SED), but, it's being too difficult to get a
> straight answer regarding do-ability of our application. We are currently
> using LUKS filesystems on several servers - so we know how good this is. We
> do not, however, know whether or not we can do what we want with it.
> 
> We understand how full disk encryption (FDE) normally works: once the drive
> is decrypted (via key/password, etc.) then the whole drive is visible to
> whomever has system access
> 
> We do NOT want that.
> 
> Ideally, the drive will be unreadable to everybody. During a brief period
> of time when a new file is to be written to the drive and also a brief
> period of time when a particular file is to be read from disk, a specific
> user would "unlock" the drive for this specific task, after which the whole
> drive will be unreadable to everybody.
> 
> We would consider other scnearios; but, it is essential that all of the
> contents of this disk are unreadable to everybody, except one particular
> user.
> 
> Furthermore, as a file server application serving enterprise critical
> files, redundancy is also a high priority. Currently, we run several SANs
> with RAID 6 and prefer similar redundancy for this application.
> 
> Almost all of our servers are Linux based and we prefer the same here.
> 
> We do a high volume of PGP/GPG file encryption for file transfer; but, we
> prefer FDE for static files
> 
> How can we accomplish this?

A little more precision in the description would be nice.

- You don't trust root? (Which means you are pretty screwed, unless you 
are already using SELinux or somesuch)
- It should be a client/server "thing"?
Those 2 are quite potent mutual exclusions.

- Backup to a remote Server
Or would a USB-HDD or somesuch be "enough"?


With a dedicated computer that can only be controller by the user it 
wouldn't be that hard.

ecryptfs (no personal experience) would make it easy to backup, just 
rsync the encrypted files.

A little autofs "magic" helps with automating the setup/teardown. I 
personally mount most of my encrypted devices by autofs, altough i had 
to patch [u]mount for the setup/teardown of dm-crypt as i'm using the 
"standard" direct(?)-mapping with the ghosting-option (To have 'tab'able 
direcories), there are other mapping-types that should support it 
without such clutches.

Depending on how the mounting of ecryptfs works (again, no personal 
experience) a little integration with gpg-agent or somesuch should make 
it possible to for e.g. load a key or an hour or so and then have it 
automountable in that timeframe. And autofs does that umount 
automatically if there are no open files and the timeout runs out.



-- 

Matthias

Re: [dm-crypt] Can SED/FDE limit access to a particular user?

[helices]

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

Hi, Matthias!

Yes, a bit of clarification.

It is not a matter of not trusting root.

Rather, the "read" and "write" processes are sub-processes of a more
extensive process and will run as a non-privileged user - not root.

Therefore, it is simpler - read, easier for the PCI-DSS auditor to
comprehend its security - if only this non-privileged user can read and
write on this filesystem.

I see statements like this: "LUKS allows multiple user keys to decrypt a
master key which is used for the bulk encryption of the partition" here:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html

This implies that a non-privileged user can have sole access to a LUKS
filesystem. "Implicit" must be made explicit.

FDE protects data if the disk is stolen.

We want to protect the data on the live system as well.

Does this make sense to you?

Please, advise. Thank you.

~ helices


On Thu, Dec 12, 2013 at 10:51 AM, Matthias Schniedermeyer <ms@citd.de>wrote:

> On 12.12.2013 09:18, helices wrote:
> > We have to protect sensitive files and keep them available for use by a
> > particular user for 7+ years
> >
> > We prefer self encrypted disk (SED), but, it's being too difficult to
> get a
> > straight answer regarding do-ability of our application. We are currently
> > using LUKS filesystems on several servers - so we know how good this is.
> We
> > do not, however, know whether or not we can do what we want with it.
> >
> > We understand how full disk encryption (FDE) normally works: once the
> drive
> > is decrypted (via key/password, etc.) then the whole drive is visible to
> > whomever has system access
> >
> > We do NOT want that.
> >
> > Ideally, the drive will be unreadable to everybody. During a brief period
> > of time when a new file is to be written to the drive and also a brief
> > period of time when a particular file is to be read from disk, a specific
> > user would "unlock" the drive for this specific task, after which the
> whole
> > drive will be unreadable to everybody.
> >
> > We would consider other scnearios; but, it is essential that all of the
> > contents of this disk are unreadable to everybody, except one particular
> > user.
> >
> > Furthermore, as a file server application serving enterprise critical
> > files, redundancy is also a high priority. Currently, we run several SANs
> > with RAID 6 and prefer similar redundancy for this application.
> >
> > Almost all of our servers are Linux based and we prefer the same here.
> >
> > We do a high volume of PGP/GPG file encryption for file transfer; but, we
> > prefer FDE for static files
> >
> > How can we accomplish this?
>
> A little more precision in the description would be nice.
>
> - You don't trust root? (Which means you are pretty screwed, unless you
> are already using SELinux or somesuch)
> - It should be a client/server "thing"?
> Those 2 are quite potent mutual exclusions.
>
> - Backup to a remote Server
> Or would a USB-HDD or somesuch be "enough"?
>
>
> With a dedicated computer that can only be controller by the user it
> wouldn't be that hard.
>
> ecryptfs (no personal experience) would make it easy to backup, just
> rsync the encrypted files.
>
> A little autofs "magic" helps with automating the setup/teardown. I
> personally mount most of my encrypted devices by autofs, altough i had
> to patch [u]mount for the setup/teardown of dm-crypt as i'm using the
> "standard" direct(?)-mapping with the ghosting-option (To have 'tab'able
> direcories), there are other mapping-types that should support it
> without such clutches.
>
> Depending on how the mounting of ecryptfs works (again, no personal
> experience) a little integration with gpg-agent or somesuch should make
> it possible to for e.g. load a key or an hour or so and then have it
> automountable in that timeframe. And autofs does that umount
> automatically if there are no open files and the timeout runs out.
>
>
>
> --
>
> Matthias
>

[-- Attachment #2: Type: text/html, Size: 5213 bytes --]

Re: [dm-crypt] Can SED/FDE limit access to a particular user?

[Matthias Schniedermeyer]

On 12.12.2013 11:13, helices wrote:
> Hi, Matthias!
> 
> Yes, a bit of clarification.
> 
> It is not a matter of not trusting root.
> 
> Rather, the "read" and "write" processes are sub-processes of a more
> extensive process and will run as a non-privileged user - not root.
> 
> Therefore, it is simpler - read, easier for the PCI-DSS auditor to
> comprehend its security - if only this non-privileged user can read and
> write on this filesystem.

That can be done with basic filesystem permissions.

- mount it
- chown user /mntpoint
- chmod 700 /mntpoint

After that only the user with that specific uid (and root) can access 
the data below that mountpoint, nobody else.

> I see statements like this: "LUKS allows multiple user keys to decrypt a
> master key which is used for the bulk encryption of the partition" here:
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html
> 
> This implies that a non-privileged user can have sole access to a LUKS
> filesystem. "Implicit" must be made explicit.

LUKS is not a fileystems.
It's a "bit-bucket" with a defined header that provides it's "payload" 
as a transparently de-/encrypted block device. Ontop of which you can 
put a filesystem.

After a LUKS device has been opened the resulting dm-crypt device is 
like any other block-device, there is no more or less security than any 
other block-device.

Same goes for the (technically optional) filesystem. You have all 
(un)security that the used file filesystems provides, regardless of the 
underlying block-device beeing encrypted or not.

IOW the filesystem doesn't "know" that it's underlying block-device is 
encrypted and the underlying block-device couldn't care less about was 
is put inside it, it's just a bit-bucket.

> FDE protects data if the disk is stolen.

Exactly.

> We want to protect the data on the live system as well.
> 
> Does this make sense to you?

Some sense yes.

But "online" security is it's own research field with practically 
endless complexity and compromise, unlike "offline" security which is 
relativly simpel and simple to understand.

For "online" security you have to create a threat model that you want to 
defend against and model your solution accordingly and see where you may 
have to make compromises so the solution is still practical.

One of the first questions in "online" security: "Can you trust root" is 
quite essential in what you can/can't/have to do.
If you trust root and "standard" permissions, the chown/chmod maybe all 
you need.

You would need to be root to circumvent basic filesystem permissions, or 
you would need the password/key and the device to mount it on another 
computer where you could circumvent the filesystem permissions.


> On Thu, Dec 12, 2013 at 10:51 AM, Matthias Schniedermeyer <ms@citd.de>wrote:
> 
> > On 12.12.2013 09:18, helices wrote:
> > > We have to protect sensitive files and keep them available for use by a
> > > particular user for 7+ years
> > >
> > > We prefer self encrypted disk (SED), but, it's being too difficult to
> > get a
> > > straight answer regarding do-ability of our application. We are currently
> > > using LUKS filesystems on several servers - so we know how good this is.
> > We
> > > do not, however, know whether or not we can do what we want with it.
> > >
> > > We understand how full disk encryption (FDE) normally works: once the
> > drive
> > > is decrypted (via key/password, etc.) then the whole drive is visible to
> > > whomever has system access
> > >
> > > We do NOT want that.
> > >
> > > Ideally, the drive will be unreadable to everybody. During a brief period
> > > of time when a new file is to be written to the drive and also a brief
> > > period of time when a particular file is to be read from disk, a specific
> > > user would "unlock" the drive for this specific task, after which the
> > whole
> > > drive will be unreadable to everybody.
> > >
> > > We would consider other scnearios; but, it is essential that all of the
> > > contents of this disk are unreadable to everybody, except one particular
> > > user.
> > >
> > > Furthermore, as a file server application serving enterprise critical
> > > files, redundancy is also a high priority. Currently, we run several SANs
> > > with RAID 6 and prefer similar redundancy for this application.
> > >
> > > Almost all of our servers are Linux based and we prefer the same here.
> > >
> > > We do a high volume of PGP/GPG file encryption for file transfer; but, we
> > > prefer FDE for static files
> > >
> > > How can we accomplish this?
> >
> > A little more precision in the description would be nice.
> >
> > - You don't trust root? (Which means you are pretty screwed, unless you
> > are already using SELinux or somesuch)
> > - It should be a client/server "thing"?
> > Those 2 are quite potent mutual exclusions.
> >
> > - Backup to a remote Server
> > Or would a USB-HDD or somesuch be "enough"?
> >
> >
> > With a dedicated computer that can only be controller by the user it
> > wouldn't be that hard.
> >
> > ecryptfs (no personal experience) would make it easy to backup, just
> > rsync the encrypted files.
> >
> > A little autofs "magic" helps with automating the setup/teardown. I
> > personally mount most of my encrypted devices by autofs, altough i had
> > to patch [u]mount for the setup/teardown of dm-crypt as i'm using the
> > "standard" direct(?)-mapping with the ghosting-option (To have 'tab'able
> > direcories), there are other mapping-types that should support it
> > without such clutches.
> >
> > Depending on how the mounting of ecryptfs works (again, no personal
> > experience) a little integration with gpg-agent or somesuch should make
> > it possible to for e.g. load a key or an hour or so and then have it
> > automountable in that timeframe. And autofs does that umount
> > automatically if there are no open files and the timeout runs out.
> >
> >
> >
> > --
> >
> > Matthias
> >

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 

Matthias

Re: [dm-crypt] Can SED/FDE limit access to a particular user?

[Claudio Moretti]

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

On Thu, Dec 12, 2013 at 3:18 PM, helices <dm-crypt@mdsresource.net> wrote:

> We understand how full disk encryption (FDE) normally works: once the
> drive is decrypted (via key/password, etc.) then the whole drive is visible
> to whomever has system access
>
That is not exact; as Matthias said, filesystem permissions allow you to
limit access to the FS, making sure that nobody except the user who has the
FS permissions (and root, of course) can access such files.
That is not, as far as I'm aware, the purpose of LUKS which is (using
Matthias's words again)

a "bit-bucket" with a defined header that provides it's "payload" as a
> transparently de-/encrypted block device. Ontop of which you can put a
> filesystem.
>

That is, of course, if by "system access" you mean "access to the system".
If you're worried about people with root access, than it's another matter
entirely.

However, you could (and FYI I haven't tested it, it's just a thought, but I
believe it's a valid one) build a system with an unencrypted system
partition and an encrypted data partition (as happens when having /
unenecrypted and /home encrypted)

In this system you could install your preferred data transfer client, let's
say rsync (the only one I can think at the moment with the minimum
requirements I'm thinking about).
You can configure it to[1]:
- authenticate users before transferring
- chroot the session
-

*execute commands before and after the transfer*
This is done using the

> *pre-xfer exec*, *post-xfer exec*
> You may specify a command to be run before and/or after the transfer. If
> the *pre-xfer exec* command fails, the transfer is aborted before it
> begins.


directives.
With those, you could unlock the encrypted partition, mount it (use
/dev/disk/by-uuid to be sure you're not mounting the wrong one), transfer,
unmount it and lock it again, and this happens in what I believe is the
shortest time possible, and it seems to me it aligns with the requirement
you were mentioning:

> Ideally, the drive will be unreadable to everybody. During a brief period
> of time when a new file is to be written to the drive and also a brief
> period of time when a particular file is to be read from disk, a specific
> user would "unlock" the drive for this specific task, after which the whole
> drive will be unreadable to everybody.
>
You can run the daemon under a specific uig/gid and, if you need to, you
can enable it to be "write only".

This should not affect your RAID6 configuration, as we're above system
level (well above LUKS level) and the only thing you'll have to worry about
is the cipher you chose when you first set up the encrypted drive.

Again, this is only a thought, but on [electronic] paper it seems te
simplest solution.

Feel free to let me know if I misunderstood something.

Cheers,

Claudio

[1] http://linux.die.net/man/5/rsyncd.conf

[-- Attachment #2: Type: text/html, Size: 4178 bytes --]

Re: [dm-crypt] Can SED/FDE limit access to a particular user?

[Arno Wagner]

On Thu, Dec 12, 2013 at 18:13:57 CET, helices wrote:
> Hi, Matthias!
> 
> Yes, a bit of clarification.
> 
> It is not a matter of not trusting root.
> 
> Rather, the "read" and "write" processes are sub-processes of a more
> extensive process and will run as a non-privileged user - not root.
> 
> Therefore, it is simpler - read, easier for the PCI-DSS auditor to
> comprehend its security - if only this non-privileged user can read and
> write on this filesystem.

Ok, going through an audit like this, you want everything as 
simple as possible, quite understandable.
 
> I see statements like this: "LUKS allows multiple user keys to decrypt a
> master key which is used for the bulk encryption of the partition" here:
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html
> 
> This implies that a non-privileged user can have sole access to a LUKS
> filesystem. "Implicit" must be made explicit.

No. It means that anybody that has root permissions can supply a 
passphrase. The "users" here refers to people, not to OS roles.
In most situations a user has to be logged in as root to 
use cryptestup directly. Indirect use can of course be 
via a custom demon or suid-binary.

> FDE protects data if the disk is stolen.
> 
> We want to protect the data on the live system as well.

That is not a job for encryption. That is a job for normal OS
access control mechanisms. For example, an NFS daemon does this
or filesystem permission do. Encryption can only be added as
an additional mechanism, but it is all-or-nothing. 

You could, for example, have a daemon that a user (OS role)
supplies its (person) passphrase to and the daemon does the 
following:

1. Open LUKS container withe the passphrase.
   Wipe passprase from demon memory here already.
2. Create a directory that only this user (OS role) can 
   get into.
3. Create a directoy within the first that serves as 
   mount point.
4. Mount whatever filesystem is in the LUKS container
   on the mount point from 3.
5. Determine somehow when to remove access again.
   Options:
   - fixed time after opening
   - fixed idle time (the automounter does this, for example).
   - user (person) driven
6. When time to close is reached
   I. Kill all processes that still access the directory
     (otherwise you cannot umount)
   II. Umount directory
   III. close LUKS container.
   
For this to be secure, you must make sure that the passphrase
does not stay in memory somewhere or, worse, goes into swap.
Proper memory locking (against swapping) and wiping is critical. 
This may mean you have to do a C/C++ implementation for this.
You should also use SELinux to lock it down further.

You may also need an independent security evaluation for daemon
or program as input for the auditor. I have not done one for 
PCI-DSS so far, so I do not know what the auditor may require 
here. 

This is however completely out of scope for cryptsetup, which 
does only protect a blob (file, partition) from access by root. 
Any filesystem within the LUKS container is not the business of 
cryptsetup. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare