[Bug 1043] Trusted IRIX Support

[bugzilla-daemon at mindrot.org]

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.