From nobody Sun Dec 17 18:29:28 2023 X-Original-To: questions@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 4StWhC3S1yz5418S for ; Sun, 17 Dec 2023 18:29:31 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Received: from gaoxing.magnetkern.de (gaoxing.magnetkern.de [167.235.225.147]) by mx1.freebsd.org (Postfix) with ESMTP id 4StWhB2jPvz4bCB for ; Sun, 17 Dec 2023 18:29:30 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jbe-mlist@magnetkern.de designates 167.235.225.147 as permitted sender) smtp.mailfrom=jbe-mlist@magnetkern.de; dmarc=none Received: from titanium.fritz.box (p200300c26f3d5c00264bfefffe54b09c.dip0.t-ipconnect.de [IPv6:2003:c2:6f3d:5c00:264b:feff:fe54:b09c]) by gaoxing.magnetkern.de (Postfix) with ESMTPSA id 67FF13AC5E for ; Sun, 17 Dec 2023 19:29:29 +0100 (CET) Date: Sun, 17 Dec 2023 19:29:28 +0100 From: Jan Behrens To: questions@freebsd.org Subject: Re: Tried to reach out to the FreeBSD security team Message-Id: <20231217192928.c96da05aae056ff0b67a1df9@magnetkern.de> In-Reply-To: References: <20231217144640.9e5881decba4008d88971e85@magnetkern.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; MLMMJ_DEST(0.00)[questions@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:167.235.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[magnetkern.de]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4StWhB2jPvz4bCB X-Spamd-Bar: -- Hi Alex, First of all, I would like to say that I didn't mean to discuss on here whether this issue is security relevant or not. I have already discussed that on the forum here: https://forums.freebsd.org/threads/91178/ And I also provided a link in the Bugzilla there: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265625#c5 Instead, came to this list to understand how to contact the security team or why I haven't received any response (maybe it's a technical issue or I reached out to a wrong address?) If the security team considers this to be non-security-relevant, I would ideally like to hear it from them. At the very least, I'd like to make sure they did receive my e-mail and looked through my considerations of why I believe this is a security issue. As of yet, I didn't even get a response like, "We looked at this issue and think you're wrong." If that would be the case, I understand, but so far I've gotten nothing, like my e-mails were just dropped. That said, see my inline response below: On Sun, 17 Dec 2023 18:01:01 +0100 (GMT+01:00) Alexander Burke wrote: > Hi Jan, > > I had a look at the issue to which you are referring. > > My understanding of your concern is that after a snapshot is taken, a user has their access to some portion of the data revoked, but would be able to work around this new restriction via `.zfs/snapshots` by virtue of the fact that all snapshots are faithful read-only reproductions of state at the time each snapshot was created and they thus do not inherit changes made to permissions later on. My concern is that a snapshot is world-readable by default *and* force-mounted *and* immutable. It's the combination of these three things. In turn, file mode changes are effectively not reflected in real time, which can be a problem, for example, when group memberships change. > > If I have misunderstood, please let me know (and probably disregard the rest of this reply). One misunderstanding is (probably) that it also affects groups, not just users. So users which have never had access to the original data might gain access to it (e.g. when they are added to a group later). This has also been brought up by me on the forum (link above). > > Changing a snapshot is impossible by design, and This Is A Feature Not A Bug; if you want a changeable snapshot, then a clone is what you're after. I don't want to make snapshots changeable. I understand that they are read-only, and I don't propose any feature like that (as for that, we have zfs clone). The issue is that snapshots (not their clones) are force-mounted and world-readable. If you look through the forum thread, you'll also see some comments on zfs-clone and zfs-promote in this matter. None of these fix the race condition. > > It would seem as though the `.zfs/snapshots` feature is not well-known (it does not appear even when `ls -lA` is invoked by root in the root directory of a pool, for example) and should probably be better publicized so each sysadmin can make a decision as to whether or not they should restrict access to that "directory" to the root user (or wheel or whatnot). > > That said, perhaps there should be a discussion regarding whether or not `.zfs/snapshots` should be simply disabled by default. In my opinion, at least world-readability should be disabled by default. Unfortunately this issue is lingering for years, despite its (arguable) security impact. > > Cheers, > Alex Thanks for your response and kind regards, Jan Behrens > ---------------------------------------- > > Dec 17, 2023 14:46:59 Jan Behrens : > > > Hi all, > > > > I tried to contact the FreeBSD security team and/or officer to bring > > their attention to issue #265625, which I believe is security relevant > > and which doesn't get fixed. > > > > None of my e-mails to secteam@FreeBSD.org or > > security-officer@FreeBSD.org were answered. After some time, I tried to > > write an e-mail to freebsd-security@freebsg.org. While that e-mail was > > accepted by mx1.freebsd.org, I never got any response and my e-mail > > didn't show up on the list. What is going on? > > > > My e-mails were sent on 2023-11-24 to secteam@FreeBSD.org, on > > 2023-12-04 to security-officer@FreeBSD.org, and on 2023-12-11 to > > freebsd-security@freebsd.org. > > > > Kind regards, > > Jan Behrens >