linux-ima-user — Q&A for users of IMA

Re: [Linux-ima-user] [PATCH v2] 98integrity: Use /etc/ima as dir for IMA policy and config file

[Stefan B. <st...@li...>]

On 11/30/2016 10:16 AM, Harald Hoyer wrote:
> On 30.11.2016 16:10, Stefan Berger wrote:
>> From: Stefan Berger <st...@us...>
>>
>> To sync with systemd, use the filepath /etc/ima/ima-policy as
>> the file location for the IMA policy. At the same time we
>> move the ima config file location to /etc/ima/ima. Adapt the
>> documentation to the new path.
>>
>> Signed-off-by: Stefan Berger <st...@li...>
>
> One more thing: Do you want to be backwards compatible and also read the old files, if they exist?

I had thought about that and can certainly add it.  Neither Fedora, 
RHEL, nor SUSE are packaging these files so far. So likely there aren't 
many users out there. Considering that, what would you suggest?

Re: [Linux-ima-user] [PATCH v2] 98integrity: Use /etc/ima as dir for IMA policy and config file

[Harald H. <ha...@re...>]

On 30.11.2016 16:10, Stefan Berger wrote:
> From: Stefan Berger <st...@us...>
> 
> To sync with systemd, use the filepath /etc/ima/ima-policy as
> the file location for the IMA policy. At the same time we
> move the ima config file location to /etc/ima/ima. Adapt the
> documentation to the new path.
> 
> Signed-off-by: Stefan Berger <st...@li...>


One more thing: Do you want to be backwards compatible and also read the old files, if they exist?

[Linux-ima-user] [PATCH v2] 98integrity: Use /etc/ima as dir for IMA policy and config file

[Stefan B. <st...@li...>]

From: Stefan Berger <st...@us...>

To sync with systemd, use the filepath /etc/ima/ima-policy as
the file location for the IMA policy. At the same time we
move the ima config file location to /etc/ima/ima. Adapt the
documentation to the new path.

Signed-off-by: Stefan Berger <st...@li...>
---
 modules.d/98integrity/README             | 8 ++++----
 modules.d/98integrity/ima-keys-load.sh   | 2 +-
 modules.d/98integrity/ima-policy-load.sh | 9 +++++++--
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/modules.d/98integrity/README b/modules.d/98integrity/README
index 64de0ae..c8ccee5 100644
--- a/modules.d/98integrity/README
+++ b/modules.d/98integrity/README
@@ -33,10 +33,10 @@ line.
 
 # Save the policy in a file.
 
-# Create the configuration file '/etc/sysconfig/ima' to override the path name of
+# Create the configuration file '/etc/ima/ima' to override the path name of
 # the IMA custom policy.
-------------- '/etc/sysconfig/ima' (with the default value) -------------
-IMAPOLICY="/etc/sysconfig/ima-policy"
+------------- '/etc/ima/ima' (with the default value) -------------
+IMAPOLICY="/etc/ima/ima-policy"
 -------------------------------------------------------------------------
 
 
@@ -64,5 +64,5 @@ IMAPOLICY="/etc/sysconfig/ima-policy"
 
 # 98integrity/ima-keys-load.sh script loads the signed certificates stored 
 # in the $IMAKEYSDIR onto the trusted IMA keyring.  The default $IMAKEYSDIR
-# directory is /etc/keys/ima, but can be specified in the /etc/sysconfig/ima
+# directory is /etc/keys/ima, but can be specified in the /etc/ima/ima
 # policy.
diff --git a/modules.d/98integrity/ima-keys-load.sh b/modules.d/98integrity/ima-keys-load.sh
index 659b722..6c6db40 100755
--- a/modules.d/98integrity/ima-keys-load.sh
+++ b/modules.d/98integrity/ima-keys-load.sh
@@ -2,7 +2,7 @@
 
 SECURITYFSDIR="/sys/kernel/security"
 IMASECDIR="${SECURITYFSDIR}/ima"
