"operation not support" when execute #restorecon -R /

"operation not support" when execute #restorecon -R /

[casinee app]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Hi,
when i execute #restorecon -R / , all the output is "... operation not
support".  I had check the source code, and in
linux/security/selinux/hooks.c :
         ...
sbsec = inode->i_sb->s_security;
if (!(sbsec->flags & SE_SBLABELSUPP))
{
return -EOPNOTSUPP;
}
        ...
it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know how can i
do to make the filesystem to support the SecurityContext of selinux.
Thanks.

[-- Attachment #2: Type: text/html, Size: 938 bytes --]

Re: "operation not support" when execute #restorecon -R /

[David Quigley]

On 06/05/2012 02:51, casinee app wrote:
> Hi,
> when i execute #restorecon -R / , all the output is "... operation
> not support".  I had check the source code, and in
> linux/security/selinux/hooks.c :
>
>          ...
>  sbsec = inode->i_sb->s_security;
>  if (!(sbsec->flags & SE_SBLABELSUPP))
>  {
>  return -EOPNOTSUPP;
>  }
>         ...
> it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know how
> can i do to make the filesystem to support the SecurityContext of
> selinux. 
> Thanks.

Which filesystem is this?

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "operation not support" when execute #restorecon -R /

[casinee app]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

the NFS. I had applied a patch to the kernel to support the xattr of NFS
filesystem.

2012/6/5 David Quigley <selinux@davequigley.com>

> On 06/05/2012 02:51, casinee app wrote:
>
>> Hi,
>> when i execute #restorecon -R / , all the output is "... operation
>> not support".  I had check the source code, and in
>> linux/security/selinux/hooks.c :
>>
>>          ...
>>  sbsec = inode->i_sb->s_security;
>>  if (!(sbsec->flags & SE_SBLABELSUPP))
>>  {
>>  return -EOPNOTSUPP;
>>  }
>>         ...
>> it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know how
>> can i do to make the filesystem to support the SecurityContext of
>> selinux.
>> Thanks.
>>
>
> Which filesystem is this?
>
> Dave
>
>

[-- Attachment #2: Type: text/html, Size: 1196 bytes --]

Re: "operation not support" when execute #restorecon -R /

[David Quigley]

On 06/05/2012 21:34, casinee app wrote:
> the NFS. I had applied a patch to the kernel to support the xattr of
> NFS filesystem.
>
> 2012/6/5 David Quigley <selinux@davequigley.com>
>
>> On 06/05/2012 02:51, casinee app wrote:
>>
>>> Hi,
>>> when i execute #restorecon -R / , all the output is "... operation
>>> not support".  I had check the source code, and in
>>> linux/security/selinux/hooks.c :
>>>
>>>          ...
>>>  sbsec = inode->i_sb->s_security;
>>>  if (!(sbsec->flags & SE_SBLABELSUPP))
>>>  {
>>>  return -EOPNOTSUPP;
>>>  }
>>>         ...
>>> it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know 
>>> how
>>> can i do to make the filesystem to support the SecurityContext of
>>> selinux. 
>>> Thanks.
>>
>> Which filesystem is this?
>>
>> Dave

Where did you get this patch? Is it supposed to be generic xattr 
support in NFS? if so what version?

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "operation not support" when execute #restorecon -R /

[casinee app]

2012/6/13 David Quigley <selinux@davequigley.com>:
> On 06/05/2012 21:34, casinee app wrote:
>>
>> the NFS. I had applied a patch to the kernel to support the xattr of
>> NFS filesystem.
>>
>> 2012/6/5 David Quigley <selinux@davequigley.com>
>>
>>> On 06/05/2012 02:51, casinee app wrote:
>>>
>>>> Hi,
>>>> when i execute #restorecon -R / , all the output is "... operation
>>>> not support".  I had check the source code, and in
>>>> linux/security/selinux/hooks.c :
>>>>
>>>>          ...
>>>>  sbsec = inode->i_sb->s_security;
>>>>  if (!(sbsec->flags & SE_SBLABELSUPP))
>>>>  {
>>>>  return -EOPNOTSUPP;
>>>>  }
>>>>         ...
>>>> it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know how
>>>> can i do to make the filesystem to support the SecurityContext of
>>>> selinux.
>>>> Thanks.
>>>
>>>
>>> Which filesystem is this?
>>>
>>> Dave
>
>
> Where did you get this patch? Is it supposed to be generic xattr support in
> NFS? if so what version?
>

I got the patch from the website  http://namei.org/nfsxattr/ .  After
i applied the patch,
when i config the kernel, i can see the options like this:
...
<*>   NFS client support
  [*]     NFS client support for NFS version 3
  [*]   NFS client support for the NFSv3 ACL protocol extension
  [*]   NFS client support for the NFSv3 XATTR protocol extension (EXPERIMENTAL)
  [*]     Extended attributes in the user namespace (EXPERIMENTAL)
  [*]   NFS client support for NFS version 4 (EXPERIMENTAL)
  [*]   Root file system on NFS
 <M>   NFS server support
    -*-     NFS server support for NFS version 3
   [*]       NFS server support for the NFSv3 ACL protocol extension
   [*]       NFS server support for the NFSv3 XATTR protocol extension
(EXPERIMENTAL)
   [*]     NFS server support for NFS version 4 (EXPERIMENTAL)


> Dave
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "operation not support" when execute #restorecon -R /

[Casey Schaufler]

On 6/12/2012 7:29 PM, casinee app wrote:
> 2012/6/13 David Quigley <selinux@davequigley.com>:
>> On 06/05/2012 21:34, casinee app wrote:
>>> the NFS. I had applied a patch to the kernel to support the xattr of
>>> NFS filesystem.
>>>
>>> 2012/6/5 David Quigley <selinux@davequigley.com>
>>>
>>>> On 06/05/2012 02:51, casinee app wrote:
>>>>
>>>>> Hi,
>>>>> when i execute #restorecon -R / , all the output is "... operation
>>>>> not support".  I had check the source code, and in
>>>>> linux/security/selinux/hooks.c :
>>>>>
>>>>>          ...
>>>>>  sbsec = inode->i_sb->s_security;
>>>>>  if (!(sbsec->flags & SE_SBLABELSUPP))
>>>>>  {
>>>>>  return -EOPNOTSUPP;
>>>>>  }
>>>>>         ...
>>>>> it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know how
>>>>> can i do to make the filesystem to support the SecurityContext of
>>>>> selinux.
>>>>> Thanks.
>>>>
>>>> Which filesystem is this?
>>>>
>>>> Dave
>>
>> Where did you get this patch? Is it supposed to be generic xattr support in
>> NFS? if so what version?
>>
> I got the patch from the website  http://namei.org/nfsxattr/ .  After
> i applied the patch,
> when i config the kernel, i can see the options like this:
> ...
> <*>   NFS client support
>   [*]     NFS client support for NFS version 3
>   [*]   NFS client support for the NFSv3 ACL protocol extension
>   [*]   NFS client support for the NFSv3 XATTR protocol extension (EXPERIMENTAL)
>   [*]     Extended attributes in the user namespace (EXPERIMENTAL)
>   [*]   NFS client support for NFS version 4 (EXPERIMENTAL)
>   [*]   Root file system on NFS
>  <M>   NFS server support
>     -*-     NFS server support for NFS version 3
>    [*]       NFS server support for the NFSv3 ACL protocol extension
>    [*]       NFS server support for the NFSv3 XATTR protocol extension
> (EXPERIMENTAL)
>    [*]     NFS server support for NFS version 4 (EXPERIMENTAL)

Ah, James' generic xattr patches. Very useful, fully functional, the
right thing is every way and totally despised by the NFS and IETF crowd.
They're fine to use for experimental purposes, but it is hard to imagine
them ever getting upstream.


>
>
>> Dave
>>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "operation not support" when execute #restorecon -R /

[David Quigley]

On 06/13/2012 12:16, Casey Schaufler wrote:
> On 6/12/2012 7:29 PM, casinee app wrote:
>> 2012/6/13 David Quigley <selinux@davequigley.com>:
>>> On 06/05/2012 21:34, casinee app wrote:
>>>> the NFS. I had applied a patch to the kernel to support the xattr 
>>>> of
>>>> NFS filesystem.
>>>>
>>>> 2012/6/5 David Quigley <selinux@davequigley.com>
>>>>
>>>>> On 06/05/2012 02:51, casinee app wrote:
>>>>>
>>>>>> Hi,
>>>>>> when i execute #restorecon -R / , all the output is "... 
>>>>>> operation
>>>>>> not support".  I had check the source code, and in
>>>>>> linux/security/selinux/hooks.c :
>>>>>>
>>>>>>          ...
>>>>>>  sbsec = inode->i_sb->s_security;
>>>>>>  if (!(sbsec->flags & SE_SBLABELSUPP))
>>>>>>  {
>>>>>>  return -EOPNOTSUPP;
>>>>>>  }
>>>>>>         ...
>>>>>> it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know 
>>>>>> how
>>>>>> can i do to make the filesystem to support the SecurityContext 
>>>>>> of
>>>>>> selinux.
>>>>>> Thanks.
>>>>>
>>>>> Which filesystem is this?
>>>>>
>>>>> Dave
>>>
>>> Where did you get this patch? Is it supposed to be generic xattr 
>>> support in
>>> NFS? if so what version?
>>>
>> I got the patch from the website  http://namei.org/nfsxattr/ .  
>> After
>> i applied the patch,
>> when i config the kernel, i can see the options like this:
>> ...
>> <*>   NFS client support
>>   [*]     NFS client support for NFS version 3
>>   [*]   NFS client support for the NFSv3 ACL protocol extension
>>   [*]   NFS client support for the NFSv3 XATTR protocol extension 
>> (EXPERIMENTAL)
>>   [*]     Extended attributes in the user namespace (EXPERIMENTAL)
>>   [*]   NFS client support for NFS version 4 (EXPERIMENTAL)
>>   [*]   Root file system on NFS
>>  <M>   NFS server support
>>     -*-     NFS server support for NFS version 3
>>    [*]       NFS server support for the NFSv3 ACL protocol extension
>>    [*]       NFS server support for the NFSv3 XATTR protocol 
>> extension
>> (EXPERIMENTAL)
>>    [*]     NFS server support for NFS version 4 (EXPERIMENTAL)
>
> Ah, James' generic xattr patches. Very useful, fully functional, the
> right thing is every way and totally despised by the NFS and IETF 
> crowd.
> They're fine to use for experimental purposes, but it is hard to 
> imagine
> them ever getting upstream.
>
>
>>
>>
>>> Dave
>>>
>>
>> --
>> This message was distributed to subscribers of the selinux mailing 
>> list.
>> If you no longer wish to subscribe, send mail to 
>> majordomo@tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>>


Proper XATTR support is not despised by the IETF. Trond at one point 
proposed to do XATTRS for NFSv4. However it is not the ideal solution 
for security attributes. The security attribute should be a first class 
citizen as it is in other UNIX like operating systems. Just because 
Linux has crammed it into an XATTR doesn't mean that NFSv4 or FreeBSD or 
Solaris or any number of other systems should be forced to do it as 
well.

The main reason these patches weren't taken is because everyone is 
strongly encouraging people to migrate away from NFSv3 and onto NFSv4. 
Having this kind of support in NFSv3 is a bad idea for two fold. One it 
will hinder migration to NFSv4 when it should happen and two it will 
never be part of the standard. This means this extension will be Linux 
only and not work with any of the other standards compliant hardware. 
This is the reason Labeled NFS is taking so long to get in the kernel. 
The Linux NFS maintainers don't want Linux specific extensions stuck in 
the kernel with no backing by storage vendors. Lets be honest here most 
if not all enterprises are using NetApp/EMC/Panases/Etc.... network 
storage appliances. They aren't sticking a Linux server with raid 
controllers in it on their network to keep track of their important 
data. So something that is a Linux specific extension does no one any 
good.

That being said the ideal person to contact to find out why it isn't 
working would be James Morris. If he wants to keep the patches up to 
date he is welcome to but this was a stop gap method until we got 
Labeled NFS in the kernel. It was determined that NFSv4 with Labeled NFS 
was the proper solution to the problem.

Dave

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "operation not support" when execute #restorecon -R /

[Stephen Smalley]

On Wed, 2012-06-13 at 14:17 -0400, David Quigley wrote:
> That being said the ideal person to contact to find out why it isn't 
> working would be James Morris. If he wants to keep the patches up to 
> date he is welcome to but this was a stop gap method until we got 
> Labeled NFS in the kernel. It was determined that NFSv4 with Labeled NFS 
> was the proper solution to the problem.

Isn't the problem just that he needs to modify his policy so that
SELinux knows to use the xattr support for nfsv3?  fs_use_xattr 

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "operation not support" when execute #restorecon -R /

[David Quigley]

On 06/13/2012 14:36, Stephen Smalley wrote:
> On Wed, 2012-06-13 at 14:17 -0400, David Quigley wrote:
>> That being said the ideal person to contact to find out why it isn't
>> working would be James Morris. If he wants to keep the patches up to
>> date he is welcome to but this was a stop gap method until we got
>> Labeled NFS in the kernel. It was determined that NFSv4 with Labeled 
>> NFS
>> was the proper solution to the problem.
>
> Isn't the problem just that he needs to modify his policy so that
> SELinux knows to use the xattr support for nfsv3?  fs_use_xattr


I can't say for sure but that would definitely be the first place to 
start. I'm not sure if that code path has changed since James released 
the patches. If it hasn't then its just a simple policy change. If it 
has his initial assumptions might not hold true and he may need to 
modify something in the NFS mount handling code.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "operation not support" when execute #restorecon -R /

[Stephen Smalley]

On Wed, 2012-06-13 at 14:36 -0400, Stephen Smalley wrote:
> On Wed, 2012-06-13 at 14:17 -0400, David Quigley wrote:
> > That being said the ideal person to contact to find out why it isn't 
> > working would be James Morris. If he wants to keep the patches up to 
> > date he is welcome to but this was a stop gap method until we got 
> > Labeled NFS in the kernel. It was determined that NFSv4 with Labeled NFS 
> > was the proper solution to the problem.
> 
> Isn't the problem just that he needs to modify his policy so that
> SELinux knows to use the xattr support for nfsv3?  fs_use_xattr 

So, to clarify, if he is using nfsv3 (not nfsv4) and wants SELinux to
use the xattr support from James' patches, he needs to add a line like
the following to his policy:
fs_use_xattr nfs gen_context(system_u:object_r:fs_t,s0);

See the examples in policy/modules/kernel/filesystem.te if using
refpolicy.

Then the filesystem will be treated as supporting security labels and
restorecon will work (or at least get past that particular error).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: "operation not support" when execute #restorecon -R /

[Vu, Joseph]

Dave,

I am a new Linux user and really interested in using the Labeled NFS.
Thank you for clarifying the patch intention.

I have been following the discussion on the Draft requirement of the Labeled NFS on IETF org.

For the purpose of planning, I am interested in finding the planning on when the Labeled NFS would be available.
Is there a plan in place for the Labeled NFS?

Thanks,

Joe

-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On Behalf Of David Quigley
Sent: Wednesday, June 13, 2012 1:17 PM
To: Casey Schaufler
Cc: casinee app; SE-Linux
Subject: Re: "operation not support" when execute #restorecon -R /

On 06/13/2012 12:16, Casey Schaufler wrote:
> On 6/12/2012 7:29 PM, casinee app wrote:
>> 2012/6/13 David Quigley <selinux@davequigley.com>:
>>> On 06/05/2012 21:34, casinee app wrote:
>>>> the NFS. I had applied a patch to the kernel to support the xattr 
>>>> of NFS filesystem.
>>>>
>>>> 2012/6/5 David Quigley <selinux@davequigley.com>
>>>>
>>>>> On 06/05/2012 02:51, casinee app wrote:
>>>>>
>>>>>> Hi,
>>>>>> when i execute #restorecon -R / , all the output is "... 
>>>>>> operation
>>>>>> not support".  I had check the source code, and in 
>>>>>> linux/security/selinux/hooks.c :
>>>>>>
>>>>>>          ...
>>>>>>  sbsec = inode->i_sb->s_security;  if (!(sbsec->flags & 
>>>>>> SE_SBLABELSUPP))  {  return -EOPNOTSUPP;  }
>>>>>>         ...
>>>>>> it returned. The  SE_SBLABELSUPP defined as 0x40, i want to know 
>>>>>> how can i do to make the filesystem to support the 
>>>>>> SecurityContext of selinux.
>>>>>> Thanks.
>>>>>
>>>>> Which filesystem is this?
>>>>>
>>>>> Dave
>>>
>>> Where did you get this patch? Is it supposed to be generic xattr 
>>> support in NFS? if so what version?
>>>
>> I got the patch from the website  http://namei.org/nfsxattr/ .  
>> After
>> i applied the patch,
>> when i config the kernel, i can see the options like this:
>> ...
>> <*>   NFS client support
>>   [*]     NFS client support for NFS version 3
>>   [*]   NFS client support for the NFSv3 ACL protocol extension
>>   [*]   NFS client support for the NFSv3 XATTR protocol extension 
>> (EXPERIMENTAL)
>>   [*]     Extended attributes in the user namespace (EXPERIMENTAL)
>>   [*]   NFS client support for NFS version 4 (EXPERIMENTAL)
>>   [*]   Root file system on NFS
>>  <M>   NFS server support
>>     -*-     NFS server support for NFS version 3
>>    [*]       NFS server support for the NFSv3 ACL protocol extension
>>    [*]       NFS server support for the NFSv3 XATTR protocol 
>> extension
>> (EXPERIMENTAL)
>>    [*]     NFS server support for NFS version 4 (EXPERIMENTAL)
>
> Ah, James' generic xattr patches. Very useful, fully functional, the 
> right thing is every way and totally despised by the NFS and IETF 
> crowd.
> They're fine to use for experimental purposes, but it is hard to 
> imagine them ever getting upstream.
>
>
>>
>>
>>> Dave
>>>
>>
>> --
>> This message was distributed to subscribers of the selinux mailing 
>> list.
>> If you no longer wish to subscribe, send mail to 
>> majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without 
>> quotes as the message.
>>


Proper XATTR support is not despised by the IETF. Trond at one point proposed to do XATTRS for NFSv4. However it is not the ideal solution for security attributes. The security attribute should be a first class citizen as it is in other UNIX like operating systems. Just because Linux has crammed it into an XATTR doesn't mean that NFSv4 or FreeBSD or Solaris or any number of other systems should be forced to do it as well.

The main reason these patches weren't taken is because everyone is strongly encouraging people to migrate away from NFSv3 and onto NFSv4. 
Having this kind of support in NFSv3 is a bad idea for two fold. One it will hinder migration to NFSv4 when it should happen and two it will never be part of the standard. This means this extension will be Linux only and not work with any of the other standards compliant hardware. 
This is the reason Labeled NFS is taking so long to get in the kernel. 
The Linux NFS maintainers don't want Linux specific extensions stuck in the kernel with no backing by storage vendors. Lets be honest here most if not all enterprises are using NetApp/EMC/Panases/Etc.... network storage appliances. They aren't sticking a Linux server with raid controllers in it on their network to keep track of their important data. So something that is a Linux specific extension does no one any good.

That being said the ideal person to contact to find out why it isn't working would be James Morris. If he wants to keep the patches up to date he is welcome to but this was a stop gap method until we got Labeled NFS in the kernel. It was determined that NFSv4 with Labeled NFS was the proper solution to the problem.

Dave

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.