[OpenAFS] Hardware Grants from Sun

[Nicolas Williams]

On Fri, Feb 23, 2007 at 12:03:58PM -0600, Douglas E. Engert wrote:
> Jeffrey Hutzelman wrote:
> >On Friday, February 23, 2007 09:23:21 AM -0600 "Douglas E. Engert" 
> ><deengert@anl.gov> wrote:
> >>So getting 100,000 in equipment is only part of it. If you are
> >>willing to state a desire to taget OpenSolaris, Sun should be willing
> >>to state a desire to integration of AFS credential handling
> >>in there products too, like ssh delegation of credentials to get
> >>AFS tokens, and having home directories in AFS.
> >
> >Doug, it's worth noting that the sorts of people who can give away 
> >equipment often have little or no control over things like operating 
> >system development, and asking for such things is at best useless. 
> 
> But it is worth asking, to make sure even within Sun one hand knows
> what the other is doing.
> 
> >On the other hand, we have plenty of contacts within Sun to help us with 
> >issues like this, and OpenSolaris, like OpenAFS, is an open-source 
> >software project in which any of us can participate.
> 
> Yes, I know many of them...  and have Bcc'ed Nico and Willys on this note.

[And I'm cc'ing security-discuss@opensolaris.org.]

I assume you're talking about PAGs.

We've waffled internally about how best to deal with PAGs.  Partly we
(well, I) worry that the way PAGs work PAGs are too closely linked to a
single network authentication mechanism and credentials, therefore it's
not general enough for us since we'd want a scheme that works with
multiple security mechanisms.

But the OpenAFS community has a very specific need that you could argue
we should meet without going into a rathole about the generality of
PAGs.  If so, please wander over to the OpenSolaris discussion lists and
tell us what the APIs you'd like us to provide are.

Actual code contributions would be a plus, but first and foremost we'll
need interface specifications.

I imagine that you want something like:

typedef uint64_t pag_t;

pag_t getpag();
pag_t setpag();

or maybe something closer to the traditional AFS PAG facility:

pag_t getpag();
pag_t setpag(pag_t pag, int change_parent);

or maybe:

pag_t getpag();
pag_t setpag();
int setprocpag(pid_t, pag_t);

Or something else?

Of course, there'd be other associated interfaces (see below).

> >Incidentally, it should be noted that Sun's ssh supports GSS-API 
> >userauth and key exchange out of the box, including credential 
> >delegation, and that its PAM support is considerably better than that of 
> >OpenSSH. 
> 
> Yes as you must already know we are using the Solaris 10 ssh and sshd, and 
> Solaris Kerberos with great success, but its not perfect. Sun insists on
> using the default ticket cache for a user: krb5cc_<uid>  rather then a
> session based cache for each sshd session.  They also insist on updating
> only the TGT in a cache when it is acquired, rather then discarding
> all the other tickets, so they will be re obtained using the
> new TGT. This has implications for aklog, as it can end up using
> a ticket that will expire a lot sooner then expected. It also has
> implications after a screen unlock. You also donm't want
> one session deleting the cache!

I'm not sure how important it is to have per-session network
credentials, but I do sympathize -- if nothing else it's what AFS users
are accustomed to.  Issues surrounding how per-user network credentials
are handled are a separate, but related concern.

> I have expressed my concerns to Nico on these issues over the years.

I know :/

> So to force sshd to use a session based cache we added a
> "pam_krb5_cache.so.1 cache=/tmp/krb5cc_%u_%p" to set the cache name.
> 
> We also are using tha pam_afs2.so to get the PAG and token.
> 
> Also as you must already know, I have bee bugging them to
> release the Kerberos header files for Solaris 10, so one could
> compile *aklog* using the Solaris Kerberos. (This is reported to be
> in "update 4". looks like this might be another 6 months!)

I'm not up to date on the S10U4 release schedule.

> We have ben using OpenSolaris Kerberos header files with Solaris 10,
> and so far it works.

It should.  We've not made any changes that could cause you grief, so,
though technically what you're doing is unsupported, it's reasonably
safe, and once you get through upgrades to S10U4 you'll be safe (but
change your build to use the shipped headers, not OpenSolaris').

> >As for home directories; we've been putting users' home 
> >directories in AFS for O(15) years, though we only appear to have been 
> >supporting Solaris since 1995. If you have specific issues, please 
> >describe them instead of asking that Sun be "willing to state a desire" 
> >for things to work that already do.
> 
> There are still issues with having to have an AFS token before any
> files in the home directory are accessed, even the .k5login. Since this
> is a general OS problem.
> 
> The point is things don't work as well as they could, partly because the
> OS developers don't use AFS. This "acceptance of a "gift" might be the
> time to get Sun to look a little closer at how things really work.

I have no idea what gift you're talking about.  If Sun is donating
equipment to the OpenAFS community, I think that'd be great.  As for the
OS support that you want, we have open mailing lists -- come tell us
_there_ (if nothing else because there are many other engineers whose
attention you could catch besides your usual suspects).  Details would
be nice, code would be even better.

BTW, a PAG facility that's faithful to the AFS notion of PAGs should be
relatively easy to specify and implement for Solaris, but it will be
more involved than you might have thought.  That's because we have
proc(4), proc(1), truss(1) and ucred_get(3C) to worry about, plus
libproc.  So we're talking about:

 - new getpag()/setpag() syscalls and library stubs
 - new cr*() functions
 - procfs (proc(4)) exts (say, PCSPAG operation to set a proc's PAG)
    - and libproc exts (Ppag(), Psetpag())
    - and proc(1) exts (say, a new option for pcred(1), or a new cmd?)
 - ucred_get(3C) exts (ucred_getpag(3C))
 - kinit(1) exts?
 - pam_unix_cred(5) exts? (set the caller's PAG!)
 - extensions to krb5_cc_default() and gssd(1M) to find per-session
   ccaches instead of per-user ccaches

The ARC will have to see a spec too.  It'd help to have OpenAFS folks
helping us get a spec together and get through the ARC review.

Again, the issue for me is the lack of generality of PAGs.  Whereas
Linux-style keyrings seem be too general.  Your best bet may be to argue
that generality be damned, you need this now.

[Also, from experience I know that thread affinity of credentials is a
controversial subject.  Certainly with respect to cred_t in general,
possibly (likely?) with respect to associated network credentials.  I
mention this because the Linux keyring facility has thread, process,
session and user affinity.]

Does this help?

Nico
--