[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Providing an alternative to setuid in GuixSD
From: |
Ludovic Courtès |
Subject: |
Re: Providing an alternative to setuid in GuixSD |
Date: |
Fri, 28 Oct 2016 15:34:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi!
address@hidden skribis:
> address@hidden (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’.