selinux: how to query if selinux is enabled

selinux: how to query if selinux is enabled

[Olga Kornievskaia]

Hi folks,

From some linux kernel module, is it possible to query and find out
whether or not selinux is currently enabled or not?

Thank you.

Re: selinux: how to query if selinux is enabled

[Paul Moore]

On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> Hi folks,
>
> From some linux kernel module, is it possible to query and find out
> whether or not selinux is currently enabled or not?
>
> Thank you.

[NOTE: CC'ing the SELinux list as it's probably a bit more relevant
that the LSM list]

In general most parts of the kernel shouldn't need to worry about what
LSMs are active and/or enabled; the simply interact with the LSM(s)
via the interfaces defined in include/linux/security.h (there are some
helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
bit more on what you are trying to accomplish?

P.S. Go Blue :)

-- 
paul moore
www.paul-moore.com

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > Hi folks,
> >
> > From some linux kernel module, is it possible to query and find out
> > whether or not selinux is currently enabled or not?
> >
> > Thank you.
>
> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> that the LSM list]
>
> In general most parts of the kernel shouldn't need to worry about what
> LSMs are active and/or enabled; the simply interact with the LSM(s)
> via the interfaces defined in include/linux/security.h (there are some
> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> bit more on what you are trying to accomplish?

Hi Paul,

Thank you for the response. What I'm trying to accomplish is the
following. Within a file system (NFS), typically any queries for
security labels are triggered by the SElinux (or I guess an LSM in
general) (thru the xattr_handler hooks). However, when the VFS is
calling to get directory entries NFS will always get the labels
(baring server not supporting it). However this is useless and affects
performance (ie., this makes servers do extra work  and adds to the
network traffic) when selinux is disabled. It would be useful if NFS
can check if there is anything that requires those labels, if SElinux
is enabled or disabled.

Thank you.

> P.S. Go Blue :)

Go Blue! :)

>
> --
> paul moore
> www.paul-moore.com

Re: selinux: how to query if selinux is enabled

[Ondrej Mosnacek]

On Thu, Oct 8, 2020 at 3:50 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > > Hi folks,
> > >
> > > From some linux kernel module, is it possible to query and find out
> > > whether or not selinux is currently enabled or not?
> > >
> > > Thank you.
> >
> > [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> > that the LSM list]
> >
> > In general most parts of the kernel shouldn't need to worry about what
> > LSMs are active and/or enabled; the simply interact with the LSM(s)
> > via the interfaces defined in include/linux/security.h (there are some
> > helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> > bit more on what you are trying to accomplish?
>
> Hi Paul,
>
> Thank you for the response. What I'm trying to accomplish is the
> following. Within a file system (NFS), typically any queries for
> security labels are triggered by the SElinux (or I guess an LSM in
> general) (thru the xattr_handler hooks). However, when the VFS is
> calling to get directory entries NFS will always get the labels
> (baring server not supporting it). However this is useless and affects
> performance (ie., this makes servers do extra work  and adds to the
> network traffic) when selinux is disabled. It would be useful if NFS
> can check if there is anything that requires those labels, if SElinux
> is enabled or disabled.

Isn't this already accomplished by the security_ismaclabel() checks
that NFS is already doing?

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Thu, Oct 8, 2020 at 10:08 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Thu, Oct 8, 2020 at 3:50 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > > > Hi folks,
> > > >
> > > > From some linux kernel module, is it possible to query and find out
> > > > whether or not selinux is currently enabled or not?
> > > >
> > > > Thank you.
> > >
> > > [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> > > that the LSM list]
> > >
> > > In general most parts of the kernel shouldn't need to worry about what
> > > LSMs are active and/or enabled; the simply interact with the LSM(s)
> > > via the interfaces defined in include/linux/security.h (there are some
> > > helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> > > bit more on what you are trying to accomplish?
> >
> > Hi Paul,
> >
> > Thank you for the response. What I'm trying to accomplish is the
> > following. Within a file system (NFS), typically any queries for
> > security labels are triggered by the SElinux (or I guess an LSM in
> > general) (thru the xattr_handler hooks). However, when the VFS is
> > calling to get directory entries NFS will always get the labels
> > (baring server not supporting it). However this is useless and affects
> > performance (ie., this makes servers do extra work  and adds to the
> > network traffic) when selinux is disabled. It would be useful if NFS
> > can check if there is anything that requires those labels, if SElinux
> > is enabled or disabled.
>
> Isn't this already accomplished by the security_ismaclabel() checks
> that NFS is already doing?

No it is not (for the readdir). Yes security_ismaclabel() is used
during the calls triggers thru the xattr_handle when a security_label
is queried on a specific file system object (inode).

This is done thru the xattr_handler interface which supplies things
like a "key" (which I'm not exactly sure that is but LSM(selinux)
uses). The only thing that we have in VFS readdir call is a
dentry(inode). (inode)->i_security isn't NULL (I already checked as I
was hoping that would be null when selinux is disabled). So I need
something else to check to see if selinux/LSM is active.

>
> --
> Ondrej Mosnacek
> Software Engineer, Platform Security - SELinux kernel
> Red Hat, Inc.
>

Re: selinux: how to query if selinux is enabled

[Casey Schaufler]

On 10/7/2020 5:40 PM, Olga Kornievskaia wrote:
> Hi folks,
>
> >From some linux kernel module, is it possible to query and find out
> whether or not selinux is currently enabled or not?

% cat /sys/kernel/security/lsm
capability,yamma,selinux

>
> Thank you.

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Thu, Oct 8, 2020 at 1:06 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 10/7/2020 5:40 PM, Olga Kornievskaia wrote:
> > Hi folks,
> >
> > >From some linux kernel module, is it possible to query and find out
> > whether or not selinux is currently enabled or not?
>
> % cat /sys/kernel/security/lsm
> capability,yamma,selinux

Thank you Casey, but it's frowned upon to read files from within a
kernel. I'm looking for a kernel api to use.

>
> >
> > Thank you.

Re: selinux: how to query if selinux is enabled

[Casey Schaufler]

On 10/8/2020 10:40 AM, Olga Kornievskaia wrote:
> On Thu, Oct 8, 2020 at 1:06 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 10/7/2020 5:40 PM, Olga Kornievskaia wrote:
>>> Hi folks,
>>>
>>> >From some linux kernel module, is it possible to query and find out
>>> whether or not selinux is currently enabled or not?
>> % cat /sys/kernel/security/lsm
>> capability,yamma,selinux
> Thank you Casey, but it's frowned upon to read files from within a
> kernel. I'm looking for a kernel api to use.

The list of active LSMs is lsm_names, exported in include/linux/lsm_hooks.h

Re: selinux: how to query if selinux is enabled

[Casey Schaufler]

On 10/8/2020 8:15 AM, Olga Kornievskaia wrote:
> On Thu, Oct 8, 2020 at 10:08 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>> On Thu, Oct 8, 2020 at 3:50 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>>>>> Hi folks,
>>>>>
>>>>> From some linux kernel module, is it possible to query and find out
>>>>> whether or not selinux is currently enabled or not?
>>>>>
>>>>> Thank you.
>>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
>>>> that the LSM list]
>>>>
>>>> In general most parts of the kernel shouldn't need to worry about what
>>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
>>>> via the interfaces defined in include/linux/security.h (there are some
>>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
>>>> bit more on what you are trying to accomplish?
>>> Hi Paul,
>>>
>>> Thank you for the response. What I'm trying to accomplish is the
>>> following. Within a file system (NFS), typically any queries for
>>> security labels are triggered by the SElinux (or I guess an LSM in
>>> general) (thru the xattr_handler hooks). However, when the VFS is
>>> calling to get directory entries NFS will always get the labels
>>> (baring server not supporting it). However this is useless and affects
>>> performance (ie., this makes servers do extra work  and adds to the
>>> network traffic) when selinux is disabled. It would be useful if NFS
>>> can check if there is anything that requires those labels, if SElinux
>>> is enabled or disabled.
>> Isn't this already accomplished by the security_ismaclabel() checks
>> that NFS is already doing?
> No it is not (for the readdir). Yes security_ismaclabel() is used
> during the calls triggers thru the xattr_handle when a security_label
> is queried on a specific file system object (inode).
>
> This is done thru the xattr_handler interface which supplies things
> like a "key" (which I'm not exactly sure that is but LSM(selinux)
> uses). The only thing that we have in VFS readdir call is a
> dentry(inode). (inode)->i_security isn't NULL (I already checked as I
> was hoping that would be null when selinux is disabled). So I need
> something else to check to see if selinux/LSM is active.

