Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755592Ab3CHIJx (ORCPT ); Fri, 8 Mar 2013 03:09:53 -0500 Received: from mail-vb0-f43.google.com ([209.85.212.43]:46695 "EHLO mail-vb0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752545Ab3CHIJt (ORCPT ); Fri, 8 Mar 2013 03:09:49 -0500 MIME-Version: 1.0 In-Reply-To: <20130307215620.GA2159@redhat.com> References: <20130305151829.GB4519@redhat.com> <1362516018.4392.233.camel@falcor1> <20130305215300.GE4519@redhat.com> <1362584551.4392.291.camel@falcor1> <20130306235525.GB29229@redhat.com> <1362620348.4392.408.camel@falcor1> <20130307143643.GA2790@redhat.com> <1362670833.4392.438.camel@falcor1> <20130307155343.GD2790@redhat.com> <20130307215620.GA2159@redhat.com> Date: Fri, 8 Mar 2013 10:09:48 +0200 Message-ID: Subject: Re: IMA: How to manage user space signing policy with others From: "Kasatkin, Dmitry" To: Vivek Goyal Cc: Mimi Zohar , Eric Paris , linux kernel mailing list , LSM List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5254 Lines: 133 On Thu, Mar 7, 2013 at 11:56 PM, Vivek Goyal wrote: > On Thu, Mar 07, 2013 at 07:53:50PM +0200, Kasatkin, Dmitry wrote: > > [..] > > Hi Dmitry, > >> Sorry if missed something from this lengthy thread and I repeat something. >> >> I have not noticed what functions you propose to export. > > Actually I have not come up with functions yet. I have yet to write > the code. But I was thinking something along the lines of > verify_signature(). > >> >> But for your use case you need to know if file was signed and >> signature was fine, right? > > Right. > >> So you want to export a function which returns, for example >> "iint->flags & IMA_DIGSIG". > > Not sure about that but I think you are referring to your patch > of also exporting the iint->DIGSIG by setting a security flag > LSM_UNSAFE_DIGSIG in bprm->unsafe. That helps but then more > issues start cropping up. I will explain issues in detail below. > >> If it was no xattr or no signature, then this flag will not be set. > > - if iint->DIGSIG is not set then it could mean few things. > - There is no xattr or digital signature > - Or there is signature but ima is disabled or there is no > appraise rule configured. > > Now second point can create confusion. It means that a signed file will > be treated as unsigned and any functionality dependent on file being > signed will fail. I think it is uintutive. > > If there is no xattr or signature, IMA hook can return failure if appraise > policy is configured. I can't ignore the return code of security hook. So > I need a separate function just to tell me whether file is signed or > not. > >> If signature verification failed, then hook returns EPERM anyway. > > There are few issues here. > I fully understand them. In the past I have implemented attacks to IMA that based on the fact that verification result is cached... > - iint->DIGSIG will be set only if ima is enabled and some appraise > rule/policy has been enabled. Otherwise it will not be set. It might > not be too huge a issue because it just means that a signed file will > be treated unsigned and any functionality dependent on file being > signed will fail. I think it is uintutive. > > - iint->DIGSIG could be set even if file is not signed. How? > - Assume system has booted with ima_appraise_tcb policy. > - A binary executes. bprm_check() is called and it will > set iint->DIGSIG. > - root does a direct write to disk blocks where file signature > are stored. > - File executes again. This time iint->DIGSIG is set but there > are no signature on the file. > > - File could have invalid signature still iint->DIGSIG could be set and > security hook will return success. > - Assume system has booted with ima_appraise_tcb policy. > - A binary executes. bprm_check() is called and it will > set iint->DIGSIG. > - User goes ahead and replaces appraise policy with some > other policy so no appraisal rule will match for same file. Policy can only be replaced once. So if policy has been initialized at early-user-space, then it cannot be replaced... > - User does a direct write to disk on file blocks. > - File executes again. This time iint->DIGSIG is set, and > IMA hook will return success (as there is no matching appraise > rule) and making caller believe file is validly signed. > > If we don't cache iint->DIGSIG, I think couple of above issues could be > solved. But then we also need to make sure digest of file and appraisal > results not cached either. Caching of everything is in general a issue > with IMA usage in my scenario. I am not sure why IMA did not address the > issue of somebody writing directly to disk bypassing file system. IMA protects against offline attacks. Runtime protection should be done by DAC/MAC. But anyway, I fully understand that you want also additional runtime protection. > > If we figure a way out to disable caching of everything, then we also > need to figure out a way to export iint->DIGSIG to callers. Current > security hooks don't allow returning anything other than success/fail > status, that means we probably need to create a new function. Seeting > it in bprm->unsafe alone is not sufficient as I might have to do file > verification in non executable file code also. bprm->unsafe was just a very-quick show-case. > > In summary, we can still solve the problem we can do few things. > > - Provide a reliable way to disable caching of iint->DIGSIG, digest > and appraisal results. > > - Provide functions to access iint->DIGSIG after every file execution. > > - Create a separate callable IMA function which tells whether file is > signed or not. > > - Provide a way to caller to ensure whether caching is disabled or not > in IMA. So that caller can interpret what does result mean. > > Thanks > Vivek I understand what you want to achieve :) - Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/