[PATCH] setfiles fails to relabel if selinux not enabled

[PATCH] setfiles fails to relabel if selinux not enabled

[Caleb Case]

Setfiles now checks the capabilities on the mounted file systems for
'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts) on
newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
feature is not available if selinux is not enabled. The result is that
setfiles silently fails to relabel any filesystems.

The patch below removes the check for seclabel if selinux is disabled.

As an alternative maybe seclabel should be available even if selinux is
disabled? It seems that whether a fs supports security labels is
independent of selinux being enabled.
---
 policycoreutils/setfiles/setfiles.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/policycoreutils/setfiles/setfiles.c b/policycoreutils/setfiles/setfiles.c
index 313767a..db2857f 100644
--- a/policycoreutils/setfiles/setfiles.c
+++ b/policycoreutils/setfiles/setfiles.c
@@ -750,6 +750,8 @@ static void exclude_non_seclabel_mounts()
 	/* Check to see if the kernel supports seclabel */
 	if (uname(&uts) == 0 && strverscmp(uts.release, "2.6.30") < 0)
 		return;
+	if (is_selinux_enabled() <= 0)
+		return;
 
 	fp = fopen("/proc/mounts", "r");
 	if (!fp)
-- 
1.6.0.4


--
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Stephen Smalley]

On Tue, 2009-09-15 at 15:20 -0400, Caleb Case wrote:
> Setfiles now checks the capabilities on the mounted file systems for
> 'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts) on
> newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
> feature is not available if selinux is not enabled. The result is that
> setfiles silently fails to relabel any filesystems.
> 
> The patch below removes the check for seclabel if selinux is disabled.
> 
> As an alternative maybe seclabel should be available even if selinux is
> disabled? It seems that whether a fs supports security labels is
> independent of selinux being enabled.

That would be difficult as the seclabel option is driven by policy, not
just by the presence/absence of xattr handlers (the issue is whether
SELinux will honor setxattr operations, which is not the case for
filesystems using genfscon or context mount options).

So I guess this is the best we can do.

> ---
>  policycoreutils/setfiles/setfiles.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/policycoreutils/setfiles/setfiles.c b/policycoreutils/setfiles/setfiles.c
> index 313767a..db2857f 100644
> --- a/policycoreutils/setfiles/setfiles.c
> +++ b/policycoreutils/setfiles/setfiles.c
> @@ -750,6 +750,8 @@ static void exclude_non_seclabel_mounts()
>  	/* Check to see if the kernel supports seclabel */
>  	if (uname(&uts) == 0 && strverscmp(uts.release, "2.6.30") < 0)
>  		return;
> +	if (is_selinux_enabled() <= 0)
> +		return;
>  
>  	fp = fopen("/proc/mounts", "r");
>  	if (!fp)
-- 
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Joshua Brindle]

On 2009-09-15 Stephen Smalley wrote:
> On Tue, 2009-09-15 at 15:20 -0400, Caleb Case wrote:
>> Setfiles now checks the capabilities on the mounted file systems for
>> 'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts)
on
>> newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
>> feature is not available if selinux is not enabled. The result is
that
>> setfiles silently fails to relabel any filesystems.
>> 
>> The patch below removes the check for seclabel if selinux is
disabled.
>> 
>> As an alternative maybe seclabel should be available even if selinux
>> is disabled? It seems that whether a fs supports security labels is
>> independent of selinux being enabled.
> 
> That would be difficult as the seclabel option is driven by policy,
> not just by the presence/absence of xattr handlers (the issue is
> whether SELinux will honor setxattr operations, which is not the case
> for filesystems using genfscon or context mount options).
> 
> So I guess this is the best we can do.
> 

What is the best we can do? Should we always attempt to relabel if
selinux is disabled or not?

>> ---
>>  policycoreutils/setfiles/setfiles.c |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>> diff --git a/policycoreutils/setfiles/setfiles.c
>> b/policycoreutils/setfiles/setfiles.c
>> index 313767a..db2857f 100644
>> --- a/policycoreutils/setfiles/setfiles.c
>> +++ b/policycoreutils/setfiles/setfiles.c
>> @@ -750,6 +750,8 @@ static void exclude_non_seclabel_mounts()
>>  	/* Check to see if the kernel supports seclabel */
>>  	if (uname(&uts) == 0 && strverscmp(uts.release, "2.6.30") < 0)
>>  		return;
>> +	if (is_selinux_enabled() <= 0)
>> +		return;
>> 
>>  	fp = fopen("/proc/mounts", "r");
>>  	if (!fp)






--
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Daniel J Walsh]

