Re: Possible issue with linux xattr support?

On Wed, Aug 30, 2023 at 06:55:14AM +0200, Alexander Leidinger wrote:
> Am 2023-08-29 21:02, schrieb Shawn Webb:
> 
> > 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
> 
> You enabled it by default. I would assume you had a thought about the
> implications... any memories about it?

I hope you don't mind if I quote a response I wrote to another person
on the list about the feature:

=== begin quote ===
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.

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.
=== end quote ===

The main reason for enabling it by default in HardenedBSD is so that
exploit mitigation toggles get applied to the application on `pkg
install` (or `make install` in ports.) We have patches to our ports
tree and have forked pkg to support the way we toggle exploit
mitigations.

So, I wanted to make sure that applications would behave the same in a
jailed environment and the host... to avoid a POLA violation.

> 
> What I'm after is:
>  - What can go wrong if we enable it by default?

I don't know if there's anything that could go wrong if FreeBSD was to
enable it by default. I think it might be more of a downstream issue:
those who have developed custom behavior backed by filesystem extended
attributes.

>  - Why would we like to disable it (or any ideas why it is disabled by
> default in FreeBSD)?

I wouldn't want to dictate what approach FreeBSD takes, if any. I
think the approach I've taken works well for HardenedBSD. But the
FreeBSD community might prefer an entirely different approach
altogether.

> 
> Depending in the answers we may even use a simpler patch and have it allowed
> in jails even without the possibility to configure it.

I also wonder if extended attributes could be taught to (optionally?)
scope extended attributes to each jail. That might be a topic worth
exploring some day for someone. Just a random thought. :-)

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc