From nobody Wed Apr 2 21:26:03 2025 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 4ZSdGK5fChz5rtnv for ; Wed, 02 Apr 2025 21:26:17 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZSdGK0RZmz3kVx for ; Wed, 02 Apr 2025 21:26:17 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=DH1AGXiH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5e5e63162a0so367569a12.3 for ; Wed, 02 Apr 2025 14:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743629174; x=1744233974; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AsgpuCeamfuItSE2ZQUt1xIIqI9RqAD/ZBJYfDWlNSI=; b=DH1AGXiH3GYUWq2MmiNTRUQyk61NcU/u3sc9YDeYxow3K+MWAuWbfwJUrufXSefAst qj1SkVA2e2QpXk992U9DujM1qYnXAJvKe3qyNwGpGXrgpBYYB//LBxW5Q+QUDMhYyH1J JN69LMajZaExRbrnLsrkXsar2lkO+4VeVJB/tHYkrKVj+MQcVNRX4AtkKuoTsSHYeZ+i WRFbQQhpHA6/hPUKRKtvbdLtjltC+OnmnigSxL3HH4a3jZqacRxygXuicKq+Hn3eN1L6 rYVdtBUNqmzF5zjckpI23T9RmgVJM1fOktp9vBL0TrfQEtGmAV/0O0vVAEod5Hq5iS1d gqjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743629174; x=1744233974; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AsgpuCeamfuItSE2ZQUt1xIIqI9RqAD/ZBJYfDWlNSI=; b=hQnOf/aM32ExiLXeKWS18qTeU5/W/aTd2FgDSQeXiz7BZnEFTonLvEz2uKyu3w1wGE VVFFxHKW8YIDdSWOFQzDUfog33cs89lP8bik9AdXwzEqdtVnOu75Ea7zJ1VxYMOHza3M kKBMYdf4AFtTvOtWW3CqWx+cWOj9mXxyioPw5OKKxHpDTXMhkGQw53UI/3186RDgw1PV 9ksFgYuavZEHwy6vKKxj1mHlNhB7NyP2TEeGNq0dm5s0yctmEtC7492fZFe+ih/COsNK Gd1V62gZE6UatGUQkcEPuISB0gGrTNdUFc/FxMGH5aLGgh4X2j/nqFS6nZ0+RVvTRbR7 GNWQ== X-Forwarded-Encrypted: i=1; AJvYcCVBR4ZiWBrOVlBVidO6ggPoHKlzAg44iKX+Caru8y5c+r+BKMSYP8ByJhcaI07qWytO/qtd8voOTLnMGW0ihIM=@freebsd.org X-Gm-Message-State: AOJu0YysBfU7Jjd06XAk2Hp0JFzLJD27doROEMQuIfySOU9MAhpHmhNb BD90PPqDQ5jrjq+/ZVYOxrWNr7jzzmOdLns9CTPIy+9fqeGZQxMOUtzpRL3BOaWxDOKehQQ/uue Oa1SaA4HBrb56SNyRZQQ8EdmkoHcNhT4= X-Gm-Gg: ASbGncvrmO9iJnEirvsj/J9EMMXO+uAvESzlenA7qgD/09mlg3ybcDaUbM47oel3Myt UE7x/q5f3igJ2y6h5Vh/hZCstOGzPoGiRYUHsGiavugSB1h64xMWfRTzza5/NGrfsBLQc7P6M3I 18Hia0KxisuplTnz7D+2+D+RJCRT2/9fbIqjEc/nLCN+5e8WFVkTlOgQZm0g== X-Google-Smtp-Source: AGHT+IHZdSQko1LzzFJ/2HW3cgMpTAuUI9ctTupnJ2DxJHiSjV8wNuop8l+XCGaovdJJDJyHCuXgjZmmhCcTkV7lMu8= X-Received: by 2002:a05:6402:d09:b0:5ed:5554:7c3b with SMTP id 4fb4d7f45d1cf-5f02b38ab59mr7333442a12.32.1743629173746; Wed, 02 Apr 2025 14:26:13 -0700 (PDT) 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 References: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> In-Reply-To: From: Rick Macklem Date: Wed, 2 Apr 2025 14:26:03 -0700 X-Gm-Features: AQ5f1JpuqNjRaIRdRSOMHr3EEs3Tu2eStntMBKqT0M9ov3rCAXVFzMSpZ5T58zA Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Shawn Webb Cc: Dennis Clarke , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZSdGK0RZmz3kVx X-Spamd-Bar: --- On Tue, Apr 1, 2025 at 4:08=E2=80=AFPM Rick Macklem wrote: > > On Sat, Mar 29, 2025 at 1:22=E2=80=AFPM Rick Macklem wrote: > > > > On Sat, Mar 29, 2025 at 1:09=E2=80=AFPM Shawn Webb wrote: > > > > > > On Sat, Mar 29, 2025 at 01:04:08PM -0700, Rick Macklem wrote: > > > > On Sat, Mar 29, 2025 at 12:50=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > On Sat, Mar 29, 2025 at 12:39:02PM -0700, Rick Macklem wrote: > > > > > > > I had added filesystem extended attribute support to libarchi= ve, 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 attrib= utes > > > > > > > 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 pr= obably needs > > > > > > to be tweaked to use the different syscall API so that it can h= andle large > > > > > > attributes and maybe the attribute's mode. (someday, maybe?) > > > > > > > > > > I believe libarchive has been updated in FreeBSD since October 20= 20, > > > > > 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 hour= s), I > > > > > would probably volunteer to update the libarchive code. > > > > > > > > > > > > Just one data point here: HardenedBSD uses filesystem extende= d > > > > > > > attributes to toggle certain exploit mitigations on a per-app= lication > > > > > > > basis. That's why we added support to libarchive: so we can s= hip > > > > > > > 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 (hbsdcontro= l) > > > > > was recently taught about the user namespace. The kernel side onl= y > > > > > 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 work= s > > > and again is bitten by more important items on my TODO list. It mainl= y > > > 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 ad= d > > > 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 ver= y slight difference (definition of some flags) from the test patches. I will update the test patches as soon as kib@ commits his struct stat patc= h 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 ge= tting 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 e= lse. > > (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_We= bb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc