Re: [RFC PATCH v3 2/2] ima: force re-appraisal on filesystems with FS_IMA_NO_CACHE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Seth Forshee (seth.forshee@xxxxxxxxxxxxx):
> On Mon, Jan 22, 2018 at 05:24:52PM +0100, Alban Crequy wrote:
> > From: Alban Crequy <alban@xxxxxxxxxx>
> > 
> > This patch forces files to be re-measured, re-appraised and re-audited
> > on file systems with the feature flag FS_IMA_NO_CACHE. In that way,
> > cached integrity results won't be used.
> > 
> > How to test this:
> > 
> > The test I did was using a patched version of the memfs FUSE driver
> > [1][2] and two very simple "hello-world" programs [4] (prog1 prints
> > "hello world: 1" and prog2 prints "hello world: 2").
> > 
> > I copy prog1 and prog2 in the fuse-memfs mount point, execute them and
> > check the sha1 hash in
> > "/sys/kernel/security/ima/ascii_runtime_measurements".
> > 
> > My patch on the memfs FUSE driver added a backdoor command to serve
> > prog1 when the kernel asks for prog2 or vice-versa. In this way, I can
> > exec prog1 and get it to print "hello world: 2" without ever replacing
> > the file via the VFS, so the kernel is not aware of the change.
> > 
> > The test was done using the branch "alban/fuse-flag-ima-nocache-v3" [3].
> > 
> > Step by step test procedure:
> > 
> > 1. Mount the memfs FUSE using [2]:
> > rm -f  /tmp/memfs-switch* ; memfs -L DEBUG  /mnt/memfs
> > 
> > 2. Copy prog1 and prog2 using [4]
> > cp prog1 /mnt/memfs/prog1
> > cp prog2 /mnt/memfs/prog2
> > 
> > 3. Lookup the files and let the FUSE driver to keep the handles open:
> > dd if=/mnt/memfs/prog1 bs=1 | (read -n 1 x ; sleep 3600 ) &
> > dd if=/mnt/memfs/prog2 bs=1 | (read -n 1 x ; sleep 3600 ) &
> > 
> > 4. Check the 2 programs work correctly:
> > $ /mnt/memfs/prog1
> > hello world: 1
> > $ /mnt/memfs/prog2
> > hello world: 2
> > 
> > 5. Check the measurements for prog1 and prog2:
> > $ sudo cat /sys/kernel/security/ima/ascii_runtime_measurements \
> >                 | grep /mnt/memfs/prog
> > 10 [...] ima-ng sha1:ac14c9268cd2[...] /mnt/memfs/prog1
> > 10 [...] ima-ng sha1:799cb5d1e06d[...] /mnt/memfs/prog2
> > 
> > 6. Use the backdoor command in my patched memfs to redirect file
> > operations on file handle 3 to file handle 2:
> > rm -f  /tmp/memfs-switch* ; touch /tmp/memfs-switch-3-2
> > 
> > 7. Check how the FUSE driver serves different content for the files:
> > $ /mnt/memfs/prog1
> > hello world: 2
> > $ /mnt/memfs/prog2
> > hello world: 2
> > 
> > 8. Check the measurements:
> > sudo cat /sys/kernel/security/ima/ascii_runtime_measurements \
> >                 | grep /mnt/memfs/prog
> > 
> > Without the patch, there are no new measurements, despite the FUSE
> > driver having served different executables.
> > 
> > With the patch, I can see additional measurements for prog1 and prog2
> > with the hashes reversed when the FUSE driver served the alternative
> > content.
> > 
> > [1] https://github.com/bbengfort/memfs
> > [2] https://github.com/kinvolk/memfs/commits/alban/switch-files
> > [3] https://github.com/kinvolk/linux/commits/alban/fuse-flag-ima-nocache-v3
> > [4] https://github.com/kinvolk/fuse-userns-patches/commit/cf1f5750cab0
> > 
> > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > Cc: linux-integrity@xxxxxxxxxxxxxxx
> > Cc: linux-security-module@xxxxxxxxxxxxxxx
> > Cc: linux-fsdevel@xxxxxxxxxxxxxxx
> > Cc: Miklos Szeredi <miklos@xxxxxxxxxx>
> > Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
> > Cc: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
> > Cc: Dmitry Kasatkin <dmitry.kasatkin@xxxxxxxxx>
> > Cc: James Morris <james.l.morris@xxxxxxxxxx>
> > Cc: "Serge E. Hallyn" <serge@xxxxxxxxxx>
> > Cc: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
> > Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>
> > Tested-by: Dongsu Park <dongsu@xxxxxxxxxx>
> > Signed-off-by: Alban Crequy <alban@xxxxxxxxxx>
> 
> I like this approach as it doesn't require any IMA policy changes to be
> effective. I'm not sure about the flag name (in my mind it would
> describe the fs property and not be specifically giving instructions to
> IMA), but if others are happy with it I won't complain.

Purely internal name at least, so if we come up with a better name
we can trivially change it.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux