Gionatan Danti
2018-05-17 21:03:22 UTC
This is one valid way to do it; bind mounts are another. A bind mount
would avoid the problem of introducing a new file (the symbolic link)
into the pathname lookup and thus avoid a new permission check.
Hi Stephen,would avoid the problem of introducing a new file (the symbolic link)
into the pathname lookup and thus avoid a new permission check.
surely bind mount would avoid the problem, but I find them less
"auto-explaining" than an "explict" symlink.
But hey - this is a matter of preferences, I suppose.
In this case, it is merely the fact that in a stock system, there are
no symbolic links with that type and thus no reason to ever have
allowed it in the default policy. In general, restricting access to
symbolic links is useful in preventing symlink attacks and
unauthorized information flow. It appears that this access is allowed
in Fedora 27/28.
Fair enough.no symbolic links with that type and thus no reason to ever have
allowed it in the default policy. In general, restricting access to
symbolic links is useful in preventing symlink attacks and
unauthorized information flow. It appears that this access is allowed
in Fedora 27/28.
Likely because there are symlinks under /etc already that are widely
accessed and thus that is allowed in the default policy.
Sounds good ;)accessed and thus that is allowed in the default policy.
NB You generally do not want to use chcon, because that context will
be overridden upon the next filesystem relabel unless you also add an
entry to file_contexts via semanage fcontext. Even in that case,
better to add first via semanage fcontext and then run restorecon.
Sure, my chcon was issue with the broken premise that "restorecon -Fbe overridden upon the next filesystem relabel unless you also add an
entry to file_contexts via semanage fcontext. Even in that case,
better to add first via semanage fcontext and then run restorecon.
/etc/libvirtd" would label the symlink the same as original directory -
with virt_etc_t. Instead, restorecon, well, restored the correct "etc_t"
context for the symlink.
You can always generate a local policy module using audit2allow to
allow the symlinks to be read.
True, but the are somewhat difficult to handle. Specifically:allow the symlinks to be read.
- if I lose the template file from which the policy was compiled, adding
further permissions to the same policy is inconvenient;
- each added policy should have a specific, non overlapping name
(right?) - and this means tracing each added policy.
So, each time it is possible, I really try hard to stick with default
policy, booleans and fcontext changes.
I am missing something that can ease me with creating/managing custom
policies?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
selinux mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to selinux-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/Q37JDLHVIKEL6ALKK3A4SGG7CLC