Re: [Linux-ima-user] [RFC 04/11] ima: add support to namespace securityfs file

[Magalhaes, G. (B. R&D-CL) <gui...@hp...>]

Hi,
Any feedback about this?
If you agree with the overall proposal I can send a RFC/patch so we can discuss the details.

Thanks.

--
Guilherme

> -----Original Message-----
> From: Magalhaes, Guilherme (Brazil R&D-CL)
> Sent: quinta-feira, 10 de agosto de 2017 11:17
> To: 'Mimi Zohar' <zo...@li...>
> Cc: lin...@li...; lin...@li...
> Subject: RE: [RFC 04/11] ima: add support to namespace securityfs file
> 
> Hi Mimi,
> 
> > The namespacing design will need to support different types of
> > environments. For example, depending on the environment, namespaces
> > can come and go frequently. In such an environment do we really want
> > all the namespace measurements to be included in the system
> > measurement list, or should each namespace have its own measurement
> > list?  Should the namespace measurement policy be the same as the
> > system measurement policy?  Should the namespace (container) owner be
> > allowed to modify their own policy?  If a file matches a rule in both
> > the namespace and system policies, should the file measurement be in
> > both the namespace and the system measurement lists?
> 
> Based on our previous discussions, the IMA policy should be set
> independently for different namespaces and each namespace will have a
> measurement list.
> 
> Based on that and considering now the issues related to namespacing the
> IMA policy interface, this interface to set policy in the host and inside
> namespaces could be solved entirely by leveraging the existent policy file.
> IMA then would detect the current namespace and assume the rules are
> added to that namespace. The root user, even when mapped to a non-root
> user outside the namespace, is able to set the namespace policy just like it
> is done in the host policy.
> 
> Once the namespace policy is set, the same policy rules should be read back
> from the policy file, with the same uids that were set in the rule and that
> make sense inside the current user namespace, not the mapped uid to the
> 'kernel' uid. This point is important because currently the uids in the IMA
> policy rules are mapped to kernel uids at parsing time.
> 
> Another required change for this proposed interface to set the policy is to
> allow read/write access to the policy file to all users, since a root user in a
> given user namespace may not be a root user outside that user namespace.
> The kernel would still block access to the policy file based on the
> SYS_ADMIN capability and any changes to the policy would be effective just
> for the current namespace.
> 
> The securityfs access inside user namespaces is possible once the user id
> mapping is done correctly, the root user, as seen inside the namespace will
> be able to mount the securityfs. Again, the read/write access to all users
> must be granted for the policy file.
> 
> The same changes could be made to the measurement list interface in
> securityfs when each namespace has its own measurement list.
> 
> A management tool in user space might be very helpful to set or read the
> policy or measurement list files in the current namespace or its children
> namespaces and to map the uid considering the current and target
> namespaces. This tool could also relate containers in user space to its IMA
> state for policy and appraise mode.
> 
> Does this design solve properly the basic architectural issues only related
> to namespacing the interface to set the IMA policy? I have a patch with
> these changes ready to be posted.
> 
> --
> Guilherme
> 
> 
> > -----Original Message-----
> > From: Mimi Zohar [mailto:zo...@li...]
> > Sent: segunda-feira, 29 de maio de 2017 14:33
> > To: Magalhaes, Guilherme (Brazil R&D-CL)
> <gui...@hp...>;
> > John Johansen <joh...@ca...>; dmi...@gm...
> > Cc: vi...@ze...; jam...@or...; se...@ha...;
> > lin...@vg...; lin...@vg...; linux-ima-
> > de...@li...; lin...@li...; linux-
> > sec...@vg...; ty...@do...; Souza, Joaquim (Brazil
> > R&D-ECL) <joa...@hp...>; Edwards, Nigel <nig...@hp...>
> > Subject: Re: [RFC 04/11] ima: add support to namespace securityfs file
> >
> > Hi Guilherme,
> >
> > (Wow, you should did Cc a lot of people.)
> >
> > On Thu, 2017-05-25 at 19:04 +0000, Magalhaes, Guilherme (Brazil R&D-
> > CL) wrote:
> > > Mimi,
> > > With the securityfs symlink we would address the case of setting
> > > policy inside containers, but we still would need a way to set the
> > > IMA policy per namespace outside containers. So, the current
> > > proposed interface would address the latter case.
> > > As an alternative to symlinks, taking this patch set as base, and
> > > still considering setting policy inside containers (or inside
> > > namespaces in general), it is possible to bind mount the securityfs
> > > files into the containers, but it would be needed to prevent
> > > read/write access to the namespaced IMA policy files for processes
> > > not running on the same namespace.
> > >
> > > These mechanisms would not require a change in the proposed design.
> > > Do you think these mechanisms are enough for the flexibility you
> > > asked?
> >
> > I'm really sorry Guileherme, but as I previously explained, IMA has
> > many aspects to it - the original file measurements (IMA-measurement),
> > file hash/signature appraisal (IMA-appraisal), and file audit messages
> > (IMA-audit) used for security analytics/forensics, not the file system
> > auditing.  To namespace IMA properly requires addressing some
> > underlying problems - securityfs, root privilege required for writing
> > security xattrs, per namespace IMA keyring - to name a few.
> >
> > I understand wanting to namespace the appraisal aspect first, but when
> > you asked me if anyone else is working on namespacing IMA at the
> > moment, I suggested starting with the IMA-audit aspect for a
> > reason.  By beginning with the IMA-audit aspect, we could ignore, at
> > least for the time being, some of these underlying problems, but
> > define the basic namespacing architecture.  By jumping to namespacing
> > the appraisal aspect, you've simply avoided addressing the IMA
> > namespacing architecture issues, which need to be addressed.
> >
> > Here are some, not by any means all, of the issues with namespacing
> > IMA.
> >
> >
> > - IMA-measurements:
> >
> > The namespacing design will need to support different types of
> > environments. For example, depending on the environment, namespaces
> > can come and go frequently. In such an environment do we really want
> > all the namespace measurements to be included in the system
> > measurement list, or should each namespace have its own measurement
> > list?  Should the namespace measurement policy be the same as the
> > system measurement policy?  Should the namespace (container) owner be
> > allowed to modify their own policy?  If a file matches a rule in both
> > the namespace and system policies, should the file measurement be in
> > both the namespace and the system measurement lists?
> >
> >
> > - IMA-appraisal
> >
> > Assuming the IMA appraisal policy requires file signatures, signatures
> > are verified based on the keys on the IMA keyring.  When discussing
> > namespacing IMA-appraisal, we might want different sets of keys in
> > different namespaces. This requires separate keyrings for each
> > namespace.  In some use cases, we might want to include the keys on
> > the system IMA keyring, while in other use cases we might not.
> >
> > Even if real root initially installs the files with their file
> > signatures, stored as extended attributes, how will software be
> > updated, as writing file signatures requires root
> > privilege?Capabilities has recently added support to permit root in
> > the namespace to write security.capability.  Similarly when
> > namespacing IMA, root in the namespace needs the ability to write
> > security.ima.
> >
> >
> > - IMA-audit:
> >
> > The IMA-audit messages can augment other file system security
> > information used in security analytics/forensics.  This information
> > should be on a per namespace basis, meaning that each time a new file
> > is accessed/executed, there needs to be a separate audit message, even
> > if a message already exists in another namespace.  Maintaining and
> > cleaning up this per namespace cache information, allows development
> > of the IMA namespace architecture independently of other issues.
> >
> > My original suggestion stands.  Start with namespacing IMA-
> > audit.  Afterwards resolve the securityfs issues needed for
> > namespacing IMA-measurement, and subsequently resolve the keyring and
> > xattr issues for namespacing IMA-appraisal. Although other subsystems
> > have already addressed some of the issues listed here, the advice to
> > start with IMA-audit is still valid.
> >
> > Small incremental change does not imply without an overall design, but
> > an overall design which is broken up in such a way (to ease review)
> > that builds upon the previous change.
> >
> > As both Apparmor and IMA use securityfs for policy, it would be nice
> > if their method for loading namespace policies would be similar too.
> >
> > Mimi