Solaris ssh pam_krb

Nicolas Williams Nicolas.Williams at sun.com
Mon Apr 3 12:11:14 EDT 2006


Let's uplevel a bit.

To me PAGs provide a useful distinction between processes in some sort
of session, sharing some common characteristics, one that is better than
environment variables in that it is easily (cheaply) observable from the
IPC peers.

PAGs have, for me, at least these uses:

 - As an Identity Selection Problem tool.

   This is how I understand you use PAGs.

   Different sessions of the same user can be associated with
   different network authentication credentials (or ID selection
   hints/preferences), possibly representing slightly different views
   of the same user's identity(ies) (e.g., joe vs. joe/admin) or very
   different identities altogether.


 - As a link from cred_t to user-land that can be used to "extend"
   cred_t.

   Specifically, Solaris RBAC authorization and profile assingments to
   users are almost like group memberships, except that RBAC is
   implemented purely in userl-land (e.g., pfexec(1) relies on being
   set-uid 0 and evaluates requests according to the caller's RBAC
   profile).

   I can see a useful extension for RBAC whereby additional profiles and
   authorizations can be granted su-like after logging in, or when
   logging in on concolse but not remotely, etc...  And for this
   tracking granted authorizations and profiles via PAGs could be
   useful.


 - As a better point for tracking extant references to network
   authentication credentials than UIDs.  I'm not too sure that this is
   correct though.  Bill Sommerfeld and/or Casper Dick (IIRC) have
   suggested tracking references to UIDs by cred_t's and to heck with
   PAGs, and as seducing as PAGs are I'm not sure that the above two
   uses really add all that much value, and perhaps they are right.


Finally, PAGs, whether AFS-like or not, do not make a good process group
separation facility.  Unless they are modelled as labels (as in Trusted
Solaris), which, I think, *may* be out of the question.

PAGs, like group memberships, do not, IMO, make a good access control on
process tracing, and they are orthogonal to [local] filesystem access
controls.  It would be rather surprising if one could not trace/debug
one's processes from different login sessions.

Yet if PAGs have no impact on process tracing authorization decisions
then I don't think one should claim that PAGs provide *any* inter-
session protection for network authentication credentials, and the like.

Here we have an all-or-nothing choice: either PAGs really do provide a
process group separation feature, or they don't.  I'm pretty sure that,
taking backwards compatibility requirements into account, and maybe even
regardless, they cannot.

Cheers,

Nico
-- 



More information about the Kerberos mailing list