Bug 1043

Summary: Trusted IRIX Support
Product: Portable OpenSSH Reporter: Jason Ostermann <josterm>
Component: sshdAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED LATER    
Severity: enhancement CC: djm, dtucker
Priority: P2 Keywords: help-wanted, patch
Version: -current   
Hardware: MIPS   
OS: IRIX   
Attachments:
Description Flags
Patch to apply Trusted IRIX changes none

Description Jason Ostermann 2005-05-20 04:25:36 AEST 
sshd does not fully support Trusted IRIX. We're aiming to meet specific password
requirements that require either using IRIX's login(1), or PAM. Setting UseLogin
to Yes is not appropriate as explained below.

The sshd daemon must run with certain privileges to support the changing of
passwords, validating passwords, etc. In the normal UNIX realm, this is done as
root, then changing to the user's UID removes the privliege. In the Trusted OS
realm, the privilege is independant of the UID - changing to the user does not
remove the privileges. Thus, the stock OpenSSH 4.0p1, when using PAM, results in
a user shell with elevated privileges that they should not have, as they have
been grated directly by the sshd process.

To my (limited) understanding, the following changes have to take place:
1) Change the MAC (Mandatory Access Control) label of the process to the label
requested by the user. This is loaded by the SGI pam_mac module into the PAM
envinronment variable "MAC". I'm assuming this should happen sometime around
permanently_set_uid in uidswap.c.
2) Change the capabilities of the process to the capabilities requested by the
user. This is loaded by the SGI pam_cap module into the PAM encironment variable
"CAP". I'm also assuming this should happen sometime around permanently_set_uid
in uidswap.c.
3) Ignore the sanity checks at the end of permanently_set_uid that ensures the
user cannot change back to the prior uid. If they request, and are granted, the
capabilities to do that, then it's ok.

This works with UsePrivilegeSeparation set to OFF, and UseLogin set to OFF. In
the Trusted OS realm, UsePrivilegeSeparation has little meaning. We have run
with UseLogin set to ON previously, but this requires authenticating to ssh and
to login, as SGI login does not support -f. In addition, failure lockout
password controls are not enforced on the first password authentication. Using
keys to avoid the initial password prompt is not feasable in our environment.
Comment 1 Jason Ostermann 2005-05-21 07:27:26 AEST 
Created attachment 919 [details]
Patch to apply Trusted IRIX changes

Proposed patch for Trusted IRIX support. Uncertain if it is complete or will
support non-PAM or PrivilegeSeparation users. Requesting feedback.
Comment 2 Darren Tucker 2005-05-21 13:17:08 AEST 
Comment on attachment 919 [details]
Patch to apply Trusted IRIX changes

For the most part, it looks pretty good.  The platform-specific bits are where
they're supposed to be and the code looks OK.  I can't comment on it's
functionality since I don't know IRIX at all.

There's a few minor stylistic things.  If you haven't already, please take a
look at http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9

>+         AC_DEFINE(WITH_IRIX_CAP)
>+         AC_DEFINE(WITH_IRIX_MAC)

We're slowly moving toward the 3-arg form of AC_DEFINE rather than acconfig.h
entries, eg:
	   AC_DEFINE(WITH_IRIX_MAC, 1, [Use IRIX MAC Label support])

>+ #ifdef WITH_IRIX_CAP
>+ void
>+ irix_set_cap(const char * cap_string)
>+ {
>+         cap_t running_cap;
>+         if(cap_string == NULL)

Most of the code (and the examples in style(9) have a blank line after variable
declarations.

>+                 fatal("irix_set_cap received NULL for input!");
>+         if(sysconf(_SC_CAP) != 0) {

ditto space after "if".

>--- openssh-4.0p1.trix/session.c        Thu May 12 13:03:23 2005
[...]
>+ #ifdef WITH_IRIX_CAP
>+         /* Set the user's capabilities before running their RC files!!
>+            Only if we won't use login(1), as login handles setting
>+            capabilities itself */
>+         if (!options.use_login) {
>+                 if(child_get_env(env,"CAP") == NULL)
>+                         irix_set_cap("all=");
>+                 else
>+                         irix_set_cap(child_get_env(env,"CAP"));
>+         }
>+ #endif /* WITH_IRIX_CAP */

This is OK for now.  Some time in the future, we're going to attempt to factor
out the platform specific code that does things like this on various platforms,
in an attempt to make the main code easier to sync and maintain.  At that time,
this could be moved to platform_set_credentials() or whatever it ends up being
called.
Comment 3 Darren Tucker 2008-01-01 02:19:00 AEDT 
Target 4.8.

This would also be a good point to start using platform.c for theses things.

Jason, are you still around and able to test this configuration?
Comment 4 Damien Miller 2009-09-09 10:14:35 AEST 
Someone with Trusted Irix needs to step up and get this patch to the point where it can be imported. This is a matter of updating the patch to OpenSSH -current and performing testing. None of the regular developers have access to Irix anymore.
Comment 5 Darren Tucker 2015-05-06 16:43:23 AEST 
Given the current state of SGI I can't imagine this happening unless someone with a Trusted IRIX system wants to update and test the diff, and since that doesn't seem to have happened I would guess nobody wants it, so I'm closing this bug.  If you have a a burning need for this and have the time and hardware to work on this please re-open.
Comment 6 Damien Miller 2016-08-02 10:41:11 AEST 
Close all resolved bugs after 7.3p1 release