|
From: Mimi Z. <zo...@li...> - 2015-01-28 03:40:59
|
On Tue, 2015-01-27 at 12:56 -0700, Curtis Veit wrote: > I have really appreciated help received on the user list. > I've now been about to get my appraisal functionality working well for > executables. (currently evm breaks it but I am putting that to the back burner) > > Most of the questions below may be able to be dealt with using LSM labels, > Is there a good reference somewhere to using LSM labels? > I currently have apparmor enabled and it does not appear to do much with labels. > Should I do something like adding Smack labels and use those or roll my own? Right, Apparmor does not label the file system using extended attributes (xattrs), like SElinux or Smack. Without LSM stacking, only one LSM can be active on a system per boot. > Any recommendations would be very welcome. > If there are no comments about the following I will assume that the > correct approach is to use LSM labels. Although there are actually > a couple items where clarification would be nice. > > I do have a few questions that affect the way the I will implement measurement > policy. Most important perhaps is wondering how policy rules that apply to a > subset of files work when there is also a rule that affects a superset? > A specific example is that I am signing and appraising all executables. > I would like to measure or appraise all config files using a hash. As there > are no path based rules, and my approach can be simple, I am looking > at using: action = (measure or appraise), mask = MAY_READ, fowner = root > (and I assume I want) func = FILE_CHECK. By default, files are appraised based on either a hash or signature. Requiring a file signature can be specified using the "appraise_type=imasig" option. For example, the following rules would require all files executed to be signed. For all other hooks, file integrity appraisal would be based on either a hash or signature. appraise fowner=0 func=BPRM_CHECK appraise_type=imasig appraise fowner=0 > Is there any way to obtain appraise actions based on a hash on the config files > while using appraise actions based on signatures on the executables? Identifying just the "config" files is the hard issue. > If not then I guess that means that I can only measure the config files? > > If I set a rule to measure these files the rule will also encompass the > root owned executables and they do not have a hash they only have a signature. > (When I create a hash for these it overwrites the signature.) > Is there a way to either provide both a hash and signature or to somehow exclude > the executables from a rule that catches the configuration files? Explanation above. > Is the use of the rules order dependent to allow masking a more general rule? The rules are order dependent. In the above example, the more specific "BPRM_CHECK" rule is specified first. > One more... > I was thinking of protecting some config files (that are essentially immutable > for these systems) with signatures but cannot see a good way to differentiate > between immutable configs and mutable configs. I was tempted to change the > group id to a "wheel" group but IMA only seems to only check fowner. Here's an opportunity to add "gid" support. :) > Is there a way to specify MAY_NOT_EXEC? > Can I just set an additional security xattr to flag this? Sorry, that is an access control(LSM) issue, not integrity. Mimi > Thanks and best regards, > Curtis |