lnk_file read permission

lnk_file read permission

[Gionatan Danti]

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

Re: lnk_file read permission

[Stephen Smalley]

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.

Re: lnk_file read permission

[Gionatan Danti]

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

Re: lnk_file read permission

[Christian Göttsche]

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).

Re: lnk_file read permission

[Dominick Grift]

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

Re: lnk_file read permission

[Gionatan Danti]

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

Re: lnk_file read permission

[Gionatan Danti]

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

Re: lnk_file read permission

[Dominick Grift]

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

Re: lnk_file read permission

[Gionatan Danti]

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

Re: lnk_file read permission

[Gionatan Danti]

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

Re: lnk_file read permission

[Dominick Grift]

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