-IMACONFIG="${NEWROOT}/etc/sysconfig/ima"
+IMACONFIG="${NEWROOT}/etc/ima/ima"
 
 load_x509_keys()
 {
diff --git a/modules.d/98integrity/ima-policy-load.sh b/modules.d/98integrity/ima-policy-load.sh
index 85cd3b9..4cd6ba3 100755
--- a/modules.d/98integrity/ima-policy-load.sh
+++ b/modules.d/98integrity/ima-policy-load.sh
@@ -5,10 +5,15 @@
 # Copyright (C) 2011 Politecnico di Torino, Italy
 #                    TORSEC group -- http://security.polito.it
 # Roberto Sassu <rob...@po...>
+#
+# Copyright (C) 2016 IBM Corporation
+#
+# Stefan Berger <st...@li...>
+#
 
 IMASECDIR="${SECURITYFSDIR}/ima"
-IMACONFIG="${NEWROOT}/etc/sysconfig/ima"
-IMAPOLICY="/etc/sysconfig/ima-policy"
+IMACONFIG="${NEWROOT}/etc/ima/ima"
+IMAPOLICY="/etc/ima/ima-policy"
 
 load_ima_policy()
 {
-- 
2.8.3

Re: [Linux-ima-user] [PATCH] 98integrity: Use /etc/ima/ima-policy as file location for IMA policy

[Harald H. <ha...@re...>]

On 30.11.2016 15:05, Stefan Berger wrote:
> From: Stefan Berger <st...@us...>
> 
> To sync with systemd, use the filepath /etc/ima/ima-policy as
> the file location for the IMA policy.
> 
> Signed-off-by: Stefan Berger <st...@li...>
> ---
>  modules.d/98integrity/ima-policy-load.sh | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/modules.d/98integrity/ima-policy-load.sh b/modules.d/98integrity/ima-policy-load.sh
> index 85cd3b9..35cfbcc 100755
> --- a/modules.d/98integrity/ima-policy-load.sh
> +++ b/modules.d/98integrity/ima-policy-load.sh
> @@ -5,10 +5,15 @@
>  # Copyright (C) 2011 Politecnico di Torino, Italy
>  #                    TORSEC group -- http://security.polito.it
>  # Roberto Sassu <rob...@po...>
> +#
> +# Copyright (C) 2016 IBM Corporation
> +#
> +# Stefan Berger <st...@li...>
> +#
>  
>  IMASECDIR="${SECURITYFSDIR}/ima"
>  IMACONFIG="${NEWROOT}/etc/sysconfig/ima"
> -IMAPOLICY="/etc/sysconfig/ima-policy"
> +IMAPOLICY="/etc/ima/ima-policy"
>  
>  load_ima_policy()
>  {
> 

you might want to change $IMACONFIG also then?

[Linux-ima-user] [PATCH] 98integrity: Use /etc/ima/ima-policy as file location for IMA policy

[Stefan B. <st...@li...>]

From: Stefan Berger <st...@us...>

To sync with systemd, use the filepath /etc/ima/ima-policy as
the file location for the IMA policy.

Signed-off-by: Stefan Berger <st...@li...>
---
 modules.d/98integrity/ima-policy-load.sh | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/modules.d/98integrity/ima-policy-load.sh b/modules.d/98integrity/ima-policy-load.sh
index 85cd3b9..35cfbcc 100755
--- a/modules.d/98integrity/ima-policy-load.sh
+++ b/modules.d/98integrity/ima-policy-load.sh
@@ -5,10 +5,15 @@
 # Copyright (C) 2011 Politecnico di Torino, Italy
 #                    TORSEC group -- http://security.polito.it
 # Roberto Sassu <rob...@po...>
+#
+# Copyright (C) 2016 IBM Corporation
+#
+# Stefan Berger <st...@li...>
+#
 
 IMASECDIR="${SECURITYFSDIR}/ima"
 IMACONFIG="${NEWROOT}/etc/sysconfig/ima"
-IMAPOLICY="/etc/sysconfig/ima-policy"
+IMAPOLICY="/etc/ima/ima-policy"
 
 load_ima_policy()
 {
-- 
2.8.3

Re: [Linux-ima-user] [systemd-devel] [PATCH 1/2] ima: Have IMA policy loaded from /etc/sysconfig or /etc/default.

[Lennart P. <le...@po...>]

On Tue, 29.11.16 07:08, Stefan Berger (st...@li...) wrote:

> > > Fedora has its policy in /etc/sysconfig/ima-policy while Ubuntu
> > > has it in /etc/default/ima-policy. So we try to read the IMA policy
> > > from one location and try it from another location if it couldn't
> > > be found. To maintainer backwards compatibility, we also try
> > > /etc/ima/ima-policy.
> > Sorry, but this looks very wrong. I am not sure what /etc/sysconfig/
> > and /etc/default/ima-policy are supposed to be, but I am pretty sure
> > placing IMA policy there is just wrong. Moreover, our goal is to
> > remove any distro-specific hooks in systemd in favour of common paths,
> > not adding new.
> 
> It's confusing... Dracut for example expects it in
> /etc/sysconfig/ima-policy:
> 
> https://github.com/dracutdevs/dracut/blob/master/modules.d/98integrity/ima-policy-load.sh#L10

That sounds like something to fix in dracut. I am sure Harald would be
fine with adopting the generic path.

Harald?

> So following that either one has to change. I chose to change systemd. To me
> /etc/default on Debian systems is the equivalent of /etc/sysconfig on RPM
> based ones (or at least RedHat based ones), so that's where this is coming
> from.

And both of them are bad idea. In particular the RH version. I mean
/etc is already system configuration, why would you place a directory
called "sysconfig" — which I figure is supposed to be short for
"system configuration" inside a directory for system configuration?

Lennart

-- 
Lennart Poettering, Red Hat

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] ima: Write the policy filename into IMA's sysfs policy file

[Stefan B. <st...@li...>]

On 11/29/2016 06:56 AM, Lennart Poettering wrote:
> On Mon, 28.11.16 14:17, Stefan Berger (st...@li...) wrote:
>
>> From: Stefan Berger <st...@us...>
>>
>> IMA validates file signatures based on the security.ima xattr. As of
>> Linux-4.7, instead of copying the IMA policy into the securityfs policy,
>> the IMA policy pathname can be written, allowing the IMA policy file
>> signature to be validated.
>>
>> This patch modifies the existing code to first attempt to write the
>> pathname, but on failure falls back to copying the IMA policy
>> contents.
> This second patch looks good. Any chance you can submit it as a PR on
> github? That's how we usually expect patches these days!

Sent pull request:

https://github.com/systemd/systemd/pull/4766

Regards,
     Stefan


> Thanks!
>
> Lennart
>

Re: [Linux-ima-user] [systemd-devel] [PATCH 1/2] ima: Have IMA policy loaded from /etc/sysconfig or /etc/default.

[Stefan B. <st...@li...>]

On 11/29/2016 06:49 AM, Lennart Poettering wrote:
> On Mon, 28.11.16 14:17, Stefan Berger (st...@li...) wrote:
>
>> From: Stefan Berger <st...@us...>
>>
>> Fedora has its policy in /etc/sysconfig/ima-policy while Ubuntu
>> has it in /etc/default/ima-policy. So we try to read the IMA policy
>> from one location and try it from another location if it couldn't
>> be found. To maintainer backwards compatibility, we also try
>> /etc/ima/ima-policy.
> Sorry, but this looks very wrong. I am not sure what /etc/sysconfig/
> and /etc/default/ima-policy are supposed to be, but I am pretty sure
> placing IMA policy there is just wrong. Moreover, our goal is to
> remove any distro-specific hooks in systemd in favour of common paths,
> not adding new.

It's confusing... Dracut for example expects it in 
/etc/sysconfig/ima-policy:

https://github.com/dracutdevs/dracut/blob/master/modules.d/98integrity/ima-policy-load.sh#L10

So following that either one has to change. I chose to change systemd. 
To me /etc/default on Debian systems is the equivalent of /etc/sysconfig 
on RPM based ones (or at least RedHat based ones), so that's where this 
is coming from.

>
> Hence I am sorry, but I don't think this is right. Please ask the
> downstream maintainers to agree on /etc/ima/ima-policy (or any oher
> common path). Let's fix the distros, let's not work around them in
> systemd.

Fine, if that's the common understanding that the proposed directories 
are not appropriate.

    Stefan

>
> I hope this makes sense,
>
> sorry,
>
> Lennart
>

Re: [Linux-ima-user] Single file measurement

[Svart K. <bla...@gm...>]

Thank you,
I enabled i_version on all mounted filesystems, nevertheless when changing
measured files, these changes do not seem to be detected!?
  - Open the file once -> it's added to the measurement list
  - Open the file again and make some changes, but the same measurement is
still there
Shouldn't this be recognized now by IMA since i_version is enabled?



On 28 November 2016 at 23:44, Mimi Zohar <zo...@li...> wrote:

> On Mon, 2016-11-28 at 21:29 +0100, Svart Kanin wrote:
> > Hi,
> > thanks for the reply.
> > > After accessing testfile.txt, does it appear in the measurement list
> > > this point?
> >
> > Yes after I access the file, it is listed in the measurement list
> > ascii_runtime_measurements,
> > but shouldn't it be already measured on reboot then as well even though
> the
> > file has not been accessed yet?
>
> On a hard boot, the measurement list starts out empty.  Based on policy,
> measurements are added on file open, mmap, or execute.  On a soft reboot
> (eg. kexec), we're working on carrying the measurements across kexec.
>
> > Now not only the testFile.txt which was assigned the 'M' attribute is
> added
> > to the measurement list,
> > but every other file as well that is being accessed!?
>
> What is measured is based on policy.
>
> >
> > > The policy needs to be loaded on reboot.  dracut and systemd have
> > > modules that load the IMA policy, but they're enabled by default.
> >
> > This means that the policies should be loaded automatically already?
>
> Oops,  that should have said that although there are dracut and systemd
> modules for loading the policy,  they still need to be enabled.
> >
> > > No, it doesn't require a reboot, but it does require the file system to
> > > be mounted with i_version.  Otherwise, files that change aren't
> > > re-measured.
> >
> > So if the filesystem is mounted with i_version, and labels are going to
> > assigned,
> > then the file should be measured immediately as soon as the label has
> been
> > assigned,
> > and not when the file is accessed the first time?
>
> No, reading/writing xattrs does not access the file itself.  So the file
> is not measured, even with the file_check rule.
>
> Mimi
>
>

Re: [Linux-ima-user] Single file measurement

[Mimi Z. <zo...@li...>]

On Mon, 2016-11-28 at 21:29 +0100, Svart Kanin wrote:
> Hi,
> thanks for the reply.
> > After accessing testfile.txt, does it appear in the measurement list
> > this point?
> 
> Yes after I access the file, it is listed in the measurement list
> ascii_runtime_measurements,
> but shouldn't it be already measured on reboot then as well even though the
> file has not been accessed yet?

On a hard boot, the measurement list starts out empty.  Based on policy,
measurements are added on file open, mmap, or execute.  On a soft reboot
(eg. kexec), we're working on carrying the measurements across kexec.

> Now not only the testFile.txt which was assigned the 'M' attribute is added
> to the measurement list,
> but every other file as well that is being accessed!?

What is measured is based on policy.

> 
> > The policy needs to be loaded on reboot.  dracut and systemd have
> > modules that load the IMA policy, but they're enabled by default.
> 
> This means that the policies should be loaded automatically already?

Oops,  that should have said that although there are dracut and systemd
modules for loading the policy,  they still need to be enabled.
> 
> > No, it doesn't require a reboot, but it does require the file system to
> > be mounted with i_version.  Otherwise, files that change aren't
> > re-measured.
> 
> So if the filesystem is mounted with i_version, and labels are going to
> assigned,
> then the file should be measured immediately as soon as the label has been
> assigned,
> and not when the file is accessed the first time?

No, reading/writing xattrs does not access the file itself.  So the file
is not measured, even with the file_check rule.

Mimi  

Re: [Linux-ima-user] Single file measurement

[Svart K. <bla...@gm...>]

Hi,
thanks for the reply.
> After accessing testfile.txt, does it appear in the measurement list
> this point?

Yes after I access the file, it is listed in the measurement list
ascii_runtime_measurements,
but shouldn't it be already measured on reboot then as well even though the
file has not been accessed yet?
Now not only the testFile.txt which was assigned the 'M' attribute is added
to the measurement list,
but every other file as well that is being accessed!?


> The policy needs to be loaded on reboot.  dracut and systemd have
> modules that load the IMA policy, but they're enabled by default.

This means that the policies should be loaded automatically already?


> No, it doesn't require a reboot, but it does require the file system to
> be mounted with i_version.  Otherwise, files that change aren't
> re-measured.

So if the filesystem is mounted with i_version, and labels are going to
assigned,
then the file should be measured immediately as soon as the label has been
assigned,
and not when the file is accessed the first time?

Thanks

On 28 November 2016 at 19:03, Mimi Zohar <zo...@li...> wrote:

> On Mon, 2016-11-28 at 17:03 +0100, Black Rabbit wrote:
> > Hello,
> > I'm trying to measure single files with IMA by using SMACK as described
> in
> > this post https://sourceforge.net/p/linux-ima/mailman/message/25990539/
> >
> > I've tried to get it to work on a machine running Ubuntu 16.04, kernel
> > version 4.4.0-47-generic.
> > These are the steps I have performed so far:
> >
> > - Added "smackfs /sys/fs/smackfs smackfs defaults 0 0" to /etc/fstab
> > - Added "security=smack ima_tcb" to the kernel boot parameters in
> > /etc/default/grub
> > - Reboot -> smackfs got mounted correctly in /sys/fs/smackfs
> > - Now added SMACK policy with `echo "_
> > M                       rwxa"` -> ('_', 23spaces, 'M', 23spaces, 'rwxa')
> > - Added the following content into a file
> >
> >                 # PROC_SUPER_MAGIC
> >                 dont_measure fsmagic=0x9fa0
> >                 # SYSFS_MAGIC
> >                dont_measure fsmagic=0x62656572
> >                # DEBUGFS_MAGIC
> >                dont_measure fsmagic=0x64626720
> >                # TMPFS_MAGIC
> >                dont_measure fsmagic=0x01021994
> >                # SECURITYFS_MAGIC
> >                dont_measure fsmagic=0x73636673
> >                measure func=BPRM_CHECK
> >                measure func=FILE_MMAP mask=MAY_EXEC
> >                measure func=FILE_CHECK mask=MAY_READ obj_user=M
> >
> >    and cat'ed it to  /sys/kernel/security/ima/policy
> > - Set the attribute M on a testfile via
> >            setfattr -n security.SMACK64 -v M testFile.txt
>
> After accessing testfile.txt, does it appear in the measurement list at
> this point?
>
> > Reboot the system
> > But the file "testFile.txt" did not get measured!? Do I have to do
> anything
> > else?
>
> The policy needs to be loaded on reboot.  dracut and systemd have
> modules that load the IMA policy, but they're enabled by default.
>
> > Is there a way to display the current policies that are being applied?
>
> More recent kernels have a Kconfig option for displaying the policy.
>
> > When adding labels to files that should be measured, does the system
> always
> > require a reboot, so that these files are going to be measured and
> changes
> > to the files noticed?
>
> No, it doesn't require a reboot, but it does require the file system to
> be mounted with i_version.  Otherwise, files that change aren't
> re-measured.
>
> Mimi
>
> > After the system has rebooted are the previously added policies still
> there
> > or just used for one "system restart session" and then reset to the
> default?
>
>

Re: [Linux-ima-user] Single file measurement

[Mimi Z. <zo...@li...>]

On Mon, 2016-11-28 at 17:03 +0100, Black Rabbit wrote:
> Hello,
> I'm trying to measure single files with IMA by using SMACK as described in
> this post https://sourceforge.net/p/linux-ima/mailman/message/25990539/
> 
> I've tried to get it to work on a machine running Ubuntu 16.04, kernel
> version 4.4.0-47-generic.
> These are the steps I have performed so far:
> 
> - Added "smackfs /sys/fs/smackfs smackfs defaults 0 0" to /etc/fstab
> - Added "security=smack ima_tcb" to the kernel boot parameters in
> /etc/default/grub
> - Reboot -> smackfs got mounted correctly in /sys/fs/smackfs
> - Now added SMACK policy with `echo "_
> M                       rwxa"` -> ('_', 23spaces, 'M', 23spaces, 'rwxa')
> - Added the following content into a file
> 
>                 # PROC_SUPER_MAGIC
>                 dont_measure fsmagic=0x9fa0
>                 # SYSFS_MAGIC
>                dont_measure fsmagic=0x62656572
>                # DEBUGFS_MAGIC
>                dont_measure fsmagic=0x64626720
>                # TMPFS_MAGIC
>                dont_measure fsmagic=0x01021994
>                # SECURITYFS_MAGIC
>                dont_measure fsmagic=0x73636673
>                measure func=BPRM_CHECK
>                measure func=FILE_MMAP mask=MAY_EXEC
>                measure func=FILE_CHECK mask=MAY_READ obj_user=M
> 
>    and cat'ed it to  /sys/kernel/security/ima/policy
> - Set the attribute M on a testfile via
>            setfattr -n security.SMACK64 -v M testFile.txt

After accessing testfile.txt, does it appear in the measurement list at
this point?

> Reboot the system
> But the file "testFile.txt" did not get measured!? Do I have to do anything
> else?

The policy needs to be loaded on reboot.  dracut and systemd have
modules that load the IMA policy, but they're enabled by default.

> Is there a way to display the current policies that are being applied?

More recent kernels have a Kconfig option for displaying the policy.

> When adding labels to files that should be measured, does the system always
> require a reboot, so that these files are going to be measured and changes
> to the files noticed?

No, it doesn't require a reboot, but it does require the file system to
be mounted with i_version.  Otherwise, files that change aren't
re-measured.

Mimi

> After the system has rebooted are the previously added policies still there
> or just used for one "system restart session" and then reset to the default?

[Linux-ima-user] Single file measurement

[Black R. <bla...@gm...>]

Hello,
I'm trying to measure single files with IMA by using SMACK as described in
this post https://sourceforge.net/p/linux-ima/mailman/message/25990539/

I've tried to get it to work on a machine running Ubuntu 16.04, kernel
version 4.4.0-47-generic.
These are the steps I have performed so far:

- Added "smackfs /sys/fs/smackfs smackfs defaults 0 0" to /etc/fstab
- Added "security=smack ima_tcb" to the kernel boot parameters in
/etc/default/grub
- Reboot -> smackfs got mounted correctly in /sys/fs/smackfs
- Now added SMACK policy with `echo "_
M                       rwxa"` -> ('_', 23spaces, 'M', 23spaces, 'rwxa')
- Added the following content into a file

                # PROC_SUPER_MAGIC
                dont_measure fsmagic=0x9fa0
                # SYSFS_MAGIC
               dont_measure fsmagic=0x62656572
               # DEBUGFS_MAGIC
               dont_measure fsmagic=0x64626720
               # TMPFS_MAGIC
               dont_measure fsmagic=0x01021994
               # SECURITYFS_MAGIC
               dont_measure fsmagic=0x73636673
               measure func=BPRM_CHECK
               measure func=FILE_MMAP mask=MAY_EXEC
               measure func=FILE_CHECK mask=MAY_READ obj_user=M

   and cat'ed it to  /sys/kernel/security/ima/policy
- Set the attribute M on a testfile via
           setfattr -n security.SMACK64 -v M testFile.txt

Reboot the system
But the file "testFile.txt" did not get measured!? Do I have to do anything
else?
Is there a way to display the current policies that are being applied?
When adding labels to files that should be measured, does the system always
require a reboot, so that these files are going to be measured and changes
to the files noticed?
After the system has rebooted are the previously added policies still there
or just used for one "system restart session" and then reset to the default?

Thank you

[Linux-ima-user] Single file measurement

[Black R. <bla...@gm...>]

Hello,
I'm trying to measure single files with IMA by using SMACK.
I have performed the following steps:

Re: [Linux-ima-user] copying files with security.ima xattr

[Mimi Z. <zo...@li...>]

On Tue, 2016-11-15 at 15:28 +0100, Patrick Ohly wrote:
> On Thu, 2016-11-03 at 08:58 +0100, Patrick Ohly wrote:
> > On Wed, 2016-11-02 at 09:47 -0400, Mimi Zohar wrote:
> > > In order to revert the patch, we need to explain the reason for doing
> > > so.   Could you expand/update the two reasons given below?
> > > 
> > > - Applications have been modified to write security xattrs, but they are
> > > not necessarily context aware.  In the case of security.ima, the
> > > security xattr can be either a file hash or a file signature.
> > > Permitting writing one, but not the other requires the application to be
> > > context aware.
> > > 
> > > - Applications write files to a staging area, which might not be in
> > > policy, and then change some file metadata (eg owner) making it in
> > > policy.  As a result, these files are not labeled properly.
> > 
> > That describes it well.
> 
> Let's move this forward. Mimi, I'll send a patch to this list to keep
> the discussion and the resulting code change in one place. Does that
> work for you?
> 
> The patch applies cleanly to your "next" branch in
> git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.

I didn't forget.  It's already queued in the #next-fixes branch with a
couple of other fixes.

7bbebfd4f0fc Revert "ima: limit file hash setting by user to fix and log
modes"

Before moving them to the usual #next branch, I need to speak with
Andrew Morton, who is carrying the IMA kexec patches.  Sorry for the
confusion!

Mimi

[Linux-ima-user] [PATCH] Revert "ima: limit file hash setting by user to fix and log modes"

[Patrick O. <pat...@in...>]

This reverts commit c68ed80c97d9720f51ef31fe91560fdd1e121533.

The original motivation was security hardening ("File hashes are
automatically set and updated and should not be manually set.")

However, that hardening ignores and breaks some valid use cases:
- File hashes might not be set because the file is currently
  outside of the policy and therefore have to be set by the
  creator. Examples:
  - Booting into an initramfs with an IMA-enabled kernel but
    without setting an IMA policy, then installing
    the OS onto the target partition by unpacking a rootfs archive
    which has the file hashes pre-computed.
  - Unpacking a file into a staging area with meta data (like owner)
    that leaves the file outside of the current policy, then changing
    the meta data such that it becomes part of the current policy.
- "should not be set manually" implies that the creator is aware
  of IMA semantic, the current system's configuration, and then
  skips setting file hashes in security.ima if (and only if) the
  kernel would prevent it. That's not the case for standard, unmodified
  tools. Example: unpacking an archive with security.ima xattrs with
  bsdtar or GNU tar.

Signed-off-by: Patrick Ohly <pat...@in...>
---
 security/integrity/ima/ima_appraise.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index 4b9b4a4..b8b2dd9 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -385,14 +385,10 @@ int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name,
 	result = ima_protect_xattr(dentry, xattr_name, xattr_value,
 				   xattr_value_len);
 	if (result == 1) {
-		bool digsig;
-
 		if (!xattr_value_len || (xvalue->type >= IMA_XATTR_LAST))
 			return -EINVAL;
-		digsig = (xvalue->type == EVM_IMA_XATTR_DIGSIG);
-		if (!digsig && (ima_appraise & IMA_APPRAISE_ENFORCE))
-			return -EPERM;
-		ima_reset_appraise_flags(d_backing_inode(dentry), digsig);
+		ima_reset_appraise_flags(d_backing_inode(dentry),
+			 (xvalue->type == EVM_IMA_XATTR_DIGSIG) ? 1 : 0);
 		result = 0;
 	}
 	return result;
-- 
2.1.4

Re: [Linux-ima-user] copying files with security.ima xattr

[Patrick O. <pat...@in...>]

On Thu, 2016-11-03 at 08:58 +0100, Patrick Ohly wrote:
> On Wed, 2016-11-02 at 09:47 -0400, Mimi Zohar wrote:
> > In order to revert the patch, we need to explain the reason for doing
> > so.   Could you expand/update the two reasons given below?
> > 
> > - Applications have been modified to write security xattrs, but they are
> > not necessarily context aware.  In the case of security.ima, the
> > security xattr can be either a file hash or a file signature.
> > Permitting writing one, but not the other requires the application to be
> > context aware.
> > 
> > - Applications write files to a staging area, which might not be in
> > policy, and then change some file metadata (eg owner) making it in
> > policy.  As a result, these files are not labeled properly.
> 
> That describes it well.

Let's move this forward. Mimi, I'll send a patch to this list to keep
the discussion and the resulting code change in one place. Does that
work for you?

The patch applies cleanly to your "next" branch in
git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] Overriding executables with overlayfs

[Kiviluoto, J. J <jaa...@in...>]

> From: Patrick Ohly [mailto:pat...@in...]
> Sent: Tuesday, November 15, 2016 12:01 PM
> 
> On Tue, 2016-11-15 at 10:51 +0100, Patrick Ohly wrote:
> > I don't know how well that'll work with the overlayfs.
> 
> We had problems with it. See
> https://github.com/ostroproject/ostro-os/blob/master/meta-ostro-
> bsp/recipes-kernel/linux-yocto/linux-yocto/0001-ovl-setxattr-don-t-
> deadlock-when-called-from-ima_fix.patch
> and (found via some searching):
> http://www.spinics.net/lists/linux-unionfs/msg00629.html
> https://patchwork.kernel.org/patch/9376729/

Yes, Krisztian already pointed me to these. That is included in 4.8.3 and allows me to boot ok, but so far none of the merged updates to overlayfs or related bits seem to make it work properly with IMA.

Jaakko

Re: [Linux-ima-user] Overriding executables with overlayfs

[Patrick O. <pat...@in...>]

On Tue, 2016-11-15 at 10:51 +0100, Patrick Ohly wrote:
> I don't know how well that'll work with the overlayfs.

We had problems with it. See
https://github.com/ostroproject/ostro-os/blob/master/meta-ostro-bsp/recipes-kernel/linux-yocto/linux-yocto/0001-ovl-setxattr-don-t-deadlock-when-called-from-ima_fix.patch
and (found via some searching):
http://www.spinics.net/lists/linux-unionfs/msg00629.html
https://patchwork.kernel.org/patch/9376729/

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] Overriding executables with overlayfs

[Patrick O. <pat...@in...>]

On Tue, 2016-11-15 at 08:54 +0000, Kiviluoto, Jaakko J wrote:
> I currently have IMA functioning on a Yocto based build (kernel 4.8.3) with overlayfs root filesystem as follows:

So you managed to get key loading working? Good :-)

> - lowerdir = loop-mounted read-only squashfs with IMA signatures set build time
> - upperdir = directory on sync,noexec mounted ext4 partition for writing persistent configs etc.
> - workdir on same partition as upperdir
> 
> Observations (as root user):
> - I cannot edit executables, e.g. /etc/init.d/networking - "Permission denied" as expected
> - I can erase (whiteout) executables
> - I can create my own (malicious) executable script, and copy it on top of an IMA-signed system binary, and execute it
> - "noexec" mount option doesn't seem to have any effect
>
> I get the same results with both of these two policies:
> https://github.com/01org/meta-intel-iot-security/blob/master/meta-integrity/data/ima_policy_appraise_all
> https://github.com/01org/meta-intel-iot-security/blob/master/meta-integrity/data/ima_policy_hashed
>
> I realize there may be more overlayfs issues than IMA, but is this behavior what others would expect?
> Can't I somehow tell IMA to strictly enforce the original signature instead of coming up with a new one for replaced files?

We are getting the behavior that you describe (an unmodifiable, signed
file can be replaced with a locally created, hashed file) on Ostro OS
because we had to allow mixing writable files and read-only files in the
same partition. It's a known loophole in that (incomplete)
proof-of-concept setup.

Ostro OS uses a slightly different policy
(https://github.com/ostroproject/ostro-os/blob/master/meta-ostro/recipes-image/images/files/ima_policy_ostro) but the basic principle is the same.

You could try with "appraise appraise_type=imasig" instead of just
"appraise".

I don't know how well that'll work with the overlayfs.

> Or am I better off seeking alternative to overlayfs setup?

I think it would indeed be better to separate writable and read-only
parts of your file tree differently, for example by mounting a partition
for read/write access (could be under /var) and then making sure that
all modifiable data ends up there.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

[Linux-ima-user] Overriding executables with overlayfs

[Kiviluoto, J. J <jaa...@in...>]

Hi all,

I currently have IMA functioning on a Yocto based build (kernel 4.8.3) with overlayfs root filesystem as follows:
- lowerdir = loop-mounted read-only squashfs with IMA signatures set build time
- upperdir = directory on sync,noexec mounted ext4 partition for writing persistent configs etc.
- workdir on same partition as upperdir

Observations (as root user):
- I cannot edit executables, e.g. /etc/init.d/networking - "Permission denied" as expected
- I can erase (whiteout) executables
- I can create my own (malicious) executable script, and copy it on top of an IMA-signed system binary, and execute it
- "noexec" mount option doesn't seem to have any effect

I get the same results with both of these two policies:
https://github.com/01org/meta-intel-iot-security/blob/master/meta-integrity/data/ima_policy_appraise_all
https://github.com/01org/meta-intel-iot-security/blob/master/meta-integrity/data/ima_policy_hashed 

I realize there may be more overlayfs issues than IMA, but is this behavior what others would expect?
Can't I somehow tell IMA to strictly enforce the original signature instead of coming up with a new one for replaced files?
Or am I better off seeking alternative to overlayfs setup?

Many thanks,
Jaakko

Re: [Linux-ima-user] Creating custom IMA policies

[Mark D. B. <md...@ju...>]

Black Rabbit <bla...@gm...> writes:

> I tried to create rules to measure specific single files, that can either
> be executed (Bash files) or opened (Text files).

The IMA Policy does not let you directly manipulate files.

> Is it even possible to define specific files that should be measured by
> IMA, maybe by defining the entire path like `/home/user/test.txt' or
> '/home/user/exec.sh'?

Yes, but you typically need to use an LSM label (as with SMACK or
SELinux) for the group of files and then measure or appriase the LSM
label.

See this thread:

  https://sourceforge.net/p/linux-ima/mailman/message/25990539/

> Are there maybe any tutorials for such rules (I have already looked at
> the default policy file structure)?

Google should dig up a few slide decks on using SMACK with IMA or
SELinux with IMA

	Good luck,
	-- Mark

[Linux-ima-user] Creating custom IMA policies

[Black R. <bla...@gm...>]

Hello,
I have read through the IMA wiki page
https://sourceforge.net/p/linux-ima/wiki/Home/ to get an overview.
Now I'd like to create my own simple IMA policies but am struggling with
the right rule format.
I found the definition of the format here
https://www.kernel.org/doc/Documentation/ABI/testing/ima_policy.

I tried to create rules to measure specific single files, that can either
be executed (Bash files) or opened (Text files).
Is it even possible to define specific files that should be measured by
IMA, maybe by defining the entire path like `/home/user/test.txt' or
'/home/user/exec.sh'?

Are there maybe any tutorials for such rules (I have already looked at the
default policy file structure)?

Thank you for you help

Re: [Linux-ima-user] How to load a key to trusted IMA keyring?

[Kiviluoto, J. J <jaa...@in...>]

> I cannot see any key signature verification taking place at this point yet.

Ok now I see the key preparsing leading to x509_key_preparse() and subsequently to x509_validate_trust() which should set "prep->trusted = 1". So there must be something wrong with my keys after all.

Jaakko
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Linux-ima-user] How to load a key to trusted IMA keyring?

[Kiviluoto, J. J <jaa...@in...>]

> > What is the correct way to get a key loaded into the trusted ".ima"
> > keyring?
> >
> > If I try the CONFIG_IMA_LOAD_X509 way, this change removes the
> > "KEY_ALLOC_TRUSTED" attribute required by a trusted keyring:
> > https://sourceforge.net/p/linux-ima/mailman/message/34449223/
> 
> The key being loaded onto the .ima keyring needs to be signed by a key on
> the .buitlin_trusted_keys keyring.  On older kernels, the key needed to be
> signed by a key on the system keyring.

When I look at key_create_or_update() at
http://lxr.free-electrons.com/source/security/keys/key.c?v=4.4#L773
it's always going to fail if the supplied "flags" doesn't have KEY_ALLOC_TRUSTED:
http://lxr.free-electrons.com/source/security/keys/key.c?v=4.4#L833 
and integrity_load_x509() never sets it:
http://lxr.free-electrons.com/source/security/integrity/digsig.c?v=4.4#L101 

The results is failure with -EPERM:
[    4.181234] integrity: Problem loading X.509 certificate (-1): /etc/keys/x509_ima.der

I cannot see any key signature verification taking place at this point yet.

> The README in the ima-evm-util package has a good explanation, with
> examples.

I have created my key with the instructions in ima-evm-utils README.

Jaakko
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.