[RFC,17/20] ima: Use integrity_admin_ns_capable() to check corresponding capability

Commit Message

Stefan Berger Nov. 30, 2021, 4:06 p.m. UTC

From: Denis Semakin <[e-mail]>

Use integrity_admin_ns_capable() to check corresponding capability to
allow read/write IMA policy without CAP_SYS_ADMIN but with
CAP_INTEGRITY_ADMIN.

Signed-off-by: Denis Semakin <[e-mail]>
---
 security/integrity/ima/ima_fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

James Bottomley Dec. 1, 2021, 4:58 p.m. UTC | #1

On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
> From: Denis Semakin <[e-mail]>
> 
> Use integrity_admin_ns_capable() to check corresponding capability to
> allow read/write IMA policy without CAP_SYS_ADMIN but with
> CAP_INTEGRITY_ADMIN.
> 
> Signed-off-by: Denis Semakin <[e-mail]>
> ---
>  security/integrity/ima/ima_fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/integrity/ima/ima_fs.c
> b/security/integrity/ima/ima_fs.c
> index fd2798f2d224..6766bb8262f2 100644
> --- a/security/integrity/ima/ima_fs.c
> +++ b/security/integrity/ima/ima_fs.c
> @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode *inode,
> struct file *filp)
>  #else
>  		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
>  			return -EACCES;
> -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
> +		if (!integrity_admin_ns_capable(ns->user_ns))

so this one is basically replacing what you did in RFC 16/20, which
seems a little redundant.

The question I'd like to ask is: is there still a reason for needing
CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty much tied
to requiring a user (and a mount, because of securityfs_ns) namespace,
there might not be a pressing need for an admin capability separated
from CAP_SYS_ADMIN because the owner of the user namespace passes the
ns_capable(..., CAP_SYS_ADMIN) check.  The rationale in 

https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations

Is effectively "because CAP_SYS_ADMIN is too powerful" but that's no
longer true of the user namespace owner.  It only passes the ns_capable
() check not the capable() one, so while it does get CAP_SYS_ADMIN, it
can only use it in a few situations which represent quite a power
reduction already.

James

Stefan Berger Dec. 1, 2021, 5:35 p.m. UTC | #2

On 12/1/21 11:58, James Bottomley wrote:
> On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
>> From: Denis Semakin <[e-mail]>
>>
>> Use integrity_admin_ns_capable() to check corresponding capability to
>> allow read/write IMA policy without CAP_SYS_ADMIN but with
>> CAP_INTEGRITY_ADMIN.
>>
>> Signed-off-by: Denis Semakin <[e-mail]>
>> ---
>>   security/integrity/ima/ima_fs.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/security/integrity/ima/ima_fs.c
>> b/security/integrity/ima/ima_fs.c
>> index fd2798f2d224..6766bb8262f2 100644
>> --- a/security/integrity/ima/ima_fs.c
>> +++ b/security/integrity/ima/ima_fs.c
>> @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode *inode,
>> struct file *filp)
>>   #else
>>   		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
>>   			return -EACCES;
>> -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
>> +		if (!integrity_admin_ns_capable(ns->user_ns))
> so this one is basically replacing what you did in RFC 16/20, which
> seems a little redundant.
>
> The question I'd like to ask is: is there still a reason for needing
> CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty much tied
> to requiring a user (and a mount, because of securityfs_ns) namespace,
> there might not be a pressing need for an admin capability separated
> from CAP_SYS_ADMIN because the owner of the user namespace passes the
> ns_capable(..., CAP_SYS_ADMIN) check.  The rationale in

Casey suggested using CAP_MAC_ADMIN, which I think would also work.

     CAP_MAC_ADMIN (since Linux 2.6.25)
               Allow MAC configuration or state changes. Implemented for
               the Smack Linux Security Module (LSM).


Down the road I think we should cover setting file extended attributes 
with the same capability as well for when a user signs files or installs 
packages with file signatures.  A container runtime could hold 
CAP_SYS_ADMIN while setting up a container and mounting filesystems and 
drop it for the first process started there. Since we are using the user 
namespace to spawn an IMA namespace, we would then require 
CAP_SYSTEM_ADMIN to be left available so that the user can do IMA 
related stuff in the container (set or append to the policy, write file 
signatures). I am not sure whether that should be the case or rather 
give the user something finer grained, such as CAP_MAC_ADMIN. So, it's 
about granularity...


>
> https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
>
> Is effectively "because CAP_SYS_ADMIN is too powerful" but that's no
> longer true of the user namespace owner.  It only passes the ns_capable
> () check not the capable() one, so while it does get CAP_SYS_ADMIN, it
> can only use it in a few situations which represent quite a power
> reduction already.

At least docker containers drop CAP_SYS_ADMIN. I am not sure what the 
decision was based on but probably they don't want to give the user what 
is not absolutely necessary, but usage of user namespaces (with IMA 
namespaces) would kind of force it to be available then to do 
IMA-related stuff ...

Following this man page here 
https://man7.org/linux/man-pages/man7/user_namespaces.7.html

CAP_SYS_ADMIN in a user namespace is about

- bind-mounting filesystems

- mounting /proc filesystems

- creating nested user namespaces

- configuring UTS namespace

- configuring whether setgroups() can be used

- usage of setns()


Do we want to add '- only way of *setting up* IMA related stuff' to this 
list?

   Stefan


>
> James
>
>

James Bottomley Dec. 1, 2021, 7:29 p.m. UTC | #3

On Wed, 2021-12-01 at 12:35 -0500, Stefan Berger wrote:
> On 12/1/21 11:58, James Bottomley wrote:
> > On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
> > > From: Denis Semakin <[e-mail]>
> > > 
> > > Use integrity_admin_ns_capable() to check corresponding
> > > capability to allow read/write IMA policy without CAP_SYS_ADMIN
> > > but with CAP_INTEGRITY_ADMIN.
> > > 
> > > Signed-off-by: Denis Semakin <[e-mail]>
> > > ---
> > >   security/integrity/ima/ima_fs.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/security/integrity/ima/ima_fs.c
> > > b/security/integrity/ima/ima_fs.c
> > > index fd2798f2d224..6766bb8262f2 100644
> > > --- a/security/integrity/ima/ima_fs.c
> > > +++ b/security/integrity/ima/ima_fs.c
> > > @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode
> > > *inode,
> > > struct file *filp)
> > >   #else
> > >   		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
> > >   			return -EACCES;
> > > -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
> > > +		if (!integrity_admin_ns_capable(ns->user_ns))
> > so this one is basically replacing what you did in RFC 16/20, which
> > seems a little redundant.
> > 
> > The question I'd like to ask is: is there still a reason for
> > needing CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty
> > much tied to requiring a user (and a mount, because of
> > securityfs_ns) namespace, there might not be a pressing need for an
> > admin capability separated from CAP_SYS_ADMIN because the owner of
> > the user namespace passes the ns_capable(..., CAP_SYS_ADMIN)
> > check.  The rationale in
> 
> Casey suggested using CAP_MAC_ADMIN, which I think would also work.
> 
>      CAP_MAC_ADMIN (since Linux 2.6.25)
>                Allow MAC configuration or state changes. Implemented
> for
>                the Smack Linux Security Module (LSM).
> 
> 
> Down the road I think we should cover setting file extended
> attributes with the same capability as well for when a user signs
> files or installs packages with file signatures.  A container runtime
> could hold CAP_SYS_ADMIN while setting up a container and mounting
> filesystems and drop it for the first process started there. Since we
> are using the user namespace to spawn an IMA namespace, we would then
> require CAP_SYSTEM_ADMIN to be left available so that the user can do
> IMA related stuff in the container (set or append to the policy,
> write file signatures). I am not sure whether that should be the case
> or rather give the user something finer grained, such as
> CAP_MAC_ADMIN. So, it's about granularity...

It's possible ... any orchestration system that doesn't enter a user
namespace has to strictly regulate capabilities.   I'm probably biased
because I always use a user_ns so I never really had to mess with
capabilities.

> > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
> > 
> > Is effectively "because CAP_SYS_ADMIN is too powerful" but that's
> > no longer true of the user namespace owner.  It only passes the
> > ns_capable() check not the capable() one, so while it does get
> > CAP_SYS_ADMIN, it can only use it in a few situations which
> > represent quite a power reduction already.
> 
> At least docker containers drop CAP_SYS_ADMIN.

Well docker doesn't use the user_ns.  But even given that,
CAP_SYS_ADMIN is always dropped for most container systems.  What
happens when you enter a user namespace is the ns_capable( ...,
CAP_SYS_ADMIN) check returns true if you're the owner of the user_ns,
in the same way it would for root.  So effectively entering a user
namespace without CAP_SYS_ADMIN but mapping the owner id to 0 (what
unshare -r --user does) gives you back a form of CAP_SYS_ADMIN that
responds only in the places in the kernel that have a ns_capable()
check instead of a capable() one (most of the places you list below). 
This is the principle of how unprivileged containers actually work ...
and the source of some of our security problems if you get back an
ability to do something you shouldn't be allowed to do as an
unprivileged user.

>  I am not sure what the decision was based on but probably they don't
> want to give the user what is not absolutely necessary, but usage of
> user namespaces (with IMA namespaces) would kind of force it to be
> available then to do IMA-related stuff ...
> 
> Following this man page here 
> https://man7.org/linux/man-pages/man7/user_namespaces.7.html
> 
> CAP_SYS_ADMIN in a user namespace is about
> 
> - bind-mounting filesystems
> 
> - mounting /proc filesystems
> 
> - creating nested user namespaces
> 
> - configuring UTS namespace
> 
> - configuring whether setgroups() can be used
> 
> - usage of setns()
> 
> 
> Do we want to add '- only way of *setting up* IMA related stuff' to
> this list?

I don't see why not, but other container people should weigh in
because, as I said, I mostly use the user namespace and unprivileged
containers and don't bother with capabilities.

James

Denis Semakin Dec. 2, 2021, 7:16 a.m. UTC | #4

