On 05/17/2018 05:03 PM, Gionatan Danti wrote: > Il 17-05-2018 18:45 Stephen Smalley ha scritto: >> 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, > 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. > >> 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 policies? > Thanks. As to your first point, yes, presently you have to separately keep your source .te/.fc files around to make future changes in that form. With a modern selinux userspace however you can extract the CIL version of the policy module via semodule -c -E, edit that, and then re-insert it. With respect to the second point, yes, the name of each policy module has to be unique, so you do have to be mindful of that. The distros should likely should define some policy module namespacing rules for local policy modules so that you can at least know that you never need to worry about conflicts with distro-provided or third party package policy. And perhaps audit2allow should automatically use such a prefix. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/selinux@xxxxxxxxxxxxxxxxxxxxxxx/message/4SNQHVH74HELG7KI65QTG5PYXSZV3XAQ/
