Henry B. Hotz wrote:
On Aug 29, 2007, at 9:46 AM, Howard Chu wrote:
And with it it has the same ownership issue as a regular ccache
file. Also, access control is limited to what inheritance provides.
Could you summarize these ownership concerns again, or point me at
an archived posting that enumerates these issues? I've missed some
context somewhere.
The context is that some of us would like to solve the AFS PAG
(Process Authentication Group) problem the same way we solve the
secure credential cache problem. PAGs have better semantics than any
extant Kerberos ccache implementation.
Ugh. I was writing AFS and DCE/DFS servers back in the mid-90s, I remember the
"funny group number" hacks. I painfully remember when DCE decided that its
version of PAGs ought to be different from AFS. sheesh.
The "leak-proof" semantics are trivially defeated though, by any desktop
sharing software. Or even running GNU screen in multi-user mode. (I co-authored
screen, and I use the multi-user feature pretty often.)
The interesting thing about this thread, to me, is that we seem to
have people interested in pushing the envelope, and using new
userland capabilities to get better scoping semantics.
The kernel hacks in AFS/DFS were only necessary because their respective
filesystem drivers wanted to use those credentials instead of the standard Unix
credentials. The reason we can have a discussion about userland solutions for
Kerberos in general is because there are no kernel/filesystem considerations to
muddy the water, the information is only needed in userland. If you decide that
you want a credential cache that will also work for AFS and OpenDCE then
efficiency will dictate bringing us back to kernel mode.
From a user's perspective, a PAG is like a terminal login session
with two exceptions. First it's "secure"; you can't break into and
access anything from another session (even with the same UID).
Second, you can create new ones on the fly; on AFS this is done by
running "pagsh" and doing work under the new shell.
PAGs are inherited by sub-processes, including set-uid-root ones like
lp (which is handy for printing files that live in AFS filespace).
There is no set-pag-id capability. Once you're in a PAG the only
ways to get out are to create a new, empty PAG or to terminate the
process (reverting to the parent's PAG as part of returning control
to the parent).
A new PAG has no credentials. You can test a program inside a new
PAG without worrying that it might modify your files.
Credentials added to a new PAG do not "leak" to other processes on
the machine. You can create a terminal window with administrative
credentials in its new PAG without worrying that a process run
elsewhere might acquire the ability to do more than you intended.
When we talk to OS people about PAGs we usually get hung up on the
"secure storage" issues, and don't necessarily get the inheritance/
scoping problem solved. The Linux keyring implementation had issues
along those lines, but I think (hope) that the implementation at
least allowed PAG semantics to be implemented, even if it provided a
bunch of other unimportant options.
It sounds like you're happy with the inheritance model and don't need anything
else. But again, your assertion that strict inheritance in the implementation
guarantees secure usage is false.
Also, despite the lack of a set-pag-id call, it was quite simple (at least in
earlier revisions) to simply call setgroups() with the funny group numbers to
assign a process to any PAG desired, or switch back and forth among many sets
of credentials.
So, I think it's important to recognize that nothing you devise will be
foolproof. Anyone who wants to shoot themselves in the foot and give away their
security tokens can always find a way to do so, and even people who don't want
to can frequently be tricked into doing so anyway.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
