From owner-freebsd-security@freebsd.org Tue May 5 23:59: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 2D5B22D9DC0 for ; Tue, 5 May 2020 23:59:34 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49GxXj18S2z3Dn8; Tue, 5 May 2020 23:59:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f67.google.com with SMTP id f3so394097ioj.1; Tue, 05 May 2020 16:59:32 -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=UP9C2AEeBu9v0wlCEeQPexsfhFpga4IKS2hx7/h7E3Q=; b=jP1/uF0c8Xl1aL5wIS8iXR7bHuW8nkUjrmgjc5YM70ifU/z4i0tUraocK4H2fSZO2c hxEFjhwXJTyahxmK5ZbaSAwGn1OY3SVkeotJ4BbAVDS/USojMrEF3u/S0dYRtWtX3g0Z 3jAYRf2WSEE6bcKAaGOrU81VVkPDgv/E2B5sG1yRFSL4gbrl3Q8auNXOj/Sj4DG0MioQ hICYhN0eayBIzq33vBqcnq+lbUkBI9ZSVvMZVoM0q6UroqzVVNYYYjvi7aThfDqIhXdX P8a9bhvCGO7QJNDZffC5Tg1R7Sc3v4DU3Lv0Z094TsIiCvTe7RkZk9wt0sUaHQ3nG6Eb 8ztw== X-Gm-Message-State: AGi0PubCfxjpcE2Lax5y43qlVo+jGX1o/fFd6Vq34Cblknw/wAnddMPh LxtHIRS3QUbmW2gdVNZyNrFqffsxx6qXtBiMFELU1mCk X-Google-Smtp-Source: APiQypIKsrIU/PXx3zU3NDPQBBOcRjJrk24MFk5qPhyEPJPUSmvPAR8JgmQQj0nJXVZQK/SZyplcM0FYixgDTMqSKdA= X-Received: by 2002:a05:6602:2208:: with SMTP id n8mr6204792ion.102.1588723171846; Tue, 05 May 2020 16:59:31 -0700 (PDT) MIME-Version: 1.0 References: <20200423153835.GF42225@spindle.one-eyed-alien.net> <9ad00dc0-b9d5-525a-9d5d-b65dac60f0d4@heuristicsystems.com.au> In-Reply-To: <9ad00dc0-b9d5-525a-9d5d-b65dac60f0d4@heuristicsystems.com.au> From: Ed Maste Date: Tue, 5 May 2020 19:59:19 -0400 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Dewayne Geraghty Cc: Brooks Davis , freebsd-security@freebsd.org, Marcin Wojtas , Rafal Jaworowski Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49GxXj18S2z3Dn8 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.67 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[67.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.18)[ip: (-0.02), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[67.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 23:59:34 -0000 On Mon, 4 May 2020 at 19:39, Dewayne Geraghty wrote: > > It would be palatable to have a "secure.mk" under /usr/ports/Mk/Uses > that enables pie, relro, now, noexecstack and elfctl features. Then > port users can enable/disable their (elfctl) default features as they wish. The general intent for elfctl isn't to have a lot of knobs to worry about, either user- or developer-facing, and they'll generally be opt-outs. Ports with known incompatibilities will be tagged at build time (regardless of whether mitigations are enabled), and mitigations should be able to be turned on system-wide. We should be able to address non-executable stack in a similar way - virtually all ports should have a RW GNU_STACK segment indicating that the stack is not executable, so a ports build stage could check for that and produce an error if not, with some sort of override for any exceptional cases. We definitely want some global infrastructure for pie, relro, and bind_now.