On 09/15/2009 04:23 PM, Joshua Brindle wrote:
> On 2009-09-15 Stephen Smalley wrote:
>> On Tue, 2009-09-15 at 15:20 -0400, Caleb Case wrote:
>>> Setfiles now checks the capabilities on the mounted file systems for
>>> 'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts)
> on
>>> newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
>>> feature is not available if selinux is not enabled. The result is
> that
>>> setfiles silently fails to relabel any filesystems.
>>>
>>> The patch below removes the check for seclabel if selinux is
> disabled.
>>>
>>> As an alternative maybe seclabel should be available even if selinux
>>> is disabled? It seems that whether a fs supports security labels is
>>> independent of selinux being enabled.
>>
>> That would be difficult as the seclabel option is driven by policy,
>> not just by the presence/absence of xattr handlers (the issue is
>> whether SELinux will honor setxattr operations, which is not the case
>> for filesystems using genfscon or context mount options).
>>
>> So I guess this is the best we can do.
>>
> 
> What is the best we can do? Should we always attempt to relabel if
> selinux is disabled or not?
> 
>>> ---
>>>  policycoreutils/setfiles/setfiles.c |    2 ++
>>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>> diff --git a/policycoreutils/setfiles/setfiles.c
>>> b/policycoreutils/setfiles/setfiles.c
>>> index 313767a..db2857f 100644
>>> --- a/policycoreutils/setfiles/setfiles.c
>>> +++ b/policycoreutils/setfiles/setfiles.c
>>> @@ -750,6 +750,8 @@ static void exclude_non_seclabel_mounts()
>>>  	/* Check to see if the kernel supports seclabel */
>>>  	if (uname(&uts) == 0 && strverscmp(uts.release, "2.6.30") < 0)
>>>  		return;
>>> +	if (is_selinux_enabled() <= 0)
>>> +		return;
>>>
>>>  	fp = fopen("/proc/mounts", "r");
>>>  	if (!fp)
> 
> 
> 
> 
> 
> 
> --
> 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.
We want setfiles to work if selinux is disabled.

We have a use case of livecd creation on a box with SELinux disabled for example.

--
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Stephen Smalley]

On Tue, 2009-09-15 at 16:23 -0400, Joshua Brindle wrote:
> On 2009-09-15 Stephen Smalley wrote:
> > On Tue, 2009-09-15 at 15:20 -0400, Caleb Case wrote:
> >> Setfiles now checks the capabilities on the mounted file systems for
> >> 'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts)
> on
> >> newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
> >> feature is not available if selinux is not enabled. The result is
> that
> >> setfiles silently fails to relabel any filesystems.
> >> 
> >> The patch below removes the check for seclabel if selinux is
> disabled.
> >> 
> >> As an alternative maybe seclabel should be available even if selinux
> >> is disabled? It seems that whether a fs supports security labels is
> >> independent of selinux being enabled.
> > 
> > That would be difficult as the seclabel option is driven by policy,
> > not just by the presence/absence of xattr handlers (the issue is
> > whether SELinux will honor setxattr operations, which is not the case
> > for filesystems using genfscon or context mount options).
> > 
> > So I guess this is the best we can do.
> > 
> 
> What is the best we can do? Should we always attempt to relabel if
> selinux is disabled or not?

The patch is the best we can do - we shouldn't exclude any mounts based
on the absence of seclabel in /proc/mounts if SELinux is disabled.
Historically setfiles has always supported relabeling filesystems even
if SELinux was disabled in the host.

> >> ---
> >>  policycoreutils/setfiles/setfiles.c |    2 ++
> >>  1 files changed, 2 insertions(+), 0 deletions(-)
> >> diff --git a/policycoreutils/setfiles/setfiles.c
> >> b/policycoreutils/setfiles/setfiles.c
> >> index 313767a..db2857f 100644
> >> --- a/policycoreutils/setfiles/setfiles.c
> >> +++ b/policycoreutils/setfiles/setfiles.c
> >> @@ -750,6 +750,8 @@ static void exclude_non_seclabel_mounts()
> >>  	/* Check to see if the kernel supports seclabel */
> >>  	if (uname(&uts) == 0 && strverscmp(uts.release, "2.6.30") < 0)
> >>  		return;
> >> +	if (is_selinux_enabled() <= 0)
> >> +		return;
> >> 
> >>  	fp = fopen("/proc/mounts", "r");
> >>  	if (!fp)
> 
> 
> 
> 
-- 
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Jeff Johnson]

On Sep 16, 2009, at 10:02 AM, Stephen Smalley wrote:

>>
>> What is the best we can do? Should we always attempt to relabel if
>> selinux is disabled or not?
>
> The patch is the best we can do - we shouldn't exclude any mounts  
> based
> on the absence of seclabel in /proc/mounts if SELinux is disabled.
> Historically setfiles has always supported relabeling filesystems even
> if SELinux was disabled in the host.

