[PATCH 1/2] systemd: mount the securityfs filesystem at early stage

[PATCH 1/2] systemd: mount the securityfs filesystem at early stage

[Roberto Sassu]

[-- Attachment #1: Type: text/plain, Size: 4231 bytes --]

The mount of the securityfs filesystem is now performed in the main systemd
executable as it is used by IMA to provide the interface for loading custom
policies. The unit file 'units/sys-kernel-security.mount' has been removed
because it is not longer necessary.

Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
Acked-by: Gianluca Ramunno <ramunno@polito.it>
---
 Makefile.am                     |    3 ---
 src/mount-setup.c               |    6 ++++--
 src/mount-setup.h               |    2 ++
 units/sys-kernel-security.mount |   17 -----------------
 4 files changed, 6 insertions(+), 22 deletions(-)
 delete mode 100644 units/sys-kernel-security.mount

diff --git a/Makefile.am b/Makefile.am
index 983ea16..d3d0ed8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -291,7 +291,6 @@ dist_systemunit_DATA = \
 	units/dev-mqueue.mount \
 	units/sys-kernel-config.mount \
 	units/sys-kernel-debug.mount \
-	units/sys-kernel-security.mount \
 	units/sys-fs-fuse-connections.mount \
 	units/var-run.mount \
 	units/media.mount \
@@ -2374,7 +2373,6 @@ systemd-install-data-hook:
 			dev-mqueue.mount \
 			sys-kernel-config.mount \
 			sys-kernel-debug.mount \
-			sys-kernel-security.mount \
 			sys-fs-fuse-connections.mount \
 			systemd-modules-load.service \
 			systemd-tmpfiles-setup.service \
@@ -2384,7 +2382,6 @@ systemd-install-data-hook:
 		$(LN_S) ../dev-mqueue.mount dev-mqueue.mount && \
 		$(LN_S) ../sys-kernel-config.mount sys-kernel-config.mount && \
 		$(LN_S) ../sys-kernel-debug.mount sys-kernel-debug.mount && \
-		$(LN_S) ../sys-kernel-security.mount sys-kernel-security.mount && \
 		$(LN_S) ../sys-fs-fuse-connections.mount sys-fs-fuse-connections.mount && \
 		$(LN_S) ../systemd-modules-load.service systemd-modules-load.service && \
 		$(LN_S) ../systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service && \
diff --git a/src/mount-setup.c b/src/mount-setup.c
index 7c14ea8..62bf743 100644
--- a/src/mount-setup.c
+++ b/src/mount-setup.c
@@ -51,13 +51,15 @@ typedef struct MountPoint {
 } MountPoint;
 
 /* The first three entries we might need before SELinux is up. The
- * other ones we can delay until SELinux is loaded. */
-#define N_EARLY_MOUNT 3
+ * fourth (securityfs) is needed by IMA to load a custom policy. The
+ * other ones we can delay until SELinux and IMA are loaded. */
+#define N_EARLY_MOUNT 4
 
 static const MountPoint mount_table[] = {
         { "proc",     "/proc",                  "proc",     NULL,                MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
         { "sysfs",    "/sys",                   "sysfs",    NULL,                MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
         { "devtmpfs", "/dev",                   "devtmpfs", "mode=755",          MS_NOSUID,                    true },
+        { "securityfs", SECURITYFS_MNTPOINT,    "securityfs", NULL,              MS_NOSUID|MS_NOEXEC|MS_NODEV, false },
         { "tmpfs",    "/dev/shm",               "tmpfs",    "mode=1777",         MS_NOSUID|MS_NODEV,           true },
         { "devpts",   "/dev/pts",               "devpts",   "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false },
         { "tmpfs",    "/run",                   "tmpfs",    "mode=755",          MS_NOSUID|MS_NODEV, true },
diff --git a/src/mount-setup.h b/src/mount-setup.h
index c1a27ba..df6f518 100644
--- a/src/mount-setup.h
+++ b/src/mount-setup.h
@@ -24,6 +24,8 @@
 
 #include <stdbool.h>
 
+#define SECURITYFS_MNTPOINT "/sys/kernel/security"
+
 int mount_setup_early(void);
 
 int mount_setup(bool loaded_policy);
diff --git a/units/sys-kernel-security.mount b/units/sys-kernel-security.mount
deleted file mode 100644
index 80cd761..0000000
--- a/units/sys-kernel-security.mount
+++ /dev/null
@@ -1,17 +0,0 @@
-#  This file is part of systemd.
-#
-#  systemd is free software; you can redistribute it and/or modify it
-#  under the terms of the GNU General Public License as published by
-#  the Free Software Foundation; either version 2 of the License, or
-#  (at your option) any later version.
-
-[Unit]
-Description=Security File System
-DefaultDependencies=no
-ConditionPathExists=/sys/kernel/security
-Before=sysinit.target
-
-[Mount]
-What=securityfs
-Where=/sys/kernel/security
-Type=securityfs
-- 
1.7.7.6


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2061 bytes --]

[PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

[-- Attachment #1: Type: text/plain, Size: 7103 bytes --]

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
the path 'ima/policy' in the security filesystem. This function is executed
at early stage in order to avoid that some file operations are not measured
by IMA and it is placed after the initialization of SELinux because IMA
needs the latter (or other security modules) to understand LSM-specific
rules.

Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
Acked-by: Gianluca Ramunno <ramunno@polito.it>
---
 Makefile.am     |    1 +
 src/ima-setup.c |  114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/ima-setup.h |   29 ++++++++++++++
 src/main.c      |    6 ++-
 4 files changed, 149 insertions(+), 1 deletions(-)
 create mode 100644 src/ima-setup.c
 create mode 100644 src/ima-setup.h

diff --git a/Makefile.am b/Makefile.am
index d3d0ed8..7476caa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -515,6 +515,7 @@ libsystemd_core_la_SOURCES = \
 	src/mount-setup.c \
 	src/hostname-setup.c \
 	src/selinux-setup.c \
+	src/ima-setup.c \
 	src/loopback-setup.c \
 	src/kmod-setup.c \
 	src/locale-setup.c \
diff --git a/src/ima-setup.c b/src/ima-setup.c
new file mode 100644
index 0000000..45afc0c
--- /dev/null
+++ b/src/ima-setup.c
@@ -0,0 +1,114 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+  Copyright (C) 2012 Roberto Sassu - Politecnico di Torino, Italy
+                                     TORSEC group -- http://security.polito.it
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU General Public License as published by
+  the Free Software Foundation; either version 2 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  General Public License for more details.
+
+  You should have received a copy of the GNU General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+***/
+
+#include <unistd.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdlib.h>
+#include <fcntl.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+
+#include "ima-setup.h"
+#include "mount-setup.h"
+#include "macro.h"
+#include "util.h"
+#include "log.h"
+#include "label.h"
+
+#define IMA_SECFS_DIR SECURITYFS_MNTPOINT "/ima"
+#define IMA_SECFS_POLICY IMA_SECFS_DIR "/policy"
+#define IMA_POLICY_PATH "/etc/sysconfig/ima-policy"
+
+int ima_setup(void) {
+       struct stat st;
+       ssize_t policy_size = 0, written = 0;
+       char *policy;
+       int policyfd = -1, imafd = -1;
+       int result = 0;
+
+#ifndef HAVE_SELINUX
+       /* Mount the securityfs filesystem */
+       mount_setup_early();
+#endif
+
+       if (stat(IMA_POLICY_PATH, &st) == -1)
+               return 0;
+
+       policy_size = st.st_size;
+       if (stat(IMA_SECFS_DIR, &st) == -1) {
+               log_debug("IMA support is disabled in the kernel, ignoring.");
+               return 0;
+       }
+
+       if (stat(IMA_SECFS_POLICY, &st) == -1) {
+               log_error("Another IMA custom policy has already been loaded, "
+                         "ignoring.");
+               return 0;
+       }
+
+       policyfd = open(IMA_POLICY_PATH, O_RDONLY);
+       if (policyfd < 0) {
+               log_error("Failed to open the IMA custom policy file %s (%s), "
+                         "ignoring.", IMA_POLICY_PATH, strerror(errno));
+               return 0;
+       }
+
+       imafd = open(IMA_SECFS_POLICY, O_WRONLY);
+       if (imafd < 0) {
+               log_error("Failed to open the IMA kernel interface %s (%s), "
+                         "ignoring.", IMA_SECFS_POLICY, strerror(errno));
+               goto out;
+       }
+
+       policy = mmap(NULL, policy_size, PROT_READ, MAP_PRIVATE, policyfd, 0);
+       if (policy == NULL) {
+               log_error("mmap() failed (%s), freezing", strerror(errno));
+               result = -errno;
+               goto out;
+       }
+
+       while(written < policy_size) {
+               ssize_t len = write(imafd, policy + written,
+                                   policy_size - written);
+               if (len <= 0) {
+                         log_error("Failed to load the IMA custom policy "
+                                   "file %s (%s), ignoring.", IMA_POLICY_PATH,
+                                   strerror(errno));
+                         goto out_mmap;
+               }
+               written += len;
+       }
+
+       log_info("Successfully loaded the IMA custom policy %s.",
+                IMA_POLICY_PATH);
+out_mmap:
+       munmap(policy, policy_size);
+out:
+       if (policyfd >= 0)
+                close_nointr_nofail(policyfd);
+       if (imafd >= 0)
+                close_nointr_nofail(imafd);
+       return result;
+}
diff --git a/src/ima-setup.h b/src/ima-setup.h
new file mode 100644
index 0000000..7d677cf
--- /dev/null
+++ b/src/ima-setup.h
@@ -0,0 +1,29 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+#ifndef fooimasetuphfoo
+#define fooimasetuphfoo
+
+/***
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+  Copyright (C) 2012 Roberto Sassu - Politecnico di Torino, Italy
+                                     TORSEC group -- http://security.polito.it
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU General Public License as published by
+  the Free Software Foundation; either version 2 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  General Public License for more details.
+
+  You should have received a copy of the GNU General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+***/
+
+int ima_setup(void);
+
+#endif
diff --git a/src/main.c b/src/main.c
index ed317b4..7ae8841 100644
--- a/src/main.c
+++ b/src/main.c
@@ -41,6 +41,7 @@
 #include "kmod-setup.h"
 #include "locale-setup.h"
 #include "selinux-setup.h"
+#include "ima-setup.h"
 #include "machine-id-setup.h"
 #include "load-fragment.h"
 #include "fdset.h"
@@ -1203,9 +1204,12 @@ int main(int argc, char *argv[]) {
                 arg_running_as = MANAGER_SYSTEM;
                 log_set_target(detect_container(NULL) > 0 ? LOG_TARGET_CONSOLE : LOG_TARGET_JOURNAL_OR_KMSG);
 
-                if (!is_reexec)
+                if (!is_reexec) {
                         if (selinux_setup(&loaded_policy) < 0)
                                 goto finish;
+                        if (ima_setup() < 0)
+                                goto finish;
+                }
 
                 log_open();
 
-- 
1.7.7.6


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2061 bytes --]

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Gustavo Sverzut Barbieri]

On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassu <roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org> 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?

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.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

Re: [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
> On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassu<roberto.sassu@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.


> 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.

Regards

Roberto Sassu

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Gustavo Sverzut Barbieri]

On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassu <roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org> wrote:
>
> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>
>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassu<roberto.sassu@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.


>> 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: barbieri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote:
> On Wed, Feb 15, 2012 at 2:26 PM, Roberto Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>  wrote:
>>
>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>>
>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>    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: barbieri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Michael Cassaniti]

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 Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>   wrote:
>>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>     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: barbieri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> 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.

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Mimi Zohar]

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 Sassu<roberto.sassu@polito.it>   wrote:
> >>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
> >>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassu<roberto.sassu@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: barbieri@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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

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
>>> Sassu<roberto.sassu@polito.it> wrote:
>>>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto
>>>>> Sassu<roberto.sassu@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: barbieri@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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Gustavo Sverzut Barbieri]

On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassu <roberto.sassu@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
>>>> Sassu<roberto.sassu@polito.it> wrote:
>>>>>
>>>>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>>>>>
>>>>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto
>>>>>> Sassu<roberto.sassu@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: barbieri@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: barbieri@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/16/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
> On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>  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
>>>>> Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>  wrote:
>>>>>>
>>>>>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>>>>>>
>>>>>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto
>>>>>>> Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>  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: barbieri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>>>> 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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Gustavo Sverzut Barbieri]

On Thu, Feb 16, 2012 at 12:35 PM, Roberto Sassu <roberto.sassu@polito.it> wrote:
> On 02/16/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>
>> On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassu<roberto.sassu@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
>>>>>> Sassu<roberto.sassu@polito.it>  wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto
>>>>>>>> Sassu<roberto.sassu@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: barbieri@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: barbieri@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Thu, 16.02.12 19:50, Gustavo Sverzut Barbieri (barbieri@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.

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/20/2012 06:24 PM, Lennart Poettering wrote:
> On Thu, 16.02.12 19:50, Gustavo Sverzut Barbieri (barbieri@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
>

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Mon, 20.02.12 20:06, Roberto Sassu (roberto.sassu@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.

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/20/2012 08:18 PM, Lennart Poettering wrote:
> On Mon, 20.02.12 20:06, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) 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
>

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Mimi Zohar]

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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

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
>

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Mimi Zohar]

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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

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
>

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Mimi Zohar]

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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Kay Sievers]

