l...@gnu.org (Ludovic Courtès) writes: > Well, the kernel Linux will forever support setuid binaries
That can be selectively turned off per-mount, simply specify the nosuid option. And so eventually we can get to a point where setuid is a Linux build configuration option, which distros can turn off. > and thus, most likely, chroot(2) will forever be restricted to root. This too can be a configuration option. And it's entirely possible for distros to turn it on after setuid is turned off. These decisions about setuid and chroot are distribution decisions; distributions can and should make decisions and innovate independent of the Linux kernel's default configuration. (That's part of how the whole GNU/Linux ecosystem works) On another point, even if chroot is forever privileged, new syscalls can be developed which duplicate the functionality of chroot with more flexibility and less baggage. But they will certainly face the same issue as chroot if they wish to be made unprivileged. Mount namespaces, for example, (with a bit of tweaking of the API to make it actually useful unprivileged) could be made unprivileged without relying on user namespaces, but face the same problems as chroot. So by removing setuid we are laying the groundwork for innovation not just by allowing unprivileged chroot. >> I think also the ability to build a setuid-free system could make GuixSD >> a useful platform for innovation in the use of filesystem namespaces. (I >> myself certainly have plans in this area.) > > Our ‘linux-libre’ package has support for user namespaces and other > namespaces built in already (this is the default kernel config I think), > so one can already play with namespaces on GuixSD and on other distros > that enable it. :-) I mean new kernel features - I'm skeptical that user namespaces provide an intuitive or easy to use API, and I have some ideas on what would be better. But the features I want to develop rely on getting rid of setuid, so I'm starting there. :) >> The largest targets for elimination are sudo and su. Luckily there is >> already a ready alternative for those commands: ssh. We can augment lsh > > SSH is a complex protocol and its implementations are complex too. I > would find it unreasonable to replace ‘su’ and ‘sudo’ with something > this complex, that goes through the TCP/IP stack, etc. Yes, that is true. The sole virtue of ssh here is that it already exists and is used for this purpose. What if we adapted s6-sudod, or wrote something from scratch? Or perhaps patched sudo to work in some way over IPC? I think a generic solution is useful. Maybe something should be written specifically for GuixSD, configured with Guile? Or maybe something which makes use of the putative standard, PolicyKit, which is configured with Javascript?
