Current each label runs its own sshd(1M) and that sshd is not aware of
Zones or TX labels at all. If we ssh to a labelled zone this means we
are doing authentication outside of the Trusted Path (regardless of
which ssh userauth type we use), I don't like this.
In the particular case of password/keyboard-interactive authentication
there is a problem in the local files case. The local files repository
supports lock_after_retries (see user_attr(4)). When all TX label zones
are running the same nameservice (generally this is the case) and that
repository is files then we usually have a single global zone (Trusted
Path) ncsd and also have /etc/passwd and /etc/shadow lofs mounted into
the label zone.
If a user fails the authentication passwdutil.so needs to update the
/etc/shadow field but it can't do that because /etc/shadow is read-only.
If instead we don't lofs mount the /etc/passwd and /etc/shadow but
provide some other means to keep them in sync with the global zone then
the counter (and subsequent locking) only happens at a single label.
This problem was first described to me by Bart Blanquart.
I've been trying to find solutions to this problem, and looked at the
issue at three different levels in the stack.
1. passwdutil.so - this is who needs to do the actual writes
to /etc/shadow
This doesn't fix the auth outside of the Trusted Path issue,
and it is a very narrow fix. One of the thoughts I had here
is that we could do this with something like rpc.nispasswdd
but for files.
2. PAM - what if we could run PAM in the global zone
This could work and might have other uses. The idea would be
to have libpam use doors to talk to a global zone process.
The advantage here is it "fixes" more than just sshd in a
labeled zone. It also means the authentication happens in
the Trusted Path.
3. sshd - make it label aware.
It would be wise to make this configurable (ie we could still
deploy as we do today). However I think this is potentially
quite complex and there are possible issues with the fact that
ssh can have multiple channels open at different times in the
lifecycle of the connection.
Discuss....
--
Darren J Moffat
