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?
Thanks.
On Sat, Apr 25, 2020 at 1:21 PM Gionatan Danti g.danti@assyoma.it 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@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8 _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org 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@lists.fedoraproject.or...
Il 2020-04-27 09:04 Zdenek Pytela ha scritto:
Hi,
Daemons/domains usually have the access to symlinks granted. Can you give a particular example? I checked mysql:
Hi Zdenek, an example take from a server running postfix with mysql integration on a CentOS 8 box:
[root@localhost ~]# sesearch -A -s postfix_master_t | grep lnk_file | grep mysql allow postfix_master_t mysqld_etc_t:lnk_file { getattr read };
As you can see, the master process can read mysqld_etc_t links but not mysqld_db_t ones.
Another example, from relocating mongodb (this time on a CentOS 7 box): semanage fcontext -a -e /var/lib/mongo /tank/graylog/var/lib/mongo mv /var/lib/mongo /tank/graylog/var/lib/mongo ln -s /tank/graylog/var/lib/mongo /var/lib/mongo restorecon /var/lib/mongo systemctl restart mongod
Result: MongoDB does not start. Issuing "cat /var/log/audit/audit.log | audit2allow" show the following error: "allow mongod_t mongod_var_lib_t:lnk_file read;"
Indeed, sesearch can not find any permission to read mongod_var_lib_t links: [root@localhost ~]# sesearch -A -s mongod_t | grep lnk_file | grep mongod_var_lib_t
Finally, in the past I opened a buzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1598593) against virtlogd which was denied reading from a relocated /var/lib/libvirt directory.
So 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?
Thanks.
Il 2020-04-27 12:18 Gionatan Danti ha scritto:
Il 2020-04-27 09:04 Zdenek Pytela ha scritto:
Hi,
Daemons/domains usually have the access to symlinks granted. Can you give a particular example? I checked mysql:
Hi Zdenek, an example take from a server running postfix with mysql integration on a CentOS 8 box:
[root@localhost ~]# sesearch -A -s postfix_master_t | grep lnk_file | grep mysql allow postfix_master_t mysqld_etc_t:lnk_file { getattr read };
As you can see, the master process can read mysqld_etc_t links but not mysqld_db_t ones.
Another example, from relocating mongodb (this time on a CentOS 7 box): semanage fcontext -a -e /var/lib/mongo /tank/graylog/var/lib/mongo mv /var/lib/mongo /tank/graylog/var/lib/mongo ln -s /tank/graylog/var/lib/mongo /var/lib/mongo restorecon /var/lib/mongo systemctl restart mongod
Result: MongoDB does not start. Issuing "cat /var/log/audit/audit.log | audit2allow" show the following error: "allow mongod_t mongod_var_lib_t:lnk_file read;"
Indeed, sesearch can not find any permission to read mongod_var_lib_t links: [root@localhost ~]# sesearch -A -s mongod_t | grep lnk_file | grep mongod_var_lib_t
Finally, in the past I opened a buzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1598593) against virtlogd which was denied reading from a relocated /var/lib/libvirt directory.
So 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?
Thanks.
Hi, anyone with some suggestion? Am I missing something? Thanks.
Il 2020-05-05 10:43 Gionatan Danti ha scritto:
Il 2020-04-27 12:18 Gionatan Danti ha scritto:
Il 2020-04-27 09:04 Zdenek Pytela ha scritto:
Hi,
Daemons/domains usually have the access to symlinks granted. Can you give a particular example? I checked mysql:
Hi Zdenek, an example take from a server running postfix with mysql integration on a CentOS 8 box:
[root@localhost ~]# sesearch -A -s postfix_master_t | grep lnk_file | grep mysql allow postfix_master_t mysqld_etc_t:lnk_file { getattr read };
As you can see, the master process can read mysqld_etc_t links but not mysqld_db_t ones.
Another example, from relocating mongodb (this time on a CentOS 7 box): semanage fcontext -a -e /var/lib/mongo /tank/graylog/var/lib/mongo mv /var/lib/mongo /tank/graylog/var/lib/mongo ln -s /tank/graylog/var/lib/mongo /var/lib/mongo restorecon /var/lib/mongo systemctl restart mongod
Result: MongoDB does not start. Issuing "cat /var/log/audit/audit.log | audit2allow" show the following error: "allow mongod_t mongod_var_lib_t:lnk_file read;"
Indeed, sesearch can not find any permission to read mongod_var_lib_t links: [root@localhost ~]# sesearch -A -s mongod_t | grep lnk_file | grep mongod_var_lib_t
Finally, in the past I opened a buzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1598593) against virtlogd which was denied reading from a relocated /var/lib/libvirt directory.
So 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?
Thanks.
Hi, anyone with some suggestion? Am I missing something? Thanks.
Hi all, sorry for the long quote, but I think it can be useful to add some context.
Today, relocating a mysql database on a new partition, I was bitten by the same issue depicted in this thread: the lacking of lnk_read permission for many selinux policy.
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), my original questions stand:
So 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?
On one of the bugzilla issue I opened regarding various processes lacking lnk_read permission, one reply stated that denying lnk_read permission lead to "unnecessary fragility". Is that true?
Finally, I am missing something? Thanks.
On Wed, Jul 29, 2020 at 11:23 PM Gionatan Danti g.danti@assyoma.it wrote:
Il 2020-05-05 10:43 Gionatan Danti ha scritto:
So 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?
There are attacks possible, although possibly not for the threat model that is interesting for a regular Fedora user. A symlink is technically still a file with some data in it (representing the path to the target, but you can basically put an arbitrary string there), so it could be used as a covert channel to smuggle some data between domains. In an MLS setting, which is one of the main target use cases of SELinux, such information leak could be a serious concern.
So for Fedora it might indeed make sense to add some "domain_can_read_symlinks" boolean for people who customize things with symlinks a lot... But there might be other reasons for being careful with symlinks that you or I haven't thought of :) I'd suggest asking on the upstream mailing list (selinux@vger.kernel.org) on if/why it's a good idea to follow the principle of least privilege also for symlinks. You are likely to get a more educated answer there.
On one of the bugzilla issue I opened regarding various processes lacking lnk_read permission, one reply stated that denying lnk_read permission lead to "unnecessary fragility". Is that true?
I don't understand what is meant here... Do you have a link to the bugzilla in question?
-- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc.
Il 2020-07-30 10:11 Ondrej Mosnacek ha scritto:
There are attacks possible, although possibly not for the threat model that is interesting for a regular Fedora user. A symlink is technically still a file with some data in it (representing the path to the target, but you can basically put an arbitrary string there), so it could be used as a covert channel to smuggle some data between domains. In an MLS setting, which is one of the main target use cases of SELinux, such information leak could be a serious concern.
True, in a full MLS or strict selinux mode, symlink can be used to sneakly pass some unwanted data between domains. But, as you stated, this should be a non-issue for a targeted policy as used by Fedora, CentOS, etc.
So for Fedora it might indeed make sense to add some "domain_can_read_symlinks" boolean for people who customize things with symlinks a lot... But there might be other reasons for being careful with symlinks that you or I haven't thought of :) I'd suggest asking on the upstream mailing list (selinux@vger.kernel.org) on if/why it's a good idea to follow the principle of least privilege also for symlinks. You are likely to get a more educated answer there.
The boolean "can_read_symlinks" is, indeed, a very good idea. I'll ask on upstream mailing list as you suggested.
I don't understand what is meant here... Do you have a link to the bugzilla in question?
Sorry, it was not on bugzilla, but on this same list: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
Thanks.
-- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc.
On Fri, Jul 31, 2020 at 9:59 AM Gionatan Danti g.danti@assyoma.it wrote:
Il 2020-07-30 10:11 Ondrej Mosnacek ha scritto:
So for Fedora it might indeed make sense to add some "domain_can_read_symlinks" boolean for people who customize things with symlinks a lot... But there might be other reasons for being careful with symlinks that you or I haven't thought of :) I'd suggest asking on the upstream mailing list (selinux@vger.kernel.org) on if/why it's a good idea to follow the principle of least privilege also for symlinks. You are likely to get a more educated answer there.
The boolean "can_read_symlinks" is, indeed, a very good idea. I'll ask on upstream mailing list as you suggested.
Just to clarify: The upstream ML is a place for general discussions about SELinux itself. Just in case you intend to mention the boolean there - for that you should rather file a BZ against selinux-policy on Fedora. I recommended the list specifically for the general question about symlinks.
I don't understand what is meant here... Do you have a link to the bugzilla in question?
Sorry, it was not on bugzilla, but on this same list: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
I think Stephen meant something along the lines that our policy macros should account for the possibility of system directories to be symlinked and generate the appropriate allow rules alongside the dir ones. Which would be a better solution, but likely also a lot of work to fix everywhere properly :/
Il 2020-07-31 10:45 Ondrej Mosnacek ha scritto:
Just to clarify: The upstream ML is a place for general discussions about SELinux itself. Just in case you intend to mention the boolean there - for that you should rather file a BZ against selinux-policy on Fedora. I recommended the list specifically for the general question about symlinks.
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1862383
I think Stephen meant something along the lines that our policy macros should account for the possibility of system directories to be symlinked and generate the appropriate allow rules alongside the dir ones. Which would be a better solution, but likely also a lot of work to fix everywhere properly :/
Yeah, this would probably be the definitive solution. Thanks.
selinux@lists.fedoraproject.org
-
Gionatan Danti -
Ondrej Mosnacek -
Zdenek Pytela