lnk_file read permission

[Gionatan Danti]

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.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8

[Zdenek Pytela]

On Sat, Apr 25, 2020 at 1:21 PM Gionatan Danti <g.danti(a)assyoma.it&gt; 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(a)assyoma.it - info(a)assyoma.it
>  GPG public key ID: FF5F32A8
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>  

-- 

Zdenek Pytela
Security controls team, sst_platform_security

[Gionatan Danti]

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.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8

[Gionatan Danti]

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.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8

[Gionatan Danti]

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.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8

[Ondrej Mosnacek]

On Wed, Jul 29, 2020 at 11:23 PM Gionatan Danti <g.danti(a)assyoma.it&gt; 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(a)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.

[Gionatan Danti]

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(a)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/[e-mail]...

Thanks.

>  
>  --
>  Ondrej Mosnacek
>  Software Engineer, Platform Security - SELinux kernel
>  Red Hat, Inc. 
-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8

[Ondrej Mosnacek]

On Fri, Jul 31, 2020 at 9:59 AM Gionatan Danti <g.danti(a)assyoma.it&gt; 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(a)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/[e-mail]...
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 :/

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

[Gionatan Danti]

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.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8