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

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.

Wkr,
	Sven Vermeulen