[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: Problem with multiple root-users (UID=0)

On Wed, 16 Nov 2011, Ritesh Raj Sarraf <rrs@debian.org> wrote:
> On 11/16/2011 11:15 AM, Mike Christie wrote:
> > Hey Ritesh,
> > 
> > Does Debian have some sort of security list? I asked some red hat people
> > and they thought removing the check for "root" and just checking for
> > UID=0 would be ok. They were not 100% sure though since we could not
> > figure out why the original maintainers check explicitly for root. So I
> > have been checking with distro people to make sure it is ok with their
> > security people.
> > 
> > Thanks
> > 
> > Mike
> > 
> > 
> > 
> > 
> > -------- Original Message --------
> > Subject: Problem with multiple root-users (UID=0)
> > Date: Mon, 7 Nov 2011 11:37:29 -0800 (PST)
> > From: Thomas Weichert <thomas@weichert-web.de>
> > Reply-To: open-iscsi@googlegroups.com
> > To: open-iscsi <open-iscsi@googlegroups.com>
> > 
> > Hi,
> > 
> > in the last few days I encountered a problem on my SLES 11.1 Linux
> > with the open-iscsi package in version 2.0-871 respectively 0.872. I
> > investigated the problem and found out that in my system there are two
> > root users with uid = 0 (sadly, this is required). Therefore I digged
> > deeper and found out that the problem most probably lies in the two
> > code snippets where "root" is defnied explicitely. Those are usr/
> > mgmt_ipc.c around line 549 with:
> > 
> > if (!mgmt_peeruser(fd, user) || strncmp(user, "root", PEERUSER_MAX)) {
> > 
> > 	goto err;
> > 
> > }
> > 
> > as well as usr/statics.c around line 7:
> > 
> > static struct passwd root_pw = {
> > 
> >         .pw_name = "root",
> > 
> > }
> > 
> > When the Linux command `whoami` returns something different than
> > "root", open-iscsi will not work.
> > 
> > As far as I understand the issue, the function call to mgmt_peeruser()
> > in mgmt_ipc.c sets the variable user to the currently logged in user
> > name and then it is compared to "root".

From a casual examination of the code it appears that the UID of the other end 
of the Unix domain socket connection with file handle fd is looked up via 
getpwuid() and then compared to "root".  So the only way we determine that the 
other end has permission to do whatever it wants is that it's UID maps to the 
name "root", which generally means UID==0.

As long as the UID==0 account named something other than "root" appears later 
in /etc/passwd this should work as you desire.

Of course just allowing UID==0 to do sysadmin stuff isn't a great idea.  SE 
Linux is one of several security systems that give you processes with UID==0 
but significantly less privileges.  Any time you have code which ONLY checks 
for UID==0 you potentially have something that could be used as part of an 
exploit on a SE Linux system - although in such a case it would be an exploit 
on every system that only uses Unix permissions anyway.

It appears that the abstract socket namespace as described in unix(7) is being 
used, this doesn't use a path name and apparently uses no other security 
mechanisms.  Therefore I expect that if someone exploited a root owned process 
that is constrained by SE Linux or another security system then if it was 
permitted to establish Unix domain socket connections it could mess with your 

> > If my root-user is named
> > differently, the strncmp function fails of course. I did not
> > investigate the code in statics.c further, whether it plays a role or
> > not, since a change to mgmt_ipc.c solves my problem.

statics.c seems like a bad idea.  Replacing a libc function with something 
that provides a tiny sub-set of the functionality which is hard-coded in a way 
that may not match the rest of the system seems like a really bad idea.

> > Is there a chance to fix this issue just by checking if the user has
> > sufficient rights, e.g. has uid=0, or is there any special reason for
> > demanding a user named root?

Checking for uid==0 would be better than statics.c.  Also checking for uid==0 
would avoid potential threading issues (of course they could use 

But really something better than assuming that every uid==0 process has 
ultimate privilege is the way to go.

My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Reply to: