Fixfiles using new setfiles/restorecon simplification

Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

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



[-- Attachment #2: fixfiles.patch --]
[-- Type: text/plain, Size: 2298 bytes --]

diff --git a/policycoreutils/scripts/fixfiles b/policycoreutils/scripts/fixfiles
index ae519fc..135835f 100755
--- a/policycoreutils/scripts/fixfiles
+++ b/policycoreutils/scripts/fixfiles
@@ -35,8 +35,8 @@ SYSLOGFLAG="-l"
 LOGGER=/usr/sbin/logger
 SETFILES=/sbin/setfiles
 RESTORECON=/sbin/restorecon
-FILESYSTEMSRW=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[234]| ext4dev | gfs2 | xfs | jfs | btrfs ).*\(rw/{print $3}';`
-FILESYSTEMSRO=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[234]| ext4dev | gfs2 | xfs | jfs | btrfs ).*\(ro/{print $3}';`
+FILESYSTEMSRW=`grep rw,seclabel /proc/self/mounts | awk '{ print $2 }'`
+FILESYSTEMSRO=`grep -v 'rw\|seclabel' /proc/self/mounts | awk '{ print $2 }'`
 FILESYSTEMS="$FILESYSTEMSRW $FILESYSTEMSRO"
 SELINUXTYPE="targeted"
 if [ -e /etc/selinux/config ]; then
@@ -87,11 +87,7 @@ if [ -f ${PREFC} -a -x /usr/bin/diff ]; then
                   esac; \
                fi; \
             done | \
-	while read pattern ; do sh -c "find $pattern \
-		      ! \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstype ext4dev  -o -fstype gfs2 -o -fstype jfs -o -fstype xfs -o -fstype btrfs \) -prune  -o \
-		      \( -wholename /home -o -wholename /root -o -wholename /tmp -wholename /dev \) -prune -o -print0"; \
-		      done 2> /dev/null | \
-	 ${RESTORECON} $* -0 -f - 
+		      ${RESTORECON} -f - -R -p  -e /home -e /tmp -r /dev; \
 	rm -f ${TEMPFILE} ${PREFCTEMPFILE}
 fi
 }
@@ -126,13 +122,7 @@ if [ ! -z "$RPMFILES" ]; then
     exit $?
 fi
 if [ ! -z "$FILEPATH" ]; then
-    if [ -x /usr/bin/find ]; then
-	/usr/bin/find "$FILEPATH" \
-	    ! \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstype ext4dev -o -fstype gfs2 -o -fstype jfs -o -fstype xfs -o -fstype btrfs \) -prune  -o -print0 | \
-	    ${RESTORECON} ${FORCEFLAG} $* -0 -f - 2>&1 >> $LOGFILE
-    else
-	${RESTORECON} ${FORCEFLAG} -R $* $FILEPATH 2>&1 >> $LOGFILE
-    fi
+    ${RESTORECON} ${FORCEFLAG} -R $* $FILEPATH 2>&1 >> $LOGFILE
     return
 fi
 [ -x /usr/sbin/genhomedircon ] && /usr/sbin/genhomedircon
@@ -146,7 +136,7 @@ exit $?
 
 fullrelabel() {
     logit "Cleaning out /tmp"
-    find /tmp/ -mindepth 1 -print0 | xargs -0 /bin/rm -f
+    find /tmp/ -mindepth 1 -delete
     LogReadOnly
     restore
 }

Re: Fixfiles using new setfiles/restorecon simplification

[Joshua Brindle]

What version of the kernel was this added in? I don't want to completely 
break old kernels using new toolchains (CLIP backports toolchains to 
RHEL 4 and 5). It would be better to use seclabel if it is there, 
otherwise fall back to the old list.

--
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Thu, 2010-02-25 at 20:41 -0500, Joshua Brindle wrote:
> What version of the kernel was this added in? I don't want to completely 
> break old kernels using new toolchains (CLIP backports toolchains to 
> RHEL 4 and 5). It would be better to use seclabel if it is there, 
> otherwise fall back to the old list.

setfiles internally checks for >= 2.6.30 and will only exclude
non-seclabel mounts in that case.

With the newer setfiles + kernel >= 2.6.30, you can actually relabel all
filesystems just by running restorecon -R / and letting it auto-exclude
filesystems that do not support labeling rather than needing to
enumerate the mount points for labeled filesystems to setfiles.  So
maybe fixfiles should just do that if the kernel >= 2.6.30.

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

On 02/25/2010 08:41 PM, Joshua Brindle wrote:
>
> What version of the kernel was this added in? I don't want to 
> completely break old kernels using new toolchains (CLIP backports 
> toolchains to RHEL 4 and 5). It would be better to use seclabel if it 
> is there, otherwise fall back to the old list.
>
> -- 
> 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.
The problem with this is we end up with a lot of cruft in the toolchain, 
that is continually out of data, and makes it hard to figure out what 
the script is doing.  We have older versions of the tool chain for those 
platforms, shouldn't we have sort of the latest toolchain.

--
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
> >
> > What version of the kernel was this added in? I don't want to 
> > completely break old kernels using new toolchains (CLIP backports 
> > toolchains to RHEL 4 and 5). It would be better to use seclabel if it 
> > is there, otherwise fall back to the old list.
> >
> > -- 
> > 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.
> The problem with this is we end up with a lot of cruft in the toolchain, 
> that is continually out of data, and makes it hard to figure out what 
> the script is doing.  We have older versions of the tool chain for those 
> platforms, shouldn't we have sort of the latest toolchain.

If we do that, we ought to make a major bump in the version numbers,
e.g. finally go to 2.1 or 3.0 or something, and make sure the release
announcement clearly marks it as not backward compatible.

With regard to fixfiles simplification though, can't we eliminate the
need to define or use FILESYSTEMS* altogether in the script by switching
all uses of setfiles to restorecon -R /, since that will automatically
skip non-labeled filesystems on kernels >= 2.6.30?

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

