openssh unix dev - Feb 2016 - Test Failure OpenSSH 7.1 P2 on HPE NSE for key-commands

On February 9, 2016 7:28 PM, Darren Tucker wrote:
> To: Randall S. Becker <rsbecker at nexbridge.com>
> Cc: OpenSSH Devel List <openssh-unix-dev at mindrot.org>
> Subject: Re: Test Failure OpenSSH 7.1 P2 on HPE NSE for key-commands
> 
> On Wed, Feb 10, 2016 at 10:35 AM, Randall S. Becker
> <rsbecker at nexbridge.com> wrote:
> > Thread split from my previous communication. Here is the key-commands
> > logs on the platform.
> 
> [...]
> 
> OK, in this case the interesting bit is in the failed-sshd.log.
> 
> > Unsafe AuthorizedKeysCommand
"/var/run/keycommand_SUPER.SUPER":
> bad
> > ownership or modes for file /var/run/keycommand_SUPER.SUPER
> >
> > debug1: restore_uid: 65535/255
> 
> sshd ensures that the AuthorizedKeysCommand can't be modified by a non-
> privileged user for obvious reasons.
> 
> Based on what you said earlier, your root (equivalent?) user is not uid 0. 
I
> suspect that the permissions on the keycommand file to not match sshd's
> expectations.  The code that checks this is in
> auth2-pubkey.c:subprocess() which calls auth.c:auth_secure_path().
> 
> What are the file permissions on /var/run/keycommand_SUPER.SUPER and
> its parent directories?  Did you run the test with SUDO=sudo?  Where did
> SUPER.SUPER come from?
SUPERUSER ends up being 65535, which is root on this platform. SUPER.SUPER is
the actual name of root. /var and /var/run are both 755, while
/var/run/keycommand_SUPER.SUPER is 644.

We do have to run the whole test suite under sudo anyway.

On Tue, Feb 09, 2016 at 07:46:45PM -0500, Randall S. Becker wrote:
[...]
> SUPERUSER ends up being 65535, which is root on this platform. SUPER.SUPER
> is the actual name of root. /var and /var/run are both 755, while
> /var/run/keycommand_SUPER.SUPER is 644.
OK, I think the ownership is the problem.

auth2-pubkey.c:subprocess() does this:

	if (stat(av[0], &st) < 0)
[...]
	if (auth_secure_path(av[0], &st, NULL, 0,
	    errmsg, sizeof(errmsg)) != 0) {
		error("Unsafe %s \"%s\": %s", tag, av[0], errmsg);

The 4th arg to auth_secure_path is the UID we expect the file to be owned by.

If you apply the following and compile with -DROOT_UID=65535 does it work?
What does ./config.guess report the platform as?

diff --git a/auth2-pubkey.c b/auth2-pubkey.c
index 41b34ae..bdcb2c2 100644
--- a/auth2-pubkey.c
+++ b/auth2-pubkey.c
@@ -420,7 +420,7 @@ subprocess(const char *tag, struct passwd *pw, const char
*command,
 		restore_uid();
 		return 0;
 	}
-	if (auth_secure_path(av[0], &st, NULL, 0,
+	if (auth_secure_path(av[0], &st, NULL, ROOT_UID,
 	    errmsg, sizeof(errmsg)) != 0) {
 		error("Unsafe %s \"%s\": %s", tag, av[0], errmsg);
 		restore_uid();
diff --git a/defines.h b/defines.h
index a438ddd..7489fef 100644
--- a/defines.h
+++ b/defines.h
@@ -857,4 +857,8 @@ struct winsize {
 # define USE_SYSTEM_GLOB
 #endif
 
+#ifndef ROOT_UID
+# define ROOT_UID	0
+#endif
+
 #endif /* _DEFINES_H */

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On February 9, 2016 8:05 PM, Darren Tucker wrote:
> To: Randall S. Becker <rsbecker at nexbridge.com>
> Cc: 'OpenSSH Devel List' <openssh-unix-dev at mindrot.org>
> Subject: Re: Test Failure OpenSSH 7.1 P2 on HPE NSE for key-commands
> 
> On Tue, Feb 09, 2016 at 07:46:45PM -0500, Randall S. Becker wrote:
> [...]
> > SUPERUSER ends up being 65535, which is root on this platform.
> > SUPER.SUPER is the actual name of root. /var and /var/run are both
> > 755, while /var/run/keycommand_SUPER.SUPER is 644.
> 
> OK, I think the ownership is the problem.
Confirmed.
> auth2-pubkey.c:subprocess() does this:
> 
> 	if (stat(av[0], &st) < 0)
> [...]
> 	if (auth_secure_path(av[0], &st, NULL, 0,
> 	    errmsg, sizeof(errmsg)) != 0) {
> 		error("Unsafe %s \"%s\": %s", tag, av[0], errmsg);
> 
> The 4th arg to auth_secure_path is the UID we expect the file to be owned
> by.
> 
> If you apply the following and compile with -DROOT_UID=65535 does it
> work?
Replacing 
 	if (auth_secure_path(av[0], &st, NULL, 0,
with
	if (auth_secure_path(av[0], &st, NULL, SUPERUSER,

Causes the keys-command test to pass! I would prefer this change to
introducing ROOT_UID as a duplicate since we already have SUPERUSER. What
I'm not sure about is whether SUPERUSER originated with a branch of ours or
not. To be investigated later. The original #define we had was in include.h
#define SUPERUSER 0, which we wrapped defining SUPERUSER 65535 on our
platform and it is used throughout. No real issue changing it to ROOT_UID if
we must .
> What does ./config.guess report the platform as?
>From config.status:
S["host_os"]="nsk"
S["host_vendor"]="tandem"
S["host_cpu"]="nse"
S["host"]="nse-tandem-nsk"
S["build_os"]="nsk"
S["build_vendor"]="tandem"
S["build_cpu"]="nse"
S["build"]="nse-tandem-nsk"

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.