* Providing an alternative to setuid in GuixSD @ 2016-10-23 15:17 sbaugh 2016-10-24 0:09 ` Chris Marusich 2016-10-26 12:24 ` Ludovic Courtès 0 siblings, 2 replies; 9+ messages in thread From: sbaugh @ 2016-10-23 15:17 UTC (permalink / raw) To: guix-devel Hi guix-devel, Has any effort been put into eliminating the need for setuid binaries from GuixSD? I would be interested in working on that. == Why remove setuid binaries? == setuid binaries are problematic for two reasons: 1. Each binary is an attack surface which is frequently exploited by attackers for local privilege escalation. So getting rid of them would improve security. 2. setuid binaries make access control decisions in an environment controlled by the user running them, by looking at files at absolute paths in that environment, such as /etc/passwd. Thus, if unprivileged users had access to chroot or other filesystem namespacing functionality, those users could escalate privileges by manipulating /etc/passwd, /etc/shadow, /etc/sudoers, and then running a setuid binary. So unprivileged chroot is not possible. Issue 2 is a matter near and dear to our hearts here in guix-land, and is my primary motivation. My understanding is that if we eliminated all setuid binaries, we could with some confidence begin to allow unprivileged access to chroot/filesystem namespaces, without first going through user namespaces (which have their own issues). Please correct me if you believe this is wrong. Unprivileged access to chroot would of course greatly aid unprivileged installation of guix. So I think it only right that we should take the necessary steps to support it in GuixSD. Then maybe (in a decade or so...) it'll be picked up by Debian and other large distributions. 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.) == How to do it == Most (all?) setuid binaries can be replaced with a non-setuid binary which performs local IPC to a privileged daemon. The largest targets for elimination are sudo and su. Luckily there is already a ready alternative for those commands: ssh. We can augment lsh with the rich access controls of sudo, add any extra missing features, and then replace sudo/su with wrappers around ssh. (A wrapper would be needed just for sheer familiarity of the system to a user.) sshd runs and performs access controls in a fixed environment, so this is not vulnerable to the chroot attack I mentioned above. Once we have a solid replacement for sudo, we can take a generic approach to eliminating other setuid binaries: just replace them with wrappers which call 'sudo command "$@"', and make sure the sudo-replacement is appropriately configured to allow running that command without authentication. I believe we could do this with all binaries, though there may be some issues I'm not yet aware of yet. In the longer term I'm not sure if we would want to individually replace setuid binaries with IPC-performing commands. The only real benefit is maybe elegance... Does this plan makes sense in the context of GuixSD? Am I leaving out anything? Thanks! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-23 15:17 Providing an alternative to setuid in GuixSD sbaugh @ 2016-10-24 0:09 ` Chris Marusich 2016-10-24 22:01 ` sbaugh 2016-10-26 12:24 ` Ludovic Courtès 1 sibling, 1 reply; 9+ messages in thread From: Chris Marusich @ 2016-10-24 0:09 UTC (permalink / raw) To: sbaugh; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 5025 bytes --] Hi, I don't think I have all the answers, but this is an interesting topic, so I'll chime in with what I can. I'm sure others will have more thoughts to share, too. sbaugh@catern.com writes: > 1. Each binary is an attack surface which is frequently exploited by > attackers for local privilege escalation. So getting rid of them > would improve security. > > 2. setuid binaries make access control decisions in an environment > controlled by the user running them, by looking at files at absolute > paths in that environment, such as /etc/passwd. Thus, if unprivileged > users had access to chroot or other filesystem namespacing > functionality, those users could escalate privileges by manipulating > /etc/passwd, /etc/shadow, /etc/sudoers, and then running a setuid > binary. So unprivileged chroot is not possible. When you say "filesystem namespacing functionality," are you referring to the Linux feature known as "user namespaces"? There is an article on LWN that discusses some of the security issues surrounding this: Filesystem mounts in user namespaces https://lwn.net/Articles/652468/ I admittedly don't know a lot about this feature, but it sounds like it is not currently designed to let a user escalate privilege in a way that would enable malicious modification of system files such as /etc/passwd. Can you clarify your second concern a little more to help me understand? You might already know, but there appears to be prior work on the general topic of eliminating setuid programs. For example, see the following paper, which surveys some of the programs and problems, and even proposes a solution they call "Protego": Practical Techniques to Obviate Setuid-to-Root Binaries https://www3.cs.stonybrook.edu/%7Eporter/pubs/jain-setuid.pdf > Issue 2 is a matter near and dear to our hearts here in guix-land, and > is my primary motivation. My understanding is that if we eliminated > all setuid binaries, we could with some confidence begin to allow > unprivileged access to chroot/filesystem namespaces, without first > going through user namespaces (which have their own issues). Please > correct me if you believe this is wrong. > > Unprivileged access to chroot would of course greatly aid unprivileged > installation of guix. It would be nice if the Guix daemon could create chroots for building packages even when it runs as a non-privileged user. That is definitely a limitation (see the comment about "--disable-chroot" in (guix) Build Environment Setup). However, I don't understand how eliminating setuid binaries would enable unprivileged access to root. Can you clarify why the latter follows from the former? > == How to do it == > > Most (all?) setuid binaries can be replaced with a non-setuid binary > which performs local IPC to a privileged daemon. > > The largest targets for elimination are sudo and su. Luckily there is > already a ready alternative for those commands: ssh. We can augment lsh > with the rich access controls of sudo, add any extra missing features, > and then replace sudo/su with wrappers around ssh. (A wrapper would be > needed just for sheer familiarity of the system to a user.) sshd runs > and performs access controls in a fixed environment, so this is not > vulnerable to the chroot attack I mentioned above. > > Once we have a solid replacement for sudo, we can take a generic > approach to eliminating other setuid binaries: just replace them with > wrappers which call 'sudo command "$@"', and make sure the > sudo-replacement is appropriately configured to allow running that > command without authentication. > > I believe we could do this with all binaries, though there may be some > issues I'm not yet aware of yet. > > In the longer term I'm not sure if we would want to individually > replace setuid binaries with IPC-performing commands. The only real > benefit is maybe elegance... That's an interesting idea. Some questions come to mind: * How would we allow one user to run a program as a different user? * How would we allow a user to update their own entries in shared databases like /etc/passwd? * Could this approach work with any kernel, not just Linux? * Because the daemon must have enough privileges to take any potential action that might be requested, does this solution fail to enforce the principle of least privilege in basically the same way that many setuid programs do (because they start with more privileges than they need)? * Do you know of any prior art in this area which is similar to what you are proposing? I saw some interesting-looking references in the Protego paper linked above, but I didn't go down the rabbit hole. For what it's worth, the Nix/NixOS people have not (to my knowledge) solved this problem, either. They didn't mention any setuid alternatives in any of the papers I checked here: http://nixos.org/docs/papers.html Best regards, -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-24 0:09 ` Chris Marusich @ 2016-10-24 22:01 ` sbaugh 0 siblings, 0 replies; 9+ messages in thread From: sbaugh @ 2016-10-24 22:01 UTC (permalink / raw) To: guix-devel Chris Marusich <cmmarusich@gmail.com> writes: > Hi, > > I don't think I have all the answers, but this is an interesting topic, > so I'll chime in with what I can. I'm sure others will have more > thoughts to share, too. > > sbaugh@catern.com writes: > >> 1. Each binary is an attack surface which is frequently exploited by >> attackers for local privilege escalation. So getting rid of them >> would improve security. >> >> 2. setuid binaries make access control decisions in an environment >> controlled by the user running them, by looking at files at absolute >> paths in that environment, such as /etc/passwd. Thus, if unprivileged >> users had access to chroot or other filesystem namespacing >> functionality, those users could escalate privileges by manipulating >> /etc/passwd, /etc/shadow, /etc/sudoers, and then running a setuid >> binary. So unprivileged chroot is not possible. > > When you say "filesystem namespacing functionality," are you referring > to the Linux feature known as "user namespaces"? I was referring to things which correspond ~directly to chroot, like mount namespaces or Plan 9 namespaces. But it's best to just consider chroot I think. The vulnerability is most clear when chroot is unprivileged, but it is present in any system with setuid binaries and the ability to perform non-trivial filesystem namespace manipulations without privileges. (In particular, to change what the root directory points to) Given chroot, all you need to do is: 1. Create your own filesystem tree with your own /etc/passwd and /etc/shadow which specifies a known password for root. 2. Chroot into that filesystem tree 3. Run su and provide the known password for root; it will check the password against the /etc/shadow that you created. 4. Escape the chroot. Once you have root in the chroot, there are many mechanisms for doing this. For example, create a device file corresponding to the real root fs, mount it, and chroot again there. 5. Enjoy your new root privileges in the main filesystem namespace. > There is an article on LWN that discusses some of the security issues > surrounding this: > > Filesystem mounts in user namespaces > https://lwn.net/Articles/652468/ > > I admittedly don't know a lot about this feature, but it sounds like it > is not currently designed to let a user escalate privilege in a way that > would enable malicious modification of system files such as /etc/passwd. > Can you clarify your second concern a little more to help me understand? That's partially correct; user namespaces would not allow modification of the "real" /etc/passwd, but they would allow you to create a mount namespace where you can put whatever file you want in place of /etc/passwd. In fact, you could get up to step 4 of the above attack. But then you would be stuck: You are not supposed to be able to escape a user namespace even with root, and while you are still inside a user namespace your privileges don't mean anything. So, user namespaces provide an alternative solution. But they also independently expose quite a large attack surface, and I am not really optimistic about them being accessible unprivileged in any mainstream distro any time soon... I am much more optimistic about the project of eliminating setuid binaries and thereby allowing "plain old chroot" to be safely done without privileges. This would only allow an a small subset of the functionality of user namespaces, but it would be enough for a lot of applications. > It would be nice if the Guix daemon could create chroots for building > packages even when it runs as a non-privileged user. That is definitely > a limitation (see the comment about "--disable-chroot" in (guix) Build > Environment Setup). However, I don't understand how eliminating setuid > binaries would enable unprivileged access to root. Can you clarify why > the latter follows from the former? Eliminating setuid binaries means step 3 in the above attack outline is not possible. A distribution without setuid binaries could therefore safely turn on unprivileged access to chroot. >> == How to do it == >> >> Most (all?) setuid binaries can be replaced with a non-setuid binary >> which performs local IPC to a privileged daemon. >> >> The largest targets for elimination are sudo and su. Luckily there is >> already a ready alternative for those commands: ssh. We can augment lsh >> with the rich access controls of sudo, add any extra missing features, >> and then replace sudo/su with wrappers around ssh. (A wrapper would be >> needed just for sheer familiarity of the system to a user.) sshd runs >> and performs access controls in a fixed environment, so this is not >> vulnerable to the chroot attack I mentioned above. >> >> Once we have a solid replacement for sudo, we can take a generic >> approach to eliminating other setuid binaries: just replace them with >> wrappers which call 'sudo command "$@"', and make sure the >> sudo-replacement is appropriately configured to allow running that >> command without authentication. >> >> I believe we could do this with all binaries, though there may be some >> issues I'm not yet aware of yet. >> >> In the longer term I'm not sure if we would want to individually >> replace setuid binaries with IPC-performing commands. The only real >> benefit is maybe elegance... > > That's an interesting idea. Some questions come to mind: > > * How would we allow one user to run a program as a different user? Well, if user A can authenticate as user B, they certainly can also run a program as user B through normal ssh-like means. So I assume you mean allowing user A to run a program as user B only by authenticating as user A. I believe that can be achieved with some ssh tricks. (I've done just this with ssh and Kerberos principals before; I believe you could do the same with ssh and Unix authentication but I haven't thought about it in much detail so I'm waving my hands a bit here) > * How would we allow a user to update their own entries in shared > databases like /etc/passwd? Through IPC to a privileged process: The "passwd" tool, as an example, could simply send a message providing the new password to a daemon privileged to perform the actual update. Alternatively for case of passwd specifically, we could use the tcb framework of Openwall: http://www.openwall.com/tcb/ Which is a somewhat more elegant trick, but may be more work and less compatible. (I'm also not sure that it works with absolutely all PAM modules; there could be some besides the basic files authentication which anticipate running as root. But I don't know for sure.) > * Could this approach work with any kernel, not just Linux? Definitely. As described currently it's totally kernel-independent. At some point, file-descriptor-passing-over-Unix-sockets might be useful. That would add a very small amount of kernel-dependence as that is sometimes available in different ways on different Unix kernels. (But it is still generally available.) > * Because the daemon must have enough privileges to take any potential > action that might be requested, does this solution fail to enforce the > principle of least privilege in basically the same way that many setuid > programs do (because they start with more privileges than they need)? Yes. However, it's a big advance over setuid, because the daemon runs in a fixed environment, rather than running in an environment entirely controlled by an unprivileged user. And that is enough of an improvement to get big benefits, namely, safe unprivileged chroot. > * Do you know of any prior art in this area which is similar to what you > are proposing? I saw some interesting-looking references in the Protego > paper linked above, but I didn't go down the rabbit hole. Yes, there is some pre-existing software which is directly relevant: - s6-sudod, which is explicitly for this purpose: http://skarnet.org/software/s6/s6-sudod.html - remctl, which is much older but could be usable for this purpose: https://www.eyrie.org/~eagle/software/remctl/ - systemd's machinectl has a "shell" subcommand for getting a shell in containers running on the local host, or on the local host itself: https://www.freedesktop.org/software/systemd/man/machinectl.html I don't know of any Unix/Linux distributions that really use this approach. There's some similarity to Plan 9; Plan 9 has unprivileged namespacing in part because it doesn't have setuid. Of course, Guix is also an example of this IPC-to-privileged-action approach: To perform the privileged action of isolating our builds, we perform IPC to another more privileged process which does it for us. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-23 15:17 Providing an alternative to setuid in GuixSD sbaugh 2016-10-24 0:09 ` Chris Marusich @ 2016-10-26 12:24 ` Ludovic Courtès 2016-10-26 14:40 ` sbaugh 2016-10-26 17:52 ` Christopher Allan Webber 1 sibling, 2 replies; 9+ messages in thread From: Ludovic Courtès @ 2016-10-26 12:24 UTC (permalink / raw) To: sbaugh; +Cc: guix-devel Hello! sbaugh@catern.com skribis: > == Why remove setuid binaries? == > > setuid binaries are problematic for two reasons: > > 1. Each binary is an attack surface which is frequently exploited by > attackers for local privilege escalation. So getting rid of them > would improve security. > > 2. setuid binaries make access control decisions in an environment > controlled by the user running them, by looking at files at absolute > paths in that environment, such as /etc/passwd. Thus, if unprivileged > users had access to chroot or other filesystem namespacing > functionality, those users could escalate privileges by manipulating > /etc/passwd, /etc/shadow, /etc/sudoers, and then running a setuid > binary. So unprivileged chroot is not possible. > > Issue 2 is a matter near and dear to our hearts here in guix-land, and > is my primary motivation. My understanding is that if we eliminated > all setuid binaries, we could with some confidence begin to allow > unprivileged access to chroot/filesystem namespaces, without first > going through user namespaces (which have their own issues). Please > correct me if you believe this is wrong. > > Unprivileged access to chroot would of course greatly aid unprivileged > installation of guix. Well, the kernel Linux will forever support setuid binaries and thus, most likely, chroot(2) will forever be restricted to root. So I think removing setuid binaries on GuixSD is helpful for GuixSD itself, but not for other distros (at least not directly so). > 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. :-) > == How to do it == > > Most (all?) setuid binaries can be replaced with a non-setuid binary > which performs local IPC to a privileged daemon. > > 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. > Does this plan makes sense in the context of GuixSD? Am I leaving out > anything? I don’t know, I’m skeptical! :-) However, I agree that GuixSD has more latitude as to how it deals with privileges, notably because the set of users, setuid binaries, and other relevant bits is all described in ‘operating-system’. Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-26 12:24 ` Ludovic Courtès @ 2016-10-26 14:40 ` sbaugh 2016-10-28 13:34 ` Ludovic Courtès 2016-10-26 17:52 ` Christopher Allan Webber 1 sibling, 1 reply; 9+ messages in thread From: sbaugh @ 2016-10-26 14:40 UTC (permalink / raw) To: guix-devel ludo@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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-26 14:40 ` sbaugh @ 2016-10-28 13:34 ` Ludovic Courtès 2016-10-29 21:41 ` sbaugh 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2016-10-28 13:34 UTC (permalink / raw) To: sbaugh; +Cc: guix-devel Hi! sbaugh@catern.com skribis: > ludo@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’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-28 13:34 ` Ludovic Courtès @ 2016-10-29 21:41 ` sbaugh 0 siblings, 0 replies; 9+ messages in thread From: sbaugh @ 2016-10-29 21:41 UTC (permalink / raw) To: guix-devel ludo@gnu.org (Ludovic Courtès) writes: > 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. Well, I am slightly more optimistic than that. It may be that this solution is such a success that other distros emulate us. :) But, yes, there is no clear path for this work to be used by anything but GuixSD (and NixOS). I think that is fine; we should not fear to innovate. > 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”. Yes. > Item #2 is already possible, but it doesn’t look “better” to me that > setuid programs from a security or configuration viewpoint. Right, item #2 is only useful when it allows actually getting to the 0-setuid-binaries state; that is, item #2 requires that item #1 has already been achieved to be useful. > Namespaces look like an improvement to me. If you want something less > hacky, there’s always the Hurd. ;-) They're definitely an improvement. Don't get me wrong, I am absolutely excited about user namespaces. But they have a lot of drawbacks. They expose a huge amount of formerly-privileged APIs to unprivileged processes, causing security problems. They require system-wide configuration and allocation of uids for the UID mapping. Working across multiple namespaces isn't possible and if it ever is possible it will probably require making the whole thing even more complicated. And finally it's just rather weird to have to create a different user namespace, gain pseudo-root, and execute syscalls using fake capabilities just to manipulate your view of the filesystem. Indeed I prefer the Hurd here. :) If we get rid of setuid binaries in userspace, these kernel APIs can be redesigned in a simpler and more powerful way. To improve the GNU/Linux system we can't just rely on kernel development: We must also develop userspace to open up paths forward. >> 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? I don't want to prescribe any specific set of features. Unprivileged chroot or equivalent, without having to first go through user namespaces, would be a start. In combination with unprivilegd bind mounts it would give us quite a lot of what we need. If I had to be specific about features, I would say that it would be nice to port an API like Plan 9 namespaces to Linux. (Hurd-like features would also be acceptable.) Perhaps this is overly optimistic. > Polkit has its own sudo-like program, ‘pkexec’, that works by talking to > the polkit daemon over D-Bus. I've investigated this. pkexec requires being setuid: it only does authentication with polkit; it actually runs things just like sudo, by setreuid and exec, rather than telling a daemon to run it. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-26 12:24 ` Ludovic Courtès 2016-10-26 14:40 ` sbaugh @ 2016-10-26 17:52 ` Christopher Allan Webber 2016-10-26 18:34 ` sbaugh 1 sibling, 1 reply; 9+ messages in thread From: Christopher Allan Webber @ 2016-10-26 17:52 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, sbaugh Ludovic Courtès writes: > 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. I agree. We could maybe have a pseudo-sudo service that is built just for this purpose though... let's call it "psudo". ;) Thinking out loud: So, you're running psudo, and this thing maybe accepts connections over something more secure, *maybe* unix domain sockets... so restrict group access to the socket to users in the "psudo" group. From there, maybe it could require PAM authentication while entering the root password, or something. It feels hard to know how psudo could "know" what user is accessing the socket... I don't think that information is made available, right? Maybe I'm wrong! I guess postgres and etc do similar things? Fun idea to think about anyway :) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Providing an alternative to setuid in GuixSD 2016-10-26 17:52 ` Christopher Allan Webber @ 2016-10-26 18:34 ` sbaugh 0 siblings, 0 replies; 9+ messages in thread From: sbaugh @ 2016-10-26 18:34 UTC (permalink / raw) To: guix-devel Christopher Allan Webber <cwebber@dustycloud.org> writes: > So, you're running psudo, and this thing maybe accepts connections over > something more secure, *maybe* unix domain sockets... so restrict group > access to the socket to users in the "psudo" group. > > From there, maybe it could require PAM authentication while entering the > root password, or something. > > It feels hard to know how psudo could "know" what user is accessing the > socket... I don't think that information is made available, right? > Maybe I'm wrong! I guess postgres and etc do similar things? On Linux, there is SCM_CREDENTIALS (and similar stuff on BSDs). From Linux unix(7): SCM_CREDENTIALS Send or receive UNIX credentials. This can be used for authentication. The credentials are passed as a struct ucred ancillary message. Thus structure is defined in <sys/socket.h> as follows: struct ucred { pid_t pid; /* process ID of the sending process */ uid_t uid; /* user ID of the sending process */ gid_t gid; /* group ID of the sending process */ }; Moreover there is the Polkit (ne PolicyKit) framework for this kind of stuff, which could provide a more high-level interface if we chose to use it. (GNOME uses it as does systemd) (Note that there is already pkexec (bundled with Polkit) which provides a sudo replacement with authentiation and policy through Polkit. But it's setuid for some reason. I haven't investigated why...) ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-10-29 21:42 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-23 15:17 Providing an alternative to setuid in GuixSD sbaugh 2016-10-24 0:09 ` Chris Marusich 2016-10-24 22:01 ` sbaugh 2016-10-26 12:24 ` Ludovic Courtès 2016-10-26 14:40 ` sbaugh 2016-10-28 13:34 ` Ludovic Courtès 2016-10-29 21:41 ` sbaugh 2016-10-26 17:52 ` Christopher Allan Webber 2016-10-26 18:34 ` sbaugh
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).