Can we enforce "IMA Policy" based on file type

Can we enforce "IMA Policy" based on file type

[Kavitha Sivagnanam]

Hi

I am wondering, in the current implementation of IMA policy, if there is a way to enforce appraisal on a file based on the file type.  The file type that I am interested in enforcing the policy is for SquashFS files.

We want to check the signature on the SquashFS file itself before mounting it and mark the partition as read-only. This would allow us to have the flexibility of not signing every immutable file we are installing. Also the installation process will be faster as setting extended attribute on every file is extremely time consuming process.  The signatures are generated at build time & we are using seftattr to set the security.ima attribute. 

Is it possible to achieve this with existing policy (or) we need enhancement to the current IMA code? If we need to enhance the kernel to support this feature, where would we start?

Thanks
Kavitha



Juniper Internal

Re: Can we enforce "IMA Policy" based on file type

[Matthew Garrett]

On Fri, Apr 19, 2019 at 5:08 PM Kavitha Sivagnanam <kavi@juniper.net> wrote:
>
> Hi
>
> I am wondering, in the current implementation of IMA policy, if there is a way to enforce appraisal on a file based on the file type.  The file type that I am interested in enforcing the policy is for SquashFS files.

Not directly - the kernel has no idea of what type a file has. If you
use selinux or smack then you can label squashfs files with a specific
type and then use the obj_role option in your policy. You'd also need
policy that prevents anyone else from modifying these, so depending on
what your threat model is this may not work out.

Re: Can we enforce "IMA Policy" based on file type

[Kavitha Sivagnanam]

Matt

Thanks for the response. You are pretty much confirming what we found out.
Even if I am using LSM label for squashfs files, it can only enforce IMA appraisal on files that I know about.
It will not affect any new Squashfs files for which label is not set yet.


On 4/23/19, 11:00 AM, "Matthew Garrett" <mjg59@google.com> wrote:

    On Fri, Apr 19, 2019 at 5:08 PM Kavitha Sivagnanam <kavi@juniper.net> wrote:
    >
    > Hi
    >
    > I am wondering, in the current implementation of IMA policy, if there is a way to enforce appraisal on a file based on the file type.  The file type that I am interested in enforcing the policy is for SquashFS files.
    
    Not directly - the kernel has no idea of what type a file has. If you
    use selinux or smack then you can label squashfs files with a specific
    type and then use the obj_role option in your policy. You'd also need
    policy that prevents anyone else from modifying these, so depending on
    what your threat model is this may not work out.
    

Re: Can we enforce "IMA Policy" based on file type

[Mimi Zohar]

On Fri, 2019-04-19 at 21:52 +0000, Kavitha Sivagnanam wrote:
> Hi
> 
> I am wondering, in the current implementation of IMA policy, if
> there is a way to enforce appraisal on a file based on the file
> type.  The file type that I am interested in enforcing the policy is
> for SquashFS files.
> 
> We want to check the signature on the SquashFS file itself before
> mounting it and mark the partition as read-only. This would allow us
> to have the flexibility of not signing every immutable file we are
> installing. Also the installation process will be faster as setting
> extended attribute on every file is extremely time consuming
> process.  The signatures are generated at build time & we are using
> seftattr to set the security.ima attribute. 
> 
> Is it possible to achieve this with existing policy (or) we need
> enhancement to the current IMA code? If we need to enhance the
> kernel to support this feature, where would we start?

As Matthew indicated, you could define LSM labels on the squashfs file
images.  Another option would be to extend IMA by implementing the LSM
security_sb_mount hook.  The IMA policy rule would probably look
something like:

appraise func=MOUNT_CHECK fsname=squashfs appraise_type=imasig

Mimi

RE: Can we enforce "IMA Policy" based on file type

[Kavitha Sivagnanam]

Mimi

>> Another option would be to extend IMA by implementing the LSM 
>> security_sb_mount hook

Yes, that’s exactly the feedback I was looking for.
I know that there is no existing support as of today.  But wanted to know how we can add support this.

-Kavitha 

Juniper Internal

