* Ben Cotton:
> Another problem of a hardcoded RPATH is security. When an ELF object
> contains an RPATH pointed to a directory not managed by the system,
> where some malicious actor has write permissions to, it's relatively
> easy to execute arbitrary code.
>
> Performance can be also affected, since probing explicitly e.g.
> /usr/lib64 through RPATH adds extra open/openat system calls to the
> process startup.
Both issues also apply to RUNPATH, not just RPATH. It particularly
impacts s390x due to its many legacy hwcaps subdirectories.
> === Definition of a broken RPATH ===
> This change will use the
> [https://github.com/rpm-software-management/rpm/blob/master/scripts/check-rpaths-worker
> rpm script] for checking the broken RPATH's.
>
> The categories are:
>
> * standard RPATHs (e.g. `/usr/lib` or `/usr/lib64`); such RPATHs are a
> minor issue but are introducing redundant searchpaths without
> providing a benefit. They can also cause errors in multilib
> environments.
> * invalid RPATHs; these are RPATHs which are neither absolute nor
> relative filenames and can therefore be a SECURITY risk
> * insecure RPATHs; these are relative RPATHs which are a SECURITY risk
> * the special `$ORIGIN` RPATHs are appearing after other RPATHs; this
> is just a minor issue but usually unwanted
> * the RPATH is empty; there is no reason for such RPATHs and they
> cause unneeded work while loading libraries
> * an RPATH references `..` of an absolute path; this will break the
> functionality when the path before `..` is a symlink
$ORIGIN needs to exempted from the absolute and .. checks as well.
I would agree here but if that's the case packagers could opt-out. The other alternative would be to change the rpm script for that specific case.
I think these rules make sense for RUNPATH, and we should outright ban
RPATH.
I'd agree here as well, however this could be a future fedora change as I would deem it too disruptive to outright ban RPATH for now.
I think we also should binutils with --enable-new-tags at configure
time.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure