On Sat, Apr 25, 2020 at 1:21 PM Gionatan Danti <g.danti@xxxxxxxxxx> wrote:
Hi all,
using selinux, I saw many times that when relocating service dirs (eg:
mysql, mongodb, etc) putting a symlink in the original location, the
affected services fail to start due to missing lnk_file read permission.
As selinux works with target file label and it is path-agnostic (this
is, indeed, a major selinux feature), while is the lnk_file read often
not granted by default? Does granting it expose to additional attack
vectors?
Hi,
Daemons/domains usually have the access to symlinks granted. Can you give a particular example? I checked mysql:
# semanage fcontext -l | grep /var/lib/mysql
/var/lib/mysql(-files|-keyring)?(/.*)? all files system_u:object_r:mysqld_db_t:s0
/var/lib/mysql/mysql\.sock socket system_u:object_r:mysqld_var_run_t:s0
# sesearch -A -s mysqld_t -t mysqld_db_t
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow mysqld_t file_type:dir { getattr ioctl lock open read search };
allow mysqld_t file_type:filesystem getattr;
allow mysqld_t file_type:sock_file getattr;
allow mysqld_t mysqld_db_t:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink write };
allow mysqld_t mysqld_db_t:file { append create getattr ioctl link lock map open read rename setattr unlink write };
allow mysqld_t mysqld_db_t:lnk_file { append create getattr ioctl link lock read rename setattr unlink write };
allow mysqld_t mysqld_db_t:sock_file { append create getattr ioctl link lock open read rename setattr unlink write };
and cannot see a problem when the destination changes from a file or directory to a symlink.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx
--
Zdenek Pytela
Security controls team, sst_platform_security
_______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx
