Dear list, I am writing this email as suggested here: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/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? As a side note, consider that the above applies to other common services as libvirt (fixed via this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1598593) and mongodb [1]. Thanks. [1] 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 -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8
On Fri, Jul 31, 2020 at 6:06 AM Gionatan Danti <g.danti@assyoma.it> wrote:
>
> Dear list,
> I am writing this email as suggested here:
> https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/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?
The lnk_file read permission check can be used to protect processes
from following/reading untrusted symlinks, often used in malicious
symlink attacks.
The more broadly you allow it, the more potential for the process to
be misdirected to an unexpected file in order to overwrite some file
or leak its contents.
That said, I think the policy macros/interfaces could allow it more
widely than is currently done without too much risk. That's more of a
question for selinux-refpolicy for upstream policy and/or the Fedora
selinux list for their fork of it. The alternative approach for
relocating directories is to use bind mounts.
Am Fr., 31. Juli 2020 um 12:03 Uhr schrieb Gionatan Danti <g.danti@assyoma.it>:
>
> Dear list,
> I am writing this email as suggested here:
> https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/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).
Christian Göttsche <cgzones@googlemail.com> writes: > Am Fr., 31. Juli 2020 um 12:03 Uhr schrieb Gionatan Danti <g.danti@assyoma.it>: >> >> Dear list, >> I am writing this email as suggested here: >> https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/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). I agree with this, also for compatibility with systemds' StateDirectory= in conjunction with DynamicUsers=. I you would for example have a mysqld service with StateDirectory=mysqld and DynamicUser=yes then systemd would maintain a symlink /var/lib/mysqld that points to /var/lib/private/mysqld Even if you do not use that functionality it should still be compatible with /data/lib /var/lib equivalency. I do this consistently in my personal policy. ie instead of using "/var/lib/mysqld(/.*)? i use /var/lib/mysqld -d and /var/lib/mysqld/.* so that the symlink context stay's generic Regardless, this is a policy design issue that you should probably take to your distribution maintainer. -- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
Il 2020-07-31 15:12 Stephen Smalley ha scritto: > The lnk_file read permission check can be used to protect processes > from following/reading untrusted symlinks, often used in malicious > symlink attacks. > The more broadly you allow it, the more potential for the process to > be misdirected to an unexpected file in order to overwrite some file > or leak its contents. Hi Stephen, I generally know the catchs with symlinks, but I fail to understand how this can be a problem for selinux: after all, the real/target file must be labeled with the correct type, otherwise the service binary (running in its confined domain) will not be able to open it. In other words, it is my understanding that selinux not only matches the symlink, but the target file also. So it should not be possible to fool it by chaning the symlink target on the fly. Am I missing something? > That said, I think the policy macros/interfaces could allow it more > widely than is currently done without too much risk. That's more of a > question for selinux-refpolicy for upstream policy and/or the Fedora > selinux list for their fork of it. The alternative approach for > relocating directories is to use bind mounts. Well, I'm coming from the fedora selinux mailing list ;) But if you think I should write to selinux-refpolicy, I will do that. Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8
Il 2020-07-31 18:25 Christian Göttsche ha scritto:
> 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).
Yeah, in some cases I uses the approach above as it seems that many
domain have lnk_file read permission to var_lib_t. I wonder if a more
generic solution exists.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
Il 2020-07-31 18:53 Dominick Grift ha scritto:
> I agree with this, also for compatibility with systemds'
> StateDirectory=
> in conjunction with DynamicUsers=.
>
> I you would for example have a mysqld service with
> StateDirectory=mysqld
> and DynamicUser=yes then systemd would maintain a symlink
> /var/lib/mysqld that points to /var/lib/private/mysqld
>
> Even if you do not use that functionality it should still be compatible
> with /data/lib /var/lib equivalency.
>
> I do this consistently in my personal policy. ie instead of using
> "/var/lib/mysqld(/.*)? i use /var/lib/mysqld -d and /var/lib/mysqld/.*
> so that the symlink context stay's generic
>
> Regardless, this is a policy design issue that you should probably take
> to your distribution maintainer.
I did not know that systemd would, with specific settings, create a
private mysql data dir.
I would try the var_lib_t approach more widely.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
Christian Göttsche <cgzones@googlemail.com> writes: > Am Fr., 31. Juli 2020 um 12:03 Uhr schrieb Gionatan Danti <g.danti@assyoma.it>: >> >> Dear list, >> I am writing this email as suggested here: >> https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/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). This issue is though that you can't override an existing "/var/lib/msqld(/.*)?" with an "/var/lib/mysqld -l". The former will take precendence of the latter AFAIK. You would have to atleast consistently replace all the /var/log/bla(/.*)? /var/spool/bla(/.*)? /var/lib/bla(/.*)? with /etc/bla -d /etc/bla/.* etc for systemd respectively then add equivalency rules: /var/log/private /var/log /var/lib/private /var/lib /var/spool/private /var/spool -- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
Il 2020-07-31 19:09 Gionatan Danti ha scritto:
> I did not know that systemd would, with specific settings, create a
> private mysql data dir.
> I would try the var_lib_t approach more widely.
> Thanks.
Mmm, it seems labeling the link as var_lib_t is not always sufficient.
Doing a mongodb test relocation from /var/lib/mongodb to /zzz/mongodb
the service does not start, even if I can see the link having var_lib_t
label:
# ls -alZ /var/lib/
...
lrwxrwxrwx. root root unconfined_u:object_r:var_lib_t:s0 mongodb
-> /zzz/mongodb
Indeed, I can see the following in /var/log/audit:
type=AVC msg=audit(1596222151.576:253): avc: denied { read } for
pid=4313 comm="mongod" name="mongodb" dev="dm-0" ino=33673444
scontext=system_u:system_r:mongod_t:s0
tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=lnk_file permissive=0
Relabeling the synlink with its "native" label via restorecon -RF
produce the following:
# ls -alZ /var/lib/
...
lrwxrwxrwx. root root system_u:object_r:mongod_var_lib_t:s0
mongodb -> /zzz/mongodb
But the service again does not start, with the followin logs:
type=AVC msg=audit(1596222240.363:257): avc: denied { read } for
pid=4344 comm="mongod" name="mongodb" dev="dm-0" ino=33673444
scontext=system_u:system_r:mongod_t:s0
tcontext=system_u:object_r:mongod_var_lib_t:s0 tclass=lnk_file
permissive=0
What would be the best approach in this case? I know that one approach
would be to use a bind mount, but I would like to avoid it because:
a) it has bad filesystem discoverably (you had to search for bind mount
explicitly, while a symlink is visible even with a simple ls)
b) I need to setup a fcontext <<None>> for the actual dir which is
bind-mounted (otherwise, a "restorecon -RF /zzz/" will cause issues, by
relabeling any files with default_t)
I am open to suggestions...
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
Gionatan Danti <g.danti@assyoma.it> writes: > Il 2020-07-31 19:09 Gionatan Danti ha scritto: >> I did not know that systemd would, with specific settings, create a >> private mysql data dir. >> I would try the var_lib_t approach more widely. >> Thanks. > > Mmm, it seems labeling the link as var_lib_t is not always sufficient. > Doing a mongodb test relocation from /var/lib/mongodb to /zzz/mongodb > the service does not start, even if I can see the link having > var_lib_t label: > > # ls -alZ /var/lib/ > ... > lrwxrwxrwx. root root unconfined_u:object_r:var_lib_t:s0 mongodb > -> /zzz/mongodb > > Indeed, I can see the following in /var/log/audit: > > type=AVC msg=audit(1596222151.576:253): avc: denied { read } for > pid=4313 comm="mongod" name="mongodb" dev="dm-0" ino=33673444 > scontext=system_u:system_r:mongod_t:s0 > tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=lnk_file > permissive=0 > > Relabeling the synlink with its "native" label via restorecon -RF > produce the following: > > # ls -alZ /var/lib/ > ... > lrwxrwxrwx. root root system_u:object_r:mongod_var_lib_t:s0 > mongodb -> /zzz/mongodb > > But the service again does not start, with the followin logs: > > type=AVC msg=audit(1596222240.363:257): avc: denied { read } for > pid=4344 comm="mongod" name="mongodb" dev="dm-0" ino=33673444 > scontext=system_u:system_r:mongod_t:s0 > tcontext=system_u:object_r:mongod_var_lib_t:s0 tclass=lnk_file > permissive=0 > > What would be the best approach in this case? I know that one approach > would be to use a bind mount, but I would like to avoid it because: > a) it has bad filesystem discoverably (you had to search for bind > mount explicitly, while a symlink is visible even with a simple ls) > b) I need to setup a fcontext <<None>> for the actual dir which is > bind-mounted (otherwise, a "restorecon -RF /zzz/" will cause issues, > by relabeling any files with default_t) > > I am open to suggestions... > Thanks. Everyone who has business in /var/lib should probably be able to read var_lib_t lnk_files. You can use audit2allow to allow these entities to read symlinks of type var_lib_t Again though, there is a larger picture here and I would argue that your distribution maintainer should acknowledge that. -- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
Il 2020-07-31 21:44 Dominick Grift ha scritto: > Everyone who has business in /var/lib should probably be able to read > var_lib_t lnk_files. I agree. > You can use audit2allow to allow these entities to read symlinks of > type var_lib_t Sure, but I would like to avoid policy customization outside what can be done via semanage. > Again though, there is a larger picture here and I would argue that > your > distribution maintainer should acknowledge that. Yeah, I opened a BZ agaist it. Do you think this also affect the reference policy? Should I write to the selinux-policy mailing list? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8