Am Fr., 31. Juli 2020 um 12:03 Uhr schrieb Gionatan Danti <g.danti@xxxxxxxxxx>: > > Dear list, > I am writing this email as suggested here: > https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx/message/GWEWGDUQS6PERAYEJHL2EE4GDO432IAO/ > > To recap: I have issue with selinux permission when relocating specific > daemon data directory, and using symlink in the original location. For > example, lets consider moving /var/lib/mysql in a new, bigger volume. > > After moving /var/lib/mysql in /data/lib/mysql and creating a symlink > for the new location, I used semanage fcontext to add the relative > equivalency rules. Moreover, I changed my.cnf to explicitly point to the > new data dir and socket file. So far, so good. > > When restarting apache, I noticed it can't connect to mysql. ausearch -m > avc showed the following: > ... > type=AVC msg=audit(1596055762.070:175569): avc: denied { read } for > pid=72946 comm="httpd" name="mysql" dev="sda2" ino=103 > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:mysqld_db_t:s0 tclass=lnk_file permissive=0 > > The log above clearly states that httpd policy lacks lnk_read permission > for mysqld_db_t type. While I solved the issue by leaving the socket > file inside the original directory (removing the /var/lib/mysql symlink > and recreating the mysql dir), I was wondering why each symlink type is > specifically allowed > rather than giving any processes a generic access to symlinks. > > Is this kind of rule not permitted by selinux? Can it open the door to > other attacks? If so, why? Generally, what is the least invasive > approach to relocate services? > An alternative would be, since these symlinks are trusted and permanent, to label them as their parent directory (e.g. var_lib_t (use the '-l' file type specifier)) and allow the applications to read these lnk types. This also prevents e.g. mysqld_t to alter the symlink /var/lib/mysqld (since it probably has write permission to mysql_db_t:lnk_file but not var_lib_t:lnk_file).
