Re: Possible issue with linux xattr support?

* 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