Kyle Moffett <[EMAIL PROTECTED]> writes:
setuid() et. al. require no additional logic because they just modify
UID/GID. If there are any key-rings associated with the UID/GID, those
won't be available any more and the ones of the new UID/GID will, but
that is the only changing one part of the set. On the other hand, keys
that are not linked through the UID or GID will remain the same without
explicit manipulation. This makes it easy for me to give a setuid
program the ability to read in a file from my AFS home.
Nice. Sessions only change upon explicit KEYCTL_SET(KEY_SESSION, ...)?
Is there any way to figure out or be notified when a certain key is no longer referenced? I suppose you do some refcounting.
Keys will have refcounts, and when the refcount hits zero it will be deleted.
Kernel stuff will be able to register a set of callbacks with a key-type to control
creation, deletion, modificiation, etc.
KEYCTL_SHLOCK KEYCTL_EXLOCK KEYCTL_UNLOCK: A mandatory lock on the key/key-ring
Be careful with those :) Are the locks connected to the open file, and discarded on close?
Probably only privileged processes (CAP_LINUX_KEYRING?) or maybe those with write privileges will be able to use those (Even the SHLOCK).
Then there is the question about default PAGs and the PAG jail. I'm still
not sure if those are necessary or even desirable. The way the current AFS
implementations seems to work is that if you don't have an allocated PAG
([EMAIL PROTECTED] session key?), your uid is used as the key under which to
store your tokens. This is handy as you don't need to initialize tokens for
every login if you do several. Also, once you have a real PAG, you can't
touch your default, or any other PAGs. This can be used as a kind of jail,
creating an unauthenticated context where it doesn't matter that I don't
know what I'm doing.
By default, a NULL (not an empty) key-ring is associated with init. If you try
to get the file-handle of a NULL key-ring, it will fail with an error, so you
can't modify it or add keys. Whenever you create a new process/UID/session
whatever, it will receive a NULL key-ring reference. This helps security :-D.
This leaves all decisions of policy to a PAM module and some configurable
programs. (Like key-sh or something :-D)
This seems kinda tricky to implement, _if_ it happens to be desirable.
Despends on how elaborate the access control is. The default PAG is easy
enough to keep under a uid key. But one would need to stop processes from
dropping our session key, right? Or else they could remove it and gain
access to the uid key. Might be undesirable if there are any applications
that change uid to root (say), should root have a default PAG with
interesting tokens attached. Or perhaps I'm just confused about which uid
is used when. Or perhaps root just needs to be careful.
Most likely you wouldn't attach a key to the UID except for a chrooted BIND or
something. For users, the PAM module would use its internal policy to attach
a new session's context to the key-ring used by the other sessions.
Still the PAG jail isn't for real now, as I store my kerberos tickets in an
ordinary file owned by myself...
I am unfamiliar with the "PAG jail", can you please explain this concept to me?
Kyle: are you in sync with dhowells on this?
He and I worked out a lot of the concepts for the patch, but I haven't talked
with him recently.
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
