From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751397AbdEaPWk (ORCPT ); Wed, 31 May 2017 11:22:40 -0400 Received: from nm21-vm6.bullet.mail.ne1.yahoo.com ([98.138.91.114]:50740 "EHLO nm21-vm6.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114AbdEaPWi (ORCPT ); Wed, 31 May 2017 11:22:38 -0400 X-Yahoo-Newman-Id: 244168.30629.bm@smtp220.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ei3VW1QVM1m_tmHeGF46DxduSWEC2fUO4ysViB48N9ntJWP Qc6pU7YWtgqcimBKEVf026SzTVL.6BHHlfkbI7v_XtGiYEo66o1zmNQ004FY djGjRX7m8ToqaMzicd4y340djfGLaz_3KA53pX.dRjdlqxw0hzMY6g4pU3ih F.k0ggbT9U4Y1LfQKxK4XbN9tryd0TKK0IB_UZxO9jf8ECLmfO9Aqg73X0VT CLc1zIGSk0JAkKMKIPyznF.ekgckMB6YjPA0ITd6Kxj2EKXscOk_5sd9ceAv WCnALu5VYRHGYVVtcMW3IMv8JDUScg2DBkqlqXGqRvaAA4tmeUPIfYaoGz0W LxygAFS.dp8YSr3vJX64gLq_dTlGueSYH1xHv6EymJ9fpjXOmUnhCDPaXDk1 wB7ph5F9JkLo6vE_toapnBgobYyLv5er6MQz8Xi0hnSdCGYiHnoxBVg7z1A8 MYza2rcHnNOss8.26nxJrHWf4cE1aDbpW..07r.pMvoGuWcygjzJAuZxVq9p pIAWeeY8OkrPydDj3aN6uTqILCIfnFDd7IvdBxxZYn4xpk_pvEnAwTsXuYhe LiDW1mihJkvZiVjzoC8ZgY2HeYu4.YpCfYveeBOQHt63vl4E5uq54dlPn8XA Vj3jQusu6Rx8ulzYcdg-- X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [RFC 0/3] WhiteEgret LSM module To: Peter Dolding , Matthew Garrett Cc: Masanobu Koike , james.l.morris@oracle.com, "Serge E. Hallyn" , linux-security-module , linux-kernel References: <20170530111157.5196-1-masanobu2.koike@toshiba.co.jp> <20170530205002.GA9841@srcf.ucam.org> From: Casey Schaufler Message-ID: <0e0aa575-263a-893a-7ade-f2dc7ce679c2@schaufler-ca.com> Date: Wed, 31 May 2017 08:22:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/31/2017 3:59 AM, Peter Dolding wrote: > ... > > Like you see here in Australian government policy there is another > thing called whitelisted. > https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm > Matthew Garrett you might want to call IMA whitelisting Australian > government for one does not agree. IMA is signed. The difference > between signed and white-listed is you might have signed a lot more > than what a particular system is white-listed to allowed used. > To be clear, I'm all for a security module to support this policy. As the explicit requirement is for a whitelist, as opposed to allowing for a properly configured system*, you can't use any of the existing technologies to meet it. This kind of thing** is why we have a LSM infrastructure. Unfortunately, the implementation proposed has very serious issues. You can't do access control from userspace. You can't count on identifying programs strictly by pathname. It's much more complicated than it needs to be for the task. Suggestion: Create an security module that looks for the attribute security.WHITELISTED on things being executed/mmapped and denys it if the attribute isn't present. Create a program (whitelistd) that reads /etc/whitelist.conf and scans the system to ensure that only things on the list have the attribute. Or, download the list into the kernel and only allow the attribute to be set on files on the list. That's harder, what with rename, links, symlinks, mounts, chroot and containers. I wrote a security module (Datastate) back in 2010 that did much the same thing for a different purpose. Please, don't give up because of negative initial feedback. Believe it or not, the community (well, most of us, anyway) is willing to help to the extent possible. --- * A script that checks for the 'x' mode bit on files should suffice. ** A return to the heady days of the Orange Book?