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] [day] [month] [year] [list]
Message-ID: <470A0359.5090008@aitel.hist.no>
Date:	Mon, 08 Oct 2007 12:15:53 +0200
From:	Helge Hafting <helge.hafting@...el.hist.no>
To:	gogi-k@...i.tv
CC:	linux-kernel@...r.kernel.org
Subject: 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 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