-----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-security&r=1&b=201111&w=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= =BXhD -----END PGP SIGNATURE----- -- 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/4ec3bdcd.7040...@mikemestnik.net