On Tue, Feb 21, 2012 at 18:32, Roberto Sassu <roberto.sassu@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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/21/2012 06:56 PM, Kay Sievers wrote:
> On Tue, Feb 21, 2012 at 18:32, Roberto Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>  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

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Kay Sievers]

On Tue, Feb 21, 2012 at 19:07, Roberto Sassu <roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org> 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

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Colin Guthrie]

'Twas brillig, and Roberto Sassu at 21/02/12 10:05 did gyre and gimble:
>> 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.

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

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Kay Sievers]

On Tue, Feb 21, 2012 at 15:07, Colin Guthrie <gmane@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

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Mimi Zohar]

On Tue, 2012-02-21 at 15:32 +0100, Kay Sievers wrote:
> On Tue, Feb 21, 2012 at 15:07, Colin Guthrie <gmane-D409yXkIzt2rnn0nCzrM/w@public.gmane.org> 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

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

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 Guthrie<gmane@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
>
>

Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Mimi Zohar]

On Mon, 2012-02-20 at 20:18 +0100, Lennart Poettering wrote:
> On Mon, 20.02.12 20:06, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) 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

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Thu, 16.02.12 12:30, Gustavo Sverzut Barbieri (barbieri-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org) 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.

Re: [systemd-devel] [Linux-ima-user] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Thu, 16.02.12 15:56, Michael Cassaniti (m.cassaniti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) 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.

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Wed, 15.02.12 18:12, Roberto Sassu (roberto.sassu@polito.it) wrote:

> 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?

/etc/ima.conf or /etc/ima/ima.conf sound like obvious candidates.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/20/2012 06:14 PM, Lennart Poettering wrote:
> On Wed, 15.02.12 18:12, Roberto Sassu (roberto.sassu@polito.it) wrote:
>
>> 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?
>
> /etc/ima.conf or /etc/ima/ima.conf sound like obvious candidates.
>

I prefer the first one, because the second pathname raises the problem
of creating a new subdirectory. However, i think we should keep the
word 'policy' in the file name to avoid users believe that is a
configuration file.

Once we define the new pathname, i will also create a patch for
the IMA module in dracut to make sure things work also for
distributions that do not have Systemd installed.

Thanks

Roberto Sassu


> Lennart
>

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Mon, 20.02.12 19:36, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) wrote:

> 
> On 02/20/2012 06:14 PM, Lennart Poettering wrote:
> >On Wed, 15.02.12 18:12, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) wrote:
> >
> >>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?
> >
> >/etc/ima.conf or /etc/ima/ima.conf sound like obvious candidates.
> >
> 
> I prefer the first one, because the second pathname raises the problem
> of creating a new subdirectory. However, i think we should keep the
> word 'policy' in the file name to avoid users believe that is a
> configuration file.

Creating a subdir is a problem? How so?

