> On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <[email protected]> wrote:
>
> On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <[email protected]> wrote:
>>
>> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <[email protected]> wrote:
>>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <[email protected]> wrote:
>>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <[email protected]> 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
[email protected]
On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <[email protected]> wrote:
>
>
>
> > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <[email protected]> wrote:
> >
> > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <[email protected]> wrote:
> >>
> >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <[email protected]> wrote:
> >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <[email protected]> wrote:
> >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <[email protected]> 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
> [email protected]
>
>
>
On Fri, Oct 9, 2020 at 12:36 PM Olga Kornievskaia <[email protected]> wrote:
>
> On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <[email protected]> wrote:
> >
> >
> >
> > > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <[email protected]> wrote:
> > >
> > > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <[email protected]> wrote:
> > >>
> > >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <[email protected]> wrote:
> > >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <[email protected]> wrote:
> > >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <[email protected]> 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.
On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley
<[email protected]> wrote:
>
> On Fri, Oct 9, 2020 at 12:36 PM Olga Kornievskaia <[email protected]> wrote:
> >
> > On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <[email protected]> wrote:
> > >
> > >
> > >
> > > > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <[email protected]> wrote:
> > > >
> > > > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <[email protected]> wrote:
> > > >>
> > > >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <[email protected]> wrote:
> > > >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <[email protected]> wrote:
> > > >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <[email protected]> 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.
On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <[email protected]> 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
http://www.paul-moore.com
On 10/14/2020 8:57 AM, Paul Moore wrote:
> On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <[email protected]> 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".
On Wed, Oct 14, 2020 at 12:31 PM Casey Schaufler <[email protected]> wrote:
> On 10/14/2020 8:57 AM, Paul Moore wrote:
> > On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <[email protected]> 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
http://www.paul-moore.com
On Wed, Oct 14, 2020 at 8:11 PM Paul Moore <[email protected]> wrote:
>
> On Wed, Oct 14, 2020 at 12:31 PM Casey Schaufler <[email protected]> wrote:
> > On 10/14/2020 8:57 AM, Paul Moore wrote:
> > > On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <[email protected]> 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
> http://www.paul-moore.com
On Wed, Nov 4, 2020 at 9:21 AM Olga Kornievskaia <[email protected]> wrote:
> On Wed, Oct 14, 2020 at 8:11 PM Paul Moore <[email protected]> wrote:
> > On Wed, Oct 14, 2020 at 12:31 PM Casey Schaufler <[email protected]> wrote:
> > > On 10/14/2020 8:57 AM, Paul Moore wrote:
> > > > On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <[email protected]> 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
http://www.paul-moore.com