SELinux Archive on lore.kernel.org
 help / color / Atom feed
* lnk_file read permission
@ 2020-07-31  9:57 Gionatan Danti
  2020-07-31 13:12 ` Stephen Smalley
  2020-07-31 16:25 ` Christian Göttsche
  0 siblings, 2 replies; 11+ messages in thread
From: Gionatan Danti @ 2020-07-31  9:57 UTC (permalink / raw)
  To: selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31  9:57 lnk_file read permission Gionatan Danti
@ 2020-07-31 13:12 ` Stephen Smalley
  2020-07-31 16:56   ` Gionatan Danti
  2020-07-31 16:25 ` Christian Göttsche
  1 sibling, 1 reply; 11+ messages in thread
From: Stephen Smalley @ 2020-07-31 13:12 UTC (permalink / raw)
  To: Gionatan Danti; +Cc: SElinux list

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31  9:57 lnk_file read permission Gionatan Danti
  2020-07-31 13:12 ` Stephen Smalley
@ 2020-07-31 16:25 ` Christian Göttsche
  2020-07-31 16:53   ` Dominick Grift
                     ` (2 more replies)
  1 sibling, 3 replies; 11+ messages in thread
From: Christian Göttsche @ 2020-07-31 16:25 UTC (permalink / raw)
  To: Gionatan Danti; +Cc: selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 16:25 ` Christian Göttsche
@ 2020-07-31 16:53   ` Dominick Grift
  2020-07-31 17:09     ` Gionatan Danti
  2020-07-31 17:00   ` Gionatan Danti
  2020-07-31 17:45   ` Dominick Grift
  2 siblings, 1 reply; 11+ messages in thread
From: Dominick Grift @ 2020-07-31 16:53 UTC (permalink / raw)
  To: Christian Göttsche; +Cc: Gionatan Danti, selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 13:12 ` Stephen Smalley
@ 2020-07-31 16:56   ` Gionatan Danti
  0 siblings, 0 replies; 11+ messages in thread
From: Gionatan Danti @ 2020-07-31 16:56 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: SElinux list

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 16:25 ` Christian Göttsche
  2020-07-31 16:53   ` Dominick Grift
@ 2020-07-31 17:00   ` Gionatan Danti
  2020-07-31 17:45   ` Dominick Grift
  2 siblings, 0 replies; 11+ messages in thread
From: Gionatan Danti @ 2020-07-31 17:00 UTC (permalink / raw)
  To: Christian Göttsche; +Cc: selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 16:53   ` Dominick Grift
@ 2020-07-31 17:09     ` Gionatan Danti
  2020-07-31 19:37       ` Gionatan Danti
  0 siblings, 1 reply; 11+ messages in thread
From: Gionatan Danti @ 2020-07-31 17:09 UTC (permalink / raw)
  To: Dominick Grift; +Cc: Christian Göttsche, selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 16:25 ` Christian Göttsche
  2020-07-31 16:53   ` Dominick Grift
  2020-07-31 17:00   ` Gionatan Danti
@ 2020-07-31 17:45   ` Dominick Grift
  2 siblings, 0 replies; 11+ messages in thread
From: Dominick Grift @ 2020-07-31 17:45 UTC (permalink / raw)
  To: Christian Göttsche; +Cc: Gionatan Danti, selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 17:09     ` Gionatan Danti
@ 2020-07-31 19:37       ` Gionatan Danti
  2020-07-31 19:44         ` Dominick Grift
  0 siblings, 1 reply; 11+ messages in thread
From: Gionatan Danti @ 2020-07-31 19:37 UTC (permalink / raw)
  To: Dominick Grift; +Cc: Christian Göttsche, selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 19:37       ` Gionatan Danti
@ 2020-07-31 19:44         ` Dominick Grift
  2020-07-31 19:49           ` Gionatan Danti
  0 siblings, 1 reply; 11+ messages in thread
From: Dominick Grift @ 2020-07-31 19:44 UTC (permalink / raw)
  To: Gionatan Danti; +Cc: Christian Göttsche, selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: lnk_file read permission
  2020-07-31 19:44         ` Dominick Grift
@ 2020-07-31 19:49           ` Gionatan Danti
  0 siblings, 0 replies; 11+ messages in thread
From: Gionatan Danti @ 2020-07-31 19:49 UTC (permalink / raw)
  To: Dominick Grift; +Cc: Christian Göttsche, selinux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-31  9:57 lnk_file read permission Gionatan Danti
2020-07-31 13:12 ` Stephen Smalley
2020-07-31 16:56   ` Gionatan Danti
2020-07-31 16:25 ` Christian Göttsche
2020-07-31 16:53   ` Dominick Grift
2020-07-31 17:09     ` Gionatan Danti
2020-07-31 19:37       ` Gionatan Danti
2020-07-31 19:44         ` Dominick Grift
2020-07-31 19:49           ` Gionatan Danti
2020-07-31 17:00   ` Gionatan Danti
2020-07-31 17:45   ` Dominick Grift

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org
	public-inbox-index selinux

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git