The NFS labeling is supposed to work for any security module, not
just SELinux. security_ismaclabel() should be the interface you need
to use. Checking inode->i_security would NOT give you a definitive
answer, as a security module may very well have an inode attribute
that is not related to Mandatory Access Control (MAC).

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Thu, Oct 8, 2020 at 2:44 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 10/8/2020 8:15 AM, Olga Kornievskaia wrote:
> > On Thu, Oct 8, 2020 at 10:08 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >> On Thu, Oct 8, 2020 at 3:50 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> >>>>> Hi folks,
> >>>>>
> >>>>> From some linux kernel module, is it possible to query and find out
> >>>>> whether or not selinux is currently enabled or not?
> >>>>>
> >>>>> Thank you.
> >>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> >>>> that the LSM list]
> >>>>
> >>>> In general most parts of the kernel shouldn't need to worry about what
> >>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
> >>>> via the interfaces defined in include/linux/security.h (there are some
> >>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> >>>> bit more on what you are trying to accomplish?
> >>> Hi Paul,
> >>>
> >>> Thank you for the response. What I'm trying to accomplish is the
> >>> following. Within a file system (NFS), typically any queries for
> >>> security labels are triggered by the SElinux (or I guess an LSM in
> >>> general) (thru the xattr_handler hooks). However, when the VFS is
> >>> calling to get directory entries NFS will always get the labels
> >>> (baring server not supporting it). However this is useless and affects
> >>> performance (ie., this makes servers do extra work  and adds to the
> >>> network traffic) when selinux is disabled. It would be useful if NFS
> >>> can check if there is anything that requires those labels, if SElinux
> >>> is enabled or disabled.
> >> Isn't this already accomplished by the security_ismaclabel() checks
> >> that NFS is already doing?
> > No it is not (for the readdir). Yes security_ismaclabel() is used
> > during the calls triggers thru the xattr_handle when a security_label
> > is queried on a specific file system object (inode).
> >
> > This is done thru the xattr_handler interface which supplies things
> > like a "key" (which I'm not exactly sure that is but LSM(selinux)
> > uses). The only thing that we have in VFS readdir call is a
> > dentry(inode). (inode)->i_security isn't NULL (I already checked as I
> > was hoping that would be null when selinux is disabled). So I need
> > something else to check to see if selinux/LSM is active.
>
> The NFS labeling is supposed to work for any security module, not
> just SELinux. security_ismaclabel() should be the interface you need
> to use. Checking inode->i_security would NOT give you a definitive
> answer, as a security module may very well have an inode attribute
> that is not related to Mandatory Access Control (MAC).

Can you suggest what should be passed into security_ismaclabel()?
Typically this is driven by a call into the kernel module that
registered an xattr_handler and LSM passes into it an attribute name
to use to lookup (basically what is passed into the xatrr_handler for
key/name is passed to security_ismaclabel()). VFS readdir doesn't have
anything like that.

Re: selinux: how to query if selinux is enabled

[Casey Schaufler]

