Messages in this thread |  | | Subject | Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk | From | Roberto Sassu <> | Date | Tue, 14 May 2019 19:20:15 +0200 |
| |
On 5/14/2019 6:58 PM, Greg KH wrote: > On Tue, May 14, 2019 at 06:33:29PM +0200, Roberto Sassu wrote: >> On 5/14/2019 5:19 PM, Andy Lutomirski wrote: >>> On Mon, May 13, 2019 at 5:47 AM Roberto Sassu <roberto.sassu@huawei.com> wrote: >>>> >>>> On 5/13/2019 11:07 AM, Rob Landley wrote: >>>>> >>>>> >>>>> On 5/13/19 2:49 AM, Roberto Sassu wrote: >>>>>> On 5/12/2019 9:43 PM, Arvind Sankar wrote: >>>>>>> On Sun, May 12, 2019 at 05:05:48PM +0000, Rob Landley wrote: >>>>>>>> On 5/12/19 7:52 AM, Mimi Zohar wrote: >>>>>>>>> On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote: >>>>>>>>>> On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote: >>>>>>>>>>> This proposal consists in marshaling pathnames and xattrs in a file called >>>>>>>>>>> .xattr-list. They are unmarshaled by the CPIO parser after all files have >>>>>>>>>>> been extracted. >>>>>>>>>> >>>>>>>>>> Couldn't this parsing of the .xattr-list file and the setting of the xattrs >>>>>>>>>> be done equivalently by the initramfs' /init? Why is kernel involvement >>>>>>>>>> actually required here? >>>>>>>>> >>>>>>>>> It's too late. The /init itself should be signed and verified. >>>>>>>> >>>>>>>> If the initramfs cpio.gz image was signed and verified by the extractor, how is >>>>>>>> the init in it _not_ verified? >>>>>>>> >>>>>>>> Ro >>>>>>> >>>>>>> Wouldn't the below work even before enforcing signatures on external >>>>>>> initramfs: >>>>>>> 1. Create an embedded initramfs with an /init that does the xattr >>>>>>> parsing/setting. This will be verified as part of the kernel image >>>>>>> signature, so no new code required. >>>>>>> 2. Add a config option/boot parameter to panic the kernel if an external >>>>>>> initramfs attempts to overwrite anything in the embedded initramfs. This >>>>>>> prevents overwriting the embedded /init even if the external initramfs >>>>>>> is unverified. >>>>>> >>>>>> Unfortunately, it wouldn't work. IMA is already initialized and it would >>>>>> verify /init in the embedded initial ram disk. >>>>> >>>>> So you made broken infrastructure that's causing you problems. Sounds unfortunate. >>>> >>>> The idea is to be able to verify anything that is accessed, as soon as >>>> rootfs is available, without distinction between embedded or external >>>> initial ram disk. >>>> >>>> Also, requiring an embedded initramfs for xattrs would be an issue for >>>> systems that use it for other purposes. >>>> >>>> >>>>>> The only reason why >>>>>> opening .xattr-list works is that IMA is not yet initialized >>>>>> (late_initcall vs rootfs_initcall). >>>>> >>>>> Launching init before enabling ima is bad because... you didn't think of it? >>>> >>>> No, because /init can potentially compromise the integrity of the >>>> system. >>> >>> I think Rob is right here. If /init was statically built into the >>> kernel image, it has no more ability to compromise the kernel than >>> anything else in the kernel. What's the problem here? >> >> Right, the measurement/signature verification of the kernel image is >> sufficient. >> >> Now, assuming that we defer the IMA initialization until /init in the >> embedded initramfs has been executed, the problem is how to handle >> processes launched with the user mode helper or files directly read by >> the kernel (if it can happen before /init is executed). If IMA is not >> yet enabled, these operations will be performed without measurement and >> signature verification. > > If you really care about this, don't launch any user mode helper > programs (hint, you have the kernel option to control this and funnel > everything into one, or no, binaries). And don't allow the kernel to > read any files either, again, you have control over this. > > Or start IMA earlier if you need/want/care about this.
Yes, this is how it works now. It couldn't start earlier than late_initcall, as it has to wait until the TPM driver is initialized.
Anyway, it is enabled at the time /init is executed. And this would be an issue because launching /init and reading xattrs from /.xattr-list would be denied (the signature is missing).
And /.xattr-list won't have a signature, if initramfs is generated locally.
Roberto
-- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI
|  |