Date: Fri, 25 Jul 2014 08:32:58 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Shawn Webb <lattera@gmail.com> Cc: Tim Kientzle <tim@kientzle.com>, Bryan Drewery <bdrewery@freebsd.org>, Pedro Giffuni <pfg@freebsd.org>, freebsd-arch@freebsd.org, PaX Team <pageexec@freemail.hu>, Oliver Pinter <oliver.pntr@gmail.com> Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <DAE144FC-9649-43C6-B47F-038E7C95EE87@FreeBSD.org> In-Reply-To: <20140724135200.GR29618@pwnie.vrt.sourcefire.com> References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <alpine.BSF.2.11.1407230017490.88645@fledge.watson.org> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> <D7CEDB47-2818-461A-BB70-479BEBDCEEE9@freebsd.org> <796EDB88-3768-48AA-B909-8A7FFBED0C1E@kientzle.com> <alpine.BSF.2.11.1407241035550.116@fledge.watson.org> <20140724135200.GR29618@pwnie.vrt.sourcefire.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Jul 2014, at 14:52, Shawn Webb <lattera@gmail.com> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DAE144FC-9649-43C6-B47F-038E7C95EE87>