One process with multiple user ids.

One process with multiple user ids.

[Giuliano Gagliardi]

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

Re: One process with multiple user ids.

[Jan Engelhardt]

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.

Re: One process with multiple user ids.

[Jan Engelhardt]

On Oct 2 2007 13:33, Giuliano Gagliardi wrote:

>Date: Tue, 2 Oct 2007 13:33:05 +0200
>From: Giuliano Gagliardi <gogi-k@gogi.tv>
>To: Jan Engelhardt <jengelh@computergmbh.de>
>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.

Re: One process with multiple user ids.

[Giuliano Gagliardi]

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 <gogi-k@gogi.tv>
> >To: Jan Engelhardt <jengelh@computergmbh.de>
> >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.

Re: One process with multiple user ids.

[Jan Engelhardt]

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.

Re: One process with multiple user ids.

[Giuliano Gagliardi]

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.

Re: One process with multiple user ids.

[Mark Lord]

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

Re: One process with multiple user ids.

[Helge Hafting]

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

Re: One process with multiple user ids.

[Chris Snook]

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

Re: One process with multiple user ids.

[David Newall]

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.

Re: One process with multiple user ids.

[Bill Davidsen]

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot