From nobody Wed Jun 28 21:59:16 2023 X-Original-To: freebsd-jail@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 4QrwV50NMdz4kMGJ for ; Wed, 28 Jun 2023 21:59:41 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QrwV473HZz49ch; Wed, 28 Jun 2023 21:59:40 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1687989581; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=g1a+mZtwnOI6Vyf80RiwPTKI0vpLbdbpWX06WaBzutU=; b=q2SnSOLaUYJQwYyrybAmgSfFvZ39fTv9PHV9wzLFjFNAnOXUonwO5Ekk7p4lQhCmmD94Iw zTGkER7g2zNp/37nqJO2Z/bYXyNICOY/cukhte7uKn3CXD+pE7mEd/6pZuhHoO2GkoEHlo jPEFlIRYzwX1FuhTSrZdqvoDswd6P1nvEKoYV5XfsIWtHroXcxtmJugses8ssqZVxeHPhh bPD5LvHWtoOFywzjuYjkIcP+FenPwxewLn3uqlM8O0YDU0M6BvNanQjMOF3bpQNFWV8AET h2D+31lwvXyVyB5h8FEoGmd/FO4qjZMVhyYfLXCrDrjO9xDJdLt/nMPdSnvUYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1687989581; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=g1a+mZtwnOI6Vyf80RiwPTKI0vpLbdbpWX06WaBzutU=; b=uQfvtiFICjJBsFHBojUYJ8fUGGAf1/PI/ABZgSmdGyxoX5ErFTdOnh/HbNcftGZg8DzVBz ADStNv0cqXe/R5baQKujYg3ejg84Xj1xx9/qfr2gXH26HaYy+9pNTAJQ+AE4aaJ3NtNKZt NhJIPVEFVgvhu1yed7DfvKPQCzSgrA6HoMQnO9XmpvFFuqOzZgyo3dsWVZrBxuAuyjCvw0 pvmI8PhHpin+d3pm5CIF2GzC8aSQ5tK1A6ozC24uQHuijr4DascfSor81DyJTj1TRqIzxX 1zEmoHQtd/6IOrbkhuaWSO5twAvBhWUeF5/up18KJ2QUQ5hRvoCoA7FcJCZIdA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1687989581; a=rsa-sha256; cv=none; b=b6LVuaoZNormgD5IeOfvbcFCzPN85UB9nqsar2lvH8WxZ7U7rgkA32UZV7a0XRUKtTOl9p /LeqszcnU03AfQdi8iAP52yMOdtWggAzfeN6yf30p1+KSTI9nO2rzgX0KVThlZI/sZj3oi KKU/W8ItF/2cB90mv+HA66R+uV0M+Wogpq/6IRzwPlA0aIfG8L9gBdgbkskm9s/9g85bZO 8OQgqww+GtYl4weWkLEw+d4tyJo0c1J++VJi8tZxXL/b/y6T2Wl4RDZXtMZF+VxtVsluNk Urz0XnopdVloXYwsoALsTbtQ8Vn3NlvEhoNFhI6JrtvUcoz0FTCV/z7RCuPERg== Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (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 did not present a certificate) (Authenticated sender: melifaro/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QrwV45w2pzlhF; Wed, 28 Jun 2023 21:59:40 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 2BFA927C005A; Wed, 28 Jun 2023 17:59:39 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Wed, 28 Jun 2023 17:59:39 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrtdefgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdetlhgv gigrnhguvghrucevhhgvrhhnihhkohhvfdcuoehmvghlihhfrghroheshfhrvggvuefuff drohhrgheqnecuggftrfgrthhtvghrnhepffdtkefhleffvdduvdeggfejteeugeegheel feeijeegudeufeetgeelueeguddtnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpfh hrvggvsghsugdrohhrghdpudeiledrvdehgedruddvfedruddtudenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgdomhgvshhmthhprghuth hhphgvrhhsohhnrghlihhthidqudefvdelvdduvdefvddqvdelfeeiuddtgeekqdhmvghl ihhfrghroheppefhrhgvvgeuufffrdhorhhgsehmphhlshdrihgv X-ME-Proxy: Feedback-ID: i02494642:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id DE2772D40090; Wed, 28 Jun 2023 17:59:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33 List-Id: Discussion about FreeBSD jail(8) List-Archive: https://lists.freebsd.org/archives/freebsd-jail List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-jail@freebsd.org Mime-Version: 1.0 Message-Id: <810c6bd0-261b-4129-bf40-e390be0e8278@app.fastmail.com> In-Reply-To: References: <93d61b80-95cb-4b3e-84dc-1d8b655e66f7@app.fastmail.com> Date: Wed, 28 Jun 2023 22:59:16 +0100 From: "Alexander Chernikov" To: "Shivank Garg" Cc: freebsd-jail@freebsd.org Subject: Re: Add IP address ioctl (SIOCAIFADDR) from jail is called with host credentials Content-Type: multipart/alternative; boundary=d0f921a6a82747fe8bccab4ed7d522b4 X-ThisMailContainsUnwantedMimeParts: N --d0f921a6a82747fe8bccab4ed7d522b4 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 28 Jun 2023, at 6:30 AM, Shivank Garg wrote: > Hi Alexander, >=20 > Thanks for replying. > I think it would mean struct prison info is lost, when it reaches ioct= l code, Is there some way we can get jail id? Yes, you should add the hook to the netlink handler. >=20 > Another question I have: prison_check_ip4 still relies on checking str= uct prison for flags and ip addr.=20 > https://github.com/freebsd/freebsd-src/blob/6927176113ee775983952edb3c= 201fed6be318d3/sys/netinet/in_jail.c#L319 > How do we handle these cases? I=E2=80=99ll take a look on the weekend. It may indeed be a problem with= nested jails. >=20 > It used to work for VNET jails inet calls sometime back when I wrote = mac_ipacl: https://reviews.freebsd.org/D20967 > - MAC policy to limit jail privilege to set its IP address. We were pl= anning to merge this code in 14.0. Is there something we can > do regarding it? Yep, sure! I=E2=80=99ll try to further decouple ioctl handler and the ac= tual address modification code so the ioctl hook wont=E2=80=99t get call= ed in the netlink handler. > Thanks, > Shivank >=20 > On Wed, 28 Jun 2023 at 04:05, Alexander Chernikov wrote: >> __ >>=20 >>=20 >> On Fri, 23 Jun 2023, at 10:27 AM, Alexander Chernikov wrote: >>>=20 >>>=20 >>> On Fri, 23 Jun 2023, at 7:53 AM, Shivank Garg wrote: >>>> Hi, >>>>=20 >>>> I want to check credentials of the thread setting the IP address wi= th SIOCAIFADDR ioctl. >>>> If the thread is jailed (jailed(td_ucred) =3D=3D 1), I'm applying s= ome checks on ip address. >>>>=20 >>>> My expectation was that (cred->cr_prison !=3D &prison0) for an ifco= nfig call made by the jail. >>> If you=E2=80=99re using -head, it=E2=80=99s a bit more complicated. = ifconfig(8) uses rtnetlink(4) interfaces to communicate with the kernel.= Privilege check is done in Netlink: https://github.com/freebsd/freebsd= -src/blob/764464af49688e74fd6d803df0404ca4726dd460/sys/netlink/route/ifa= ce.c#L1472 . After that, (as of now) netlink calls ioctl code from its o= wn kernel thread, which may be the reason of the behavior you=E2=80=99re= observing. >> Apparently the previous message was not delivered everywhere. >>>> However, it is showing me some weird behavior. Here are the logs fo= r a tweaked kernel: >>>>=20 >>>> @@ -339,7 +343,7 @@ in_control(struct socket *so, u_long cmd, void = *data, struct ifnet *ifp, >>>> return (EADDRNOTAVAIL); >>>> struct ucred *cred =3D (td !=3D NULL) ? td->td_ucred : NULL; >>>> - >>>> + printf("in_control jailed? %d jid %d prison_owns_vnet? %d\n= ",jailed(cred),cred->cr_prison->pr_id,prison_owns_vnet(cred)); >>>>=20 >>>> # jexec 1 ifconfig epair0b inet 169.254.123.101/24 up >>>>=20 >>>> Dmesg logs: >>>> *[256] in_control jailed? 0 jid 0 prison_owns_vnet? 1* >>>>=20 >>>> Cred value indicates host and jail is 0 but the PR_VNET flag is set. >>>>=20 >>>> Is this behavior expected? or something going wrong - what's the ne= xt debug step? >>>>=20 >>>> I greatly appreciate your help! >>>>=20 >>>> Thanks, >>>> Shivank >>>=20 >>> /Alexander >>>=20 >>=20 >> /Alexander /Alexander --d0f921a6a82747fe8bccab4ed7d522b4 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Wed, 28 Jun 2023, at 6:30 AM, Shivank Garg wrote:
<= /div>
Hi Alexander,

Thanks for replying.
I think it would mean struct prison info is lost, when= it reaches ioctl code, Is there some way we can get jail id?
<= /div>
Yes, you should add the hook to the netlink= handler.

Another question I have: prison_check_ip4= still relies on checking struct prison for flags and ip addr. 
=
How do we handle = these cases?
I=E2=80=99ll take a look o= n the weekend. It may indeed be a problem with nested jails.

 It used to work for VNET jails inet calls sometime back= when I wrote mac_ipacl: = https://reviews.freebsd.org/D20967
- MAC policy to lim= it jail privilege to set its IP address. We were planning to merge this = code in 14.0. Is there something we can
do regarding = it?
Yep, sure! I=E2=80=99ll try t= o further decouple ioctl handler and the actual address modification cod= e so the ioctl hook wont=E2=80=99t get called in the netlink handler.
= Thanks,
Shivank

On Wed, 28 Jun= 2023 at 04:05, Alexander Chernikov <melifaro@freebsd.org> wrote:



=
On Fri, 23 Jun 2023, at 10:27 AM, Alexander Chernikov wrote:<= br>


On Fri, 23 Jun 2023, at 7:53 AM, Shivank= Garg wrote:
Hi,

I wa= nt to check credentials of the thread setting the IP address with S= IOCAIFADDR ioctl.
If the thread is jailed (jailed(td_ucred= ) =3D=3D 1), I'm applying some checks on ip address.

<= /div>
My expectation was that (c= red->cr_prison !=3D &prison0) fo= r an ifconfig call made by the jail.
If= you=E2=80=99re using -head, it=E2=80=99s a bit more complicated. ifconf= ig(8) uses rtnetlink(4) interfaces to communicate with the kernel. Privi= lege check is done in Netlink:  https://github.com/freebsd/freeb= sd-src/blob/764464af49688e74fd6d803df0404ca4726dd460/sys/netlink/route/i= face.c#L1472 . After that, (as of now) netlink calls ioctl code= from its own kernel thread, which may be the reason of the behavior you= =E2=80=99re observing.
Apparently the previou= s message was not delivered everywhere.
However, it is showing= me some weird behavior. Here are the logs for a tweaked kernel:

@@ -339,7 +343,7 @@ in_control(struct socket *so, u_long cmd, v= oid *data, struct ifnet *ifp,
          &nbs= p;     return (EADDRNOTAVAIL);
        = struct ucred *cred =3D (td !=3D NULL) ? td->td_ucred : NULL;
-
= +       printf("in_control jailed? %d jid %d prison_owns_= vnet? %d\n",jailed(cred),cred->cr_prison->pr_id,prison_owns_vnet(c= red));

# jexec 1 ifconfig epair0b inet <= a href=3D"http://169.254.123.101/24" target=3D"_blank">169.254.123.101/2= 4 up

Dmesg logs:
[256] in_con= trol jailed? 0 jid 0 prison_owns_vnet? 1

Cred value indicates host and jail is 0 but the PR_VNET&nb= sp;flag is set.

Is this behavior expected? or something going= wrong - what's the next debug step?

I grea= tly appreciate your help!

Thanks,
<= /div>
Shivank

/Alexander
=


/Alexander

/Alexander

--d0f921a6a82747fe8bccab4ed7d522b4--