On Mon, 2017-12-11 at 11:01 -0500, Paul R. Tagliamonte wrote: > > Great! And if you replaced the "uid=0" with "fowner=0" the appraisal > > would succeed whether or not you're running as root. > > I was looking to appraise any binaries that a single user is running, > not anything any user runs that's owned by root. > > > Different files can be signed with different keys, but all keys should > > be loaded onto the same _ima keyring. (This will change once IMA is > > namespaced.) > > Yes. Good copy on that. > > My question was about how to ensure the _ima keyring is present in all > user's keyrings, if the IMA module is searching the user executing the > program's keyring. See the terminal output in my last mail. It shouldn't need to search multiple keyrings as all keys should be on the one and only IMA keyring. > Once again, the kernel is throwing errors if I try to appraise > binaries that uid 1000 is running unless the _ima keyring is linked to > uid 1000's @u keyring. Is this expected behavior, and if so, where can > I read more about this? This is definitely not expected behavior. > > The policy defines which files should be appraised. If you want to > > verify files owned by uid 1000, the policy would include an appraise > > rule fowner=1000. > > I want to appraise anything run by user 1000, regardless of file > owner. I can only seem to do this if uid 1000's @u has a _ima keyring > under it, and **not** if uid 0's @u has an _ima keyring under it. Is > this expected behavior? The builtin measurement policy measures all files executed (eg. measure func=BPRM_CHECK). A similar rule could be defined to appraise everything executed (eg. audit func=BPRM_CHECK), but the builtin policy can't do that since it would require knowing and signing all executables, including scripts, on the file system. For this reason, we've defined the builtin appraise TCB policy to appraise only files owned by root. > > Normally one starts with something that is known to work, before > > attempting/complaining something different doesn't work. > > Cheers, thanks for that. > > I'd like to point out that at no point have I complained, even about > things fully deserving of it, such as the lack of documentation or > opaque errors. Agreed, the wiki and documentation definitely need to be updated. It's on my "todo" list. I'm hoping to work my way through it, when things quiet down. > I've been courteous and tried to provide helpful > information and context proactively. To be honest, I'm a bit > disappointed and frustrated at this side-comment. Basically you're asking me to replicate your environment to figure out why your environment isn't working, before you've tried the "normal" method of creating a keyring/loading keys (eg. dracut/systemd) and booting the system with a builtin policy. > I understand you must be frustrated, and I appreciate you replied on a > weekend and it's not your job to provide support, but as a newcomer, I > am just as frustrated with this interaction. >From my perspective, I need to understand if you're reporting a regression or a new usecase scenario. > A bit of empathy would be nice. You definitely have my empathy! Until files come signed, enabling IMA-appraisal is difficult. For now, create the keyring and load the keys in the initramfs, as you described. Boot with the builtin policies by adding the ima_policy="tcb|appraise_tcb" on the boot commnad line. Only afterwards, replace the builtin "appraise_tcb" policy with a custom policy, which appraises all executables not just those owned by root. Instead of "appraise func=BPRM_CHECK fowner=0 appraise_type=imasig" the appraise rule would be "appraise func=BPRM_CHECK appraise_type=imasig". Mimi
