mount --bind and autorelabel versus restorecon

[Stephen Smalley]

On Tue, 2009-02-17 at 20:53 +0100, Per Sjoholm wrote:
> 
> Stephen Smalley wrote:
> > On Tue, 2009-02-17 at 15:26 +0100, Per Sjoholm wrote:
> >   
> >> There are more than one problem described here and the are connected.
> >> One is the basic how to organize data regarding updates, backup and daily task.
> >> One is SELinux protection.
> >> One is this should NOT be a problem in the first place.
> >> (IT was NOT until target/enforing policy)
> >>
> >> I have systems and try to keep OS and data separated.
> >> This makes backup and updating OS easier.
> >> SELinux chamges things.
> >> Normaly:
> >> Partion 1,2 and 3 contain an OS and 4 is an extend partion with my data.
> >> Then I can install a new OS and prepare it before changing over.
> >> Keeping system running, rebooting into the new version.
> >> Reverting to old OS version by a reboot if needed.
> >>
> >> ONLY OS dependent data(config, deamon ..) is under "/" rest is elsewhere
> >> and the physical file system for /dev/sda5 is mounted under /disk_dev/sda5.
> >> with a mount --bind parts of   /disk_dev/<part>/<subdir> get mounted i the proper place.
> >> mount --bind /disk_dev/sda5/projects/A /prj/A
> >> the NFS4 exports is an other example
> >>
> >> Some clients use samba and some NFS parts of the data should be available via httpd, bittorrent.
> >> Some of the files are large and can't be duplicated (symlinked)?
> >> Most data belongs to A project and the project belongs to a group
> >>
> >> SELinux
> >> Using symlinks or an alias in httpd does not work as components in the path
> >> is missing lables as they contain data that ftp,samba or httpd is not ment to read.
> >>     
> >
> > You should be able to label those symlinks or directory components with
> > a type that is readable by those domains, e.g. public_content_t, or add
> > allow rules via a local policy module to allow those domains to
> > read/search whatever type is presently on those symlinks or directory
> > components.
> >
> >   
> >> autorelabel only handles filesystem mounts NOT mount --bind
> >> the result of
> >> doing a touch /.autorelabel; reboot
> >> doing a restorecon -R <path>
> >>
> >> will differ as autorelable does only see the physical mount.
> >>
> >> It's possible to construct file context and they will most likely NOT
> >> work reliable for both autorelabel and restorecon
> >>     
> >
> > If you can't reorganize your actual filesystem layout (e.g using LVM),
> > then perhaps the easiest solution here would be to disable labeling of
> > the actual file tree under /disk_dev and only use restorecon to label
> > the logical file tree.  Steps:
> > 1) Exclude /disk_dev from relabeling.
> > semanage fcontext -a -t "<<none>>" "/disk_dev(/.*)?"
> >
> > 2) Relabel your logical file tree.
> > restorecon -R /
> >
> >   
> Sounds good
> I will use a /prj/web   and mount --bind to create a logical tree
> Is there a way of triggering a restorecon -R / if a autorelabel has 
> occured ?

You could modify /etc/rc.sysinit to invoke /sbin/restorecon -R / instead
of running /sbin/fixfiles restore, I think.

-- 
Stephen Smalley
National Security Agency