Obviously the main goal by adding new capability was to avoid the using CAP_SYS_ADMIN (IOW superuser)
to manage IMA stuff, that was also about security granularity.  It's good if CAP_MAC_ADMIN will be enough for doing IMA related things (write policies and extended attributes).
But for me it's a little bit unclear how to deal with unprivileged users: assuming there's no CAP_INTEGRITY_ADMIN but CAP_MAC_ADMIN was set up, so in this case user can control any LSM (seLinux, SMACK, etc) and IMA (policies, xattrs). What if .. for some systems there would be some requirements that will allow to touch LSM but do not change any IMA (integrity) things? A user can set up any IMA policy (it's about the system integrity), modify IMA related xattrs but it's forbidden to change seLinux policies and e.g. SMACK labels... May be it's unreal scenario of course... but I guess it's not 100% impossible.

Best regards,
Denis


-----Original Message-----
From: James Bottomley [mailto:[e-mail]] 
Sent: Wednesday, December 1, 2021 10:29 PM
To: Stefan Berger <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Krzysztof Struczynski <[e-mail]>; Roberto Sassu <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Denis Semakin <[e-mail]>
Subject: Re: [RFC 17/20] ima: Use integrity_admin_ns_capable() to check corresponding capability

On Wed, 2021-12-01 at 12:35 -0500, Stefan Berger wrote:
> On 12/1/21 11:58, James Bottomley wrote:
> > On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
> > > From: Denis Semakin <[e-mail]>
> > > 
> > > Use integrity_admin_ns_capable() to check corresponding capability 
> > > to allow read/write IMA policy without CAP_SYS_ADMIN but with 
> > > CAP_INTEGRITY_ADMIN.
> > > 
> > > Signed-off-by: Denis Semakin <[e-mail]>
> > > ---
> > >   security/integrity/ima/ima_fs.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/security/integrity/ima/ima_fs.c 
> > > b/security/integrity/ima/ima_fs.c index fd2798f2d224..6766bb8262f2 
> > > 100644
> > > --- a/security/integrity/ima/ima_fs.c
> > > +++ b/security/integrity/ima/ima_fs.c
> > > @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode 
> > > *inode, struct file *filp)
> > >   #else
> > >   		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
> > >   			return -EACCES;
> > > -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
> > > +		if (!integrity_admin_ns_capable(ns->user_ns))
> > so this one is basically replacing what you did in RFC 16/20, which 
> > seems a little redundant.
> > 
> > The question I'd like to ask is: is there still a reason for needing 
> > CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty much 
> > tied to requiring a user (and a mount, because of
> > securityfs_ns) namespace, there might not be a pressing need for an 
> > admin capability separated from CAP_SYS_ADMIN because the owner of 
> > the user namespace passes the ns_capable(..., CAP_SYS_ADMIN) check.  
> > The rationale in
> 
> Casey suggested using CAP_MAC_ADMIN, which I think would also work.
> 
>      CAP_MAC_ADMIN (since Linux 2.6.25)
>                Allow MAC configuration or state changes. Implemented 
> for
>                the Smack Linux Security Module (LSM).
> 
> 
> Down the road I think we should cover setting file extended attributes 
> with the same capability as well for when a user signs files or 
> installs packages with file signatures.  A container runtime could 
> hold CAP_SYS_ADMIN while setting up a container and mounting 
> filesystems and drop it for the first process started there. Since we 
> are using the user namespace to spawn an IMA namespace, we would then 
> require CAP_SYSTEM_ADMIN to be left available so that the user can do 
> IMA related stuff in the container (set or append to the policy, write 
> file signatures). I am not sure whether that should be the case or 
> rather give the user something finer grained, such as CAP_MAC_ADMIN. 
> So, it's about granularity...

It's possible ... any orchestration system that doesn't enter a user
namespace has to strictly regulate capabilities.   I'm probably biased
because I always use a user_ns so I never really had to mess with capabilities.

> > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerat
> > ions
> > 
> > Is effectively "because CAP_SYS_ADMIN is too powerful" but that's no 
> > longer true of the user namespace owner.  It only passes the
> > ns_capable() check not the capable() one, so while it does get 
> > CAP_SYS_ADMIN, it can only use it in a few situations which 
> > represent quite a power reduction already.
> 
> At least docker containers drop CAP_SYS_ADMIN.

Well docker doesn't use the user_ns.  But even given that, CAP_SYS_ADMIN is always dropped for most container systems.  What happens when you enter a user namespace is the ns_capable( ...,
CAP_SYS_ADMIN) check returns true if you're the owner of the user_ns, in the same way it would for root.  So effectively entering a user namespace without CAP_SYS_ADMIN but mapping the owner id to 0 (what unshare -r --user does) gives you back a form of CAP_SYS_ADMIN that responds only in the places in the kernel that have a ns_capable() check instead of a capable() one (most of the places you list below). 
This is the principle of how unprivileged containers actually work ...
and the source of some of our security problems if you get back an ability to do something you shouldn't be allowed to do as an unprivileged user.

>  I am not sure what the decision was based on but probably they don't 
> want to give the user what is not absolutely necessary, but usage of 
> user namespaces (with IMA namespaces) would kind of force it to be 
> available then to do IMA-related stuff ...
> 
> Following this man page here
> https://man7.org/linux/man-pages/man7/user_namespaces.7.html
> 
> CAP_SYS_ADMIN in a user namespace is about
> 
> - bind-mounting filesystems
> 
> - mounting /proc filesystems
> 
> - creating nested user namespaces
> 
> - configuring UTS namespace
> 
> - configuring whether setgroups() can be used
> 
> - usage of setns()
> 
> 
> Do we want to add '- only way of *setting up* IMA related stuff' to 
> this list?

I don't see why not, but other container people should weigh in because, as I said, I mostly use the user namespace and unprivileged containers and don't bother with capabilities.

James

James Bottomley Dec. 2, 2021, 12:33 p.m. UTC | #5

On Thu, 2021-12-02 at 07:16 +0000, Denis Semakin wrote:
> Obviously the main goal by adding new capability was to avoid the
> using CAP_SYS_ADMIN (IOW superuser)

OK, but as I've said a couple of times now: the check for CAP_SYS_ADMIN
doesn't have to be monolithic like this.  We have two sets of checks in
the kernel: capable(..., CAP_SYS_ADMIN) which is for the global
monolithic root like capability and ns_capable(..., CAP_SYS_ADMIN)
which is for the owner (possibly unprivileged) of the user namespace.

This gives us a way of parsing out admin capabilites into the small
subset that the user namespace needs.  Patch 16 changed the check from
capable to ns_capable, meaning it's no longer the monolithic
CAP_SYS_ADMIN.

> to manage IMA stuff, that was also about security granularity.  It's
> good if CAP_MAC_ADMIN will be enough for doing IMA related things
> (write policies and extended attributes).

To be honest, as long as the check resolves to ns_capable(...,
CAP_SYS_<SOMETHING>) I'm not that bothered because the owner of the
user namespace will still pass the check.

> But for me it's a little bit unclear how to deal with unprivileged
> users: assuming there's no CAP_INTEGRITY_ADMIN but CAP_MAC_ADMIN was
> set up, so in this case user can control any LSM (seLinux, SMACK,
> etc) and IMA (policies, xattrs). What if .. for some systems there
> would be some requirements that will allow to touch LSM but do not
> change any IMA (integrity) things? A user can set up any IMA policy
> (it's about the system integrity), modify IMA related xattrs but it's
> forbidden to change seLinux policies and e.g. SMACK labels... May be
> it's unreal scenario of course... but I guess it's not 100%
> impossible.

This is why looking at it as a switch from capable to ns_capable is
useful: an ordinary user can assume ns_capable(..., CAP_SYS_ADMIN)
powers arbitrarily, so its a significant check on where you can make
the switch.

James

Christian Brauner Dec. 2, 2021, 12:59 p.m. UTC | #6

On Wed, Dec 01, 2021 at 02:29:09PM -0500, James Bottomley wrote:
> On Wed, 2021-12-01 at 12:35 -0500, Stefan Berger wrote:
> > On 12/1/21 11:58, James Bottomley wrote:
> > > On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
> > > > From: Denis Semakin <[e-mail]>
> > > > 
> > > > Use integrity_admin_ns_capable() to check corresponding
> > > > capability to allow read/write IMA policy without CAP_SYS_ADMIN
> > > > but with CAP_INTEGRITY_ADMIN.
> > > > 
> > > > Signed-off-by: Denis Semakin <[e-mail]>
> > > > ---
> > > >   security/integrity/ima/ima_fs.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/security/integrity/ima/ima_fs.c
> > > > b/security/integrity/ima/ima_fs.c
> > > > index fd2798f2d224..6766bb8262f2 100644
> > > > --- a/security/integrity/ima/ima_fs.c
> > > > +++ b/security/integrity/ima/ima_fs.c
> > > > @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode
> > > > *inode,
> > > > struct file *filp)
> > > >   #else
> > > >   		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
> > > >   			return -EACCES;
> > > > -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
> > > > +		if (!integrity_admin_ns_capable(ns->user_ns))
> > > so this one is basically replacing what you did in RFC 16/20, which
> > > seems a little redundant.
> > > 
> > > The question I'd like to ask is: is there still a reason for
> > > needing CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty
> > > much tied to requiring a user (and a mount, because of
> > > securityfs_ns) namespace, there might not be a pressing need for an
> > > admin capability separated from CAP_SYS_ADMIN because the owner of
> > > the user namespace passes the ns_capable(..., CAP_SYS_ADMIN)
> > > check.  The rationale in
> > 
> > Casey suggested using CAP_MAC_ADMIN, which I think would also work.
> > 
> >      CAP_MAC_ADMIN (since Linux 2.6.25)
> >                Allow MAC configuration or state changes. Implemented
> > for
> >                the Smack Linux Security Module (LSM).
> > 
> > 
> > Down the road I think we should cover setting file extended
> > attributes with the same capability as well for when a user signs
> > files or installs packages with file signatures.  A container runtime
> > could hold CAP_SYS_ADMIN while setting up a container and mounting
> > filesystems and drop it for the first process started there. Since we
> > are using the user namespace to spawn an IMA namespace, we would then
> > require CAP_SYSTEM_ADMIN to be left available so that the user can do
> > IMA related stuff in the container (set or append to the policy,
> > write file signatures). I am not sure whether that should be the case
> > or rather give the user something finer grained, such as
> > CAP_MAC_ADMIN. So, it's about granularity...
> 
> It's possible ... any orchestration system that doesn't enter a user
> namespace has to strictly regulate capabilities.   I'm probably biased
> because I always use a user_ns so I never really had to mess with
> capabilities.
> 
> > > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
> > > 
> > > Is effectively "because CAP_SYS_ADMIN is too powerful" but that's
> > > no longer true of the user namespace owner.  It only passes the
> > > ns_capable() check not the capable() one, so while it does get
> > > CAP_SYS_ADMIN, it can only use it in a few situations which
> > > represent quite a power reduction already.
> > 
> > At least docker containers drop CAP_SYS_ADMIN.
> 
> Well docker doesn't use the user_ns.  But even given that,
> CAP_SYS_ADMIN is always dropped for most container systems.  What
> happens when you enter a user namespace is the ns_capable( ...,
> CAP_SYS_ADMIN) check returns true if you're the owner of the user_ns,
> in the same way it would for root.  So effectively entering a user
> namespace without CAP_SYS_ADMIN but mapping the owner id to 0 (what
> unshare -r --user does) gives you back a form of CAP_SYS_ADMIN that
> responds only in the places in the kernel that have a ns_capable()
> check instead of a capable() one (most of the places you list below). 
> This is the principle of how unprivileged containers actually work ...
> and the source of some of our security problems if you get back an
> ability to do something you shouldn't be allowed to do as an
> unprivileged user.
> 
> >  I am not sure what the decision was based on but probably they don't
> > want to give the user what is not absolutely necessary, but usage of
> > user namespaces (with IMA namespaces) would kind of force it to be
> > available then to do IMA-related stuff ...
> > 
> > Following this man page here 
> > https://man7.org/linux/man-pages/man7/user_namespaces.7.html
> > 
> > CAP_SYS_ADMIN in a user namespace is about
> > 
> > - bind-mounting filesystems
> > 
> > - mounting /proc filesystems
> > 
> > - creating nested user namespaces
> > 
> > - configuring UTS namespace
> > 
> > - configuring whether setgroups() can be used
> > 
> > - usage of setns()
> > 
> > 
> > Do we want to add '- only way of *setting up* IMA related stuff' to
> > this list?
> 
> I don't see why not, but other container people should weigh in
> because, as I said, I mostly use the user namespace and unprivileged
> containers and don't bother with capabilities.