You should use a subdir /etc/ima/ if there's the chance that sooner or
later you might have to add another config file of some sorts to IMA. If
you are really sure that never happens, then you don't need the dir, but
if you are in doubt, better use one. (But this is the policy file,
right? so i figure you might end up with adding a conf file with options
like selinux' enforcing/permissive later on, so i think you should
better add a dir)

(Oh, and in contrast to what i suggested, if this is the policy file,
and not a configuration file, the .conf suffix of course makes little sense)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/20/2012 08:07 PM, Lennart Poettering wrote:
> On Mon, 20.02.12 19:36, Roberto Sassu (roberto.sassu@polito.it) wrote:
>
>>
>> On 02/20/2012 06:14 PM, Lennart Poettering wrote:
>>> On Wed, 15.02.12 18:12, Roberto Sassu (roberto.sassu@polito.it) wrote:
>>>
>>>> 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?
>>>
>>> /etc/ima.conf or /etc/ima/ima.conf sound like obvious candidates.
>>>
>>
>> I prefer the first one, because the second pathname raises the problem
>> of creating a new subdirectory. However, i think we should keep the
>> word 'policy' in the file name to avoid users believe that is a
>> configuration file.
>
> Creating a subdir is a problem? How so?
>

The problem i see is who creates the subdirectory. In the Systemd case,
i think this should be accomplished in the Makefile or in the RPM
script. Other boot solutions should implement something like that
and they need to create the subdirectory as well. This because, as
said above, there is no an IMA userspace package to perform the
operation. However, if the creation is made by the boot software
i think this should not be a problem.


> You should use a subdir /etc/ima/ if there's the chance that sooner or
> later you might have to add another config file of some sorts to IMA. If
> you are really sure that never happens, then you don't need the dir, but
> if you are in doubt, better use one. (But this is the policy file,
> right? so i figure you might end up with adding a conf file with options
> like selinux' enforcing/permissive later on, so i think you should
> better add a dir)
>

Ok, probably is better to add a new subdirectory to support additional
IMA configuration files. Maybe Mimi Zohar knows if there are plans
to introduce new files.


> (Oh, and in contrast to what i suggested, if this is the policy file,
> and not a configuration file, the .conf suffix of course makes little sense)
>

So, finally i think we can agree to use '/etc/ima/ima-policy' as
pathname for the IMA custom policy.

Thanks

Roberto Sassu


> Lennart
>

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Wed, 15.02.12 17:26, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) wrote:

> 
> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
> >On Wed, Feb 15, 2012 at 11:23 AM, Roberto Sassu<roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org>  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.

We will sooner or later drop the per-distro ifdeffery. Please don't even
start it for new code. Given that IMA is still new, please make sure to
adopt configuration fails that are the same across all distributions.

> >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.

Sounds good.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Wed, 15.02.12 14:23, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) 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
> the path 'ima/policy' in the security filesystem. This function is executed
> at early stage in order to avoid that some file operations are not measured
> by IMA and it is placed after the initialization of SELinux because IMA
> needs the latter (or other security modules) to understand LSM-specific
> rules.

This must be a configure option. I am pretty sure most embedded people
don't require this feature.

The kernel side of things is merged upstream I presume? (We generally
only want to support stuff in our code that is merged upstream itself)

> +#define IMA_SECFS_DIR SECURITYFS_MNTPOINT "/ima"
> +#define IMA_SECFS_POLICY IMA_SECFS_DIR "/policy"

Please use proper strings for this. (see my earlier mail)

> +#define IMA_POLICY_PATH "/etc/sysconfig/ima-policy"

This is a Fedoraism. Please introduce a proper configuration file for this.

> +
> +int ima_setup(void) {
> +       struct stat st;
> +       ssize_t policy_size = 0, written = 0;
> +       char *policy;
> +       int policyfd = -1, imafd = -1;
> +       int result = 0;
> +
> +#ifndef HAVE_SELINUX
> +       /* Mount the securityfs filesystem */
> +       mount_setup_early();
> +#endif
> +
> +       if (stat(IMA_POLICY_PATH, &st) == -1)
> +               return 0;

We tend to do "< 0" instead of "== -1" checks for syscall
failures. Might be good to use the same here, but this is not necessary
for getting this merged.

> +
> +       policyfd = open(IMA_POLICY_PATH, O_RDONLY);

We tend to add O_CLOEXEC to all fds we open, just for being
paranoid. Please do so here, too, to avoid surprise and avoid exceptions
when people grep for all open() invocations looking for O_CLOEXEC.

> +       if (policyfd < 0) {
> +               log_error("Failed to open the IMA custom policy file %s (%s), "
> +                         "ignoring.", IMA_POLICY_PATH, strerror(errno));
> +               return 0;
> +       }

Consider using %m instead of %s and strerror(errno).

> +       imafd = open(IMA_SECFS_POLICY, O_WRONLY);

Also O_CLOEXEC please.

> +       if (imafd < 0) {
> +               log_error("Failed to open the IMA kernel interface %s (%s), "
> +                         "ignoring.", IMA_SECFS_POLICY, strerror(errno));
> +               goto out;
> +       }
> +
> +       policy = mmap(NULL, policy_size, PROT_READ, MAP_PRIVATE, policyfd, 0);
> +       if (policy == NULL) {

mmap() returns MAP_FAILED (i.e. (void) -1) on failure, not NULL. This
check needs to be fixed.

> +               log_error("mmap() failed (%s), freezing", strerror(errno));
> +               result = -errno;
> +               goto out;
> +       }
> +
> +       while(written < policy_size) {
> +               ssize_t len = write(imafd, policy + written,
> +                                   policy_size - written);
> +               if (len <= 0) {
> +                         log_error("Failed to load the IMA custom policy "
> +                                   "file %s (%s), ignoring.", IMA_POLICY_PATH,
> +                                   strerror(errno));
> +                         goto out_mmap;
> +               }
> +               written += len;
> +       }

It might make sense to use loop_write() here instead, which does more or
less this loop, and is defined in util.c anyway.

Otherwise looks good.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/20/2012 06:12 PM, Lennart Poettering wrote:
> On Wed, 15.02.12 14:23, Roberto Sassu (roberto.sassu@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
>> the path 'ima/policy' in the security filesystem. This function is executed
>> at early stage in order to avoid that some file operations are not measured
>> by IMA and it is placed after the initialization of SELinux because IMA
>> needs the latter (or other security modules) to understand LSM-specific
>> rules.
>
> This must be a configure option. I am pretty sure most embedded people
> don't require this feature.
>
> The kernel side of things is merged upstream I presume? (We generally
> only want to support stuff in our code that is merged upstream itself)
>

Yes. IMA was in the mainline kernel since 2.6.30.


>> +#define IMA_SECFS_DIR SECURITYFS_MNTPOINT "/ima"
>> +#define IMA_SECFS_POLICY IMA_SECFS_DIR "/policy"
>
> Please use proper strings for this. (see my earlier mail)
>

Ok, i will replace the former with the hard-coded pathname.


>> +#define IMA_POLICY_PATH "/etc/sysconfig/ima-policy"
>
> This is a Fedoraism. Please introduce a proper configuration file for this.
>

Ok, i will answer about this in the next your email.


>> +
>> +int ima_setup(void) {
>> +       struct stat st;
>> +       ssize_t policy_size = 0, written = 0;
>> +       char *policy;
>> +       int policyfd = -1, imafd = -1;
>> +       int result = 0;
>> +
>> +#ifndef HAVE_SELINUX
>> +       /* Mount the securityfs filesystem */
>> +       mount_setup_early();
>> +#endif
>> +
>> +       if (stat(IMA_POLICY_PATH,&st) == -1)
>> +               return 0;
>
> We tend to do "<  0" instead of "== -1" checks for syscall
> failures. Might be good to use the same here, but this is not necessary
> for getting this merged.
>

Ok.


>> +
>> +       policyfd = open(IMA_POLICY_PATH, O_RDONLY);
>
> We tend to add O_CLOEXEC to all fds we open, just for being
> paranoid. Please do so here, too, to avoid surprise and avoid exceptions
> when people grep for all open() invocations looking for O_CLOEXEC.
>

No problem, i will do the change.


>> +       if (policyfd<  0) {
>> +               log_error("Failed to open the IMA custom policy file %s (%s), "
>> +                         "ignoring.", IMA_POLICY_PATH, strerror(errno));
>> +               return 0;
>> +       }
>
> Consider using %m instead of %s and strerror(errno).
>
>> +       imafd = open(IMA_SECFS_POLICY, O_WRONLY);
>
> Also O_CLOEXEC please.
>
>> +       if (imafd<  0) {
>> +               log_error("Failed to open the IMA kernel interface %s (%s), "
>> +                         "ignoring.", IMA_SECFS_POLICY, strerror(errno));
>> +               goto out;
>> +       }
>> +
>> +       policy = mmap(NULL, policy_size, PROT_READ, MAP_PRIVATE, policyfd, 0);
>> +       if (policy == NULL) {
>
> mmap() returns MAP_FAILED (i.e. (void) -1) on failure, not NULL. This
> check needs to be fixed.
>

Ok, i will replace NULL with MAP_FAILED.


>> +               log_error("mmap() failed (%s), freezing", strerror(errno));
>> +               result = -errno;
>> +               goto out;
>> +       }
>> +
>> +       while(written<  policy_size) {
>> +               ssize_t len = write(imafd, policy + written,
>> +                                   policy_size - written);
>> +               if (len<= 0) {
>> +                         log_error("Failed to load the IMA custom policy "
>> +                                   "file %s (%s), ignoring.", IMA_POLICY_PATH,
>> +                                   strerror(errno));
>> +                         goto out_mmap;
>> +               }
>> +               written += len;
>> +       }
>
> It might make sense to use loop_write() here instead, which does more or
> less this loop, and is defined in util.c anyway.
>

I briefly looked at the code and i'm not sure to use it, because i want
to add some extra information in the output message (for example the
line number of the rule in the policy file that was rejected by IMA).

Thanks

Roberto Sassu


> Otherwise looks good.
>
> Lennart
>

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Lennart Poettering]

On Mon, 20.02.12 19:23, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) wrote:

> >>+               log_error("mmap() failed (%s), freezing", strerror(errno));
> >>+               result = -errno;
> >>+               goto out;
> >>+       }
> >>+
> >>+       while(written<  policy_size) {
> >>+               ssize_t len = write(imafd, policy + written,
> >>+                                   policy_size - written);
> >>+               if (len<= 0) {
> >>+                         log_error("Failed to load the IMA custom policy "
> >>+                                   "file %s (%s), ignoring.", IMA_POLICY_PATH,
> >>+                                   strerror(errno));
> >>+                         goto out_mmap;
> >>+               }
> >>+               written += len;
> >>+       }
> >
> >It might make sense to use loop_write() here instead, which does more or
> >less this loop, and is defined in util.c anyway.
> 
> I briefly looked at the code and i'm not sure to use it, because i want
> to add some extra information in the output message (for example the
> line number of the rule in the policy file that was rejected by IMA).

Line number? The policy is text? Your code above doesn't print any line
numbers?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu]

On 02/20/2012 07:52 PM, Lennart Poettering wrote:
> On Mon, 20.02.12 19:23, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) wrote:
>
>>>> +               log_error("mmap() failed (%s), freezing", strerror(errno));
>>>> +               result = -errno;
>>>> +               goto out;
>>>> +       }
>>>> +
>>>> +       while(written<   policy_size) {
>>>> +               ssize_t len = write(imafd, policy + written,
>>>> +                                   policy_size - written);
>>>> +               if (len<= 0) {
>>>> +                         log_error("Failed to load the IMA custom policy "
>>>> +                                   "file %s (%s), ignoring.", IMA_POLICY_PATH,
>>>> +                                   strerror(errno));
>>>> +                         goto out_mmap;
>>>> +               }
>>>> +               written += len;
>>>> +       }
>>>
>>> It might make sense to use loop_write() here instead, which does more or
>>> less this loop, and is defined in util.c anyway.
>>
>> I briefly looked at the code and i'm not sure to use it, because i want
>> to add some extra information in the output message (for example the
>> line number of the rule in the policy file that was rejected by IMA).
>
> Line number? The policy is text? Your code above doesn't print any line
> numbers?
>

Sorry, this is not done in the current patch. But i think it may be
useful for a user to know what rule is being rejected by IMA.
Yes, the policy is text.

