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-- From owner-freebsd-security@freebsd.org Sun May 17 00:29:18 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 EEC492E1B9B for ; Sun, 17 May 2020 00:29:18 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Pjgx5Smmz3yNJ for ; Sun, 17 May 2020 00:29:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 04H0SxWH036520 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 May 2020 00:28:59 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ihor@antonovs.family Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 04H0Sr1a057286 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 17 May 2020 07:28:53 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Malicious root user sandboxing To: ihor@antonovs.family, freebsd-security@freebsd.org References: <1641188.rRC0nNcZtX@amos> From: Eugene Grosbein Message-ID: <442284bc-e137-f5de-aee6-1d5c69e7d3b8@grosbein.net> Date: Sun, 17 May 2020 07:28:46 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1641188.rRC0nNcZtX@amos> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 49Pjgx5Smmz3yNJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.90)[ip: (-5.32), ipnet: 2a01:4f8::/29(-2.67), asn: 24940(-1.47), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; 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:29:19 -0000 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. Also, shared PAM does not mean duplication of system user database, take a look at: man -k pam_|fgrep '(8)' 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). 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-- From owner-freebsd-security@freebsd.org Thu May 21 07:43:21 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 E103932C469 for ; Thu, 21 May 2020 07:43:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49SM6w3X3Lz4XgM for ; Thu, 21 May 2020 07:43:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 04L7h1sL008977 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 May 2020 07:43:02 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ihor@antonovs.family Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 04L7gxrQ007784 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 May 2020 14:42:59 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Malicious root user sandboxing To: ihor@antonovs.family, freebsd-security@freebsd.org References: <1641188.rRC0nNcZtX@amos> <442284bc-e137-f5de-aee6-1d5c69e7d3b8@grosbein.net> <26311043.RtLttYiU3N@amos> From: Eugene Grosbein Message-ID: <6526a9b1-0913-20db-40a7-443623934e06@grosbein.net> Date: Thu, 21 May 2020 14:42:54 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <26311043.RtLttYiU3N@amos> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 49SM6w3X3Lz4XgM X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.31)[-0.305]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.04)[0.043]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[empty SPF record]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.29)[0.289]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(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: Thu, 21 May 2020 07:43:21 -0000 21.05.2020 12:16, Ihor Antonov wrote: > Jails have a lot of drawbacks to. [skip] > I tried jails and was left disappointed. Just use sysutils/ezjail from ports that hides all the hassle and does it all for you, so you need to perform installworld for the host system only. >> 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. If you don't like LDAP, use FreeRADIUS and pam_radius. Combined with ezjail, it is most lightweight solution you may currently obtain without writing additional kernel level code. From owner-freebsd-security@freebsd.org Wed May 20 07:20:05 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 0B4992C903A for ; Wed, 20 May 2020 07:20:05 +0000 (UTC) (envelope-from damien.deville@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49RkfW6Vm8z3Ydd; Wed, 20 May 2020 07:20:03 +0000 (UTC) (envelope-from damien.deville@stormshield.eu) Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 49EA037A2787; Wed, 20 May 2020 09:20:01 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 1689B3778060; Wed, 20 May 2020 09:20:01 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 work.stormshield.eu 1689B3778060 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu; s=BBC9ECEA-016A-11EA-9CC1-8A393C11FBBB; t=1589959201; bh=3pcV5B5kzdxYlAlwQKXDtO81DzIxPL9ZPjuH/EWIaBo=; h=Date:From:To:Message-ID:MIME-Version; b=xocbkjOaAWgOtKjMoxSbs91ZWrPRSc6y2iihLMd/8s/6iRW3INpTG1VTye2ww3dNu rqwvBcfF8lSfKmIe4AY6GDY6yJrn2Gy7d2dlytyAJ2pN2qtQDEHalJEvEI6BYxn7sv 53x1lLm0JB0LV1R2KkKTxszunKth3htvfESrHOXlZGvxNnc9/2VWuSY4zXi9OCqV/6 te4aWu5iUitWm7pPxWQDJ3dA5e3y65mhwQ0ydsA5p7DiYSxsv4tDagQHCGUbo0bweN j3uxcfQao1G6oh2YoNhP0dHBm5UvcOMY2cnFhOAI7nINZQcCMiA2TEME7eh4F3lyGq hd3f0C9ugAE3w== Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vU0YhA0Imkej; Wed, 20 May 2020 09:20:01 +0200 (CEST) Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id EA14837A7884; Wed, 20 May 2020 09:20:00 +0200 (CEST) Date: Wed, 20 May 2020 09:20:00 +0200 (CEST) From: Damien DEVILLE To: Marcin Wojtas Cc: emaste , freebsd-security@freebsd.org, Rafal Jaworowski Message-ID: <151792368.1257575.1589959200761.JavaMail.zimbra@stormshield.eu> In-Reply-To: References: Subject: Re: ASLR/PIE status in FreeBSD HEAD MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thread-Topic: ASLR/PIE status in FreeBSD HEAD Thread-Index: tMqGYIrSrJEaHZeuwLHjt3yAwySeLQ== X-Rspamd-Queue-Id: 49RkfW6Vm8z3Ydd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=BBC9ECEA-016A-11EA-9CC1-8A393C11FBBB header.b=xocbkjOa; dmarc=none; spf=pass (mx1.freebsd.org: domain of damien.deville@stormshield.eu designates 91.212.116.1 as permitted sender) smtp.mailfrom=damien.deville@stormshield.eu X-Spamd-Result: default: False [-2.23 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.920]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=BBC9ECEA-016A-11EA-9CC1-8A393C11FBBB]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.212.116.1]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[stormshield.eu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+]; NEURAL_HAM_SHORT(-0.81)[-0.806]; RCVD_IN_DNSWL_NONE(0.00)[91.212.116.1:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-Mailman-Approved-At: Thu, 21 May 2020 13:30:15 +0000 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: Wed, 20 May 2020 07:20:05 -0000 Hi everyone, This a very good news. Thanks to Semihalf to their commitment on this subje= ct. At Stormshield as a security vendor using FreeBSD we are highly interested = in all subjects that enhance the security level of FreeBSD. What is your target in term of timing ? Are there any plans to work on othe= r hardening subjects (like for example improving W^X) ? Do you have any roa= dmap in terms of features and deadlines ? We would be interested to take part to live discussions as a vendor if some= are planned. Internally we have some plans to work on this subject with deadlines by the= end of the year. Thanks to all of you for working on this subject, Damien -- Damien Deville IPS Technical Leader http://www.stormshield.eu Stormshield 2/6 Avenue de l'Horizon, Bat. 6 - FR 59650 Villeneuve d'Ascq ----- Le 14 Mai 20, =C3=A0 10:00, Marcin Wojtas mw@semihalf.com a =C3=A9cri= t : | Hi, |=20 | wt., 5 maj 2020 o 12:03 Marcin Wojtas napisa=C5=82(a): |> |> pon., 4 maj 2020 o 17:24 Ed Maste napisa=C5=82(a): |> > |> > On Mon, 20 Apr 2020 at 10:22, Marcin Wojtas wrote: |> > > |> > > Indeed I thought of kyua and measuring buildworld execution time for |> > > stressing the DUT and having the first comparison numbers for the lo= w |> > > price. |> > > |> > > Do you think it is possible to get help here, i.e. is there a FreeBS= D |> > > devops team, maintaining the Jenkins CI whose spare cycles could be |> > > used for this purpose? Or is this a field requiring external help fr= om |> > > interested parties? |> > |> > There aren't a lot of spare cycles to go around, but putting |> > automation in place so that tests like this can easily be performed is |> > certainly something that's in the Jenkins team's domain. |> |> Of course the available bandwidth is a limitation, but IMO we should |> start with defining the requirements so that eventually it could be |> added to the backlog. |> |> > |> > > Yes, making use of something actively maintained would be great. Do |> > > you see a need for IO stressing/benchmarking for the discussed cases= ? |> > |> > In the fullness of time I think it's important, but my opinion is that |> > it's really functional tests that we need, for enabling features in |> > -CURRENT; we can work on benchmarking before and after changing a |> > default. |> |> Understood. Since there seem to be no blockers / major objections at |> this point, how do you suggest proceed with the topic? How about |> having a live discussion with interested parties, so that we can |> establish at least a rough plan allowing to achieve the enablement of |> this (and possibly other) feature in a foreseeable perspective? |> |=20 | Any thoughts about having a live discussion on the ALSR/PIE enablement to= pic? |=20 | Best regards, | Marcin | _______________________________________________ | freebsd-security@freebsd.org mailing list | https://lists.freebsd.org/mailman/listinfo/freebsd-security | To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g"