There are very few scenarios where dropping capabilities in an
unprivileged container makes sense. In a lot of other scenarios it is
just a misunderstanding of the meaning of capabilities and their
relationship to user namespaces. Usually, granting a full set of
capabilities to the payload of an unprivigileged container is the right
thing to do. All things that are properly namespaced will check
capabilities in the relevant user namespace. Those that aren't will
check them against the initial user namespaces.

But I do think the question of whether or not ima should go into
cap_sys_admin is more a question of capability semantics then it is in
how exactly ima is namespaced. We do have agreed before that overloading
cap_sys_admin further isn't ideal. Often we end up rectifying that
mistake later. For example, how we moved stuff like criu, bpf, and perf
to their own capability. Now we're left with stuff like:

static inline bool perfmon_capable(void)
{
	return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
}

static inline bool bpf_capable(void)
{
	return capable(CAP_BPF) || capable(CAP_SYS_ADMIN);
}

static inline bool checkpoint_restore_ns_capable(struct user_namespace *ns)
{
	return ns_capable(ns, CAP_CHECKPOINT_RESTORE) ||
		ns_capable(ns, CAP_SYS_ADMIN);
}

for the sake of adhering to legacy behavior. I think we can skip over
that mistake and introduce cap_sys_integrity.

Christian

Christian Brauner Dec. 2, 2021, 1:01 p.m. UTC | #7

On Thu, Dec 02, 2021 at 01:59:55PM +0100, Christian Brauner wrote:
> On Wed, Dec 01, 2021 at 02:29:09PM -0500, James Bottomley wrote:
> > On Wed, 2021-12-01 at 12:35 -0500, Stefan Berger wrote:
> > > On 12/1/21 11:58, James Bottomley wrote:
> > > > On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
> > > > > From: Denis Semakin <[e-mail]>
> > > > > 
> > > > > Use integrity_admin_ns_capable() to check corresponding
> > > > > capability to allow read/write IMA policy without CAP_SYS_ADMIN
> > > > > but with CAP_INTEGRITY_ADMIN.
> > > > > 
> > > > > Signed-off-by: Denis Semakin <[e-mail]>
> > > > > ---
> > > > >   security/integrity/ima/ima_fs.c | 2 +-
> > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/security/integrity/ima/ima_fs.c
> > > > > b/security/integrity/ima/ima_fs.c
> > > > > index fd2798f2d224..6766bb8262f2 100644
> > > > > --- a/security/integrity/ima/ima_fs.c
> > > > > +++ b/security/integrity/ima/ima_fs.c
> > > > > @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode
> > > > > *inode,
> > > > > struct file *filp)
> > > > >   #else
> > > > >   		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
> > > > >   			return -EACCES;
> > > > > -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
> > > > > +		if (!integrity_admin_ns_capable(ns->user_ns))
> > > > so this one is basically replacing what you did in RFC 16/20, which
> > > > seems a little redundant.
> > > > 
> > > > The question I'd like to ask is: is there still a reason for
> > > > needing CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty
> > > > much tied to requiring a user (and a mount, because of
> > > > securityfs_ns) namespace, there might not be a pressing need for an
> > > > admin capability separated from CAP_SYS_ADMIN because the owner of
> > > > the user namespace passes the ns_capable(..., CAP_SYS_ADMIN)
> > > > check.  The rationale in
> > > 
> > > Casey suggested using CAP_MAC_ADMIN, which I think would also work.
> > > 
> > >      CAP_MAC_ADMIN (since Linux 2.6.25)
> > >                Allow MAC configuration or state changes. Implemented
> > > for
> > >                the Smack Linux Security Module (LSM).
> > > 
> > > 
> > > Down the road I think we should cover setting file extended
> > > attributes with the same capability as well for when a user signs
> > > files or installs packages with file signatures.  A container runtime
> > > could hold CAP_SYS_ADMIN while setting up a container and mounting
> > > filesystems and drop it for the first process started there. Since we
> > > are using the user namespace to spawn an IMA namespace, we would then
> > > require CAP_SYSTEM_ADMIN to be left available so that the user can do
> > > IMA related stuff in the container (set or append to the policy,
> > > write file signatures). I am not sure whether that should be the case
> > > or rather give the user something finer grained, such as
> > > CAP_MAC_ADMIN. So, it's about granularity...
> > 
> > It's possible ... any orchestration system that doesn't enter a user
> > namespace has to strictly regulate capabilities.   I'm probably biased
> > because I always use a user_ns so I never really had to mess with
> > capabilities.
> > 
> > > > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
> > > > 
> > > > Is effectively "because CAP_SYS_ADMIN is too powerful" but that's
> > > > no longer true of the user namespace owner.  It only passes the
> > > > ns_capable() check not the capable() one, so while it does get
> > > > CAP_SYS_ADMIN, it can only use it in a few situations which
> > > > represent quite a power reduction already.
> > > 
> > > At least docker containers drop CAP_SYS_ADMIN.
> > 
> > Well docker doesn't use the user_ns.  But even given that,
> > CAP_SYS_ADMIN is always dropped for most container systems.  What
> > happens when you enter a user namespace is the ns_capable( ...,
> > CAP_SYS_ADMIN) check returns true if you're the owner of the user_ns,
> > in the same way it would for root.  So effectively entering a user
> > namespace without CAP_SYS_ADMIN but mapping the owner id to 0 (what
> > unshare -r --user does) gives you back a form of CAP_SYS_ADMIN that
> > responds only in the places in the kernel that have a ns_capable()
> > check instead of a capable() one (most of the places you list below). 
> > This is the principle of how unprivileged containers actually work ...
> > and the source of some of our security problems if you get back an
> > ability to do something you shouldn't be allowed to do as an
> > unprivileged user.
> > 
> > >  I am not sure what the decision was based on but probably they don't
> > > want to give the user what is not absolutely necessary, but usage of
> > > user namespaces (with IMA namespaces) would kind of force it to be
> > > available then to do IMA-related stuff ...
> > > 
> > > Following this man page here 
> > > https://man7.org/linux/man-pages/man7/user_namespaces.7.html
> > > 
> > > CAP_SYS_ADMIN in a user namespace is about
> > > 
> > > - bind-mounting filesystems
> > > 
> > > - mounting /proc filesystems
> > > 
> > > - creating nested user namespaces
> > > 
> > > - configuring UTS namespace
> > > 
> > > - configuring whether setgroups() can be used
> > > 
> > > - usage of setns()
> > > 
> > > 
> > > Do we want to add '- only way of *setting up* IMA related stuff' to
> > > this list?
> > 
> > I don't see why not, but other container people should weigh in
> > because, as I said, I mostly use the user namespace and unprivileged
> > containers and don't bother with capabilities.
> 
> There are very few scenarios where dropping capabilities in an
> unprivileged container makes sense. In a lot of other scenarios it is
> just a misunderstanding of the meaning of capabilities and their
> relationship to user namespaces. Usually, granting a full set of
> capabilities to the payload of an unprivigileged container is the right
> thing to do. All things that are properly namespaced will check
> capabilities in the relevant user namespace. Those that aren't will
> check them against the initial user namespaces.
> 
> But I do think the question of whether or not ima should go into
> cap_sys_admin is more a question of capability semantics then it is in
> how exactly ima is namespaced. We do have agreed before that overloading
> cap_sys_admin further isn't ideal. Often we end up rectifying that
> mistake later. For example, how we moved stuff like criu, bpf, and perf
> to their own capability. Now we're left with stuff like:
> 
> static inline bool perfmon_capable(void)
> {
> 	return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
> }
> 
> static inline bool bpf_capable(void)
> {
> 	return capable(CAP_BPF) || capable(CAP_SYS_ADMIN);
> }
> 
> static inline bool checkpoint_restore_ns_capable(struct user_namespace *ns)
> {
> 	return ns_capable(ns, CAP_CHECKPOINT_RESTORE) ||
> 		ns_capable(ns, CAP_SYS_ADMIN);
> }
> 
> for the sake of adhering to legacy behavior. I think we can skip over
> that mistake and introduce cap_sys_integrity.