Thanks

Roberto Sassu


> Lennart
>

Re: [systemd-devel] [PATCH 1/2] systemd: mount the securityfs filesystem at early stage

[Lennart Poettering]

On Wed, 15.02.12 14:23, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) wrote:

> The mount of the securityfs filesystem is now performed in the main systemd
> executable as it is used by IMA to provide the interface for loading custom
> policies. The unit file 'units/sys-kernel-security.mount' has been removed
> because it is not longer necessary.
>  
> +#define SECURITYFS_MNTPOINT "/sys/kernel/security"
> +

Just use the proper path name here. Not sure why we would want a macro
for this, as things are simpler with literal strings for this, the path
is unlikely to change and we generaly don't do this for any of the other
paths.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: [systemd-devel] [PATCH 1/2] systemd: mount the securityfs filesystem at early stage

[Roberto Sassu]

On 02/20/2012 06:04 PM, Lennart Poettering wrote:
> On Wed, 15.02.12 14:23, Roberto Sassu (roberto.sassu-8RLafaVCWuNeoWH0uzbU5w@public.gmane.org) wrote:
>
>> The mount of the securityfs filesystem is now performed in the main systemd
>> executable as it is used by IMA to provide the interface for loading custom
>> policies. The unit file 'units/sys-kernel-security.mount' has been removed
>> because it is not longer necessary.
>>
>> +#define SECURITYFS_MNTPOINT "/sys/kernel/security"
>> +
>
> Just use the proper path name here. Not sure why we would want a macro
> for this, as things are simpler with literal strings for this, the path
> is unlikely to change and we generaly don't do this for any of the other
> paths.
>

Hi Lennart

thanks for the review! I'm starting to address issues now.

I created the above macro to avoid that changing this path breaks
other code, but probably yes, its value is unlikely to change.
I will remove it.


Roberto Sassu


> Lennart
>