differences between setfiles and restorecon? repeat of old thread?

[Tom London]

Running targeted/enforcing, latest rawhide.

I created a 'backup' of my root lvm2 partition, mounted the new partition as 
/mnt, and copied the files via 'cp -dpR / /mnt'.

The copied files were all incorrectly labeled. (same result with cp 
--preserve=all'). 

I tried 'chroot /mnt; restorcon -v -R /', but it had no effect (returned 
immediately), as did any other resorecon attempted in the chroot'ed shell.

'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did the 
right thing. 

[Its almost as if restorecon is using the 'real' full pathname (with leading 
/mnt), and setfiles is using the 'chroot'ed' pathname (without the leading 
/mnt).]

First, should the 'preserve' on cp have failed to copy the contexts? Second, 
why the difference in behavior between setfiles and restorecon in this 
context?

Still curious,
tom
-- 
Tom London

[Stephen Smalley]

On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote:
>  Running targeted/enforcing, latest rawhide.
>  
>  I created a 'backup' of my root lvm2 partition, mounted the new
>  partition as /mnt, and copied the files via 'cp -dpR / /mnt'.
>  
>  The copied files were all incorrectly labeled. (same result with cp
>  --preserve=all'). 
>  
>  I tried 'chroot /mnt; restorcon -v -R /', but it had no effect
>  (returned immediately), as did any other resorecon attempted in the
>  chroot'ed shell.
>  
>  'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did
>  the right thing. 
>  
>  [Its almost as if restorecon is using the 'real' full pathname (with
>  leading /mnt), and setfiles is using the 'chroot'ed' pathname (without
>  the leading /mnt).]
>  
>  First, should the 'preserve' on cp have failed to copy the contexts?
>  Second, why the difference in behavior between setfiles and restorecon
>  in this context?  
Good questions.  I know that at one time, there was debate over whether
cp should ever preserve security contexts without use of an explicit
option to that effect, as it might otherwise break existing users
(because a process that may be able to preserve all of the DAC
attributes might not be able to preserve the MAC label).  However, it
does seem unfortunate that a --preserve=all doesn't give you the
intuitive result.  I'm not sure what the right answer is there.

With regard to restorecon, a long time ago, Dan added a test on entry to
it to immediately exit if SELinux wasn't enabled so that it could be
safely called from the rc scripts regardless of whether SELinux was
enabled or disabled.  Since you are running it in a chroot environment,
is_selinux_enabled will always fail because it cannot
check /proc/filesystems for selinuxfs, so restorecon thinks that SELinux
is disabled and exits silently.  Possibly that should be removed or at
least display a warning.

setfiles runs regardless of whether SELinux is enabled or disabled.

-- 
Stephen Smalley
National Security Agency

[Stephen Smalley]

On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote:
>  'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts
> /' did
>  the right thing. 
>  
>  [Its almost as if restorecon is using the 'real' full pathname (with
>  leading /mnt), and setfiles is using the 'chroot'ed' pathname (without
>  the leading /mnt).] 
BTW, I'm not sure what you mean by the above.  setfiles does accept a -r
option to specify an alternate root path, so you can apply it to a
chroot setup without running it chroot'd itself.  But without that
option, I wouldn't have expected it to touch /mnt at all, especially as
file_contexts marks it <<none>>.

-- 
Stephen Smalley
National Security Agency

[Tom London]

On 8/29/05, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  
>  On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote:
>  > 'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did
>  > the right thing.
>  >
>  > [Its almost as if restorecon is using the 'real' full pathname (with
>  > leading /mnt), and setfiles is using the 'chroot'ed' pathname (without
>  > the leading /mnt).]
>  
>  BTW, I'm not sure what you mean by the above. setfiles does accept a -r
>  option to specify an alternate root path, so you can apply it to a
>  chroot setup without running it chroot'd itself. But without that
>  option, I wouldn't have expected it to touch /mnt at all, especially as
>  file_contexts marks it <<none>>. 

First, thanks for the explanation.

My comment regarding 'real' vs. 'chroot-ed' pathnames was just my feeble 
poke at explaning what was going on. I had noticed the entry for /mnt in 
file_contexts, and concluded that 1+1=3. ;)

Regarding setfiles, thanks for the info regarding '-r' option. Its not in 
the man page nor in 'setfiles --help', so I did the 'chroot' balancing
act. 
'setfiles -r' produces 'usage: setfiles -r rootpath' though. 

tom
-- 
Tom London