-----Original Message-----
From: Mimi Zohar <zohar@linux.ibm.com> 
Sent: Thursday, April 25, 2019 4:59 AM
To: Kavitha Sivagnanam <kavi@juniper.net>; linux-integrity@vger.kernel.org
Subject: Re: Can we enforce "IMA Policy" based on file type

On Fri, 2019-04-19 at 21:52 +0000, Kavitha Sivagnanam wrote:
> Hi
> 
> I am wondering, in the current implementation of IMA policy, if there 
> is a way to enforce appraisal on a file based on the file type.  The 
> file type that I am interested in enforcing the policy is for SquashFS 
> files.
> 
> We want to check the signature on the SquashFS file itself before 
> mounting it and mark the partition as read-only. This would allow us 
> to have the flexibility of not signing every immutable file we are 
> installing. Also the installation process will be faster as setting 
> extended attribute on every file is extremely time consuming process.  
> The signatures are generated at build time & we are using seftattr to 
> set the security.ima attribute.
> 
> Is it possible to achieve this with existing policy (or) we need 
> enhancement to the current IMA code? If we need to enhance the kernel 
> to support this feature, where would we start?

As Matthew indicated, you could define LSM labels on the squashfs file images.  Another option would be to extend IMA by implementing the LSM security_sb_mount hook.  The IMA policy rule would probably look something like:

appraise func=MOUNT_CHECK fsname=squashfs appraise_type=imasig

Mimi

Re: Can we enforce "IMA Policy" based on file type

[Nayna]

On 04/25/2019 01:07 PM, Kavitha Sivagnanam wrote:
> Mimi
>
>>> Another option would be to extend IMA by implementing the LSM
>>> security_sb_mount hook
> Yes, that’s exactly the feedback I was looking for.
> I know that there is no existing support as of today.  But wanted to know how we can add support this.

Adding this support shouldn't be too difficult. You can start from IMA 
policy code in security/integrity/ima_policy.c.

And just a reminder, please keep your responses as inline/bottom post.

Thanks & Regards,
      - Nayna

>
> -Kavitha
>
> Juniper Internal
>
>

Re: Can we enforce "IMA Policy" based on file type

[Kavitha Sivagnanam]

On 4/25/19, 4:59 AM, "Mimi Zohar" <zohar@linux.ibm.com> wrote:

>    As Matthew indicated, you could define LSM labels on the squashfs file
>   images.  Another option would be to extend IMA by implementing the LSM
>    security_sb_mount hook.  The IMA policy rule would probably look
>   something like:

We looked in to the security_sb_mount function. It receives the device name as string "const char *dev_name".
We need to do the IMA appraisal on the backing file (squashfs file) associated with this device.
However, based on this device name we were unable to get the backing_file associated with it in kernel space.
Can you give some pointers? 

Also, we need to know if at the time when this function is called, if the backing file is associated with this device.

>    appraise func=MOUNT_CHECK fsname=squashfs appraise_type=imasig
  
  
    

Re: Can we enforce "IMA Policy" based on file type

[Mimi Zohar]

On Tue, 2019-06-25 at 21:35 +0000, Kavitha Sivagnanam wrote:
> 
> On 4/25/19, 4:59 AM, "Mimi Zohar" <zohar@linux.ibm.com> wrote:
> 
> >    As Matthew indicated, you could define LSM labels on the squashfs file
> >   images.  Another option would be to extend IMA by implementing the LSM
> >    security_sb_mount hook.  The IMA policy rule would probably look
> >   something like:
> 
> We looked in to the security_sb_mount function. It receives the
> device name as string "const char *dev_name".  We need to do the IMA
> appraisal on the backing file (squashfs file) associated with this
> device.  However, based on this device name we were unable to get
> the backing_file associated with it in kernel space.
> Can you give some pointers? 
> 
> Also, we need to know if at the time when this function is called,
> if the backing file is associated with this device.
> 
> >    appraise func=MOUNT_CHECK fsname=squashfs appraise_type=imasig

When the squashfs file is loopback mounted, the backing file is set in
drivers/block/loop.c: loop_set_fd() and stored as lo->lo_backing_file.

Although security_sb_mount() is called after setting the backing file,
it seems to be too early.  You probably need to wait until after
fill_super().  Try using security_sb_kern_mount().

Mimi