On 02/26/2010 09:10 AM, Stephen Smalley wrote:
> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
>    
>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
>>      
>>> What version of the kernel was this added in? I don't want to
>>> completely break old kernels using new toolchains (CLIP backports
>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
>>> is there, otherwise fall back to the old list.
>>>
>>> -- 
>>> 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.
>>>        
>> The problem with this is we end up with a lot of cruft in the toolchain,
>> that is continually out of data, and makes it hard to figure out what
>> the script is doing.  We have older versions of the tool chain for those
>> platforms, shouldn't we have sort of the latest toolchain.
>>      
> If we do that, we ought to make a major bump in the version numbers,
> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
> announcement clearly marks it as not backward compatible.
>
> With regard to fixfiles simplification though, can't we eliminate the
> need to define or use FILESYSTEMS* altogether in the script by switching
> all uses of setfiles to restorecon -R /, since that will automatically
> skip non-labeled filesystems on kernels>= 2.6.30?
>
>    
It will still walk on read/only file systems.

--
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
> > On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
> >    
> >> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
> >>      
> >>> What version of the kernel was this added in? I don't want to
> >>> completely break old kernels using new toolchains (CLIP backports
> >>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
> >>> is there, otherwise fall back to the old list.
> >>>
> >>> -- 
> >>> 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.
> >>>        
> >> The problem with this is we end up with a lot of cruft in the toolchain,
> >> that is continually out of data, and makes it hard to figure out what
> >> the script is doing.  We have older versions of the tool chain for those
> >> platforms, shouldn't we have sort of the latest toolchain.
> >>      
> > If we do that, we ought to make a major bump in the version numbers,
> > e.g. finally go to 2.1 or 3.0 or something, and make sure the release
> > announcement clearly marks it as not backward compatible.
> >
> > With regard to fixfiles simplification though, can't we eliminate the
> > need to define or use FILESYSTEMS* altogether in the script by switching
> > all uses of setfiles to restorecon -R /, since that will automatically
> > skip non-labeled filesystems on kernels>= 2.6.30?
> >
> >    
> It will still walk on read/only file systems.

That should be fairly easy to fix in setfiles given that we are already
reading /proc/mounts - we can just add exclude on any ro mounts.

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

Problems with the new fixfiles logic even with kernels >= 2.6.30:

- Bind mounts are not excluded (and note that they aren't marked with
bind as an option in /proc/mounts - only in /etc/mtab aka mount output):
# mkdir /foo
# mount -o bind /etc /foo
# grep /foo /proc/mounts
/dev/root /foo ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
# grep /foo /etc/mtab
/etc /foo none rw,bind 0 0

- You are assuming fixed option ordering and that no other options can
appear between "rw" and "seclabel" in your grep pattern for
FILESYSTEMSRW.  As a trivial counterexample, if the user mounts with a
rootcontext= option (override the root directory context, but allow
setting of individual file contexts), it won't match.  If we can assume
that seclabel always follows rw, then you can use grep
'rw,.*seclabel' /proc/self/mounts.  If they used a regular context=
mount option, then seclabel won't be displayed so that will get
excluded.

- The definition for FILESYSTEMSRO appears to be wrong.  I think
possibly you want grep 'ro,.*seclabel' there (i.e. filesystems mounted
read-only that support labeling).  Simple test case:
# mount -o remount,ro /boot
# grep 'ro,.*seclabel' /proc/mounts 
/dev/sda1 /boot ext3
ro,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

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

On 02/26/2010 09:36 AM, Stephen Smalley wrote:
> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
>    
>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
>>      
>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
>>>
>>>        
>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
>>>>
>>>>          
>>>>> What version of the kernel was this added in? I don't want to
>>>>> completely break old kernels using new toolchains (CLIP backports
>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
>>>>> is there, otherwise fall back to the old list.
>>>>>
>>>>> -- 
>>>>> 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.
>>>>>
>>>>>            
>>>> The problem with this is we end up with a lot of cruft in the toolchain,
>>>> that is continually out of data, and makes it hard to figure out what
>>>> the script is doing.  We have older versions of the tool chain for those
>>>> platforms, shouldn't we have sort of the latest toolchain.
>>>>
>>>>          
>>> If we do that, we ought to make a major bump in the version numbers,
>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
>>> announcement clearly marks it as not backward compatible.
>>>
>>> With regard to fixfiles simplification though, can't we eliminate the
>>> need to define or use FILESYSTEMS* altogether in the script by switching
>>> all uses of setfiles to restorecon -R /, since that will automatically
>>> skip non-labeled filesystems on kernels>= 2.6.30?
>>>
>>>
>>>        
>> It will still walk on read/only file systems.
>>      
> That should be fairly easy to fix in setfiles given that we are already
> reading /proc/mounts - we can just add exclude on any ro mounts.
>
>    
How about this patch to remove ro mount points from setfiles/restorecon


[-- Attachment #2: policycoreutils-romounts.patch --]
[-- Type: text/plain, Size: 692 bytes --]

diff --git a/policycoreutils/setfiles/setfiles.c b/policycoreutils/setfiles/setfiles.c
index 8f4f663..27d52b1 100644
--- a/policycoreutils/setfiles/setfiles.c
+++ b/policycoreutils/setfiles/setfiles.c
@@ -186,14 +186,17 @@ static void exclude_non_seclabel_mounts()
 
 		item = strtok(mount_info[3], ",");
 		while (item != NULL) {
+			if (strcmp(item, "ro") == 0) {
+				found = 0;
+				break;
+			}
 			if (strcmp(item, "seclabel") == 0) {
 				found = 1;
-				break;
 			}
 			item = strtok(NULL, ",");
 		}
 
-		/* exclude mount points without the seclabel option */
+		/* exclude ro mount points and those without the seclabel option */
 		if (!found)
 			add_exclude(mount_info[1]);
 	}

Re: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

On 02/26/2010 12:56 PM, Stephen Smalley wrote:
> Problems with the new fixfiles logic even with kernels>= 2.6.30:
>
> - Bind mounts are not excluded (and note that they aren't marked with
> bind as an option in /proc/mounts - only in /etc/mtab aka mount output):
> # mkdir /foo
> # mount -o bind /etc /foo
> # grep /foo /proc/mounts
> /dev/root /foo ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
> # grep /foo /etc/mtab
> /etc /foo none rw,bind 0 0
>
> - You are assuming fixed option ordering and that no other options can
> appear between "rw" and "seclabel" in your grep pattern for
> FILESYSTEMSRW.  As a trivial counterexample, if the user mounts with a
> rootcontext= option (override the root directory context, but allow
> setting of individual file contexts), it won't match.  If we can assume
> that seclabel always follows rw, then you can use grep
> 'rw,.*seclabel' /proc/self/mounts.  If they used a regular context=
> mount option, then seclabel won't be displayed so that will get
> excluded.
>
> - The definition for FILESYSTEMSRO appears to be wrong.  I think
> possibly you want grep 'ro,.*seclabel' there (i.e. filesystems mounted
> read-only that support labeling).  Simple test case:
> # mount -o remount,ro /boot
> # grep 'ro,.*seclabel' /proc/mounts
> /dev/sda1 /boot ext3
> ro,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
>
>    
I think we just want to remove this and go with the

restorecon -R /

With the ro fix, I just sent.

The problem with this is if you have a seclabel file system mounted on a 
non seclabel file system, it will not get labeled.  But trying to figure 
out whether a file system is seclabel or not along with figuring out 
bind mounts is not going to be easy.  The way we have it now I think 
will cause multiple passes.



--
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

On 02/26/2010 12:56 PM, Stephen Smalley wrote:
> Problems with the new fixfiles logic even with kernels>= 2.6.30:
>
> - Bind mounts are not excluded (and note that they aren't marked with
> bind as an option in /proc/mounts - only in /etc/mtab aka mount output):
> # mkdir /foo
> # mount -o bind /etc /foo
> # grep /foo /proc/mounts
> /dev/root /foo ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
> # grep /foo /etc/mtab
> /etc /foo none rw,bind 0 0
>
> - You are assuming fixed option ordering and that no other options can
> appear between "rw" and "seclabel" in your grep pattern for
> FILESYSTEMSRW.  As a trivial counterexample, if the user mounts with a
> rootcontext= option (override the root directory context, but allow
> setting of individual file contexts), it won't match.  If we can assume
> that seclabel always follows rw, then you can use grep
> 'rw,.*seclabel' /proc/self/mounts.  If they used a regular context=
> mount option, then seclabel won't be displayed so that will get
> excluded.
>
> - The definition for FILESYSTEMSRO appears to be wrong.  I think
> possibly you want grep 'ro,.*seclabel' there (i.e. filesystems mounted
> read-only that support labeling).  Simple test case:
> # mount -o remount,ro /boot
> # grep 'ro,.*seclabel' /proc/mounts
> /dev/sda1 /boot ext3
> ro,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
>
>    


How about this script,  It searches mount eliminating context and bind 
mounts and then
searches /proc/self/mounts for seclabel.

get_mounts() {
FS=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk 
'/rw/{print $3}';`
for i in $FS; do
     grep --silent "$i ".*seclabel /proc/self/mounts && echo $i
done
}
FILESYSTEMRW=`get_mounts`
echo $FILESYSTEMRW



--
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
> > On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
> >    
> >> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
> >>      
> >>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
> >>>
> >>>        
> >>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
> >>>>
> >>>>          
> >>>>> What version of the kernel was this added in? I don't want to
> >>>>> completely break old kernels using new toolchains (CLIP backports
> >>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
> >>>>> is there, otherwise fall back to the old list.
> >>>>>
> >>>>> -- 
> >>>>> 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.
> >>>>>
> >>>>>            
> >>>> The problem with this is we end up with a lot of cruft in the toolchain,
> >>>> that is continually out of data, and makes it hard to figure out what
> >>>> the script is doing.  We have older versions of the tool chain for those
> >>>> platforms, shouldn't we have sort of the latest toolchain.
> >>>>
> >>>>          
> >>> If we do that, we ought to make a major bump in the version numbers,
> >>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
> >>> announcement clearly marks it as not backward compatible.
> >>>
> >>> With regard to fixfiles simplification though, can't we eliminate the
> >>> need to define or use FILESYSTEMS* altogether in the script by switching
> >>> all uses of setfiles to restorecon -R /, since that will automatically
> >>> skip non-labeled filesystems on kernels>= 2.6.30?
> >>>
> >>>
> >>>        
> >> It will still walk on read/only file systems.
> >>      
> > That should be fairly easy to fix in setfiles given that we are already
> > reading /proc/mounts - we can just add exclude on any ro mounts.
> >
> >    
> How about this patch to remove ro mount points from setfiles/restorecon

Your logic depends on the option order - if "seclabel" appears first,
then you'll break out of the loop and never see the "ro".  If we are ok
with that assumption (which happens to be true at present,
but /proc/mounts format is not guaranteed to remain stable), then it is
ok but then there is no reason to set found to 0 (already initialized to
0).  If we want to be robust against ordering changes, we'd need to drop
the break; from the seclabel case and keep scanning to check for any
subsequent "ro" options.  Or you could just use strstr() on the entire
mount_info[3] and not worry about splitting it into tokens.

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

On 02/26/2010 03:16 PM, Stephen Smalley wrote:
> On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
>    
>> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
>>      
>>> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
>>>
>>>        
>>>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
>>>>
>>>>          
>>>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> What version of the kernel was this added in? I don't want to
>>>>>>> completely break old kernels using new toolchains (CLIP backports
>>>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
>>>>>>> is there, otherwise fall back to the old list.
>>>>>>>
>>>>>>> -- 
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> The problem with this is we end up with a lot of cruft in the toolchain,
>>>>>> that is continually out of data, and makes it hard to figure out what
>>>>>> the script is doing.  We have older versions of the tool chain for those
>>>>>> platforms, shouldn't we have sort of the latest toolchain.
>>>>>>
>>>>>>
>>>>>>              
>>>>> If we do that, we ought to make a major bump in the version numbers,
>>>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
>>>>> announcement clearly marks it as not backward compatible.
>>>>>
>>>>> With regard to fixfiles simplification though, can't we eliminate the
>>>>> need to define or use FILESYSTEMS* altogether in the script by switching
>>>>> all uses of setfiles to restorecon -R /, since that will automatically
>>>>> skip non-labeled filesystems on kernels>= 2.6.30?
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> It will still walk on read/only file systems.
>>>>
>>>>          
>>> That should be fairly easy to fix in setfiles given that we are already
>>> reading /proc/mounts - we can just add exclude on any ro mounts.
>>>
>>>
>>>        
>> How about this patch to remove ro mount points from setfiles/restorecon
>>      
> Your logic depends on the option order - if "seclabel" appears first,
> then you'll break out of the loop and never see the "ro".  If we are ok
> with that assumption (which happens to be true at present,
> but /proc/mounts format is not guaranteed to remain stable), then it is
> ok but then there is no reason to set found to 0 (already initialized to
> 0).  If we want to be robust against ordering changes, we'd need to drop
> the break; from the seclabel case and keep scanning to check for any
> subsequent "ro" options.  Or you could just use strstr() on the entire
> mount_info[3] and not worry about splitting it into tokens.
>
>    
No I removed the break after finding seclabel, and set found to 0 if ro 
is found.

So it will either search the entire structure for seclabel or break out 
with ro.


+            if (strcmp(item, "ro") == 0) {
+                found = 0;
+                break;
+            }
              if (strcmp(item, "seclabel") == 0) {
                  found = 1;
-                break;
              }


--
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Fri, 2010-02-26 at 15:25 -0500, Daniel J Walsh wrote:
> On 02/26/2010 03:16 PM, Stephen Smalley wrote:
> > On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
> >    
> >> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
> >>      
> >>> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
> >>>
> >>>        
> >>>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
> >>>>
> >>>>          
> >>>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
> >>>>>
> >>>>>
> >>>>>            
> >>>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>>>> What version of the kernel was this added in? I don't want to
> >>>>>>> completely break old kernels using new toolchains (CLIP backports
> >>>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
> >>>>>>> is there, otherwise fall back to the old list.
> >>>>>>>
> >>>>>>> -- 
> >>>>>>> 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.
> >>>>>>>
> >>>>>>>
> >>>>>>>                
> >>>>>> The problem with this is we end up with a lot of cruft in the toolchain,
> >>>>>> that is continually out of data, and makes it hard to figure out what
> >>>>>> the script is doing.  We have older versions of the tool chain for those
> >>>>>> platforms, shouldn't we have sort of the latest toolchain.
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>> If we do that, we ought to make a major bump in the version numbers,
> >>>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
> >>>>> announcement clearly marks it as not backward compatible.
> >>>>>
> >>>>> With regard to fixfiles simplification though, can't we eliminate the
> >>>>> need to define or use FILESYSTEMS* altogether in the script by switching
> >>>>> all uses of setfiles to restorecon -R /, since that will automatically
> >>>>> skip non-labeled filesystems on kernels>= 2.6.30?
> >>>>>
> >>>>>
> >>>>>
> >>>>>            
> >>>> It will still walk on read/only file systems.
> >>>>
> >>>>          
> >>> That should be fairly easy to fix in setfiles given that we are already
> >>> reading /proc/mounts - we can just add exclude on any ro mounts.
> >>>
> >>>
> >>>        
> >> How about this patch to remove ro mount points from setfiles/restorecon
> >>      
> > Your logic depends on the option order - if "seclabel" appears first,
> > then you'll break out of the loop and never see the "ro".  If we are ok
> > with that assumption (which happens to be true at present,
> > but /proc/mounts format is not guaranteed to remain stable), then it is
> > ok but then there is no reason to set found to 0 (already initialized to
> > 0).  If we want to be robust against ordering changes, we'd need to drop
> > the break; from the seclabel case and keep scanning to check for any
> > subsequent "ro" options.  Or you could just use strstr() on the entire
> > mount_info[3] and not worry about splitting it into tokens.
> >
> >    
> No I removed the break after finding seclabel, and set found to 0 if ro 
> is found.
> 
> So it will either search the entire structure for seclabel or break out 
> with ro.
> 
> 
> +            if (strcmp(item, "ro") == 0) {
> +                found = 0;
> +                break;
> +            }
>               if (strcmp(item, "seclabel") == 0) {
>                   found = 1;
> -                break;
>               }

Ok, I'm blind.  Yep, looks ok to me.

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Fri, 2010-02-26 at 15:25 -0500, Daniel J Walsh wrote:
> On 02/26/2010 03:16 PM, Stephen Smalley wrote:
> > On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
> >    
> >> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
> >>      
> >>> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
> >>>
> >>>        
> >>>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
> >>>>
> >>>>          
> >>>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
> >>>>>
> >>>>>
> >>>>>            
> >>>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>>>> What version of the kernel was this added in? I don't want to
> >>>>>>> completely break old kernels using new toolchains (CLIP backports
> >>>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
> >>>>>>> is there, otherwise fall back to the old list.
> >>>>>>>
> >>>>>>> -- 
> >>>>>>> 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.
> >>>>>>>
> >>>>>>>
> >>>>>>>                
> >>>>>> The problem with this is we end up with a lot of cruft in the toolchain,
> >>>>>> that is continually out of data, and makes it hard to figure out what
> >>>>>> the script is doing.  We have older versions of the tool chain for those
> >>>>>> platforms, shouldn't we have sort of the latest toolchain.
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>> If we do that, we ought to make a major bump in the version numbers,
> >>>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
> >>>>> announcement clearly marks it as not backward compatible.
> >>>>>
> >>>>> With regard to fixfiles simplification though, can't we eliminate the
> >>>>> need to define or use FILESYSTEMS* altogether in the script by switching
> >>>>> all uses of setfiles to restorecon -R /, since that will automatically
> >>>>> skip non-labeled filesystems on kernels>= 2.6.30?
> >>>>>
> >>>>>
> >>>>>
> >>>>>            
> >>>> It will still walk on read/only file systems.
> >>>>
> >>>>          
> >>> That should be fairly easy to fix in setfiles given that we are already
> >>> reading /proc/mounts - we can just add exclude on any ro mounts.
> >>>
> >>>
> >>>        
> >> How about this patch to remove ro mount points from setfiles/restorecon
> >>      
> > Your logic depends on the option order - if "seclabel" appears first,
> > then you'll break out of the loop and never see the "ro".  If we are ok
> > with that assumption (which happens to be true at present,
> > but /proc/mounts format is not guaranteed to remain stable), then it is
> > ok but then there is no reason to set found to 0 (already initialized to
> > 0).  If we want to be robust against ordering changes, we'd need to drop
> > the break; from the seclabel case and keep scanning to check for any
> > subsequent "ro" options.  Or you could just use strstr() on the entire
> > mount_info[3] and not worry about splitting it into tokens.
> >
> >    
> No I removed the break after finding seclabel, and set found to 0 if ro 
> is found.
> 
> So it will either search the entire structure for seclabel or break out 
> with ro.
> 
> 
> +            if (strcmp(item, "ro") == 0) {
> +                found = 0;
> +                break;
> +            }
>               if (strcmp(item, "seclabel") == 0) {
>                   found = 1;
> -                break;
>               }
> 

Actually, given your other comment, I guess we can't do it this way, as
if they have e.g. read-only root with writable mounts underneath, we'll
never reach them.

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Fri, 2010-02-26 at 13:59 -0500, Daniel J Walsh wrote:
> On 02/26/2010 12:56 PM, Stephen Smalley wrote:
> > Problems with the new fixfiles logic even with kernels>= 2.6.30:
> >
> > - Bind mounts are not excluded (and note that they aren't marked with
> > bind as an option in /proc/mounts - only in /etc/mtab aka mount output):
> > # mkdir /foo
> > # mount -o bind /etc /foo
> > # grep /foo /proc/mounts
> > /dev/root /foo ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
> > # grep /foo /etc/mtab
> > /etc /foo none rw,bind 0 0
> >
> > - You are assuming fixed option ordering and that no other options can
> > appear between "rw" and "seclabel" in your grep pattern for
> > FILESYSTEMSRW.  As a trivial counterexample, if the user mounts with a
> > rootcontext= option (override the root directory context, but allow
> > setting of individual file contexts), it won't match.  If we can assume
> > that seclabel always follows rw, then you can use grep
> > 'rw,.*seclabel' /proc/self/mounts.  If they used a regular context=
> > mount option, then seclabel won't be displayed so that will get
> > excluded.
> >
> > - The definition for FILESYSTEMSRO appears to be wrong.  I think
> > possibly you want grep 'ro,.*seclabel' there (i.e. filesystems mounted
> > read-only that support labeling).  Simple test case:
> > # mount -o remount,ro /boot
> > # grep 'ro,.*seclabel' /proc/mounts
> > /dev/sda1 /boot ext3
> > ro,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
> >
> >    
> 
> 
> How about this script,  It searches mount eliminating context and bind 
> mounts and then
> searches /proc/self/mounts for seclabel.
> 
> get_mounts() {
> FS=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk 
> '/rw/{print $3}';`

You can drop the grep -v "context=" if you are relying on seclabel
in /proc/mounts, as it won't appear if they used a "context=" mount
(disables setting of security contexts).  Whereas if they used a
rootcontext= or defcontext= mount just to initialize the root directory
context (as with /dev in some distributions and /dev/shm) or to define
the default context if the file lacks an xattr on disk, you still want
to relabel, so excluding anything with context= would exclude too much.
That's a bug in the current fixfiles.

Also, in the old fixfiles, you used \(rw rather than just rw in the
pattern so that you would only match on the mount option, not on any
occurrence of rw in e.g. the name of the device or the directory or the
filesystem type.

Interestingly /dev doesn't appear in mount output aka /etc/mtab but it
does in /proc/self/mounts.  So at present this won't relabel /dev.

> for i in $FS; do
>      grep --silent "$i ".*seclabel /proc/self/mounts && echo $i
> done
> }
> FILESYSTEMRW=`get_mounts`
> echo $FILESYSTEMRW

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

On 02/26/2010 03:47 PM, Stephen Smalley wrote:
> On Fri, 2010-02-26 at 15:25 -0500, Daniel J Walsh wrote:
>    
>> On 02/26/2010 03:16 PM, Stephen Smalley wrote:
>>      
>>> On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
>>>
>>>        
>>>> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
>>>>
>>>>          
>>>>> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> What version of the kernel was this added in? I don't want to
>>>>>>>>> completely break old kernels using new toolchains (CLIP backports
>>>>>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
>>>>>>>>> is there, otherwise fall back to the old list.
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> The problem with this is we end up with a lot of cruft in the toolchain,
>>>>>>>> that is continually out of data, and makes it hard to figure out what
>>>>>>>> the script is doing.  We have older versions of the tool chain for those
>>>>>>>> platforms, shouldn't we have sort of the latest toolchain.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>> If we do that, we ought to make a major bump in the version numbers,
>>>>>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
>>>>>>> announcement clearly marks it as not backward compatible.
>>>>>>>
>>>>>>> With regard to fixfiles simplification though, can't we eliminate the
>>>>>>> need to define or use FILESYSTEMS* altogether in the script by switching
>>>>>>> all uses of setfiles to restorecon -R /, since that will automatically
>>>>>>> skip non-labeled filesystems on kernels>= 2.6.30?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> It will still walk on read/only file systems.
>>>>>>
>>>>>>
>>>>>>              
>>>>> That should be fairly easy to fix in setfiles given that we are already
>>>>> reading /proc/mounts - we can just add exclude on any ro mounts.
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> How about this patch to remove ro mount points from setfiles/restorecon
>>>>
>>>>          
>>> Your logic depends on the option order - if "seclabel" appears first,
>>> then you'll break out of the loop and never see the "ro".  If we are ok
>>> with that assumption (which happens to be true at present,
>>> but /proc/mounts format is not guaranteed to remain stable), then it is
>>> ok but then there is no reason to set found to 0 (already initialized to
>>> 0).  If we want to be robust against ordering changes, we'd need to drop
>>> the break; from the seclabel case and keep scanning to check for any
>>> subsequent "ro" options.  Or you could just use strstr() on the entire
>>> mount_info[3] and not worry about splitting it into tokens.
>>>
>>>
>>>        
>> No I removed the break after finding seclabel, and set found to 0 if ro
>> is found.
>>
>> So it will either search the entire structure for seclabel or break out
>> with ro.
>>
>>
>> +            if (strcmp(item, "ro") == 0) {
>> +                found = 0;
>> +                break;
>> +            }
>>                if (strcmp(item, "seclabel") == 0) {
>>                    found = 1;
>> -                break;
>>                }
>>
>>      
> Actually, given your other comment, I guess we can't do it this way, as
> if they have e.g. read-only root with writable mounts underneath, we'll
> never reach them.
>
>    
We have that problem with or without this patch.  Since no seclabel is 
the same problem.


--
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: Fixfiles using new setfiles/restorecon simplification

[Stephen Smalley]

On Fri, 2010-02-26 at 15:52 -0500, Daniel J Walsh wrote:
> On 02/26/2010 03:47 PM, Stephen Smalley wrote:
> > On Fri, 2010-02-26 at 15:25 -0500, Daniel J Walsh wrote:
> >    
> >> On 02/26/2010 03:16 PM, Stephen Smalley wrote:
> >>      
> >>> On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
> >>>
> >>>        
> >>>> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
> >>>>
> >>>>          
> >>>>> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
> >>>>>
> >>>>>
> >>>>>            
> >>>>>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                
> >>>>>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>                  
> >>>>>>>>> What version of the kernel was this added in? I don't want to
> >>>>>>>>> completely break old kernels using new toolchains (CLIP backports
> >>>>>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
> >>>>>>>>> is there, otherwise fall back to the old list.
> >>>>>>>>>
> >>>>>>>>> -- 
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>                    
> >>>>>>>> The problem with this is we end up with a lot of cruft in the toolchain,
> >>>>>>>> that is continually out of data, and makes it hard to figure out what
> >>>>>>>> the script is doing.  We have older versions of the tool chain for those
> >>>>>>>> platforms, shouldn't we have sort of the latest toolchain.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>                  
> >>>>>>> If we do that, we ought to make a major bump in the version numbers,
> >>>>>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
> >>>>>>> announcement clearly marks it as not backward compatible.
> >>>>>>>
> >>>>>>> With regard to fixfiles simplification though, can't we eliminate the
> >>>>>>> need to define or use FILESYSTEMS* altogether in the script by switching
> >>>>>>> all uses of setfiles to restorecon -R /, since that will automatically
> >>>>>>> skip non-labeled filesystems on kernels>= 2.6.30?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                
> >>>>>> It will still walk on read/only file systems.
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>> That should be fairly easy to fix in setfiles given that we are already
> >>>>> reading /proc/mounts - we can just add exclude on any ro mounts.
> >>>>>
> >>>>>
> >>>>>
> >>>>>            
> >>>> How about this patch to remove ro mount points from setfiles/restorecon
> >>>>
> >>>>          
> >>> Your logic depends on the option order - if "seclabel" appears first,
> >>> then you'll break out of the loop and never see the "ro".  If we are ok
> >>> with that assumption (which happens to be true at present,
> >>> but /proc/mounts format is not guaranteed to remain stable), then it is
> >>> ok but then there is no reason to set found to 0 (already initialized to
> >>> 0).  If we want to be robust against ordering changes, we'd need to drop
> >>> the break; from the seclabel case and keep scanning to check for any
> >>> subsequent "ro" options.  Or you could just use strstr() on the entire
> >>> mount_info[3] and not worry about splitting it into tokens.
> >>>
> >>>
> >>>        
> >> No I removed the break after finding seclabel, and set found to 0 if ro
> >> is found.
> >>
> >> So it will either search the entire structure for seclabel or break out
> >> with ro.
> >>
> >>
> >> +            if (strcmp(item, "ro") == 0) {
> >> +                found = 0;
> >> +                break;
> >> +            }
> >>                if (strcmp(item, "seclabel") == 0) {
> >>                    found = 1;
> >> -                break;
> >>                }
> >>
> >>      
> > Actually, given your other comment, I guess we can't do it this way, as
> > if they have e.g. read-only root with writable mounts underneath, we'll
> > never reach them.
> >
> >    
> We have that problem with or without this patch.  Since no seclabel is 
> the same problem.

It isn't quite the same though.  If someone were using SELinux, then I'd
expect their root filesystem to support labeling (otherwise init and
friends won't transition).  But they might very well go with a read-only
root after installation.

-- 
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

On 02/26/2010 03:57 PM, Stephen Smalley wrote:
> On Fri, 2010-02-26 at 15:52 -0500, Daniel J Walsh wrote:
>    
>> On 02/26/2010 03:47 PM, Stephen Smalley wrote:
>>      
>>> On Fri, 2010-02-26 at 15:25 -0500, Daniel J Walsh wrote:
>>>
>>>        
>>>> On 02/26/2010 03:16 PM, Stephen Smalley wrote:
>>>>
>>>>          
>>>>> On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                      
>>>>>>>>>>> What version of the kernel was this added in? I don't want to
>>>>>>>>>>> completely break old kernels using new toolchains (CLIP backports
>>>>>>>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
>>>>>>>>>>> is there, otherwise fall back to the old list.
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                        
>>>>>>>>>> The problem with this is we end up with a lot of cruft in the toolchain,
>>>>>>>>>> that is continually out of data, and makes it hard to figure out what
>>>>>>>>>> the script is doing.  We have older versions of the tool chain for those
>>>>>>>>>> platforms, shouldn't we have sort of the latest toolchain.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                      
>>>>>>>>> If we do that, we ought to make a major bump in the version numbers,
>>>>>>>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
>>>>>>>>> announcement clearly marks it as not backward compatible.
>>>>>>>>>
>>>>>>>>> With regard to fixfiles simplification though, can't we eliminate the
>>>>>>>>> need to define or use FILESYSTEMS* altogether in the script by switching
>>>>>>>>> all uses of setfiles to restorecon -R /, since that will automatically
>>>>>>>>> skip non-labeled filesystems on kernels>= 2.6.30?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> It will still walk on read/only file systems.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>> That should be fairly easy to fix in setfiles given that we are already
>>>>>>> reading /proc/mounts - we can just add exclude on any ro mounts.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> How about this patch to remove ro mount points from setfiles/restorecon
>>>>>>
>>>>>>
>>>>>>              
>>>>> Your logic depends on the option order - if "seclabel" appears first,
>>>>> then you'll break out of the loop and never see the "ro".  If we are ok
>>>>> with that assumption (which happens to be true at present,
>>>>> but /proc/mounts format is not guaranteed to remain stable), then it is
>>>>> ok but then there is no reason to set found to 0 (already initialized to
>>>>> 0).  If we want to be robust against ordering changes, we'd need to drop
>>>>> the break; from the seclabel case and keep scanning to check for any
>>>>> subsequent "ro" options.  Or you could just use strstr() on the entire
>>>>> mount_info[3] and not worry about splitting it into tokens.
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> No I removed the break after finding seclabel, and set found to 0 if ro
>>>> is found.
>>>>
>>>> So it will either search the entire structure for seclabel or break out
>>>> with ro.
>>>>
>>>>
>>>> +            if (strcmp(item, "ro") == 0) {
>>>> +                found = 0;
>>>> +                break;
>>>> +            }
>>>>                 if (strcmp(item, "seclabel") == 0) {
>>>>                     found = 1;
>>>> -                break;
>>>>                 }
>>>>
>>>>
>>>>          
>>> Actually, given your other comment, I guess we can't do it this way, as
>>> if they have e.g. read-only root with writable mounts underneath, we'll
>>> never reach them.
>>>
>>>
>>>        
>> We have that problem with or without this patch.  Since no seclabel is
>> the same problem.
>>      
> It isn't quite the same though.  If someone were using SELinux, then I'd
> expect their root filesystem to support labeling (otherwise init and
> friends won't transition).  But they might very well go with a read-only
> root after installation.
>
>    
The latest fixfiles picks the "correct" mounts and does not cross file 
system barriers.

restorecon -R -v /

Would not pick up file systems if any labels are wrong on a dir, because 
it stops traversing if it gets an error anyways.

But I do not have a problem dropping this patch.

I think we need to stay with the setfiles/fixfiles solution for this case.

--
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: Fixfiles using new setfiles/restorecon simplification

[Daniel J Walsh]

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

On 02/26/2010 03:49 PM, Stephen Smalley wrote:
> On Fri, 2010-02-26 at 13:59 -0500, Daniel J Walsh wrote:
>    
>> On 02/26/2010 12:56 PM, Stephen Smalley wrote:
>>      
>>> Problems with the new fixfiles logic even with kernels>= 2.6.30:
>>>
>>> - Bind mounts are not excluded (and note that they aren't marked with
>>> bind as an option in /proc/mounts - only in /etc/mtab aka mount output):
>>> # mkdir /foo
>>> # mount -o bind /etc /foo
>>> # grep /foo /proc/mounts
>>> /dev/root /foo ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
>>> # grep /foo /etc/mtab
>>> /etc /foo none rw,bind 0 0
>>>
>>> - You are assuming fixed option ordering and that no other options can
>>> appear between "rw" and "seclabel" in your grep pattern for
>>> FILESYSTEMSRW.  As a trivial counterexample, if the user mounts with a
>>> rootcontext= option (override the root directory context, but allow
>>> setting of individual file contexts), it won't match.  If we can assume
>>> that seclabel always follows rw, then you can use grep
>>> 'rw,.*seclabel' /proc/self/mounts.  If they used a regular context=
>>> mount option, then seclabel won't be displayed so that will get
>>> excluded.
>>>
>>> - The definition for FILESYSTEMSRO appears to be wrong.  I think
>>> possibly you want grep 'ro,.*seclabel' there (i.e. filesystems mounted
>>> read-only that support labeling).  Simple test case:
>>> # mount -o remount,ro /boot
>>> # grep 'ro,.*seclabel' /proc/mounts
>>> /dev/sda1 /boot ext3
>>> ro,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
>>>
>>>
>>>        
>>
>> How about this script,  It searches mount eliminating context and bind
>> mounts and then
>> searches /proc/self/mounts for seclabel.
>>
>> get_mounts() {
>> FS=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk
>> '/rw/{print $3}';`
>>      
> You can drop the grep -v "context=" if you are relying on seclabel
> in /proc/mounts, as it won't appear if they used a "context=" mount
> (disables setting of security contexts).  Whereas if they used a
> rootcontext= or defcontext= mount just to initialize the root directory
> context (as with /dev in some distributions and /dev/shm) or to define
> the default context if the file lacks an xattr on disk, you still want
> to relabel, so excluding anything with context= would exclude too much.
> That's a bug in the current fixfiles.
>
>    
Dropped
> Also, in the old fixfiles, you used \(rw rather than just rw in the
> pattern so that you would only match on the mount option, not on any
> occurrence of rw in e.g. the name of the device or the directory or the
> filesystem type.
>
>    
Fixed
> Interestingly /dev doesn't appear in mount output aka /etc/mtab but it
> does in /proc/self/mounts.  So at present this won't relabel /dev.
>
>    
Added /dev to list of file context,  Since this is added in 
initrc/dracut, it does not show up in /etc/mtab
>> for i in $FS; do
>>       grep --silent "$i ".*seclabel /proc/self/mounts&&  echo $i
>> done
>> }
>> FILESYSTEMRW=`get_mounts`
>> echo $FILESYSTEMRW
>>      
>    
Updated patch

[-- Attachment #2: fixfiles.patch --]
[-- Type: text/plain, Size: 3359 bytes --]

diff --git a/policycoreutils/scripts/fixfiles b/policycoreutils/scripts/fixfiles
index ae519fc..d694e3c 100755
--- a/policycoreutils/scripts/fixfiles
+++ b/policycoreutils/scripts/fixfiles
@@ -21,6 +21,17 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 
 #
+# Get all mounted rw file systems that support seclabel
+#
+get_labeled_mounts() {
+# /dev is not listed in the mountab
+FS="`mount | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/\(rw/{print $3}';` /dev"
+for i in $FS; do 
+    grep --silent "$i ".*seclabel /proc/self/mounts && echo $i
+done
+}
+
+#
 # Set global Variables
 #
 fullFlag=0
@@ -35,9 +46,7 @@ SYSLOGFLAG="-l"
 LOGGER=/usr/sbin/logger
 SETFILES=/sbin/setfiles
 RESTORECON=/sbin/restorecon
-FILESYSTEMSRW=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[234]| ext4dev | gfs2 | xfs | jfs | btrfs ).*\(rw/{print $3}';`
-FILESYSTEMSRO=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[234]| ext4dev | gfs2 | xfs | jfs | btrfs ).*\(ro/{print $3}';`
-FILESYSTEMS="$FILESYSTEMSRW $FILESYSTEMSRO"
+FILESYSTEMS=`get_labeled_mounts`
 SELINUXTYPE="targeted"
 if [ -e /etc/selinux/config ]; then
     . /etc/selinux/config
@@ -87,23 +96,10 @@ if [ -f ${PREFC} -a -x /usr/bin/diff ]; then
                   esac; \
                fi; \
             done | \
-	while read pattern ; do sh -c "find $pattern \
-		      ! \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstype ext4dev  -o -fstype gfs2 -o -fstype jfs -o -fstype xfs -o -fstype btrfs \) -prune  -o \
-		      \( -wholename /home -o -wholename /root -o -wholename /tmp -wholename /dev \) -prune -o -print0"; \
-		      done 2> /dev/null | \
-	 ${RESTORECON} $* -0 -f - 
+		      ${RESTORECON} -f - -R -p  -e /home -e /tmp -r /dev; \
 	rm -f ${TEMPFILE} ${PREFCTEMPFILE}
 fi
 }
-#
-# Log all Read Only file systems 
-#
-LogReadOnly() {
-if [ ! -z "$FILESYSTEMSRO" ]; then
-    logit "Warning: Skipping the following R/O filesystems:"
-    logit "$FILESYSTEMSRO"
-fi
-}
 
 rpmlist() {
 rpm -q --qf '[%{FILESTATES} %{FILENAMES}\n]' "$1" | grep '^0 ' | cut -f2- -d ' '
@@ -126,18 +122,11 @@ if [ ! -z "$RPMFILES" ]; then
     exit $?
 fi
 if [ ! -z "$FILEPATH" ]; then
-    if [ -x /usr/bin/find ]; then
-	/usr/bin/find "$FILEPATH" \
-	    ! \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstype ext4dev -o -fstype gfs2 -o -fstype jfs -o -fstype xfs -o -fstype btrfs \) -prune  -o -print0 | \
-	    ${RESTORECON} ${FORCEFLAG} $* -0 -f - 2>&1 >> $LOGFILE
-    else
-	${RESTORECON} ${FORCEFLAG} -R $* $FILEPATH 2>&1 >> $LOGFILE
-    fi
+    ${RESTORECON} ${FORCEFLAG} -R $* $FILEPATH 2>&1 >> $LOGFILE
     return
 fi
 [ -x /usr/sbin/genhomedircon ] && /usr/sbin/genhomedircon
-LogReadOnly
-${SETFILES} -q ${SYSLOGFLAG} ${FORCEFLAG} $* ${FC} ${FILESYSTEMSRW} 2>&1 >> $LOGFILE
+${SETFILES} -q ${SYSLOGFLAG} ${FORCEFLAG} $* ${FC} ${FILESYSTEMS} 2>&1 >> $LOGFILE
 rm -rf /tmp/gconfd-* /tmp/pulse-* /tmp/orbit-*
 find /tmp \( -context "*:file_t*" -o -context "*:unlabeled_t*" \) -exec chcon -t tmp_t {} \;
 find /var/tmp \( -context "*:file_t*" -o -context "*:unlabeled_t*" \) -exec chcon -t tmp_t {} \;
@@ -146,8 +135,7 @@ exit $?
 
 fullrelabel() {
     logit "Cleaning out /tmp"
-    find /tmp/ -mindepth 1 -print0 | xargs -0 /bin/rm -f
-    LogReadOnly
+    find /tmp/ -mindepth 1 -delete
     restore
 }