[Linux-ima-user] example policy for appraisal with read/write files (was: Re: IMA (latest patches) do not allow creation of in policy files.)

[Patrick O. <pat...@in...>]

Hello Curtis!

Thanks for sharing your policy with the list. I found that very helpful.
May I ask some questions about it?

Is the appraisal part supposed to protect against offline attacks (i.e.
device turned off, partition mounted and modified)? What do you expect
to happen when that occurs?

You probably use both IMA and EVM, right?

My expectation is that a device protected by appraisal refuses access to
files that an attacker has tampered with while offline, without relying
on measurements and a remote service that checks these measurements.
Otherwise, what would be the benefit of appraisal?

For example, suppose there is a data file read by the init process (for
systemd, /lib/systemd/system/systemd-networkd.service would be a
specific example). I can think of two approaches how an attacker could
get systemd to use a modified file (for example, one which
invokes /bin/sh on a shell script which then runs as root).

     1. Edit the file, change owner from root:root to some other owner.
        Because appraisal is limited to files owned by certain groups,
        it is no longer covered by the policy and thus access is granted
        despite the modified content.
     2. Replace the file with a symlink to a file on the special
        partitions, modify it there.

Symlinks are explicitly allowed by systemd, and I also don't expect that
it cares about file ownership, so I don't see how such an attack would
be prevented. Do I miss anything?

On Mon, 2015-06-22 at 11:03 -0600, Curtis Veit wrote:
> -------------------------------------------------------------------------
> # Default Rules
> dont_measure fsmagic=0x9fa0
> dont_appraise fsmagic=0x9fa0
> dont_measure fsmagic=0x62656572
> dont_appraise fsmagic=0x62656572
> dont_measure fsmagic=0x64626720
> dont_appraise fsmagic=0x64626720
> dont_measure fsmagic=0x01021994
> dont_appraise fsmagic=0x01021994
> dont_measure fsmagic=0x858458f6
> dont_appraise fsmagic=0x858458f6
> dont_measure fsmagic=0x73636673
> dont_appraise fsmagic=0x73636673
> #
> # Special partition
> dont_measure  fsuuid=a11234...
> dont_appraise fsuuid=a11243...
> 
> # Special immutable group 
> appraise appraise_type=imasig func=FILE_CHECK mask=MAY_READ fgroup=200
> 
> # this area allows hashed executables
> appraise func=FILE_MMAP  mask=MAY_EXEC fsuuid=0761e0f1...
> appraise func=BPRM_CHECK mask=MAY_EXEC fsuuid=0761e0f1...
> #
> # All executables must be signed
> appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC
> appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC
> #
> # Attempt to avoid log and cache file (etc) 
> # This may belong above the previous appraise group
> # sda7=/tmp sda8=/var
> dont_measure  fsuuid=ac010c7... this is /tmp
> dont_appraise fsuuid=ac010c7... 
> dont_measure  fsuuid=...        this is /var 
> dont_appraise fsuuid=...
> 
> # Is there a better way to handle the text based log files 
> # that linux creates?
> 
> # Using groups instead of uid mainly for testing
> # gid functionality
> # group root = 0 may want to go by owner or group?
> # group shadow = 42 needed if above not by owner
> measure func=FILE_CHECK mask=MAY_READ fgroup=0
> appraise func=FILE_CHECK mask=MAY_READ fgroup=0
> measure func=FILE_CHECK mask=MAY_READ fgroup=42
> appraise func=FILE_CHECK mask=MAY_READ fgroup=42
> #
> # non-root group to protect with hashes = 201
> # also protect www-data group = 33
> measure func=FILE_CHECK mask=MAY_READ fgroup=33
> appraise func=FILE_CHECK mask=MAY_READ fgroup=33
> measure func=FILE_CHECK mask=MAY_READ fgroup=201
> appraise func=FILE_CHECK mask=MAY_READ fgroup=201
> #
> # remaining default rules 
> measure func=BPRM_CHECK
> measure func=MODULE_CHECK
> measure func=FIRMWARE_CHECK

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.