danwalsh (danwalsh) wrote,

10 things you probably did not know about SELinux #9 Backing up and Restoring Labels.

It has been a few years since I discusses backing up and restoring labels with SELinux.   

I was asked at the Lisa 11 conference by a backup utility developer, "How should he save and restore SELinux security contexts?"  He also asked whether or not his tool should always maintain these context?  Finally how should the tool react if the system would not allow the context to be restored? 

Interesting topic.  Lets first take a look at a few tools for backing up content with SELinux labels.

SELinux stores SELinux security labels (contexts) as extended attributes with the inode on the file system.  If an administrate wants to backup/restore files with the SELinux labels,  you need to use a utility that supports this.

When SELinux first shipped the only utility to do this was star (RHEL4) , GNU tar at that time did not support extended attributes.  Later extended attribute support was added to GNU tar.  ( tar --selinux -cvf /tmp/etc.tgz /etc ) Rsync also has support for maintaining extended attributes.  Even Dump/Restore can now support maintaining the extended attributes.

I often question is whether this is a good idea to maintain the labels.  In some cases your security goals require it.  For example backing up sensitivity labelled data (MLS) requires this.  If you have a file labelled TopSecret, you would definitely want to maintain this within the archive.

But most of us do not deal with sensitivity labelled data, and we would want to make sure the data on our system is labelled correctly based on the current security definition on our system.  Trying to maintain the SELinux labels and restore them can be a mistake in several cases. 

For example:

Target file system does not support extended attributes.

If you attempted to restore files to a file system that does not support extended attributes.  Does the administrator have a way to allow this?

Updating a machine for one version of the OS to another.

If you backed up your /home directory before updating from Fedora 15 to Fedora 16 and then restored the content of the archive, certain directories in you home directory will be mislabeled and potentially tools like googlechrome or colord will fail.  You would have been better off having the content restored the archive and then running restorecon -R - v /home.

Copying an archive from one machine to another machine with an older OS.

Attempting to maintain the labels would be wrong if you created an archive on a RHEL6 box and then attempting to restore the archive on a RHEL5 box.  If the RHEL5 kernel does not understand a label from a RHEL6 box, then the label will not be allowed to be placed on the disk.   In this case, again you would want to put the files down and then restore the labels. 

In this case it would be nice if the tools used to restore the content had the ability to label the content "correctly" based on the file_contexts definitions on the target system.  That way we would not have a race condition where the labels on the files are incorrect for a period of time.

In conclusion the backup/restore utility should:
  • allow the administrator to decide whether or not to save the SELinux labels and restore them.
  • Allow the administrator to specify the tool to restore the files using the default labels as specified on the target system (matchpathcon/setfscreatecon)
  • If the utility does not allow have the second option, in most cases the administrator should run restorecon on the restored files.

  • Container Domains (Types)

    One of the things people have always had a hard time understanding about SELinux is around different types. In this blog, I am going to discuss…

  • Musings on Hybrid Cloud

    I work on the lowest levels of container runtimes and usually around process security. My team and I work on basically everything needed run…

  • Container Labeling

    An issue was recently raised on libpod, the github repo for Podman. "container_t isn't allowed to access container_var_lib_t" Container policy…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened