Hi! sba...@catern.com skribis:
> 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. Right. >> 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. Yes, I agree with this. I think we must just be clear that GuixSD will be the only one to benefit from a solution along the lines you wrote, at least for the foreseeable future. It seems to me that your proposal could be summarized as (1) replacing sudo with a sudo-that-uses-IPCs (fine), and (2) replacing other setuid programs by a wrapper that does “sudo program”. Item #2 is already possible, but it doesn’t look “better” to me that setuid programs from a security or configuration viewpoint. Note that GuixSD is different from other distros regarding setuid binaries: they exist only in /run/setuid-programs, which is recreated at boot time (unless of course root messes up with the system). >>> 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. :) What features do you have in mind? Namespaces look like an improvement to me. If you want something less hacky, there’s always the Hurd. ;-) >>> 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? Polkit has its own sudo-like program, ‘pkexec’, that works by talking to the polkit daemon over D-Bus. Ludo’.
