From owner-freebsd-arch@FreeBSD.ORG Fri Jul 25 07:33:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58F857E6; Fri, 25 Jul 2014 07:33:06 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8872F41; Fri, 25 Jul 2014 07:33:06 +0000 (UTC) Received: from [10.0.1.9] (host86-132-108-36.range86-132.btcentralplus.com [86.132.108.36]) by cyrus.watson.org (Postfix) with ESMTPSA id 7E2D846B1A; Fri, 25 Jul 2014 03:33:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch From: "Robert N. M. Watson" In-Reply-To: <20140724135200.GR29618@pwnie.vrt.sourcefire.com> Date: Fri, 25 Jul 2014 08:32:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> <796EDB88-3768-48AA-B909-8A7FFBED0C1E@kientzle.com> <20140724135200.GR29618@pwnie.vrt.sourcefire.com> To: Shawn Webb X-Mailer: Apple Mail (2.1878.6) Cc: Tim Kientzle , Bryan Drewery , Pedro Giffuni , freebsd-arch@freebsd.org, PaX Team , Oliver Pinter X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:33:06 -0000 On 24 Jul 2014, at 14:52, Shawn Webb wrote: > Great points. I agree completely. This is why I've added two = facilities > for toggling ASLR. I modified mac_bsdextended(4)/ugidfw(8) to provide > toggling ASLR on a per-binary basis. I also made the sysctl tunables > settable per-jail. This allows one to place the executable in question > in a jail where ASLR is turned off just for that jail. I came across > this on Tuesday of this week when doing ClamAV development. Since I do > all my development in a jail, I came across a bug in ClamAV and I = needed > deterministic behavior, so I turned off ASLR just for that jail and = was > able to find the cause of the bug and fix it. Could you say a bit more about the ugidfw use case: is it common to want = to not use ASLR for particular users or groups, rather than it being = focused on applications or installed system instances? One question I have is whether it is sometimes the case that code in = libraries is ASLR-unfriendly, as opposed to code in applications? = Tagging binaries is easy, but as run-time linking of some specific = library within a process might happen after quite a few layout choices = have been influenced by ASLR. Or is it really just applications that = have problems? >> (2) A new inherited process property, or perhaps credential property, = enabling >> ASLR. This can be changed to 'disabled' using a system call -- = perhaps >> prctl() or similar. If we hit a transitioning binary (e.g., = setuid) then >> in the same way that we manipulate other properties, we'd reset = to the >> global default. It would be easy to imagine this being CR_ASLR = on the >> cr_flags field of the credential. This could be set in various = ways by >> userspace applications -- by gdb, as a login-shell property, = perhaps via >> 'su' or something simular? >=20 > This is interesting. I didn't think of using the prctl facility. I'll > look into that. The main use case I have in mind for this is repeatable application = development: I'm running test suites against one or more in-development = programs and would like to get deterministic test-suite runs. This might = well not be under the debugger, so automatic disabling under the = debugger doesn't help, but it is a debugger-like environment in which = determinism is important. >> (3) As suggested by Kostik, an ELF note on binaries indicating that = the binary >> is not ASLR-compatible, which would override (I guess) the global = policy >> flag and process/credential flag. We could then set this with >> NO_ASLR=3Dtrue in Makefiles, during package creation, etc. >=20 > I really don't like ELF flags. It's really heavy-handed. It can trip > file-based IDSs (the hash of the file changes when you change an ELF > flag). It requires that the user, sysadmin, or team of sysadmins keep = a > database of binaries for which the ELF flag needs to be changed when = the > binary gets updated or replaced (think: freebsd-update, pkgng/ports). > This is why I went with mac_bsdextended(4)/ugidfw(8). In the end, the > user is still maintaining a database (via ugidfw(8) rules). But the = user > doesn't need to go back and modify anything if that binary were to = ever > be modified. >=20 > With that said, we are planning on also adding FS extended attribute > support as well. Though I'm unsure if extended attributes work over > network-mounted filesystems like NFS. I'm not imagining that the ELF note is something you change frequently = or dynamically: rather, that it's effectively a part of application = linking by the system build or packaging system. That means that the ELF = note will be in place before any IDS tools generate initial signatures, = etc. E.g., NO_ASLR in a base-system Makefile would cause us to always = generate the binary with a suitable ELF note in place. Similarly, as = part of the port definition, we might identify that some or all binaries = generated by the port require the ELF note. This will be much more = robust than using techniques like ugidfw or extended attributes, where = changes in file ownership, storing on filesystems without extended = attributes, etc, will prove extremely fragile. With that in mind: is there a use case in which you see binaries being = distributed by the FreeBSD Project that an end user will want to always = run without ASLR despite the fact that we believe the program to be = ASLR-friendly? Other than debugging environments, where tools such as = gdb can dynamically disable ASLR for specific processes, or we're not in = a 'debug shell' per above? >> I'm not opposed to MAC policy modules being able to manipulate ASLR = behaviour,=20 >> but I think I'd prefer that the core policy controls (e.g., the = above) be=20 >> MAC-independent. Part of the reason is that you may want ASLR on = very low-end=20 >> systems where the additional cost of MAC interposition is more = measurable. >=20 > How much overhead does mac_bsdextended(4) have? I'm assuming a small > ruleset pertaining to ASLR. Depends a lot on the system and configuration. The MAC Framework has = certain baseline costs when enabled but inactive -- which we have = attempted to minimise to the greatest extent possible. These are = typically masked pretty well on cache-centred, superscalar = architectures, but may be more visible on systems with less ILP and = slower clock rates (e.g., our FPGA-based BERI processors). Turning the = MAC Framework on, however, introduces additional costs -- I've not = benchmarked ugidfw lately, but my guess would be that it has a >0% and = <5% overhead on cached filesystem operations -- something to confirm if = we anticipate it entering universal use rather than being selectively = configured as part of a local tradeoff. I have other concerns about ugidfw as well: we don't have a useful = scheme to 'merge' different sets of ugidfw rule sets -- e.g., ones = provided by the vendor (make the pgsql user always turn off ASLR) vs the = end administrator, as it's intended to be an administrator-facing tool = rather than a vendor-facing tool. More generally, I'd like to learn more = about use cases in which users and groups, rather than application = installs or virtual-system instances, become a desirable granularity for = ASLR policy. >> How does this interact with features like the Linuxulator? Do we = also want=20 >> ABI emulations to be able to disable ASLR as ABIs might not support = it [well]? >=20 > Oliver has done testing on the linuxulator and has found it to be > stable. He can share more info about this. The question I had in mind was: are their ABIs that we emulate in which = introducing ASLR might violate assumptions of the ABI, or disrupt more = subtle functions of the emulator? For example, Kostik has pointed out = that mechanisms such as FreeBSD's ps_strings (part of our ABI) are = sensitive to randomised layout of the initial process stack, and changes = could cause certain ps(1) and procstat(1) functions to fail (e.g., ps = -e, procstat -x). A careful analysis of each ABI would be required to = convince ourselves that this isn't a problem. With ASLR use on many = other systems, it could well be that only the FreeBSD ABI remains = sensitive to surprising randomness, but that's not an assumption I would = reach naturally as well-known addresses have long been part of ABIs. Robert=