porting CCAPI to UNIX
kenh at cmf.nrl.navy.mil
Tue May 8 16:07:54 EDT 2007
>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
Actually, I have a (limited) prevention strategy in place for that.
>Heck, you can just grab the file descriptor for the ccapi daemon
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.
More information about the krbdev