linux-kernel - Re: One process with multiple user ids.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 02 Oct 2007 13:11:41 -0400
From:	Chris Snook <csnook@...hat.com>
To:	gogi-k@...i.tv
CC:	linux-kernel@...r.kernel.org
Subject: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/