From nobody Wed Aug 30 05:01:40 2023 X-Original-To: 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 4RbBwn0TvXz4rgq2 for ; Wed, 30 Aug 2023 05:02:01 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RbBwl59xCz4S1x for ; Wed, 30 Aug 2023 05:01:59 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=hW0usFje; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net Received: from webmail2.leidinger.net (roundcube.Leidinger.net [192.168.1.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id 92705244C for ; Wed, 30 Aug 2023 07:01:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1693371704; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xKbt1JVhLYg6jeaQ6UaPZU5/xYzwHKLhoffoGaV7X3U=; b=hW0usFjeE+LxYXhpdafeRrW3JgwoP+9630C6uPPur5uNIY33RMWKEzzKKQUIkYvMGVp66o vtTAUNiAIcMmI1TomatKMzKJIIhiNtKtvpqSSXbigzMg0oXqu8QMBWDnNRxZLFo5sc+za2 Fh2j8K/3j9EzuLhw/ZeiRFEG+NOI37bp9SPJofuRJYKh3wl+Umz1ODaj9C0gIRI4mJohjX dQqox9kagbnlIelwVFCQV4TDrqgVKsNxfU3rXRc1qQJFuknZ3oR78sgk6CGofczxEx2dRw y07UESTvc7Pip1n7GijjCYf4Hjn1JpCoaa7KHiH/jwPqZJzlef+9w8RIe1/kMg== 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 Date: Wed, 30 Aug 2023 07:01:40 +0200 From: Alexander Leidinger To: current@freebsd.org Subject: Re: Possible issue with linux xattr support? In-Reply-To: References: <20230829190258.uc67572553e4fq3v@mutt-hbsd> <20230829192516.jb2t65sp5rdlysss@mutt-hbsd> Message-ID: <0b080ade83ea277c91f97dc9ea990670@Leidinger.net> X-Sender: Alexander@Leidinger.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[current@freebsd.org]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4RbBwl59xCz4S1x Am 2023-08-29 21:31, schrieb Felix Palmen: > * Shawn Webb [20230829 15:25]: >> On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote: >> > * Kyle Evans [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? In https://reviews.freebsd.org/D40370 I provide infrastructure to automatically jail rc.d services. It will use the complete filesystem of the system, but uses all the other restrictions of jails. So the answer to your questions is "it depends". Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF