When using the mac_biba module, only root processes that are capable of
attaining biba/equal status are considered privileged. Among the privileges
to be lost for processes that cannot attain biba/equal is the ability to
set the login class of the process.

When sshd sets the user's context upon successful authentication
(session.c:1494), both the user's login class and the corresponding MAC
label are set in the same call to setusercontext. Since this isn't an
atomic function, it's possible for the MAC label to be set before the
login class (in my case, this certainly happens.) Therefore, if the
login class of the user logging in has a MAC label in /etc/login.conf
incompatible with biba/equal (e.g. biba/high(high-high)) then the login
class might not be set (in my case it *doesn't* get set.) This can cause
unexpected behavior for tools that can be configured by login class,
e.g. rctl.

My proposed solution is to separate context-setting into two calls to
setusercontext, with the first call setting all but LOGIN_SETMAC, and
the second call setting only LOGIN_SETMAC. I've included a patch, which
works on my system.

Fix: Patch /usr/src/crypto/openssh/session.c so that the MAC label is explicitly
set after the login class is set.

Patch attached with submission follows:
How-To-Repeat: - Enable mac_biba.
- Set the MAC label of a login class to ":label=biba/high(high-high):"
  in /etc/login.conf and run cap_mkdb. By default, sshd will probably
  run under the "default" login class; therefore, use a different login
  class so that a change in login class is required upon login.
- Log in remotely as a user who is a member of the login class modified
  in the step above. The login should succeed.
- Look at /var/log/messages for a message regarding setloginclass, and/or
  use `ps -o class -aux | grep sshd` to verify that the login class hasn't
  been set properly for the logged-in user.