From owner-freebsd-security@freebsd.org Mon May 25 18:00:34 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ACD9632D75C for ; Mon, 25 May 2020 18:00:34 +0000 (UTC) (envelope-from ihor@antonovs.family) Received: from mail.antonovs.family (mail.antonovs.family [100.25.240.195]) (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 (2048 bits) client-digest SHA256) (Client CN "mail.antonovs.family", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49W4dF6HRcz4FdD for ; Mon, 25 May 2020 18:00:33 +0000 (UTC) (envelope-from ihor@antonovs.family) Received: by mail.antonovs.family (OpenSMTPD) with ESMTPSA id b61e9793 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 25 May 2020 18:00:25 +0000 (UTC) From: Ihor Antonov To: freebsd-security@freebsd.org Reply-To: ihor@antonovs.family Subject: Re: Malicious root user sandboxing Date: Mon, 25 May 2020 11:00:22 -0700 Message-ID: <9242947.RX05g1dFuk@amos> In-Reply-To: References: <1641188.rRC0nNcZtX@amos> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart162544286.F4svvxeWm1"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 49W4dF6HRcz4FdD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=antonovs.family; spf=pass (mx1.freebsd.org: domain of ihor@antonovs.family designates 100.25.240.195 as permitted sender) smtp.mailfrom=ihor@antonovs.family X-Spamd-Result: default: False [-4.55 / 15.00]; HAS_REPLYTO(0.00)[ihor@antonovs.family]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.01)[-1.013]; REPLYTO_ADDR_EQ_FROM(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-0.12)[-0.116]; DMARC_POLICY_ALLOW(-0.50)[antonovs.family,none]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:14618, ipnet:100.24.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 18:00:34 -0000 --nextPart162544286.F4svvxeWm1 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, 25 May 2020 09:37:19 PDT Ed Maste wrote: > On Sat, 16 May 2020 at 20:02, Ihor Antonov wrote: > > Hello FreeBSD Community, > > > > I am looking for possible options to sandbox an untrusted application that > > runs with root privileges. > > > > I can't use Jails or Capsicum as modification of the application is > > outside of the scope of my task and application needs to share the file > > system with some other applications. (several applications use PAM to > > authenticate users and they all have to have the same set of users, and I > > want > > to avoid duplicating system users across jails) > > > > For this write up I will use opensmptd server as an example application, > > but there are many more examples that fit the usecase. > > Is the application dynamically linked? If so it's possible to do > "oblivious sandboxing" with Capsicum. There's a proof of concept in > the "Super Capsicumizer 9000" - > https://github.com/myfreeweb/capsicumizer. It builds on libpreopen > from MUN which handles filesystem access. This is not something that > will work "out of the box" today for your application, but is an area > of active interest that could benefit from a motivating use case. With > some development work (using the approach of capsicumizer + > libpreopen) it could be the basis for a quality sandbox. > > > 1) Application should only be able to listen and talk to TCP port 25. > > > > Initiating connections to other TCP ports and other address families > > must be prevented. > > This would be net new work, intercepting connect(2), accept(2) and > such, passing the args to a socket service, and returning the fd. > > > 2) Application should only have write access to a specific directory, the > > > > rest of the filesystem must be seen by the application as read-only. > > Capsicumizer + libpreopen is most of the way there now. A little work > would be needed to extend it to support different permissions per > directory group. > > > 3) Application should not be able to change it's login class. > > This is inherent in capability mode. > > > 4) Application should not be able to escape the sandbox by forking a child > > > > process. > > Capsicum does not address this, but the child starts in capability > mode and inherits the same sandbox restrictions. The real need then is > for comprehensive resource limits. > > > 5) Application's resource usage must be limited. > > > > 6) Application should not be able to shake-off resource limits by forking > > > > a child or changing login class. > > This probably needs some rctl improvements. > > > 7) Application should not be able to change system configuration, > > load/unload> > > kernel modules, modify firewall rules. > > > > 8) Application should not be able to create new system users, > > > > or change passwords of existing users > > These are inherent in capability mode. Thanks Ed, I was looking at Capsicumizer and it looks very interesting. The only reason I was hesitant is that this is an external application, not a FreeBSD core. Is it going to be included in FreeBSD in some distant future? -- Ihor Antonov --nextPart162544286.F4svvxeWm1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEERRGvVtv7zdxEBhtZWJxtLLeFgVIFAl7MB7YACgkQWJxtLLeF gVLZtw//Tn0gQud9d2uHs62JYrbh0R7JB5WwhfJMkQrvtWxR/FdUd5MYWTJ+Wn/f 7Za+eusmX4HHeyus6SL0d8faFmFS43f6gb6RScrISGbKyvOcojVc6QKEjFXeL4im K5ZR7cBSk896YCLWbOOU2+9109Tc0qKa5gwDcSHi4dqi9vB8tdV4SAgjpDs89hek DnLQD3yHm6G+kU/1/78BltYKaiUVZ2xyeItwGywoEoq7lTA09Bld2nWNfvli52+0 V7m5LHi9er2ytDj8ZnbPL0Y6naQMAmsMV4g/jemVQwEe/qGVs7rADlXiB2hZgcyH 22b3foIjNq9R2/eUHfhWRO5C9qA+sYiwfKAcF0J/rOIu+WIiO4cZ1wPHetwiLkcz B1z55Mhnf8ZSGpeJbkIKAqZnJFqU8pgvQeGZ57mWPU5W3LpG9TYF8DBhPL9wt8/f p9TsQ8dmhl+m1NcjflQM2cwM9SMlajTFQ6IhC4NJoBi9OqIuFszgl/gimmqz4kGT KEEmHIxpkHbSzX3Ken2nqzC61S+lhuJcthoCoCEiGP6e5bASuOaqAfj2aNnzYtGk CKsDT3GHdqPWdCIYQJDr3eYwoyKLDDq0ofDmRpwvzClcYoL22oS+c0Eo4m/ZwacE QChTRuJtfuSKe3PDE15UldrPpvRFHM7VXPOXqtYNIw650++OLx0= =EQrv -----END PGP SIGNATURE----- --nextPart162544286.F4svvxeWm1--