Re: One process with multiple user ids.
Giuliano Gagliardi wrote: On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. Why exactly do you need to change UID to a predefined set? Do your app need to work with files owned by those users perhaps? If so, consider filesystem solutions: * make a group with all these users in, make the files rw for this group or * Use ACLs and let whatever UID your process use, have access to the files in question. Another approach if filesystem tricks don't fit your need: Have a small process running as root. It should not do much io or data processing, so its source is small and easy to audit. You can make reasonably sure it has no security holes. This minimal app will when needed: * fork, * set the correct UID for this particular job, * exec the app that do work that is so complicated that security holes might happen. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. Why exactly do you need to change UID to a predefined set? Do your app need to work with files owned by those users perhaps? If so, consider filesystem solutions: * make a group with all these users in, make the files rw for this group or * Use ACLs and let whatever UID your process use, have access to the files in question. Another approach if filesystem tricks don't fit your need: Have a small process running as root. It should not do much io or data processing, so its source is small and easy to audit. You can make reasonably sure it has no security holes. This minimal app will when needed: * fork, * set the correct UID for this particular job, * exec the app that do work that is so complicated that security holes might happen. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: Hello, I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. I have seen that two possible solutions have already been suggested here on the LKML, but it was some years ago, and nothing like it has been implemented. (1) Having supplementary user ids like there are supplementary group ids and system calls getuids() and setuids() that work like getgroups() and setgroups() (2) Allowing processes to pass user and group ids via sockets. Both (1) and (2) would solve my problem. Now my question is whether there are any fundamental flaws with (1) or (2), or whether the right way to solve my problem is another one. Changing to a limited set of IDs is interesting, I have never looked at what happens when a thread does setuid, and neither the man page or a very quick look at the code tells me. But the portable way is to do the things needed for init, then fork into three processes and give each a UID as needed. I would really evaluate the design which made this necessary, to see if some IPC could be used. Certainly that's more likely to be portable. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. Why don't you use group security instead of user security; you already have supplemental group id's. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: Hello, I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. Well, it's probably going to have to *start* as root, or use something like sudo. It's probably easiest to have it start as root and drop privileges as soon as possible, certainly before handling any untrusted data. > I only need the server to be able to switch to certain pre-defined user ids. This is a very easy special case. Just start a process for each user ID and drop root privileges. They can communicate via sockets or even shared memory. If you wanted to switch between arbitrary UIDs at runtime, it might be worth doing something exotic, but it's really not in this case. Also, if you do it this way, it's rather easy to verify the correctness of your design, and you never have to touch kernel code. I have seen that two possible solutions have already been suggested here on the LKML, but it was some years ago, and nothing like it has been implemented. (1) Having supplementary user ids like there are supplementary group ids and system calls getuids() and setuids() that work like getgroups() and setgroups() But you can already accomplish this with ACLs and SELinux. You're trying to make this problem harder than it really is. (2) Allowing processes to pass user and group ids via sockets. And do what with them? You can already pass arbitrary data via sockets. It sounds like you need (1) to use (2). Both (1) and (2) would solve my problem. Now my question is whether there are any fundamental flaws with (1) or (2), or whether the right way to solve my problem is another one. (1) doesn't accomplish anything you can't already do, but it would make a huge mess of a lot of code. (2) is silly. Sockets are for communicating between userspace processes. If you want to be granting/revoking credentials, you should be using system calls, and even then only if you absolutely must. Having the kernel snoop traffic on sockets between processes would be disastrous for performance, and without that, any process could claim that it had been granted privileges over a socket and the kernel would just have to trust it. Don't overthink this. You don't need to touch the kernel at all to do this. Just use a multi-process model, like qmail does, for example. You can start with root privileges and drop them, or use sudo to help you out. It's fast, secure, takes advantage of modern multi-core CPUs, and is much simpler. -- Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. It really sounds like the app should be restructured. If security is that important to it, then it shouldn't be changing uids back and forth on the fly (too risky). There's probably a nice redesign possible where it just forks off 3 sub-processes, one for each UID, and then farms out the work to each as required. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Oct 2 2007 13:39, Giuliano Gagliardi wrote: >> >> You could write up a LSM that restricts UID changing. > >Would you not consider it more useful to let one process have multiple user >ids? I do not see why they can have multiple group ids, but only (and >exactly) three user ids. It would raise the complexity enormously. In the kernel, you currently do if (current->uid == inode->i_uid) or so. If you were to have multiple identities, that would evolve into a costly "if (in_user_p(inode->i_uid))" or so, much like in_group_p does it at the moment. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Tuesday 02 October 2007, Jan Engelhardt wrote: > On Oct 2 2007 13:33, Giuliano Gagliardi wrote: > >Date: Tue, 2 Oct 2007 13:33:05 +0200 > >From: Giuliano Gagliardi <[EMAIL PROTECTED]> > >To: Jan Engelhardt <[EMAIL PROTECTED]> > >Subject: Re: One process with multiple user ids. > > > >On Tuesday 02 October 2007, Jan Engelhardt wrote: > >> On Oct 2 2007 12:56, Giuliano Gagliardi wrote: > >> >I have a server that has to switch to different user ids, but because > >> > it does other complex things, I would rather not have it run as root. > >> > I only need the server to be able to switch to certain pre-defined > >> > user ids. > >> > >> All you need is CAP_SETUID. Also see man setresuid, > >> where you could, I think, use saved_uid=0 if you do not > >> like to use real_uid=0 effective_uid=non-0. > > > >But CAP_SETUID would let me change to any uid, would it not? I would like > > my process to have no possibility to change to any uid, except some > > predefined set, so that in case of a security hole only those uids could > > be compromised. > > You could write up a LSM that restricts UID changing. Would you not consider it more useful to let one process have multiple user ids? I do not see why they can have multiple group ids, but only (and exactly) three user ids. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Tuesday 02 October 2007, Jan Engelhardt wrote: > On Oct 2 2007 12:56, Giuliano Gagliardi wrote: > >I have a server that has to switch to different user ids, but because it > > does other complex things, I would rather not have it run as root. I only > > need the server to be able to switch to certain pre-defined user ids. > > All you need is CAP_SETUID. Also see man setresuid, > where you could, I think, use saved_uid=0 if you do not > like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Oct 2 2007 13:33, Giuliano Gagliardi wrote: >Date: Tue, 2 Oct 2007 13:33:05 +0200 >From: Giuliano Gagliardi <[EMAIL PROTECTED]> >To: Jan Engelhardt <[EMAIL PROTECTED]> >Subject: Re: One process with multiple user ids. > >On Tuesday 02 October 2007, Jan Engelhardt wrote: >> On Oct 2 2007 12:56, Giuliano Gagliardi wrote: >> >I have a server that has to switch to different user ids, but because it >> > does other complex things, I would rather not have it run as root. I only >> > need the server to be able to switch to certain pre-defined user ids. >> >> All you need is CAP_SETUID. Also see man setresuid, >> where you could, I think, use saved_uid=0 if you do not >> like to use real_uid=0 effective_uid=non-0. > >But CAP_SETUID would let me change to any uid, would it not? I would like my >process to have no possibility to change to any uid, except some predefined >set, so that in case of a security hole only those uids could be compromised. > > You could write up a LSM that restricts UID changing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Oct 2 2007 12:56, Giuliano Gagliardi wrote: > >I have a server that has to switch to different user ids, but because it does >other complex things, I would rather not have it run as root. I only need the >server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
One process with multiple user ids.
Hello, I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. I have seen that two possible solutions have already been suggested here on the LKML, but it was some years ago, and nothing like it has been implemented. (1) Having supplementary user ids like there are supplementary group ids and system calls getuids() and setuids() that work like getgroups() and setgroups() (2) Allowing processes to pass user and group ids via sockets. Both (1) and (2) would solve my problem. Now my question is whether there are any fundamental flaws with (1) or (2), or whether the right way to solve my problem is another one. Giuliano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
One process with multiple user ids.
Hello, I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. I have seen that two possible solutions have already been suggested here on the LKML, but it was some years ago, and nothing like it has been implemented. (1) Having supplementary user ids like there are supplementary group ids and system calls getuids() and setuids() that work like getgroups() and setgroups() (2) Allowing processes to pass user and group ids via sockets. Both (1) and (2) would solve my problem. Now my question is whether there are any fundamental flaws with (1) or (2), or whether the right way to solve my problem is another one. Giuliano - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Oct 2 2007 13:33, Giuliano Gagliardi wrote: Date: Tue, 2 Oct 2007 13:33:05 +0200 From: Giuliano Gagliardi [EMAIL PROTECTED] To: Jan Engelhardt [EMAIL PROTECTED] Subject: Re: One process with multiple user ids. On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. You could write up a LSM that restricts UID changing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 13:33, Giuliano Gagliardi wrote: Date: Tue, 2 Oct 2007 13:33:05 +0200 From: Giuliano Gagliardi [EMAIL PROTECTED] To: Jan Engelhardt [EMAIL PROTECTED] Subject: Re: One process with multiple user ids. On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. You could write up a LSM that restricts UID changing. Would you not consider it more useful to let one process have multiple user ids? I do not see why they can have multiple group ids, but only (and exactly) three user ids. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
On Oct 2 2007 13:39, Giuliano Gagliardi wrote: You could write up a LSM that restricts UID changing. Would you not consider it more useful to let one process have multiple user ids? I do not see why they can have multiple group ids, but only (and exactly) three user ids. It would raise the complexity enormously. In the kernel, you currently do if (current-uid == inode-i_uid) or so. If you were to have multiple identities, that would evolve into a costly if (in_user_p(inode-i_uid)) or so, much like in_group_p does it at the moment. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: On Tuesday 02 October 2007, Jan Engelhardt wrote: On Oct 2 2007 12:56, Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. All you need is CAP_SETUID. Also see man setresuid, where you could, I think, use saved_uid=0 if you do not like to use real_uid=0 effective_uid=non-0. But CAP_SETUID would let me change to any uid, would it not? I would like my process to have no possibility to change to any uid, except some predefined set, so that in case of a security hole only those uids could be compromised. It really sounds like the app should be restructured. If security is that important to it, then it shouldn't be changing uids back and forth on the fly (too risky). There's probably a nice redesign possible where it just forks off 3 sub-processes, one for each UID, and then farms out the work to each as required. Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: Hello, I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. Well, it's probably going to have to *start* as root, or use something like sudo. It's probably easiest to have it start as root and drop privileges as soon as possible, certainly before handling any untrusted data. I only need the server to be able to switch to certain pre-defined user ids. This is a very easy special case. Just start a process for each user ID and drop root privileges. They can communicate via sockets or even shared memory. If you wanted to switch between arbitrary UIDs at runtime, it might be worth doing something exotic, but it's really not in this case. Also, if you do it this way, it's rather easy to verify the correctness of your design, and you never have to touch kernel code. I have seen that two possible solutions have already been suggested here on the LKML, but it was some years ago, and nothing like it has been implemented. (1) Having supplementary user ids like there are supplementary group ids and system calls getuids() and setuids() that work like getgroups() and setgroups() But you can already accomplish this with ACLs and SELinux. You're trying to make this problem harder than it really is. (2) Allowing processes to pass user and group ids via sockets. And do what with them? You can already pass arbitrary data via sockets. It sounds like you need (1) to use (2). Both (1) and (2) would solve my problem. Now my question is whether there are any fundamental flaws with (1) or (2), or whether the right way to solve my problem is another one. (1) doesn't accomplish anything you can't already do, but it would make a huge mess of a lot of code. (2) is silly. Sockets are for communicating between userspace processes. If you want to be granting/revoking credentials, you should be using system calls, and even then only if you absolutely must. Having the kernel snoop traffic on sockets between processes would be disastrous for performance, and without that, any process could claim that it had been granted privileges over a socket and the kernel would just have to trust it. Don't overthink this. You don't need to touch the kernel at all to do this. Just use a multi-process model, like qmail does, for example. You can start with root privileges and drop them, or use sudo to help you out. It's fast, secure, takes advantage of modern multi-core CPUs, and is much simpler. -- Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. Why don't you use group security instead of user security; you already have supplemental group id's. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: Hello, I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. I have seen that two possible solutions have already been suggested here on the LKML, but it was some years ago, and nothing like it has been implemented. (1) Having supplementary user ids like there are supplementary group ids and system calls getuids() and setuids() that work like getgroups() and setgroups() (2) Allowing processes to pass user and group ids via sockets. Both (1) and (2) would solve my problem. Now my question is whether there are any fundamental flaws with (1) or (2), or whether the right way to solve my problem is another one. Changing to a limited set of IDs is interesting, I have never looked at what happens when a thread does setuid, and neither the man page or a very quick look at the code tells me. But the portable way is to do the things needed for init, then fork into three processes and give each a UID as needed. I would really evaluate the design which made this necessary, to see if some IPC could be used. Certainly that's more likely to be portable. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
