Il 17-05-2018 18:45 Stephen Smalley ha scritto:
This is one valid way to do it; bind mounts are another. A bind
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
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 ;)
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 -F
/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:
- 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
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8