Thank you all for the insightful responses. I think Steffen nailed the true "security concern" that I had overlooked.
Since LinuxCNC uses setuid to run linuxcnc_module_helper, pci_write, pci_read and rtapi_app any outside executable called from one of those four programs needs to be "trusted". In the theoretical case where linuxcnc_module_helper calls "insmod" by using the PATH, a malicious user could craft an insmod replacement that does *malicious thing* and add it to their own PATH. linuxcnc_module_helper looks on PATH, calls the malicious insmod with root permissions and the system is compromised. Using PATH at all in anything with setuid seems very dangerous and my understanding is that this is exactly why "sudo" strips the unprivileged user's environment variables before running anything. The thing is - module_helper.c already uses hardcoded paths to /sbin/ <https://github.com/LinuxCNC/linuxcnc/blob/master/src/module_helper/module_helper.c#L230> and completely ignores the paths found by ./configure (which seems like the right way to do it). I don't think this is a major concern outside of the four executables that use setuid. If the linuxcnc script calls "pidof", it's doing it with the same permissions as the currently logged in user. i.e. - if they could do something malicious they could just open up a shell and do it if they have the permissions, no need to introduce a fake "pidof" via the PATH. If the consensus is that simplification is better, I would be happy to submit some incremental patches to have things use the PATH directly instead of hard coding executable locations at compile time. This would be a good time to take a look through the code that does use setuid and make sure it's not using PATH, as a bonus. Best, Peter On Fri, Apr 25, 2025 at 7:31 AM Steffen Möller via Emc-developers < emc-developers@lists.sourceforge.net> wrote: > > > > > > Gesendet: Freitag, 25. April 2025 um 14:46 > > Von: "andy pugh" <bodge...@gmail.com> > > An: "EMC developers" <emc-developers@lists.sourceforge.net> > > Betreff: Re: [Emc-developers] Questions about hard coded paths at > "./configure" time > > > > On Fri, 25 Apr 2025 at 13:13, Bertho Stultiens <l...@vagrearg.org> > wrote: > > > > > And it isn't even used consistently throughout the code base. > > > > From a parallel conversation: > > > > "I was thinking about this more and I probably can kind of guess what > > was going on. > > > > There is usage of lsmod and modprobe and those are "root" binaries. I > > suspect they were trying to ensure the right path to the root binaries > > could be found. This was then copied for other utilities like grep. > > > > Modern distros should have PATH set correctly for users to be able to > > find binaries. This was an issue on weird non-linux platforms but Linux > > should have been ok even then, certainly now. > > > > I'd think it could all be simplified." > > > > I suspect that lsmod and modprobe are only relevant to RTAI builds, > > and I doubt that the Yocto build would ever use RTAI. > > The exact specification of paths gives some extra security. For instance > you can have loads of fun with somethign along > > echo "#!/bin/rm -r /" > python3 > chmod +x !$ > export PATH=.:$PATH > > You kind of want to know exactly what is executed, especially while > training some small horde of giggling teenagers and giving too much > attention to the metal, turning your back to your keyboard. > > But yes, I also want things to be simple. > > Steffen > > > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