There's a fundamental confusion between the act (of labelling) and the  
use of selinux labels.

The issue shows up when there are multiple (and possibly incompatible)
sets of labels, such as in chroot's, or creating an image for a  
different
installation.

One can choose to not install labels condition on whether  
is_selinux_enabled()
consistently and methodically.

Perhaps a simpple example to illustrate:

	Should cp(1) always copy security labels or only if is_selinux_enabled 
()?

What I'm hearing is "No. cp(1) should copy labels iff  
is_selinux_senabled() is TRUE."

73 de Jeff

--
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Stephen Smalley]

On Wed, 2009-09-16 at 10:16 -0400, Jeff Johnson wrote:
> On Sep 16, 2009, at 10:02 AM, Stephen Smalley wrote:
> 
> >>
> >> What is the best we can do? Should we always attempt to relabel if
> >> selinux is disabled or not?
> >
> > The patch is the best we can do - we shouldn't exclude any mounts  
> > based
> > on the absence of seclabel in /proc/mounts if SELinux is disabled.
> > Historically setfiles has always supported relabeling filesystems even
> > if SELinux was disabled in the host.
> 
> There's a fundamental confusion between the act (of labelling) and the  
> use of selinux labels.
> 
> The issue shows up when there are multiple (and possibly incompatible)
> sets of labels, such as in chroot's, or creating an image for a  
> different
> installation.
> 
> One can choose to not install labels condition on whether  
> is_selinux_enabled()
> consistently and methodically.
> 
> Perhaps a simpple example to illustrate:
> 
> 	Should cp(1) always copy security labels or only if is_selinux_enabled 
> ()?
> 
> What I'm hearing is "No. cp(1) should copy labels iff  
> is_selinux_senabled() is TRUE."

That's a different issue.  Here we are talking about a recent change to
setfiles that was preventing it from relabeling filesystems if SELinux
was disabled (because then no filesystems were reporting the seclabel
option in /proc/mounts).  As we want setfiles to support relabeling of
filesystems even if SELinux is disabled, we want to skip the seclabel
option processing in that case as the kernel won't report seclabel
information when SELinux is disabled (seclabel means more than just
"filesystem has an xattr handler").

As far as cp goes, I believe you are correct - it will only preserve
security contexts if SELinux is enabled, and even then, only if the
caller specified -a or -c.  And in the -a case, it has to be able to
gracefully fall back to not preserving the context if not permitted by
policy, as not all callers will be able to do so for the security
context even if they can do so for the DAC attributes.

Note that preserving security contexts may be using SELinux-specific
interfaces (e.g. setfscreatecon(3)) to create the copy directly in the
desired security context rather than creating the file and then
relabeling it after creation.

-- 
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Jeff Johnson]

On Sep 16, 2009, at 10:36 AM, Stephen Smalley wrote:

> On Wed, 2009-09-16 at 10:16 -0400, Jeff Johnson wrote:
>> On Sep 16, 2009, at 10:02 AM, Stephen Smalley wrote:
>>
>>>>
>>>> What is the best we can do? Should we always attempt to relabel if
>>>> selinux is disabled or not?
>>>
>>> The patch is the best we can do - we shouldn't exclude any mounts
>>> based
>>> on the absence of seclabel in /proc/mounts if SELinux is disabled.
>>> Historically setfiles has always supported relabeling filesystems  
>>> even
>>> if SELinux was disabled in the host.
>>
>> There's a fundamental confusion between the act (of labelling) and  
>> the
>> use of selinux labels.
>>
>> The issue shows up when there are multiple (and possibly  
>> incompatible)
>> sets of labels, such as in chroot's, or creating an image for a
>> different
>> installation.
>>
>> One can choose to not install labels condition on whether
>> is_selinux_enabled()
>> consistently and methodically.
>>
>> Perhaps a simpple example to illustrate:
>>
>> 	Should cp(1) always copy security labels or only if  
>> is_selinux_enabled
>> ()?
>>
>> What I'm hearing is "No. cp(1) should copy labels iff
>> is_selinux_senabled() is TRUE."
>
> That's a different issue.  Here we are talking about a recent change  
> to

Yes a different issue, but distribution (and the need for relabeling) !=
the use of the labels, yet applications (like cp(1)) have only  
is_selinux_enabled()
or (as in this report) the (non-)existence of sclable in /proc/mounts
to determine what behavior is "expected".

