Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Dmitry Kasatkin <dmitry.kasatkin <at> intel.com>
Subject: [RFC v2 0/4] ima: directory and special files integrity protection
Newsgroups: gmane.linux.kernel.lsm
Date: Friday 17th August 2012 18:03:14 UTC (over 5 years ago)
Hello,

Both IMA-appraisal and EVM protect the integrity of regular files.
IMA protects file data integrity, while EVM protects the file meta-data
integrity, such as file attributes and extended attributes. This patch
set adds offline directory and special file integrity protection.

An inode itself does not have any file name associated with it. The
association of the file name to inode is done via directory entries.
On a running system, mandatory and/or discretionary access control prevent
unprivileged file deletion, file name change, or hardlink creation.
In an offline attack, without these protections, the association between
a file name and an inode is unprotected. Files can be deleted, renamed
or moved from one directory to another one. A simple example is restoring
an old file from backup, containing an exploit. In all of these cases,
the integrity of the file data and metadata is good.

To prevent such attacks, it is necessary to protect the integrity of the
directory content.  These patches maintain a hash of the directory contents
and verify this hash on first access after boot. The directory hash is a
hash over list of directory entries, that includes name, offset, ino,
d_type.

Similarly, IMA does not protect integrity of special files, such as
symbolic links, device nodes, sockets, pipes. Links might be modified
and it will remain undetected.

This patch set adds 2 new hooks - ima_dir_check() and ima_dir_update() -
for directory integrity protection.

ima_dir_check() verifies the directory integrity during the initial path
lookup, when the dentry is just being created and may block. It allocates
the needed data structures and performs the integrity verification.
The results of which are cached. Subsequent calls mostly happen under
RCU locking, when the code may not block, and returns immediately with
the cached verification status. So ima_dir_check() does not break
RCU path walk.

ima_dir_update(), which is called from several places in namei.c when
the directory content is changing, updates the directory hash.

Similarly to regular files, directory integrity is protected with the hash,
which is stored in the 'security.ima' extended attribute and protected by
EVM. 

For special files verification, also 2 new hooks have been added.
ima_link_check() is called from follow_link() and generic_readlink().
ima_special_check()is called from IMA open hook.

Changelog in v2:
- ima_dir_check() code in may_lookup() refactored to look clear
- dentry sorting has been removed, because dentry order stays the same
- after initial verification, verification status is returned without
locking
  It is completely RCU walk friendly
- added integrity verification of special files.
- more informative commit messages and cover letter

- Dmitry


Dmitry Kasatkin (4):
  ima: hooks for directory integrity protection
  ima: directory integrity protection implementation
  ima: hooks for special files integrity protection
  ima: special files integrity verification implementation

 fs/namei.c                          |   54 +++++-
 fs/open.c                           |    7 +
 include/linux/ima.h                 |   33 ++++
 net/unix/af_unix.c                  |    3 +
 security/integrity/ima/Kconfig      |    9 +
 security/integrity/ima/Makefile     |    1 +
 security/integrity/ima/ima.h        |    3 +-
 security/integrity/ima/ima_dir.c    |  321
+++++++++++++++++++++++++++++++++++
 security/integrity/ima/ima_main.c   |    6 +
 security/integrity/ima/ima_policy.c |    4 +
 10 files changed, 434 insertions(+), 7 deletions(-)
 create mode 100644 security/integrity/ima/ima_dir.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 3ms