On Thu, Jan 17, 2013 at 10:55 PM, Vivek Goyal <vgo...@redhat.com> wrote: > On Thu, Jan 17, 2013 at 03:33:47PM -0500, Frank Ch. Eigler wrote: >> Vivek Goyal <vgo...@redhat.com> writes: >> >> > [...] >> >> Can you please tell a bit more how this patch protect against direct >> >> writing to the blocks? >> > >> > If you have loaded all the pages from disk and locked them in memory and >> > verified the signature, then even if somebody modifies a block on disk >> > it does not matter. We will not read pages from disk anymore for this >> > exec(). We verified the signature of executable loaded in memory and >> > in-memory copy is intact. >> >> Does this imply dramatically increasing physical RAM pressure and load >> latency, because binaries (and presumably all their shared libraries) >> have to be locked & loaded? (Else if they are paged out to >> encrypted-swap, is that sufficient protection against manipulation?) > > Even if you employ encrypted-swap, we still need to lock down any code > and data which lives in executable file on disk to avoid the case of > it being modified directly by writing to a block. Looks like IMA will not > detect that case. >
See my IMA patch I set today, which does locking the same way as you do. - Dmitry > May be we can only lock down any information which is loaded from > executable file. Rest of the pages can be swapped to encrypted swap. > > As long as number of signed binaries are small, I think RAM pressure might > not be a problem but yes, if we sign everything, it will become an issue. > > I am not sure how kernel can enforce the requirement of encrypted swap. If > we leave it to user as a recommendation, then we have the potential that > some hacker can bypass the whole thing. So it is not enforceable. > > May be there could be a config option if that's enabled swapping works only > if it is encrypted. > > So locking few select statically compiled executables completely in memory > I think should not be too much of trouble and solve the problem I have at > hand. > > For the more generic case of completely locked system, we will have to > conditionally modify the code to lock only any info loaded from executable > and allow swapping other data to encrypted swap. This one we can look into > once somebody really wants to use it. > > Thanks > Vivek > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