(Or under CAP_MAC_ADMIN as suggested elsewhere in the thread as I saw
just now.)

Casey Schaufler Dec. 2, 2021, 3:58 p.m. UTC | #8

On 12/2/2021 5:01 AM, Christian Brauner wrote:
> On Thu, Dec 02, 2021 at 01:59:55PM +0100, Christian Brauner wrote:
>> On Wed, Dec 01, 2021 at 02:29:09PM -0500, James Bottomley wrote:
>>> On Wed, 2021-12-01 at 12:35 -0500, Stefan Berger wrote:
>>>> On 12/1/21 11:58, James Bottomley wrote:
>>>>> On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
>>>>>> From: Denis Semakin <[e-mail]>
>>>>>>
>>>>>> Use integrity_admin_ns_capable() to check corresponding
>>>>>> capability to allow read/write IMA policy without CAP_SYS_ADMIN
>>>>>> but with CAP_INTEGRITY_ADMIN.
>>>>>>
>>>>>> Signed-off-by: Denis Semakin <[e-mail]>
>>>>>> ---
>>>>>>    security/integrity/ima/ima_fs.c | 2 +-
>>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/security/integrity/ima/ima_fs.c
>>>>>> b/security/integrity/ima/ima_fs.c
>>>>>> index fd2798f2d224..6766bb8262f2 100644
>>>>>> --- a/security/integrity/ima/ima_fs.c
>>>>>> +++ b/security/integrity/ima/ima_fs.c
>>>>>> @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode
>>>>>> *inode,
>>>>>> struct file *filp)
>>>>>>    #else
>>>>>>    		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
>>>>>>    			return -EACCES;
>>>>>> -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
>>>>>> +		if (!integrity_admin_ns_capable(ns->user_ns))
>>>>> so this one is basically replacing what you did in RFC 16/20, which
>>>>> seems a little redundant.
>>>>>
>>>>> The question I'd like to ask is: is there still a reason for
>>>>> needing CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty
>>>>> much tied to requiring a user (and a mount, because of
>>>>> securityfs_ns) namespace, there might not be a pressing need for an
>>>>> admin capability separated from CAP_SYS_ADMIN because the owner of
>>>>> the user namespace passes the ns_capable(..., CAP_SYS_ADMIN)
>>>>> check.  The rationale in
>>>> Casey suggested using CAP_MAC_ADMIN, which I think would also work.
>>>>
>>>>       CAP_MAC_ADMIN (since Linux 2.6.25)
>>>>                 Allow MAC configuration or state changes. Implemented
>>>> for
>>>>                 the Smack Linux Security Module (LSM).
>>>>
>>>>
>>>> Down the road I think we should cover setting file extended
>>>> attributes with the same capability as well for when a user signs
>>>> files or installs packages with file signatures.  A container runtime
>>>> could hold CAP_SYS_ADMIN while setting up a container and mounting
>>>> filesystems and drop it for the first process started there. Since we
>>>> are using the user namespace to spawn an IMA namespace, we would then
>>>> require CAP_SYSTEM_ADMIN to be left available so that the user can do
>>>> IMA related stuff in the container (set or append to the policy,
>>>> write file signatures). I am not sure whether that should be the case
>>>> or rather give the user something finer grained, such as
>>>> CAP_MAC_ADMIN. So, it's about granularity...

