[Bug 1310092] Review Request: cryptobone - Secure Communication Under Your Control

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

 



https://bugzilla.redhat.com/show_bug.cgi?id=1310092



--- Comment #23 from Ralf Senderek <fedora@xxxxxxxxxxx> ---
(In reply to Richard Shaw from comment #21)
> Package Review

My analysis of the RPMLINT-issue:
  This executable is calling setuid and setgid without setgroups or initgroups.
  There is a high probability this means it didn't relinquish all groups, and
  this would be a potential security issue to be fixed. Seek POS36-C on the web
  for details about the problem.

The problem is described in the following URL:
https://www.securecoding.cert.org/confluence/display/c/POS36C.+Observe+correct+revocation+order+while+relinquishing+privileges

The relevant part of the source code file "random/unix.c" (lines 1258 and 1259)
uses setresuid to set all three uids (real, effective and saved) as __linux__
is set.
The author notes that dropping the privileges here occurs as a precautionary
measure.
I cannot see that there is any chance that there are supplementary groups set
that
will not be relinquished, so I don't see any reason to bother the author to
include
setgroups or initgroups to address this issue.


source code:
1215                 /* If we're root, give up our permissions to make sure
that we don't
1216                    inadvertently read anything sensitive.  If the
getpwnam() fails
1217                    (this can happen if we're chrooted with no "nobody"
entry in the
1218                    local passwd file) we default to -1, which is usually
nobody.
1219                    The newer setreXid() and setresXid() calls use a
parameter value
1220                    of -1 to indicate "don't change this value" so this
isn't
1221                    possible any longer, but then there's not really much
else that
1222                    we can do at this point.
1223 
1224                    We don't check whether the change succeeds since it's
not a major
1225                    security problem but just a precaution (in theory an
attacker
1226                    could do something like fork()ing until RLIMIT_NPROC is
reached,
1227                    at which point it'd fail, but that doesn't really give
them
1228                    anything) */
1229                 if( geteuid() == 0 )

1248                         if( gathererUID != ( uid_t ) -1 )
1249                                 {
1250 #if 0                   /* Not available on some OSes */
1251                                 ( void ) setuid( gathererUID );
1252                                 ( void ) seteuid( gathererUID );
1253                                 ( void ) setgid( gathererGID );
1254                                 ( void ) setegid( gathererGID );
1255 #else
1256   #if( defined( __linux__ ) || ( defined( __FreeBSD__ ) && OSVERSION >= 5
) || \
1257            ( defined( __hpux ) && OSVERSION >= 11 ) )
1258                                 ( void ) setresuid( gathererUID,
gathererUID, gathererUID );
1259                                 ( void ) setresgid( gathererGID,
gathererGID, gathererGID );
1260   #else
1261                                 ( void ) setreuid( gathererUID,
gathererUID );
1262                                 ( void ) setregid( gathererGID,
gathererGID );
1263   #endif /* OSses with setresXid() */
1264 #endif /* 0 */
1265                                 }
1266                         }

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review




[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]