openssh bugs - May 2005 - [Bug 1043] Trusted IRIX Support

http://bugzilla.mindrot.org/show_bug.cgi?id=1043

           Summary: Trusted IRIX Support
           Product: Portable OpenSSH
           Version: 4.0p1
          Platform: MIPS
        OS/Version: IRIX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: josterm at raytheon.com


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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1043





------- Additional Comments From josterm at raytheon.com  2005-05-21 07:27
-------
Created an attachment (id=919)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=919&action=view)
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1043





------- Additional Comments From dtucker at zip.com.au  2005-05-21 13:17 -------
(From update of attachment 919)
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.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.