Date: Wed, 2 Apr 2025 14:26:03 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: Dennis Clarke <dclarke@blastwave.org>, freebsd-current@freebsd.org Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: <CAM5tNy6Pw2tmjx9P-0-PFupK=j=Vp1kC2r8KwFP%2B2VZYUcquWg@mail.gmail.com> In-Reply-To: <CAM5tNy7JL1WnkuMXfjGghnSCjw89wz99440sJG8PBeSXkgvqLQ@mail.gmail.com> References: <CAM5tNy6wkfPRUpkyHB3h6=fhJHf-eFSWWNdeHV5VLA_xG7pGDA@mail.gmail.com> <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> <CAM5tNy6UEcoNVTaZxXfje4UY%2BNuBcK-O3fBCNcf%2B-K4rBp7sVw@mail.gmail.com> <sntzdnewyxq2ncoemz5kq7ryirvhv2n2rrxkax265vsbjb2smm@ez7eyxigawpu> <CAM5tNy6DTULRg86ainHQYRP0pic60epi4yVDKJ_U3waf3N%2Be2Q@mail.gmail.com> <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> <CAM5tNy5Mc8sdcU5CQgTfSQRwxbe_Z7CxJwG3x_rkPj5Bj6nH3A@mail.gmail.com> <yjms7fqzbsxsqhu5hpbsosquqld6f2drifilfqn6d5qf2nsyer@pi72scnvai56> <CAM5tNy7WPffP2u_gKJ1Q7f74d8bivh2d7TkjO5n4XVsJQc0j_g@mail.gmail.com> <CAM5tNy7JL1WnkuMXfjGghnSCjw89wz99440sJG8PBeSXkgvqLQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tue, Apr 1, 2025 at 4:08 PM Rick Macklem <rick.macklem@gmail.com> wrote: > > On Sat, Mar 29, 2025 at 1:22 PM Rick Macklem <rick.macklem@gmail.com> wrote: > > > > On Sat, Mar 29, 2025 at 1:09 PM Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > > > > > > On Sat, Mar 29, 2025 at 01:04:08PM -0700, Rick Macklem wrote: > > > > On Sat, Mar 29, 2025 at 12:50 PM Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > > > > > > > > > > On Sat, Mar 29, 2025 at 12:39:02PM -0700, Rick Macklem wrote: > > > > > > > I had added filesystem extended attribute support to libarchive, which > > > > > > > is what FreeBSD's tar(1) is based off of. I upstreamed that, so that's > > > > > > > taken care of. FreeBSD's tar(1) has supported extended attributes > > > > > > > since 2020 (see libarchive PR 1409: > > > > > > > https://github.com/libarchive/libarchive/pull/1409) > > > > > > Ok, thanks for the info. If this stuff goes into FreeBSD, it probably needs > > > > > > to be tweaked to use the different syscall API so that it can handle large > > > > > > attributes and maybe the attribute's mode. (someday, maybe?) > > > > > > > > > > I believe libarchive has been updated in FreeBSD since October 2020, > > > > > so the vendored libarchive in FreeBSD should already support it. But, > > > > > yeah, if FreeBSD makes changes to how extended attributes work, I or > > > > > someone else would need to update libarchive to account for that. > > > > > > > > > > Since HardenedBSD follows FreeBSD closely (we sync every six hours), I > > > > > would probably volunteer to update the libarchive code. > > > > > > > > > > > > Just one data point here: HardenedBSD uses filesystem extended > > > > > > > attributes to toggle certain exploit mitigations on a per-application > > > > > > > basis. That's why we added support to libarchive: so we can ship > > > > > > > certain packages with exploit mitigations pre-toggled. > > > > > > Just curious. Does it use "system" or "user" attribute space? > > > > > > > > > > We use the system namespace, though the userland tool (hbsdcontrol) > > > > > was recently taught about the user namespace. The kernel side only > > > > > supports system namespace. So the user namespace support in > > > > > hbsdcontrol is somewhat meaningless. I do plan to eventually get to > > > > > the kernel side, but my TODO list continues growing. :-) > > > > Ok, this wouldn't be affected by the patches I've been doing, since they > > > > handle user space only. (system space will still work, but only via the > > > > extattr_XXX() APIs. > > > > > > Cool. I have another project that uses user namespaces: > > > https://git.hardenedbsd.org/shawn.webb/altfs > > > > > > AltFS is a fusefs driver that stores file payload in filesystem > > > extended attributes, using the user namespace. It only partially works > > > and again is bitten by more important items on my TODO list. It mainly > > > serves as a proof-of-concept for a weird data exfiltration technique. > > > Not at all meant for actual production use. > > > > > > Do you already have a patch for review in Phabric? I might want to add > > > myself to it so I can more easily keep informed. > > Not yet. I am still cleaning things up and testing. > I have put the VFS/syscall changes up in phabricator under D49583. > I listed a few reviewers, but anyone is welcome to review/comment on it. I have just committed this to main as 2ec2ba7e232d. However, there is a very slight difference (definition of some flags) from the test patches. I will update the test patches as soon as kib@ commits his struct stat patch in D49651. This shouldn't take long. Thanks go to kib@ for reviewing this. After that there will two patches to be applied on top of a current main kernel src. https://people.freebsd.org/~rmacklem/zfs-xattr.patch https://people.freebsd.org/~rmacklem/nfs-xattr.patch I will put the ZFS patch up on phabricator soon, as a first step towards getting it pulled into openzfs. rick > > rick > > > Also, there ahs not been much response related to the question "should this > > go in FreeBSD?". Dennis doesn't sounds like a "no" and the two posters on > > freebsd-hackers@ I assume are a"yes", but I haven't heard from anyone else. > > (Good technical comments, but not related to "should it be in FreeBSD?".) > > > > rick > > > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder / Security Engineer > > > HardenedBSD > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.aschelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy6Pw2tmjx9P-0-PFupK=j=Vp1kC2r8KwFP%2B2VZYUcquWg>