Default context with context mount option.

Default context with context mount option.

[dE]

When a new file is created on a FS which supports security namespace but 
the FS is mounted using context= option, then what will be the context 
of the newly created file on the FS?

I did exactly this, and next, umount and then mount the FS readonly to 
get the getfattr dump to realize the security namespace is not empty 
(this came as a surprise).

So, can someone explain what exactly happens in this case?

Thanks.

Re: Default context with context mount option.

[Christian Evans]

On Sun, 08 Jun 2014 20:18:15 +0530
dE <de.techno@gmail.com> wrote:

> When a new file is created on a FS which supports security namespace but 
> the FS is mounted using context= option, then what will be the context 
> of the newly created file on the FS?
> 

What do you mean by "security namespace" actually?

Re: Default context with context mount option.

[dE]

On 06/08/14 23:16, Christian Evans wrote:
> On Sun, 08 Jun 2014 20:18:15 +0530
> dE <de.techno@gmail.com> wrote:
>
>> When a new file is created on a FS which supports security namespace but
>> the FS is mounted using context= option, then what will be the context
>> of the newly created file on the FS?
>>
> What do you mean by "security namespace" actually?
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

The xattr security namespace in the file system which's used by SELinux 
to store security context.

Re: Default context with context mount option.

[Stephen Smalley]

On 06/08/2014 10:48 AM, dE wrote:
> When a new file is created on a FS which supports security namespace but
> the FS is mounted using context= option, then what will be the context
> of the newly created file on the FS?
> 
> I did exactly this, and next, umount and then mount the FS readonly to
> get the getfattr dump to realize the security namespace is not empty
> (this came as a surprise).
> 
> So, can someone explain what exactly happens in this case?

The kernel lies to you ;)

If SELinux (or another security module that implements the
inode_getsecurity and inode_listsecurity hooks) is enabled, then the
security module gets to report its view of the security.* attributes to
userspace instead of whatever may or may not be stored by the
filesystem.  That allows SELinux to handle such requests even for
filesystems that do not natively support the security.* namespace as
well as remap attribute values as needed to deal with removed types or
conversion from non-MLS to MLS policies or various other situations.

Re: Default context with context mount option.

[dE]

