Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/20/2012 08:18 PM, Lennart Poettering wrote: On Mon, 20.02.12 20:06, Roberto Sassu (roberto.sa...@polito.it) wrote: We moved SELinux loading out of the initrd into systemd, in order to support fully featured initrd-less boots. I don't think we should reopen this problem set by having IMA in the initrd. I believe IMA should be treated pretty much exactly like SELinux here: the policy should be loaded from PID1 and it needs to be a compile time option, and it needs a kernel cmdline option to disable it (i.e. like selinux=0). If the SELinux module in dracut is to be considered definitively broken probably also the IMA module should be removed, because it will not be possible to load policies with LSM rules. But i don't know how this feature can be supported by distributions without Systemd installed. Well, if the rumours I keep hearing are true Ubuntu might join the systemd camp too after their LTS release. Maybe the supporting non-systemd systems issues solves itself by that for you? The code for loading IMA custom policies was placed in the initial ramdisk with the purpose to avoid distribution specific dependencies. However, since the SELinux initialization has been moved to Systemd and Systemd itself will be used by the major distributions, i think placing the IMA code here is the best solution, even if it is not the most general. Regarding the kernel option, actually there is no a specific parameter to disable IMA. However, it can be introduced in the patches proposed by Mimi Zohar about the 'ima-appraisal' feature. This can allow to disable IMA or to put it in permissive/enforce mode as it happens for example in SELinux. Whether there is a kernel option to enable/disable IMA will not stop these patches from getting into systemd. But I am quite sure they will stop IMA from getting any wider coverage in the mainstream distributions (if you care for that). Actually, IMA doesn't take any action if the policy is not provided nor it consumes additional system resources. Further, in the current implementation, even if IMA measures files it does not return any error to the system call being executed. Oh, and one more thing: it matters to me that this doesn't break my build. So it needs to allow me booting when enabled in configure, but without any IMA policy around. Ok. this should be not a problem because all errors (IMA support not included in the kernel, policy file access denied, ...) are ignored except for the mmap() failure. Thanks Roberto Sassu Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Mon, 2012-02-20 at 20:18 +0100, Lennart Poettering wrote: On Mon, 20.02.12 20:06, Roberto Sassu (roberto.sa...@polito.it) wrote: We moved SELinux loading out of the initrd into systemd, in order to support fully featured initrd-less boots. I don't think we should reopen this problem set by having IMA in the initrd. I believe IMA should be treated pretty much exactly like SELinux here: the policy should be loaded from PID1 and it needs to be a compile time option, and it needs a kernel cmdline option to disable it (i.e. like selinux=0). If the SELinux module in dracut is to be considered definitively broken probably also the IMA module should be removed, because it will not be possible to load policies with LSM rules. But i don't know how this feature can be supported by distributions without Systemd installed. Well, if the rumours I keep hearing are true Ubuntu might join the systemd camp too after their LTS release. Maybe the supporting non-systemd systems issues solves itself by that for you? Regarding the kernel option, actually there is no a specific parameter to disable IMA. However, it can be introduced in the patches proposed by Mimi Zohar about the 'ima-appraisal' feature. This can allow to disable IMA or to put it in permissive/enforce mode as it happens for example in SELinux. Whether there is a kernel option to enable/disable IMA will not stop these patches from getting into systemd. But I am quite sure they will stop IMA from getting any wider coverage in the mainstream distributions (if you care for that). Really? The original IMA patch set defined CONFIG_IMA_BOOTPARAM and CONFIG_IMA_BOOTPARAM_VALUE, but based on the lkml discussion, I removed support for them. (May 2008) In lieu of a switch to enable/disable IMA, the default measurement policy is null, so that nothing is measured, unless 'ima_tcb' is provided on the boot command line. Oh, and one more thing: it matters to me that this doesn't break my build. So it needs to allow me booting when enabled in configure, but without any IMA policy around. Lennart Of course IMA should work with/without updating the measurement policy. thanks, Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Tue, 2012-02-21 at 11:05 +0100, Roberto Sassu wrote: Ok. this should be not a problem because all errors (IMA support not included in the kernel, policy file access denied, ...) are ignored except for the mmap() failure. Hi Roberto, IMA should never return an error, only IMA-appraisal should enforce file integrity. Can you please show me or send a patch? thanks, Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/21/2012 02:01 PM, Mimi Zohar wrote: On Tue, 2012-02-21 at 11:05 +0100, Roberto Sassu wrote: Ok. this should be not a problem because all errors (IMA support not included in the kernel, policy file access denied, ...) are ignored except for the mmap() failure. Hi Roberto, IMA should never return an error, only IMA-appraisal should enforce file integrity. Can you please show me or send a patch? Hi Mimi do you intend a patch to reintroduce the 'ima=' kernel parameter for enabling/disabling IMA? If so, i have not actually thought about this but it should be not difficult to implement. Probably we can support these modes: - disabled: IMA returns immediately to the system call; - measure_only: IMA performs only measurements and does not return any error to the system call; - appraise_permissive: IMA stores measurements in the files extended attribute and in the measurements list but does not return any error to the system call even if the integrity check fails; - appraise_enforce: IMA does the same as the previous mode but returns an error to the system call if the integrity check fails. Further, we can have a simple user-space package which will contain the documentation about how to write a policy (so that it will be more easy to find in respect to the whole kernel documentation) and a tool that will fix/verify the measurements stored in the files extended attribute. Having a separate user-space package will simplify the interaction for users with the IMA kernel-space portion and will allow to determine whether the IMA support should be enabled in Systemd. Thanks Roberto Sassu thanks, Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Tue, Feb 21, 2012 at 15:07, Colin Guthrie gm...@colin.guthr.ie wrote: The code for loading IMA custom policies was placed in the initial ramdisk with the purpose to avoid distribution specific dependencies. However, since the SELinux initialization has been moved to Systemd and Systemd itself will be used by the major distributions, i think placing the IMA code here is the best solution, even if it is not the most general. Just for reference, not all distros use the same initrd generator anyway. We're trying to move to dracut, but it's certainly not universal at the moment. I think Suse use something else (maybe they plan to move to dracut too?) and I've no idea about Ubuntu but I doubt they use dracut. So I'd suggest that at the moment, systemd will actually get you wider coverage... although that's just a slightly ill-informed and hand-wave analysis on my part. Either way, I think it's better in systemd :D Sounds right. The initramfs is definitely less generic than systemd is. Almost every distro has still its own here. The situation today with initramfs generators can probably not get more distro-specific; it is still almost at its maximum. :) So the thinking of moving anything to the initramfs to avoid the Linux distro balcanization problem will usually not work out. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Tue, 2012-02-21 at 15:32 +0100, Kay Sievers wrote: On Tue, Feb 21, 2012 at 15:07, Colin Guthrie gm...@colin.guthr.ie wrote: The code for loading IMA custom policies was placed in the initial ramdisk with the purpose to avoid distribution specific dependencies. In a trusted-grub, or equivalent environment, the kernel, initramfs, and kernel boot options are measured. The main reason for loading the IMA policy in the initramfs was that the policy would be included in the initramfs measurement. Mimi However, since the SELinux initialization has been moved to Systemd and Systemd itself will be used by the major distributions, i think placing the IMA code here is the best solution, even if it is not the most general. Just for reference, not all distros use the same initrd generator anyway. We're trying to move to dracut, but it's certainly not universal at the moment. I think Suse use something else (maybe they plan to move to dracut too?) and I've no idea about Ubuntu but I doubt they use dracut. So I'd suggest that at the moment, systemd will actually get you wider coverage... although that's just a slightly ill-informed and hand-wave analysis on my part. Either way, I think it's better in systemd :D Sounds right. The initramfs is definitely less generic than systemd is. Almost every distro has still its own here. The situation today with initramfs generators can probably not get more distro-specific; it is still almost at its maximum. :) So the thinking of moving anything to the initramfs to avoid the Linux distro balcanization problem will usually not work out. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Tue, 2012-02-21 at 14:58 +0100, Roberto Sassu wrote: Hi Mimi do you intend a patch to reintroduce the 'ima=' kernel parameter for enabling/disabling IMA? If so, i have not actually thought about this but it should be not difficult to implement. Probably we can support these modes: I'm not sure. There was a lot of complaint way back when. Before re-introducing it, I'd prefer to hear from others how they feel. - disabled: IMA returns immediately to the system call; Today this is done by booting with a null policy. - measure_only: IMA performs only measurements and does not return any error to the system call; Booting with a policy, will achieve this result. - appraise_permissive: IMA stores measurements in the files extended attribute and in the measurements list but does not return any error to the system call even if the integrity check fails; IMA and IMA-appraisal are different features and should not be combined. Currently, one can be enabled without the other. For example, some may only want the measurement list, while others may only want integrity enforcement. - appraise_enforce: IMA does the same as the previous mode but returns an error to the system call if the integrity check fails. ima_appraise= enabled | fix | off are currently supported. Further, we can have a simple user-space package which will contain the documentation about how to write a policy (so that it will be more easy to find in respect to the whole kernel documentation) and a tool that will fix/verify the measurements stored in the files extended attribute. Having a separate user-space package will simplify the interaction for users with the IMA kernel-space portion and will allow to determine whether the IMA support should be enabled in Systemd. Having a Systemd config file wouldn't change the need for the existing boot command line options. None of them can or should go away, since IMA must start measuring before any files are accessed, including the config and policy files, otherwise the chain of trust would be lost. thanks, Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/21/2012 05:15 PM, Mimi Zohar wrote: On Tue, 2012-02-21 at 14:58 +0100, Roberto Sassu wrote: Hi Mimi do you intend a patch to reintroduce the 'ima=' kernel parameter for enabling/disabling IMA? If so, i have not actually thought about this but it should be not difficult to implement. Probably we can support these modes: I'm not sure. There was a lot of complaint way back when. Before re-introducing it, I'd prefer to hear from others how they feel. Ok, it is better to wait until this point becomes clear. - disabled: IMA returns immediately to the system call; Today this is done by booting with a null policy. I think 'disabled' would mean that the hooks implementation should consist only in a immediate return without the execution of any specific code (in the IMA case, the function ima_must_measure()). Probably it is a good idea to allow to completely disable IMA at runtime. - measure_only: IMA performs only measurements and does not return any error to the system call; Booting with a policy, will achieve this result. The purpose of the 'ima=' kernel parameter can be also to select the IMA features to be enabled at runtime. So, to avoid confusion, we can use it to disable all features, to enable the measure or appraise capabilities or both. Then, we can keep the existing 'ima_appraise=' parameter while defining the values 'permissive' and 'enforcing'. - appraise_permissive: IMA stores measurements in the files extended attribute and in the measurements list but does not return any error to the system call even if the integrity check fails; IMA and IMA-appraisal are different features and should not be combined. Currently, one can be enabled without the other. For example, some may only want the measurement list, while others may only want integrity enforcement. Maybe both can be useful. For example, the appraise feature allows to detect if a file has been tampered with while the measurement feature allows verifiers to determine if the value stored can be considered good or not. - appraise_enforce: IMA does the same as the previous mode but returns an error to the system call if the integrity check fails. ima_appraise= enabled | fix | off are currently supported. Further, we can have a simple user-space package which will contain the documentation about how to write a policy (so that it will be more easy to find in respect to the whole kernel documentation) and a tool that will fix/verify the measurements stored in the files extended attribute. Having a separate user-space package will simplify the interaction for users with the IMA kernel-space portion and will allow to determine whether the IMA support should be enabled in Systemd. Having a Systemd config file wouldn't change the need for the existing boot command line options. None of them can or should go away, since IMA must start measuring before any files are accessed, including the config and policy files, otherwise the chain of trust would be lost. I meant we can create a new package called for example 'ima-utils' that can be used by Systemd to determine, at compile time, whether the IMA support for loading custom policies should be enabled or not. At runtime, Systemd could inspect the kernel command line looking for IMA-related parameters (this solution is actually not available) or, as implemented in my patch, it will only check for the presence of the policy file in the default location. This file will be measured by the boot loader, together with the Systemd main executable, to preserve the chain of trust. Thanks Roberto Sassu thanks, Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Tue, Feb 21, 2012 at 18:32, Roberto Sassu roberto.sa...@polito.it wrote: I meant we can create a new package called for example 'ima-utils' that can be used by Systemd to determine, at compile time, whether the IMA support for loading custom policies should be enabled or not. That's not needed. There is no problem enabling ima support conditionally in ./configure. Build systems are unlikely to install ima in the buildroot anyway, when there is no library or anything to link against, so auto-detection is not really useful. A default to off and requiring an explicit enable sounds sufficient here. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
Hi Roberto, The only package we have at the moment is Dmitry Kasatkin's evm-utils git://linux-ima.git.sourceforge.net/gitroot/linux-ima/evm-utils used for labeling the filesystem with security.evm/security.ima digital signatures. There's still a lot left to do, but we've started updating the linux-ima Wiki: https://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page thanks, Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/21/2012 06:56 PM, Kay Sievers wrote: On Tue, Feb 21, 2012 at 18:32, Roberto Sassuroberto.sa...@polito.it wrote: I meant we can create a new package called for example 'ima-utils' that can be used by Systemd to determine, at compile time, whether the IMA support for loading custom policies should be enabled or not. That's not needed. There is no problem enabling ima support conditionally in ./configure. Build systems are unlikely to install ima in the buildroot anyway, when there is no library or anything to link against, so auto-detection is not really useful. A default to off and requiring an explicit enable sounds sufficient here. Hi Kay ok, that was because Systemd also checks for the presence of libselinux in order to enable the SELinux support. I will introduce in the next version of the patches only the new configure parameter '--enable_ima' without additional checks. Thanks Roberto Sassu Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/21/2012 05:14 PM, Mimi Zohar wrote: On Tue, 2012-02-21 at 15:32 +0100, Kay Sievers wrote: On Tue, Feb 21, 2012 at 15:07, Colin Guthriegm...@colin.guthr.ie wrote: The code for loading IMA custom policies was placed in the initial ramdisk with the purpose to avoid distribution specific dependencies. In a trusted-grub, or equivalent environment, the kernel, initramfs, and kernel boot options are measured. The main reason for loading the IMA policy in the initramfs was that the policy would be included in the initramfs measurement. Unfortunately not, the policy file is placed in the root filesystem. However, since trusted-grub supports the measurement of an user-defined list of files, it is possible to preserve the chain of trust by measuring the policy file and the Systemd main executable. Roberto Sassu Mimi However, since the SELinux initialization has been moved to Systemd and Systemd itself will be used by the major distributions, i think placing the IMA code here is the best solution, even if it is not the most general. Just for reference, not all distros use the same initrd generator anyway. We're trying to move to dracut, but it's certainly not universal at the moment. I think Suse use something else (maybe they plan to move to dracut too?) and I've no idea about Ubuntu but I doubt they use dracut. So I'd suggest that at the moment, systemd will actually get you wider coverage... although that's just a slightly ill-informed and hand-wave analysis on my part. Either way, I think it's better in systemd :D Sounds right. The initramfs is definitely less generic than systemd is. Almost every distro has still its own here. The situation today with initramfs generators can probably not get more distro-specific; it is still almost at its maximum. :) So the thinking of moving anything to the initramfs to avoid the Linux distro balcanization problem will usually not work out. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Tue, Feb 21, 2012 at 19:07, Roberto Sassu roberto.sa...@polito.it wrote: On 02/21/2012 06:56 PM, Kay Sievers wrote: ok, that was because Systemd also checks for the presence of libselinux in order to enable the SELinux support. Yeah, systemd provides a shared lib which we need to link against, hence the systemd is needed at build time, and needs to be in the buildroot and we can do the auto-detect here. If ima will ever need a shared lib or other files at build time, we can change that. I will introduce in the next version of the patches only the new configure parameter '--enable_ima' without additional checks. Sounds good. Options are usually a ll dashes not underscores, you can check the current ones with ./configure --help. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, 16.02.12 15:56, Michael Cassaniti (m.cassan...@gmail.com) wrote: Also, I certainly have no such things in my system and see no point in calling ima_setup() on it. Or even compiling the source file in such case. Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA' statement, as it happens for SELinux. However an issue is that there is no a specific package for IMA that can be checked to set the HAVE_IMA definition to yes. Instead, the code can be enabled for example by adding the parameter '--enable_ima' in the configure script. okay. I'm under the impression this function belongs to a userspace tool. If not then I just don't see a good reason that this patch is required. I do understand that the IMA policy should be loaded as early as possible, but I believe that early userspace scripts should be doing that work. If it is a userspace function, then whatever makes you happy, other distro's will roll their own. in systemd, bootup is fully parallelized. I much prefer invoking the IMA policy at the right time, before we spawn off the first processes, instead of having to express that with dependencies towards all units. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, 16.02.12 12:30, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: Since the policy loading can be implemented in different ways depending on the init system (systemd, upstart, ...), an user must identify the components to be measured for each case. Instead, if the IMA policy is loaded in the main Systemd executable, only this file must be measured by the boot loader. Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. We worked really hard on being able to load the SELinux policy without any unnecessary (re-)execs. I don't think we should reopen that problem by loading IMA from a pre-init tool. Also, the management of such a thing would seriously suck (i.e. you'd probably need something like update-alternatives, and that sucks), especially since we now already taught the initrd to spawn /usr/lib/systemd/systemd directly, instead of /sbin/init. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, 16.02.12 19:50, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. This does not work because SELinux is initialized inside Systemd and IMA requires it for parsing LSM rules in the policy. initramfs may do it as well, no? then systemd will inherit it. We moved SELinux loading out of the initrd into systemd, in order to support fully featured initrd-less boots. I don't think we should reopen this problem set by having IMA in the initrd. I believe IMA should be treated pretty much exactly like SELinux here: the policy should be loaded from PID1 and it needs to be a compile time option, and it needs a kernel cmdline option to disable it (i.e. like selinux=0). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, 16.02.12 15:40, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Thu, Feb 16, 2012 at 12:30:31PM -0200, Gustavo Sverzut Barbieri wrote: On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassu roberto.sa...@polito.it wrote: the reason for which the loading of IMA policies has been placed in the main Systemd executable is that the measurement process performed by IMA should start as early as possible. Otherwise, in order to build the 'chain of trust' during the boot process from the BIOS to software applications, it is required to measure those components loaded before IMA is initialized with other means (for example from the boot loader). Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. Isn't that a job for initramfs? We support booting without initramfs in systemd. SELinux/IMA should be available for those systems, too. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/20/2012 06:24 PM, Lennart Poettering wrote: On Thu, 16.02.12 19:50, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. This does not work because SELinux is initialized inside Systemd and IMA requires it for parsing LSM rules in the policy. initramfs may do it as well, no? then systemd will inherit it. We moved SELinux loading out of the initrd into systemd, in order to support fully featured initrd-less boots. I don't think we should reopen this problem set by having IMA in the initrd. I believe IMA should be treated pretty much exactly like SELinux here: the policy should be loaded from PID1 and it needs to be a compile time option, and it needs a kernel cmdline option to disable it (i.e. like selinux=0). If the SELinux module in dracut is to be considered definitively broken probably also the IMA module should be removed, because it will not be possible to load policies with LSM rules. But i don't know how this feature can be supported by distributions without Systemd installed. Regarding the kernel option, actually there is no a specific parameter to disable IMA. However, it can be introduced in the patches proposed by Mimi Zohar about the 'ima-appraisal' feature. This can allow to disable IMA or to put it in permissive/enforce mode as it happens for example in SELinux. Thanks Roberto Sassu Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Mon, 20.02.12 20:06, Roberto Sassu (roberto.sa...@polito.it) wrote: We moved SELinux loading out of the initrd into systemd, in order to support fully featured initrd-less boots. I don't think we should reopen this problem set by having IMA in the initrd. I believe IMA should be treated pretty much exactly like SELinux here: the policy should be loaded from PID1 and it needs to be a compile time option, and it needs a kernel cmdline option to disable it (i.e. like selinux=0). If the SELinux module in dracut is to be considered definitively broken probably also the IMA module should be removed, because it will not be possible to load policies with LSM rules. But i don't know how this feature can be supported by distributions without Systemd installed. Well, if the rumours I keep hearing are true Ubuntu might join the systemd camp too after their LTS release. Maybe the supporting non-systemd systems issues solves itself by that for you? Regarding the kernel option, actually there is no a specific parameter to disable IMA. However, it can be introduced in the patches proposed by Mimi Zohar about the 'ima-appraisal' feature. This can allow to disable IMA or to put it in permissive/enforce mode as it happens for example in SELinux. Whether there is a kernel option to enable/disable IMA will not stop these patches from getting into systemd. But I am quite sure they will stop IMA from getting any wider coverage in the mainstream distributions (if you care for that). Oh, and one more thing: it matters to me that this doesn't break my build. So it needs to allow me booting when enabled in configure, but without any IMA policy around. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 16/02/2012 04:12, Roberto Sassu wrote: On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassuroberto.sa...@polito.it wrote: The new function ima_setup() loads an IMA custom policy from a file in the default location '/etc/sysconfig/ima-policy', if present, and writes it to isn't /etc/sysconfig too specific to Fedora? Hi Gustavo probably yes. I see the code in 'src/locale-setup.c' where the the configuration directory depends on the target distribution. I can implement something like that in my patch. Can't IMA be changed? Lennart seems to be pushing for distribution independent location files. If you can get IMA people to agree on something, just use this one instead. People that use IMA with systemd must use this location. Eventually this will happen with every configuration file we support. The location of the policy file is not IMA dependent. I chose that because it seemed to me the right place where to put this file. So, i can easily modify the location to be distribution independent but i don't known which directory would be appropriate. Any proposal? Regards Roberto Sassu Also, I certainly have no such things in my system and see no point in calling ima_setup() on it. Or even compiling the source file in such case. Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA' statement, as it happens for SELinux. However an issue is that there is no a specific package for IMA that can be checked to set the HAVE_IMA definition to yes. Instead, the code can be enabled for example by adding the parameter '--enable_ima' in the configure script. okay. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I'm under the impression this function belongs to a userspace tool. If not then I just don't see a good reason that this patch is required. I do understand that the IMA policy should be loaded as early as possible, but I believe that early userspace scripts should be doing that work. If it is a userspace function, then whatever makes you happy, other distro's will roll their own. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/16/2012 05:56 AM, Michael Cassaniti wrote: On 16/02/2012 04:12, Roberto Sassu wrote: On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassuroberto.sa...@polito.it wrote: The new function ima_setup() loads an IMA custom policy from a file in the default location '/etc/sysconfig/ima-policy', if present, and writes it to isn't /etc/sysconfig too specific to Fedora? Hi Gustavo probably yes. I see the code in 'src/locale-setup.c' where the the configuration directory depends on the target distribution. I can implement something like that in my patch. Can't IMA be changed? Lennart seems to be pushing for distribution independent location files. If you can get IMA people to agree on something, just use this one instead. People that use IMA with systemd must use this location. Eventually this will happen with every configuration file we support. The location of the policy file is not IMA dependent. I chose that because it seemed to me the right place where to put this file. So, i can easily modify the location to be distribution independent but i don't known which directory would be appropriate. Any proposal? Regards Roberto Sassu Also, I certainly have no such things in my system and see no point in calling ima_setup() on it. Or even compiling the source file in such case. Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA' statement, as it happens for SELinux. However an issue is that there is no a specific package for IMA that can be checked to set the HAVE_IMA definition to yes. Instead, the code can be enabled for example by adding the parameter '--enable_ima' in the configure script. okay. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I'm under the impression this function belongs to a userspace tool. If not then I just don't see a good reason that this patch is required. I do understand that the IMA policy should be loaded as early as possible, but I believe that early userspace scripts should be doing that work. If it is a userspace function, then whatever makes you happy, other distro's will roll their own. Thanks Mimi for your contribution. I just want to add some considerations. Hi Michael the reason for which the loading of IMA policies has been placed in the main Systemd executable is that the measurement process performed by IMA should start as early as possible. Otherwise, in order to build the 'chain of trust' during the boot process from the BIOS to software applications, it is required to measure those components loaded before IMA is initialized with other means (for example from the boot loader). The more the IMA initialization is postponed, greater is the number of components that must be measured using the second way. For instance, if the policy loading is done in a userspace script you have to measure the interpreter and the configuration files read by the latter. Since the policy loading can be implemented in different ways depending on the init system (systemd, upstart, ...), an user must identify the components to be measured for each case. Instead, if the IMA policy is loaded in the main Systemd executable, only this file must be measured by the boot loader. Regards Roberto Sassu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, 2012-02-16 at 15:56 +1100, Michael Cassaniti wrote: On 16/02/2012 04:12, Roberto Sassu wrote: On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassuroberto.sa...@polito.it wrote: The new function ima_setup() loads an IMA custom policy from a file in the default location '/etc/sysconfig/ima-policy', if present, and writes it to isn't /etc/sysconfig too specific to Fedora? Hi Gustavo probably yes. I see the code in 'src/locale-setup.c' where the the configuration directory depends on the target distribution. I can implement something like that in my patch. Can't IMA be changed? Lennart seems to be pushing for distribution independent location files. If you can get IMA people to agree on something, just use this one instead. People that use IMA with systemd must use this location. Eventually this will happen with every configuration file we support. The location of the policy file is not IMA dependent. I chose that because it seemed to me the right place where to put this file. So, i can easily modify the location to be distribution independent but i don't known which directory would be appropriate. Any proposal? Regards Roberto Sassu Also, I certainly have no such things in my system and see no point in calling ima_setup() on it. Or even compiling the source file in such case. Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA' statement, as it happens for SELinux. However an issue is that there is no a specific package for IMA that can be checked to set the HAVE_IMA definition to yes. Instead, the code can be enabled for example by adding the parameter '--enable_ima' in the configure script. okay. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I'm under the impression this function belongs to a userspace tool. If not then I just don't see a good reason that this patch is required. I do understand that the IMA policy should be loaded as early as possible, but I believe that early userspace scripts should be doing that work. If it is a userspace function, then whatever makes you happy, other distro's will roll their own. The default 'ima_tcb' measurement policy measures all files executed, all files mmapped, and all files read by root. Not all of these files need to be measured, but until the LSM policy is loaded, there is no means of identifying files in order to constrain the policy. Secondly, the 'security.ima' xattr, for files included in the IMA appraisal policy, is updated on __fput() to reflect changes. Depending on when the policy is updated, this could cause the file's real value and the xattr stored value to be out of sync, resulting in integrity verification failures. As the IMA policy definition can be based on LSM obj/subj labels, the policy needs to be loaded as early as possible, but only after the LSM policy has been loaded. thanks, Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassu roberto.sa...@polito.it wrote: On 02/16/2012 05:56 AM, Michael Cassaniti wrote: On 16/02/2012 04:12, Roberto Sassu wrote: On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassuroberto.sa...@polito.it wrote: The new function ima_setup() loads an IMA custom policy from a file in the default location '/etc/sysconfig/ima-policy', if present, and writes it to isn't /etc/sysconfig too specific to Fedora? Hi Gustavo probably yes. I see the code in 'src/locale-setup.c' where the the configuration directory depends on the target distribution. I can implement something like that in my patch. Can't IMA be changed? Lennart seems to be pushing for distribution independent location files. If you can get IMA people to agree on something, just use this one instead. People that use IMA with systemd must use this location. Eventually this will happen with every configuration file we support. The location of the policy file is not IMA dependent. I chose that because it seemed to me the right place where to put this file. So, i can easily modify the location to be distribution independent but i don't known which directory would be appropriate. Any proposal? Regards Roberto Sassu Also, I certainly have no such things in my system and see no point in calling ima_setup() on it. Or even compiling the source file in such case. Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA' statement, as it happens for SELinux. However an issue is that there is no a specific package for IMA that can be checked to set the HAVE_IMA definition to yes. Instead, the code can be enabled for example by adding the parameter '--enable_ima' in the configure script. okay. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I'm under the impression this function belongs to a userspace tool. If not then I just don't see a good reason that this patch is required. I do understand that the IMA policy should be loaded as early as possible, but I believe that early userspace scripts should be doing that work. If it is a userspace function, then whatever makes you happy, other distro's will roll their own. Thanks Mimi for your contribution. I just want to add some considerations. Hi Michael the reason for which the loading of IMA policies has been placed in the main Systemd executable is that the measurement process performed by IMA should start as early as possible. Otherwise, in order to build the 'chain of trust' during the boot process from the BIOS to software applications, it is required to measure those components loaded before IMA is initialized with other means (for example from the boot loader). The more the IMA initialization is postponed, greater is the number of components that must be measured using the second way. For instance, if the policy loading is done in a userspace script you have to measure the interpreter and the configuration files read by the latter. Since the policy loading can be implemented in different ways depending on the init system (systemd, upstart, ...), an user must identify the components to be measured for each case. Instead, if the IMA policy is loaded in the main Systemd executable, only this file must be measured by the boot loader. Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On 02/16/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/16/2012 05:56 AM, Michael Cassaniti wrote: On 16/02/2012 04:12, Roberto Sassu wrote: On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassuroberto.sa...@polito.it wrote: The new function ima_setup() loads an IMA custom policy from a file in the default location '/etc/sysconfig/ima-policy', if present, and writes it to isn't /etc/sysconfig too specific to Fedora? Hi Gustavo probably yes. I see the code in 'src/locale-setup.c' where the the configuration directory depends on the target distribution. I can implement something like that in my patch. Can't IMA be changed? Lennart seems to be pushing for distribution independent location files. If you can get IMA people to agree on something, just use this one instead. People that use IMA with systemd must use this location. Eventually this will happen with every configuration file we support. The location of the policy file is not IMA dependent. I chose that because it seemed to me the right place where to put this file. So, i can easily modify the location to be distribution independent but i don't known which directory would be appropriate. Any proposal? Regards Roberto Sassu Also, I certainly have no such things in my system and see no point in calling ima_setup() on it. Or even compiling the source file in such case. Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA' statement, as it happens for SELinux. However an issue is that there is no a specific package for IMA that can be checked to set the HAVE_IMA definition to yes. Instead, the code can be enabled for example by adding the parameter '--enable_ima' in the configure script. okay. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I'm under the impression this function belongs to a userspace tool. If not then I just don't see a good reason that this patch is required. I do understand that the IMA policy should be loaded as early as possible, but I believe that early userspace scripts should be doing that work. If it is a userspace function, then whatever makes you happy, other distro's will roll their own. Thanks Mimi for your contribution. I just want to add some considerations. Hi Michael the reason for which the loading of IMA policies has been placed in the main Systemd executable is that the measurement process performed by IMA should start as early as possible. Otherwise, in order to build the 'chain of trust' during the boot process from the BIOS to software applications, it is required to measure those components loaded before IMA is initialized with other means (for example from the boot loader). The more the IMA initialization is postponed, greater is the number of components that must be measured using the second way. For instance, if the policy loading is done in a userspace script you have to measure the interpreter and the configuration files read by the latter. Since the policy loading can be implemented in different ways depending on the init system (systemd, upstart, ...), an user must identify the components to be measured for each case. Instead, if the IMA policy is loaded in the main Systemd executable, only this file must be measured by the boot loader. Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. This does not work because SELinux is initialized inside Systemd and IMA requires it for parsing LSM rules in the policy. Regards Roberto Sassu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, Feb 16, 2012 at 12:30:31PM -0200, Gustavo Sverzut Barbieri wrote: On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassu roberto.sa...@polito.it wrote: the reason for which the loading of IMA policies has been placed in the main Systemd executable is that the measurement process performed by IMA should start as early as possible. Otherwise, in order to build the 'chain of trust' during the boot process from the BIOS to software applications, it is required to measure those components loaded before IMA is initialized with other means (for example from the boot loader). Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. Isn't that a job for initramfs? -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies
On Thu, Feb 16, 2012 at 12:35 PM, Roberto Sassu roberto.sa...@polito.it wrote: On 02/16/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/16/2012 05:56 AM, Michael Cassaniti wrote: On 16/02/2012 04:12, Roberto Sassu wrote: On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassuroberto.sa...@polito.it wrote: On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote: On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassuroberto.sa...@polito.it wrote: The new function ima_setup() loads an IMA custom policy from a file in the default location '/etc/sysconfig/ima-policy', if present, and writes it to isn't /etc/sysconfig too specific to Fedora? Hi Gustavo probably yes. I see the code in 'src/locale-setup.c' where the the configuration directory depends on the target distribution. I can implement something like that in my patch. Can't IMA be changed? Lennart seems to be pushing for distribution independent location files. If you can get IMA people to agree on something, just use this one instead. People that use IMA with systemd must use this location. Eventually this will happen with every configuration file we support. The location of the policy file is not IMA dependent. I chose that because it seemed to me the right place where to put this file. So, i can easily modify the location to be distribution independent but i don't known which directory would be appropriate. Any proposal? Regards Roberto Sassu Also, I certainly have no such things in my system and see no point in calling ima_setup() on it. Or even compiling the source file in such case. Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA' statement, as it happens for SELinux. However an issue is that there is no a specific package for IMA that can be checked to set the HAVE_IMA definition to yes. Instead, the code can be enabled for example by adding the parameter '--enable_ima' in the configure script. okay. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I'm under the impression this function belongs to a userspace tool. If not then I just don't see a good reason that this patch is required. I do understand that the IMA policy should be loaded as early as possible, but I believe that early userspace scripts should be doing that work. If it is a userspace function, then whatever makes you happy, other distro's will roll their own. Thanks Mimi for your contribution. I just want to add some considerations. Hi Michael the reason for which the loading of IMA policies has been placed in the main Systemd executable is that the measurement process performed by IMA should start as early as possible. Otherwise, in order to build the 'chain of trust' during the boot process from the BIOS to software applications, it is required to measure those components loaded before IMA is initialized with other means (for example from the boot loader). The more the IMA initialization is postponed, greater is the number of components that must be measured using the second way. For instance, if the policy loading is done in a userspace script you have to measure the interpreter and the configuration files read by the latter. Since the policy loading can be implemented in different ways depending on the init system (systemd, upstart, ...), an user must identify the components to be measured for each case. Instead, if the IMA policy is loaded in the main Systemd executable, only this file must be measured by the boot loader. Then I wonder: why not make an ima-init binary that: - does ima_setup() - exec systemd || upstart || ... this way you only have to audit this very small file and not systemd itself, it's very early and so on. This does not work because SELinux is initialized inside Systemd and IMA requires it for parsing LSM rules in the policy. initramfs may do it as well, no? then systemd will inherit it. I'm not using or reviewing the SELinux patches myself, so I may be wrong. Let's see if someone will check the code or Lennart will say what he did. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
