Re: lnk_file read permission

[Dominick Grift <dominick.grift@defensec.nl>]

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