Re: Fwd: Problem with multiple root-users (UID=0)
On Wed, 16 Nov 2011, Ritesh Raj Sarraf r...@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 tho...@weichert-web.de
Reply-To: open-is...@googlegroups.com
To: open-iscsi open-is...@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)) {
err = MGMT_IPC_ERR_ACCESS;
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
iscsi.
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
getpwuid_r()).
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 Bloghttp://doc.coker.com.au/
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20161929.49953.russ...@coker.com.au
Re: Fwd: Problem with multiple root-users (UID=0)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/16/11 00:13, Ritesh Raj Sarraf wrote:
Hello Mike,
Yes, That'd be debian-security@lists.debian.org, Cced with this email.
Ritesh
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
Did you catch (russ...@coker.com.au)'s reply?
http://173.79.223.25/?l=debian-securityr=1b=20w=2 Not posted
yet, but it should eventually show up here.
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 tho...@weichert-web.de
Reply-To: open-is...@googlegroups.com
To: open-iscsi open-is...@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)) {
err = MGMT_IPC_ERR_ACCESS;
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.
I think you will find that the gentent command more closely matches what
a C/C++ application would see.
It's defiantly erroneous to assume that UID(0)=='root', I can just tell
that some day PCI auditors will insist that any account called 'root'
must not be UID0 if the account exists at all.
I'm not sure what the above code is getting at. As russell pointed out
UID0 does not always mean the same as Has access to every thing. It
would be more appropriate to create an iscsiadm group and use this to
control access instead, AKL the wheel and sudo groups... However access
to a service IMHO should be controlled with authentication, not ownership.
If instead these checks are done to prevent a future operation from
failing on a permission issue, then it sounds like the test is causing
more problems then removing them *should*. The application should
already gracefully handle any failure, so attempting to pre-discover a
permission issue should generate/assert a warning and not an error.
Thus I'm writing this email to say that your whole question sounds like
it's barking up a tree full of some fairly nasty security issues.
Either it's being to open to grant access based on UID/GID with out
further identifying the user issuing the request as a proper
authentication scheme should, keep in mind that SELINUX would have no
way of limiting access to a service like this and there could be code
run under UID0/SELINUX that's insecure. On the other hand if the code
dosn't gracefully handle failure this could also be used in a privilege
escalation attack. That covers all the reasons for code like the above
that I can think of, though there is still room for something else to be
going on. In the latter case you should be able to safely change the
result of failure here to printing a message indecating so and then
continue as though it passed, or just remove it completely. In the
former case it should be replaced with something else entirely, though
it could be left as to further limit access beyond what authentication
would do.
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. 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.
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?
Thanks a lot
Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOw73NAAoJEEGHzDDLDhle8XcH/R/qsQpGjXuK3rcY8rYBRJC/
HOYz3lx067kcjfH0TmXFQcZtsAzqjsDxdH4HlQ8TBuA20oSUMh9fbSqN2icLY4Y5
bDSZHChezWHOPH83G1yns4kCnCagOHDWYc7gHZcRTHkh/qALP90Ce1kXFyp1e1xR
OqVL0l7EXGmshcUQhF1eCweEZBPXSpfJpFHF46OpUrnwmwgq2mdxAD5RhiGQ5qVW
R/G0QatW338ti+0KTwhEx8VMOqw96+ftgx5DL/MV15dWD65PLjtaacEGStVWjTT1
iRxTBwAuBNwIXGkteDwFmca8vFN8VoQ/b/XUtkGk2XkwxysepShhpFs9qXhfAe8=
Re: Fwd: Problem with multiple root-users (UID=0)
Hello Mike,
Yes, That'd be debian-security@lists.debian.org, Cced with this email.
Ritesh
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 tho...@weichert-web.de
Reply-To: open-is...@googlegroups.com
To: open-iscsi open-is...@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)) {
err = MGMT_IPC_ERR_ACCESS;
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. 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.
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?
Thanks a lot
Thomas
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
