Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote: > On 12/25/15 at 09:45am, Mimi Zohar wrote: > > IMA calculates the file hash, in this case, based on the buffer > > contents. The hash is calculated once and used for both measurement > > and appraisal. If the file integrity appraisal fails (eg. hash > > comparison or signature failure), IMA prevents the kexec files from > > being used. > > > > Ok, thanks for the explanatioin. But I have another question, why do we > need a special hook for KEXEC? Shouldn't all files use same way to do the > measurement and appraisal? "By all files" are you referring to all files read by the kernel or all files opened, executed or mmapped by the system? Currently IMA allocates a page sized buffer, reads a file a page chunk at a time calculating the file hash as it does so, and then frees the buffer before returning to the caller. This method of calculating the file hash is used for measuring and appraising files opened (FILE_CHECK), executed (BPRM_CHECK) or mmapped (MMAP_CHECK) by the system. This patch set addresses files being read by kernel. A single new generic hook named ima_hash_and_process_file() is defined to not only measure and appraise the kexec image and initramfs, but firmware and the IMA policy. As we identify other places that the kernel is reading files, this hook would be called in those places as well. Mimi -- 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
Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote: > On 12/25/15 at 09:45am, Mimi Zohar wrote: > > IMA calculates the file hash, in this case, based on the buffer > > contents. The hash is calculated once and used for both measurement > > and appraisal. If the file integrity appraisal fails (eg. hash > > comparison or signature failure), IMA prevents the kexec files from > > being used. > > > > Ok, thanks for the explanatioin. But I have another question, why do we > need a special hook for KEXEC? Shouldn't all files use same way to do the > measurement and appraisal? "By all files" are you referring to all files read by the kernel or all files opened, executed or mmapped by the system? Currently IMA allocates a page sized buffer, reads a file a page chunk at a time calculating the file hash as it does so, and then frees the buffer before returning to the caller. This method of calculating the file hash is used for measuring and appraising files opened (FILE_CHECK), executed (BPRM_CHECK) or mmapped (MMAP_CHECK) by the system. This patch set addresses files being read by kernel. A single new generic hook named ima_hash_and_process_file() is defined to not only measure and appraise the kexec image and initramfs, but firmware and the IMA policy. As we identify other places that the kernel is reading files, this hook would be called in those places as well. Mimi -- 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
Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On 15-12-28 07:51:15, Mimi Zohar wrote: > On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote: > > On 12/25/15 at 09:45am, Mimi Zohar wrote: > > > IMA calculates the file hash, in this case, based on the buffer > > > contents. The hash is calculated once and used for both measurement > > > and appraisal. If the file integrity appraisal fails (eg. hash > > > comparison or signature failure), IMA prevents the kexec files from > > > being used. > > > > > > > Ok, thanks for the explanatioin. But I have another question, why do we > > need a special hook for KEXEC? Shouldn't all files use same way to do the > > measurement and appraisal? > > "By all files" are you referring to all files read by the kernel or all > files opened, executed or mmapped by the system? > > Currently IMA allocates a page sized buffer, reads a file a page chunk > at a time calculating the file hash as it does so, and then frees the > buffer before returning to the caller. This method of calculating the I kind of wonder isn't it possible to optimize the file read? If the file is relatively small (a few megabytes, for example) it will fit into any modern system's memory. At least those that cares to run IMA, i mean. Fetching file page by page is a slow process even though the BIO subsystem reads larger chunks off the real storage devices. Has anyone done a benchmark test? cheers, Petko -- 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
Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On Mon, 2015-12-28 at 16:29 +0200, Petko Manolov wrote: > On 15-12-28 07:51:15, Mimi Zohar wrote: > > On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote: > > > On 12/25/15 at 09:45am, Mimi Zohar wrote: > > > > IMA calculates the file hash, in this case, based on the buffer > > > > contents. The hash is calculated once and used for both measurement > > > > and appraisal. If the file integrity appraisal fails (eg. hash > > > > comparison or signature failure), IMA prevents the kexec files from > > > > being used. > > > > > > > > > > Ok, thanks for the explanatioin. But I have another question, why do we > > > need a special hook for KEXEC? Shouldn't all files use same way to do the > > > measurement and appraisal? > > > > "By all files" are you referring to all files read by the kernel or all > > files opened, executed or mmapped by the system? > > > > Currently IMA allocates a page sized buffer, reads a file a page chunk > > at a time calculating the file hash as it does so, and then frees the > > buffer before returning to the caller. This method of calculating the > > I kind of wonder isn't it possible to optimize the file read? If the file is > relatively small (a few megabytes, for example) it will fit into any modern > system's memory. At least those that cares to run IMA, i mean. > > Fetching file page by page is a slow process even though the BIO subsystem > reads > larger chunks off the real storage devices. Has anyone done a benchmark test? Dmitry recently added asynchronous hash (ahash) support, which allows HW crypto acceleration, for calculating the file hash. Mimi -- 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
Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On 15-12-28 09:42:22, Mimi Zohar wrote: > On Mon, 2015-12-28 at 16:29 +0200, Petko Manolov wrote: > > > > I kind of wonder isn't it possible to optimize the file read? If the file > > is relatively small (a few megabytes, for example) it will fit into any > > modern system's memory. At least those that cares to run IMA, i mean. > > > > Fetching file page by page is a slow process even though the BIO subsystem > > reads larger chunks off the real storage devices. Has anyone done a > > benchmark test? > > Dmitry recently added asynchronous hash (ahash) support, which allows HW > crypto acceleration, for calculating the file hash. This is nice. However, i was referring to reading a file page by page vs larger (a couple of megabytes) chunks. Is this also covered by the ahash support? cheers, Petko -- 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
Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On Mon, 2015-12-28 at 16:59 +0200, Petko Manolov wrote: > On 15-12-28 09:42:22, Mimi Zohar wrote: > > On Mon, 2015-12-28 at 16:29 +0200, Petko Manolov wrote: > > > > > > I kind of wonder isn't it possible to optimize the file read? If the > > > file > > > is relatively small (a few megabytes, for example) it will fit into any > > > modern system's memory. At least those that cares to run IMA, i mean. > > > > > > Fetching file page by page is a slow process even though the BIO > > > subsystem > > > reads larger chunks off the real storage devices. Has anyone done a > > > benchmark test? > > > > Dmitry recently added asynchronous hash (ahash) support, which allows HW > > crypto acceleration, for calculating the file hash. > > This is nice. However, i was referring to reading a file page by page vs > larger > (a couple of megabytes) chunks. Is this also covered by the ahash support? Yes, basically it attempts to allocate a buffer for the entire file. On failure, ahash attempts to allocate two buffers larger than PAGE_SIZE, but falls back to using just PAGE_SIZE. Refer to ima_alloc_pages() for a full description. When two buffers are allocated, while waiting for one hash to complete, the subsequent file read is read into the other buffer. Mimi -- 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
Donation/Charity
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- 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
