Mounting encrypted ZFS datasets/GELI for users?

[Eric McCorkle]

On 10/5/20 11:50 AM, Alan Somers wrote:
> On Mon, Oct 5, 2020 at 9:40 AM Eric McCorkle <eric at metricspace.net
> <mailto:eric at metricspace.net>> wrote:
> 
>     On 10/5/20 11:12 AM, Alan Somers wrote:
> 
>     > First of all, what kind of thread are you concerned with?  Disk
>     > encryption does not protect against an attacker with access to a live
>     > machine; it only protects against an attacker with access to an off
>     > machine, or to the bare HDDs.  Per-user encryption would presumably
>     > protect one user from another user who has physical access to the off
>     > server.  Is that what you're worried about?  If not, then you
>     shouldn't
>     > bother with per-user encryption.  Just encrypt all of /home or all of
>     > the pool with a single key.
>     >
>     > -Alan
> 
>     I am evaluating options for domains where use of per-user encryption is
>     mandated, often as a means of protecting against insider threats.
> 
> 
> But if the victim user and the aggressor user are logged in at the same
> time, then both users' home directories will be decrypted, and unix
> permissions will be the only thing protecting the victim, right?  That
> situation doesn't sound any better than no encryption at all.  And
> insiders who have offline access to the HDDs would be thwarted by global
> encryption just as much as per-user encryption.  I'm not denying that
> you may be under some legal mandate for per-user encryption; I just
> don't understand the motivation.

Per-user encryption is not perfect, but that's not the goal of
requirements like this.  First of all, this can be used to protect
secure workstations, where it's reasonable to expect only one person to
be logged in at a time.

Beyond that, the goal is to shrink the window of possible attacks and to
aid detection.  If the Adversary has to be active while a particular
user is logged in, then they have a much smaller window of attack.
Moreover, this helps with forensics, as you can look at what else was
going on in the system in the much shorter window while a compromised
user was active.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20201005/de42edc5/attachment.sig>