> setfiles that was preventing it from relabeling filesystems if SELinux
> was disabled (because then no filesystems were reporting the seclabel
> option in /proc/mounts).  As we want setfiles to support relabeling of
> filesystems even if SELinux is disabled, we want to skip the seclabel
> option processing in that case as the kernel won't report seclabel
> information when SELinux is disabled (seclabel means more than just
> "filesystem has an xattr handler").
>
> As far as cp goes, I believe you are correct - it will only preserve
> security contexts if SELinux is enabled, and even then, only if the
> caller specified -a or -c.  And in the -a case, it has to be able to
> gracefully fall back to not preserving the context if not permitted by
> policy, as not all callers will be able to do so for the security
> context even if they can do so for the DAC attributes.
>

I'd suggest changing cp(1) to always copy security.* xattr's if found,
overriding from CLI options when present.

But choosing a default behavior that is acceptable to everyone is a  
difficult
problem. There's no right or wrong if cp(1) copies security.* xattr's  
(or not),
only defacto expectations.

But please s/cp(1)/rpm(8)/ and consider what RPM should do if/when  
installing
modular policy in a chroot with /proc/selinux unmounted. I nearly  
implemented
	Always install security.* xattr's.
way back when, and (now that modular policy is headed into *.rpm  
packages somehow)
I am again considering what "default" behavior in RPM will lead to the  
fewest
RPM bug reports. I'm very likely to add a configurable policy install  
mode that achieves
	Always copy security.* xattr's when replacing a file.
with an appropriately automated conflict resolution when matchpathcon()
and *.pp (either from *.rpm packages or not) and what is currently  
present on
the file system all have differnt and incompatible security.* xattr's  
attached
to the path.

A "best effort" deterministic automation leads to fewer bug reports  
imho, ymmv.

And SELinux tools still relabel which can/will impose whatever labels  
you
want everywhere any time you choose. A tad costly, but known to work and
cannot be avoided. Yet.

73 de Jeff

--
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Stephen Smalley]

On Wed, 2009-09-16 at 13:21 -0400, Jeff Johnson wrote:
> I'd suggest changing cp(1) to always copy security.* xattr's if found,
> overriding from CLI options when present.
> 
> But choosing a default behavior that is acceptable to everyone is a  
> difficult
> problem. There's no right or wrong if cp(1) copies security.* xattr's  
> (or not),
> only defacto expectations.

No, it would actually be wrong in the common case.  It isn't so
different from the situation wrt uids - cp(1) does not preserve the uid
of the original file by default but rather lets the file gets created in
accordance with the creating process' attributes, and often the caller
does not have the necessary permissions to force preservation even if it
wanted to do so (even more so with the SELinux attributes).

> But please s/cp(1)/rpm(8)/ and consider what RPM should do if/when  
> installing
> modular policy in a chroot with /proc/selinux unmounted. I nearly  
> implemented
> 	Always install security.* xattr's.
> way back when, and (now that modular policy is headed into *.rpm  
> packages somehow)

If you can instead just arrange for proc to always be mounted, then we
can in fact probe for selinux enabled/disabled.  We don't need selinuxfs
to be mounted for that.

> I am again considering what "default" behavior in RPM will lead to the  
> fewest
> RPM bug reports. I'm very likely to add a configurable policy install  
> mode that achieves
> 	Always copy security.* xattr's when replacing a file.
> with an appropriately automated conflict resolution when matchpathcon()
> and *.pp (either from *.rpm packages or not) and what is currently  
> present on
> the file system all have differnt and incompatible security.* xattr's  
> attached
> to the path.
> 
> A "best effort" deterministic automation leads to fewer bug reports  
> imho, ymmv.

-- 
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: [PATCH] setfiles fails to relabel if selinux not enabled

[Joshua Brindle]

Caleb Case wrote:
> Setfiles now checks the capabilities on the mounted file systems for
> 'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts) on
> newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
> feature is not available if selinux is not enabled. The result is that
> setfiles silently fails to relabel any filesystems.
>
> The patch below removes the check for seclabel if selinux is disabled.
>
> As an alternative maybe seclabel should be available even if selinux is
> disabled? It seems that whether a fs supports security labels is
> independent of selinux being enabled.
> ---
>   policycoreutils/setfiles/setfiles.c |    2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/policycoreutils/setfiles/setfiles.c b/policycoreutils/setfiles/setfiles.c
> index 313767a..db2857f 100644
> --- a/policycoreutils/setfiles/setfiles.c
> +++ b/policycoreutils/setfiles/setfiles.c
> @@ -750,6 +750,8 @@ static void exclude_non_seclabel_mounts()
>   	/* Check to see if the kernel supports seclabel */
>   	if (uname(&uts) == 0&&  strverscmp(uts.release, "2.6.30")<  0)
>   		return;
> +	if (is_selinux_enabled()<= 0)
> +		return;
>
>   	fp = fopen("/proc/mounts", "r");
>   	if (!fp)


Merged in policycoreutils 2.0.74

--
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.