[refpolicy] restorecon needs to read bin_t symlinks

[guido@trentalancia.com (Guido Trentalancia)]

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.

Regards,

Guido