Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Aug 2024 21:07:14 +0200
From:      Steffen Nurpmeso <steffen@sdaoden.eu>
To:        freebsd-current@freebsd.org
Subject:   Re: a zfs thank you :)
Message-ID:  <20240819190714.mtYVCmQC@steffen%sdaoden.eu>
In-Reply-To: <d8c5a0b1-6162-4b7a-8bbe-4fea2dd4ee4c@rlwinm.de>
References:  <ZqpSHAPDcSlikhnC@int21h> <d8c5a0b1-6162-4b7a-8bbe-4fea2dd4ee4c@rlwinm.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

 --End of <d8c5a0b1-6162-4b7a-8bbe-4fea2dd4ee4c@rlwinm.de>

--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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240819190714.mtYVCmQC>