linux-kernel - Re: [GIT PULL] Security subsystem updates for 4.14

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 10 Sep 2017 08:17:19 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:     James Morris <jmorris@...ei.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, Sep 10, 2017 at 03:13:23AM -0400, Mimi Zohar wrote:
> 
> From a file integrity perspective this would be interesting, but that
> only addresses IMA-appraisal, not IMA-integrity or IMA-audit.  We
> would still need to calculate the file hash to be included in the
> measurement list and used for auditing.
> 
> Have you done any work on protecting the directory information itself
> (eg. file names) using Merkle trees?

I have not, because the problem that I was trying to address was
primarily concerned with immutable files.  I did do some brainstorming
about adding the filename into the data integrity header to prevent
someone who had direct access to the flash exchanging the inode
numbers for "rm" and "ls", such that if you had a policy which
required that all ELF executables be signed, that a trickster couldn't
cause the user to run "rm" when they meant to run, say, "ls", just for
the lulz.  :-)

But that would break various symlink or hardlinks that are
legitimately present (e.g., /sbin/mkfs.ext[234] being a link to
/sbin/mke2fs), and if the adversary can carry out a chip-off attack
against your root file system, (a) it's not clear how much this would
help, and (b) this is really what dm-verity is for.

The main security problem I was looking at is one where the system
image is already protected using dm-verity, but you might have (for
example) some APK files which are downloaded once and stored in some
shared-user directory hierarchy (so file-based encryption can't even
provide pretend integrity protection), integrity checked at download
time, and never checked again.  Adding some kind of per-file Merkle
tree might be useful in that particular use case.

Cheers,

						- Ted