Re: Tried to reach out to the FreeBSD security team

Hi Jan,

Given that freqlabs@ is responsible for the sysutils/openzfs port, I've taken the liberty of CCing them; perhaps they can point us in the right direction.

Cheers,
Alex
----------------------------------------

Dec 17, 2023 19:29:48 Jan Behrens <jbe-mlist@magnetkern.de>:

> 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 <alex@alexburke.ca> 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 <jbe-mlist@magnetkern.de>:
>> 
>>> 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
>>