Re: a zfs thank you :)

On Tue, Aug 20, 2024 at 12:18 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>
> Jan Bramkamp wrote in
>  <d8c5a0b1-6162-4b7a-8bbe-4fea2dd4ee4c@rlwinm.de>:
>  |On 31.07.24 17:02, void wrote:
>  |> I was pleasantly surprised when I installed a new [1] zfs-on-root
>  |> -current
>  |> to rpi4 that when adduser was invoked, I was given the option to
>  |> encrypt the homedir. This is a great feature for my context [2].
>  |>
>  |> It doesn't automount on boot but I think this is more of a feature
>  |> rather than a bug. One can have a different password to the GELI one used
>  |> to boot up the whole system.
>  |>
>  |> I have not tested yet whether one can have the user, once logged in,
>  |> mount
>  |> their homedir with doas(1). Right now, I mount the homedir like so:
>  |>
>  |> zfs load-key -a (prompts for password)
>  |> zfs mount -a
>  |>
>  |> as root.
>  |>
>  |> I could I guess make a doas line for the user for zfs load-key -r
>  |> zfsfile/system.
>  |> Can anyone suggest any better ideas please?
>
>  |There is the pam_zfs_key.so PAM session module that should do exactly
>  |what you're looking for if your users login with a password. It should
>  |similar to the pam_ssh.so module if you're already familiar with that
>  |one. Unless users provide the password there isn't much file system or
>  |disk encryption can do for you against hardware theft since the
>  |Raspberry Pi doesn't have any secure key storage nor would the kernel be
>  |able to know when it has been stolen and stop auto-loading the keys.
>
> To suggest a screen locker for "warm" security.
> Ie here this is (on Linux, in /root/bin/zzz.sh upon lid close etc)
>
>   if command -v X >/dev/null 2>&1 && command -v slock >/dev/null 2>&1; then
>           had_z=
>           for p in $(pgrep X); do
>                   uid=$(awk '/^Uid:/{print $2}' < /proc/$p/status)
>                   disp=$(sed -Ee 's/^.*DISPLAY=:([[:digit:]]+).*$/\1/' < /proc/$p/environ)
>                   [ -z "$disp" ] && disp=$(xargs -0 printf '%s\n' < /proc/$p/cmdline |
>                                   awk '/^:[[:digit:]]+/{sub(":", ""); print}')
>                   if [ -z "$disp" ]; then
>                           [ -n "$had_z" ] && continue
>                           had_z=y
>                           disp=0
>                   elif [ $disp = 0 ]; then
>                           [ -n "$had_z" ] && continue
>                           had_z=y
>                   fi
>                   act "DISPLAY=:$disp $SUPER -u $uid slock </dev/null >/dev/null 2>&1 &"
>           done
>   fi
>
> Unfortunately there is no other easy way i know to lock all
> X sessions otherwise.
>
> This is the problem i have with "encrypted home directories" per
> se, i do not use that, but have several encfs directories, like,
> say, ~/.sec.arena, which i mount via fuse as a normal user, and
> $HOME is nothing but a symlink farm like
>   .xinitrc -> sec.arena/configs.git/home/.xinitrc
> so before i mount this that is all hollow.
> The zzz.sh script also does (simplified)
>
>   if command -v encfs >/dev/null 2>&1; then
>           grep encfs /proc/mounts | cut -d ' ' -f 2 | {
>                   while read line; do
>                           act "{ sync $line/.; umount $line; } </dev/null >/dev/null 2>&1 &"
>                   done
>           }
>   fi
>
> so that all these are unmounted upon LID close etc.  (Unless some
> process uses any directory within as CWD/pwd(1), then not.  Force
> unmounting does not work.)
>
> Ie that is all pretty uncomfortable (it is even more complicated
> in practice), but like this data i care of a bit more is not
> mounted when the LID is opened.  (And data i really need to take
> care off is never mounted all the time.  And "of course" the hard
> disk partition as such is also "cold" encrypted.)
>
> Ie, i just feel better that way.  If you steal the laptop you can
> switch to another console, and, i mean, here is no automounter for
> USB sticks or what, no code runs then (i hope), but i do not know,
> but anyway, if all that time an encrypted home directory of myself
> would be unencrypted, that feels a bit odd.
>
> Anyhow.  To remark that PAM sessions can easily be bypassed by any
> shell script (script </dev/null >/dev/null 2>&1 &), and, i looked
> at the ZFS PAM module in particular a few years ago, it did not
> do anything REAPER-alike by then.  That is "script" may be running
> when the ZFS user logs out, and the PAM module will then likely
> unmount the ZFS home directory.
> One should at least hear about this situation once.
>
> It would be cool if the PAM implementations i know (Open and
> Linux) would consider adding a dedicated session reaper, with all
> session related modules stopping doing lots of dances, but instead
> relying on some generic PAM library support mechanism.
> Sounds a bit like a sophisticated and relevant Google Summer of
> Code or something project.

It feels like you're reimplementing ConsoleKit. I'm not sure if it can
react to lid closing out of the box, but it manages sessions and
locks/unlocks them depending on circumstances.