From nobody Mon Sep 6 17:16:04 2021 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 E4EF417AA2B4; Mon, 6 Sep 2021 17:15:49 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 4H3FR91smjz3Qfg; Mon, 6 Sep 2021 17:15:49 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id BB3F4132F; Mon, 6 Sep 2021 17:15:48 +0000 (UTC) Subject: Re: PAM module for loading ZFS keys on login To: freebsd-current@freebsd.org, Greg , FreeBSD Hackers References: <67F44CFE-2496-4B13-8583-8A80D9ED3A4A@unrelenting.technology> <20210906140137.iGt2J%steffen@sdaoden.eu> From: Eric McCorkle Message-ID: Date: Mon, 6 Sep 2021 13:16:04 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 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 In-Reply-To: <20210906140137.iGt2J%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4H3FR91smjz3Qfg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 2001:470:1f11:617::107) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-0.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[eric]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[metricspace.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 > : > |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) >