Re: __libc_enable_secure sgid to different own group

[Samuel Thibault]

Hello,

Pino Toscano, le Sat 27 Jun 2015 14:03:08 +0200, a écrit :
 $ groups
 users dialout [...]
 $ chown $(id -nu).dialout frob-gid
 $ chmod g+s frob-gid
 
 At this point, the output of frob-gid is 1 on Linux, while 0 on Hurd.

So the user was actually already part of the dialout group?

Then I'd say we indeed have no reason to set __libc_enable_secure to 1:
there is no privilege escalation here, so no reason to disable any
features (which is the consequence of __libc_enable_secure being 1)

 p11-kit uses __libc_enable_secure in its replacement for
 getauxval(AT_SECURE), falling back to issetugid (which we don't have)
 and then to getresuid (which we have).
 
 I don't have much knowledge in how this behaviour should be, so
 a) the current Hurd behaviour is fine and conformant, so p11-kit should
avoid using __libc_enable_secure for getauxval(AT_SECURE)

For me getauxval(AT_SECURE) should also return 0 in this case, since
there is no privilege escalation.

Samuel

__libc_enable_secure sgid to different own group

[Pino Toscano]

Hi,

While debugging p11-kit, I found out a different behaviour of
__libc_enable_secure between Linux and Hurd. In particular:

$ cat EOF frob-gid.c
#include stdio.h

int main(void)
{
  extern int __libc_enable_secure;
  printf(__libc_enable_secure = %d\n, __libc_enable_secure);
  return 0;
}
EOF
$ cc -o frob-gid frob-gid.c
$ ./frob-gid
__libc_enable_secure = 0

Now we make frob-gid sgid, using another of the groups of the current
user:

$ groups
users dialout [...]
$ chown $(id -nu).dialout frob-gid
$ chmod g+s frob-gid

At this point, the output of frob-gid is 1 on Linux, while 0 on Hurd.

__libc_enable_secure is set by checking for the EXEC_SECURE flag, which 
e.g. diskfs_S_file_exec sets before calling exec_exec. Reading 
fshelp_exec_reauth makes me think this behaviour is somehow wanted, and 
this code (except fixes like 913d709e1) is basically doing that way for
decades.

p11-kit uses __libc_enable_secure in its replacement for
getauxval(AT_SECURE), falling back to issetugid (which we don't have)
and then to getresuid (which we have).

I don't have much knowledge in how this behaviour should be, so
a) the current Hurd behaviour is fine and conformant, so p11-kit should
   avoid using __libc_enable_secure for getauxval(AT_SECURE)
b) the behaviour is wrong and should be fixed in Hurd
?

Thanks,
-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.