Date: Thu, 1 May 2014 07:30:32 +0400 From: Solar Designer <solar@...nwall.com> To: Steve Grubb <sgrubb@...hat.com> Cc: oss-security@...ts.openwall.com Subject: Re: local privilege escalation due to capng_lock as used in seunshare On Wed, Apr 30, 2014 at 11:55:31AM -0400, Steve Grubb wrote: > In my opinion, the issue is that I think SECURE_NOROOT doesn't get its > semantics right as is. I'm thinking if noroot is set and cap_setuid is set, > suid should be as normal but with no capabilities. If noroot is set and > cap_setuid is unset, no transition of any uid should occur. If noroot is > unset, then works as normal. Of the three cases above, only the "noroot is set and cap_setuid is unset" case currently has semantics different from what you propose, and the rest are already as you described, correct? Is my understanding correct that setuid(2)'s "appropriate privileges" end up being altered via lacking CAP_SETUID, even though we do gain UID 0 during the SUID root exec? This appears consistent with the code. If so, we may either prevent this combination of settings from occurring (in the way you describe or otherwise) or maybe we should fix setuid(2) (and a few others?) to treat the lack of CAP_SETUID differently. IIRC, the "sendmail bug" was fixed in the kernel by requiring privileges to drop capabilities, so an attacker wouldn't simply drop CAP_SETUID. Your proposed change is in line with that, but the behavior feels hackish and unexpected. That said, Linux 2.4+ already set the precedent of ignoring SUID/SGID in some cases, yet proceeding with exec, so it won't be a new bad thing (rather, more of the moderately old bad thing). Sorry for so many messages. It's been years since I looked at this code closely, so it takes a while to recall what it's about. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