From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 21 Mar 2011 09:29:47 -0400
Subject: [refpolicy] restorecon needs to read bin_t symlinks
In-Reply-To: <1300567085.3101.35.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>
	<20110319200535.GA6479@siphos.be>
	<1300567085.3101.35.camel@tesla.lan>
Message-ID: <4D8752CB.4020203@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 03/19/11 16:38, Guido Trentalancia wrote:
> 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.
> 
> The example was not just wrong, it was mad. If that was really
> happening, then an unprivileged user could potentially relabel the
> entire filesystem at will by just creating symbolic links into his/her
> home directory, labelling them at will and running the relabelling tool
> on each of those links. Clearly (and fortunately) the label is not taken
> from the source file !
> 
> However, the conclusion is either we want setfiles/restorecon to relabel
> the target or we want to "dontaudit" read operations on symbolic links.
> I am quite sure we don't want the logs flooded.

Restorecon should not be following symlinks.  If it is labeling the
target with the label of the link, that is a bug and needs to go to the
SELinux list.  I looked at the source, and all I see is usage of
lsetfilecon() and lgetfilecon(), so it shouldn't be following symlinks.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com