Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757520AbbDXPB2 (ORCPT ); Fri, 24 Apr 2015 11:01:28 -0400 Received: from mail-lb0-f173.google.com ([209.85.217.173]:36411 "EHLO mail-lb0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754885AbbDXPB0 (ORCPT ); Fri, 24 Apr 2015 11:01:26 -0400 MIME-Version: 1.0 Date: Fri, 24 Apr 2015 16:01:24 +0100 Message-ID: Subject: Regression: Requiring CAP_SYS_ADMIN for /proc//pagemap causes application-level breakage From: Mark Williamson To: linux-kernel@vger.kernel.org Cc: "Kirill A. Shutemov" , Pavel Emelyanov , Konstantin Khlebnikov , Andrew Morton , Linus Torvalds , Mark Seaborn , Andy Lutomirski , linux-api@vger.kernel.org, Finn Grimwood , Daniel James Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2276 Lines: 50 Hi all, Recent changes have restricted a userspace interface used by our product; specifically, a security patch to require CAP_SYS_ADMIN when opening /proc/PID/pagemap (https://github.com/torvalds/linux/commit/ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce, original LKML discussion here: https://lkml.org/lkml/2015/3/9/864). Although I've marked this as a "Regression", we do realise there are legitimate security concerns over the original implementation of this interface. Still, given the kernel's strong stance on preserving userspace interfaces, we thought we ought to flag this quickly as something that has changed application-relevant behaviour. We believe this change came into released kernels with Linux 4.0. We first observed problems when testing on Ubuntu 15.04 this week; I see the patch is now backported to the various -stable kernel lines, so I'd expect it to show up in other distros in due course. The obvious solution (to simply run with CAP_SYS_ADMIN) is quite undesirable for our product, which is a debugger; we're expecting our users to run without special privileges. In our use of /proc/PID/pagemap, we currently make use of the physical pageframe addresses. We should be able to work with a scrambled representation of these (Andy Lutomirski suggested this in the original discussion - https://lkml.org/lkml/2015/3/16/1273) so long as the scrambling remained consistent during the lifetime of the open pagemap file. Alternatively, if physical addresses were simply zeroed (also suggested by Pavel Emelyanov - https://lkml.org/lkml/2015/3/9/871) we would be able to change our code to rely only on the soft-dirty flag and thus still work correctly. I propose to follow up with a patch that provides unprivileged access to /proc/PID/pagemap with the physical pageframe addresses zeroed. Would this be an acceptable approach? Thank you, Mark Williamson --- Undo Software - http://undo-software.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/