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
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.
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.
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.
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.
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.
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
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
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.
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
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