porting CCAPI to UNIX

[Ken Hornstein]

>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.

Actually, I have a (limited) prevention strategy in place for that.

>Heck, you can just grab the file descriptor for the ccapi daemon
>through /proc!

Have you _tried_ doing that?  I have, and from what I see you _cannot_
do that for Unix domain sockets.  They're definately there in /proc,
but you can't perform any I/O on them.  In Linux they are linked to a
nonexistant file and on Solaris all of the fd's in proc are mode 000.

I said originally that this wasn't fullproof.  But it's the best I can
do.  It is certainly a lot better than anything that relies on file
permissions, which is circumventable by an attacker with no programming
experience.  Would I use an OS facility if it provided the same
semantics?  You bet.  But we don't have that today (except on MacOS X,
and in that case I do use the supplied API cache).

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

Look, I'm not interested in getting into a discussion where my
requirements are redefined for me, which is where I feel this is headed
if I explain the whole background behind this.  I've stated the
requirements: they are what they are.  Moving on ...

>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).

Actually, I have demonstrable proof that this credential cache _does_
help me.  Yes, I've made my nasty, evil bed ... I have no one to blame
but myself if it breaks in the future.  If it breaks in the future, I'll
burn that bridge when I come to it.

My point was not to advocate this scheme: it was just to explain what
I did in the context of the CCAPI discussion.  Treat it as food for
though or a cautionary tale, whichever you prefer.

--Ken