On 06/09/14 19:04, Stephen Smalley wrote:
> On 06/08/2014 10:48 AM, dE wrote:
>> When a new file is created on a FS which supports security namespace but
>> the FS is mounted using context= option, then what will be the context
>> of the newly created file on the FS?
>>
>> I did exactly this, and next, umount and then mount the FS readonly to
>> get the getfattr dump to realize the security namespace is not empty
>> (this came as a surprise).
>>
>> So, can someone explain what exactly happens in this case?
> The kernel lies to you ;)
>
> If SELinux (or another security module that implements the
> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
> security module gets to report its view of the security.* attributes to
> userspace instead of whatever may or may not be stored by the
> filesystem.  That allows SELinux to handle such requests even for
> filesystems that do not natively support the security.* namespace as
> well as remap attribute values as needed to deal with removed types or
> conversion from non-MLS to MLS policies or various other situations.

Yes, if I mount vfat for e.g. check the xattr using getfattr, there does 
exist a security attribute. But these FSs are defined by genfscon.

But about FSs which do support the security namespace (like XFS), and so 
do not have a genfscon statement associated to them they but still have 
a security namespace value (as reported by the kernel, which lies to 
userspace).

Question is -- are these values actually written to the FS or are they 
just empty? Things get more confusing cause I get permission denied when 
trying to delete the security namespace values.

Re: Default context with context mount option.

[Stephen Smalley]

On 06/10/2014 04:16 AM, dE wrote:
> On 06/09/14 19:04, Stephen Smalley wrote:
>> On 06/08/2014 10:48 AM, dE wrote:
>>> When a new file is created on a FS which supports security namespace but
>>> the FS is mounted using context= option, then what will be the context
>>> of the newly created file on the FS?
>>>
>>> I did exactly this, and next, umount and then mount the FS readonly to
>>> get the getfattr dump to realize the security namespace is not empty
>>> (this came as a surprise).
>>>
>>> So, can someone explain what exactly happens in this case?
>> The kernel lies to you ;)
>>
>> If SELinux (or another security module that implements the
>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>> security module gets to report its view of the security.* attributes to
>> userspace instead of whatever may or may not be stored by the
>> filesystem.  That allows SELinux to handle such requests even for
>> filesystems that do not natively support the security.* namespace as
>> well as remap attribute values as needed to deal with removed types or
>> conversion from non-MLS to MLS policies or various other situations.
> 
> Yes, if I mount vfat for e.g. check the xattr using getfattr, there does
> exist a security attribute. But these FSs are defined by genfscon.
> 
> But about FSs which do support the security namespace (like XFS), and so
> do not have a genfscon statement associated to them they but still have
> a security namespace value (as reported by the kernel, which lies to
> userspace).
> 
> Question is -- are these values actually written to the FS or are they
> just empty? Things get more confusing cause I get permission denied when
> trying to delete the security namespace values.

It shouldn't be written to the filesystem.  You can check by booting
with SELinux disabled (selinux=0 on the kernel command-line or
/etc/selinux/config SELINUX=disabled) and then running getfattr; then
the kernel will just call down to the filesystem code to fetch the
attribute without any interference by the security module.  However,
note that this will trigger an automatic filesystem relabel upon reboot
into SELinux to ensure that all files are labeled, which can take some time.

With regard to removing the security.selinux attributes, SELinux also
prohibits that entirely; see
security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
again, to do that, you'd have to boot with SELinux disabled, but it
shouldn't be necessary.

RE: Default context with context mount option.

[David Caplan]

> -----Original Message-----
> From: Selinux [mailto:selinux-bounces@tycho.nsa.gov] On Behalf Of
> Stephen Smalley
> Sent: Tuesday, June 10, 2014 8:05 AM
> To: dE; selinux@tycho.nsa.gov
> Subject: Re: Default context with context mount option.
> 
> On 06/10/2014 04:16 AM, dE wrote:
> > On 06/09/14 19:04, Stephen Smalley wrote:
> >> On 06/08/2014 10:48 AM, dE wrote:
> >>> When a new file is created on a FS which supports security
> namespace but
> >>> the FS is mounted using context= option, then what will be the
> context
> >>> of the newly created file on the FS?
> >>>
> >>> I did exactly this, and next, umount and then mount the FS readonly
> to
> >>> get the getfattr dump to realize the security namespace is not
> empty
> >>> (this came as a surprise).
> >>>
> >>> So, can someone explain what exactly happens in this case?
> >> The kernel lies to you ;)
> >>
> >> If SELinux (or another security module that implements the
> >> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
> >> security module gets to report its view of the security.* attributes
> to
> >> userspace instead of whatever may or may not be stored by the
> >> filesystem.  That allows SELinux to handle such requests even for
> >> filesystems that do not natively support the security.* namespace as
> >> well as remap attribute values as needed to deal with removed types
> or
> >> conversion from non-MLS to MLS policies or various other situations.
> >
> > Yes, if I mount vfat for e.g. check the xattr using getfattr, there
> does
> > exist a security attribute. But these FSs are defined by genfscon.
> >
> > But about FSs which do support the security namespace (like XFS), and
> so
> > do not have a genfscon statement associated to them they but still
> have
> > a security namespace value (as reported by the kernel, which lies to
> > userspace).
> >
> > Question is -- are these values actually written to the FS or are
> they
> > just empty? Things get more confusing cause I get permission denied
> when
> > trying to delete the security namespace values.
> 
> It shouldn't be written to the filesystem.  You can check by booting
> with SELinux disabled (selinux=0 on the kernel command-line or
> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
> the kernel will just call down to the filesystem code to fetch the
> attribute without any interference by the security module.  However,
> note that this will trigger an automatic filesystem relabel upon reboot
> into SELinux to ensure that all files are labeled, which can take some
> time.
> 
> With regard to removing the security.selinux attributes, SELinux also
> prohibits that entirely; see
> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
> again, to do that, you'd have to boot with SELinux disabled, but it
> shouldn't be necessary.
> 

How about creating a file based filesystem image and mounting it with a loop device? You can mount it with context mount options or straight up and easily see changes (or no changes) to the filesystem. That way you don't have to disable selinux and reboot the whole system. You can easily experiment with whichever filesystem types you'd like. 

David

Re: Default context with context mount option.

[Stephen Smalley]

On 06/10/2014 11:41 AM, David Caplan wrote:
>> -----Original Message-----
>> From: Selinux [mailto:selinux-bounces@tycho.nsa.gov] On Behalf Of
>> Stephen Smalley
>> Sent: Tuesday, June 10, 2014 8:05 AM
>> To: dE; selinux@tycho.nsa.gov
>> Subject: Re: Default context with context mount option.
>>
>> On 06/10/2014 04:16 AM, dE wrote:
>>> On 06/09/14 19:04, Stephen Smalley wrote:
>>>> On 06/08/2014 10:48 AM, dE wrote:
>>>>> When a new file is created on a FS which supports security
>> namespace but
>>>>> the FS is mounted using context= option, then what will be the
>> context
>>>>> of the newly created file on the FS?
>>>>>
>>>>> I did exactly this, and next, umount and then mount the FS readonly
>> to
>>>>> get the getfattr dump to realize the security namespace is not
>> empty
>>>>> (this came as a surprise).
>>>>>
>>>>> So, can someone explain what exactly happens in this case?
>>>> The kernel lies to you ;)
>>>>
>>>> If SELinux (or another security module that implements the
>>>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>>>> security module gets to report its view of the security.* attributes
>> to
>>>> userspace instead of whatever may or may not be stored by the
>>>> filesystem.  That allows SELinux to handle such requests even for
>>>> filesystems that do not natively support the security.* namespace as
>>>> well as remap attribute values as needed to deal with removed types
>> or
>>>> conversion from non-MLS to MLS policies or various other situations.
>>>
>>> Yes, if I mount vfat for e.g. check the xattr using getfattr, there
>> does
>>> exist a security attribute. But these FSs are defined by genfscon.
>>>
>>> But about FSs which do support the security namespace (like XFS), and
>> so
>>> do not have a genfscon statement associated to them they but still
>> have
>>> a security namespace value (as reported by the kernel, which lies to
>>> userspace).
>>>
>>> Question is -- are these values actually written to the FS or are
>> they
>>> just empty? Things get more confusing cause I get permission denied
>> when
>>> trying to delete the security namespace values.
>>
>> It shouldn't be written to the filesystem.  You can check by booting
>> with SELinux disabled (selinux=0 on the kernel command-line or
>> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
>> the kernel will just call down to the filesystem code to fetch the
>> attribute without any interference by the security module.  However,
>> note that this will trigger an automatic filesystem relabel upon reboot
>> into SELinux to ensure that all files are labeled, which can take some
>> time.
>>
>> With regard to removing the security.selinux attributes, SELinux also
>> prohibits that entirely; see
>> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
>> again, to do that, you'd have to boot with SELinux disabled, but it
>> shouldn't be necessary.
>>
> 
> How about creating a file based filesystem image and mounting it with a loop device? You can mount it with context mount options or straight up and easily see changes (or no changes) to the filesystem. That way you don't have to disable selinux and reboot the whole system. You can easily experiment with whichever filesystem types you'd like. 

I could be wrong, but as long as SELinux is enabled in the kernel I
don't believe that will change anything.  SELinux will still interpose
on getxattr() and listxattr() requests performed on directories and
files in the mounted filesystem, and it will still prohibit removexattr
of the security.selinux attribute on such files.

Now, you could of course create a VM, perform your test there and only
disable SELinux in the VM.

Re: Default context with context mount option.

[dE]

On 06/10/14 17:35, Stephen Smalley wrote:
> On 06/10/2014 04:16 AM, dE wrote:
>> On 06/09/14 19:04, Stephen Smalley wrote:
>>> On 06/08/2014 10:48 AM, dE wrote:
>>>> When a new file is created on a FS which supports security namespace but
>>>> the FS is mounted using context= option, then what will be the context
>>>> of the newly created file on the FS?
>>>>
>>>> I did exactly this, and next, umount and then mount the FS readonly to
>>>> get the getfattr dump to realize the security namespace is not empty
>>>> (this came as a surprise).
>>>>
>>>> So, can someone explain what exactly happens in this case?
>>> The kernel lies to you ;)
>>>
>>> If SELinux (or another security module that implements the
>>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>>> security module gets to report its view of the security.* attributes to
>>> userspace instead of whatever may or may not be stored by the
>>> filesystem.  That allows SELinux to handle such requests even for
>>> filesystems that do not natively support the security.* namespace as
>>> well as remap attribute values as needed to deal with removed types or
>>> conversion from non-MLS to MLS policies or various other situations.
>> Yes, if I mount vfat for e.g. check the xattr using getfattr, there does
>> exist a security attribute. But these FSs are defined by genfscon.
>>
>> But about FSs which do support the security namespace (like XFS), and so
>> do not have a genfscon statement associated to them they but still have
>> a security namespace value (as reported by the kernel, which lies to
>> userspace).
>>
>> Question is -- are these values actually written to the FS or are they
>> just empty? Things get more confusing cause I get permission denied when
>> trying to delete the security namespace values.
> It shouldn't be written to the filesystem.  You can check by booting
> with SELinux disabled (selinux=0 on the kernel command-line or
> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
> the kernel will just call down to the filesystem code to fetch the
> attribute without any interference by the security module.  However,
> note that this will trigger an automatic filesystem relabel upon reboot
> into SELinux to ensure that all files are labeled, which can take some time.
>
> With regard to removing the security.selinux attributes, SELinux also
> prohibits that entirely; see
> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
> again, to do that, you'd have to boot with SELinux disabled, but it
> shouldn't be necessary.

So preventing removal of security namespace is hard coded into the kernel.

I booted off sysrescuecd to check the security context -- and no, there 
was no security context for the file.

Thanks for clarifying.

Re: Default context with context mount option.

[dE]

On 06/10/14 21:11, David Caplan wrote:
>> -----Original Message-----
>> From: Selinux [mailto:selinux-bounces@tycho.nsa.gov] On Behalf Of
>> Stephen Smalley
>> Sent: Tuesday, June 10, 2014 8:05 AM
>> To: dE; selinux@tycho.nsa.gov
>> Subject: Re: Default context with context mount option.
>>
>> On 06/10/2014 04:16 AM, dE wrote:
>>> On 06/09/14 19:04, Stephen Smalley wrote:
>>>> On 06/08/2014 10:48 AM, dE wrote:
>>>>> When a new file is created on a FS which supports security
>> namespace but
>>>>> the FS is mounted using context= option, then what will be the
>> context
>>>>> of the newly created file on the FS?
>>>>>
>>>>> I did exactly this, and next, umount and then mount the FS readonly
>> to
>>>>> get the getfattr dump to realize the security namespace is not
>> empty
>>>>> (this came as a surprise).
>>>>>
>>>>> So, can someone explain what exactly happens in this case?
>>>> The kernel lies to you ;)
>>>>
>>>> If SELinux (or another security module that implements the
>>>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>>>> security module gets to report its view of the security.* attributes
>> to
>>>> userspace instead of whatever may or may not be stored by the
>>>> filesystem.  That allows SELinux to handle such requests even for
>>>> filesystems that do not natively support the security.* namespace as
>>>> well as remap attribute values as needed to deal with removed types
>> or
>>>> conversion from non-MLS to MLS policies or various other situations.
>>> Yes, if I mount vfat for e.g. check the xattr using getfattr, there
>> does
>>> exist a security attribute. But these FSs are defined by genfscon.
>>>
>>> But about FSs which do support the security namespace (like XFS), and
>> so
>>> do not have a genfscon statement associated to them they but still
>> have
>>> a security namespace value (as reported by the kernel, which lies to
>>> userspace).
>>>
>>> Question is -- are these values actually written to the FS or are
>> they
>>> just empty? Things get more confusing cause I get permission denied
>> when
>>> trying to delete the security namespace values.
>> It shouldn't be written to the filesystem.  You can check by booting
>> with SELinux disabled (selinux=0 on the kernel command-line or
>> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
>> the kernel will just call down to the filesystem code to fetch the
>> attribute without any interference by the security module.  However,
>> note that this will trigger an automatic filesystem relabel upon reboot
>> into SELinux to ensure that all files are labeled, which can take some
>> time.
>>
>> With regard to removing the security.selinux attributes, SELinux also
>> prohibits that entirely; see
>> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
>> again, to do that, you'd have to boot with SELinux disabled, but it
>> shouldn't be necessary.
>>
> How about creating a file based filesystem image and mounting it with a loop device? You can mount it with context mount options or straight up and easily see changes (or no changes) to the filesystem. That way you don't have to disable selinux and reboot the whole system. You can easily experiment with whichever filesystem types you'd like.
>
> David
>

Yeah, I did exactly that, but to see the actually xattr on the FS, you 
have to disable SELinux, cause get/setxattr works at VFS level; it 
queries the kernel for the xattr, and the kernel lies to it via SELinux 
(which has attached LSM hooks).

The manual loop mount idea is good to prevent an automatic relabel by 
the systemd services, but you have to disable SELinux.

Re: Default context with context mount option.

[dE]

On 06/10/14 17:35, Stephen Smalley wrote:
> On 06/10/2014 04:16 AM, dE wrote:
>> On 06/09/14 19:04, Stephen Smalley wrote:
>>> On 06/08/2014 10:48 AM, dE wrote:
>>>> When a new file is created on a FS which supports security namespace but
>>>> the FS is mounted using context= option, then what will be the context
>>>> of the newly created file on the FS?
>>>>
>>>> I did exactly this, and next, umount and then mount the FS readonly to
>>>> get the getfattr dump to realize the security namespace is not empty
>>>> (this came as a surprise).
>>>>
>>>> So, can someone explain what exactly happens in this case?
>>> The kernel lies to you ;)
>>>
>>> If SELinux (or another security module that implements the
>>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>>> security module gets to report its view of the security.* attributes to
>>> userspace instead of whatever may or may not be stored by the
>>> filesystem.  That allows SELinux to handle such requests even for
>>> filesystems that do not natively support the security.* namespace as
>>> well as remap attribute values as needed to deal with removed types or
>>> conversion from non-MLS to MLS policies or various other situations.
>> Yes, if I mount vfat for e.g. check the xattr using getfattr, there does
>> exist a security attribute. But these FSs are defined by genfscon.
>>
>> But about FSs which do support the security namespace (like XFS), and so
>> do not have a genfscon statement associated to them they but still have
>> a security namespace value (as reported by the kernel, which lies to
>> userspace).
>>
>> Question is -- are these values actually written to the FS or are they
>> just empty? Things get more confusing cause I get permission denied when
>> trying to delete the security namespace values.
> It shouldn't be written to the filesystem.  You can check by booting
> with SELinux disabled (selinux=0 on the kernel command-line or
> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
> the kernel will just call down to the filesystem code to fetch the
> attribute without any interference by the security module.  However,
> note that this will trigger an automatic filesystem relabel upon reboot
> into SELinux to ensure that all files are labeled, which can take some time.
>
> With regard to removing the security.selinux attributes, SELinux also
> prohibits that entirely; see
> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
> again, to do that, you'd have to boot with SELinux disabled, but it
> shouldn't be necessary.
>
>
>

Another question is -- what will be the default security context of a FS 
which does not have a genfscon statement associated to it? Does it 
depend on the policy or is it hard coded in the kernel?

 From what I've seen, it defaults to system_u:object_r:file_t:s0

Re: Default context with context mount option.

[Stephen Smalley]

On 06/11/2014 03:29 AM, dE wrote:
> On 06/10/14 17:35, Stephen Smalley wrote:
>> On 06/10/2014 04:16 AM, dE wrote:
>>> On 06/09/14 19:04, Stephen Smalley wrote:
>>>> On 06/08/2014 10:48 AM, dE wrote:
>>>>> When a new file is created on a FS which supports security
>>>>> namespace but
>>>>> the FS is mounted using context= option, then what will be the context
>>>>> of the newly created file on the FS?
>>>>>
>>>>> I did exactly this, and next, umount and then mount the FS readonly to
>>>>> get the getfattr dump to realize the security namespace is not empty
>>>>> (this came as a surprise).
>>>>>
>>>>> So, can someone explain what exactly happens in this case?
>>>> The kernel lies to you ;)
>>>>
>>>> If SELinux (or another security module that implements the
>>>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>>>> security module gets to report its view of the security.* attributes to
>>>> userspace instead of whatever may or may not be stored by the
>>>> filesystem.  That allows SELinux to handle such requests even for
>>>> filesystems that do not natively support the security.* namespace as
>>>> well as remap attribute values as needed to deal with removed types or
>>>> conversion from non-MLS to MLS policies or various other situations.
>>> Yes, if I mount vfat for e.g. check the xattr using getfattr, there does
>>> exist a security attribute. But these FSs are defined by genfscon.
>>>
>>> But about FSs which do support the security namespace (like XFS), and so
>>> do not have a genfscon statement associated to them they but still have
>>> a security namespace value (as reported by the kernel, which lies to
>>> userspace).
>>>
>>> Question is -- are these values actually written to the FS or are they
>>> just empty? Things get more confusing cause I get permission denied when
>>> trying to delete the security namespace values.
>> It shouldn't be written to the filesystem.  You can check by booting
>> with SELinux disabled (selinux=0 on the kernel command-line or
>> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
>> the kernel will just call down to the filesystem code to fetch the
>> attribute without any interference by the security module.  However,
>> note that this will trigger an automatic filesystem relabel upon reboot
>> into SELinux to ensure that all files are labeled, which can take some
>> time.
>>
>> With regard to removing the security.selinux attributes, SELinux also
>> prohibits that entirely; see
>> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
>> again, to do that, you'd have to boot with SELinux disabled, but it
>> shouldn't be necessary.
>>
>>
>>
> 
> Another question is -- what will be the default security context of a FS
> which does not have a genfscon statement associated to it? Does it
> depend on the policy or is it hard coded in the kernel?
> 
> From what I've seen, it defaults to system_u:object_r:file_t:s0

Whatever the unlabeled SID is mapped to by policy, typically unlabeled_t.

file_t is the type associated with the file SID, which is used as the
default label for files that lack any security.selinux xattr value in
filesystems that support xattrs.  That was recently collapsed into
unlabeled_t in refpolicy.

Re: Default context with context mount option.

[Daniel J Walsh]

On 06/11/2014 12:29 AM, dE wrote:
> On 06/10/14 17:35, Stephen Smalley wrote:
>> On 06/10/2014 04:16 AM, dE wrote:
>>> On 06/09/14 19:04, Stephen Smalley wrote:
>>>> On 06/08/2014 10:48 AM, dE wrote:
>>>>> When a new file is created on a FS which supports security
>>>>> namespace but
>>>>> the FS is mounted using context= option, then what will be the
>>>>> context
>>>>> of the newly created file on the FS?
>>>>>
>>>>> I did exactly this, and next, umount and then mount the FS
>>>>> readonly to
>>>>> get the getfattr dump to realize the security namespace is not empty
>>>>> (this came as a surprise).
>>>>>
>>>>> So, can someone explain what exactly happens in this case?
>>>> The kernel lies to you ;)
>>>>
>>>> If SELinux (or another security module that implements the
>>>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>>>> security module gets to report its view of the security.*
>>>> attributes to
>>>> userspace instead of whatever may or may not be stored by the
>>>> filesystem.  That allows SELinux to handle such requests even for
>>>> filesystems that do not natively support the security.* namespace as
>>>> well as remap attribute values as needed to deal with removed types or
>>>> conversion from non-MLS to MLS policies or various other situations.
>>> Yes, if I mount vfat for e.g. check the xattr using getfattr, there
>>> does
>>> exist a security attribute. But these FSs are defined by genfscon.
>>>
>>> But about FSs which do support the security namespace (like XFS),
>>> and so
>>> do not have a genfscon statement associated to them they but still have
>>> a security namespace value (as reported by the kernel, which lies to
>>> userspace).
>>>
>>> Question is -- are these values actually written to the FS or are they
>>> just empty? Things get more confusing cause I get permission denied
>>> when
>>> trying to delete the security namespace values.
>> It shouldn't be written to the filesystem.  You can check by booting
>> with SELinux disabled (selinux=0 on the kernel command-line or
>> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
>> the kernel will just call down to the filesystem code to fetch the
>> attribute without any interference by the security module.  However,
>> note that this will trigger an automatic filesystem relabel upon reboot
>> into SELinux to ensure that all files are labeled, which can take
>> some time.
>>
>> With regard to removing the security.selinux attributes, SELinux also
>> prohibits that entirely; see
>> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
>> again, to do that, you'd have to boot with SELinux disabled, but it
>> shouldn't be necessary.
>>
>>
>>
>
> Another question is -- what will be the default security context of a
> FS which does not have a genfscon statement associated to it? Does it
> depend on the policy or is it hard coded in the kernel?
>
> From what I've seen, it defaults to system_u:object_r:file_t:s0
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.
Policy states that file system objects without labels is file_t, In
latest Fedora and RHEL7 this is changed to unlabeled_t.

Re: Default context with context mount option.

[dE]

On 06/11/14 18:03, Stephen Smalley wrote:
> On 06/11/2014 03:29 AM, dE wrote:
>> On 06/10/14 17:35, Stephen Smalley wrote:
>>> On 06/10/2014 04:16 AM, dE wrote:
>>>> On 06/09/14 19:04, Stephen Smalley wrote:
>>>>> On 06/08/2014 10:48 AM, dE wrote:
>>>>>> When a new file is created on a FS which supports security
>>>>>> namespace but
>>>>>> the FS is mounted using context= option, then what will be the context
>>>>>> of the newly created file on the FS?
>>>>>>
>>>>>> I did exactly this, and next, umount and then mount the FS readonly to
>>>>>> get the getfattr dump to realize the security namespace is not empty
>>>>>> (this came as a surprise).
>>>>>>
>>>>>> So, can someone explain what exactly happens in this case?
>>>>> The kernel lies to you ;)
>>>>>
>>>>> If SELinux (or another security module that implements the
>>>>> inode_getsecurity and inode_listsecurity hooks) is enabled, then the
>>>>> security module gets to report its view of the security.* attributes to
>>>>> userspace instead of whatever may or may not be stored by the
>>>>> filesystem.  That allows SELinux to handle such requests even for
>>>>> filesystems that do not natively support the security.* namespace as
>>>>> well as remap attribute values as needed to deal with removed types or
>>>>> conversion from non-MLS to MLS policies or various other situations.
>>>> Yes, if I mount vfat for e.g. check the xattr using getfattr, there does
>>>> exist a security attribute. But these FSs are defined by genfscon.
>>>>
>>>> But about FSs which do support the security namespace (like XFS), and so
>>>> do not have a genfscon statement associated to them they but still have
>>>> a security namespace value (as reported by the kernel, which lies to
>>>> userspace).
>>>>
>>>> Question is -- are these values actually written to the FS or are they
>>>> just empty? Things get more confusing cause I get permission denied when
>>>> trying to delete the security namespace values.
>>> It shouldn't be written to the filesystem.  You can check by booting
>>> with SELinux disabled (selinux=0 on the kernel command-line or
>>> /etc/selinux/config SELINUX=disabled) and then running getfattr; then
>>> the kernel will just call down to the filesystem code to fetch the
>>> attribute without any interference by the security module.  However,
>>> note that this will trigger an automatic filesystem relabel upon reboot
>>> into SELinux to ensure that all files are labeled, which can take some
>>> time.
>>>
>>> With regard to removing the security.selinux attributes, SELinux also
>>> prohibits that entirely; see
>>> security/selinux/hooks.c:selinux_inode_removexattr() in the kernel.  So
>>> again, to do that, you'd have to boot with SELinux disabled, but it
>>> shouldn't be necessary.
>>>
>>>
>>>
>> Another question is -- what will be the default security context of a FS
>> which does not have a genfscon statement associated to it? Does it
>> depend on the policy or is it hard coded in the kernel?
>>
>>  From what I've seen, it defaults to system_u:object_r:file_t:s0
> Whatever the unlabeled SID is mapped to by policy, typically unlabeled_t.
>
> file_t is the type associated with the file SID, which is used as the
> default label for files that lack any security.selinux xattr value in
> filesystems that support xattrs.  That was recently collapsed into
> unlabeled_t in refpolicy.

Thanks for clarifying.