From: guido@trentalancia.com (Guido Trentalancia)
Date: Sat, 19 Mar 2011 21:25:13 +0100
Subject: [refpolicy] restorecon needs to read bin_t symlinks
In-Reply-To: <20110319200535.GA6479@siphos.be>
References: <1300549506.3034.24.camel@tesla.lan>
	<4D84D11C.5090909@gmail.com> <1300554772.3034.28.camel@tesla.lan>
	<1300564486.3101.14.camel@tesla.lan> <20110319200535.GA6479@siphos.be>
Message-ID: <1300566313.3101.30.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Sat, 19/03/2011 at 21.05 +0100, Sven Vermeulen wrote:
> On Sat, Mar 19, 2011 at 08:54:46PM +0100, Guido Trentalancia wrote:
> > Actually it has nothing to do with restorecon being a symbolic link to
> > the setfiles binary.
> > 
> > Without the "read" capability restorecon is not able to relabel the
> > target file. This is quite bad as we could have non-standard things such
> > as:
> > 
> > ls -al /bin/example_executable
> > lrwxrwxrwx. root root /bin/example_executable
> > -> /opt/example/example_application
> > 
> > and example_application never getting relabelled as bin_t (but instead
> > falling back to usr_t).
> 
> Actually, I would imagine we don't want restorecon to follow symlinks to
> relabel the target files. If we did, then in your example both usr_t and
> bin_t for /opt/example/example_application are valid labels (which isn't
> possible).
> 
> restorecon /bin/example_executable
> restorecon /opt/example/example_application
> 
> The statements would switch the label. A full filesystem relabel, which is
> sometimes touted to be a good solution in case of problems, is in this case
> undecisive as we don't know in which order the files are scanned.

With "lnk_file:read" it just relabels the target file according to the
(unique system-wide) file context definitions. So there won't be
indecision.

My example was wrong (that would never happen). Do we want
setfiles/restorecon to follow symbolic links and relabel the target ?

Regards,

Guido