From owner-freebsd-security@freebsd.org Thu May 21 05:17:13 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 AB301329986 for ; Thu, 21 May 2020 05:17:13 +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 49SHtJ5HBdz4PXh for ; Thu, 21 May 2020 05:17:12 +0000 (UTC) (envelope-from ihor@antonovs.family) Received: by mail.antonovs.family (OpenSMTPD) with ESMTPSA id 1023f729 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Thu, 21 May 2020 05:17:03 +0000 (UTC) From: Ihor Antonov To: freebsd-security@freebsd.org Reply-To: ihor@antonovs.family Subject: Re: Malicious root user sandboxing Date: Wed, 20 May 2020 22:16:58 -0700 Message-ID: <26311043.RtLttYiU3N@amos> In-Reply-To: <442284bc-e137-f5de-aee6-1d5c69e7d3b8@grosbein.net> References: <1641188.rRC0nNcZtX@amos> <442284bc-e137-f5de-aee6-1d5c69e7d3b8@grosbein.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3158226.By3kIKPnOH"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 49SHtJ5HBdz4PXh 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.41 / 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,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.80)[-0.803]; REPLYTO_ADDR_EQ_FROM(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-0.26)[-0.257]; DMARC_POLICY_ALLOW(-0.50)[antonovs.family,none]; NEURAL_HAM_MEDIUM(-0.95)[-0.954]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; 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-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Thu, 21 May 2020 05:17:13 -0000 --nextPart3158226.By3kIKPnOH Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Saturday, 16 May 2020 17:28:46 PDT Eugene Grosbein wrote: > 17.05.2020 7:02, Ihor Antonov wrote: > > So far it seems that my endeavor is doomed. Any comments or suggestions > > are > > appreciated. > > You'll need to write and test lots of kernel-level code to achieve this. > > I'd suggest you re-think your decision about jails because it seems jails > can really be the solution if you combine jail with other system abilities. > For example, sharing subtree with r/o access is easily achieved using > read-only nullfs mount. Jails have a lot of drawbacks to. In most basic (by the book) example you effectively end up with a separate machine, which just happens to share same kernel with the host. And you need to manage this machine separately patches, upgrades, etc. (viva tools like ansible / chef) This is not very different from "just put it on a different VM" suggestion. If you try to go off the handbook script and try using nullfs and unionfs to re-use pieces of your FS you quickly find out how limited those tools are. You can't mount a single file into a directory, nullfs and unionfs operate only on directories. Example: try to put a file into jails /etc. Your options are: a) mount the whole directory and duplicate/overwrite (depending on how exactly you do it) a lot of files b) copy the file In either case you are not far off the "separate VM" management scenario You also can't just mount / to /path/to/jail - so you end up mounting /bin /etc /sbin ... into the jail with a separate commands. And this is possible to do, but now you can't use a lot of conveniences that jail.conf has because your custom mounts conflict with jail's mount.* directives (and the order in which they execute is undocumented) I tried jails and was left disappointed. Jails are just VMs, trying to treat them somewhat closer to Linux containers is not justifiable given how much trouble it brings. > Also, shared PAM does not mean duplication of system user database, > take a look at: man -k pam_|fgrep '(8)' The idea was to have a lightweight solution with minimum moving parts. Bringing machinery like LDAP into this defeats the purpose of the exercise. > Usage of jails does not require any modification of the application. > I did it for multiple setups and it works perfectly. > > As last resort, you may run nested FreeBSD system using bhyve(8). Not an option as defeats the purpose of the excercise. -- Ihor Antonov --nextPart3158226.By3kIKPnOH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEERRGvVtv7zdxEBhtZWJxtLLeFgVIFAl7GDsoACgkQWJxtLLeF gVIyzg/+K2XokeAvS2OEipMZNb4RegHxq1FQrnL7oQAz1C9MrccLzyCcMSZpWt8O GyRu3eF3Ex2q0YNxZTF5053dgkksL5I40H05ykcOvPvXGR5bl1tBdEVDz4+X3a+v jDzeGtBIqMW9kRrWONEzMmltB4GHp/SMpx6YVtuRNhXxwTObiJHPBFKJ3GhH6uLC BUB7DXkM64iVz3/uYg4fM48nHr2Hu3DqM0WcfdJ5yKEyI1d5sBmjMMfxcNZcTcCh mMK+IzjciE1Z0hBO9u75rHDErYdo3zrF6J3cqhC/AfGrG1tE36lGKIXdES97pnzj VXwazUaZZVVQzquAxfQNBUdrjOkboiXjjSb3XKRKVimJg/b/9cJm+stUJIKtr9eH OSiIYJWShhBpetEGT/Y6I+zveELR1Imfe29waPp6fMy09z8O1yBfeR59q4GAJz+Q R88njqy80SXOGUL0lOlYi4Kld9Whnn/1gP4Njp2hQMmSAfJcl/lFOrBX5kQR8QEq J/tLo3KGpCsaGg7bNCflds1P03ijFN+pfIwyvdFj8VEvFM4QJlftF6uDjdxvAdq2 Pih3lVxrXi03a+yAX8MocDunea48yIVDcWJXK+jca5vjzRRrKM6QcE+LR/FLBoS9 ZHUfn+9MiqBsJvG38UiPaPYGU91/L+S7QuhUKRm7PPjPwTIv2j4= =9x5J -----END PGP SIGNATURE----- --nextPart3158226.By3kIKPnOH--