Re: [PATCH v1 0/4] ima: require signed user-space initialization

[Dmitry Kasatkin]

On Wed, Jul 23, 2014 at 9:08 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 2014-07-16 at 23:26 +0300, Dmitry Kasatkin wrote:
>> Hello,
>>
>>
>> On Wed, Jul 16, 2014 at 12:33 AM, Andrew Morton
>> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Tue, 15 Jul 2014 15:54:19 +0300 Dmitry Kasatkin <d.kasatkin@xxxxxxxxxxx> wrote:
>> >
>> >> Currently secure IMA/EVM initialization has to be done from the initramfs,
>> >> embedded in the signed kernel image. Many systems do not want to use
>> >> initramfs or usage of embedded initramfs makes it difficult to have
>> >> multi-target kernels.
>> >>
>> >> This is a very simple patchset which makes it possible to perform secure
>> >> initialization by requiring initial user-space to be signed.
>> >>
>> >> It does it by:
>> >> - introducing IMA public keys loading hook
>> >> - loading IMA trusted public key into .ima trusted keyring
>> >> - making default IMA appraisal policy to require everything to be signed
>> >>
>> >> When builtin initramfs is not in use, keys cannot be read from initcalls,
>> >> because root filesystem is not yet mounted. In order to read keys before
>> >> executing init process, ima_prepare_keys() hook is introduced. Reading
>> >> public keys from the kernel is justified because signature verification
>> >> key is needed in order to verify anything else which is read from the
>> >> file system. Public keys are X509 certificates and itself signed by the
>> >> trusted key from the .system keyring. Kernel BIG KEYS support is an example
>> >> of reading keys directly by the kernel.
>> >>
>> >> CONFIG_IMA_APPRAISE_SIGNED_INIT kernel option is provided to make the IMA
>> >> default appraisal policy to required signature validation. Signed init
>> >> process need to initialize EVM key and load appropriate IMA policy which
>> >> would not require everything to be signed.
>> >>
>> >> Unless real '/sbin/init' is signed, a simple and practical way is to place
>> >> all signed programs, libraries, scripts and configuration files under
>> >> dedicated directory, for example '/ima', and run signed init process by
>> >> providing a kernel command line parameter 'init=/ima/init'
>> >
>> > The kernel may already have loaded kernel modules before it gets around
>> > to mounting rootfs and running /sbin/init.  How does that fit into the
>> > overall signing scheme?  And how did /sbin/modprobe get its signature
>> > checked?
>> >
>> >
>>
>> If kernel embedded initramfs is in use then it is signed together with kernel,
>> and this functionality is not needed and no need to enable it with
>> kernel configuration.
>>
>> As it is IMA extensions and it is entirely based on IMA functionality
>> it requires extended attribute support.
>>
>> If externally loaded initramfs is used, then that one uses cpio based
>> archive that does not support extended attributes and thus external
>> initramfs cannot be used for secure initialization.
>
> Right, but GNU tar version 1.27.1 supports Posix.1 (ustar) format, which
> has xattr support.  GNU CPIO supports the Posix.1 tar format.  The
> question is whether CPIO supports the included xattrs.
>
>> This functionality is targeted to be used without initramfs on normal
>> filesystems supporting xattrs. In such case, modprobe cannot be loaded before
>> rootfs is mounted. Any filesystems and block device drivers obviously
>> need to be embedded into the kernel. In the place where
>> ima_prepare_keys() hooks is called, we have
>>
>>    ima_prepare_keys();
>>    load_default_modules();
>>
>> So we load keys after mounting rootfs and before calling load_default_modules().
>> So if anything useful kernel loads with load_default_modules, will be
>> loaded after IMA key is available and thus modprobe will be verified.
>>
>>
>> > The proposed interface and implementation look reasonable to me.
>> > Opening and reading a file from the root fs is a bit unusual, but we
>> > already do something similar with "/sbin/init" and the reasoning here
>> > is similar.
>> >
>> > The only alternative I can immediately think of is to bundle the public
>> > keys into a kernel module and load them into the kernel that way but
>> >
>> > - if/when we implement module signing, we have a chicken-and-egg problem
>> >
>> > - doing it via a kernel module seems a bit fake - a bit of trickery
>> >   to reduce code duplication.  Better to do it explicitly.
>> >
>>
>> This was the idea. Kernel has embedded certificate signing key on the
>> .system keyring. Filesystem image/package can come with own signing key
>> and that one is loaded and verified by existing KEY infrastructure.
>> Entire signed init code can come as rpm or deb package with its own key.
>> That is benefit of loading key.
>
> Ok, this type of solution addresses the concerns of devices, but we also
> need a viable solution for systems with an initramfs.
>
> Mimi
>

Sorry for the late reply. I am on holidays at the moment.

Offered solution is simple one to work without initramfs.

When using initramfs, one approach is that it can be be embedded into
the kernel.

When initramfs is separate, offered solution would work as well, but
it would require initramfs container, which is 'cpio' would support
extended attributes. cpio does not support them. 'cpio' maintainer
Sergey Poznyakoff replied in my email to him that it would require
standardization work. He suggested that it is better to use 'tar'
archive which supports xattrs. Using tar for initramfs would require
initramfs tool changes across all distros and kernel. As I said above
offered solution would work as well for initramfs without any changes
if initramfs container would support xattrs... So further extensions
are not related to this patchset.

Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/