On Thu, Jan 17, 2013 at 4:58 PM, Kasatkin, Dmitry <dmitry.kasat...@intel.com> wrote: > On Wed, Jan 16, 2013 at 11:53 PM, Vivek Goyal <vgo...@redhat.com> wrote: >> On Wed, Jan 16, 2013 at 02:24:50PM -0500, Mimi Zohar wrote: >> [..] >>> > > Sorry, this is out of scope for IMA. Dmitry has looked into this, but >>> > > I'm not sure where it stands at the moment. >>> > >>> > Ok, so that's one reason that why I wrote these patcehs. IMA currently >>> > is not doing following things to make sure address space of signed images >>> > is not modified by others. >>> > >>> > - Protecting against modifications to pages on swap. >>> > - Protecting against modifications by ptrace. >>> > - Protecting against modifications which bypassed filesystem and directly >>> > wrote to the block. >>> > >>> > Locking down all the pages of signed binaries in memory hopefully should >>> > solve above problems. >>> >>> Signing and verifying ELF executables goes back a long time ~2003/4, >>> from a number of esteemed kernel developers, including Greg-KH and Serge >>> Hallyn. >>> >>> IMA-appraisal isn't limited to appraising a single type of file, but is >>> a generic mechanism for appraising all files. If there are issues that >>> aren't being addressed, then by all means, please help by addressing >>> them. Duplicating a large portion of the code is not productive. >> >> So do you have ideas on how to address above mentioned issues. Do they >> fit into the realm of IMA/EVM or I just need to write separate code (which >> I have already done). >> >> With above issues, IMA stuff for executable files sounds incomplete. >> > > swap is a last resort. healthy system uses swap minimally. > It is very easy to add /etc/crypttab which allows to have encrypted swap > > # <target name> <source device> <key file> <options> > swap /dev/sda6 /dev/urandom swap > > And it will eliminate plenty of possible attacks. > Processes have also RW data, modification of those will create huge > risk for the system... > > But certain locking extensions like you implemented can be added to IMA as > well. > > It was said about ptrace already. > > >> - Protecting against modifications which bypassed filesystem and directly >> wrote to the block. > > Can you please tell a bit more how this patch protect against direct > writing to the blocks? > > Thanks, > Dmitry > >> Thanks >> Vivek
One important thing to mention. Protecting ELF-only does not help too much in protecting the system. There are plenty of init, upstart and systemd scripts which must be verified as well. IMA does it. - Dmitry -- 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/
