* Re: [Linux-ima-user] Initramfs and IMA Appraisal [not found] ` <5476EBAC.8090103@utc.fr> @ 2014-12-29 13:45 ` Mimi Zohar 2014-12-29 20:34 ` Rob Landley 0 siblings, 1 reply; 8+ messages in thread From: Mimi Zohar @ 2014-12-29 13:45 UTC (permalink / raw) To: Christophe Fillot Cc: linux-ima-user, Rob Landley, linux-security-module, linux-kernel On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote: > > > > Are you using an initrd not an initramfs? According to > > Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If > CONFIG_TMPFS > > is enabled, rootfs will use tmpfs instead of ramfs by default". > > > Yes, that what I thought too, but it seems that it is not really the > case because of this test: > > if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && > (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { > err = shmem_init(); > is_tmpfs = true; > } else { > err = init_ramfs_fs(); > } [CC'ing Rob Landley, lsm, lkml] Thanks! "saved_root_name" is set to the boot command line "root=" option, which in my case is the UUID. I'm not sure why real root should impact the initramfs tmpfs/ramfs decision. Unless there is a good explanation, did you want to post a patch to remove the test? Mimi ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-ima-user] Initramfs and IMA Appraisal 2014-12-29 13:45 ` [Linux-ima-user] Initramfs and IMA Appraisal Mimi Zohar @ 2014-12-29 20:34 ` Rob Landley 2014-12-29 21:46 ` Mimi Zohar 0 siblings, 1 reply; 8+ messages in thread From: Rob Landley @ 2014-12-29 20:34 UTC (permalink / raw) To: Mimi Zohar, Christophe Fillot Cc: linux-ima-user, linux-security-module, linux-kernel On 12/29/2014 07:45 AM, Mimi Zohar wrote: > On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote: >>> >>> Are you using an initrd not an initramfs? According to >>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If >> CONFIG_TMPFS >>> is enabled, rootfs will use tmpfs instead of ramfs by default". >>> >> Yes, that what I thought too, but it seems that it is not really the >> case because of this test: >> >> if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && >> (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { >> err = shmem_init(); >> is_tmpfs = true; >> } else { >> err = init_ramfs_fs(); >> } > > [CC'ing Rob Landley, lsm, lkml] > > Thanks! "saved_root_name" is set to the boot command line "root=" > option, which in my case is the UUID. I'm not sure why real root should > impact the initramfs tmpfs/ramfs decision. > > Unless there is a good explanation, did you want to post a patch to > remove the test? I added support last year, here's the start of the patch series: https://lkml.org/lkml/2013/6/29/101 The logic is that if you specify a fallback root via root=, then you're not staying on rootfs (that's what root= _means_, "here is the root filesystem the kernel is to mount over rootfs"), and thus the extra infrastructure for tmpfs instead of ramfs is unnecessary. I keep encountering people who set root=/dev/ram0 because they think that means initrd (it doesn't), and then they feed in a cpio archive (that's a third state even before you get to the ramfs/tmpfs distinction), and they always want to change the code to make what they asked it to do not be crazy... Possibly the documentation needs to elaborate, but I expect what we really need is a CONFIG_VERBOSE_ROOT_SETUP that sticks in a bunch of printfs so the /dev/console output explains what it's doing. ("could not exec /init out of initramfs (errno %d, file %s), falling back to root=\nAdd blather=1 to kernel cmdline to see cpio filenames/permissions.", and so on. Where "actual exec" shows where your dynamic linker is when that's what wasn't there.) Rob ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-ima-user] Initramfs and IMA Appraisal 2014-12-29 20:34 ` Rob Landley @ 2014-12-29 21:46 ` Mimi Zohar 2014-12-30 1:55 ` Rob Landley 2014-12-30 2:25 ` David Lang 0 siblings, 2 replies; 8+ messages in thread From: Mimi Zohar @ 2014-12-29 21:46 UTC (permalink / raw) To: Rob Landley Cc: Christophe Fillot, linux-ima-user, linux-security-module, linux-kernel On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote: > On 12/29/2014 07:45 AM, Mimi Zohar wrote: > > On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote: > >>> > >>> Are you using an initrd not an initramfs? According to > >>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If > >> CONFIG_TMPFS > >>> is enabled, rootfs will use tmpfs instead of ramfs by default". > >>> > >> Yes, that what I thought too, but it seems that it is not really the > >> case because of this test: > >> > >> if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && > >> (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { > >> err = shmem_init(); > >> is_tmpfs = true; > >> } else { > >> err = init_ramfs_fs(); > >> } > > > > [CC'ing Rob Landley, lsm, lkml] > > > > Thanks! "saved_root_name" is set to the boot command line "root=" > > option, which in my case is the UUID. I'm not sure why real root should > > impact the initramfs tmpfs/ramfs decision. > > > > Unless there is a good explanation, did you want to post a patch to > > remove the test? > > I added support last year, here's the start of the patch series: > > https://lkml.org/lkml/2013/6/29/101 > > The logic is that if you specify a fallback root via root=, then you're > not staying on rootfs (that's what root= _means_, "here is the root > filesystem the kernel is to mount over rootfs"), and thus the extra > infrastructure for tmpfs instead of ramfs is unnecessary. Thanks Rob for the explanation. The problem is that ramfs does not support extended attributes, while tmpfs does. The boot loader could "measure" (trusted boot) the initramfs, but as the initramfs is generated on the target system, the initramfs is not signed, preventing it from being appraised (secure Boot). To close the initramfs integrity appraisal gap requires verifying the individual initramfs file signatures, which are stored as extended attributes. > I keep encountering people who set root=/dev/ram0 because they think > that means initrd (it doesn't), and then they feed in a cpio archive > (that's a third state even before you get to the ramfs/tmpfs > distinction), and they always want to change the code to make what they > asked it to do not be crazy... > > Possibly the documentation needs to elaborate, but I expect what we > really need is a CONFIG_VERBOSE_ROOT_SETUP that sticks in a bunch of > printfs so the /dev/console output explains what it's doing. ("could not > exec /init out of initramfs (errno %d, file %s), falling back to > root=\nAdd blather=1 to kernel cmdline to see cpio > filenames/permissions.", and so on. Where "actual exec" shows where your > dynamic linker is when that's what wasn't there.) To add to the confusion Documentation/filesystems/ramfs-rootfs-initramfs.txt says, "If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by default." This statement should be modified to reflect the actual code. Mimi ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-ima-user] Initramfs and IMA Appraisal 2014-12-29 21:46 ` Mimi Zohar @ 2014-12-30 1:55 ` Rob Landley 2014-12-30 3:20 ` Mimi Zohar 2014-12-30 2:25 ` David Lang 1 sibling, 1 reply; 8+ messages in thread From: Rob Landley @ 2014-12-30 1:55 UTC (permalink / raw) To: Mimi Zohar Cc: Christophe Fillot, linux-ima-user, linux-security-module, linux-kernel On 12/29/2014 03:46 PM, Mimi Zohar wrote: > On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote: >> On 12/29/2014 07:45 AM, Mimi Zohar wrote: >>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote: >>>>> >>>>> Are you using an initrd not an initramfs? According to >>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If >>>> CONFIG_TMPFS >>>>> is enabled, rootfs will use tmpfs instead of ramfs by default". >>>>> >>>> Yes, that what I thought too, but it seems that it is not really the >>>> case because of this test: >>>> >>>> if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && >>>> (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { >>>> err = shmem_init(); >>>> is_tmpfs = true; >>>> } else { >>>> err = init_ramfs_fs(); >>>> } >>> >>> [CC'ing Rob Landley, lsm, lkml] >>> >>> Thanks! "saved_root_name" is set to the boot command line "root=" >>> option, which in my case is the UUID. I'm not sure why real root should >>> impact the initramfs tmpfs/ramfs decision. >>> >>> Unless there is a good explanation, did you want to post a patch to >>> remove the test? >> >> I added support last year, here's the start of the patch series: >> >> https://lkml.org/lkml/2013/6/29/101 >> >> The logic is that if you specify a fallback root via root=, then you're >> not staying on rootfs (that's what root= _means_, "here is the root >> filesystem the kernel is to mount over rootfs"), and thus the extra >> infrastructure for tmpfs instead of ramfs is unnecessary. > > Thanks Rob for the explanation. The problem is that ramfs does not > support extended attributes, while tmpfs does. If you're _using_ initramfs/initmpfs, there's no reason to specify a root=. > The boot loader could > "measure" (trusted boot) the initramfs, but as the initramfs is > generated on the target system, the initramfs is not signed, preventing > it from being appraised (secure Boot). To close the initramfs integrity > appraisal gap requires verifying the individual initramfs file > signatures, which are stored as extended attributes. Faced with the phrases "trusted boot" and "integrity appraisal", I plead the third. (In the wake of the Snowden infodump, people no longer want to use the elliptic curve cryptography the NSA designed, but they still happily base their system configuration on SELinux with a stack of thousands of rules you just have to take on faith. Possibly they're unaware the NSA designed and still maintains SELinux? Dunno...) >> Possibly the documentation needs to elaborate, but I expect what we >> really need is a CONFIG_VERBOSE_ROOT_SETUP that sticks in a bunch of >> printfs so the /dev/console output explains what it's doing. ("could not >> exec /init out of initramfs (errno %d, file %s), falling back to >> root=\nAdd blather=1 to kernel cmdline to see cpio >> filenames/permissions.", and so on. Where "actual exec" shows where your >> dynamic linker is when that's what wasn't there.) > > To add to the confusion > Documentation/filesystems/ramfs-rootfs-initramfs.txt says, "If > CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by > default." This statement should be modified to reflect the actual code. Actually I modified the code to reflect the documentation last year. (I wrote the docs in 2005, the initmpfs code in 2013.) The rootfs code _does_ use tmpfs by default. Specifying root= disables it, because it indicates you aren't using ramfs but are requesting the kernel overmount it with another filesystem before launching PID 1. That's what root= _means_. I can add a paragraph describing what root= means and that it's inappropriate to use it with ramfs in general? (And that root=/dev/ram0 is a nonsensical option despite what some bits of the internet seem to think.) > Mimi Rob ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-ima-user] Initramfs and IMA Appraisal 2014-12-30 1:55 ` Rob Landley @ 2014-12-30 3:20 ` Mimi Zohar 2014-12-30 4:17 ` Rob Landley 0 siblings, 1 reply; 8+ messages in thread From: Mimi Zohar @ 2014-12-30 3:20 UTC (permalink / raw) To: Rob Landley Cc: Christophe Fillot, linux-ima-user, linux-security-module, linux-kernel On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote: > > On 12/29/2014 03:46 PM, Mimi Zohar wrote: > > On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote: > >> On 12/29/2014 07:45 AM, Mimi Zohar wrote: > >>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote: > >>>>> > >>>>> Are you using an initrd not an initramfs? According to > >>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If > >>>> CONFIG_TMPFS > >>>>> is enabled, rootfs will use tmpfs instead of ramfs by default". > >>>>> > >>>> Yes, that what I thought too, but it seems that it is not really the > >>>> case because of this test: > >>>> > >>>> if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && > >>>> (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { > >>>> err = shmem_init(); > >>>> is_tmpfs = true; > >>>> } else { > >>>> err = init_ramfs_fs(); > >>>> } > >>> > >>> [CC'ing Rob Landley, lsm, lkml] > >>> > >>> Thanks! "saved_root_name" is set to the boot command line "root=" > >>> option, which in my case is the UUID. I'm not sure why real root should > >>> impact the initramfs tmpfs/ramfs decision. > >>> > >>> Unless there is a good explanation, did you want to post a patch to > >>> remove the test? > >> > >> I added support last year, here's the start of the patch series: > >> > >> https://lkml.org/lkml/2013/6/29/101 > >> > >> The logic is that if you specify a fallback root via root=, then you're > >> not staying on rootfs (that's what root= _means_, "here is the root > >> filesystem the kernel is to mount over rootfs"), and thus the extra > >> infrastructure for tmpfs instead of ramfs is unnecessary. > > > > Thanks Rob for the explanation. The problem is that ramfs does not > > support extended attributes, while tmpfs does. > > If you're _using_ initramfs/initmpfs, there's no reason to specify a root=. The menu entry looks like: linux /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f ro ... initrd /initramfs-3.17.0+.img Because "root=" is specified, rootfs is not using tmpfs. > > The boot loader could > > "measure" (trusted boot) the initramfs, but as the initramfs is > > generated on the target system, the initramfs is not signed, preventing > > it from being appraised (secure Boot). To close the initramfs integrity > > appraisal gap requires verifying the individual initramfs file > > signatures, which are stored as extended attributes. > > Faced with the phrases "trusted boot" and "integrity appraisal", I plead > the third. Fine. Bottom line, rootfs needs to support extended attributes. > (In the wake of the Snowden infodump, All the more reason to allow only those files that are properly signed to be read/executed. Mimi ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-ima-user] Initramfs and IMA Appraisal 2014-12-30 3:20 ` Mimi Zohar @ 2014-12-30 4:17 ` Rob Landley 0 siblings, 0 replies; 8+ messages in thread From: Rob Landley @ 2014-12-30 4:17 UTC (permalink / raw) To: Mimi Zohar Cc: Christophe Fillot, linux-ima-user, linux-security-module, linux-kernel On 12/29/2014 09:20 PM, Mimi Zohar wrote: > On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote: >>> Thanks Rob for the explanation. The problem is that ramfs does not >>> support extended attributes, while tmpfs does. >> >> If you're _using_ initramfs/initmpfs, there's no reason to specify a root=. > > The menu entry looks like: > linux /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f > ro ... > initrd /initramfs-3.17.0+.img > > Because "root=" is specified, rootfs is not using tmpfs. Yes. Pilot error. If you want tmpfs to switch to UUID $THINGY you can do ROOT= and have it use that. You're asking for something to be interpreted by the kernel sometimes and passed on to userspace other times and have no side effects even though it's interpeted by the kernel. >>> The boot loader could >>> "measure" (trusted boot) the initramfs, but as the initramfs is >>> generated on the target system, the initramfs is not signed, preventing >>> it from being appraised (secure Boot). To close the initramfs integrity >>> appraisal gap requires verifying the individual initramfs file >>> signatures, which are stored as extended attributes. >> >> Faced with the phrases "trusted boot" and "integrity appraisal", I plead >> the third. > > Fine. Bottom line, rootfs needs to support extended attributes. I added a patch to make it work as tmpfs a year ago. You now know what trivial configuration mistake you make that's preventing it from working. If you'd like me to submit a documentation update patch to make it easier to avoid in future, I can do that. >> (In the wake of the Snowden infodump, > > All the more reason to allow only those files that are properly signed > to be read/executed. Using the infrastructure the NSA provided, which is intentionally so complicated that "you are not expected to understand this". Good luck with that. > Mimi Rob ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-ima-user] Initramfs and IMA Appraisal 2014-12-29 21:46 ` Mimi Zohar 2014-12-30 1:55 ` Rob Landley @ 2014-12-30 2:25 ` David Lang 2014-12-30 3:06 ` Mimi Zohar 1 sibling, 1 reply; 8+ messages in thread From: David Lang @ 2014-12-30 2:25 UTC (permalink / raw) To: Mimi Zohar Cc: Rob Landley, Christophe Fillot, linux-ima-user, linux-security-module, linux-kernel On Mon, 29 Dec 2014, Mimi Zohar wrote: > Thanks Rob for the explanation. The problem is that ramfs does not > support extended attributes, while tmpfs does. The boot loader could > "measure" (trusted boot) the initramfs, but as the initramfs is > generated on the target system, the initramfs is not signed, preventing > it from being appraised (secure Boot). To close the initramfs integrity > appraisal gap requires verifying the individual initramfs file > signatures, which are stored as extended attributes. what's the point of checking the files on the filesystem against signatures stored on the same filesystem? If someone could alter the file contents they can alter the signatures as well. David Lang ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-ima-user] Initramfs and IMA Appraisal 2014-12-30 2:25 ` David Lang @ 2014-12-30 3:06 ` Mimi Zohar 0 siblings, 0 replies; 8+ messages in thread From: Mimi Zohar @ 2014-12-30 3:06 UTC (permalink / raw) To: David Lang Cc: Rob Landley, Christophe Fillot, linux-ima-user, linux-security-module, linux-kernel On Mon, 2014-12-29 at 18:25 -0800, David Lang wrote: > On Mon, 29 Dec 2014, Mimi Zohar wrote: > > > Thanks Rob for the explanation. The problem is that ramfs does not > > support extended attributes, while tmpfs does. The boot loader could > > "measure" (trusted boot) the initramfs, but as the initramfs is > > generated on the target system, the initramfs is not signed, preventing > > it from being appraised (secure Boot). To close the initramfs integrity > > appraisal gap requires verifying the individual initramfs file > > signatures, which are stored as extended attributes. > > what's the point of checking the files on the filesystem against signatures > stored on the same filesystem? If someone could alter the file contents they can > alter the signatures as well. It's all about limiting which public keys can be used to verify the file signatures. As of 3.17, only keys signed by a "trusted" key on the system keyring may be added to the IMA keyring. Mimi ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-12-30 4:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <5463ABC8.10308@utc.fr>
[not found] ` <1415827252.18773.33.camel@dhcp-9-2-203-236.watson.ibm.com>
[not found] ` <547617AF.6000604@utc.fr>
[not found] ` <1417039941.26016.46.camel@dhcp-9-2-203-236.watson.ibm.com>
[not found] ` <5476EBAC.8090103@utc.fr>
2014-12-29 13:45 ` [Linux-ima-user] Initramfs and IMA Appraisal Mimi Zohar
2014-12-29 20:34 ` Rob Landley
2014-12-29 21:46 ` Mimi Zohar
2014-12-30 1:55 ` Rob Landley
2014-12-30 3:20 ` Mimi Zohar
2014-12-30 4:17 ` Rob Landley
2014-12-30 2:25 ` David Lang
2014-12-30 3:06 ` Mimi Zohar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.