Date: Tue, 20 Aug 2024 09:08:33 +0300 From: Gleb Popov <arrowd@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: a zfs thank you :) Message-ID: <CALH631=RDwEcLCPTWNttYrq6F=_UeuSyMYFnGPBA3FOwryj%2B7g@mail.gmail.com> In-Reply-To: <20240819190714.mtYVCmQC@steffen%sdaoden.eu> References: <ZqpSHAPDcSlikhnC@int21h> <d8c5a0b1-6162-4b7a-8bbe-4fea2dd4ee4c@rlwinm.de> <20240819190714.mtYVCmQC@steffen%sdaoden.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 20, 2024 at 12:18=E2=80=AFAM 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 b=
e
> |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; th=
en
> had_z=3D
> for p in $(pgrep X); do
> uid=3D$(awk '/^Uid:/{print $2}' < /proc/$p/status)
> disp=3D$(sed -Ee 's/^.*DISPLAY=3D:([[:digit:]]+).*$/\1/=
' < /proc/$p/environ)
> [ -z "$disp" ] && disp=3D$(xargs -0 printf '%s\n' < /pr=
oc/$p/cmdline |
> awk '/^:[[:digit:]]+/{sub(":", ""); pri=
nt}')
> if [ -z "$disp" ]; then
> [ -n "$had_z" ] && continue
> had_z=3Dy
> disp=3D0
> elif [ $disp =3D 0 ]; then
> [ -n "$had_z" ] && continue
> had_z=3Dy
> fi
> act "DISPLAY=3D:$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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALH631=RDwEcLCPTWNttYrq6F=_UeuSyMYFnGPBA3FOwryj%2B7g>