From owner-freebsd-security@freebsd.org Mon May 25 15:24:27 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 D4E0C3299C7 for ; Mon, 25 May 2020 15:24:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49W1966Z19z40c6 for ; Mon, 25 May 2020 15:24:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f68.google.com with SMTP id f3so18960737ioj.1 for ; Mon, 25 May 2020 08:24:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bgbhekkMs6R4Sic5Qh+L/qj3ZDYUlzkzDVyKgqGGqHc=; b=mXtDbFW3zmIYPuxuHoIKv88XxzXHCwGFQhQY2qa9T2uk3XCfHpqQtAe2W8uRXMfQP9 3u2l2ItA482Q3x371aizJpIeNYjZKC5TK4UvZkKob1nI06ta3xLOXwdgLtt6R3siOYYy Gq+mCIftD6k7eE4JG8vy5vwpeKE1OXegVvSiBTsUllLL1i+Aq0+JHV+H1HyBzlN6mzr5 +BmoMIU34UInELGKp32pjyD/l8HNQTpLcret2sKqBBCzXOi6Kwufs1FQdnRODdpCdfG4 F9dpo/PogibfkreAmxApJRrNfmx7XYuGo6a24Y/bxmsBtnyHVVYPMdJcmzX4OGDJKaOG bvUQ== X-Gm-Message-State: AOAM530bV4TYz5XDLlKTibxKR0WJ8zU3Pmh2PNpKHCIbL4Hikl8aU1nO sjunj75j/qfK2+LWhwf/11j6cOnSQnEbKAJcrdp+Jf/0w+c= X-Google-Smtp-Source: ABdhPJxNqRPpZYfOkbLLjVy6E83mhhFRhQvsvIHPfTpZT0PR1jesXd8KnGLYgxPHIqYd7QX6KQSvYAF9bkakVlMD7N0= X-Received: by 2002:a05:6638:a47:: with SMTP id 7mr19343398jap.12.1590420265582; Mon, 25 May 2020 08:24:25 -0700 (PDT) MIME-Version: 1.0 References: <151792368.1257575.1589959200761.JavaMail.zimbra@stormshield.eu> In-Reply-To: <151792368.1257575.1589959200761.JavaMail.zimbra@stormshield.eu> From: Ed Maste Date: Mon, 25 May 2020 11:24:13 -0400 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Damien DEVILLE Cc: Marcin Wojtas , freebsd-security@freebsd.org, Rafal Jaworowski Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49W1966Z19z40c6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.68 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.002]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.08)[-0.078]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.68:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.68:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] 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 15:24:27 -0000 On Wed, 20 May 2020 at 03:20, Damien DEVILLE wrote: > > Hi everyone, > > This a very good news. Thanks to Semihalf to their commitment on this subject. > 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 other hardening subjects (like for example improving W^X) ? Do you have any roadmap in terms of features and deadlines ? My goal is that we can test & enable these features in advance of FreeBSD 13.0 (although there's no published timeline for 13 yet). We can aim for iterating over each of the settings over the rest of this year. Basic W^X for mmap and mprotect at the system call interface is trivial - I put a(n untested) patch up at https://reviews.freebsd.org/D24933 as an illustration. There's a TODO in the description before this could be committable - adding procctl(2), proccontrol(1), and ELF tagging support. > We would be interested to take part to live discussions as a vendor if some are planned. Sounds good. This will make a good topic in lieu of BSDCan developer summit sessions. Interested folks please email me off-list and fill in the poll of suitable times at http://whenisgood.net/qbmg72a From owner-freebsd-security@freebsd.org Mon May 25 16:37:33 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 3608A32B7DF for ; Mon, 25 May 2020 16:37:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49W2nS1kCJz477n for ; Mon, 25 May 2020 16:37:32 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f45.google.com with SMTP id r2so8806037ioo.4 for ; Mon, 25 May 2020 09:37:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zzwY8qpVZOxQZdIx/jQycGbI6aUKuRQVyGnFwviEk6g=; b=U4g3KmxcTcTAL4ckKPInrVadaARKqI7Kmp2AO1bOBgKscqc/+ctX9HA3qSebXnSm0M mdMUFqMoW/WewREE4YQsJO2KHGoI4OY2B35a1hoNFzTqWyehAWP8G2QsO/RLcIle2OAP hJCEvj/4KXW8uckqOo/NJXY3cb5Gl+e/7H4keNL++yR7MoefvtxOsxX9WOV4IdnLs2vV qrhwlzxXP1CuDyEApoPz8M95mof1b43NcOP6g9/4enr3lVbGpYPBSOlwAfJozqq96FzN UmG4vBzAKqOOYqZMpekGj0tYqMR9GfYQydydcX4+zLkz0FeD05ndDAxo7P1tw8DbQndL QiXQ== X-Gm-Message-State: AOAM532uTOacmrIjI+d0wJhvqdUgEYhAHe7sikaSa015/AbuOrjWzc4C ou4hG2YnMYsrCMXK4RnpxnUdd+F2xRBYi7G6d7CrxUMhCt0= X-Google-Smtp-Source: ABdhPJycDPLN/hMTXQr+a7aFMoGMae6C0qw9OD8GA9sCeCUSnEkyJe9SOBkALLz3jvTahq8S+BLPZpMjz1FUM7XBH2o= X-Received: by 2002:a5d:824c:: with SMTP id n12mr14046420ioo.15.1590424651176; Mon, 25 May 2020 09:37:31 -0700 (PDT) MIME-Version: 1.0 References: <1641188.rRC0nNcZtX@amos> In-Reply-To: <1641188.rRC0nNcZtX@amos> From: Ed Maste Date: Mon, 25 May 2020 12:37:19 -0400 Message-ID: Subject: Re: Malicious root user sandboxing To: ihor@antonovs.family Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49W2nS1kCJz477n X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.14 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.98)[-0.976]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.15)[-1.151]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.45:from]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.45:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com] 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 16:37:33 -0000 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. 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-- From owner-freebsd-security@freebsd.org Mon May 25 20:29:02 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 77A4D2CA1CB for ; Mon, 25 May 2020 20:29:02 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49W7wY52cvz4Xcq for ; Mon, 25 May 2020 20:29:01 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f44.google.com with SMTP id f3so19797820ioj.1 for ; Mon, 25 May 2020 13:29:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DLY0/sFu6WA4XbivZ+uBZ+r+zxJfWayGozKbHJwMcjE=; b=ZPZD7OJn7cB0zpUKdSHY7jJaQ0dxftPn2yK/JIjzYqha1CCCZ7LcTJgujDfqT+/F7D tH/zALp2n8+tUEcryizXA/FE9TIX7Jx1xZ0S9Pa7xvfAvuQSHCnuAvJwhVOJzAnuU8TK 984diGwriA5EmCi1jdnuEEetZbyGVzIUSURf9iTGaClhCWmefClmwmWRxzRzPy9a6fVW NbHEg2l2Tw5EcYqx/3zgrfOQWWP6GnNm6oS77g9ijx9xwTgpMqv30X0IBQjnUbjNPhL4 9xEOPefE7/DPPO0VUP89LPMFmlsOLbPaKfdsCtVrIAK8ojbQS6L1lC0DVJmm77thG+sW Xpfw== X-Gm-Message-State: AOAM53358HEOvJOlvDzWzXc92GNve/xFOnNtLkFppX3L48ZFghzBx0fI ccoEy/ZBWRqZWmjUI67Bt1uOcckBzCvzPQZndG+b52Bt X-Google-Smtp-Source: ABdhPJyYgavx3iQIJx4a+A3NV44JqJG0iACzUebM/+CkMe5BqHIJSf4uM5bY+3z34mIakpvGPY8INnf2U2ciStl4aKE= X-Received: by 2002:a05:6638:dd3:: with SMTP id m19mr21423389jaj.106.1590438540734; Mon, 25 May 2020 13:29:00 -0700 (PDT) MIME-Version: 1.0 References: <1641188.rRC0nNcZtX@amos> <9242947.RX05g1dFuk@amos> In-Reply-To: <9242947.RX05g1dFuk@amos> From: Ed Maste Date: Mon, 25 May 2020 16:28:48 -0400 Message-ID: Subject: Re: Malicious root user sandboxing To: ihor@antonovs.family Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49W7wY52cvz4Xcq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.98)[-0.979]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.72)[-0.717]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.44:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.44:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] 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 20:29:02 -0000 On Mon, 25 May 2020 at 14:00, Ihor Antonov wrote: > > 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? There are no explicit plans at this point and right now I would describe it as a solid proof of concept - it works well, but only a limited amount of functionality is supported by libpreopen. That said, I would be very happy to see it developed further and become a component of FreeBSD.