Date: Tue, 29 Aug 2023 21:31:46 +0200 From: Felix Palmen <zirias@freebsd.org> To: current@freebsd.org Subject: Re: Possible issue with linux xattr support? Message-ID: <tkut7qfcobxty7jrcxqlbzgl75q7hclugqu4g332c2m6lv7s6w@mlzazyhlhzff> In-Reply-To: <20230829192516.jb2t65sp5rdlysss@mutt-hbsd> References: <wuwg3egv3rilgfaa5hor47v3yjwzvxlt5krj4la4wvugcnhkg3@vgrtgfr7rc6i> <EA27BAE1-C687-47F9-BB6D-B72A85A5CA8D@cschubert.com> <elx6cvceobzgw66fskkfhhicsdpsur5xaktluu5tk7m7p4qwno@s7qmm4kyuvag> <ZOzD9noXVrslppot@heemeyer.club> <smfbmu35sxh2f3hu5nrpdwb355trlucd2bbp4ag5ke7v3zf3il@s3ua2x4i3nzj> <ZO4En1UJqcr4GGiw@heemeyer.club> <20230829190258.uc67572553e4fq3v@mutt-hbsd> <af11b09e-7b93-7c17-a8b8-6cea86291176@FreeBSD.org> <izo5sjuirgprs6dwcski2xtqqa3fqnjh47jpwrb5v4q4sqmark@3vybbvcdap4z> <20230829192516.jb2t65sp5rdlysss@mutt-hbsd>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] * Shawn Webb <shawn.webb@hardenedbsd.org> [20230829 15:25]: > On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote: > > * Kyle Evans <kevans@FreeBSD.org> [20230829 14:07]: > > > On 8/29/23 14:02, Shawn Webb wrote: > > > > Back in 2019, I had a similar issue: I needed access to be able to > > > > read/write to the system extended attribute namespace from within a > > > > jailed context. I wrote a rather simple patch that provides that > > > > support on a per-jail basis: > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3 > > > > > > > > Hopefully that's useful to someone. > > > > > > > > Thanks, > > > > > > > > > > FWIW (which likely isn't much), I like this approach much better; it makes > > > more sense to me that it's a feature controlled by the creator of the jail > > > and not one allowed just by using a compat ABI within a jail. > > > > Well, a typical GNU userland won't work in a jail without this, that's > > what I know now. But I'm certainly with you, it doesn't feel logical > > that a Linux binary can do something in a jail a FreeBSD binary can't. > > > > So, indeed, making it a jail option sounds better. > > > > Unless, bringing back a question raised earlier in this thread: What's > > the reason to restrict this in a jailed context in the first place? IOW, > > could it just be allowed unconditionally? > > In HardenedBSD's case, since we use filesystem extended attributes to > toggle exploit mitigations on a per-application basis, there's now a > conceptual security boundary between the host and the jail. > > Should the jail and the host share resources, like executables, a > jailed process could toggle an exploit mitigation, and the toggle > would bubble up to the host. So the next time the host executed > /shared/app/executable/here, the security posture of the host would be > affected. Isn't the sane approach here *not* to share any executables with a jail other than via a read-only nullfs mount? > FreeBSD uses ELF header tagging, not filesystem extended attributes, > to toggle exploit mitigations. So my description above is moot for > FreeBSD users. I'm just hoping to share a unique perspective. Thanks! -- Felix Palmen <zirias@FreeBSD.org> {private} felix@palmen-it.de -- ports committer -- {web} http://palmen-it.de {pgp public key} http://palmen-it.de/pub.txt {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iNUEABYKAH0WIQRpNhPVW79IN7ISOsxUreAGmHnyMQUCZO5Hol8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0Njkz NjEzRDU1QkJGNDgzN0IyMTIzQUNDNTRBREUwMDY5ODc5RjIzMQAKCRBUreAGmHny MdpPAP4ixAAvJRAaEpI1NeYfDTs6Ezw5zPxaa6aStU3nwxzrpAEAvl1L4epzz8nQ 7IRwY4uJBWVYWcako8p2U4pmE4Iiqwk= =tkNE -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?tkut7qfcobxty7jrcxqlbzgl75q7hclugqu4g332c2m6lv7s6w>