The important rationale for capabilities is separation
of privilege from user id. Granularity has always been a
contentious issue. Whether you use CAP_SYS_ADMIN or CAP_MAC_ADMIN
you are using privilege, and need to be diligent.

>>> It's possible ... any orchestration system that doesn't enter a user
>>> namespace has to strictly regulate capabilities.   I'm probably biased
>>> because I always use a user_ns so I never really had to mess with
>>> capabilities.
>>>
>>>>> https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
>>>>>
>>>>> Is effectively "because CAP_SYS_ADMIN is too powerful" but that's
>>>>> no longer true of the user namespace owner.  It only passes the
>>>>> ns_capable() check not the capable() one, so while it does get
>>>>> CAP_SYS_ADMIN, it can only use it in a few situations which
>>>>> represent quite a power reduction already.
>>>> At least docker containers drop CAP_SYS_ADMIN.
>>> Well docker doesn't use the user_ns.  But even given that,
>>> CAP_SYS_ADMIN is always dropped for most container systems.  What
>>> happens when you enter a user namespace is the ns_capable( ...,
>>> CAP_SYS_ADMIN) check returns true if you're the owner of the user_ns,
>>> in the same way it would for root.  So effectively entering a user
>>> namespace without CAP_SYS_ADMIN but mapping the owner id to 0 (what
>>> unshare -r --user does) gives you back a form of CAP_SYS_ADMIN that
>>> responds only in the places in the kernel that have a ns_capable()
>>> check instead of a capable() one (most of the places you list below).
>>> This is the principle of how unprivileged containers actually work ...
>>> and the source of some of our security problems if you get back an
>>> ability to do something you shouldn't be allowed to do as an
>>> unprivileged user.
>>>
>>>>   I am not sure what the decision was based on but probably they don't
>>>> want to give the user what is not absolutely necessary, but usage of
>>>> user namespaces (with IMA namespaces) would kind of force it to be
>>>> available then to do IMA-related stuff ...
>>>>
>>>> Following this man page here
>>>> https://man7.org/linux/man-pages/man7/user_namespaces.7.html
>>>>
>>>> CAP_SYS_ADMIN in a user namespace is about
>>>>
>>>> - bind-mounting filesystems
>>>>
>>>> - mounting /proc filesystems
>>>>
>>>> - creating nested user namespaces
>>>>
>>>> - configuring UTS namespace
>>>>
>>>> - configuring whether setgroups() can be used
>>>>
>>>> - usage of setns()
>>>>
>>>>
>>>> Do we want to add '- only way of *setting up* IMA related stuff' to
>>>> this list?
>>> I don't see why not, but other container people should weigh in
>>> because, as I said, I mostly use the user namespace and unprivileged
>>> containers and don't bother with capabilities.
>> There are very few scenarios where dropping capabilities in an
>> unprivileged container makes sense. In a lot of other scenarios it is
>> just a misunderstanding of the meaning of capabilities and their
>> relationship to user namespaces. Usually, granting a full set of
>> capabilities to the payload of an unprivigileged container is the right
>> thing to do. All things that are properly namespaced will check
>> capabilities in the relevant user namespace. Those that aren't will
>> check them against the initial user namespaces.
>>
>> But I do think the question of whether or not ima should go into
>> cap_sys_admin is more a question of capability semantics then it is in
>> how exactly ima is namespaced. We do have agreed before that overloading
>> cap_sys_admin further isn't ideal. Often we end up rectifying that
>> mistake later. For example, how we moved stuff like criu, bpf, and perf
>> to their own capability. Now we're left with stuff like:
>>
>> static inline bool perfmon_capable(void)
>> {
>> 	return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
>> }
>>
>> static inline bool bpf_capable(void)
>> {
>> 	return capable(CAP_BPF) || capable(CAP_SYS_ADMIN);
>> }
>>
>> static inline bool checkpoint_restore_ns_capable(struct user_namespace *ns)
>> {
>> 	return ns_capable(ns, CAP_CHECKPOINT_RESTORE) ||
>> 		ns_capable(ns, CAP_SYS_ADMIN);
>> }
>>
>> for the sake of adhering to legacy behavior. I think we can skip over
>> that mistake and introduce cap_sys_integrity.
> (Or under CAP_MAC_ADMIN as suggested elsewhere in the thread as I saw
> just now.)

Stefan Berger Dec. 2, 2021, 5:54 p.m. UTC | #9

