[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <TU4PR84MB03025BC4B8DEC44A0D63A298FFBF0@TU4PR84MB0302.NAMPRD84.PROD.OUTLOOK.COM>
Date: Fri, 28 Jul 2017 14:19:59 +0000
From: "Magalhaes, Guilherme (Brazil R&D-CL)" <guilherme.magalhaes@....com>
To: Mimi Zohar <zohar@...ux.vnet.ibm.com>,
"Serge E. Hallyn" <serge@...lyn.com>
CC: Mehmet Kayaalp <mkayaalp@...binghamton.edu>,
Yuqiong Sun <sunyuqiong1988@...il.com>,
containers <containers@...ts.linux-foundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
David Safford <david.safford@...com>,
"James Bottomley" <James.Bottomley@...senPartnership.com>,
linux-security-module <linux-security-module@...r.kernel.org>,
ima-devel <linux-ima-devel@...ts.sourceforge.net>,
Yuqiong Sun <suny@...ibm.com>
Subject: RE: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA
namespace support
> > Each measurement entry in the list could have new fields to identify
> > the namespace. Since the namespaces can be reused, a timestamp or
> > others fields could be added to uniquely identify the namespace id.
>
> The more fields included in the measurement list, the more
> measurements will be added to the measurement list. Wouldn't it be
> enough to know that a certain file has been accessed/executed on the
> system and base any analytics/forensics on the IMA-audit data.
With the recursive application of policy through the namespace hierarchy,
a measurement added to the parent namespace could be misleading since
the file pathname makes sense in the current namespace but possibly not
for the parent namespace. This is the reason why I believe some new field
might be needed in the IMA template format to indicate or uniquely
identify the namespace.
--
Guilherme
Powered by blists - more mailing lists