linux-kernel - Re: [RFC 0/3] WhiteEgret LSM module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e0aa575-263a-893a-7ade-f2dc7ce679c2@schaufler-ca.com>
Date:   Wed, 31 May 2017 08:22:34 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Peter Dolding <oiaohm@...il.com>,
        Matthew Garrett <mjg59@...gle.com>
Cc:     Masanobu Koike <masanobu2.koike@...hiba.co.jp>,
        james.l.morris@...cle.com, "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 0/3] WhiteEgret LSM module

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?