Date: Sun, 17 Dec 2023 21:19:47 +0100 (GMT+01:00) From: Alexander Burke <alex@alexburke.ca> To: Jan Behrens <jbe-mlist@magnetkern.de> Cc: questions@freebsd.org, freqlabs@freebsd.org Subject: Re: Tried to reach out to the FreeBSD security team Message-ID: <72c0cfb0-e13b-4a41-b1c9-65aa165c8b59@alexburke.ca> In-Reply-To: <20231217192928.c96da05aae056ff0b67a1df9@magnetkern.de> References: <20231217144640.9e5881decba4008d88971e85@magnetkern.de> <e5aeff29-0b0d-42ce-9332-70ab4d6f9643@alexburke.ca> <20231217192928.c96da05aae056ff0b67a1df9@magnetkern.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72c0cfb0-e13b-4a41-b1c9-65aa165c8b59>