On 10/8/2020 1:56 PM, Olga Kornievskaia wrote:
> On Thu, Oct 8, 2020 at 2:44 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 10/8/2020 8:15 AM, Olga Kornievskaia wrote:
>>> On Thu, Oct 8, 2020 at 10:08 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>>>> On Thu, Oct 8, 2020 at 3:50 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>>>>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> From some linux kernel module, is it possible to query and find out
>>>>>>> whether or not selinux is currently enabled or not?
>>>>>>>
>>>>>>> Thank you.
>>>>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
>>>>>> that the LSM list]
>>>>>>
>>>>>> In general most parts of the kernel shouldn't need to worry about what
>>>>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
>>>>>> via the interfaces defined in include/linux/security.h (there are some
>>>>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
>>>>>> bit more on what you are trying to accomplish?
>>>>> Hi Paul,
>>>>>
>>>>> Thank you for the response. What I'm trying to accomplish is the
>>>>> following. Within a file system (NFS), typically any queries for
>>>>> security labels are triggered by the SElinux (or I guess an LSM in
>>>>> general) (thru the xattr_handler hooks). However, when the VFS is
>>>>> calling to get directory entries NFS will always get the labels
>>>>> (baring server not supporting it). However this is useless and affects
>>>>> performance (ie., this makes servers do extra work  and adds to the
>>>>> network traffic) when selinux is disabled. It would be useful if NFS
>>>>> can check if there is anything that requires those labels, if SElinux
>>>>> is enabled or disabled.
>>>> Isn't this already accomplished by the security_ismaclabel() checks
>>>> that NFS is already doing?
>>> No it is not (for the readdir). Yes security_ismaclabel() is used
>>> during the calls triggers thru the xattr_handle when a security_label
>>> is queried on a specific file system object (inode).
>>>
>>> This is done thru the xattr_handler interface which supplies things
>>> like a "key" (which I'm not exactly sure that is but LSM(selinux)
>>> uses). The only thing that we have in VFS readdir call is a
>>> dentry(inode). (inode)->i_security isn't NULL (I already checked as I
>>> was hoping that would be null when selinux is disabled). So I need
>>> something else to check to see if selinux/LSM is active.
>> The NFS labeling is supposed to work for any security module, not
>> just SELinux. security_ismaclabel() should be the interface you need
>> to use. Checking inode->i_security would NOT give you a definitive
>> answer, as a security module may very well have an inode attribute
>> that is not related to Mandatory Access Control (MAC).
> Can you suggest what should be passed into security_ismaclabel()?
> Typically this is driven by a call into the kernel module that
> registered an xattr_handler and LSM passes into it an attribute name
> to use to lookup (basically what is passed into the xatrr_handler for
> key/name is passed to security_ismaclabel()). VFS readdir doesn't have
> anything like that.

I'm not convinced that the question makes sense. Are you trying to
avoid in the VFS layer a call in the NFS layer to fetch an attribute
the NFS layer isn't supporting? Is that reasonable? I could see changing
the NFS implementation to be more careful about the calls it is making,
but not the VFS layer. Or am I (once again) missing the point?

Re: selinux: how to query if selinux is enabled

[Paul Moore]

->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > > Hi folks,
> > >
> > > From some linux kernel module, is it possible to query and find out
> > > whether or not selinux is currently enabled or not?
> > >
> > > Thank you.
> >
> > [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> > that the LSM list]
> >
> > In general most parts of the kernel shouldn't need to worry about what
> > LSMs are active and/or enabled; the simply interact with the LSM(s)
> > via the interfaces defined in include/linux/security.h (there are some
> > helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> > bit more on what you are trying to accomplish?
>
> Hi Paul,
>
> Thank you for the response. What I'm trying to accomplish is the
> following. Within a file system (NFS), typically any queries for
> security labels are triggered by the SElinux (or I guess an LSM in
> general) (thru the xattr_handler hooks). However, when the VFS is
> calling to get directory entries NFS will always get the labels
> (baring server not supporting it). However this is useless and affects
> performance (ie., this makes servers do extra work  and adds to the
> network traffic) when selinux is disabled. It would be useful if NFS
> can check if there is anything that requires those labels, if SElinux
> is enabled or disabled.

[Adding Chuck Lever to the CC line as I believe he has the most recent
LSM experience from the NFS side - sorry Chuck :)]

I'll need to ask your patience on this as I am far from a NFS expert.

Looking through the NFS readdir/getdents code this evening, I was
wondering if the solution in the readdir case is to simply tell the
server you are not interested in the security label by masking out
FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in
_nfs4_proc_readdir()?  Of course this assumes that the security label
genuinely isn't needed in this case (and not requesting it doesn't
bypass access controls or break something on the server side), and we
don't screw up some NFS client side cache by *not* fetching the
security label attribute.

Is this remotely close to workable, or am I missing something fundamental?

-- 
paul moore
www.paul-moore.com

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <paul@paul-moore.com> wrote:
>
> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> > On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > > > Hi folks,
> > > >
> > > > From some linux kernel module, is it possible to query and find out
> > > > whether or not selinux is currently enabled or not?
> > > >
> > > > Thank you.
> > >
> > > [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> > > that the LSM list]
> > >
> > > In general most parts of the kernel shouldn't need to worry about what
> > > LSMs are active and/or enabled; the simply interact with the LSM(s)
> > > via the interfaces defined in include/linux/security.h (there are some
> > > helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> > > bit more on what you are trying to accomplish?
> >
> > Hi Paul,
> >
> > Thank you for the response. What I'm trying to accomplish is the
> > following. Within a file system (NFS), typically any queries for
> > security labels are triggered by the SElinux (or I guess an LSM in
> > general) (thru the xattr_handler hooks). However, when the VFS is
> > calling to get directory entries NFS will always get the labels
> > (baring server not supporting it). However this is useless and affects
> > performance (ie., this makes servers do extra work  and adds to the
> > network traffic) when selinux is disabled. It would be useful if NFS
> > can check if there is anything that requires those labels, if SElinux
> > is enabled or disabled.
>
> [Adding Chuck Lever to the CC line as I believe he has the most recent
> LSM experience from the NFS side - sorry Chuck :)]
>
> I'll need to ask your patience on this as I am far from a NFS expert.
>
> Looking through the NFS readdir/getdents code this evening, I was
> wondering if the solution in the readdir case is to simply tell the
> server you are not interested in the security label by masking out
> FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in
> _nfs4_proc_readdir()?  Of course this assumes that the security label
> genuinely isn't needed in this case (and not requesting it doesn't
> bypass access controls or break something on the server side), and we
> don't screw up some NFS client side cache by *not* fetching the
> security label attribute.
>
> Is this remotely close to workable, or am I missing something fundamental?
>

No this is not going to work, as NFS requires labels when labels are
indeed needed by the LSM. What I'm looking for is an optimization.
What we have is functionality correct but performance might suffer for
the standard case of NFSv4.2 seclabel enabled server and clients that
don't care about seclabels.


> --
> paul moore
> www.paul-moore.com

Re: selinux: how to query if selinux is enabled

[Chuck Lever]

> On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> 
> On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <paul@paul-moore.com> wrote:
>> 
>> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@umich.edu> wrote:
>>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>>>>> Hi folks,
>>>>> 
>>>>> From some linux kernel module, is it possible to query and find out
>>>>> whether or not selinux is currently enabled or not?
>>>>> 
>>>>> Thank you.
>>>> 
>>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
>>>> that the LSM list]
>>>> 
>>>> In general most parts of the kernel shouldn't need to worry about what
>>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
>>>> via the interfaces defined in include/linux/security.h (there are some
>>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
>>>> bit more on what you are trying to accomplish?
>>> 
>>> Hi Paul,
>>> 
>>> Thank you for the response. What I'm trying to accomplish is the
>>> following. Within a file system (NFS), typically any queries for
>>> security labels are triggered by the SElinux (or I guess an LSM in
>>> general) (thru the xattr_handler hooks). However, when the VFS is
>>> calling to get directory entries NFS will always get the labels
>>> (baring server not supporting it). However this is useless and affects
>>> performance (ie., this makes servers do extra work  and adds to the
>>> network traffic) when selinux is disabled. It would be useful if NFS
>>> can check if there is anything that requires those labels, if SElinux
>>> is enabled or disabled.
>> 
>> [Adding Chuck Lever to the CC line as I believe he has the most recent
>> LSM experience from the NFS side - sorry Chuck :)]
>> 
>> I'll need to ask your patience on this as I am far from a NFS expert.
>> 
>> Looking through the NFS readdir/getdents code this evening, I was
>> wondering if the solution in the readdir case is to simply tell the
>> server you are not interested in the security label by masking out
>> FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in
>> _nfs4_proc_readdir()?  Of course this assumes that the security label
>> genuinely isn't needed in this case (and not requesting it doesn't
>> bypass access controls or break something on the server side), and we
>> don't screw up some NFS client side cache by *not* fetching the
>> security label attribute.
>> 
>> Is this remotely close to workable, or am I missing something fundamental?
>> 
> 
> No this is not going to work, as NFS requires labels when labels are
> indeed needed by the LSM. What I'm looking for is an optimization.
> What we have is functionality correct but performance might suffer for
> the standard case of NFSv4.2 seclabel enabled server and clients that
> don't care about seclabels.

Initial thought: We should ask linux-nfs for help with this.
I've added them to the Cc: list.

Olga, are you asking if the kernel NFS client module can somehow find
out whether the rest of the kernel is configured to care about security
labels before it forms an NFSv4 READDIR or LOOKUP request?

I would certainly like to take the security label query out of every
LOOKUP operation if that is feasible!


--
Chuck Lever
chucklever@gmail.com

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <chucklever@gmail.com> wrote:
>
>
>
> > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> >
> > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <paul@paul-moore.com> wrote:
> >>
> >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> >>>>> Hi folks,
> >>>>>
> >>>>> From some linux kernel module, is it possible to query and find out
> >>>>> whether or not selinux is currently enabled or not?
> >>>>>
> >>>>> Thank you.
> >>>>
> >>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> >>>> that the LSM list]
> >>>>
> >>>> In general most parts of the kernel shouldn't need to worry about what
> >>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
> >>>> via the interfaces defined in include/linux/security.h (there are some
> >>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> >>>> bit more on what you are trying to accomplish?
> >>>
> >>> Hi Paul,
> >>>
> >>> Thank you for the response. What I'm trying to accomplish is the
> >>> following. Within a file system (NFS), typically any queries for
> >>> security labels are triggered by the SElinux (or I guess an LSM in
> >>> general) (thru the xattr_handler hooks). However, when the VFS is
> >>> calling to get directory entries NFS will always get the labels
> >>> (baring server not supporting it). However this is useless and affects
> >>> performance (ie., this makes servers do extra work  and adds to the
> >>> network traffic) when selinux is disabled. It would be useful if NFS
> >>> can check if there is anything that requires those labels, if SElinux
> >>> is enabled or disabled.
> >>
> >> [Adding Chuck Lever to the CC line as I believe he has the most recent
> >> LSM experience from the NFS side - sorry Chuck :)]
> >>
> >> I'll need to ask your patience on this as I am far from a NFS expert.
> >>
> >> Looking through the NFS readdir/getdents code this evening, I was
> >> wondering if the solution in the readdir case is to simply tell the
> >> server you are not interested in the security label by masking out
> >> FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in
> >> _nfs4_proc_readdir()?  Of course this assumes that the security label
> >> genuinely isn't needed in this case (and not requesting it doesn't
> >> bypass access controls or break something on the server side), and we
> >> don't screw up some NFS client side cache by *not* fetching the
> >> security label attribute.
> >>
> >> Is this remotely close to workable, or am I missing something fundamental?
> >>
> >
> > No this is not going to work, as NFS requires labels when labels are
> > indeed needed by the LSM. What I'm looking for is an optimization.
> > What we have is functionality correct but performance might suffer for
> > the standard case of NFSv4.2 seclabel enabled server and clients that
> > don't care about seclabels.
>
> Initial thought: We should ask linux-nfs for help with this.
> I've added them to the Cc: list.
>
> Olga, are you asking if the kernel NFS client module can somehow find
> out whether the rest of the kernel is configured to care about security
> labels before it forms an NFSv4 READDIR or LOOKUP request?

Yes exactly, but I'm having a hard time trying to figure out how to
use security_ismaclabel() function as has been suggested by Casey.

> I would certainly like to take the security label query out of every
> LOOKUP operation if that is feasible!

A LOOKUP doesn't add the seclabel query (by default) like READDIR does
(it's hard-coded in the xdr code). LOOKUP uses server's bitmask and
chooses the version without the seclabel bitmask because no label is
passed into it. It looks like LOOKUP just allocates a label in
nfs_lookup_revalidate_dentry().  So it's not driven by the something
that I see used by the xattr_handle example in the NFS code.

>
>
> --
> Chuck Lever
> chucklever@gmail.com
>
>
>

Re: selinux: how to query if selinux is enabled

[Stephen Smalley]

On Fri, Oct 9, 2020 at 12:36 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>
> On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <chucklever@gmail.com> wrote:
> >
> >
> >
> > > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> > >
> > > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <paul@paul-moore.com> wrote:
> > >>
> > >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> > >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> > >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > >>>>> Hi folks,
> > >>>>>
> > >>>>> From some linux kernel module, is it possible to query and find out
> > >>>>> whether or not selinux is currently enabled or not?
> > >>>>>
> > >>>>> Thank you.
> > >>>>
> > >>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> > >>>> that the LSM list]
> > >>>>
> > >>>> In general most parts of the kernel shouldn't need to worry about what
> > >>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
> > >>>> via the interfaces defined in include/linux/security.h (there are some
> > >>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> > >>>> bit more on what you are trying to accomplish?
> > >>>
> > >>> Hi Paul,
> > >>>
> > >>> Thank you for the response. What I'm trying to accomplish is the
> > >>> following. Within a file system (NFS), typically any queries for
> > >>> security labels are triggered by the SElinux (or I guess an LSM in
> > >>> general) (thru the xattr_handler hooks). However, when the VFS is
> > >>> calling to get directory entries NFS will always get the labels
> > >>> (baring server not supporting it). However this is useless and affects
> > >>> performance (ie., this makes servers do extra work  and adds to the
> > >>> network traffic) when selinux is disabled. It would be useful if NFS
> > >>> can check if there is anything that requires those labels, if SElinux
> > >>> is enabled or disabled.
> > >>
> > >> [Adding Chuck Lever to the CC line as I believe he has the most recent
> > >> LSM experience from the NFS side - sorry Chuck :)]
> > >>
> > >> I'll need to ask your patience on this as I am far from a NFS expert.
> > >>
> > >> Looking through the NFS readdir/getdents code this evening, I was
> > >> wondering if the solution in the readdir case is to simply tell the
> > >> server you are not interested in the security label by masking out
> > >> FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in
> > >> _nfs4_proc_readdir()?  Of course this assumes that the security label
> > >> genuinely isn't needed in this case (and not requesting it doesn't
> > >> bypass access controls or break something on the server side), and we
> > >> don't screw up some NFS client side cache by *not* fetching the
> > >> security label attribute.
> > >>
> > >> Is this remotely close to workable, or am I missing something fundamental?
> > >>
> > >
> > > No this is not going to work, as NFS requires labels when labels are
> > > indeed needed by the LSM. What I'm looking for is an optimization.
> > > What we have is functionality correct but performance might suffer for
> > > the standard case of NFSv4.2 seclabel enabled server and clients that
> > > don't care about seclabels.
> >
> > Initial thought: We should ask linux-nfs for help with this.
> > I've added them to the Cc: list.
> >
> > Olga, are you asking if the kernel NFS client module can somehow find
> > out whether the rest of the kernel is configured to care about security
> > labels before it forms an NFSv4 READDIR or LOOKUP request?
>
> Yes exactly, but I'm having a hard time trying to figure out how to
> use security_ismaclabel() function as has been suggested by Casey.

I would suggest either introducing a new hook for your purpose, or
altering the existing one to support a form of query that isn't based
on a particular xattr name but rather just checking whether the module
supports/uses MAC labels at all.  Options: 1) NULL argument to the
existing hook indicates a general query (could hide a bug in the
caller, so not optimal), 2) Add a new bool argument to the existing
hook to indicate whether the name should be used, or 3) Add a new hook
that doesn't take any arguments.

>
> > I would certainly like to take the security label query out of every
> > LOOKUP operation if that is feasible!
>
> A LOOKUP doesn't add the seclabel query (by default) like READDIR does
> (it's hard-coded in the xdr code). LOOKUP uses server's bitmask and
> chooses the version without the seclabel bitmask because no label is
> passed into it. It looks like LOOKUP just allocates a label in
> nfs_lookup_revalidate_dentry().  So it's not driven by the something
> that I see used by the xattr_handle example in the NFS code.

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Fri, Oct 9, 2020 at 12:36 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> >
> > On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <chucklever@gmail.com> wrote:
> > >
> > >
> > >
> > > > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> > > >
> > > > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >>
> > > >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> > > >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> > > >>>>> Hi folks,
> > > >>>>>
> > > >>>>> From some linux kernel module, is it possible to query and find out
> > > >>>>> whether or not selinux is currently enabled or not?
> > > >>>>>
> > > >>>>> Thank you.
> > > >>>>
> > > >>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> > > >>>> that the LSM list]
> > > >>>>
> > > >>>> In general most parts of the kernel shouldn't need to worry about what
> > > >>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
> > > >>>> via the interfaces defined in include/linux/security.h (there are some
> > > >>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> > > >>>> bit more on what you are trying to accomplish?
> > > >>>
> > > >>> Hi Paul,
> > > >>>
> > > >>> Thank you for the response. What I'm trying to accomplish is the
> > > >>> following. Within a file system (NFS), typically any queries for
> > > >>> security labels are triggered by the SElinux (or I guess an LSM in
> > > >>> general) (thru the xattr_handler hooks). However, when the VFS is
> > > >>> calling to get directory entries NFS will always get the labels
> > > >>> (baring server not supporting it). However this is useless and affects
> > > >>> performance (ie., this makes servers do extra work  and adds to the
> > > >>> network traffic) when selinux is disabled. It would be useful if NFS
> > > >>> can check if there is anything that requires those labels, if SElinux
> > > >>> is enabled or disabled.
> > > >>
> > > >> [Adding Chuck Lever to the CC line as I believe he has the most recent
> > > >> LSM experience from the NFS side - sorry Chuck :)]
> > > >>
> > > >> I'll need to ask your patience on this as I am far from a NFS expert.
> > > >>
> > > >> Looking through the NFS readdir/getdents code this evening, I was
> > > >> wondering if the solution in the readdir case is to simply tell the
> > > >> server you are not interested in the security label by masking out
> > > >> FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in
> > > >> _nfs4_proc_readdir()?  Of course this assumes that the security label
> > > >> genuinely isn't needed in this case (and not requesting it doesn't
> > > >> bypass access controls or break something on the server side), and we
> > > >> don't screw up some NFS client side cache by *not* fetching the
> > > >> security label attribute.
> > > >>
> > > >> Is this remotely close to workable, or am I missing something fundamental?
> > > >>
> > > >
> > > > No this is not going to work, as NFS requires labels when labels are
> > > > indeed needed by the LSM. What I'm looking for is an optimization.
> > > > What we have is functionality correct but performance might suffer for
> > > > the standard case of NFSv4.2 seclabel enabled server and clients that
> > > > don't care about seclabels.
> > >
> > > Initial thought: We should ask linux-nfs for help with this.
> > > I've added them to the Cc: list.
> > >
> > > Olga, are you asking if the kernel NFS client module can somehow find
> > > out whether the rest of the kernel is configured to care about security
> > > labels before it forms an NFSv4 READDIR or LOOKUP request?
> >
> > Yes exactly, but I'm having a hard time trying to figure out how to
> > use security_ismaclabel() function as has been suggested by Casey.
>
> I would suggest either introducing a new hook for your purpose, or
> altering the existing one to support a form of query that isn't based
> on a particular xattr name but rather just checking whether the module
> supports/uses MAC labels at all.  Options: 1) NULL argument to the
> existing hook indicates a general query (could hide a bug in the
> caller, so not optimal), 2) Add a new bool argument to the existing
> hook to indicate whether the name should be used, or 3) Add a new hook
> that doesn't take any arguments.

Hi Stephen,

Yes it seems like current api lacks the needed functionality and what
you are suggesting is needed. Thank you for confirming it.

>
> >
> > > I would certainly like to take the security label query out of every
> > > LOOKUP operation if that is feasible!
> >
> > A LOOKUP doesn't add the seclabel query (by default) like READDIR does
> > (it's hard-coded in the xdr code). LOOKUP uses server's bitmask and
> > chooses the version without the seclabel bitmask because no label is
> > passed into it. It looks like LOOKUP just allocates a label in
> > nfs_lookup_revalidate_dentry().  So it's not driven by the something
> > that I see used by the xattr_handle example in the NFS code.

Re: selinux: how to query if selinux is enabled

[Paul Moore]

On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley wrote:
> > I would suggest either introducing a new hook for your purpose, or
> > altering the existing one to support a form of query that isn't based
> > on a particular xattr name but rather just checking whether the module
> > supports/uses MAC labels at all.  Options: 1) NULL argument to the
> > existing hook indicates a general query (could hide a bug in the
> > caller, so not optimal), 2) Add a new bool argument to the existing
> > hook to indicate whether the name should be used, or 3) Add a new hook
> > that doesn't take any arguments.
>
> Hi Stephen,
>
> Yes it seems like current api lacks the needed functionality and what
> you are suggesting is needed. Thank you for confirming it.

To add my two cents at this point, I would be in favor of a new LSM
hook rather than hijacking security_ismaclabel().  It seems that every
few years someone comes along and asks for a way to detect various LSM
capabilities, this might be the right time to introduce a LSM API for
this.

My only concern about adding such an API is it could get complicated
very quickly.  One nice thing we have going for us is that this is a
kernel internal API so we don't have to worry about kernel/userspace
ABI promises, if we decide we need to change the API at some point in
the future we can do so without problem.  For that reason I'm going to
suggest we do something relatively simple with the understanding that
we can change it if/when the number of users grow.

To start the discussion I might suggest the following:

#define LSM_FQUERY_VFS_NONE     0x00000000
#define LSM_FQUERY_VFS_XATTRS   0x00000001
int security_func_query_vfs(unsigned int flags);

... with an example SELinux implementation looks like this:

int selinux_func_query_vfs(unsigned int flags)
{
    return !!(flags & LSM_FQUERY_VFS_XATTRS);
}

-- 
paul moore
www.paul-moore.com

Re: selinux: how to query if selinux is enabled

[Casey Schaufler]

On 10/14/2020 8:57 AM, Paul Moore wrote:
> On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <aglo@umich.edu> wrote:
>> On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley wrote:
>>> I would suggest either introducing a new hook for your purpose, or
>>> altering the existing one to support a form of query that isn't based
>>> on a particular xattr name but rather just checking whether the module
>>> supports/uses MAC labels at all.  Options: 1) NULL argument to the
>>> existing hook indicates a general query (could hide a bug in the
>>> caller, so not optimal), 2) Add a new bool argument to the existing
>>> hook to indicate whether the name should be used, or 3) Add a new hook
>>> that doesn't take any arguments.
>> Hi Stephen,
>>
>> Yes it seems like current api lacks the needed functionality and what
>> you are suggesting is needed. Thank you for confirming it.
> To add my two cents at this point, I would be in favor of a new LSM
> hook rather than hijacking security_ismaclabel().  It seems that every
> few years someone comes along and asks for a way to detect various LSM
> capabilities, this might be the right time to introduce a LSM API for
> this.
>
> My only concern about adding such an API is it could get complicated
> very quickly.  One nice thing we have going for us is that this is a
> kernel internal API so we don't have to worry about kernel/userspace
> ABI promises, if we decide we need to change the API at some point in
> the future we can do so without problem.  For that reason I'm going to
> suggest we do something relatively simple with the understanding that
> we can change it if/when the number of users grow.
>
> To start the discussion I might suggest the following:
>
> #define LSM_FQUERY_VFS_NONE     0x00000000
> #define LSM_FQUERY_VFS_XATTRS   0x00000001
> int security_func_query_vfs(unsigned int flags);
>
> ... with an example SELinux implementation looks like this:
>
> int selinux_func_query_vfs(unsigned int flags)
> {
>     return !!(flags & LSM_FQUERY_VFS_XATTRS);
> }

Not a bad start, but I see optimizations and issues.

It would be really easy to collect the LSM features at module
initialization by adding the feature flags to struct lsm_info.
We could maintain a variable lsm_features in security.c that
has the cumulative feature set. Rather than have an LSM hook for
func_query_vfs we'd get

int security_func_query_vfs(void)
{
	return !!(lsm_features & LSM_FQUERY_VFS_XATTRS);
}

In either case there could be confusion in the case where more
than one security module provides the feature. NFS, for example,
cares about the SELinux "selinux" attribute, but probably not
about the Smack "SMACK64EXEC" attribute. It's entirely possible
that a bit isn't enough information to check about a "feature".

Re: selinux: how to query if selinux is enabled

[Paul Moore]

On Wed, Oct 14, 2020 at 12:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 10/14/2020 8:57 AM, Paul Moore wrote:
> > On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> >> On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley wrote:
> >>> I would suggest either introducing a new hook for your purpose, or
> >>> altering the existing one to support a form of query that isn't based
> >>> on a particular xattr name but rather just checking whether the module
> >>> supports/uses MAC labels at all.  Options: 1) NULL argument to the
> >>> existing hook indicates a general query (could hide a bug in the
> >>> caller, so not optimal), 2) Add a new bool argument to the existing
> >>> hook to indicate whether the name should be used, or 3) Add a new hook
> >>> that doesn't take any arguments.
> >> Hi Stephen,
> >>
> >> Yes it seems like current api lacks the needed functionality and what
> >> you are suggesting is needed. Thank you for confirming it.
> > To add my two cents at this point, I would be in favor of a new LSM
> > hook rather than hijacking security_ismaclabel().  It seems that every
> > few years someone comes along and asks for a way to detect various LSM
> > capabilities, this might be the right time to introduce a LSM API for
> > this.
> >
> > My only concern about adding such an API is it could get complicated
> > very quickly.  One nice thing we have going for us is that this is a
> > kernel internal API so we don't have to worry about kernel/userspace
> > ABI promises, if we decide we need to change the API at some point in
> > the future we can do so without problem.  For that reason I'm going to
> > suggest we do something relatively simple with the understanding that
> > we can change it if/when the number of users grow.
> >
> > To start the discussion I might suggest the following:
> >
> > #define LSM_FQUERY_VFS_NONE     0x00000000
> > #define LSM_FQUERY_VFS_XATTRS   0x00000001
> > int security_func_query_vfs(unsigned int flags);
> >
> > ... with an example SELinux implementation looks like this:
> >
> > int selinux_func_query_vfs(unsigned int flags)
> > {
> >     return !!(flags & LSM_FQUERY_VFS_XATTRS);
> > }
>
> Not a bad start, but I see optimizations and issues.
>
> It would be really easy to collect the LSM features at module
> initialization by adding the feature flags to struct lsm_info.
> We could maintain a variable lsm_features in security.c that
> has the cumulative feature set. Rather than have an LSM hook for
> func_query_vfs we'd get
>
> int security_func_query_vfs(void)
> {
>         return !!(lsm_features & LSM_FQUERY_VFS_XATTRS);
> }

Works for me.

> In either case there could be confusion in the case where more
> than one security module provides the feature. NFS, for example,
> cares about the SELinux "selinux" attribute, but probably not
> about the Smack "SMACK64EXEC" attribute. It's entirely possible
> that a bit isn't enough information to check about a "feature".

In the LSM stacking world that shouldn't matter to callers, right?  Or
perhaps more correctly, if it matters to the caller which individual
LSM supports what feature then the caller is doing it wrong, right?

-- 
paul moore
www.paul-moore.com

Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia]

On Wed, Oct 14, 2020 at 8:11 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Wed, Oct 14, 2020 at 12:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > On 10/14/2020 8:57 AM, Paul Moore wrote:
> > > On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> > >> On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley wrote:
> > >>> I would suggest either introducing a new hook for your purpose, or
> > >>> altering the existing one to support a form of query that isn't based
> > >>> on a particular xattr name but rather just checking whether the module
> > >>> supports/uses MAC labels at all.  Options: 1) NULL argument to the
> > >>> existing hook indicates a general query (could hide a bug in the
> > >>> caller, so not optimal), 2) Add a new bool argument to the existing
> > >>> hook to indicate whether the name should be used, or 3) Add a new hook
> > >>> that doesn't take any arguments.
> > >> Hi Stephen,
> > >>
> > >> Yes it seems like current api lacks the needed functionality and what
> > >> you are suggesting is needed. Thank you for confirming it.
> > > To add my two cents at this point, I would be in favor of a new LSM
> > > hook rather than hijacking security_ismaclabel().  It seems that every
> > > few years someone comes along and asks for a way to detect various LSM
> > > capabilities, this might be the right time to introduce a LSM API for
> > > this.
> > >
> > > My only concern about adding such an API is it could get complicated
> > > very quickly.  One nice thing we have going for us is that this is a
> > > kernel internal API so we don't have to worry about kernel/userspace
> > > ABI promises, if we decide we need to change the API at some point in
> > > the future we can do so without problem.  For that reason I'm going to
> > > suggest we do something relatively simple with the understanding that
> > > we can change it if/when the number of users grow.
> > >
> > > To start the discussion I might suggest the following:
> > >
> > > #define LSM_FQUERY_VFS_NONE     0x00000000
> > > #define LSM_FQUERY_VFS_XATTRS   0x00000001
> > > int security_func_query_vfs(unsigned int flags);
> > >
> > > ... with an example SELinux implementation looks like this:
> > >
> > > int selinux_func_query_vfs(unsigned int flags)
> > > {
> > >     return !!(flags & LSM_FQUERY_VFS_XATTRS);
> > > }
> >
> > Not a bad start, but I see optimizations and issues.
> >
> > It would be really easy to collect the LSM features at module
> > initialization by adding the feature flags to struct lsm_info.
> > We could maintain a variable lsm_features in security.c that
> > has the cumulative feature set. Rather than have an LSM hook for
> > func_query_vfs we'd get
> >
> > int security_func_query_vfs(void)
> > {
> >         return !!(lsm_features & LSM_FQUERY_VFS_XATTRS);
> > }
>
> Works for me.
>
> > In either case there could be confusion in the case where more
> > than one security module provides the feature. NFS, for example,
> > cares about the SELinux "selinux" attribute, but probably not
> > about the Smack "SMACK64EXEC" attribute. It's entirely possible
> > that a bit isn't enough information to check about a "feature".
>
> In the LSM stacking world that shouldn't matter to callers, right?  Or
> perhaps more correctly, if it matters to the caller which individual
> LSM supports what feature then the caller is doing it wrong, right?

Hi folks,

I would like to resurrect this discussion and sorry for a delayed
response. I'm a little bit unsure about the suggested approach of
adding something like selinux_func_query_vfs() call where selinux has
such a function. What happens when selinux is configured to be
"disabled" wouldn't this call still return the same value as when it
is configured as "permissive or enforcing"?

Thank you.



>
> --
> paul moore
> www.paul-moore.com

Re: selinux: how to query if selinux is enabled

[Paul Moore]

On Wed, Nov 4, 2020 at 9:21 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> On Wed, Oct 14, 2020 at 8:11 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Wed, Oct 14, 2020 at 12:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > On 10/14/2020 8:57 AM, Paul Moore wrote:
> > > > On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> > > >> On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley wrote:

...

> > > > To start the discussion I might suggest the following:
> > > >
> > > > #define LSM_FQUERY_VFS_NONE     0x00000000
> > > > #define LSM_FQUERY_VFS_XATTRS   0x00000001
> > > > int security_func_query_vfs(unsigned int flags);
> > > >
> > > > ... with an example SELinux implementation looks like this:
> > > >
> > > > int selinux_func_query_vfs(unsigned int flags)
> > > > {
> > > >     return !!(flags & LSM_FQUERY_VFS_XATTRS);
> > > > }
> > >
> > > Not a bad start, but I see optimizations and issues.
> > >
> > > It would be really easy to collect the LSM features at module
> > > initialization by adding the feature flags to struct lsm_info.
> > > We could maintain a variable lsm_features in security.c that
> > > has the cumulative feature set. Rather than have an LSM hook for
> > > func_query_vfs we'd get
> > >
> > > int security_func_query_vfs(void)
> > > {
> > >         return !!(lsm_features & LSM_FQUERY_VFS_XATTRS);
> > > }
> >
> > Works for me.
> >
> > > In either case there could be confusion in the case where more
> > > than one security module provides the feature. NFS, for example,
> > > cares about the SELinux "selinux" attribute, but probably not
> > > about the Smack "SMACK64EXEC" attribute. It's entirely possible
> > > that a bit isn't enough information to check about a "feature".
> >
> > In the LSM stacking world that shouldn't matter to callers, right?  Or
> > perhaps more correctly, if it matters to the caller which individual
> > LSM supports what feature then the caller is doing it wrong, right?
>
> Hi folks,
>
> I would like to resurrect this discussion and sorry for a delayed
> response. I'm a little bit unsure about the suggested approach of
> adding something like selinux_func_query_vfs() call where selinux has
> such a function. What happens when selinux is configured to be
> "disabled" wouldn't this call still return the same value as when it
> is configured as "permissive or enforcing"?

Hello again.

To start, the non-LSM portion of the kernel shouldn't be calling
selinux_func_query_vfs() directly, it should call
security_func_query_vfs(); it would be up to the individual LSMs to
indicate to the LSM hooks layer what is required.  If SELinux wasn't
built into the kernel, or was disabled at boot, I would expect that
the security_func_query_vfs() function would adjust to exclude the
SELinux requirements.

-- 
paul moore
www.paul-moore.com