Date: Wed, 30 Aug 2023 16:23:34 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Dmitry Chagin <dchagin@freebsd.org>, current@freebsd.org Subject: Re: Possible issue with linux xattr support? Message-ID: <20230830202334.vvois6ijpf3h54zh@mutt-hbsd> In-Reply-To: <8b49a01cfc32aa0a4bb9d0e9aebbe7be@Leidinger.net> References: <pzu4sxp4wvfpn3mzzo2giw3otvg6z5ewia6rr2tdgpkjurfcfe@aat2k6ywm6jm> <ZOuoH6Llw8PKgMJQ@heemeyer.club> <wuwg3egv3rilgfaa5hor47v3yjwzvxlt5krj4la4wvugcnhkg3@vgrtgfr7rc6i> <EA27BAE1-C687-47F9-BB6D-B72A85A5CA8D@cschubert.com> <elx6cvceobzgw66fskkfhhicsdpsur5xaktluu5tk7m7p4qwno@s7qmm4kyuvag> <ZOzD9noXVrslppot@heemeyer.club> <smfbmu35sxh2f3hu5nrpdwb355trlucd2bbp4ag5ke7v3zf3il@s3ua2x4i3nzj> <ZO4En1UJqcr4GGiw@heemeyer.club> <20230829190258.uc67572553e4fq3v@mutt-hbsd> <8b49a01cfc32aa0a4bb9d0e9aebbe7be@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--t3q6xn7etqdmgxyz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 30, 2023 at 06:55:14AM +0200, Alexander Leidinger wrote: > Am 2023-08-29 21:02, schrieb Shawn Webb: >=20 > > 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: > >=20 > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b4= 5e44a6105664c7068a92d0a61da2a3 >=20 > 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: =3D=3D=3D begin quote =3D=3D=3D 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. =3D=3D=3D end quote =3D=3D=3D 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. >=20 > 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. >=20 > Depending in the answers we may even use a simpler patch and have it allo= wed > 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, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --t3q6xn7etqdmgxyz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmTvpUAACgkQ/y5nonf4 4frJsA/9HUv37Ws/kNyDJPCclIrBp+roiKSt4t/z5W8JR9hPWMKOgDIjU674ZayD vnOyhvIgFX3aP9sp0VNFCF5JLcMXBln23FVkxszdNxtBhD8qIISboJz+pgVwNP8k ZYL6uVC0KikZz+SzSJiFhmU1apenGN5Df7SUF8GqOvmgOvpd10bozBNjzkqCP2Wi DMXJ5M3WDC5d5XTzjkb4PG9aplL7FC4Xs5plMENjbhwIZK8Nhnyx13HXfiRvgTxG /4faQ8I9XfZjDKmG3cvpjtSUQx/h6NCgs3gedkdQ74bnFqS4oZFwB4Pr75cRTQ+U nf6HHimXuhmtU75vztOfkQDwSh28HLp7AgJt2VrMGHSYMr2+KmFoLWcQKTKWd99M X/tOraqR9Tz3ZtwUrOVViv7YH9cVeXlO89TUduoOWnoHBWKipu+lmUyFp6+POmoa DQ8RcOR7ydPbo5eNhnl/RdZgQbU7yMVe3MlYnPw0gLp+PVs0Ow1OemfNFtoHdOVn SD7bip3Hs6YVVXyRxnnUjfUzSyfeUuNjnYoGhWeRCJRoTmV7WFuZWM+6L3AC7pkP czULanGDoyneDRZXqOvK0ZSrWDKqAhpInUBha0ti3VTjQ1i8SHfTWJqFASOafTdu pQELJqgKzJYmnvqWtLvm2VrwChAgkVGvTR4c1JauQyGQTyfLAe8= =bOlk -----END PGP SIGNATURE----- --t3q6xn7etqdmgxyz--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230830202334.vvois6ijpf3h54zh>