From owner-freebsd-security@freebsd.org Sun May 17 00:02:17 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 F26112DA8E0 for ; Sun, 17 May 2020 00:02:17 +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) server-signature RSA-PSS (4096 bits) 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 49Pj4m70t7z4BWL for ; Sun, 17 May 2020 00:02:16 +0000 (UTC) (envelope-from ihor@antonovs.family) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antonovs.family; s=20200215; t=1589673728; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type; bh=7peg1p7XYZheeH8upYYCIRsSsdfRN54EUDYqNoGZqt8=; b=6LUOHX8pHeu7d2BG6ulWphF+4RABpUp+5ZG5/mtjwE47JBSrj+jKjgSIn0pIupqAecZza+ TuIZjSnPy8xgI5ME3REhttfol69Vk2l13hcQA6EUJ4wlDSTkBkep4l3ZFbBW+B60LqytDm H2ZUfB8RUDwBeOxBpcCMZ2MwpbSgYlg= Received: by mail.antonovs.family (OpenSMTPD) with ESMTPSA id f13e19ba (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Sun, 17 May 2020 00:02:07 +0000 (UTC) From: Ihor Antonov To: freebsd-security@freebsd.org Reply-To: ihor@antonovs.family Subject: Malicious root user sandboxing Date: Sat, 16 May 2020 17:02:04 -0700 Message-ID: <1641188.rRC0nNcZtX@amos> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9804114.PH3qC69YLz"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 49Pj4m70t7z4BWL X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=antonovs.family header.s=20200215 header.b=6LUOHX8p; 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 [-7.82 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[antonovs.family:s=20200215]; HAS_REPLYTO(0.00)[ihor@antonovs.family]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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.00)[-1.000,0]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DKIM_TRACE(0.00)[antonovs.family:+]; DMARC_POLICY_ALLOW(-0.50)[antonovs.family,none]; IP_SCORE(-3.22)[ip: (-9.06), ipnet: 100.24.0.0/13(-3.98), asn: 14618(-3.01), country: US(-0.05)]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; 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: Sun, 17 May 2020 00:02:18 -0000 --nextPart9804114.PH3qC69YLz Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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. Threat Model: ------------ Assumption is that attacker have gained remote control of the smtp server process. It is necessary to limit the blast radius in case of the RCE. What I want to achieve: ----------------------- 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. 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. 3) Application should not be able to change it's login class. 4) Application should not be able to escape the sandbox by forking a child process. 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. 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 How to get there?: ----------------- - securelevel=3 pretty much solves requirement 7 - firewall can prevent undesired incoming or outgoing connections. Although firewall does not distinguish between applications(other apps need other ports) and so requirement 1 can't be satisfied without putting smtp server in its own VNET jail. This is as far as I was able to go before I started researching MAC Framework. And it seems at first to be able to solve some of the problems, but not quite. - mac_bsdextended can be used to satisfy requirements 2 and 8 but it operates on UIDs so access will be restricted for any root process, which is undesired. Is there a way to target specific process or login class with bsdextended? - Same goes for mac_portaclmac - operates only on UID level. So requirement 1 can't be satisfied without impacting the rest of the system So it seems that there is no way to sandbox an untrusted application with MAC without severely restricting whole OS usability. And this warning in man pages confirms my suspicions: > man 4 mac > While the MAC Framework design is intended to support the containment of > the root user, not all attack channels are currently protected by entry > point checks. As such, MAC Framework policies should not be relied on, in > isolation, to protect against a malicious privileged user. Questions I did not find any answers to: ---------------------------------------- - Is it possible to restrict login class change for a root process? (requirement 3) - How to enforce resource limits? rctl seem to target process, user, loginclass or jail. using it for all root process is undesired. login class is coupled with the question above process - can be escaped by forking a child. - Is it possible to satisfy my requirements with Biba/MLS? - Is it possible to label an executable with MLS so that the running process will inherit the label? - Is it possible to shake-off Biba/MLS the label by forking a child or changing login class? So far it seems that my endeavor is doomed. Any comments or suggestions are appreciated. Thanks ------------ Ihor Antonov -- Ihor Antonov --nextPart9804114.PH3qC69YLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEERRGvVtv7zdxEBhtZWJxtLLeFgVIFAl7AfvwACgkQWJxtLLeF gVL1ew/7BvokPy3flPEXb8p06jKBGejcpFcear3XwUNl6lewT5sQobqUU74gZ36q t+t6r/UF5PWfoVOwGG2rgDNY6d0JdVJhFGwcmTss+68vlvAwOapPr91Uu1zT3V+G aP3ddI715/p2rB9GYdPhVblRMVQcI+WLf1cE3utVivF59sQsL3lGAfjlY8nccz5A X7Tdzspn4pRczJZAxAWeqsF/5SbEQRstSV8etPKU1EX5YLOR5wkreXEiVGSdnML2 7pEuTJGdEFgZQrv9lGBmLlyQfhKhKy+uEe9PVbF+xCNpnUhb3HcVPEAO5ALoUyNE hXCKq3qYvCLyhr90fMBEOsA9iiMwzvZcxn524ZGFP0eti/NafskGv8hNgTACW/wM GARb5Emi5W4ozVVsXryHB0Mr8M12VI26EtJZMWTcWkmdxa92m1tiXDnsetcF9FKY zL5HE9qjhZZ2PgAek4nbiOkGGNomMUxCcxc8MeDcfgqGUJ2NCyRsgnMsjHl0ndrO 7ZyrzG1oP9bJkF4MYHlGeiDLEysMJETDqu2Zl0kQlgSkKiuqrDRFQAponadjlElf X001KRWvYyXKb/Z8qDTahDgKZmK+qJMNcEW+D43Gy+A2Jw3Ol8VhA2Cm+NCl/tUt OS/Vh8fMr9iQZa4k8ye8twY40ImNQCoysXK6eXC4SCmeDiH+hcQ= =MoZH -----END PGP SIGNATURE----- --nextPart9804114.PH3qC69YLz--