On 12/2/21 02:16, Denis Semakin wrote:
> Obviously the main goal by adding new capability was to avoid the using CAP_SYS_ADMIN (IOW superuser)
> to manage IMA stuff, that was also about security granularity.  It's good if CAP_MAC_ADMIN will be enough for doing IMA related things (write policies and extended attributes).
> But for me it's a little bit unclear how to deal with unprivileged users: assuming there's no CAP_INTEGRITY_ADMIN but CAP_MAC_ADMIN was set up, so in this case user can control any LSM (seLinux, SMACK, etc) and IMA (policies, xattrs). What if .. for some systems there would be some requirements that will allow to touch LSM but do not change any IMA (integrity) things? A user can set up any IMA policy (it's about the system integrity), modify IMA related xattrs but it's forbidden to change seLinux policies and e.g. SMACK labels... May be it's unreal scenario of course... but I guess it's not 100% impossible.

If we can introduce a new capability I would use CAP_INTEGRITY_ADMIN, if 
not CAP_MAC_ADMIN.


    Stefan

>
> Best regards,
> Denis
>
>
> -----Original Message-----
> From: James Bottomley [mailto:[e-mail]]
> Sent: Wednesday, December 1, 2021 10:29 PM
> To: Stefan Berger <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Krzysztof Struczynski <[e-mail]>; Roberto Sassu <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Denis Semakin <[e-mail]>
> Subject: Re: [RFC 17/20] ima: Use integrity_admin_ns_capable() to check corresponding capability
>
> On Wed, 2021-12-01 at 12:35 -0500, Stefan Berger wrote:
>> On 12/1/21 11:58, James Bottomley wrote:
>>> On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
>>>> From: Denis Semakin <[e-mail]>
>>>>
>>>> Use integrity_admin_ns_capable() to check corresponding capability
>>>> to allow read/write IMA policy without CAP_SYS_ADMIN but with
>>>> CAP_INTEGRITY_ADMIN.
>>>>
>>>> Signed-off-by: Denis Semakin <[e-mail]>
>>>> ---
>>>>    security/integrity/ima/ima_fs.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/security/integrity/ima/ima_fs.c
>>>> b/security/integrity/ima/ima_fs.c index fd2798f2d224..6766bb8262f2
>>>> 100644
>>>> --- a/security/integrity/ima/ima_fs.c
>>>> +++ b/security/integrity/ima/ima_fs.c
>>>> @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode
>>>> *inode, struct file *filp)
>>>>    #else
>>>>    		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
>>>>    			return -EACCES;
>>>> -		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
>>>> +		if (!integrity_admin_ns_capable(ns->user_ns))
>>> so this one is basically replacing what you did in RFC 16/20, which
>>> seems a little redundant.
>>>
>>> The question I'd like to ask is: is there still a reason for needing
>>> CAP_INTEGRITY_ADMIN?  My thinking is that now IMA is pretty much
>>> tied to requiring a user (and a mount, because of
>>> securityfs_ns) namespace, there might not be a pressing need for an
>>> admin capability separated from CAP_SYS_ADMIN because the owner of
>>> the user namespace passes the ns_capable(..., CAP_SYS_ADMIN) check.
>>> The rationale in
>> Casey suggested using CAP_MAC_ADMIN, which I think would also work.
>>
>>       CAP_MAC_ADMIN (since Linux 2.6.25)
>>                 Allow MAC configuration or state changes. Implemented
>> for
>>                 the Smack Linux Security Module (LSM).
>>
>>
>> Down the road I think we should cover setting file extended attributes
>> with the same capability as well for when a user signs files or
>> installs packages with file signatures.  A container runtime could
>> hold CAP_SYS_ADMIN while setting up a container and mounting
>> filesystems and drop it for the first process started there. Since we
>> are using the user namespace to spawn an IMA namespace, we would then
>> require CAP_SYSTEM_ADMIN to be left available so that the user can do
>> IMA related stuff in the container (set or append to the policy, write
>> file signatures). I am not sure whether that should be the case or
>> rather give the user something finer grained, such as CAP_MAC_ADMIN.
>> So, it's about granularity...
> It's possible ... any orchestration system that doesn't enter a user
> namespace has to strictly regulate capabilities.   I'm probably biased
> because I always use a user_ns so I never really had to mess with capabilities.
>
>>> https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerat
>>> ions
>>>
>>> Is effectively "because CAP_SYS_ADMIN is too powerful" but that's no
>>> longer true of the user namespace owner.  It only passes the
>>> ns_capable() check not the capable() one, so while it does get
>>> CAP_SYS_ADMIN, it can only use it in a few situations which
>>> represent quite a power reduction already.
>> At least docker containers drop CAP_SYS_ADMIN.
> Well docker doesn't use the user_ns.  But even given that, CAP_SYS_ADMIN is always dropped for most container systems.  What happens when you enter a user namespace is the ns_capable( ...,
> CAP_SYS_ADMIN) check returns true if you're the owner of the user_ns, in the same way it would for root.  So effectively entering a user namespace without CAP_SYS_ADMIN but mapping the owner id to 0 (what unshare -r --user does) gives you back a form of CAP_SYS_ADMIN that responds only in the places in the kernel that have a ns_capable() check instead of a capable() one (most of the places you list below).
> This is the principle of how unprivileged containers actually work ...
> and the source of some of our security problems if you get back an ability to do something you shouldn't be allowed to do as an unprivileged user.
>
>>   I am not sure what the decision was based on but probably they don't
>> want to give the user what is not absolutely necessary, but usage of
>> user namespaces (with IMA namespaces) would kind of force it to be
>> available then to do IMA-related stuff ...
>>
>> Following this man page here
>> https://man7.org/linux/man-pages/man7/user_namespaces.7.html
>>
>> CAP_SYS_ADMIN in a user namespace is about
>>
>> - bind-mounting filesystems
>>
>> - mounting /proc filesystems
>>
>> - creating nested user namespaces
>>
>> - configuring UTS namespace
>>
>> - configuring whether setgroups() can be used
>>
>> - usage of setns()
>>
>>
>> Do we want to add '- only way of *setting up* IMA related stuff' to
>> this list?
> I don't see why not, but other container people should weigh in because, as I said, I mostly use the user namespace and unprivileged containers and don't bother with capabilities.
>
> James
>
>

Patch

diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index fd2798f2d224..6766bb8262f2 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -393,7 +393,7 @@  static int ima_open_policy(struct inode *inode, struct file *filp)
 #else
 		if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
 			return -EACCES;
-		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
+		if (!integrity_admin_ns_capable(ns->user_ns))
 			return -EPERM;
 		return seq_open(filp, &ima_policy_seqops);
 #endif