On 2023-04-18, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >>>> I'm quite opinionated about the setuid-programs unification: there >>>> should not be multiple confusing and masking layers of privilege, and >>>> it should be possible to setgid a capable executable. >>> >>> So you mean that ‘privileged-programs’ should entirely replace >>> ‘setuid-programs’, right? >>> >>> I’m a bit unsure about using file capabilities: >>> >>> 1. File capabilities are persistent and less visible than setuid bits >>> (you won’t see them with “ls -l”), so easily overlooked. Could >>> there be a risk of lingering file capabilities when reconfiguring a >>> system? >> >> Does reconfigure leave old setuid binaries laying around in >> /run/setuid-programs currently? > > No: ‘activate-setuid-programs’ first deletes /run/setuid-programs/*, > then populates it. Good! >> Seems like with setuid/setgid and the proposed priviledged binaries, the >> setuid/setgid bits and capabilties should be explicitly set on any >> defined binaries, and any that are left over in the /run/*-programs >> directories should be... forcibly removed! Otherwise your current system >> is vulnerable to previous potentially bad choices indefinitely... > > Right, so in that sense it’s no different from setuid binaries, other > than the fact that “ls -l” won’t show it. That aspect seems fixable with documentation in the simplest case of how to show that /run/*-programs contains the correct permissions, e.g a brief mention of "getcap" to show the capabilities. The most fancy case I quickly think of might be "guix system list-privledged-programs" or some such that would display all the various privledges (setuid, setgid, capabilities, etc.) on each of the binaries in /run/*-programs? But probably overkill... >>> 2. How ’bout portability to different file systems and to GNU/Hurd? >> >> Currently I *think* /run/setuid-programs is tmpfs > > It’s not by default. Huh, could have sworn on all my guix systems that /run was on tmpfs by default, and I did not knowingly do anything special to change that... >> In all seriousness though, while I appreciate thinking about broad >> compatibility across different types of systems, I am a bit nervous >> about an approach that would require features to behave compatibly >> across all systems... > > I guess All I’m saying is that we should keep this in mind. > > Perhaps the hypothetical ‘activate-privileged-programs’ procedure would > fall back to setuid-root on GNU/Hurd or do some other Hurd-specific > thing. We don’t need to go too far, but we do need to give it some > thought IMO. If it cannot properly set the capabilities, then it should not assume setuid-root is an ok fallback; it should instead most definitely just fail! At least the case I am most familiar with, lcsync, it really should not run as setuid-root, as that effectively allows anyone to modify or copy any file as root. Although, likely Hurd limits the impacts of setuid root in ways I do not understand? Even then, I still think if you ask for something in your guix system configuration, and it cannot deliver what you asked for, it should not give you something else as an approximation of what you wanted. Maybe that is a strict interpretation of an ideal, and reality is much harder than that. :) live well, vagrant