From nobody Tue Aug 20 06:08:33 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WnzYr6b77z5SNDB for ; Tue, 20 Aug 2024 06:09:04 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WnzYq3qNQz4YTs for ; Tue, 20 Aug 2024 06:09:03 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=6yearold@gmail.com Received: by mail-vs1-f49.google.com with SMTP id ada2fe7eead31-4928fb6fdceso1560055137.3 for ; Mon, 19 Aug 2024 23:09:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724134142; x=1724738942; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Uj5g9GrVejlIubjFPkTpDore/bEk2J5ZH0tQHcfHdII=; b=k5mf4TPWKILwMgxl4JoMfe2tq0gg6UAI0AG34pxIT0nE3W7idT7yfYxbLpYFFXxZg0 XhlFarJBj4vy2FUhAFrPJ4dRBlVdygD8F8wxX/nJe6edb3z1LRx1kN8rXPTaIafFIJEu nr75XEoZSgoP6K83qZOsj05nRbdxeOtYTu6kpxuDo5AIIJEATzxKG4fFhRQdsjsm5lVQ rAh5a5wIoI7TX16f+TYRXSWcMdk9CUxM6+F0PUNH4IVIIJya+odXYuKxqxXWxaFk4Yqx ifVxTRgPQ1hm5d3ktGKcgpsePCAZD9Qcl3kraywCbKUJn3vFCVOVrO6twqcp7vwugCLN c1Qw== X-Gm-Message-State: AOJu0Yx77uEtxws/cloe0OoY52VvhsQGY4CA0sbmgvLXEHPXyWATcg6z nCy9+5WWG9CVy2C3TuUoLC1HTvZ9UpWZmqv0QzAqpx8wB2Z7aQxgaTJ4SA== X-Google-Smtp-Source: AGHT+IHYvnBLf3DRiUw2i5hge9bfxYH1H95BQP4F8ioiI+ilg6c+mYt/grgUI7n2BBgX24tLkyowJQ== X-Received: by 2002:a05:6102:2ad3:b0:492:a11f:a878 with SMTP id ada2fe7eead31-4977997d48emr15992924137.23.1724134142007; Mon, 19 Aug 2024 23:09:02 -0700 (PDT) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com. [209.85.221.176]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-842fb72f79bsm1400317241.12.2024.08.19.23.09.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Aug 2024 23:09:01 -0700 (PDT) Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4f6ac477ff4so2807118e0c.3 for ; Mon, 19 Aug 2024 23:09:01 -0700 (PDT) X-Received: by 2002:a05:6122:308e:b0:4f5:26c6:bf31 with SMTP id 71dfb90a1353d-4fc6ca09b55mr15266693e0c.12.1724134141311; Mon, 19 Aug 2024 23:09:01 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <20240819190714.mtYVCmQC@steffen%sdaoden.eu> In-Reply-To: <20240819190714.mtYVCmQC@steffen%sdaoden.eu> From: Gleb Popov Date: Tue, 20 Aug 2024 09:08:33 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: a zfs thank you :) To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.78 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.879]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.49:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.217.49:from,209.85.221.176:received] X-Rspamd-Queue-Id: 4WnzYq3qNQz4YTs On Tue, Aug 20, 2024 at 12:18=E2=80=AFAM Steffen Nurpmeso wrote: > > Jan Bramkamp wrote in > : > |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 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 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 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.