Re: PAM module for loading ZFS keys on login

Honestly, I think the best approach to this is the autounmountd unload
keys thing.  There's just too many ways the sessions thing can go wrong.
 The autounmountd solution gets the job done, and it tolerates possible
failures better than anything else I can think of, barring some kind of
major kernel-side awareness of sessions.  There's potentially a gap
between the user logging out and the keys being unloaded, but that's not
much of a problem when you consider the most likely use case.

The thing to keep in mind with the primary use case I've suggested for
the ZFS key load/unload stuff is that it's not so much about preventing
the Adversary from gaining access to data is it is about constraining
when they need to be active to pull off an exfiltration.  This is the
real reason you see it on secure systems: it makes the Adversary's job a
lot harder, while at the same time making the jobs of defensive ops and
DFIR folks a whole lot easier.

Say I've got sensitive files in my home directory.  On a base system,
the Adversary just has to circumvent OS file protections, but they can
do this at any time.  This means your DFIR folks have to dig through a
huge amount of history.  If I have to be logged in for the keys to be
present, then the Adversary has to have some kind of monitoring to
detect when I am, and then has a constrained window in which to pull off
the attack.  Both of these increase the likelihood of detection, while
also constraining the window of time the DFIR folks have to examine.

This isn't changed much by having the system wait some small time
interval after I'm logged out to unmount my home directory and unload my
keys.  (If anything, it introduces another potential vector for
detection: the unmounting/unloading will fail if someone is still
accessing my data after I'm gone.)



On 9/6/21 10:01 AM, Steffen Nurpmeso wrote:
> Eric McCorkle wrote in
>  <b265fa82-53f2-59f4-65c2-b07a9412bf83@metricspace.net>:
>  |Interesting, I wasn't aware of the upstream module.  I'd say that's
> 
> It's existence was the reason i have readded (now optional, and
> a tad different) session support for my pam_xdg PAM module,
> because i was thinking that, if such a many-eyes-seen thing of
> a software project that claims to be and aims at being enterprise,
> ships such a terrible and terribly broken thing, then i can also
> offer session tracking.  But my manual at least states
> 
>   CAVEATS
>        On Unix systems any “daemonized” program or script is reparented to the
>        program running with PID 1, most likely leaving the PAM user session
>        without PAM recognizing this.  Yet careless such code may hold or expect
>        availability of resources of the session it just left, truly performing
>        cleanup when sessions end seems thus unwise.  Since so many PAM modules
>        do support session tracking and cleanup pam_xdg.so readded optional sup‐
>        port for this.
> 
> But the real solution would be PAM session tracking in-kernel,
> somehow, wouldn't it?
> Also, on FreeBSD and OpenPAM many separate files exist in
> /etc/pam.d for things which might open a session, whereas linuxpam
> at least has /etc/pam.d/common-session; it has many common- things
> in fact, and in /etc/pam.d/sshd i for example see
> 
>   #
>   # /etc/pam.d/sshd - openssh service module configuration
>   #
> 
>   auth        include common-auth
> 
>   account     include common-account
> 
>   password    include common-password
> 
>   session     include common-session
> 
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>