From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2AFAC43387 for ; Sat, 5 Jan 2019 20:36:09 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5F195222FD for ; Sat, 5 Jan 2019 20:36:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F195222FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.91) (envelope-from ) id 1gfsff-0002Vp-Hm; Sat, 05 Jan 2019 15:35:51 -0500 Received: from omr2.cc.ipv6.vt.edu ([2607:b400:92:8400:0:33:fb76:806e] helo=omr2.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gfsfd-0002Vi-Gr for kernelnewbies@kernelnewbies.org; Sat, 05 Jan 2019 15:35:49 -0500 Received: from mr2.cc.vt.edu (smtp.ipv6.vt.edu [IPv6:2607:b400:92:9:0:9d:8fcb:4116]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x05KZl0F002850 for ; Sat, 5 Jan 2019 15:35:48 -0500 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by mr2.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x05KZfJV003922 for ; Sat, 5 Jan 2019 15:35:47 -0500 Received: by mail-qt1-f200.google.com with SMTP id u32so48593399qte.1 for ; Sat, 05 Jan 2019 12:35:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:date:message-id; bh=HVHAX5J1dZ2S6ny7nJJcx1f9LItd1xgI0JB5SwolC9I=; b=JrLfV4gsmVihI0DFnpjkQtoPzPRfI6FDrgJT5Fgfxn2s9/6vQ7pM9jWTW7DPz+oCLK VjFgyLeef1Uczw1IZ+A6kHmcPvHbOAqhrNl10NK13J4F6xmQNpjO7HrmxvryMJY8nSKe Iau/+tTzYVWasAsDHabhKpLVuNZc524CG2rhMawBMDXPFxOuABHg6Vv8yClbcjTfWCZm dmKlEfb9iC2YMNsUrQR2gtPMJ2PF43oU31zPhK/C3Wdm6/o3FoDj9tRe59O9GzH/QwhA 3ZZahvYGWo4CfURQdTZdhuAJB0L3DqAL/Zpuz6LxksGhWKzKJCHr03s7OsWCsOjkfU8x 2JpA== X-Gm-Message-State: AJcUukfl9PUvKd4W/9o0eQD8NqNtBA4AYUUQrwxGgcuF6E2/OGPaLnru C69BF1PFm2ACIcCXhAcsDxqiZntuxs/9z/3sCXaHzaM+9TVuIHpu5ZJejomkHvHOpwrByRSAJm+ ydj9siyJaXwjmyhVVP4ERdVu0hrXOJyopmPDU9Ck= X-Received: by 2002:aed:38a1:: with SMTP id k30mr4468925qte.50.1546720541799; Sat, 05 Jan 2019 12:35:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN5D6w9pZtysiGSRILGfXmFB44XJt5dWOYpnp4Go2S2KoByUllO+eH75hAppgzQyhnqpL8oZnQ== X-Received: by 2002:aed:38a1:: with SMTP id k30mr4468914qte.50.1546720541541; Sat, 05 Jan 2019 12:35:41 -0800 (PST) Received: from turing-police.cc.vt.edu ([2601:5c0:c001:4341::359]) by smtp.gmail.com with ESMTPSA id n71sm34970425qkh.59.2019.01.05.12.35.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 05 Jan 2019 12:35:40 -0800 (PST) From: valdis.kletnieks@vt.edu X-Google-Original-From: Valdis.Kletnieks@vt.edu X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: Lev Olshvang Subject: Re: How to forbid user space and kernel executable pages from becoming writable? In-reply-to: <33504091546702201@myt2-cd7fa496c4f7.qloud-c.yandex.net> References: <33504091546702201@myt2-cd7fa496c4f7.qloud-c.yandex.net> Mime-Version: 1.0 Date: Sat, 05 Jan 2019 15:35:39 -0500 Message-ID: <9784.1546720539@turing-police.cc.vt.edu> Cc: linux-il , kernelnewbies X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Sat, 05 Jan 2019 18:30:01 +0300, Lev Olshvang said: > Some articles, ex https://shanetully.com/2013/12/writing-a-self-mutating-x86_64-c-program/ > state that mprotect() can change protection of executable section. Note that appears to be a 5 year old article, and one that tries to be operating system agnostic. > As I understanf pte entry has page protection bits set to RO so mprotect > should change pte which is loaded to MMU/TLB. Why kernel can not refuse do > perform this mprotect call(). Whu we do norhave kernel config options to forbid > user-space mutable code as security feature? Hint: Read up on how shared libraries get loaded when a process starts up, and also read up on dlopen() Think about how you get those to work if you can't have user-space mutable code at all. Are you ready to accept the performance hit of statically linked binaries? Or the maintenance nightmare of replacing every relevant binary whenever a bug is found in a library (use glibc as an example)? > From the other side, when run-time linker or elf_loader loads the > executable it uses MAP_DENYWRITE which protect executable file from being > overwritten. Now, That's a reasonably cheap protection that closes a fairly large attack surface. It's a lot harder to exploit a buffer overrun or similar if it's difficult to find or create a page that's both writable and executable. Of course, there's always ways to change a page mapping to allow it - the other half of the protection is that the vast majority of exploits are severely limited in how many bytes can be injected. > To add to the confusion, the following quote from the LWN articlle > https://lwn.net/Articles/422487/ about CONFIG_DEBUG_SET_MODULE_RONX > "Marking the kernel module pages as RO and/or NX is important not only because > But I am not sure that some variant of pte_clear(), pte_mkexec() can not disable it. So how would modprobe and (possibly more importantly) rmmod work if it couldn't be disabled? > So let me cut to final qiestion: > > Suppose I want to cut off dynamic code instrumentation, like ftrace and friends. > Is it achievable at least at ARM architecture to enforce RO+X at hardware or kernel? And here is where we get into a discussion of computer security, and this thing called a "treat model". Basically, it boils down to several questions: 1) What sensitive data are you trying to protect? 2) Who/what are you trying to protect it from? 3) Why do you think "I should prevent XYZ" is a reasonable protection? If you're trying to harden a given feature, it's important to ask whether it's worth the effort (and include "amount of inconvenience caused" in there). And an often overlooked part is "how easy is it to bypass?". Say you manage to fix dlopen() and the dynamic loader to totally prevent code outside dlopen() from finding a writable executable page. What stops an attacker from simply handing an existing program a booby-trapped shared library via LD_LIBRARY_PATH? Similarly, disabling ftrace in the kernel doesn't buy you much if an attacker can modprobe code that re-enables it, or write a new kernel down into /boot and waiting for (or causing) a reboot. So now your security measure needs to include modifying the shared library loader to ignore environment variables when loading into a setuid binary, and add support for secure boot and crypto signing of kernel modules and other similar things.... _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies