> > After upgrading to Fedora 45, Shadow Stack support will be enabled > > automatically for processes whose binary and all loaded shared > > libraries carry the appropriate markup. Processes that load any > > non-compliant shared object will have Shadow Stack silently disabled > > at startup. > > Is anyone aware of any other mainstream distros that have enabled > Shadow Stack yet, or is Fedora going to be the first to get the > visibility of any potential lurking incompatibilities ?
We will be the first. This reminds me of: Freedom, Friends, Features, First. > > == User Experience == > > This change is transparent to users. No action is required to enable > > or configure support. Applications that are not compatible with Shadow > > Stack run without the protection; they continue to function normally > > but do not benefit from the additional security. In rare cases, an > > application that loads a non-compliant plugin at runtime may encounter > > a `dlopen` error. Known affected applications ship with a drop-in > > configuration file that prevents this. Users who encounter this with > > other applications can create a file in `/etc/tunables.conf.d/` to opt > > the application out, and then run `ldconfig`. > > "encounter a dlopen error" is rather vague. > > What is the exact behaviour that users will see when an app dlopens > a library that is not shadow stack compatible ? Will the application > in question crash/abort, or will it report a generic or specific error > message and can apps expect to gracefully degrade in some manner ? > How will users diagnose that the problem is specifically related > to shadow stacks incompatiblity, in order to know to turn off > the feature ? This will depend on how the application handles a dlopen failure. If it assumes success, there will be a null pointer dereference and a crash when it tries to proceed. On the other hand, the application could gracefully fail or degrade when dlopen fails. We provide an error message.I did mention it in the change proposal: "error: dlopen: /path/to/library.so: rebuild shared object with SHSTK support enabled" This error message sounds confusing and isn't relevant to the user. I'll file a ticket to work on improving this. > Editting an /etc/tunables.conf.d file is not going to be so nice if > users are dealing with pre-built containers from a 3rd party. > > Is there any system global mechanism to turn off ShadowStacks that > would be inherited by containers too ? I guess since this sounds > like purely a glibc control mechanism, there's no kernel cmdline > boot arg to disable this feature ? > > IOW if any containers were affected, users would need to mount an > override for /etc/tunables.conf.d The enablement status of shadow stack is a container property. If the hardware supports it, the container inherits the capability to use it. Even when the capability is available, whether the container runs its application in shadow stack mode depends on the container runtime, i.e. the glibc dynamic loader inside the container. Regarding the kernel command line, I believe the capability can be turned off. i.e. the kernel will not offer it to userspace. -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
