porting CCAPI to UNIX

[Nicolas Williams]

On Tue, May 08, 2007 at 03:01:44PM -0400, Ken Hornstein wrote:
> >> I don't see how that would work.  How would I store Kerberos credentials
> >> inside of a PAG?  (Given my client base I can't assume AFS is available).
> >
> >Associate the credential cache with the PAG, the way AFS does.
> 
> Ummm ... yeah?  How do I do that as a userspace process?  I don't have
> the luxury of being in the kernel like AFS does.

/tmp/krb5cc_pag<PAG#>

Every time you need creds you find out your PAG# and use that to find
the cred cache.

You may need to have a daemon to handle ccache registration if you don't
want to live with anything-goes-1777-tmp-dirs.

> >Why do you need to restrict the daemon to clients in the same session?
> 
> It's not necessary that the daemon be restricted, per se ... like you
> surmise, it's just that I want to insure that only processes within the
> same session have access to that session's credentials.  What I _don't_
> want is processes that have the same Unix userid but are in a different
> session being able to access these credentials.

As in by accident or at all?  Because unless you drop PRIV_PROC_SESSION
(or equivalent) you can always attach a debugger to processes in your
other sessions.  Heck, you can just grab the file descriptor for the
ccapi daemon through /proc!

> I looked into this, but given that requiring OpenAFS is not an option I
> cannot see a way of doing this on a portable manner.  When you're doing
> Unix IPC the best you can get is Unix userid and group membership of
> the peer.  Perhaps if, like you said, the task ID was included in the
> ucred structure that would be sufficient at least for Solaris ... but
> your implication is that currently it does not (I guess the version of
> Solaris I am using is too old; it lacks door_ucred()).  So the only
> solution I could come up with was restricting access to the credential
> cache server itself ... and that's how I came up with the current scheme.

Note that even this scheme you're not protecting against the same users'
other sessions (see above).

> Why I want these security semantics is a long story, but it's the
> result of hard-learned lessons.  I can share the whole saga over a
> beer sometime if you like.

I think it's important to know why you want this.

The only ways to protect a user's processes against the users' other
procesess is to either: a) add a session construct with the desired
access control semantics (neither Solaris, nor Linux, nor AIX, nor HPUX,
nor *BSDs give you this), b) add a privilege system (like, say,
Solaris') and drop the debug privilege (but this is too large a hammer
as a it affects inter-process interactions withing a single session), c)
use a labelling system (as in SELinux or Solaris 10 Trusted Extensions)
(which may or may not be too big a hammer, depending on why you want
this feature).

Pretending that you have such an access control feature when you don't
doesn't really help you, and if it leads you to do things like dup2(fd
rlimit) + lower the fd rlimit, then it's putting you well into dangerous
territory (namely: future OS releases can break you).

Nico
--