David Woodhouse <dwmw2(a)infradead.org> wrote:
It's been suggested that perhaps we could use the kernel's
key
management facilities for this. By attaching a key of a certain type to
the session keyring, we get to set it _synchronously_, and we also have
an unambiguous indication of its _absence_.
This facility has been in the vanilla Linux kernel since 2.6.10. See:
Documentation/keys.txt
David, can a process ever override its session keyring and elect to
use
another? That could be a problem -- this has to be immutable after it's
set at login time, I believe.
Unfortunately, yes. There's a keyctl() op that allows a process to change the
session it belongs to.
However, since the key management stuff is not entirely graven in stone yet,
it can be extended. I can deal with the problem Dave mentioned by adding a
root-privileged keyring to each process that can't just be shuffled aside so
easily for the purpose of keeping track of auditing and security info of this
type. This keyring would be inherited across fork.
Either I can have it so that it is searched first, thus the search order would
become:
Audit (or System, Security or whatever)
Thread
Process
Session
Either that or it could just require explicit searching and not be on the
standard search path.
I'd make the "Audit" keyring owned by root, with modify privileges only for
root and stick keys of the type you'd be dealing with owned by root and only
modifyable by root so that the user can't change them. Furthermore, if you
don't provide an update method for the key type, then the keys are immutable
once instantiated.
David