From: guido@trentalancia.com (Guido Trentalancia) Date: Mon, 21 Mar 2011 15:14:24 +0100 Subject: [refpolicy] R: Re: restorecon needs to read bin_t symlinks Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -- original message originale -- Subject: Re: [refpolicy] restorecon needs to read bin_t symlinks From: "Christopher J. PeBenito" Date: 21/03/2011 14:30 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. There is no bug in userspace (the example was mad). But "read" denial on symbolic links is literally flooding logs and audit logging denial is generating error message from userspace, so it needs to be tackled. Regards, Guido -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com